Subject: [Ietf-behave] RE: draft-ietf-behave-nat-udp-01, REQ-7

From: "Francois Audet" <[email-masked]>
Date: Fri, 27 May 2005 11:14:29 -0700 (PDT)

You wording is starting to look like something I proposed a while ago...

I think the "configurable option" thing should be a sub-item (with a MAY).

So either my old wording:

REQ-7: In order to maximize application transparency, it is RECOMMENDED that 
       a NAT have an "Endpoint independent filtering" behavior. 
       If a more stringent filtering behavior is desired, it is RECOMMENDED 
       that a NAT have an "Address dependent" behavior. 

         a) The filtering behavior MAY be a user configurable option.

or your wording:

REQ-7: NATs SHOULD support Endpoint Independent Filtering and Address
       Dependent Filtering, and MAY support Address and Port Dependent
       Filtering. It is RECOMMENDED that Endpoint Independent Filtering 
       be the default, unless the NAT is designed primarily as a firewall 
       for which security concerns take precedence over concerns of 
       connectivity or compatibility.

         b) The filtering behavior MAY be a user configurable option.

> -----Original Message-----
> From: Bryan Ford [mailto:baford@xxxxxxx] 
> Sent: Friday, May 27, 2005 03:29
> To: Audet, Francois [SC100:9T51:EXCH]
> Cc: 'Cullen Jennings'; 'Behave'; 'Jon Peterson'
> Subject: Re: draft-ietf-behave-nat-udp-01, REQ-7
> 
> 
> On Thursday 26 May 2005 13:25, Francois Audet wrote:
> > Bryan,
> >
> > Would you agree with this proposal?
> 
> I assume the proposal is this:
> 
> > REQ-7: Favored by Cullen (as co-author, not chair), and maybe others
> >
> >         A NAT should support Endpoint Independent Filtering
> >         or Address and Port Dependent Filtering.
> 
> No, I'm not OK with this, because it says nothing useful.  I 
> feel very 
> strongly that it is not unreasonable, and it may be highly 
> beneficial to the 
> long-term health of the Internet:
> 
> (a) to ask NAT vendors to allow users to disable 
> connectivity-limiting 
> firewall functionality - i.e., make the behavior configurable 
> - unless there 
> is some specific overriding concern that dictates the NAT be 
> non-configurable.
> 
> (b) to affirm "full first-class connectivity" as the norm for 
> the Internet 
> unless there are overriding security concerns that dictate otherwise.
> 
> I do sympathize with Cullen's (and your) concerns about 
> potential vendor 
> resistance, but that's why these are soft recommendations 
> rather than hard 
> requirements.  I cannot see the harm it will do to show a 
> little backbone and 
> stick up for preserving the basic connectivity principles the 
> Internet was 
> built on.  The vendors will make the final decision anyway; 
> the least we can 
> do is ask them to think about it.
> 
> In light of the concerns over potential vendor resistance to 
> recommendation 
> (b) above (I frankly don't see much resistance to (a) being 
> likely), I offer 
> the following counter-proposal, which makes it more explicit 
> that there can 
> be legitimate reasons to go against that recommendation:
> 
> REQ-7:
>          NATs SHOULD support Endpoint Independent Filtering 
> and Address
>          Dependent Filtering, and MAY support Address and 
> Port Dependent
>          Filtering, as options configurable by the user. It 
> is RECOMMENDED
>          that Endpoint Independent Filtering be the default, 
> unless the NAT
>          is designed primarily as a firewall for which 
> security concerns
>          take precedence over concerns of connectivity or 
> compatibility.
> 
> Would this text answer your objections, Cullen?
> 
> Cheers,
> Bryan
> 
>

---

From: Bryan Ford <[email-masked]>
Date: Fri, 27 May 2005 11:34:44 -0700 (PDT)

>        b) The filtering behavior MAY be a user configurable option.

I prefer the more explicit wording of the latter, but I could live with the 
following two-word modification to your version:

REQ-7:
        In order to maximize application transparency, it is RECOMMENDED that
        a NAT have an "Endpoint independent filtering" behavior.
        If a more stringent filtering behavior is required, it is RECOMMENDED
        that a NAT have an "Address dependent" behavior.

         a) The filtering behavior SHOULD be a user configurable option.

Change 1: "desired" -> "required" in the main recommendation.

Change 2: "MAY" -> "SHOULD" in the sub-point.  Using "MAY" here makes the 
recommendation completely vacuous; it's trivially and obviously the case that 
for any behavior we leave to the discretion of the NAT designer, they MAY 
(are free to) make it user-configurable if they want to.  The crucial point 
here is that vendors SHOULD (be encouraged to) make it configurable.

And I would still like the proposed text (or some variation of it) to be added 
to the "Security Considerations" section, with a forward reference from the 
REQ-7 justification text.

Is this acceptable?

Cheers,
Bryan