Subject: [Ietf-behave] Re: Rough minutes for BEHAVE

From: Cullen Jennings <[email-masked]>
Date: Sun, 14 Aug 2005 15:14:58 -0700 (PDT)

Paul, thank you for taking notes...

Just to add a few more bits of information... On the last topic of in Paul's notes, the topic Bryan Ford had brought up with the group was the adoption of gen and overall organization of the documents.

The blue sheets had 102 names on them.

Cullen

On 8/8/05 8:20 AM, "Paul Kyzivat" <pkyzivat@xxxxxxxxx> wrote:

Attached are my notes from the BEHAVE session. There is a point down 
near the ned that I didn't get good notes on.

 Paul
Notes: Behave WG – IETF63, Tuesday 2-aug-2005
Scribe: Paul Kyzivat
Draft-ietf-behave-nat-udp-03
Presented by Francois Audet
Discussed status and changes. There were two open issues: 
1.     Removal of Section 5.2. 
Final Resolution: Approved.
2.     In new REQ-7 (a) there is debate whether to use MAY or SHOULD in: the filtering behavior {MAY/SHOULD} be an option configurable by the administrator of the NAT. Brian Ford advocated SHOULD, Cullen Jennings advocated MAY. 
Cullen said applications can’t depend on this favor anyway, so no point in requiring it. 
Paul Hoffmann noted that SHOULD must include the rationale when it can be violated, and he thought that may be hard to do in this case. 
Jon Peterson thought there was confusion regarding the target for this requirement – a NAT builder or administrator. 
Brian said just having the option is helpful for self organizing peer-to-peer systems where some of the nodes need to be super nodes that require special NAT behavior. He postulated that the objection to SHOULD was that some NAT vendors might object to meeting it. He asked if there were NAT vendors in the room that could answer, but none did. 
Jon asked for anybody other than Brian in favor of SHOULD to respond. Nobody did. 
Someone from Juniper (I didn’t catch who) spoke as a NAT vendor.  He said they are concerned about security in their NAT, and that if they were convinced to implement the option they would strongly encourage customers not to enable it. 
Final resolution: this stays a MAY.
Other discussion on the draft:
Dan Wing suggested that maybe the document should be targeted at application developers (what they should expect) rather than what NAT vendors should do. 
Brian Ford brought up an issue regarding fragmented UDP packets. He said some operating systems routinely send fragmented packets out of order, and this breaks applications. This was identified as a change from a MAY to a MUST in Requirement 13. Cullen claimed it is impossible because it opens up DOS attacks. Dave Oran said there is no DOS attack if reassembly of fragmented packets is done right. (By reserving a fixed number of reassembly buffers and only doing reassembly when a buffer is available.) 
Final resolution: Agreed in principle to this change pending a write-up by Brian Ford.
Brian brought up another issue: Twice NAT is becoming a big issue. Almost all consumer NATs use DHCP to obtain their IP address. If this gets an address from another NAT, then the downstream and upstream addresses could end up the same. Some NATs have been observed to fail in this case. He requested language that NAT vendors be sure to cope with this. There was some question of whether use of twice NAT is increasing or decreasing. However no one in the room had first hand knowledge of this situation – only hearsay. 
Final resolution: Brian and Cullen will come up with wording to address this.
Brian had an issue regarding document organization. 
Final Resolution: Paul Hoffman said that can be done by chairs and AD – it doesn’t require consensus. 
Brian had another issue about terminology. Jon Peterson thought it appropriate. 
 [ed: I didn’t catch what the actual issue was, and this item doesn’t make much sense to me now.] 
Brian complained he hasn’t had a hearing on all the documents he has tried to offer. Jon Peterson thought this has had ample hearing on the list. The room was polled for others agreeing with Brian. No one responded, so Brian agreed to drop his objections. 
The end of the meeting was then at hand so there was no time to discuss other documents.