Subject: [SAFE] SAFE BoF in Vancouver

From: Colin Perkins <[email-masked]>
Date: Fri, 16 Nov 2007 13:59:53 +0000

The following BoF has been proposed for the Vancouver IETF. There is  
a mailing list <[email-masked]> for discussion.

Colin

SAFE - Self-Address Fixing Evolution BoF
----------------------------------------

Chairs:
   Colin Perkins  ([email-masked])
   Markus Isomaki ([email-masked])

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/safe

---

From: Ted Hardie <[email-masked]>
Date: Tue, 20 Nov 2007 11:07:55 -0800

At 1:59 PM +0000 11/16/07, Colin Perkins wrote:
>The following BoF has been proposed for the Vancouver IETF. There is a mailing list <[email-masked]> for discussion.
>
>Colin

This seems to be scheduled against both the Applications area open meeting and
a RAI group focused on media servers.  Both groups would have an interest in
following this work and discussing where future IETF work in this area will happen.
Is there still a possibility of adjusting this timing?  I understand, of course,
that not every conflict can be resolved, but it would be useful to know whether
this is still something that might be addressed.
			regards,
				Ted Hardie

>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:
>
>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:
>Ietf mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/ietf

---

From: Colin Perkins <[email-masked]>
Date: Tue, 20 Nov 2007 23:38:25 +0000

On 20 Nov 2007, at 19:07, Ted Hardie wrote:
>> The following BoF has been proposed for the Vancouver IETF. There  
>> is a mailing list <[email-masked]> for discussion.
>
> This seems to be scheduled against both the Applications area open  
> meeting and a RAI group focused on media servers.  Both groups  
> would have an interest in following this work and discussing where  
> future IETF work in this area will happen. Is there still a  
> possibility of adjusting this timing?  I understand, of course,  
> that not every conflict can be resolved, but it would be useful to  
> know whether this is still something that might be addressed.

We're aware of the conflicts, but this is the least bad scheduling  
we've been able to find. If you have suggestions for a better slot,  
we're open to ideas.

Regards,
Colin

---

From: Ted Hardie <[email-masked]>
Date: Tue, 20 Nov 2007 15:54:46 -0800

At 11:38 PM +0000 11/20/07, Colin Perkins wrote:
>>This seems to be scheduled against both the Applications area open meeting and a RAI group focused on media servers.  Both groups would have an interest in following this work and discussing where future IETF work in this area will happen. Is there still a possibility of adjusting this timing?  I understand, of course, that not every conflict can be resolved, but it would be useful to know whether this is still something that might be addressed.
>
>We're aware of the conflicts, but this is the least bad scheduling we've been able to find. If you have suggestions for a better slot, we're open to ideas.

Friday morning?  There are no APPs or TSV groups meeting then, and the RAI group is
GeoPRIV, which wouldn't have as high an overlap as most other RAI groups.

Again, I know we can resolve every conflict, and I appreciate your considering changes.
				regards,
					Ted

---

From: Ted Hardie <[email-masked]>
Date: Tue, 20 Nov 2007 16:46:22 -0800

At 6:38 PM -0600 11/20/07, James M. Polk wrote:
>But Ted, you're going to Geopriv?  So how does this work?

Hi James,
	I'm trying to focus on the general problem (particularly the
apps open conflict), rather than my own ability to be there.  I'm conflicted
either way, but lots of other APPs people would be free on Friday.  Similar
for MEDIACTRL; some might still be conflicted, but a larger number would
be free.  I understand from Mary Barnes that she would
have a conflict with the Friday slot, so it may be unsolvable, but I hope
there may still be a way.
			regards,
				Ted

---

From: Colin Perkins <[email-masked]>
Date: Wed, 21 Nov 2007 01:11:02 +0000

On 21 Nov 2007, at 00:46, Ted Hardie wrote:
> apps open conflict), rather than my own ability to be there.  I'm  
> conflicted either way, but lots of other APPs people would be free  
> on Friday.  Similar for MEDIACTRL; some might still be conflicted,  
> but a larger number would be free.  I understand from Mary Barnes  
> that she would have a conflict with the Friday slot, so it may be  
> unsolvable, but I hope there may still be a way.

There's also a desire to avoid BoFs late in the week, to give time  
for hallway discussions on the outcome (as Pete Resnick has just  
mentioned on the WG chairs list).

-- 
Colin Perkins
http://csperkins.org/

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 20 Nov 2007 18:38:44 -0600

At 05:54 PM 11/20/2007, Ted Hardie wrote:
> >>>The following BoF has been proposed for the Vancouver IETF. 
> There is a mailing list <[email-masked]> for discussion.
> >>
> >>This seems to be scheduled against both the Applications area 
> open meeting and a RAI group focused on media servers.  Both groups

---

From: <[email-masked]>
Date: Wed, 21 Nov 2007 14:19:07 +0200

Hi Ted,

Ted Hardie [mailto:[email-masked]] wrote: 
>open meeting and a RAI group focused on media servers.  Both 
>groups would have an interest in following this work and 
>discussing where future IETF work in this area will happen.
>Is there still a possibility of adjusting this timing?  I 
>understand, of course, that not every conflict can be 
>resolved, but it would be useful to know whether this is still 
>something that might be addressed.
>			regards,
>				Ted Hardie
>

As Colin pointed out, it migth be difficult to reschedule the BoF to a
better slot, especially if Friday is considered as a bad day for BoFs in
general.

However, I agree that middlebox control should be quite relevant to
Applications community (inside and outside the IETF), also for reasons
that may not be so well known yet. In general most application protocols
that the IETF has developed already deal relatively well with NATs, and
methods such as ICE, hole punching, symmetric RTP/UDP, persistent
TCP/TLS connections are well known. The apps community outside the IETF
is actually doing better (with Skype etc.), since they know that NAT
traversal is a must-have feature to get anything deployed.

But what is not necessarily that well known is that even if the best of
these methods are used, "non-controllable" middleboxes still cause
constraints on how certain applications can be used in battery-powered
devices using wireless access networks. This is because the frequent
keepalives sent to maintain state in the middleboxes are a huge source
of power consumption. Many wide-area radio technologies (where endpoints
mostly are battery-powered) have been optimized for saving power when
there is nothing to send/receive. These schemes become quite useless if
there are multiple applications generating keepalive traffic just to
keep connected. UDP is basically totally out of question (as a transport
for long-lived app sessions) for its typical sub-one-minute keepalive
rate. TCP is better, but even that has visible effects on the battery
lifetime and when there are multiple applications the overall rate
becomes quite a problem.

With IPv4 address exhaustion I'm worried that we will see multiple
layers of NATs in many networks, so working with that kind of scenarios
seems more and more relevant. (Currently e.g. UPnP does not address
this.) Also we should consider Ipv6/IPv4 translation issues and IPv6
firewalls.

So, at this point the folks designing e.g. VPN, VoIP, IM, "push" e-mail
and various other apps requiring persistent connectivity for wireless
devices should be aware of this issue and should be quite motivated to
solve these problems in one way or another. Not to mention people with
interest in running P2P apps or more genral servers in such devices.
Migrating to IPv6 is a good long-term solution, but even then and
especially in the meanwhile middlebox control is important. Perhaps an
excplicit control protocol is not always needed, but a discovery
mechnisms (how to optimize the keepalive rate) seems like a mandatory
ingredient.

Markus

---

From: <[email-masked]>
Date: Wed, 21 Nov 2007 17:52:36 +0200

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:[email-masked]] 
>Sent: 16 November, 2007 16:00
>To: [email-masked]
>Cc: [email-masked]; Isomaki Markus (Nokia-SIR/Espoo)
>Subject: [SAFE] SAFE BoF in Vancouver
>
>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:
>
>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:

---

From: Philip Matthews <[email-masked]>
Date: Thu, 22 Nov 2007 10:24:44 -0500

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

---

From: <[email-masked]>
Date: Fri, 30 Nov 2007 12:17:25 +0200

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

>From: ext Philip Matthews [mailto:[email-masked]] 
>Sent: 22 November, 2007 17:25
>To: Isomaki Markus (Nokia-SIR/Espoo)
>Cc: [email-masked]
>Subject: Re: [SAFE] SAFE BoF in Vancouver
>
>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.
>
>- 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 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
>> that the protocol should meet and then see if it makes sense to use 
>> STUN as a starting point.
>>
>> - 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 
>> 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.
>> - 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?
>> 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:
>> 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?)
>> 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?
>> - 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 
>> 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.
>which is 
>>> The first is to interact directly with the NAT using a NAT control 
>>> 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: