Re: [SAFE] SAFE BoF in Vancouver

[Philip Matthews <[e-mail]>]

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