BoF request: STUN Control Usage

As individual contributor:

I would like to summarize my reasons for calling this BoF,
and the
value I see STUN Control can bring.  Hopefully this summary
will tease
out futher objections or further agreement for this BoF and
discussion
of draft-wing-behave-nat-control-stun-usage itself.

 1. ICE works.  This has been well demonstrated by its
successful
    deployment on the Internet by millions of endpoints.  It
works
    without explicit support by subscriber's NATs or ISP's
NATs.

 2. A drawback of ICE (and STUN) is the chattiness of
keepalive
    messages (primarily with SIP servers
[draft-ietf-sip-outbound]) 
    and the chattiness of binding discovery messages for
each 
    call (primarily due to ICE).

STUN Control adds an optimization to STUN's existing areas
of
applicability by allowing an end host to negotiate and
extend NAT
binding lifetimes.  This improves the performance of ICE and

sip-outbound and any other protocols making use of STUN.

In our draft, we don't compare STUN Control to other
protocols, so
here are some points:

* STUN Control is inherently limited in the scope of control
it
provides.  It only allows for extension of binding
lifetimes, and only
allows such extensions for the binding associated with the
source
IP/port the STUN Control request is coming from.  Because of
its
fundamentally limited scope of control, the NAT can operate
with a
trivial authorization policy - a control message coming on
its
internal interface is always authorized to manage the
binding lifetime
for the private address and port the message comes from. 
This is, in
fact, exactly the same authorization policies used by NATs
today to
authorize the creation and termination of bindings.  STUN
Control
merely extends that authorization to make the termination
more 
controlled.  The trivial scope of control and authorization
policy 
means that authentication, credentials, shared secrets, and
so on, 
are not required.  The need for such security measures in
other, 
richer control protocols makes them hard to deploy.  STUN
Control 
is meant to be trivially deployable to solve a small but
important 
problem.

* STUN Control works with nested NATs; UPnP does not.

* STUN Control is incrementally deployable.  Other
mechanisms are not
(they require modifying end hosts and NATs, or else they
fail or
they fall back to other mechanisms).  STUN Control is an
optimization to ICE and sip-outbound.  If a host or a NAT
doesn't
support STUN Control, ICE and sip-outbound continue to work
--
albeit with more frequent keepalive messages and binding
discovery
messages sent to the STUN server (which is what they do
today 
without STUN Control).

Please send comments to behaveietf.org.

-d

-----

(Below is my original BoF proposal.  Chairs are still TBD. 
Since
my original request, it has been suggested that one hour
isn't 
sufficient, as we need to discuss deployment barriers to
existing 
techniques, and optimizations that would be useful for
sip-outbound 
and ICE).

Description:
ICE and its companion protocol STUN are emerging as a
popular
mechanism to traverse NATs without requiring deployment of
new
software in existing NATs.  ICE has been specified for SIP,
extended
to Jabber/XMPP, and will work with RTSP.  ICE is
incrementally
deployable, providing operation over any sort of NAT and any
sort of
firewall, without requiring upgrades to those NATs and
firewalls.

A successful Firewall or NAT control protocols needs to also
be
incrementally deployable so that applications can request
enhanced
services from firewalls and from NATs to permit certain
flows towards
a host and to the host's applications.  Incremental
deployment allows
hosts to deploy the protocol without requiring NATs or
firewalls in
front of the host to be upgraded to enjoy basic operation,
but after
upgrading to enjoy enhanced operation.

Draft-wing-behave-nat-control-stun-usage describes how STUN
could be
used to communicate with both NATs and firewalls to enhance
the
operation of those NATs and firewalls to allow certain flows
or treat
them differently.

This BoF is intended to discuss one proposed technique,
draft-wing-behave-nat-control-stun-usage as an
incrementally-deployable
NAT control mechanism and firewall control mechanism, and to
determine
if there is sufficient community interest to move this work
forward
in the IETF.

Agenda:
  Agenda bash ............................................. 
5
  Summary of existing NAT traversal techniques ............
20
   (UPnP, NAT-PMP/Bonjour, MIDCOM techniques, NSIS GIST,
ICE)
  STUN Control ............................................
30

---------
                                                     total:
55

_______________________________________________
Behave mailing list
Behaveietf.org
https:/
/www1.ietf.org/mailman/listinfo/behave

BoF request: STUN Control Usage

Thread: BoF request: STUN Control Usage