Whereabouts: IETF60, Behave (Behavior Engineering for Hindrance AVoidancE) BoF, Tuesday August 04th 2004 Behave Minutes -- Alan Johnston ------------------------------- BEHAVE BOF (Behavior Engineering for Hindrance AVoidancE) Chairs: Cullen, Jiri Scribe: Alan Agenda Bash: no comments. Problem Statement - Cullen NATs! Proposal: BCP for NAT vendors, How to characterize, etc. Consistent with UNSAF Goals & Milestones presented (includes possible revisions to STUN) Ed Levinson: "What is broken" is missing from milestones. Brian Carpenter: Draft is good but why BCP instead of informational? Informational easier. Cullen: Agreed we need to discuss this. Spenser Dawkins: Limited to UDP? Cullen wants comments on this. Personal opinion not step into firewall area. Spenser: Can't fix ICMP Jonathan Rosenberg: Strongly in favor of BCP due to inconsistency in deployed devices Rohan Mahy: Charter page comments page 2, should have milestones on a per protocol basis. Alain Durand: Overlap with V6ops charter? Cullen: There are similarities, don't want to overlap (v6/v4 NATs). May feed requirements to V6ops group. Alain: Do you mean RFC 3056 or general v6/v4 translation? Cullen: RFC 3056 only. Alain: Shouldn't limit our scopt to this. Jon: IESG aware of overlap potential. Won't do overlap. Not intention to develop transition mechanisms. Alain: Why has v6/v4 been standardized in v6ops? Brian: Take out parenthetical phrase (6to4) Jiri: OK Spenser: NAT WG took a long time. Rohan: More operational experience now. Also wants BCP strength even if it takes longer. Cullen: We do have operational experience. We won't invent new ways, just look at existing. Jonathan: Can move out dates or split the problem into smaller chunks. UDP-centric nature in document is due to VoIP experience. March '05 should be achievable. John Warner: Problem of pointing vendors at multiple document? Cullen: Feel it is OK. Already thousands. Mark Handley: Jonthan's idea is good - should have templates and continuing document series. Henry Sinnreich: Will this reduce the need for media relays in VoIP? Jiri: Expectation is yes. Cullen: All documents say this helps UDP work without relays. Jonathan: For example STUN doesn't know NAT behavior. As this is deployed, STUN will work more often. Get rid of relays. Cullen: What protocols are important? UDP, TCP, ICMP perhaps? Others? Gregory Lebovitz: ESP - IKE on UDP works, ESP does not. We use tricks today to solve. There are a number of tricks. Spenser: How do we come down on ALGs? Jon: Yes, but this is not the point of BOF. About IKE, we aren't IKE experts, we need to understand requirements. Gregory: Not IKE, but ESP is the problem. Ackman: multicast is next in importance Cullen: More specifics? Ackman: Join using source address. Interdomain behaviors. Don't think it works today. Cullen: Question is do we have operational experience to do this as BCP Melinda Shore: Any problem where solution space is ALG is out of scope of this WG Jonathan: Feel more strongly we need to break it into pieces. Separate multicast joining from routing. Collin Perkins: Is RTP traversal out of scope. Jonathan; Yes. This is like ALG. Don't want NATs to pay attention to RTP. Collin: STUN has RTP implications due to port sharing requirement. Melinda: NATs should not have to deal with embedded addresses Collin: Agree NATs shouldn't deal with RTP. Jonathan: Application guidelines may discuss protocols such as RTP, but not in BCP. Melinda: Assume data is encrypted or proprietary, so can't do anything. Gregory: Can put in charter than NATs shouldn't read into payloads, past transport layer. Cullen: Need to wordsmith Gregory: How will we get the work done? Should protocols be handled in their own working groups? This group provides guidelines for other WGs to pick up and run with it. Cullen: Sounds like a good idea, need to decide which ones. Jiri: Preferences is for experts to come to this WG Jonathan; Agree work should be done here due to sharing of expertise. Need people in the room to commit cycles to get work done. Ackman: All NATs look into payloads, so I don't understand payload comments? Cullen: Need to define which level we mean - don't want to do ALGs at HTTP, RTSP layer. Jon: Look at payload issue as we do the work rather than bounding it in the charter. Same for list of protocols. such as text is good, but do the investigation going forward. John Lochney: Don't get bogged down in protocols but provide general guidelines for NAT makers. For new protocols, it should work based on general guidelines. "Don't mess with Layer 7" for example. Need to read existing literature on this topic as every WG has some text on how to get their protocol through NATs. NAT/Firewall Behavior Requirements - Francois Audet NAT/Firewall behavior was tested separately. Firewall only means filtering rules in NAT. Jonathan; NAT inherently requires filtering, and this is all we are talking about due to binding establishing. Scope is only enough filtering to make a NAT work. Not general behavior which has policy. change the term. Brian; There are boxes that do both. NAT/Firewall term suggests a combined box. Need a new word. Jiri: The WG should sort out this terminology. Really just packet matching Rohan; Lets not define new terminology, but redefine existing. Suraj: Agree with earlier comments on limiting scope to NATs. NATs are not deterministic, unfortunately. Document has requirements. Rohan; Before we start on details, lets get an idea of interest? Jiri: This is our set of requirements. Jon: I think this is a great idea. Alan Johnston: Its great, lets do it. Unknown: Why do it now? Didn't we try to stop them originally? Cullen: Like making rules for how to mug someone. Melinda: Fine line. There is a lot of IPR on NATs. Difficult to convince them to change. There is under participation by NAT folks. Result of groups might not be implemented except small residential NATs. Joe Hildebrand: Sex education is a better analogy, will do it anyway, help them to be safe. Rohan: We didn't provide NAT builders an alternative. Linksys is onboard. Many NAT providers are shipping voice services. Also being beaten up by gamers. Gregory: We have 75% of NATs builders here in this room. Abstinance just won't work. John: We are helping NAT vendors. Jeff Huston: Implementors get creative in the absence of standards. Implementors make guesses at the rough edges. Applications must navigate NATs. By not attacking this problem we are making a mistake. Ackman: Good idea. Jonathan; If we don't tell them what to do, they will not do what we want. Darran Falk; IETF doesn't do conformance testing. Brian: In addition to mention of IPv4, should insert IPv4 at the first occurance of the word "NAT" Joe: Deterministic behavior is good. Unknown: What about v6? Are we making this mistake again. Jon: I hope not. There is a tactical problem now, IPv6 can appear with a minimum of these intermediaries. IPv6 should be designed to prevent this problem, but could be wrong. Alan Hawrylyshen: What is the mailing list. Cullen: Mailing list is on agenda page. Jarki: Need to make more clear, one goal is that new NATs should meet this. Cullen: Let's take a hum on forming a WG using this charter. Strong consensus to proceed in Hum. Behave Notes -- Spencer Dawkins ------------------------------- AGENDA: (1) Agenda bashing (5 minutes) (2) Problem Statement, Scope Overview, and Charter (30 mins) Lots of NATs, especially in residential environments, and a lot of variety in how they work - and we can't predict or detect how they will work, on any given network path. This creates problems and makes it harder to deploy end-to-end applications. Think about what's broken and do a BCP about appropriate behaviors for NATs. Probably have to characterize NATs, give application developers NAT clues, and don't make IPv6 transition more difficult. Milestones are really aggressive, especially for a BCP. We have more operational experience, but we have more deployed residential NATs. Maybe looking at Mar 06, more likely than Mar 05 - Mar 05 is probably achievable for UDP, maybe not for everything. Is developing multiple documents, per protocol, OK? We think so. UDP could become a template for other protocols (DCCP, etc.). Should we explicitly state our expectation that this work will lessen the need for media relays? What other protocols? ICMP? ESP? Multicast (and how much work is required for multicast? And do we have enough operational experience to do NATs?)? Not looking at firewalls or at ALGs - this really will be TSV work, so these topics are clearly out of scope - anything that involves embedded addresses. Is RTP out of scope? Already covered when it's UDP-encapsulated. We' ll include examining transport payloads as out-of-scope. Need to wordsmith this carefully in the charter. Should some protocols be handled in protocol working groups? Break up, do a template, doesn't matter who actually writes what where after that? But does this cause inter-working group dependencies? And would the other working groups have people willing to contribute cycles on this topic? Don't make too many assumptions in the charter - do some investigation - maybe even the list of protocols should be "after some thought". What's broken enough that we know how to fix? Do we have to do protocol-by-protocol? Can't we provide general guidelines? Where can we collect "how to get protocol X through NATs" lore from protocol working groups? (3) Behavior Recommendations (15 mins) draft-audet-nat-behave-00.txt Co-authors (Nortel and Cisco) discovered they were drafting similar guidance for NAT/FW vendors for peer-to-peer media. NAT/FW vendors don 't really WANT to break VoIP or gaming, so they want this guidance. Terminology is confusing (at best), and we need to provide simple requirements suitable for consumer-grade NAT/FWs. Draft separates firewall behavior from NAT behavior - this conflation contributes to the confusion. Need some description of firewall behavior, but needs to be the minimum (not policy level aspects). Probably need a different word to avoid confusion - but make it a new term, not a redefinition of existing terms. And NATs aren't NATs, they are NAPTs. Other behaviors matter, too (hair-pinning, determinism, ICMP, fragmentation, TCP, multicast/IGMP). Determinism - NAT behavior is hack-upon-hack - no design at all, just debugging to solve specific problems. Why will anybody listen to the IETF BCP on NATs now? This is like making a BCP on mugging people. NAT vendors have a lot of intellectual property tied up in doing things the way they do things now. This BoF is driven by VoIP people folks, not by NAT folks, so may not be effective when the work is done. Residential NATs are probably easier, because they have less functionality, but NAT happens "inside the box" - no incentive for them to even come to the IETF. This isn't about mugging, it's about sex education. People are going to do this anyway - help make things safe. Abstinence-only is not a winning strategy. We didn't provide an alternative to NAT when people did NATs. We have representatives from 75% of the NAT product vendors in the world. They do have an incentive to do this stuff. Implementers get creative in the absence of standards. You've got to do this, or people will guess, and guess inconsistently. We should have done this two years ago. If we don't tell them what to do, there' s no chance they will do what we didn't tell them to do. Clearly defined documents attract implementers. We need to make it clear that we're talking about IPv4 NATs. We need to provide a discovery mechanism so people can tell a device does what we think they should do. If we say "no NATs in IPv6", are we setting ourselves up for another round of failure? IPv6 could be deployed without these problems - hopefully this will happen. What mailing list? It's in the charter. Deployed NATs won't be changed. Can we also include PROTO-41 forwarding? (4) Summary and conclusions (10 minutes) Hmmm in favor? Room sense is "yes". Behave Incomplete Notes -- Jiri Kuthan -------------------------------------- - Levinson: problem statement should be included - Carpenter: I'm a NAT hater. Why BCP and not INFO -- BCP harder to achieve; - Spencer: would like to fix ICMP, timeline concerns - JDR: recommends BCP -- it is what it is about - Mahy: split milestones by protocl - Durand: overlap with v6ops? - Dawkins: make it BCP - jdr: BCP, splitting deliverables by protocol may help with deadlines - Handley: seconded jdr - hsi: will we elimante media relays - fluffy: protocol priority? UDP high! - gle: include ESP in scope - Dawkins: verification question: ALGs in scope? (widely agreed that not, even though there was some struggle about where the border line is) - floor: something needs to be done about multicast - shore: ALGs are out of scope - perkins: how does it relate to RTP/RTCP - gle: rule out applications - loughney: name protocols specifically --- final discussion began - peterson: it's good, do it - johnston: supported - shore: concerns about vendors' willingness to give up on their ALGs, IPRs and other technology which would be obsoleted be behave - Hildebrand: it is like safe sex education - gle: question to floor: how many have private IP @ home; almostall hands in the room raised - Huston: you have got to do it, it is necessary - Carpenter: insert IPv4 before NAT (there was another Brian's comment before: remove v6 from charter)