[SAFE] RE: [tsv-area] BOF request under consideration: SAFE

[[e-mail]]

Magnus,

IKE and IKEv2 NAT Traversal for IPsec (also widely deployed, e.g.,
I believe my VPN client is using it to send this message ;-) ...)
are not on the list of related technologies.  This might be an
omission, but I suspect that the (assumed) problem definition
for SAFE may exclude IPsec (e.g., IKE and IKEv2 have a different
security model for which a server like the STUN server may be
problematic).  This should be clarified.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
[phone]             FAX: [phone]
[e-mail]        Mobile: [phone]
----------------------------------------------------

> -----Original Message-----
> From: Magnus Westerlund [mailto:[e-mail]] 
> Sent: Monday, October 08, 2007 11:09 AM
> To: TSV Area; Behave WG; mmusic (E-mail)
> Subject: [tsv-area] 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-control-stun-u
sage-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]
> ----------------------------------------------------------------------
> 
> 
> 
> 


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