SAFE - Self-Address Fixing Evolution BoF Request ------------------------------------------------ Chairs: Colin Perkins (csp@csperkins.org) Markus Isomaki (Markus.Isomaki@nokia.com) 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