RE: [SAFE] SAFE BoF in Vancouver

[<[e-mail]>]

Hi Philip,

Personally I pretty much agree with everything you say below. No one
else has commented, so we can thus far declare this as the consensus on
the list ;)

Markus
 

>-----Original Message-----
>From: ext Philip Matthews [mailto:[e-mail]] 
>Sent: 22 November, 2007 17:25
>To: Isomaki Markus (Nokia-SIR/Espoo)
>Cc: [e-mail]
>Subject: Re: [SAFE] SAFE BoF in Vancouver
>
>Of all the points your raise, I think the last one (about vendor
>interest) is the most important. In my opinion, this is where 
>all the existing proposals have fallen down. So perhaps any 
>working group should be deliberately given a very constrained 
>mandate: to produce a simple proposal that solves only the 
>most important problems, and do it quickly. Then, if there 
>seems to be interest, extensions can be considered.
>
>Personally, I think this would suggest the following:
>- The scope should be limited to UDP, since TCP mappings tend 
>to time out much more slowly.
>- Only minimal extra work should be done for firewalls. Don't 
>ignore them (because we don't want people turning on the NAT 
>in a firewall just so it can be controlled), but really limit 
>the firewall-only features to the minimum that seem to make sense.
>- Do handle the case of nested NATs/firewalls (because these 
>are increasingly common)
>- Assume any NAT that supports STUN-control is BEHAVE-compliant.
>- Assume any firewall that supports STUN-control does NOT do 
>address- and-port-dependent filtering.
>- Do provide a mechanism for path lifetime discovery (similar 
>to path MTU discovery; what is the minimum rate that 
>keep-alives need to be
>sent?) as this is very useful with only some NATs support STUN-control.
>
>- Philip
>
>
>On 21-Nov-07, at 10:52 , <[e-mail]> 
><[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
>>
>
>


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