Subject: [Ietf-behave] unrevised behave bof minutes

From: Jiri Kuthan <[email-masked]>
Date: Thu, 5 Aug 2004 17:18:19 -0700 (PDT)

Here are unrevised behave bof minutes, courtesy of Alan Johnston.
If people think, there is something missing or worth fixing, let
me please know.

-jiri

---------
BEHAVE BOF (Behavior Engineering for Hindrance AVoidancE)

Chairs: Cullen Jennings, Jiri Kuthan
Scribe: Alan Johnston
Time and date: IETF 60, Aug 04th 2004

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 Parlor: What is the mailing list.

Cullen: Mailing list is on agenda page.
http://www.ietf.org/ietf/04aug/behave.txt

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.