Re: [SAFE] SAFE BoF in Vancouver

[Jonathan Rosenberg <[e-mail]>]

My two cents: I think the primary requirement is the ability to control 
binding lifetimes explicitly for UDP, and thats it. Everything else, 
like discovering intervening NAT, is a consequence of that requirement, 
and not a requirement by itself. I think binding lifetime control is the 
main issue since, without NAT control, techniques like ICE and sip 
outbound work well-enough that really we don't need control of the NAT. 
So, what is it thats not working so well with ICE and sip-outbound? 
Really primarily in the sip-outbound case its the frequent keepalive. So 
lets fix just that problem.

-Jonathan R.



[e-mail] wrote:
> Hi,
> 
> Here are some thougths on what I think we should be able to figure out
> wrt. this BoF. Not necessarily perfectly structured, but I hope this
> helps to initiate some discussion already *before* the actual BoF
> session, and helps us to formulate the actual key questions to present
> in the BoF.
> 
> 
> Requirements
> ------------
> 
> Perhaps it's fair to say that stun-control is mostly an opportunistic
> extension of an existing protocol (STUN) to do some new stuff (control
> NATs instead of just discovering them) rather than a top-down design
> based on pre-established requirements. However, to evaluate the
> usefulness of stun-control we should agree on some set of requirements
> that the protocol should meet and then see if it makes sense to use STUN
> as a starting point.
> 
> It might help as as starting point to list what stun-control CAN do
> without taking it too far. Here is my initial attempt, please comment:
> - Discover the NATs between the host and its STUN server. Assuming only
> a "single route" between the host and it's outmost NAT, these are the
> NATs between the host and any other host in the Internet. Assuming a
> more complex topology, the set of NATs depends on the peer (and
> routing/link state). There may be further issues with overalapping
> private address spaces.
> - Discover the "properties" of the UDP-binding in each of the NATs, in
> practice the filtering rules and expiration timer. Here it is important
> to note that this needs to be done binding-by-binding and in it's not
> possible to discover bindings created by other hosts. This can be seen
> as a feature or a limitation. 
> - Configure the properties of the discovered bindings, if allowed by the
> NAT policy. 
> - Discover which "control" protocols are supported by each NAT,
> including other than STUN itself.
> 
> The current draft also extends the discovery and control to firewalls,
> with a slightly different techique. 
> 
> Based on this analysis a few questions can be raised:
> - Is a protocol with features and limitations listed above useful on its
> own, or should the functionality be offered as part of some more capable
> protocol?
> - Should firewalls be in or out of scope?
> - Should only UDP be considered, or should also TCP be brought to scope?
> If we want to include TCP, does STUN approach make sense?
> - Is it a feature or a limitation that bindings are
> controlled/discovered one-by-one and hosts can only control/discover
> their own bindings?
> 
> Applicability
> -------------
> 
> This relates very much to requirements, i.e. from which real-word
> problem do we derive our requirements from and does stun-control indeed
> solve a real problem in a reasonable way. I think that the problem
> statement is relatively well written in the BoF proposal, including
> things like power consumption, server load and possibilty to optimize
> certain NAT traversal scenarios. Some questions related to this are:
> - What are the exact problems stun-control is supposed to solve?
> - Does it really solve them *well enough*? (For instance there are
> issues like the complex topologies, inability to discover
> non-STUN-supporting firewalls, overlapping address spaces and so on. Are
> these serious enough to ruin the use cases people have in mind or can we
> live with them?)
> - Can it be incrementally deployed? This has been one selling argument.
> 
> 
> Relation to other work
> ----------------------
> 
> This is the tough part related to dozens of other middlebox related
> protocols, i.e. how does stun-control fit in or differentiate itself.
> stun-control seems to have some distinct qualitities compared to various
> other protocols. It is hard to describe the differences in brief,
> draft-eggert-middlebox-control-survey is one attempt to classify and
> compare such protocols. Conserns about overlap with UPnP IGD has been
> specifically brough up. In that case the difference is quite clear,
> related e.g. to stun-control supporting nested NATs. In general there
> are various questions:
> - What is the difference/overlap between stun-control and protocols X, Y
> and Z?
> - What are the most relevant X, Y, and Z?
> - In cases of partial overlaps, can the protocols co-exist?
> - Does stun-control have some qualities why it would be easier to deploy
> than some of the existing protocols that (AFAIK) have not enjoyed wide
> deployment so far?
> 
> Another area is the separation of discovery and control. In some cases,
> e.g. with Teredo, Teredo itself can discover the outermost NAT and
> stun-control can start its work from that point onward. On the other
> hand, stun-control can be used only for discovery and some other
> protocols (such as UPnP IGD) for the actual control.
> - Should these kind of interactions be described somewhere in more
> detail, or do we just leave them to the product vendors to figure out
> (who may come up with exotic combinations...)?
> 
> Interest in the vendor/ISP/enterprise/application community
> -----------------------------------------------------------
> 
> By definition middlebox control solutions are not end-to-end things that
> we can just layer on top of the Internet. So, their success heavily
> depends on the vendors actually building the middleboxes. Also, in many
> cases the features need to be explicitly turned on by the ISPs or
> enterprise IT folks, so their support is also needed. Finally, support
> is needed from the less-well-defined applications community, who need to
> integrate the capabilities in the actual applications who want the
> control capabilities.
> - Can we say anyting about the interest of these communities toward
> stun-control? Is there any good way to find this out?
> 
> 
> Regards,
> 	Markus
> 
> 
> 
>> -----Original Message-----
>> From: ext Colin Perkins [mailto:[e-mail]] 
>> Sent: 16 November, 2007 16:00
>> To: [e-mail]
>> Cc: [e-mail]; Isomaki Markus (Nokia-SIR/Espoo)
>> Subject: [SAFE] SAFE BoF in Vancouver
>>
>> The following BoF has been proposed for the Vancouver IETF. 
>> There is a mailing list <[e-mail]> for discussion.
>>
>> Colin
>>
>>
>>
>>
>> SAFE - Self-Address Fixing Evolution BoF
>> ----------------------------------------
>>
>> Chairs:
>>   Colin Perkins  ([e-mail])
>>   Markus Isomaki ([e-mail])
>>
>> Mailing list:
>>   https://www1.ietf.org/mailman/listinfo/safe
>>
>> Various NAT hole-punching techniques such as IPsec NAT 
>> traversal, Teredo, and STUN/ICE send periodic UDP keep-alive 
>> messages to keep their NAT binding alive.
>>
>> However, a drawback of these techniques is their chattiness 
>> which is a result of the host application not knowing the 
>> NAT's binding lifetime (IPsec NAT traversal, STUN/ICE) or 
>> because the application is unable to extend the lifetime of 
>> the NAT's binding (Teredo).  The endpoint has to send periodic 
>> packets which consume power on battery powered devices, 
>> consume network bandwidth, and place an unnecessary load on servers.
>>
>> There are two approaches to resolve the problem of chattiness. 
>> The first is to interact directly with the NAT using a NAT 
>> control protocol. Several of these protocols exist which 
>> unfortunately have different drawbacks:
>>
>>   * incremental deployment is not possible with MIDCOM, NSIS-NSLP,
>>     UPnP IGD, or NAT-PMP.  With all of these protocols, both the NAT
>>     and the endpoint have to support the same protocol
>>   * nested NATs are not possible with UPnP IGD or NAT-PMP
>>   * topology awareness is required of MIDCOM
>>   * security must be established between the controlling entity and
>>     the NAT for MIDCOM and NSIS-NSLP
>>   * UPnP IGD uses broadcasts packets and NAT-PMP expects the NAT to be
>>     the default gateway; neither work well on routed networks
>>
>> The second approach is to empirically test the NAT's binding 
>> lifetime, as done by Teredo. This can optimise the keep-alive 
>> traffic based on the NAT's binding lifetime, but cannot extend 
>> the duration of the binding lifetime. Also, empirical testing 
>> does not always give reliable results due to varying behaviour 
>> of NAT and firewall implementations.
>>
>> This BoF is intended to discuss a newly-proposed technique for 
>> using STUN to discover, query and control firewalls and NATs, 
>> that can eliminate UDP keep-alive traffic. The BoF will review 
>> the problem space and existing work, and decide if there is a 
>> need for new work in the area, and if the IETF is an 
>> appropriate home for that work. The intent is not to form a 
>> new working group at this time, but to gauge interest in work 
>> in this area, and consider an appropriate future home for that work.
>>
>>
>> Agenda:
>>    Introduction ...................................... (Chairs, 10)
>>    Problem statement and scope ......................... (Wing, 15)
>>    Survey of existing work ........................... (Barnes, 30)
>>       draft-eggert-middlebox-control-survey-01.txt
>>    NAT/Firewall control with STUN ...................... (Wing, 15)
>>       draft-wing-behave-nat-control-stun-usage-05.txt
>>    Discussion ................................................ (20)
>>    Future directions ................................. (Chairs, 30)
>>
>>
>> --
>> version: 1.5, 16-Nov-2007
>>
>>
>>
>> _______________________________________________
>> SAFE mailing list
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/safe
>>
> 
> 
> _______________________________________________
> SAFE mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/safe
> 

-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[e-mail]
http://www.jdrosen.net                         PHONE: [phone]
http://www.cisco.com


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