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

["Dan Wing" <[e-mail]>]

Hi, David.  

I am aware of IPsec-over-UDP (RFC3947, RFC3948), but I'm not sure 
how it applies in a comparison of MIDCOM, UPnP, NSIS-NSLP, 
NAT-PMP, and STUN/ICE.

-d


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] 
> Sent: Monday, October 08, 2007 9:52 AM
> To: [e-mail]; [e-mail]; [e-mail]
> Cc: [e-mail]
> Subject: RE: [tsv-area] BOF request under consideration: SAFE
> 
> 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-cont
> rol-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