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 ===================================== CHAIRS: 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 draft-ietf-behave-rfc3489bis-00 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? Discussion: 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 draft-ietf-behave-nat-00 Discussion: o JR: add udp in filename Status: 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 Discussion: 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) Discussion: 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. Discussion: 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 Discussion: 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. Discussion: 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 draft-wing-behave-multicast-00 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 Discussion: 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? Discussion: 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. Discussion: 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 Status: - 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 draft-ietf-behave-nat-00 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 draft-wing-behave-behave-multicast-00 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. |