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

From: [email-masked]
Date: Mon, 8 Oct 2007 12:52:16 -0400

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
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

> -----Original Message-----
> From: Magnus Westerlund [mailto:[email-masked]] 
> 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: [email-masked]
> 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 +46 8 4048287
> Torshamsgatan 23           | Fax   +46 8 7575550
> S-164 80 Stockholm, Sweden | mailto: [email-masked]
> ----------------------------------------------------------------------
> 
> 
> 
> 

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

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 9 Oct 2007 12:43:04 -0700

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

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Monday, October 08, 2007 9:52 AM
> To: [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: [tsv-area] BOF request under consideration: SAFE
> 
> Magnus,
>

---

From: [email-masked]
Date: Tue, 9 Oct 2007 18:10:54 -0400

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

> From: Dan Wing [mailto:[email-masked]] 
> Sent: Tuesday, October 09, 2007 3:43 PM
> To: Black, David
> Cc: [email-masked]; [email-masked]; [email-masked]

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 9 Oct 2007 17:04:14 -0700

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

> Sent: Tuesday, October 09, 2007 3:11 PM
> To: [email-masked]

---

From: <[email-masked]>
Date: Thu, 11 Oct 2007 13:22:27 +0300

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

>From: ext Dan Wing [mailto:[email-masked]] 
>Sent: 10 October, 2007 03:04
>To: [email-masked]
>Cc: [email-masked]; [email-masked]
>Subject: [SAFE] RE: [tsv-area] BOF request under consideration: SAFE
>
>knew how often to send the keeaplive.  It could learn or 
>adjust the keepalive interval using UPnP, STUN Control, NAT-PMP, etc.
>
>-- much like SIP-Outbound benefits from knowing the NAT 
>binding lifetime and is able to reduce keepalive traffic.
>
>> 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
>NAT-PMP, 
>> > and STUN/ICE.
>> > > omission, but I suspect that the (assumed) problem 
>definition for 
>> > > SAFE may exclude IPsec (e.g., IKE and IKEv2 have a different 
>> > > David L. Black, Senior Technologist EMC Corporation, 176 South 
>> > > St., Hopkinton, MA  01748

---

From: <[email-masked]>
Date: Thu, 11 Oct 2007 15:53:56 +0300

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    

>From: ext Magnus Westerlund [mailto:[email-masked]] 
>Sent: 08 October, 2007 18:09
>Subject: [BEHAVE] BOF request under consideration: SAFE
>
>Hi,
>
>appreciate any feedback on this. For public discussion please 
>use the SAFE mailing list.
>
>Post: [email-masked]
>http://www.ietf.org/internet-drafts/draft-wing-behave-nat-contr
ol-stun-usage-03.txt
>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:
>
>Other NAT traversal protocols do not share these 
>characteristics, which hinders their widespread deployment.  
>Specifically,
>
>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.
>
>draft-wing-behave-nat-control-stun-usage, which nearly 
>eliminates STUN's keepalive chatter and still preserves the 
>desirable characteristics of STUN/ICE.
>
>Behave mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/behave
>

---

From: Philip Matthews <[email-masked]>
Date: Fri, 12 Oct 2007 08:06:12 -0400

I would like to second Markus comments: I also support the goals of  
the BOF, but I share his two technical concerns. The second concern  
was raised at the "informal BOF" in Chicago, but the first concern I  
have not hear discussed before.

Regarding the first concern, I think this might actually go beyond  
just STUN Control to be a general STUN/ICE issue. Even without STUN  
Control, it seems important for an endpoint to know if its keep-alive  
rate is sufficient to keep the bindings in intermediate NATs alive.  
The way I see this might be done is for the STUN server (or perhaps  
the remote endpoint) to send data at regular intervals while the  
client sends keep-alives at some rate. If the client continues to  
receive data after one or two keep-alive intervals have passed, the  
client knows its keep-alive rate is sufficient. A client may choose  
to test a lower keep-alive rate in this manner to see if that is also  
sufficient.

- Philip

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Fri, 12 Oct 2007 15:19:33 +0300

> to test a lower keep-alive rate in this manner to see if that is also

From RFC4380, see §5.2.7 "Optional Refresh Interval Determination Procedure", 
which is exactly that. I had the feeling that "old" STUN also had such a 
thing as part of the behavior analysis stuff, but that this was considered 
bad, though. Maybe I got it wrong... ?

In any case, how often one sends keep-alives is a matter of engineering 
tradeoff between increased battery consumption and increased failure rate. I 
guess if the battery footprint is really bad, the industry will try to use 
longer refresh intervals whatever IETF recommends.

Nevertheless, I agree with Markus and you that there may be value in 
investigating STUN NAT control (and perhaps ALD and as well?), e.g. to 
negociate longer refresh intervals whenever possible. Hence, I support this 
BoF proposal.

-- 
Rémi Denis-Courmont

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 12 Oct 2007 10:20:28 -0700

> From: Philip Matthews [mailto:[email-masked]] 
> Sent: Friday, October 12, 2007 5:06 AM
> To: <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [SAFE] RE: [BEHAVE] BOF request under consideration: SAFE
> 
> Control, it seems important for an endpoint to know if its 
> keep-alive rate is sufficient to keep the bindings in intermediate 
> NATs alive.  The way I see this might be done is for the STUN server 
> (or perhaps the remote endpoint) to send data at regular intervals 
> while the client sends keep-alives at some rate. If the client 
> continues to receive data after one or two keep-alive intervals have 
> passed, the client knows its keep-alive rate is sufficient.  A client 
> may choose to test a lower keep-alive rate in this manner to see 
> if that is also sufficient.

Teredo (Section 5.2.7 of RFC4380, 
http://tools.ietf.org/html/rfc4380#section-5.2.7) has a documented
procedure for doing what you describe.

-d

> > would be impossible to rely on the increased timer values, 
> and thus  
> > the