[SAFE] RE: [BEHAVE] BOF request under consideration: SAFE

[<[e-mail]>]

Hi,

I support the goals of this BOF and I believe in the reasoning provided
by the charter. I have two concerns that should be addressed before I
think STUN NAT control could become successfully deployed:

1. Technical issue: STUN control allows a host/application to discover
NATs and disover/set NAT binding timers for UDP (typically to higher
values than what the defaults, perhaps around 30-300 s, would be).
However, BEFORE the application can start using the increased keepalive
period, it needs to have a some sort of assurance that there aren't
OTHER middleboxes on its path with lower keepalive values. Otherwise it
would be impossible to rely on the increased timer values, and thus the
whole mechanism might fail in practice. So, I would like to include in
the charter a goal where such discovery mechanisms and their
applicability are considered. The actual mechanism might be based on
STUN or something else. I know this is a hard problem in general, but in
many access network topologies the problem can be solved by
configuration + discovery. I'd be happy to contribute in this area.
Actually I believe this discovery part to be the real issue with this
whole work, rather than the details of STUN itself. 

2. Deployment issue: We do have several protocols in this area, for
instance NSIS. Their deployment does not look to be happening. For STUN
control to be useful, we would need real interest from some real NAT/FW
vendors. It's of course difficult to say how to verify this in a BOF
beyond matching people's e-mail addresses to NAT/FW product brands :-)
Personally I can speak for a single client/host/device vendor only.

Markus    
 

>-----Original Message-----
>From: ext Magnus Westerlund [mailto:[e-mail]] 
>Sent: 08 October, 2007 18:09
>To: TSV Area; Behave WG; mmusic (E-mail)
>Subject: [BEHAVE] BOF request under consideration: SAFE
>
>Hi,
>
>We ADs have received a request for a BOF in Vancouver: SAFE - 
>Self-Address Fixing Evolution. See description below. I would 
>appreciate any feedback on this. For public discussion please 
>use the SAFE mailing list.
>
>Post: [e-mail]
>Subscribe: https://www1.ietf.org/mailman/listinfo/safe
>
>Draft:
>http://www.ietf.org/internet-drafts/draft-wing-behave-nat-contr
ol-stun-usage-03.txt
>
>
>SAFE - Self-Address Fixing Evolution
>------------------------------------
>
>Chairs:
>  TBD
>
>
>ICE and its companion protocol STUN have been successfully 
>deployed on the Internet for NAT traversal.  ICE and STUN have 
>several characteristics which contribute to their success:
>
>  1. incremental deployment.  ICE and STUN are functional without any
>     modifications to existing NATs.
>  2. nested NATs.  ICE and STUN work when there are multiple NATs
>     between a host and the Internet.
>  3. topology unaware.  ICE and STUN are not configured with
>     information about NATs, firewalls, or their locations -- only
>     with the IP address of a server on the Internet.
>  4. simple security model.  If a host behind a NAT is allowed to send
>     a packet across the NAT, it is allowed to receive a response.
>  5. works on routed networks, which allows operation in both
>     enterprise networks and home networks.
>
>Other NAT traversal protocols do not share these 
>characteristics, which hinders their widespread deployment.  
>Specifically,
>
>  * incremental deployment is not possible with MIDCOM, NSIS-NSLP,
>    UPnP, or Bonjour.  With all of these protocols, both the NAT
>    and the endpoint have to support the same protocol.
>  * nested NATs are not possible with UPnP or Bonjour.
>  * topology awareness is required of MIDCOM.
>  * security must be established between the controlling entity
>    and the NAT for MIDCOM and NSIS-NSLP.
>  * Both UPnP and Bonjour use broadcast packets which don't work
>    well on routed networks.
>
>However, a drawback of ICE/STUN is its chatty keepalive 
>traffic, which is a result of STUN not knowing the binding 
>lifetime of its on-path NATs.  This chattiness causes a burden 
>on servers and consumes network bandwidth, which is especially 
>critical on wireless networks.  It is desirable to reduce this 
>chattiness while still retaining the important characteristics 
>of STUN and ICE.
>
>This BoF is intended to discuss one proposed technique, 
>draft-wing-behave-nat-control-stun-usage, which nearly 
>eliminates STUN's keepalive chatter and still preserves the 
>desirable characteristics of STUN/ICE.
>
>The purpose of this BoF is to create a working group for this effort.
>
>
>Agenda:
>  Introduction, Agenda ....................................  5
>  Summary of existing NAT traversal techniques ............ 40
>   (UPnP, NAT-PMP/Bonjour, MIDCOM techniques, NSIS-NSLP, ICE)
>  draft-wing-behave-nat-control-stun-usage ................ 40
>  Q&A ..................................................... 25
>                                                    ----------
>                                                    total: 110
>
>Cheers
>
>Magnus Westerlund
>
>IETF Transport Area Director & TSVWG Chair
>----------------------------------------------------------------------
>Multimedia Technologies, Ericsson Research EAB/TVM/M
>----------------------------------------------------------------------
>Ericsson AB                | Phone [phone]
>Torshamsgatan 23           | Fax   [phone]
>S-164 80 Stockholm, Sweden | mailto: [e-mail]
>----------------------------------------------------------------------
>
>
>_______________________________________________
>Behave mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/behave
>


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