Subject: [BEHAVE] NAT Control STUN Usage

From: "Dan Wing" <[email-masked]>
Date: Fri, 12 Jan 2007 10:09:49 -0800

(as individual contributor:)

In San Diego, Jonathan presented our
draft-wing-behave-nat-control-stun-usage document,
<http://www3.ietf.org/proceedings/06nov/slides/behave-5/sld1.htm>, 
<http://tools.ietf.org/html/draft-wing-behave-nat-control-stun-usage-00>:
   Simple Traversal Underneath NAT (STUN) is a mechanism for traversing
   NATs.  STUN requests are transmitted through a NAT to external STUN
   servers.  While this works very well, its two primary drawbacks are
   the inability to modify the properties of a NAT binding and the need
   to query a public STUN server for every NAT binding.  These drawbacks
   require frequent messages which present a load on servers (like SIP
   servers and STUN servers) and are bad for low speed access networks,
   such as cellular.  This document proposes that the STUN server be
   embedded in the NAT itself, and describes how these STUN servers can
   be readily discovered and utilized to reduce queries to public STUN
   servers and to reduce NAT keepalive traffic.

As Jonathan indicated at the meeting, Cisco claims IPR on this technique.
Terms are here:
http://www.ietf.org/ietf/IPR/cisco-ipr-draft-wing-behave-nat-control-stun-us
age-00.txt

At the San Diego meeting there were positive comments around this approach.

Is there interest in moving this work forward?

-d

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

---

From: Christian Huitema <[email-masked]>
Date: Fri, 12 Jan 2007 21:37:23 -0800

> Is there interest in moving this work forward?

If you want to get mapping control between the client and the NAT, why
not just use UPNP? The protocol has been used since 2001, there are many
implementations...

-- Christian Huitema

---

From: "Dan Wing" <[email-masked]>
Date: Sun, 14 Jan 2007 18:29:07 -0800

> If you want to get mapping control between the client and the NAT, 
> why not just use UPNP? The protocol has been used since 2001, 
> there are many implementations...

* UPnP Doesn't work with nested NATs (a NAT in my apartment (or dorm room)
and another in the basement of my apartment/dorm building; or two NATs at
home),

* UPnP is said to be slow
<http://www.voipsa.org/pipermail/voipsec_voipsa.org/2006-June/001832.html>,

* some NAT vendors don't implement UPnP,

* UPnP doesn't work in a routed network.  Such as an enterprise network.

* To work in the above situations, endpoints need to implement STUN anyway.
Designing an endpoint that only works in UPnP environments restricts the
endpoint to only ever working in the presence of UPnP.

-d

---

From: "Eric Cooper" <[email-masked]>
Date: Mon, 15 Jan 2007 09:57:57 -0500

I'm interested in seeing this move forward.

Eric.

---

From: Philip Matthews <[email-masked]>
Date: Mon, 15 Jan 2007 14:33:17 -0500

I would like to see BEHAVE take on work in this area.
I think that a solution to this problem is of interest.

May I suggest that the work begin by writing a problem statement,
so that we can agree on exactly what we are trying to achieve?
This could be just a section or two at the beginning of the existing
document (i.e., I am NOT suggesting a separate requirements
document).

- Philip