Subject: [SAFE] nat-control-stun-usage-04

From: "Dan Wing" <[email-masked]>
Date: Wed, 10 Oct 2007 12:32:37 -0700

We just submitted a new version of STUN Control,
http://www.ietf.org/internet-drafts/draft-wing-behave-nat-control-stun-usage-0
4.txt

The changes were mostly organizational and editorial, and included:

   o  Clarified that all existing bindings, for that source IP address
      and UDP port, are controlled with STUN Control.

   o  Introduction now concentrates on the primary purpose of STUN
      Control, namely reducing keepalive traffic for SIP-Outbound.

There is also an appendix which describes Linux implementation specifics.

Diffs are at:
  http://www.tinyurl.com/2bak33

Comments welcome,
-d

_______________________________________________
SAFE mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/safe

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Thu, 11 Oct 2007 13:57:44 +0300

Le Wednesday 10 October 2007 22:32:37 ext Dan Wing, vous avez écrit :
> http://www.ietf.org/internet-drafts/draft-wing-behave-nat-control-stun-usag
>e-0 4.txt
>

As far as I understand, STUN in general, and STUN in particular, can be used 
for any UDP-based always-on protocol. ESP-in-UDP, TEREDO, perhaps some long 
usages of RTP (such as MIDI-over-RTP(?) or RTSP-based streaming), proprietary 
UDP overlays (not giving any names)...

And then, there is the relation to ICE in finding "intermediary" NAT mappings 
in nested NATs scenarios.

At the same time, I thought SIP Outbound was going to recommend TCP, so that 
it could end up being a less likely "customer" of STUN control??

-- 
Rémi Denis-Courmont

---

From: <[email-masked]>
Date: Thu, 11 Oct 2007 16:27:35 +0300

Hi,

Rémi Denis-Courmont [mailto:[email-masked]] wrote:
>As far as I understand, STUN in general, and STUN in 
>particular, can be used for any UDP-based always-on protocol. 
>ESP-in-UDP, TEREDO, perhaps some long usages of RTP (such as 
>MIDI-over-RTP(?) or RTSP-based streaming), proprietary UDP 
>overlays (not giving any names)...
>
>And then, there is the relation to ICE in finding 
>"intermediary" NAT mappings in nested NATs scenarios.
>
>At the same time, I thought SIP Outbound was going to 
>recommend TCP, so that it could end up being a less likely 
>"customer" of STUN control??
>

I agree with Rémi. For protocols like SIP it would be much better to switch to TCP than to build NAT control solutions for UDP. (For instance XMPP uses only TCP and it is proven to scale well.) But there are protocols like those listed above where UDP probably is the only option, and for them controlling UDP NAT bindings makes sense.

Markus

---

From: Philip Matthews <[email-masked]>
Date: Thu, 11 Oct 2007 10:38:19 -0400

> in nested NATs scenarios.

This remains a big interest of mine, though increasing the lifetime  
of UDP mapping and filtering entries is also a big win. I am not sure  
why the focus is SIP-Outbound as opposed to other UDP uses.

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 11 Oct 2007 09:48:15 -0700

> MIDI-over-RTP(?) or RTSP-based streaming), proprietary 

You're right.

I will expand the draft to describe how STUN Control could reduce
keepalive traffic for those protocols.

> recommend TCP, so that 

Unfortunately, most SIP signaling remains UDP no matter the statements or
warnings in IETF specifications.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 12 Oct 2007 11:08:37 -0700

> ESP-in-UDP, TEREDO, perhaps some long usages of RTP (such 
> as MIDI-over-RTP(?) or RTSP-based streaming), proprietary 

I looked at how IKE learns of an on-path NAT, and unfortunately
the IP addresses are hashed in the IKE exchange.  This prevents
the IKE endpoint from learning the IP address seen by its IKE
peer, and thus prevents the IKE endpoint from learning its own
public IP address.  To use STUN Control, you need to learn that
public IP address.  I see two approaches:

* It is possible to multiplex STUN, IKE, and IPsec ESP on the
same UDP port.  IKE-over-UDP starts with 4 bytes of zeros,
IPsec ESP starts with the 32-bit SPI, and STUN has known bits
in its header (first 16 bits indicate a STUN Request, Response,
or Indication, and has a fixed magic cookie in bits 32-64) and
the STUN SHA-1 fingerprint attribute.  While not ideal, it
would be possible for the IKE peers to demultiplex STUN on
that same UDP port so that they could learn the IP address
as seen by the other peer and use STUN Control to adjust their
timings.  

* Alternatively, the IKE peer (VPN concentrator) could
run a normal STUN server on the STUN port (UDP/3478) if we make
the (reasonable) assumption that the same NATs would be be
traversed for traffic to UDP/500, UDP/4500, and UDP/3478.  This
wouldn't require changes to VPN concentrator code.

I would lean towards the second approach.

-d