Subject: 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

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

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:

---

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: "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 

But Ted, you're going to Geopriv?  So how does this work?

---

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

>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: <[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