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 <safe(_at_)ietf(_dot_)org> 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
SAFE - Self-Address Fixing Evolution BoF
----------------------------------------
Chairs:
Colin Perkins (csp(_at_)csperkins(_dot_)org)
Markus Isomaki (Markus(_dot_)Isomaki(_at_)nokia(_dot_)com)
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
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf