Nmap Development mailing list archives
Re: Request for Comments: Nping Echo Protocol
From: "Luis M." <luis.mgarc () gmail com>
Date: Mon, 27 Jul 2009 11:55:28 +0200
Hi Brandon, Brandon Enright wrote:
Unless Nping is compiled without OpenSSL support,You haven't described what happens if you use a client compiled with OpenSSL but a server without or vice versa. I'd suggest that the server and client both require a flag like "--unencrypted" to allow fallback no encryption. A server/client compiled without OpenSSL should return a fatal warning if used without --unencrypted. This will prevent a MitM attack degrading the channel to no encryption.
Yes, that makes sense.
Okay, SHA-256. It's overkill but you're right that there isn't a good smaller alternative. We could truncate SHA-256 to only 128 bits but since we aren't pressed for space, might as well use the full 256.
Yes, I think we should use the full 256 bits.
Encryption is good at hiding contents, it is bad at resisting certain types of attacks. Matasano *just* did a long and annoying blog post about this very thing: http://74.125.155.132/search?q=cache:693pTMNFilMJ:www.matasano.com/log/1749/typing-the-letters-a-e-s-into-your-code-youre-doing-it-wrong/+matsano+aes&cd=1&hl=en&ct=clnk&gl=us In short, you want to use the encryption to protect the contents. You want to use a MAC to authenticate the contents. Put another way, the SHA-3 competition would not exist if one could just use AES.
Maybe I didn't explain myself very well. When I talk about using the checksum for authentication, what I mean is the following: Given message A, we compute its checksum S=H(A). The message we want to transmit is P=A+S. So what we do is to encrypt the whole thing to obtain the ciphertext: C=Ek(A+S). As the hash is included into the encrypted text, any change to the ciphertext (whatever mode we use), corrupts the message. Let's say an attacker flips one single bit of C, obtaining C' and forwards C' to the server. When the server gets C', decrypts it P'=Dk(C'). P' should correspond to a message A' and a checksum S' but the fact that the attacker flipped one bit in the message means that now S' != H(A'), because even if the attacker managed to change the message so P and P' differ only in a single bit, there is no way the decrypted checksum validates. However, although I think using encrypted hashes is almost the same as using MACs, we should probably go for MAC as Openssl has support for them and it sounds right to use Message Authentication Codes to actually do authentication.
Better to make the server inform the client what the starting nonce is.
So how would this all fit together?
For a nonce (sequence number/IV), something randomly generated by the
server should do. It will be transmitted in plain-text which is okay.
For a MAC, we should use HMAC-SHA-256.
For a PSK, we should use iterated SHA-256. I'd suggest 128k
iterations. That is, if somebody shares the key "pass" then "pass"
should be hashed with SHA-256 128k times. If that seems to take too
long maybe only 64k or even 4k iterations is enough. You want the
whole iteration process to take about 100ms on an average computer.
The calculation only needs to happen once on the server side and once
on the client side.
The derived PSK can be used as the key to both AES256-CTR and
HMAC-SHA-256.
The client can prove that it has the PSK by computing the HMAC(nonce,
PSK).
That would look something like:
server -> client:
"hello" + <nonce>
client -> server:
hmac("reply" + <nonce>, <psk>)
You can fit this exchange in with the rest of the protocol exchange.
It allows the client to prove that it is legit to the server. If you
want the server to prove that it is legit to the client do something
like:
server -> client:
<servernonce>, hmac("hello" + <servernonce>, <psk>), <clientnonce>
client -> server:
hmac("reply" + <clientnonce>, <psk>)
Once the client and server have authorized each other and established a
nonce for each, then the messages can be encrypted like so:
ciphertext = <nonce> + AES-256-CTR(<message>, <nonce>)
ciphertext = <ciphertext> + hmac(<ciphertext>, <psk>)
The server should use the server nonce and the client should use the
client nonce.
This email has gone on long enough and I'm sure it's pretty confusing.
If you have any questions or quibbles let me know. If you are having
trouble understanding my pseudo-protocol let me know and I can code a
working version in perl.
Well, yes, I'm actually having problems to understand your proposal.
This is what I've understood. Here I present a simple list of steps and
in the attached document I include a modified version of the protocol
RFC. (Please check sections 2.4, 2.5, 2.6 and 2.7. An also flow diagrams
in section 2.12). However, if I didn't get it right, it would be really
helpful
If you could sketch the basic flow diagram or how the initial packets
headers would look like.
Here's what I've understood:
1. Client sends initial HELLO packet encrypted, but also provides the
nonce unencrypted, at the beginning of the packet.
2. Server sends HELLO RESPONSE also encrypted and also providing its
own nonce unencrypted, at the beginning of the packet.
3. Client computes the challenge:
HMAC-SHA256("dummy text" + <server_nonce>, <psk>)
and sends it to the server.
4. Server verifies the challege response. If correct, now it's server's turn
prove himself computing:
HMAC-SHA256("dummy text" + <client_nonce>, <psk>)
5. The client verifies the challenge response received from the server. If
it is correct, proceeds with the SPECS packet and both server and client
live happily during their session.
NOTES:
The first packet (1) is AES-CTR encrypted using client_nonce as the IV.
Subsequent client packets are also encrypted that way, but nonce is not
included anymore as the server already knows it.
The second packet (2) is encrypted using server_nonce as the IV.
Subsequent server-generated packets are also encrypted that way,
but the nonce is not included anymore as the client already knows it.
The HMAC-SHA256 is sent unencrypted, this is, it is not feed into the
encryption function. (Why do we do this?)
The HMAC-SHA256 does NOT cover the plaintext, but authenticates
the ciphertext. This is, the data fed into the HMAC computation function
is the ciphertext, not the plaintext. (Why do we do this?)
Again, thanks for your comments, Brandon,
Regards,
Luis.
+-----------------------------------------------------------------------------+
NPING ECHO PROTOCOL
PROTOCOL SPECIFICATION
Request for Comments
July 2009
Luis MartinGarcia
(luis.mgarc () gmail com)
+-----------------------------------------------------------------------------+
PREFACE
This document introduces Nping Echo Protocol, the protocol that has been
designed to support a new feature that allows Nping users to see what the
packets they send look like when they reach their destination.
TABLE OF CONTENTS
1. INTRODUCTION ..................................................... x
2. NPING ECHO PROTOCOL SPECIFICATION................................. x
2.1 General Packet Format.............. ........................... x
2.2 Field Description ............................................. x
2.3 Operation Codes ............................................... x
2.4 Operation HELLO................................................ x
2.5 Operation HELLO RESPONSE ...................................... x
2.6 Operation CLIENT_CHALLENGE_RESPONSE ............................x
2.7 Operation SERVER_CHALLENGE_RESPONSE ............................x
2.8 Operation SPECS ............................................... x
2.9 Operation READY ............................................... x
2.10 Operation ECHOPKT ............................................. x
2.11 Operation QUIT ................................................ x
2.12 Flow Diagram .................................................. x
2.13 Security .......................................................x
3. GLOSSARY .......................................................... x
4. REFERENCES ........................................................ x
1. INTRODUCTION
Troubleshooting routing and firewall issues is a common task nowadays.
The scenario is generally that some network traffic should be flowing
but isn't. The causes of problem can range from routing issues to
network firewall to host-based firewalls to all sorts of other strange
things. It is usually the "middle box" problem that is the hardest to
find.
Suppose there is some host with a TCP service listening that you can't
connect to for an unknown reason. If a Nmap -sS scan doesn't show the
port as open there are a multitude of possible problems. Maybe the SYN
packet never made it because of some firewall in the middle. Maybe the
SYN did make it but the SYN+ACK got dropped on it's way back to you.
Maybe the TTL expired in transit but the ICMP message got blocked by
another firewall before making it back to you. Maybe the SYN made it
but some intermediate host forged a reset packet to snipe the connection
before the SYN+ACK made it back to you.
When things like the above are going on it is often the case that even
hping can't track down the problem alone. One generally have to turn to
Wireshark/tcpdump on one station and hping on the other but sometimes
it may be quite difficult to coordinate, specially when the person at
the remote host does not even know what an IP address is.
To solve this problem, Nping will have a mode called "Echo mode" (We are
still looking for a better name, suggestions are welcome), that will
give it the power of hping + tcpdump.
Both machines have to be running Nping, one of them in server mode and
the other in client mode. The way it works is: the Nping
client performs an initial handshake with the server over some
standard port (creating a side-channel). Then it notifies the server
what packets are about to be sent. The server sets up a liberal BPF
filter that captures those packets, and starts listening. When the server
receives a packet it encapsulates it (including the link layer frame)
into our own protocol packet and sends it back to the nping client.
This would be essentially like running tcpdump on the remote machine
and having it report back the packets you sent to it with Nping.
By having the side-channel to talk to the server, things like NAT would
become immediately apparent because you'd see your source IP (and
sometimes port) change. Things like "packet shapers" that change TCP
window sizes transparently between hosts would
turn up. It would be easy to tell if the traffic is being dropped in
transit and never gets to the box. It would also be easy to tell if
the traffic does make it to the box but the reply never makes it back
to you.
In general, it would be like sending a postal package to someone and
having them email you a photo of the package when they get it. If you
think your packages are being abused by the parcel service then having
someone on the other end to send information back is a great way to
uncover what is going on.
2. NPING ECHO PROTOCOL SPECIFICATION
2.1 General Packet Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | OP Code | Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. DATA .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Checksum .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
There are 6 different kinds of packets:
HELLO: (C->S)
Informs the server of the highest version we support.
HELLO RESPONSE: (S->C)
Informs the client of the highest version we support.
SPECS: (C->S):
Tells the server what kind of packets we are planning to send.
READY: (S->C):
Tells the client that the server is ready to start receiving
packets.
ECHOPKT: (S->C):
Contains the packet that the server receives from the client.
QUIT: (C->S or S->C):
Asks to stop the echo process.
2.2 Field Description
Version: 8 bits
Current version of the protocol. This document covers version 0x01.
Operation Code: 8 bits
Indicates the type of packet. It must be one of the operation
codes defined in section 2.2.
Total Length: 16 bits
Length of the entire packet, measured in 32bit words. Value must
be in NETWORK byte order.
Sequence Number: 32 bits
Initially each peer generates a random sequence number and then
increments it by one in each packet that it sends. It must be
in NETWORK byte order. This field is intented to provide some,
very basic, protection against replay attacks.
Reserved: 64 bits
Reserved for future use. Reserved fields have been added for two
reason. To allow future extension of the protocol and to make
the header a multiple of 128 bits needed to satisfy AES encryption
requirements in block size.
Data: variable length
Operation specific data.
Checksum: 256 bits
SHA-256 sum of the entire packet. Checksum computation includes
the checksum field which must be previously set to zero.
This field is intended to provide client authentication. Echo
messages are transmitted encrypted (unless Nping is compiled
without OpenSSL). When a server receives a packet, it decrypts it
using a symmetric key known by both ends. Then it verifies the
checksum. If the checksum is correct it assumes the client is
an authorized user because only a person who knows the encryption
key and is capable of generating packets that when decrypted
produce valid sums.
2.3 Operation Codes
Operation HELLO: 0x01
Operation HELLO RESPONSE: 0x02
Operation CLIENT_CHALLENGE_RESPONSE
Operation SERVER_CHALLENGE_RESPONSE
Operation SPECS: 0x03
Operation READY: 0x04
Operation ECHOPKT: 0x05
Operation QUIT: 0x06
2.4 Operation HELLO
The HELLO packet is sent by the client and it asks the server
to establish a new session. The packet also informs the server
of the latest version of the protocol that the client supports.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-8 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /* Transmitted as plaintext */
| |
-7 +-- --+
| |
-6 +-- --+
| |
-5 +-- --+
| Client Nonce |
-4 +-- --+
| |
-3 +-- --+
| |
-2 +-- --+
| |
-1 +-- --+
| |
0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /* Encryption starts here */
| Version | OP Code 0x01 | Total Length |
1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Reserved | IP version |
4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
5 +-- --+
| |
6 +-- Partner IP address --+
| |
7 +-- --+
| |
8 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
9 +-- --+
| |
10 +-- Reserved --+
| |
11 +-- --+
| |
12 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /* Encryption ends here */
| |
. . .
. . HMAC-SHA256 .
. . .
| |
20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IP Version: 8 bits
IP version of the following IP address.
Partner IP address: 128 bits
This is the server's IP address as seen by the client. This is
not very useful but is provided for consistency with the HELLO
response packet.
This field has 128 bits to allow use of both IPv4 and IPv6
addresses. When IPv4 is used, only the first four bytes are used.
The rest may be set to zero or filled with random data.
Reserved: 128 bits
Reserved for future use.
2.5 Operation HELLO RESPONSE
The HELLO RESPONSE packet is sent by the server to indicate the client
that he is actually a Nping Echo server and to inform about the
latest version it supports.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-8 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /* Transmitted as plaintext */
| |
-7 +-- --+
| |
-6 +-- --+
| |
-5 +-- --+
| Server Nonce |
-4 +-- --+
| |
-3 +-- --+
| |
-2 +-- --+
| |
-1 +-- --+
| |
0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /* Encryption starts here */
| Version | OP Code 0x01 | Total Length |
1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Reserved | IP version |
4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
5 +-- --+
| |
6 +-- Partner IP address --+
| |
7 +-- --+
| |
8 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
9 +-- --+
| |
10 +-- Reserved --+
| |
11 +-- --+
| |
12 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /* Encryption ends here */
| |
. . .
. . HMAC-SHA256 .
. . .
| |
20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IP Version: 8 bits
IP version of the following IP address.
Partner IP address: 128 bits
This is the client's IP address as seen by the server. This
lets the client to inmediatly detect the presence of some
intermediate device that changes his source IP (e.g a NAT box).
This can also be useful in case the client wants to specify
its own BPF filter (overriding server's default behaviour)
(see section 2.5 for more information).
This field has 128 bits to allow use of both IPv4 and IPv6
addresses. When IPv4 is used, only the first four bytes are used.
The rest may be set to zero or filled with random data.
Reserved: 128 bits
Reserved for future use.
2.6 Operation CLIENT_CHALLENGE_RESPONSE
0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | OP Code 0x0A | Total Length |
1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Reserved |
4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
5 +-- --+
| |
6 +-- HMAC-SHA256("dummy text" + <server_nonce>, <psk>) --+
| |
7 +-- --+
| |
8 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
9 +-- --+
| |
10 +-- Reserved --+
| |
11 +-- --+
| |
12 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. . .
. . HMAC-SHA256 .
. . .
| |
20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.7 Operation SERVER_CHALLENGE_RESPONSE
0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | OP Code 0x0A | Total Length |
1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Reserved |
4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
5 +-- --+
| |
6 +-- HMAC-SHA256("dummy text" + <client_nonce>, <psk>) --+
| |
7 +-- --+
| |
8 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
9 +-- --+
| |
10 +-- Reserved --+
| |
11 +-- --+
| |
12 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. . .
. . HMAC-SHA256 .
. . .
| |
20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.8 Operation SPECS
The SPECS packet is sent by the client to tell the server what kind
of packets it should expect. Additionally, the client may also include
a custom BPF filter for the server.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | OP Code 0x03 | Total Length |
1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol | Reserved | Packet Count |
4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. | |
. . .
. . BPF filter specification .
n . .
| |
n+1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. . .
. . SHA256 Checksum .
. . .
| |
n+9 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Protocol: 8 bits.
Specifies which kind of packets will be sent to the server. It
must contain one of the following values:
0x01 (Protocol TCP)
Tells the server to listen to TCP packets coming from
the client's IP address.
0x02 (Protocol UDP)
Tells the server to listen to UDP packets coming from
the client's IP address.
0x03 (Protocol ICMP)
Tells the server to listen to ICMP packets coming from
the client's IP address.
0x04 (Protocol ARP)
Tells the server to listen to ARP packets coming from
the client's MAC address (or in most cases, server's
gateway MAC address).
0xAA (Custom BPF filter included)
Tells the server to use a custom BPF filter specified in
an additional field.
0xFF (Any protocol)
Tells the server to listen to any packets coming from
the client's IP address.
Reserved: 8 bits
Reserved for future use.
Packet count: 16 bits.
Specifies how many packets will be sent. It must be in NETWORK
byte order.
BPF filter specification: variable length
When field "Protocol" contains value 0xAA, an additional
field is included in the packet: the BPF filter specification.
This field contains a BPF filter specification in tcpdump
format. This is useful when the client wants to override the
server's default BPF filters and capture a different type of
traffic.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BPF Filter Spec Length | .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .
. .
. BFP Filter Spec .
. +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The length is measured in bytes and should be in NETWORK byte
order. If the length is not a multiple of 16, it must be padded
with NULL bytes.
When client specifies an empty filter, meaning capture all
packets, the field will look like:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length=0 | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
As a security measure, the server may not allow use of
custom BPF filters. In that case, a QUIT packet must be
sent to the client.
2.9 Operation READY
The READY packet is sent by the server to indicate the client that
his SPECS packet was accepted and that everything is ready to start
receiving and echoing packets.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | OP Code 0x04 | Total Length |
1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. . .
. . SHA256 Checksum .
. . .
| |
12 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.10 Operation ECHOPKT
The ECHOPKT packet is sent by the server and it contains an echoed
packet.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | OP Code 0x05 | Total Length |
1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Reserved |
4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DLT Type | Packet Length |
5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . .
. . Packet .
. . .
n . +-+-+-+-+-+-+-+-+
| | Padding |
n+1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. . .
. . SHA256 Checksum .
. . .
| |
n+9 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DLT Type: 16 bits.
Specifies the type of link layer device used in the server side.
Since the server includes link layer frames in echoed packets,
the client needs to know the DLT in order to process link layer
header information.
Values used in this field must match DLT types defined in libpcap
and must be transmitted in NETWORK byte order.
Packet Length: 16 bits.
Specifies the length of the echoed packet measured in bytes.
It must be in NETWORK byte order.
Packet: variable length.
This corresponds to the packet being echoed. Server should
store the packet exactly as it was received. No byte order
conversions or any other alteration should be performed.
If the length is not a multiple of 16, it must be padded with
NULL bytes.
2.11 Operation QUIT
The QUIT packet is sent by client or server to tell its peer to
terminate the current session.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | OP Code 0x06 | Total Length |
1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. . .
. . SHA256 Checksum .
. . .
| |
12 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This packet should be sent:
By the client: to tell the server to stop echoing packets and
terminate the current session.
By the server: to tell the client that no custom BPF filter
is allowed so the session will be terminated.
2.12 Flow diagram
The following diagram represents a typical session:
+------+ +------+
|CLIENT| |SERVER|
+------+ +------+
| |
| HELLO | :: Hi. I'm an Nping Client.
|------------------>>| I support version 1.
| |
| |
| HELLO RESPONSE |
|<<------------------| :: Nice 2 meet u. Im a server..
| | I also support version 1
| |
| CLIENT_CHAL_RESP | :: Here's the response to your.
|------------------>>| challenge.
| |
| |
| SERVER_CHAL_RESP |
|<<------------------| :: Your challenge response was OK,
| | here it's mine.
| |
| SPECS |
|------------------>>| :: I'll be sending 5 ICMP
| | Destination Unreachable probes.
| |
| |
| READY |
|<<-- ---------------| :: OK, I'm ready for those probes.
| |
| |
| |
| |
| ECHOPKT |
|<<------------------| :: Here's what I received.
| |
| ECHOPKT |
|<<------------------| :: Here's what I received.
| |
| ECHOPKT |
|<<------------------| :: Here's what I received.
| . |
| . |
| . |
| ECHOPKT |
|<<------------------| :: Here's what I received.
| |
| |
| |
| QUIT |
|------------------>>| :: It's been a pleasure.
The following diagram represents a session where the client requests
the use of a custom BPF filter but the server is configured not to
allow it.
+------+ +------+
|CLIENT| |SERVER|
+------+ +------+
| |
| HELLO | :: Hi. I'm an Nping Client.
|------------------>>| I support version 1.
| |
| |
| HELLO RESPONSE |
|<<------------------| :: Nice 2 meet u. Im a server..
| | I also support version 1
| |
| CLIENT_CHAL_RESP | :: Here's the response to your.
|------------------>>| challenge.
| |
| |
| SERVER_CHAL_RESP |
|<<------------------| :: Your challenge response was OK,
| | here it's mine.
| |
| SPECS |
|------------------>>| :: Use this BPF filter (tcp and udp)
| |
| |
| |
| QUIT |
|<<-- ---------------| :: Sorry, no custom BPF allowed.
The following diagrams represents a session where the client fails to
provide a valid challenge response.
+------+ +------+
|CLIENT| |SERVER|
+------+ +------+
| |
| HELLO | :: Hi. I'm an Nping Client.
|------------------>>| I support version 1.
| |
| |
| HELLO RESPONSE |
|<<------------------| :: Nice 2 meet u. Im a server..
| | I also support version 1
| |
| CLIENT_CHAL_RESP | :: Here's the response to your.
|------------------>>| challenge.
| |
| |
| QUIT |
|<<------------------| :: Sorry, mate. Access denied.
| |
The following diagrams represents a session where the server fails to
provide a valid challenge response.
+------+ +------+
|CLIENT| |SERVER|
+------+ +------+
| |
| HELLO | :: Hi. I'm an Nping Client.
|------------------>>| I support version 1.
| |
| |
| HELLO RESPONSE |
|<<------------------| :: Nice 2 meet u. Im a server..
| | I also support version 1
| |
| CLIENT_CHAL_RESP | :: Here's the response to your.
|------------------>>| challenge.
| |
| |
| SERVER_CHAL_RESP |
|<<------------------| :: Your challenge response was OK,
| | here it's mine.
| |
| QUIT |
|------------------>>| :: Sorry, mate. I don't trust you as
| | a server.
| |
2.13 Security
The Nping Echo functionality involves direct access to network traffic
on the server side and that can easily involve information leakage
problems if no security measures are taken.
Unless Nping is compiled without OpenSSL support, all Nping Echo
Protocol (NEP) packets are transmitted encrypted. Rijndael/AES standard
is used. It has a block size of 128 bits, that's why all NEP packets
must have a lenght that is multiple of 16 bytes.
Every NEP packet includes a SHA-256 checksum. SHA-256 has been chosen
over MD5 or SHA1, just to be safe in the future. MD5 is already broken
and some studies show important advances in SHA1 attacks.
As described above, client authentication
[...]
Security aspects are not yet defined properly. Any comments and
suggestions are welcome.
3. GLOSSARY
4. REFERENCES
[1]
[2]
[3]
[4]
_______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://SecLists.Org
Current thread:
- Request for Comments: Nping Echo Protocol Luis M. (Jul 22)
- Re: Request for Comments: Nping Echo Protocol DePriest, Jason R. (Jul 22)
- Re: Request for Comments: Nping Echo Protocol Luis M. (Jul 22)
- Re: Request for Comments: Nping Echo Protocol David Fifield (Jul 22)
- Re: Request for Comments: Nping Echo Protocol Luis M. (Jul 23)
- Re: Request for Comments: Nping Echo Protocol David Fifield (Jul 23)
- Re: Request for Comments: Nping Echo Protocol Luis M. (Jul 23)
- Re: Request for Comments: Nping Echo Protocol Brandon Enright (Jul 22)
- Re: Request for Comments: Nping Echo Protocol Luis M. (Jul 23)
- Re: Request for Comments: Nping Echo Protocol Brandon Enright (Jul 23)
- Re: Request for Comments: Nping Echo Protocol Luis M. (Jul 23)
- Re: Request for Comments: Nping Echo Protocol Brandon Enright (Jul 26)
- Re: Request for Comments: Nping Echo Protocol Luis M. (Jul 27)
- Re: Request for Comments: Nping Echo Protocol Brandon Enright (Jul 27)
- Re: Request for Comments: Nping Echo Protocol Luis M. (Jul 27)
- Re: Request for Comments: Nping Echo Protocol DePriest, Jason R. (Jul 22)