2.7.2 Behavior Engineering for Hindrance Avoidance (behave)

NOTE: This charter is a snapshot of the 62nd IETF Meeting in Minneapolis, MN USA. It may now be out-of-date.

Last Modified: 2005-01-07


J Kuthan <jiri@iptel.org>
Cullen Jennings <fluffy@cisco.com>

Transport Area Director(s):

Allison Mankin <mankin@psg.com>
Jon Peterson <jon.peterson@neustar.biz>

Transport Area Advisor:

Jon Peterson <jon.peterson@neustar.biz>

Mailing Lists:

General Discussion: ietf-behave@list.sipfoundry.org
To Subscribe: ietf-behave-request@list.sipfoundry.org
In Body: with subscribe in body
Archive: http://list.sipfoundry.org/archive/ietf-behave

Description of Working Group:

Given the current near-universal deployment of NATs (Network Address
Translators) in the public Internet, the lack of standards for NAT
behavior has given rise to a crisis. While it is widely acknowledged
that NATs create problems for numerous Internet applications, our
inability to describe precisely what a NAT is or how it behaves leaves
us few solutions for compensating for the presence of NATs.

The behavior of NATs varies dramatically from one implementation to
another. As a result it is very difficult for applications to predict
discover the behavior of these devices. Predicting and/or discovering
the behavior of NATs is important for designing application protocols
and NAT traversal techniques that work reliably in existing networks.
This situation is especially problematic for end-to-end interactive
applications such as multiuser games and interactive multimedia.

NATs continue to proliferate and have seen an increasing rate of
deployment. IPv6 deployments can eliminate this problem, but there is a
significant interim period in which applications will need to work both
in IPv4 NAT environments and with the IPv6 to IPv4 transition

This working group proposes to generate requirements documents and best
current practices to enable NATs to function in as deterministic a
fashion as possible. It will consider what is broken by these devices
and document approaches for characterizing and testing them. The NAT
behavior practices will be application independent. The group will also
advise on how to develop applications that discover and reliably
function in environments with NATs that follow the best current
practices identified by this working group. The group will consider the
security implications (or non-implications) of these devices.

The work will be done with the goal of encouraging eventual migration
IPv6 and compliance with the UNSAF [RFC 3424] considerations. It will
not encourage the proliferation of NATs.

The behavior that will be considered includes IP fragmentation and
parameters that impact ICMP, UDP, TCP, IGMP, MLD, and multicast. The
prop osed WG will coordinate with v6ops, midcom and nsis. The work is
largely limited to examining various approaches that are already in use
today and providing suggestions about which ones are likely to work
in the internet architecture. Discussion will start from several
existing drafts or RFCs, including:

RFC 3489

Goals and Milestones:

Mar 05  Produce a BCP document that describes the usage of protocols like STUN for performing black-box testing and characterizing NAT behavior
May 05  Produce a BCP that defines unicast UDP behavioral requirements for NATs
Jul 05  Any revisions to STUN required by other WG deliverables
Sep 05  Produce a BCP that defines TCP behavioral requirements for NATs
Nov 05  Produce a BCP that defines basic ICMP behavioral requirements for NATs
Dec 05  Produce a BCP that discusses protocol design techniques for using the existing set of NAT traversal approaches
Jan 06  Close WG or recharter


  • draft-ietf-behave-rfc3489bis-01.txt
  • draft-ietf-behave-nat-00.txt
  • draft-ietf-behave-nat-udp-00.txt

    No Request For Comments

    Current Meeting Report

    CHAIRS: Jiri Kuthan <jiri@iptel.org>
    Cullen Jennings <fluffy@cisco.com>
    Scribe: Spencer Dawkins <spencer@mcsr-labs.org>


    9:00 Agenda Bashing - Chairs

    * UDP close to consensus (unicast and multicast)
    * TCP getting slose
    * Thinkng about application draft
    * Missed "Using STUN for testing UDP" milestone
    * Do we need a separate draft for ICMP, or include this in other protocol drafts? include as part of general recommendation? TCPM is looking at problems with mapping ICMP messages back to TCP connections - could BEHAVE look at this?

    IAB Considerations for NAT Traversaql - Jonathan Rosenberg
    * draft-iab-nat-traversal-considerations-00 released just prior to the meeting
    * IAB wants inputs from multiple WGs, including BEHAVE
    * Lots of traversal mechanisms - how to choose the right general approach?
    * Looking at these considerations: security, deployability, manageability, availability
    * Please send comments to jdrosen@cisco.com or to IAB

    9:05 Unicast UDP - Francois Audet
    - draft-ietf-behave-nat-udp-00
    * Second release of draft (first was individual submission)
    * No major outstanding issues raised on mailing list
    * "Address and port mapping" <> "binding" in terminology
    * "Big NAT/FW opt-out" in applicability statement- large enterprise NATs that may partially comply to this recommendation because of of security, multihoming, etc. - do we really want to do this? Can we downgrade MUSTs to SHOULDs and give applications a heads-up that they can't count on specific behavior? We need to be realistic about MUSTs and SHOULDs, and explain when SHOULDs might not apply. Can we bring these issues onto the list? NAT security is too important to punt on it. If we want NATs to be deterministic, we can't punt. We should be talking about comply/non-comply - but we have "partially complybecause we don't implement all the SHOULDs", and this isn't 2119 language. The IESG thinks we're working on consensus in the industry, not opt-out. We have devices in the field today that randomize IP addresses for every session and we can't solve the problems we want to solve if this is OK. We've worked around these problems before, but it's a huge issue and we need to be aware of them.
    * Removed "RECOMMENDED but you MAY do something else" language - now "RECOMMENDED". Simpler, clearer.
    * Removed "REQ-8: NAT UDP filter and UDP binding timeout behaviors MUST be the same" - this was confusing.
    * ALGs - "If a NAT includes ALGs, it is RECOMMENDED that all of these ALGs should be disabled by default,, and that the NAT allow the user to enable or disable each ALG separately" - what about DNS ALG? But we need to turn SIP ALGs off by default (they aren't as helpful as they wish they were). Recommend DNS and FTP be on by default? Residential NAT defaults aren't likely to be changed - the defaults need to be right in the document.
    * Added definition of "deterministic NATs" into REQ-10. Can we reactively filter? Many NATs try to preserve the port mapping (cone NATs), but when they realize they can't because multiple endpoints are using the port, they suddenly become symmetric NATs - sometimes your application works, other times it fails. We don't care as much about what behavior a NAT adopts as we do about NATs that change behaviors. This isn't just about making testing work better, it's about making applications work better.
    * Port Parity - didn't change requirement, but changed text on RFC 3550, pointed out that some implementations don't support RFC 3605, and SDP-new-24 requires you to either respect the parity rule or use RFC 3605. What happens if only on party supprots RFC 3605?
    * No attempt ro require continuity of ports.
    * Now showing the relationship with Cone and Symmetric NAT terminology. We're still rat-holing on this. Some NATs make forwarding decisions based on IP address/port, others only on IP address - these have been documented during the testing sponsored by BEHAVE. Some NATs allow multiple hosts to send a UDP packet back to the internal host, although Symmetric NATs shouldn't allow this. Should we worry about this? We're trying to come up with more determinism, and allowing this behavior in requirements isn't giving us more determinism. Some spinning over definition of Symmetric NATs in STUN. We've already said not to build Symmetric NATs, do we need to talk about different ways ot building quasi-Symmetric NATs? Can we just show the mapping in a diagram? RFC 3489 definition is problematic - can't change the RFC 3489 definition, so do we need to use another definition? We'll take this to the list for exact wording discussion.
    * Open issue: REQ-3 recommends "No port assignment" behavior, but random behavior can result in port preservation. Don't recommend anything at all? Ports may/'may not be preserved, not important.

    9:45 Multicast UDP - Dan Wing
    - draft-wing-behave-multicast-00
    * Would like to adopt this as WG document, but not getting comments on the list since last IETF.
    * Determination on adoption will be made after checking with mailing list.

    10:00 Testing Results Status - Chairs
    - http://nutss.gforge.cis.cornell.edu/stunt-client.php
    - http://bgp.lcs.mit.edu/~dga/view.cgi
    - draft-jennings-behave-test-results-00
    * We have open source implementations for all the tests we've discussed - what should we test?

    10:05 What To Test? - Open Discussion & Chairs
    * Haven't seen any tests for multicast yet.
    * If you have ideas for testing, please tell us!
    * Requests: Router alert option, MTU handling on TCP and UDP, deterministic behavior with multiple devices behind NATs, ALG translation,

    10:15 TCP Behavior - Pyda Srisuresh
    - draft-sivakumar-behave-nat-tcp-req-00
    * Contains general recommendations that will be moved to behave-gen draft (after WG consensus).
    * Requiring a light-weight state machine (STARTUP, ACTIVE, CLOSING phases).
    * Allow reuse of TCP address/port binding across multiple sessions - does this accommodate peer-to-peer TCP connections we've been discussing? Yes, it's a MUST. Does port parity/continuity matter for TCP? No, we'll exclude this from discussion.
    * State machine should have timers for each state in the state machine - STARTUP timer values need to be shorter than ACTIVE timer values. How minmalistic can these requirements be, and still make sense? NATs are changing paradigm from packets to sessions. Is this requiring more than is necessary? We don't want to do applications - maybe we should be leaving timer values to NAT vendors, and not stating MUSTs? Timeout values probably make more sense for UDP (no explicity shutdowns, etc.). Does any of this help with SYN flood attacks? 30-60 seconds is way too long to help with SYN flooding attacks. 60 minutes are way too long for ACTIVE timer - Juniper does 30 minutes for long-lived applications, 10 minutes for other applications. We clear sessions completely on FINs. Indiustry has seven years of experience making this work - don't overlook this. Specifying values is a separate issue from specifying timers - maybe timers are enough?
    * TCP MUST NOT use a singed TCP port for both NAT'ed and local application sessions at the same time.
    * Suggest moving IP fragment requirements to behave-gen draft.
    * Suggest sequence number/ack number adjustments only when ALG is on the same ALG.
    * Suggestr moving ICMP error requiements to behave-gen draft.
    * New requirements - generate and process P-MTU for TCP. This could be used by UDP, too - move to behave-gen draft?

    10:30 TCP Behavior - Nagendra Modadugu
    - draft-modadugu-nat-tcp-00
    * Does NAT allow incoming SYN with simultaneous TCP open? Recommendation is "yes". What about traditional (outbound-only) NATs? Qualify this in the recommendation.
    * NATs don't send RST when port is unbound and you get a SYN. Recommendation is "discard silently".
    * How many TCP applications actually use TCP connections that go silent for long periods of time? Could have NAT implement TCP keep-alive - recommend that we don't do this. NATs have limited amounts of memory, have to time things out to avoid intentional/unintentional DoS attacks. If applications don't have keepalives, can't expect NATs to guess what's going on. SO_KEEPALIVE timer is on the order of 2 hours - if NATs are shorter, we keep creating zombie sessions on the servers. Doing RESETs in both directions without probing is not good. Need to make sure we don't keep dead sessions up forever. Can't we just rely on applications? NAT devices shouldn't cause a meltdown (but wasn't clear on how this would happen). Servers still have to worry about zombie clients, anyway. Can we make suggestions without tying them to requirements? But then we lose determinism, and application designers have to code for the worst case, anyway.
    * Do timer values need to be aware of standard TCP values?
    * Other behavior of NATs we need to consider? NAT rules based on specific destinations, other classes of traffic? If we have two different polcies, would both be BEHAVE-compliant? Greg to follow up offline.
    * Can we say "MUST NOT be symmetric NAT"?

    10:45 TCP Behavior - Open Discussion & Chairs
    * Recommend port mapping is endpoint-independent? General nods.
    * Port preservation? What about specific port numbers? BGP and IKE? Not IKE - this was a misunderstanding, DESTINATION port must be 500, but not source port - but this is is a deployed misunderstanding. Please send other examples to the list. BGP source port is also ephemeral.
    * Receive RESET behavior - do we care about this? Greg recommending NATing the RESET and starting a short timer (5 seconds) to accommodate packets in transit, but this is probably a hint to the NAT implementer. Don't want the NAT doing RESET processing unless it's tracking sequence numbers. What if RESET gets dropped and retransmitted? This is off to the land of firewalls, anyway - do we have to go there? If a NAT knows that RESETs don't open connections, it's turning into a firewall anyway.
    * Receiving an external SYN - General nods.
    * Port range preservation? Try to keep it in the same range.
    * Sequence number adjustment - in scope or ALG scope? If we recommend that some ALGs are on by default, can we declare ALG functionality out of scope? NATs won't change sequence numbers, so need to decide if we're going to be talking about ALGs.
    * Port parity? No
    * Port continuity? No
    * IP Fragmentation? Concern that requiring out-of-order fragmentation processing is open to DoS attack. Concern that NFS relies on fragmentation - can't break this. But aren't we talking about new applications? Do we need to care about existing applications in the decisions we make?
    * TCP timers? Lower bounds, or do we include defaults? What problem are we solving? Do applications really need to worry about keepalives? Existing customers dial down when they approach memory limits now - can't really give applications guidance on what you expect for timers - application timers have to be dialable, too.
    * Is ALG Segmentation Reassembly in scope? Don't know.
    * ICMP fix-up?
    * Refresh direction? We don't care?
    * Refresh scope? If it's TCP unicast, probably we don't care, and TCPs will need to keepalive on a per-connection case. UDP may have wildcards in both directions - we'll assume that we don't care.
    * IP Header Options to identify BEHAVE-compliance? Too vulnerable to manipulation - same as evil bit.

    11:30 Finish

    Mail Archive: http://list.sipfoundry.org/archive/ietf-behave


    Behave Status
    IAB Considerations for NAT Traversal
    NAT Behavioral Requirements for Unicast UDP
    BEHAVE Multicast
    Testing Status & What to Test
    NAT requirements for TCP (BEHAVE WG)
    TCP Behavior
    TCP Open Issues