Subject: Re: [BEHAVE] [hip-nat-traversal] STUN and RFC3948

From: Miika Komu <[email-masked]>
Date: Sat, 1 Mar 2008 11:41:48 +0200 (EET)

On Fri, 29 Feb 2008, Jonathan Rosenberg wrote:

Hi,

The relationship with e.g. STUN and RTP is similar what we have already 
with HIP/IKE and UDP-ESP. Both STUN and ESP provide their own demuxing 
methods for UDP, but now new problems arise when we want to combine them. 
Therefore, I would actually claim that the fingerprint is not adequate 
means of solving this problem (which is a problem of having two demuxers 
in the same port).

The use of the fingerprint does not remove the time/complexity issues with 
UDP-ESP in RFC3948. In fact, it will either impose some additional 
performance penalties on input packet processing or halve the Security 
Parameter Index (SPI) namespace. The latter tradeoff probably needs some 
input from security area.

I would ask the behave WG to reconsider adding the 32-zero bits or 
documenting this limitation explicitly to the STUN specification.

Btw, the most recent HIP NAT traversal draft is here in case you have 
missed it:

http://www.ietf.org/internet-drafts/draft-ietf-hip-nat-traversal-03.txt

> Right - my answer was going to be, "thats why there is the FINGERPRINT".
>  Clearly we cannot modify the stun header every time we want to demux
> with a new protocol; thats why FINGERPRINT was added.
>
> -Jonathan R.
>
> Philip Matthews wrote:
>> On Fri, 29-Feb-08, at 07:20 , Rémi Denis-Courmont wrote:
>>>> We could also bend ESP towards this direction, but unfortunately it
>>>> appears to imply some negative tradeoffs related to security,
>>>> performance
>>>> and deployment.
>>> You mean, like adding restrictions on the SPI field? I don't know
>>> IPsec well
>>> enough to realistically comment on this.
>>
>> Yes. As long as the SPI field does not look like 00........00, the
>> demux is simple. However, I am not enough of a security expert to
>> know what affect putting this restriction on the SPI field might have
>> on ESP security.
>>
>>> Did you consider the use of the STUN FINGERPRINT attribute? I am
>>> not sure if
>>> it would have serious security implications.
>>
>> Yes. Without a restriction in the SPI range, it seems that the only
>> way to demux is to do the full suite of STUN demux tests:
>> * First longword looks like 00...........00
>> * Second longword contains the magic cookie value.
>> * STUN packet contains a FINGERPRINT attribute.
>> Packets passing all three tests are STUN, others are ESP.
>>
>> It is certainly possible to do this. There was just some grumblings
>> about the time/complexity of implementing the third test, especially
>> since some OSes process ESP packets in the kernel.
>>
>> - Philip
>>
>>
>> _______________________________________________
>> Behave mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/behave
>>
>
> -- 
> Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
> Cisco Fellow                                   Edison, NJ 08837
> Cisco, Voice Technology Group
> [email-masked]
> http://www.jdrosen.net                         PHONE: (408) 902-3084
> http://www.cisco.com
> _______________________________________________
> hip-nat-traversal mailing list
> [email-masked]
> https://users.piuha.net/mailman/listinfo.cgi/hip-nat-traversal
>

-- 
Miika Komu                                       http://www.iki.fi/miika/

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

---

From: <[email-masked]>
Date: Mon, 3 Mar 2008 13:15:04 +0200

Philip Matthews wrote:

> Without a restriction in the SPI range, it seems that the only  

BTW, if an implementation did only the first two tests, it would
work just fine in practise. If you rekey before sending 500 million
packets, the ESP sequence number (the second longword) won't match
the magic cookie -- and if you rekey less often, you would experience
1-in-500 million additional packet loss (which might be acceptable
for an implementation that cares about implementation complexity).

Best regards,
Pasi