Subject: [BEHAVE] STUN and RFC3948

From: Miika Komu <[email-masked]>
Date: Fri, 29 Feb 2008 13:55:03 +0200 (EET)

Folks,

we have been discussing about STUN and RFC3948 compatibility with the NAT 
traversal design team for HIP. The design team has planned to use STUN/ICE 
for connectivity tests and keepalives for HIP. However, we found out an 
incompatibility with STUN and UDP encapsulation of IPsec ESP [RFC3948] 
(HIP uses ESP).

The problem is that section 2.2. in RFC3948 assumes 32-bits of zeroes 
after the UDP header. We would have HIP, STUN and ESP messages arriving at 
the same UDP port number and being demuxed using the 32-bits after the UDP 
header based on the following:

         * HIP (or IKE): zero bytes [RFC3948]
         * ESP: non-zero bytes [RFC3948]
         * STUN: 0x00 + length + type [RFC3489bis-14]
         (* IPsec keepalive: 0xFF [RFC3948])

There is conflict between demuxing ESP and STUN in the current standards. 
I wonder if it would still be possible to add 32-bits of zeroes in the 
beginning of STUN header to make it compatible with RFC3948? I would image 
that this could make STUN more attractive solution also to some other 
protocols such as IKE.

We could also bend ESP towards this direction, but unfortunately it 
appears to imply some negative tradeoffs related to security, performance 
and deployment.

-- 
Miika Komu                                       http://www.iki.fi/miika/
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Fri, 29 Feb 2008 14:20:48 +0200

Le Friday 29 February 2008 13:55:03 ext Miika Komu, vous avez écrit :
> for connectivity tests and keepalives for HIP.

Makes sense.

> However, we found out an 

This does not affect the validity of your point, but STUN does not start with 
a zero byte, it starts with two zero bits.

> that this could make STUN more attractive solution also to some other

As long as the first two bits remain zeroes, we can demux STUN from RTP, which 
is what SIP and XMPP need. In that sense, this would be do-able. And it would 
allow using ICE cleanly with ESP-in-UDP - not only HIP.

However, this would totally break backward compatibility with RFC3489. This is 
not a problem for ICE, but is a problem for STUN binding discovery (which ICE 
relies upon anyway) with RFC3489 STUN servers - i.e. those currently deployed 
STUN servers. That had probably better be avoided.

> appears to imply some negative tradeoffs related to security, performance

You mean, like adding restrictions on the SPI field? I don't know IPsec well 
enough to realistically comment on this.

Did you consider the use of the STUN FINGERPRINT attribute? I am not sure if 
it would have serious security implications.

-- 
Rémi Denis-Courmont

---

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

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

> 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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 29 Feb 2008 16:58:03 -0500

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.

-- 
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
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave