RE: [SAFE] SAFE BoF in Vancouver

[<[e-mail]>]

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