2.8.2 Behavior Engineering for Hindrance Avoidance (behave) Bof

Current Meeting Report

Behave Minutes -- Alan Johnston


(Behavior Engineering for Hindrance AVoidancE)

Chairs: Cullen, Jiri

Scribe: Alan

Agenda Bash: no comments.

Problem Statement - Cullen

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.


NAT/Firewall Behavioral Requirements