The following BoF has been proposed for the Vancouver IETF. There is
a mailing list <safe@xxxxxxxx> for discussion.
Colin
SAFE - Self-Address Fixing Evolution BoF
----------------------------------------
Chairs:
Colin Perkins (csp@xxxxxxxxxxxxx)
Markus Isomaki (Markus.Isomaki@xxxxxxxxx)
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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf