/
githubmirror
/
nmap
Обзор
Документация
Войти
/
githubmirror
/
nmap
Код
Запросы
0
Пакеты
0
Релизы
0
Аналитика
Безопасность
master
nping/docs/EchoProtoRFC.txt
1 158 строк
57 KB
dmiller
Spellcheck: common misspellings in the entire source tree
22 фев 2014, 01:10
22 фев 2014, 01:10
ddcfa8c
Код
Авторство
О чём код?
+-----------------------------------------------------------------------------+ NPING ECHO PROTOCOL PROTOCOL SPECIFICATION Request for Comments August 2010 Luis MartinGarcia (luis.mgarc@gmail.com) +-----------------------------------------------------------------------------+ Status of this document: DRAFT First version: May 29, 2009. Last revision date: April 27, 2011. +-----------------------------------------------------------------------------+ PREFACE This documents presents the technical specification of the Nping Echo Protocol. TABLE OF CONTENTS 1. INTRODUCTION ..................................................... x 2. NPING ECHO PROTOCOL SPECIFICATION................................. x 2.1 General Message Format......................................... x 2.2 Field Description.............................................. x 2.3 Message type codes............................................. x 2.4 Message NEP_HANDSHAKE_SERVER................................... x 2.5 Message NEP_HANDSHAKE_CLIENT................................... x 2.6 Message NEP_HANDSHAKE_FINAL.................................... x 2.7 Operation NEP_PACKET_SPEC...................................... x 2.8 Operation NEP_READY............................................ x 2.9 Operation NEP_ECHO............................................. x 2.10 Operation NEP_ERROR............................................ x 2.11 Flow diagrams.................................................. x 2.12 Security....................................................... x 2.13 Cryptographic key derivation................................... x 2.14 Encryption process............................................. x 2.15 Additional considerations...................................... 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 its 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 nping can't track down the problem alone. One generally has to turn to Wireshark/tcpdump on one station and nping 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 implements a new mode of operation, called "Echo mode", which provides a combination of a packet generator and a remote sniffer. The Echo mode is based on a client/server architecture. Both ends run 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 Message Format The following diagram describes the general format of the NEP messages. 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 | Message Type | Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . DATA . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Message Authentication Code . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ There are 7 different kinds of packets: NEP_HANDSHAKE_SERVER (S->C) Informs the client of the highest version it supports and sends the server's authentication parameters. NEP_HANDSHAKE_CLIENT (C->S) Informs the server of the highest version it supports and sends the initial authentication parameters. NEP_HANDSHAKE_FINAL (S->C) Echoes server nonce back to the server. NEP_PACKET_SPEC: (C->S): Tells the server what kind of packets we are planning to send. NEP_READY: (S->C): Tells the client that the server is ready to start receiving packets. NEP_ECHO: (S->C): Contains the packet that the server receives from the client. NEP_ERROR: (C->S or S->C): Indicates an error and terminates the session. 2.2 Field Description Version: 8 bits Current version of the protocol. This document covers version 0x01. Message type: 8 bits Integer that indicates the type of packet. It must be one of the type codes defined in section 2.3. Total Length: 16 bits Length of the entire packet, measured in 32bit words. Value must be in NETWORK byte order. Sequence Number: 32 bits Packet sequence number, relative to the sender. Initially this field is set to a random value, and then it is incremented by one for each packet that is sent in a given session. The counter must wrap back to zero after it reaches (2^32)-1. This field is intended to provide flow tracking and basic protection against replay attacks. Timestamp: 32 bits Current time of the sender. This time is expressed as the number of seconds elapsed since 00:00, 01/01/1970 UTC (epoch time). Reserved: 32 bits Reserved for future use. Reserved fields have been added for two reasons: 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 Message specific data. Message Authentication Code : 256 bits Code that provides integrity and authentication to the rest of the packet. For this, the HMAC-SHA256 suite must be used. The computation of the code includes the whole plain-text message until the first byte of the Message Authentication Code field. 2.3 Message type codes Message NEP_HANDSHAKE_SERVER: 0x01 Message NEP_HANDSHAKE_CLIENT: 0x02 Message NEP_HANDSHAKE_FINAL: 0x03 Message NEP_PACKET_SPEC: 0x04 Message NEP_READY: 0x05 Message NEP_ECHO: 0x06 Message NEP_ERROR: 0x07 2.4 Message NEP_HANDSHAKE_SERVER The NEP_HANDSHAKE_SERVER message is sent by the server and it requests client's authentication. The packet informs the client of the latest version of the protocol that the server supports and provides the appropriate information for the client authentication process. The NEP_HANDSHAKE_SERVER message establishes the following: - The identity of the server and that the message was generated by that server. - That the message was intended for the client. - The integrity and originality of the message. The format of the NEP_HANDSHAKE_SERVER message is the following: 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 | Message Type | Total Length | 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | 4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 5 +-- --+ | | 6 +-- --+ | | 7 +-- --+ | Server Nonce | 8 +-- --+ | | 9 +-- --+ | | 10 +-- --+ | | 11 +-- --+ | | 12 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 13 + --+ | | 14 +-- Reserved --+ | | 15 +-- --+ | | 16 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . . . Message Authentication Code . . . . | | 24 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Server Nonce: 256 bits Random number. This number must be generated using a cryptographically secure PRNG and must not be reused. This is the data that should be used by the client to construct its cipher block initialization vector. Reserved: 120 bits Reserved for future use. HMAC-SHA256: 256 bits Message authentication code that covers the entire packet, from byte 0 to the last byte of the last reserved field. The code is computed over the plaintext, before the encryption is applied to part of the packet. 2.5 Message NEP_HANDSHAKE_CLIENT The NEP_HANDSHAKE_CLIENT message is sent by the client and it provides the appropriate information for client-side authentication. This type of message is generated only if the previous NEP_HANDSHAKE_CLIENT message contains a valid message authentication code. The NEP_HANDSHAKE_CLIENT message establishes the following: - The identity of the client and that reply message has been generated by the client. - That the message was intended for the server. - The integrity and originaltity of the reply. The format of the NEP_HANDSHAKE_CLIENT message is the following: 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 | Message Type | Total Length | 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | 4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 5 +-- --+ | | 6 +-- --+ | | 7 +-- --+ | Server Nonce | 8 +-- --+ | | 9 +-- --+ | | 10 +-- --+ | | 11 +-- --+ | | 12 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 13 +-- --+ | | 14 +-- --+ | | 15 +-- --+ | Client Nonce | 16 +-- --+ | | 17 +-- --+ | | 18 +-- --+ | | 19 +-- --+ | | 20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ###################### ENCRYPTION STARTS HERE ####################### 20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 21 +-- --+ | | 22 +-- Partner IP address --+ | | 23 +-- --+ | | 24 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Version | | 25 +---------------+ --+ | | 26 +-- Reserved --+ | | 27 +-- --+ | | 28 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ####################### ENCRYPTION ENDS HERE ####################### 28 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . . . Message Authentication Code . . . . | | 36 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Server Nonce: 256 bits Nonce value received from the server in the previous NEP_HANDSHAKE_SERVER message. This allows the server to ensure that the received reply is fresh and was generated as a result of its NEP_HANDSHAKE_SERVER message. Client Nonce: 256 bits Random number. This number must be generated using a cryptographically secure PRNG and must not be reused. This is the data that should be used by the server to construct its cipher block initialization vector. Partner IP address: 128 bits This is the server's IP address as seen by the client. 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. IP version: 8-bits Version of the address in the "Partner IP address" field. It should take one of the following values: 0x04 : for IP version 4. 0x06 : for IP version 6. 2.6 Message NEP_HANDSHAKE_FINAL 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 | Message Type | Total Length | 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | 4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 5 +-- --+ | | 6 +-- --+ | | 7 +-- --+ | Client Nonce | 8 +-- --+ | | 9 +-- --+ | | 10 +-- --+ | | 11 +-- --+ | | 12 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ###################### ENCRYPTION STARTS HERE ####################### 12 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 13 +-- --+ | | 14 +-- Partner IP address --+ | | 15 +-- --+ | | 16 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Version | | 17 +---------------+ --+ | | 18 +-- Reserved --+ | | 19 +-- --+ | | 20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ####################### ENCRYPTION ENDS HERE ######################## 20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . . . Message Authentication Code . . . . | | 28 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Client Nonce: 256 bits Nonce value received from the client in the preceding NEP_HANDSHAKE_CLIENT message. Partner IP address: 128 bits This is the clients's IP address as seen by the server. 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. The inclusion of this information lets the client immediately detect the presence of some intermediate devices that change his source IP (e.g a NAT box). This is a modification of the original X.509 three way authentication protocol, provided, among other things, in order to make the man-in-the-middle attack described in [1] more difficult. IP version: 8 bits Version of the address in the "Partner IP address" field. It should take one of the following values: 0x04 : for IP version 4. 0x06 : for IP version 6. 2.7 Operation NEP_PACKET_SPEC The NEP_PACKET_SPEC message is sent by the client to tell the server what kind of packets it should expect. 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 ###################### ENCRYPTION STARTS HERE ####################### 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Message Type | Total Length | 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | 4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP version | Protocol | Packet Count | 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . | | . . . . . PacketSpec . n . . | | 32 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ####################### ENCRYPTION ENDS HERE ######################## 32 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . . . Message Authentication Code . . . . | | 40 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IP version: 8 bits Specifies which is the expected IP version. It must contain one of the following values: 0x04 (IP version 4) 0x06 (IP version 6) 0xFF (Any version) Protocol: 8 bits. Specifies which kind of packets will be sent to the server. It must contain one of the following values: 0x06 (Protocol TCP) Tells the server to listen to TCP packets coming from the client's IP address. 0x11 (Protocol UDP) Tells the server to listen to UDP packets coming from the client's IP address. 0x01 (Protocol ICMP) Tells the server to listen to ICMP packets coming from the client's IP address. Packet count: 16 bits. Specifies how many packets will be sent. It must be in NETWORK byte order. PacketSpec: 864 bits. Tells the server which header fields should be checked to match a captured packet with the client that sent it. This is necessary as the server supports multiple user sessions at a time, and needs a way to distinguish the packets. The PacketSpec field consists of a list of protocol fields and their expected value. Every item on that list has the following format: {Field Code, Field Value} Where "Field Code" is an 8-bit numeric identifier of the field (see definitions below) and "Field Value" is the expected value, that the server should try to match. The length of "Field Value" depends on the "Field Code" (see table below for details) and, in general, it matches the usual length for that field int its original protocol header. Items on the PacketSpec list are specified sequentially. However, the final length of the list must be 108 bytes, so null bytes must be added after the last item. The following table lists the available field specifiers, their code and the length of their values. ====NAME======== ==CODE== ==LENGTH== +----------------+--------+----------+ | IPv4_TOS | 0xA0 | 8 bits | +----------------+--------+----------+ | IPv4_ID | 0xA1 | 16 bits | +----------------+--------+----------+ | IPv4_FRAGOFF | 0xA2 | 16 bits | +----------------+--------+----------+ | IPv4_PROTO | 0xA3 | 8 bits | +----------------+--------+----------+ +----------------+--------+----------+ | IPv6_TCLASS | 0xB0 | 8 bits | +----------------+--------+----------+ | IPv6_FLOW | 0xB1 | 24 bits | +----------------+--------+----------+ | IPv6_NHDR | 0xB2 | 8 bits | +----------------+--------+----------+ +----------------+--------+----------+ | TCP_SPORT | 0xC0 | 16 bits | +----------------+--------+----------+ | TCP_DPORT | 0xC1 | 16 bits | +----------------+--------+----------+ | TCP_SEQ | 0xC2 | 32 bits | +----------------+--------+----------+ | TCP_ACK | 0xC3 | 32 bits | +----------------+--------+----------+ | TCP_FLAGS | 0xC4 | 8 bits | +----------------+--------+----------+ | TCP_WIN | 0xC5 | 16 bits | +----------------+--------+----------+ | TCP_URP | 0xC6 | 16 bits | +----------------+--------+----------+ +----------------+--------+----------+ | ICMP_TYPE | 0xD0 | 8 bits | +----------------+--------+----------+ | ICMP_CODE | 0xD1 | 8 bits | +----------------+--------+----------+ +----------------+--------+----------+ | UDP_SPORT | 0xE0 | 16 bits | +----------------+--------+----------+ | UDP_DPORT | 0xE1 | 16 bits | +----------------+--------+----------+ | UDP_LEN | 0xE2 | 16 bits | +----------------+--------+----------+ +----------------+--------+----------+ | PAYLOAD_MAGIC | 0xFF | Variable | +----------------+--------+----------+ The PAYLOAD_MAGIC type lets the client specify some magic number included in the packet's payload. This can be used when all other specifiers fail (e.g: in IPv4-to-IPv6 tunnels). The length of its field data is variable and must be specified right after the field code. Note that the length can never be higher than the remaining space in the PacketSpec field. If no other field specifiers are set, "length" can never be higher than 106 bytes. Servers should carefully check the structure of the PacketSpec field and close the session established with the sender if it does not meet the requirements specified in this document. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PAYLOAD_MAGIC | Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ PAYLOAD_MAGIC: 8 bits. Field code. MUST be set to 0xFF. Length: 8 bits. Length of the data in the "Value" field. MUST be greater than zero; MUST NOT be greater than the remaining space in the PacketSpec field and MUST NEVER exceed 106 bytes. Value: variable length. Payload data. Its length must be the one specified in the "Length" field. It may contain any binary value. Comparisons at the server side should be made at the bit level so the encoding should match the one used at the application layer in the packets that are produced and sent by the client. Here is an example of how a typical specifier list looks like: 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4_TOS | 0x00 | IPv4_ID | 0xCA | 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0xFE | IPv4_PROTO | 0x06 | TCP_SPORT | 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x4432 | TCP_DPORT | 0x00 | 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x50 | TCP_FLAGS | 0x08 | TCP_SEQ | 4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x5D33FA6D | 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x00 | 0x00 | 0x00 | 0x00 | 6 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x00 | 0x00 | 0x00 | 0x00 | 27 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ All packet specifications MUST include the IPv4_ID specifier (or IPv6_Flow for IPv6) and at least three other fields specifiers. Additionally, clients MUST NEVER specify the same field specifier more than once in a NEP_PACKET_SPEC message. Clients that send messages that do not meet these requirements MUST be rejected by the server. 2.8 Operation NEP_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 ###################### ENCRYPTION STARTS HERE ####################### 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Message Type | Total Length | 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | 4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ####################### ENCRYPTION ENDS HERE ######################## 4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . . . Message Authentication Code . . . . | | 12 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2.9 Operation NEP_ECHO The NEP_ECHO message is sent by the server and it contains an echoed network 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 ###################### ENCRYPTION STARTS HERE ####################### 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Message Type | Total Length | 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | 4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DLT Type | Packet Length | 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . Packet . . . . . . +-+-+-+-+-+-+-+-+ | | Padding | n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ####################### ENCRYPTION ENDS HERE ######################## n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . . . Message Authentication Code . . . . | | n+8 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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. Servers may use the special value 0x0000 to indicate that no link layer header is included. Packet Length: 16 bits. Specifies the length of the echoed packet measured in bytes. The value stored in this field must be in NETWORK byte order and must never be greater than 9212, as that is the maximum number of bytes that can be echoed per packet. Packet: variable length. This corresponds to the packet being echoed. Servers should store the packet exactly as it was received. No byte order conversions or any other alteration should be performed. The whole NEP_ECHO packet must have a length that is a multiple of 16 bytes, so if (packet_len+4)mod16 is not zero, the packet field must be padded with NULL bytes. As noted before, the maximum length for an echoed packet is 9212 bytes. Any packet that exceeds that length must be truncated. 2.10 Operation NEP_ERROR The NEP_ERROR packet is sent by client or server when an error occurs, and informs the other end that the sender is terminating the NEP session and closing the TCP connection. This message includes an error description string that should explain the reason why the session is being terminated (e.g. authentication failed, invalid message 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 ###################### ENCRYPTION STARTS HERE ####################### 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Message Type | Total Length | 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | 4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . Error Message . . . . . . . | | 24 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ####################### ENCRYPTION ENDS HERE ######################## 24 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . . . Message Authentication Code . . . . | | 32 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Error Message: 640 bits. Contains a NULL-terminated ASCII string that describes the reason why the session is being terminated by the sender. The string MUST contain a NULL character (0x00) at the end of it. The remaining bytes, if any, must also be set to zero. 2.11 Flow diagrams The following diagram shows a typical client/server session: +------+ +------+ |CLIENT| |SERVER| +------+ +------+ | | | NEP_HANDSHAKE_SERVER | |<<---------------------| | | | | | NEP_HANDSHAKE_CLIENT | |--------------------->>| | | | | | NEP_HANDSHAKE_FINAL | |<<---------------------| | | | | | | | NEP_PACKET_SPEC | |--------------------->>| | | | | | | | NEP_READY | |<<---------------------| | | | | | | | | | NEP_ECHO | |<<---------------------| | | | NEP_ECHO | |<<---------------------| | | | NEP_ECHO | |<<---------------------| | . | | . | | . | | NEP_ECHO | |<<---------------------| | | | | | | | TCP Connection Close | |<<------------------->>| The following diagram represents a session where the client sends an invalid PacketSpec message. +------+ +------+ |CLIENT| |SERVER| +------+ +------+ | | | NEP_HANDSHAKE_SERVER | |<<---------------------| | | | | | NEP_HANDSHAKE_CLIENT | |--------------------->>| | | | | | NEP_HANDSHAKE_FINAL | |<<---------------------| | | | | | | | NEP_PACKET_SPEC | |--------------------->>| | | | | | NEP_ERROR | |<<---------------------| | | | TCP Connection Close | |<<------------------->>| The following diagram represents a session where the server fails to provide a valid NEP_HANDSHAKE_SERVER message. +------+ +------+ |CLIENT| |SERVER| +------+ +------+ | | | NEP_HANDSHAKE_SERVER | |<<---------------------| | | | | | TCP Connection Close | |<<------------------->>| The following diagram represents a session where the client fails to provide a valid NEP_HANDSHAKE_CLIENT message. +------+ +------+ |CLIENT| |SERVER| +------+ +------+ | | | NEP_HANDSHAKE_SERVER | |<<---------------------| | | | | | NEP_HANDSHAKE_CLIENT | |--------------------->>| | | | | | TCP Connection Close | |<<------------------->>| 2.12 Security The NEP client/server authentication process is based on the three-way authentication protocol, described in CITT recommendation X.509 [2]. However, it has been slightly modified: - Messages are not signed using public-key cryptography but a symmetric encryption key known by both client and server. This provides the same authentication as the original specification but it does not provide non-repudiation. - Ciphertext is encrypted using the secret key shared by client and server, instead of using the receiver's public key. The cipher suite to be used for data encryption is AES-128. When one of the two participating entities receives a fully encrypted message (any message other than NEP_HANDSHAKE_SERVER, NEP_HANDSHAKE_CLIENT or NEP_HANDSHAKE_FINAL), it performs the following steps: 1. Reads 128 bits and decrypts them. 2. Checks that version equals 0x01 3. Checks that the value in the message type field corresponds to a valid message type code. 4. If message type is not one of NEP_HANDSHAKE_CLIENT or NEP_HANDSHAKE_SERVER, it checks that the received sequence number matches the last received sequence number from the same sender plus one. 5. It checks that the received timestamp is inside a "reasonable" time window (where "reasonable" is left undefined on purpose, as it may vary depending on the nature of the implementation or the host system). 6. Checks the received total length. For messages whose length is fixed, it should check whether the received length matches the expected length of the message. For variable length messages, it should check that the length is at least, higher than or equal to the minimum length for that kind of message. 7. If all tests succeed, then the remaining bits are read (remaining = TotalLength - 128bits) 8. Any remaining ciphertext is decrypted. 9. An alternative message authentication code is computed over the unencrypted data and matched against the received one. If both codes match, then the message is considered valid (its integrity has been verified and its contents are to be trusted), authentic (the creator of the message is someone who knows the secret) and fresh (the message is new and has not been replayed). 2.13 Cryptographic key derivation. Five cryptographic keys are generated for each client session. All of them are derived from a single shared secret (a passphrase), known by client and server. The key derivation process is the following: h=SHA256( "passphrase" + NONCES + KEY_TYPE_ID ) do(1000 times){ h=SHA256(h); } Where 'h' is a 256bit buffer that holds the final key, 'SHA256' is the hash computation function for the SHA-256 algorithm, 'NONCES' is the combination of server's and client's nonce values, exchanged during handshake, and KEY_TYPE_ID is a string that varies depending on the type of key being derived. (See below for its definitions). As mentioned above, a total of 5 symmetric keys are used. Those keys are: NEP_KEY_MAC_S2C : Key used by the server to sign its messages. For this type of key, KEY_TYPE_ID="NEPkeyforMACServer2Client" (unquoted) and NONCES equals the server nonce in the NEP_HANDSHAKE_SERVER message, concatenated with the client nonce in the NEP_HANDSHAKE_CLIENT message (SERVER_NONCE + CLIENT_NONCE). NEP_KEY_MAC_S2C_INITIAL : Key used by the server to sign its NEP_HANDSHAKE_SERVER messages. This is a special case key because it needs to be generated before a client nonce is received (this is the only key that is not influenced by the client's nonce). For this type of key, KEY_TYPE_ID="NEPkeyforMACServer2ClientInitial" (unquoted) and NONCES equals the nonce in the NEP_HANDSHAKE_SERVER message, concatenated with an empty client nonce, in other words, a nonce with all its bits set to zero (SERVER_NONCE + ZEROED_NONCE). NEP_KEY_MAC_C2S : Key used by the client to sign its messages. For this type of key, KEY_TYPE_ID="NEPkeyforMACClient2Server" (unquoted) and NONCES equals the server nonce in the NEP_HANDSHAKE_SERVER message, concatenated with the client nonce in the NEP_HANDSHAKE_CLIENT message (SERVER_NONCE + CLIENT_NONCE). NEP_KEY_CIPHERTEXT_C2S : Key used by the client to encrypt its messages. For this type of key, KEY_TYPE_ID= "NEPkeyforCiphertextClient2Server" (unquoted) and NONCES equals the server nonce in the NEP_HANDSHAKE_SERVER message, concatenated with the client nonce in the NEP_HANDSHAKE_CLIENT message (SERVER_NONCE + CLIENT_NONCE). NEP_KEY_CIPHERTEXT_S2C : Key used by the server to encrypt its messages. For this type of key, KEY_TYPE_ID= "NEPkeyforCiphertextServer2Client" (unquoted) and NONCES equals the server nonce in the NEP_HANDSHAKE_SERVER message, concatenated with the client nonce in the NEP_HANDSHAKE_CLIENT message (SERVER_NONCE + CLIENT_NONCE). When not all 256 bits are required, the last 256-N bits of key material may be discarded, where N is the desired key length. This is, if less than 256 of key material is needed, discarded bits must be the least significant ones. 2.14 Encryption process. Encryption must be performed using AES-128-CBC. This is, using the AES encryption algorithm in CBC mode, with 128-bit keys. For each party producing encrypted data, the first initialization vector should be the nonce that this same party generated during the authentication handshake phase. If the nonce has more bits than needed, only the necessary number of bits should be used. These bits should be the most significant ones. The initialization vector for subsequent encryption operations should be the last ciphertext block produced by the same entitiy. This is, to encrypt the Nth message, the last ciphertext block of the (N-1)th message should be used as the initialization vector for message N. Same rule applies for decryption operations, where the initialization vector should be the last ciphertext block received from the other end. 2.15 Additional considerations. - By default, the server side will listen for incoming connections on TCP port 9929. 3. GLOSSARY C->S : Indicates that a given message is sent from the client to the server S->C : Indicates that a given message is sent from the server to the client NEP : Acronym for Nping Echo Protocol 4. REFERENCES [1] I'Anson, C. and Mitchell, C. (1990). "Security defects in CCITT recommendation X.509: the directory authentication framework". ACM SIGCOMM Computer Communication Review, Volume 20, Issue 2. United States. [2] C.C.I.T.T. (1988). "Recommendation X .509, The Directory - Authentication Framework"