Nmap Development mailing list archives
Request for Comments: Nping Echo Protocol
From: "Luis M." <luis.mgarc () gmail com>
Date: Wed, 22 Jul 2009 14:18:28 +0200
Hi! As you may already know, apart from the usual hping-like functionality, Nping will have a special client/server mode that allows users to see what the packets they send look like when they reach their destination. The document attached introduces this Nping functionality and it is a Request For Comments for the protocol that has been designed for this purpose. If you are already familiar with the new mode, feel free to skip the long Introduction section. Implementation of this functionality will start in less than a week so now it's the best time to make comments and give your opinion. It would be specially useful if those of you who are into cryptography and security had a look at section "2.11 Security" and make comments on the choices that have been made. As a boring priest would say: "If anyone objects to the current definition of this protocol, speak now or forever hold your peace". Best regards, Luis M.
+-----------------------------------------------------------------------------+
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 SPECS ............................................... x
2.7 Operation READY ............................................... x
2.8 Operation ECHOPKT ............................................. x
2.9 Operation QUIT ................................................ x
2.10 Flow Diagram .................................................. x
2.11 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 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
0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. . .
. . SHA256 Checksum .
. . .
| |
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
0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | OP Code 0x02 | 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. . .
. . SHA256 Checksum .
. . .
| |
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 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.7 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.8 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.9 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.10 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
| |
| 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
| |
| SPECS |
|------------------>>| :: Use this BPF filter (tcp and udp)
| |
| |
| |
| QUIT |
|<<-- ---------------| :: Sorry, no custom BPF allowed.
2.11 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 is performed using the
checksum field. The server assumes only a client in possesion of the
correct encryption key is capable of producing packets that, when
decrypted, contain valid SHA-256 checksum. However, replay attacks
may be possible in this scheme. A small 32bit Sequence field is
included in every packet. In theory, the server could have a list
of sequence numbers that have already been used and deny connection
to clients that use replayed packets. However, a 32 bit space may not
be sufficiently large to provide security, and exhaustion of sequence
numbers may result in a denial of service for authorized clients.
If we set the "Reserved" field (56 bits) in the initial HELLO packet
to some random value, and we instruct the server to keep a list of
both, sequence numbers and checksums, then it is possible that the
tuple (seq, checksum) provides enough security while significantly
reducing the possibility of client denial of service. We can even use
(seq, rand, checksum) where "rand" is the random data included in
the reserved space.
The problem with replay attacks is not tremendously important because,
at the end of the day, an attacker that does not have the encryption
key and therefore cannot see the contents of the ECHOPKT packets.
However, if the attacker replays old packets to establish a new
connection, the server will send him some data whenever he captures
a packet, and the fact the it has actually captured a packet can give
the attacker enough information to tell if the server is behind a
firewall, etc.
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)
(Thread continues...)
- Re: Request for Comments: Nping Echo Protocol DePriest, Jason R. (Jul 22)