Last Modified: 2004-10-04
|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|
Behavior Engineering for Hindrance Avoidance WG (behave)
TUESDAY, November 9, 2004, 1415-1515
Jiri Kuthan <email@example.com>
Cullen Jennings <firstname.lastname@example.org>
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
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 Servers still need to support it
o Problematic in ICE
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 (?)
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 "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 Works without changing NATs
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 Works without changing NATs
o Port# prediction may fail
o Requires NATS to allow packets.
o How portable is SO_REUSEPORT?
Solution 3: Port Reservation
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 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
Tuesday November 9, 2004
Minute Taker: Alan Johnston
- first meeting of this WG
- four I-Ds written
- still have some documents not yet written
- Chairs Update
- 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
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.