[VOIPSEC] Put STUN in NAT Boxes?

[Dan Wing]

Simon Horne wrote:
> Dan (Wing)
> 
> I noticed that you submitted a proposal to add STUN to NAT devices
> http://www.ietf.org/internet-drafts/draft-wing-behave-nat-control-stun-usage-02.txt

Yes.  I had asked for a BoF at the upcoming IETF meeting, but it was 
denied.  Discussion of that document is on the SAFE mailing list,
https://www1.ietf.org/mailman/listinfo/safe.  I will ask for a BoF
at this fall's IETF (Vancouver).

Related, you might read
http://tools.ietf.org/html/draft-eggert-middlebox-control-survey-00
although it is incomplete.

> and looking at sect 14.4 of the STUN working document
> http://tools.ietf.org/html/draft-ietf-behave-rfc3489bis-06#section-14.4
> 
> Your long term solution to NAT traversal is to control the NAT boxes? Are
> you giving up on the initial idea of ICE which was to work with existing 
> NATs and instead taking the UPnP and MIDCOM type approach and putting some 
> form of control into the NAT boxes and attempt to control/instruct them?

I don't know if you bumped into my discussion of STUN Control, but in
case you haven't, it's at:
http://www1.ietf.org/mail-archive/web/behave/current/msg02392.html

In that post, I describe some of the motivations for STUN Control.

In summary -- no, this isn't "giving up".  Rather, STUN Control
allows optimizing STUN when your own NAT(s) support STUN Control.
The most useful optimizations to STUN are (a) reducing keepalives
(which isn't a characteristic of STUN, but rather of any sort of
UDP hole-punching technique; STUN is one such technique), and (b) 
getting per-call bindings without involving the STUN server
on the Internet.

-d