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

[[e-mail]]

Dan,

Section 2.23 of RFC 4306 is also part of this technology.

I'm also not sure how any of this applies to the BoF.  The
BoF proposal should probably contain a few sentences to
say that IPsec NAT Traversal is a different problem,
including a brief explanation of why it's different, and
state that therefore it's outside the scope of the BoF.

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: Dan Wing [mailto:[e-mail]] 
> Sent: Tuesday, October 09, 2007 3:43 PM
> To: Black, David
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: RE: [tsv-area] BOF request under consideration: SAFE
> 
> 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