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

[<[e-mail]>]

Hi,

STUN control would be able to reduce keepalive traffic for all UDP-based
applications or UDP encapsultated protocols. In addition to IPSec/IKE,
there are also other protocols such as DSMIPv6 and Teredo, that use UDP
encapsulation to work through NATs. So, one clear use case for STUN
control is to optimize how any of those protocols work through NATs.

IPSec VPNs are of special interest as they are already widely used. For
instance you can try to run a VPN connection on any handheld device in
any wide-area radio network (CDMA EV-DO, WCDMA, EDGE, WiMAX) and see how
long the battery on the device will last. Most of the battery is
consumed by NAT keepalives sent every 20 to 120 seconds while there is
no real traffic to send. Optimizing this should be of interest to: 
a) users (get their work done before the battery dies) 
b) enterprises (allow their employees get their work done while on the
road) 
c) handheld device vendors (make VPN usable in the devices) 
d) wireless operators (make VPN usable in their network) 
e) NAT vendors (sell boxes that meet the reqs of the above groups)

In the long run any IPv6 over IPv4 solutions might also become necessary
for mobile hosts and they will face the same UDP NAT problem. 

Markus
 

>-----Original Message-----
>From: ext Dan Wing [mailto:[e-mail]] 
>Sent: 10 October, 2007 03:04
>To: [e-mail]
>Cc: [e-mail]; [e-mail]
>Subject: [SAFE] RE: [tsv-area] BOF request under consideration: SAFE
>
>Thanks for the pointer.  I read RFC4306 section 2.23, and IKE 
>(and IPsec) could benefit from reduced keepalive traffic if it 
>knew how often to send the keeaplive.  It could learn or 
>adjust the keepalive interval using UPnP, STUN Control, NAT-PMP, etc.
>
>So, the IPsec/IKE UDP-based NAT traversal technique is another 
>thing that could benefit from knowing the NAT binding lifetime
>-- much like SIP-Outbound benefits from knowing the NAT 
>binding lifetime and is able to reduce keepalive traffic.
>
>So, I think I'll mention this reduction of IPsec keepalive 
>traffic is another benefit that STUN Control could bring.  In 
>that light, I added the following to the soon-to-be-published
>draft-wing-behave-nat-control-stun-usage-04.txt:
>
>   2.4.  Reduce IPsec keepalive messages
>
>   STUN Control is also able to reduce keepalive traffic for non-STUN
>   protocols.  In Section 4 of [RFC3948], it is suggested that IPsec
>   keepalive packets be sent every 20 seconds if an on-path NAT is
>   detected.  If a host and its NAT were to implement STUN Control, the
>   host can query and control the NAT's binding lifetime, and thus
>   reduce the NAT keepalive traffic.  This reduction in keepalive
>   traffic would slightly reduce the load on its IPsec concentrator.
>
>-d
>
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]]
>> Sent: Tuesday, October 09, 2007 3:11 PM
>> To: [e-mail]
>> Cc: [e-mail]; [e-mail]; [e-mail]
>> Subject: RE: [tsv-area] BOF request under consideration: SAFE
>> 
>> 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
>


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