2.8.2 Behavior Engineering for Hindrance Avoidance (behave)

NOTE: This charter is a snapshot of the 61st IETF Meeting in Washington, DC USA. It may now be out-of-date.

Last Modified: 2004-10-04


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 or
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 mechanisms.

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 to
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 best
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-00.txt
  • draft-ietf-behave-nat-00.txt

    No Request For Comments

    Current Meeting Report

    Behavior Engineering for Hindrance Avoidance WG (behave)

    TUESDAY, November 9, 2004, 1415-1515

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

    Below is my summary of the key items with * beside the ones where the author of the draft needs to go do something.

    STUN Update - Jonathan - draft-ietf-behave-rfc3489bis-00

    Added server name attribute to this rev

    * Agreed to change support for server change address flag from MUST to SHOULD

    UDP Unicast Behavior Francois AUDET 15 min - draft-ietf-behave-nat-00

    * Change name to have udp in the draft name

    * Draft is suggesting to preserver ports. Leave draft same but add text that indicates that some security devices may not want to do this to obfuscate the traffic but that is outside the scope of behave.

    * Port parity preservation can not be replied on and thus is not deterministic so we probably don't want it. The application usage document needs to discuss how RTP applications that work with behave nats need to explicitly signal rtp and rtcp port numbers.

    * Port range conclusion: if the host's source port was in the range 0-1023, the NAT's source port MUST also be in the same range. If the host's source port was in the range 1024-65535, the NAT's source port MUST also be in that range

    * make sure multihoming is addressed in document

    UDP Multicast Behavior Dan Wing draft-wing-behave-multicast-00

    Looks good - people need to read this.

    TCP Behavior Discussion

    Most people felt that solutions that relied on spoofing source addresses were not the way to go.

    Some of the other solutions would be scope creep if we dealt them in this WG. They would best be dealt with in MIDCOM or NSIS (in fact may already be done :-)

    There was interest in pursing what would be required of the NATs to make the the simultaneous open approach reliably work.

    More details provided in 3 sets of notes below. Many thanks to Mary Barnes, Spencer Dawkins, and Alan Johnston for the great notes.

    AGENDA: (Last revised Nov. 1)

    1. Agenda Bashing, Bluesheets, Note-takers 5 min

    2. WG status update Chairs 5 min

    3. STUN Update - Jonathan - draft-ietf-behave-rfc3489bis-00

    Jonanthan added the "changed attribute" in this revision, and we noticed that there are some interop issues here (with ICE, it's optional for servers).

    Need to at least document when it's OK to not implement it.

    If I send this to a server that doesn't support this, I get an error response - is that enough? Actually, error is unrecoverable so we need to try to avoid the situation. ICE specifies a response code - we should probably use it.

    4. UDP Unicast Behavior Francois AUDET 15 min - draft-ietf-behave-nat-00

    Should this filename have UDP? Probably - deadline was problematic.

    Integrates post-IETF 60 decisions

    Have had new mailing list discussions (in blue, in the slide deck) and will be reflected in the next draft

    Document only covers NAT - no Firewall and no ALG. Covers only UDP Unicast

    IP address assignment - "paired, best-effort" assignment is RECOMMENDED, "arbitrary" is MUST NOT - but customers have requested "arbitrary" and then demanded "sticky" behavior for security-by-obscurity reasons. We can't make bad behavior illegal, but we can say what conforms, and doesn't conform, to BEHAVE behavior in a BCP.

    RTCP/RTP is slightly ugly here, we think (because two source ports are involved. Adding text about problems with current approaches.

    Is BEHAVE for all NATs, or just peer-to-peer NATs? We think it's for all NATs, but would love to think about this more.

    APPS area multi-homing?

    We're adding requirement that well-known source ports MUST map to well-known ports at the NAT, other source ports MUST NOT. Can cause confusion with IKE, for instance (and telnet, and SSH, and ...)

    We really like NATs that fail deterministically more than NATs that fail non-deterministically.

    Preserve parity of UDP ports if possible ("if not running out of ports with right parity") - this helps with RTP/RTCP parity. If not possible - SHOULD log it?

    Want to allow Inband Refresh as a MAY to allow for MULTICAST.

    SHOULDs and MAYs drive Jonathan nuts, because there's more behavior that might happen but can't be counted on.

    Any outstanding issues? Is multihoming a hard problem to solve? We haven't talked about it in these documents.

    5. UDP Multicast Behavior Dan Wing 10 min - draft-wing-behave-multicast-00

    IGMP from a host keeps multicast NAT bindings open - don't need inside-to-outside packets to refresh bindings

    NAT devices become IGMP proxies in this document (IGMP to the left, PIM to the right?)

    Not everyone has read this draft...

    6. TCP Behavior Nagendra 10 min

    How to peer-to-peer TCP connections between two hosts separated by two facing NATs.

    Using an external server to forge SYN/ACKs in both directions to get past unmodified NATs dropping incoming SYNs? Lots of problems (for instance, ingress filtering.) - we should make things like this always fail!

    Port reservation? Requires NAT upgrades on at least one side.

    Should we keep looking at this in BEHAVE?

    Boy, it would be easier to adopt IPv6 than require this level of infrastructure change.

    Cornell has done some of these scenarios - they work through about 70 percent of NATs, unless you do port prediction.

    What are we doing in this WG? We aren't standardizing anything, we're trying to define behavior. We're still not sure we can make TCP work peer-to-peer across multiple NATs, certainly without changes to protocols (NSIS, MIDCOM, etc.). This is scope creep actively creeping.

    7. Open Issues Jiri Kuthan 10 min

    8. Other Topics TBD 0 min

    9. Next steps Chairs 5 min


    AGENDA: (Last revised Nov. 1)

    0. Agenda Bashing, Bluesheets, Note-takers 5 min

    1. WG status update Chairs 5 min

    2. STUN bis - Jonathan
    Few changes:
    o Added server attribute to include server name and version.

    Issue: supporting change flags
    o The change flas and CHANGED-ADDRESS attribute needed only for detection
    o Detection is now not central to STUN
    o Problem:
    o Servers still need to support it
    o Problematic in ICE
    o Approach:
    o Optional in server (SHOULD) (change from MUST)
    o Document scenarios when its OK to not implement it
    o Interop concerns?

    o Cullen: if you sent a request to a server that didn't support this, you'd get an error back?
    o JR: yes. Error response isn't awfully useful (non-recoverable) It's more important to document.
    o Cullen: right now if you have a server that does this, the client comes to the wrong conclusion.
    o JR: ICE spec recommends a particular error response code and consider whether that is the right one.

    Conclusion: Agreed to proposal.

    3. UDP Unicast Behavior Francois AUDET 15 min

    o JR: add udp in filename

    o WG doc
    o Last version was draft-audet-nat-behave-00
    o Integrates decisions made in IETF60 and on the list since then.
    o Presentation also describes new mailing list discussion consensus reached after current text was submitted.
    o No major outstanding issues.

    Changes to scope:
    o Covers only nat
    o Firewall out of scope; only inherent filtering aspects of NAT is in scope.
    o Covers only UDP unicast
    o UDP multicast in another doc
    o TCP behavior to be in separate doc
    o Application aspects still out of scope (but very important)

    IP Address Assignment
    o Multiple IP addresses on external side of NAT
    o IP address pooling:
    o "arbitrary": MUST NOT (Req 2a)
    o "paired, strict" MAY (Req-2b
    o "Paired, best effort" (RECOMMENDED) (REQ-2)
    o Required for gaming and other protocols that don't negotiate IP address for RTP/RTCP separately
    o Minimize port exhaustion

    o Gregory (Juniper): arbitrary, customers have explicitly asked for this and have had to do functional modes that are sticky (if you start an appl on one IP, you keep that same arbitrary address). As an architect, this was not likable, but did understand why they need this for their appls, randomness, security (etc.) We can say MUST NOT if ?
    o Cullen: different appls originating on different ports, if it was data from same port on PC client, then it would stay on the same IP (source).
    o Gregory: 5 tuple (application) always stays with the same binding. It's when it's a new dest or source, it can change. There are valid requirements for "arbitary", can we really tell the world "MUST NOT" or restrict that to BEHAVE compliant only. At high level there is appl, a layer lower there is the thing that SW does. You're telling people that you must bind SW (source addrs). But, the box in the middle of NW doesn't have this correlation. Not sure that can be created.
    o Francois: if traffic coming from the same internal IP address, it will always have the same external IP address binding (while it's active - simultaneously).
    o Gregory: How does box know if streams are for the same higher level appl?
    o Francois: they don't.
    o Gregory: some people want to know.
    o Spencer: the decision to violate the RFC is at the endpoints and not in the network; is that true?
    o Cullen: if source IP and port are the same, the assumption is it's the same appl
    o Francois: we assume the binding will be the same.
    o Gregory: semantics clarification: same source address&port. Middle of NW assumes that any 5 tuple is the same stream. (and that will stay bound).
    o Cullen: stickiness is not on the 5 tuple, but on the source IP address and port.
    o Steve C: it's often not the case that things are sent from the same port. At the same time seems like the right compromise. It sounds like some people won't be satisfied with that.
    o Gregory: what we can't say is that "MUST NOT" isn't applicable. Need to say if you want to run these sorts of protocols and use these types of NATs. Be clear to describe what it is that will work.
    o Jiri: there are different boxes with different objectives. BEHAVE compliant must comply, although there may
    o Christian H: address and port must map to the same address on the other side.
    o Cullen: might want to mention that there are occasions when this might not be so.
    o Christian H: when traffic originates from a certain IP addr and port, it should go out the same IP address and port. If you don't want to do that, then behavior must be explicitly defined.
    o Spencer: is it going to be possible for appls that think they're compliant.
    o Gregory: "I love SIP". Can we make sure we're not using the SIP hammer? All appls don't have the same requirements. Concern over Christian's statement, don't want to force this compliance if they have other security requirements. Needs further considerationŠ
    o Leif: SIP is a good model application. Perhaps should refer to Eric Nordmark's presentation
    o Cullen: Back Christian's comments. We are saying if you builds NATs this way for these applications; won't get rid of those. ICE is what you use to figure if you have the NATs you needŠLike draft how it is.
    o Christian: Microsoft has been looking for such a recommendation.

    Conclusion: text is okay as is (?)

    Issue: RTCP=RTP+1
    o No requirement to attempt to preserve the port contiguity rule
    o Mailing list consensus for new text for new release:
    o Explaining that techniques currently used have significant issues with glare and /or wasteful for non-RTP UDP packets.
    o OK with Magnus (AVT): RTSP impact
    o Separate negotiation must be done by application (out-of-scope of this document, but very important for application doc)

    Cullen: this is an RTP issue; they need changes anyway. There is no backwards compatibility issue.
    Roni: you need to specify what you need for RTP and RTCP.
    Francois: there is another doc for appl aspects. For certain protocols, it's already done.

    Conclusion: not covered in this doc.

    Issue: Source port Range
    o Current text: MUST not use Well-known (REq-3c)
    o Mailing list: some appls will break with this (RFC 2623)
    o Agreement: if the host's source port was in the range 0-1023, the NAT's source port MUST also be in the same range. If the host's source port was in the range 1024-65535, the NAT's source port MUST also be in that range (REq-3c)

    o Michael Richardson: Is it legal for the NAT to use the same source port?
    o Francois: yes.
    o Michael: this has caused problems for IKE. Causes problems for gamers. Prefer consistent failure. Does not want non-deterministic.
    o Adam: this looks good, but 1024 range is small. May need that to be a SHOULD. Don't want to reject if you have higher ports available.

    Issue: Port Parity preservation
    o Behavior:
    o "yes, best effort" RECOMMENDED (REQ4)
    o "yes, strict": MAY (REQ-4a)
    o "No": MUST NOT (REQ-4b)
    o Respect RTP/RTCP parity convention when possible, without running out of port unnecessarily
    o Some RFC 3550 has some wording that may cause appls to unilaterally subtract 1 to an odd RTP port
    o Reasonable and simple to implement.

    o Gregory: should have the ability to log if you don't behave in this way, so that it can be debugged.
    o Steven C: surprised that people make that interpretation, the text is clear
    o Cullen: should signal both. This is exactly the non-deterministic behavior that we wanted to get rid of. Will have to signal RTCP port in devices.
    o Gregory: if we're going to say only keep parity, you should still log it so people know why app is breaking.

    Conclusion: still open issue.

    Issue: binding refresh direction
    o Outbound refresh=True: MUST (REQ-6) - no change
    o Inband refresh=TRUE: MAY (REQ-6a) - to allow for multicast, described in new document

    o JR: why is this a problem. Why can't outbound rule apply? Why can't the text stay to just address unicast?
    o Christian: what's wrong with MAY?
    o JR: introduces more non-determinism.
    o Francois: ?
    o JR: ?
    o Christian: those are old appls, so they may work.
    o Dan: music on hold is a non-behave aware application, thus NAT vendor would want inbound refresh. One solution might be to have

    Conclusion: continue discussion on the list.

    o Henry S: multihoming: don't see it addressed in these docs?
    o Cullen: we'll make sure it's addressed.

    4. UDP Multicast Behavior Dan Wing 10 min

    o IGMP packets from a host keeps multicast NAT binding open - don't need inside-to-outside packets

    o MUST support incoming multicast of IP protocol

    o Dan: only have received a few comments
    o Joerg: you're not assuming a router in the NW?
    o Dan: the NAT behaves as if it were a host. A residential class NAT that behaves as a host.
    o Gregory: NATing box is multicast aware and acts as a router on the other side and the other model is IGMP proxy model.
    o Dan: draft is the latter model, the former wasn't considered in scope. Conclusion: ? continue discussion on list - need more feedback

    5. TCP Behavior Nagendra 10 min

    p2p behavior behind nats.

    Solution 1: No changes to NAT:
    o A&B sends ISN's to S
    o S "determines" external port numbers
    o A&B send SYNs towards each other
    o S generates forged SYN/ACKs

    o Pros:
    o Works without changing NATs
    o Cons:
    o Port# prediction may fail
    o Egress/ingress filtering may block forged packets
    o How portable is SO_REUSEPORT?

    o Gregory: IETF work will make this fail.

    Solution 2: No forged packets
    o A&B sends ISN's to S
    o S "determines" external port numbers
    o A&B send SYNs towards each other

    o Pros:
    o Works without changing NATs
    o Cons:
    o Port# prediction may fail
    o Requires NATS to allow packets.
    o How portable is SO_REUSEPORT?

    Solution 3: Port Reservation

    o Pros:
    o No port number guessing - works reliably
    o Works even if NATs only on one side are upgraded
    o Client code simpler
    o Port reservation can be implemented as an ALG
    o Cons:
    o Need to define and deploy a new protocol
    o All NATs need upgrading.

    o Suresh: this work has been covered in MIDCOM already (ford draft)
    o Cullen: yes, this last approach is closer to MIDCOM and NSIS.
    o Christian: UPNP port reservation is available (on many ISPs). Or overlay IPv6.
    o Paul Francis: have implemented 1 and 2 (at Cornell). Setup about 12 home boxes. Second one works through about 70%. First works in almost all.
    o Gregory: 3rd option is almost how ALGs work today. The delta is that nothing singles what to try, thus go deeper in appl layer.
    o JR: getting confused about what we're doing in this WG. Have an opportunity to define NAT behavior so something can work. Don't want to have to make some of these assumptions. If we can change behavior of NATs, should we do that to facilitate the connectivity; that's what this group should work on.
    o Melinda: Feature creep: important problem, but doesn't belong in this WG. Don't think that there's anything that can be done.
    o Cullen: If the approaches that only modified NAT behavior, might look at them.
    o Melinda: agree someone needs to do the work, but not here.
    o Suresh: One suggestion is that TCP port binding, simultaneous open would work - applicable to this WG.

    6. Open Issues Jiri Kuthan 10 min

    7. Other Topics TBD 0 min

    8. Next steps Chairs 5 min


    Behave WG Minutes

    Cullen Jennings
    Jiri Kuthan

    Tuesday November 9, 2004

    Minute Taker: Alan Johnston


    - first meeting of this WG
    - four I-Ds written
    - still have some documents not yet written

    Agenda Bash

    - Chairs Update
    - STUNbis
    - UDP Unicast
    - UDP Multicast
    - TCP behavior
    - Open issues

    No changes to agenda.

    STUNbis - Jonathan Rosenberg

    - few changes
    - added Server attribute
    - open issue - supporting change flags

    solution: make SHOULD strength for server support

    Cullen: OK with this

    Resolution: document will be updated for this change.

    NAT Behavior Requirements - Francois Audet

    suggestion: add udp to the filename
    Status: WG document
    No major outstanding issues
    Changes since last version:

    - Some changes to scope
    - IP address assignment changes

    Greg: Can say MUST NOT on arbitrary assignment if we require protocols to note that they need this requirement or they will break
    Spenser Dawkins: It is a good thing if a failure only affects endpoints, not core of the network, is it?
    Cullen; If same source IP address, then address mapping should be the same.
    Greg; Is it 5 tuple?
    CUllen: Based on source IP address and protocol number only
    Stephen Casner: Different ports are used for RTP vs RTCP, for example
    Greg: Can't say MUST NOT do this in a NAT
    Cullen: We have consensus on this.
    Jiri (individual): Can bulid a security NAT box that doesn't conform to this requirements
    Christian Huitma: People can do anything they want. Can only say, preferably the same IP address should be used.
    Spenser: OK with all comments.
    Greg: Make sure this document doesn't only fit SIP requirements. Sometimes there are other requirements
    Cullen: Behave applies to NATs, but not Security NATs and Firewall devices
    Leif: Other applications besides SIP
    Cullen: Draft is OK as is.
    Christian: Also like draft

    - RTCP=RTP+1 port contiguity

    No requirement - out of scope
    Cullen: Don't see backwards compatibility issue.
    Roni: Not just RTP and RTCP

    Application specific documents will address this.

    - Source port range

    Current text: MUsT NOT use well known range
    Mail list agreement: if in well known, mapped port in well known, if 1024-65535, stays in that range
    Michael Richardson: Can the port stay the same? If so, causes problems with IKE. NAT doesn't know if IKE are for it.
    Cullen: Also SSH problems, etc.
    Michael Richardson: First gamer gets to play, the second does not. Rather have deterministic
    Adam Roach: Could be port exhaustion problems due to smallness of lower port range - don't want to fail because of this.

    - Port parity preservation

    Current text: preserve if you can (yes, best effort)

    Greg: Should log if you don't behave due to port exhaustion - helps troubleshooting
    Stephen: RFC 3550 doesn't say this
    Cullen: SHould get rid of this because it is not deterministic. RFC 3550 does not need to be changed

    - Binding refresh direction

    Jonathan: Don't know why have this problem. Just say outbound rule only applies to unicast.
    Christian: Proposal is OK - what is wrong with MAY
    Jonathan: Avoid non-determinism - SHOULD or MAY is bad
    Dan Wing: Solution is to have document be more explicitly unicast

    Take rest of issues to the rest

    Behave Multicast - Dan Wing

    No open issues
    Few have read.

    Joerg: Are you assuming a router?
    Dan: NAT acts as a host
    Greg: NAT can be mulicast aware OR NAT can proxy IGMP
    Dan: This is an IGMP proxy device

    P2P TCP through NATs - Nagendra Modadugu

    Problem statement
    Solution 1: no change to NAT, clients connect through a server first, server forges SYN/ACK
    Solution 2; no forged packets if NATs allow incoming SYNs
    Solution 3: port reservation - requires port reservation requests between NATs

    All NATs on one side must be upgraded.

    Question: There is a midcom draft that discusses this.
    Cullen: closer to NSIS than MIDCOM

    Cullen: Wrap up. Do we want to solve this problem in BEHAVE?
    Christian: UPnP has not been mentioned, is widely used and deployed in home NATs. Or could overlap IPv6 across NAT
    Paul Francis: We have implemented 1 & 2 and done testing. 2 works for 70%, 1 worked almost all.
    Greg: option 3 is like an ALG
    Jonathan: We shouldn't standardize any of these things. We are defining NAT behavior. Don't support forging.
    Melinda: I have a similar comment. This is scope creep. Important problem but doesn't belong here
    Cullen: Might consider other approaches.


    Welcome, Agenda Bashing, WG Status Update
    NAT/Firewall Behavioral Requirements
    Behave Multicast
    P2P TCP behavior through NAT’