2.8.2 Behavior Engineering for Hindrance Avoidance (behave)

NOTE: This charter is a snapshot of the 64th IETF Meeting in Vancouver, British Columbia Canada. It may now be out-of-date.

Last Modified: 2005-09-27


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


  • draft-ietf-behave-rfc3489bis-02.txt
  • draft-ietf-behave-nat-udp-04.txt
  • draft-ietf-behave-multicast-00.txt

    No Request For Comments

    Current Meeting Report

    IETF 64
    November 8, 2005, 1510 - 1710
    Eric Burger, unworthy scribe, but will work for beer
    NAT Behavioral Requirements for Unicast TCP
    Security considerations say do not send RST to SYN, but send ICMP
    soft-error, in order to prevent identity theft.  TCP WG is working on
    this problem.  Should be different error.  Also, sending error can make
    life difficult for end system.
    Looks like coordination between two working groups, as BEHAVE document
    may conflict with new TCP document.  Galling as new TCP document might
    address problem BEHAVE is trying to address.
    Randall Stuart for writing some text on this.
    Scope: things that are good for firewall to do, but not required for a
    NAT, are out of scope.  Not for us to forbid good properties, but not
    really for us to mandate, either.
    NAT needs to keep track of TCP Timestamp wraparound.
    SHOULD send RST to both parties probably will not work.  This encourages
    attacks, as timeouts trigger 3rd-part attack.  Ideally, this should be a
    local configuration option.  If done this way, note it in the document
    that YOUR application behavior may vary.
    Chairs: RST discussion in document is out of scope, as it has nothing to
    do with NAT traversal.
    Reminder: traversal of more than just SIP, but IPTV, etc. 
    sivakumar-draft on TCP traversal
    Should drop the SYN & RST attack language, for same reasons described
    above. (viz REQ-5)
    What about REQ-6, on keep-alives?  Jiri - feels out of scope for behave.
    Looks like application-specific behavior.  Hard to do in firmware.
    Smells like firewall stuff, not NAT stuff.  Inappropriate to do in NAT
    Times: Establishment phase timeout is way too short.  Get around by
    regular ping over ssh, or have per-flow timer settings.  Need to specify
    minimum TCP keep-alive value.
    What about having variable, load-based timeouts?  Not worthwhile, as
    client will not know.
    TCPM is looking to allow per-TCP stream timeouts.
    ipfilter uses 5 day timeouts.  8 years old; driven by long-lived TELNET
    Closing things in 4 minutes can actually cause more load on NAT.
    Back to configurable, per-stream configuration
    Eric with lemonade hat on, brings up the mobile battery problem: lots of
    keep-alive = no battery life
    Rohan: if timers in current RFCs are sub-optimal, write a draft to
    update those RFCs (e.g., TCP, UDP)
    Most low-end NATs are not configurable; need reasonable values
    Consensus: start with draft-hoffman-behave-tcp-03 as starting point.  WG
    can put stuff into it as necessary.
    Rohan: Need STUN over TCP for ICE, too.
    Rohan: likes concept of defining what is STUN is. Does not like it to be
    called a framework.  Likes it to be "a request/response protocol".
    Francois points out this work will be useful, as it clarifies what it
    means to "implement STUN."
    Noted that MUST have shared secret, but NO implementations do it.
    However, so much pain from security directorate that not really
    interested in taking it out and fighting battles again.  Might be able
    to hide it in the use cases.
    Home for TURN
    Why not do ICE in this work group, too?  Mute issue: ICE is pretty much
    done.  Also, ICE really is an extension to offer/answer, and thus
    Clarification: TURN would still be a separate document, just a use case
    of STUN.
    Mood for adopting TURN in BEHAVE?  Positive.
    Rohan: people have done hacks, like UDP<->TCP translation on TURN
    TURN Extension for IPv4/IPv6 Transition
    IPv6 possible and backwards compatible.
    Mood is to adopt this draft, too.
    Milestone Discussion
    Dropping STUN Test from milestones?
    Francois: might be worth doing, since stuff is more settled.
    Push to whenever?
    STUN Revisions: Rohan thinks March is better; JDR is willing to sign up
    for January 2006.
    Need author for BCP on Usage
    SCTP and NAT
    Use 32-bit random numbers to identify multi-homed streams, even if port
    numbers change.  2^16 combinations to avoid birthday problem.  In, for
    example, SIP case, lots of clients will have same destination address
    (SIP server).


    TCP Saikat
    TCP Biswas
    TURN IPv6
    UDP Tunnel