Cullen,

We are waiting for you to tell us what you really meant: "SHOULD" or "MAY"
in 7a.

Please say so on the list so we can put this issue to rest...

To refresh your memory, I have:

 REQ-7: If application transparency is most important, it is
        RECOMMENDED that a NAT have an "Endpoint independent filtering"
        behavior. If a more stringent filtering behavior is most
          important, it is RECOMMENDED that a NAT have an "Address
        dependent filtering" behavior.

        a) The filtering behavior MAY be an option configurable by the
           administrator of the NAT.

Bryan is OK with 7, but wants to change the "MAY" to a "SHOULD" in 7a, and
claims that you are OK with it.

As you know, I really don't give a &*(*#? at this point.

> -----Original Message-----
> From: ietf-behave-bounces <at> list.sipfoundry.org
> [mailto:ietf-behave-bounces <at> list.sipfoundry.org] On Behalf Of
> Bryan Ford
> Sent: Tuesday, June 21, 2005 12:22
> To: Saikat Guha
> Cc: 'Behave'
> Subject: Re: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7
>
>
> On Tuesday 21 June 2005 19:07, Saikat Guha wrote:
> > On Tue, 2005-06-21 at 09:59 -0600, Bryan Ford wrote:
> > > On Thursday 09 June 2005 16:17, Francois Audet wrote:
> > > >        a) The filtering behavior MAY be an option
> configurable by
> > > > the
> > >
> > > I still feel strongly that the MAY should be
> > > a SHOULD in the second.  I don't recall hearing any
> objections from
> > > Cullen or anyone else after my earlier suggestion that we
> keep the
> > > SHOULD but change "user configurable" to "configurable by the
> > > administrator of the NAT".
> >
> > I agree with Cullen (below) that changing the MAY to should doesn't
> > change any interoperability issues. Even if "user configurable" is
> > changed to "configurable by the administrator", all of Cullen's
> > objections still hold.
>
> In what way do they still hold?  As far as I can tell,
> Cullen's objections
> were primarily based on his comment that "In many case[s] the
> administrator
> of the NAT is very different from the user of it" and
> therefore it was
> unreasonable to expect a NAT's behavior to be
> "user-configurable".  That
> statement I agree with.  It is entirely reasonable, however,
> to expect a
> NAT's behavior to be "administrator-configurable".  Every NAT
> on the planet
> is already "administrator-configurable" - even locked-down
> NATs supplied by
> ISPs, which are configured by the ISP's administrator
> (perhaps before they
> are even shipped to the user).  The problem was merely a
> minor semantic
> confusion caused by the distinction between "user" and
> "administrator".  I
> always meant "administrator-configurable"; it just
> accidentally came out
> "user-configurable" at some point because I wasn't thinking
> carefully about
> that distinction at the time.
>
> > Changing it to SHOULD/RECOMMENDED in REQ-7a
> > introduces a hidden recommendation that a NAT SHOULD implement both
> > filtering behaviors (so it can have an option configurable by the
> > admin) ... which is not what REQ-7 says. I support "MAY" in REQ-7a.
>
> That hidden recommendation that a NAT SHOULD implement both filtering
> behaviors is precisely the point.  I feel that if a NAT
> implements EF=A
> filtering (which is a problematic but reasonable security
> feature), then it
> SHOULD also provide a way for the NAT's administrator to turn
> that filtering
> feature off.  Since an EF=A NAT minus filtering effectively
> becomes an EF=I
> NAT, what we have is a NAT that is configurable for either
> EF=I or EF=A. 
> This will take an absurdly small amount of implementation
> effort by the NAT
> implementor - every NAT on the planet has a zillion
> configuration options
> already; this is just one more, and all it does is turn off a
> particular
> security feature that sometimes gets in the way of
> application connectivity. 
> Can you explain why it is unreasonable or undesirable for NAT
> vendors to be
> expected to provide this small but potentially important bit of
> configurability?
>
> Bryan
>
> > On Wed, 2005-06-01 at 09:25 -0400, Cullen Jennings wrote:
> > > > a) The filtering behavior SHOULD be a user configurable option.
> > >
> > > I could deal with this if we change to MAY but strongly object to
> > > the SHOULD. There are going to be devices where this is
> difficult.
> > > There are going to be devices that only support one type. In many
> > > case the administrator of the NAT is very different from
> the user of
> > > it. There is no reason why the WG should tell vendors how
> to build
> > > this. Having it as MAY or SHOULD does not change any
> > > interoperability issues between devices. Any standards
> body should
> > > focus on things that it needs to specify to ensure
> interoperability.
> > > Once vendors start down the slipper slope of not being fully
> > > compliant, pain and suffering will ensue - I'd rather avoid that.
> > > It's about as useful for the draft to say that all NAT
> user manuals
> > > SHOULD be in gender neutral language. It has no effect on
> > > interoperability. I can not see any good come it and I
> can see harm
> > > caused by it when key vendors that are not fully complaint start
> > > justifying why it is not useful to be fully complaint
> with BEHAVE. I
> > > know it sounds weird to care about this, but I would like
> to have a
> > > chance of getting the largest vendor of residential and corporate
> > > NATs to do this and this is not going to help.
> _______________________________________________
> Ietf-behave mailing list
> Ietf-behave <at> list.sipfoundry.org
> https://list.sipfoundry.org/mailman/listinfo/ietf-behave
>
>

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.