Subject: Re: [Hipsec] Demultiplexing STUN from ESP

From: Pekka Nikander <[email-masked]>
Date: Mon, 3 Mar 2008 10:54:42 +0200

Personally, I would prefer the latter alternative of requiring the  
SPI selection algorithm to make sure that at least one of the 0, 1,  
30, and 31 bits is one.  The SPI selection algorithm already now has  
some complexity in it, that is, making sure that none of the reserved  
SPIs (0, 1-255) are chosen.

--Pekka

On 29 Feb 2008, at 15:20, Philip Matthews wrote:

> 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
>

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