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)