Subject: [Hipsec] Demultiplexing STUN from ESP

From: Philip Matthews <[email-masked]>
Date: Fri, 29 Feb 2008 08:20:35 -0500

Folks:

A few of us on the NAT Traversal for HIP design team have been  
discussing how to demux a STUN connectivity check packet from an ESP  
packet containing application data. Due to the way NATs work, the  
STUN connectivity check packets have to be sent using the same  
addresses and ports as the ESP packets. Thus a way to distinguish  
these two kinds of packets at the receiver is needed.

The current mechanism is described in section 5.2 of draft-ietf-hip- 
nat-traversal-03 and draft-ietf-behave-rfc3489bis. Under the current  
proposal, an incoming packet is a STUN packet if it has _all three_  
of the properties listed in the STUN specification:
1) Bits 0, 1, 30, and 31 of the first 32-bit longword are zero;
2) The second 32-bit longword contains the so-called "magic cookie"  
value of 0x2112A442; AND
3) The STUN message contains a Fingerprint TLV with the correct value.
The first two tests are clearly quick and easy to do, but the third  
test requires more work because the packet must be parsed to locate  
the Fingerprint TLV and then the value of the TLV must be checked.

The design team has been discussing whether we might move to a  
simpler test. In this simpler test, HIP endpoints would be required  
to select SPI values in the range 0x80000000 to 0xFFFFFFFF. This  
would ensure that the first bit of the ESP header is a 1. Since a  
STUN packet must have a 0 in this position, a simple test would be  
sufficient to demultiplex the two packet types.

The only drawback that we can see from this simpler test is that the  
effective range of an SPI is cut in half. It is not clear to us  
whether this range reduction is important from a security standpoint  
or not.

We would like to get the WG's feedback on this proposed simpler test.  
Is this the reduction in the SPI range acceptable?

Comments?

- Philip

PS. An alternative, slightly more complex test is to ensure that the  
SPI chosen sets at least one of bits 0,1,30,31 to one, since a STUN  
packet sets all four of these bits to zero. This alternative test  
allows the new SPI range to be 94% of the current range, at the cost  
of a more complex algorithm for choosing an SPI (to keep it random).

_______________________________________________
Hipsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/hipsec