Subject: RE: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 25 May 2005 15:48:53 -0700 (PDT)

<FONT face=Arial color=#0000ff 
size=2>Cullen,
<FONT face=Arial color=#0000ff 
size=2> 
I'm 
not sure I agree that this sort of configuration option is beyond the ken of 
residential NAT users. I can imagine a very simple knob; users could choose 
between "more secure" and "more compatible" with a little explanatory text 
saying that some peer-to-peer applications won't work in the "more secure" mode. 
Residential NATs, including those coming from Linksys, already have many screens 
worth of configuration information, many options for port filtering, forwarding, 
and so on.
<FONT face=Arial color=#0000ff 
size=2> 
I do 
agree that it would be preferable if we could all agree on a default behavior, 
but realistically, I don't see us arriving at a consensus on this matter. 
I am persuaded by the argument that some applications will break in the 
face of address-dependent filtering, but I also believe address-independent 
filtering weakens security. I really have a hard time seeing how we can 
expect to deal with the fact that sometimes users want more security, and 
sometimes they want more compatibility, without suggesting that we make these 
configurable options. The best situation for applications and end users 
seems to be one in whch end users are empowered to make the 
choice.
<FONT face=Arial color=#0000ff 
size=2> 
Jon 
Peterson
<FONT face=Arial color=#0000ff 
size=2>NeuStar, Inc.
<BLOCKQUOTE 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid">
  <FONT face=Tahoma 
  size=2>-----Original Message-----From: Cullen Jennings 
  [mailto:fluffy@xxxxxxxxx]Sent: Tuesday, May 24, 2005 6:33 
  PMTo: Francois Audet; Peterson, Jon; BehaveSubject: Re: 
  [Ietf-behave] comments on 
  draft-ietf-behave-nat-udp-01<FONT 
  face="Verdana, Helvetica, Arial">I can't 
  imagine how to explain to a residential NAT user what these options even mean 
  much less how they should or would configure them. The high end enterprise 
  firewalls already have many configuration options for filtering.  I don't 
  think the important thing for this group is what NATs can be configured to do 
  or not do - I'm fine if someone wants to make a configurable NAT. The issues 
  this group needs to tackle is what is the minimal behavior that an application 
  can count on getting. If we say the NAT MAY do A or may do B, then that is 
  fine, the application can't assume that it is A or B but can assume it is one 
  or the other. Statements about the default configuration SHOULD be B won't 
  help the application. I strongly object to anything that says the 
  "Endpoint-Independent Filtering SHOULD be the default." - For the Linksys 
  devices, they will basically never be change from the default. All the 
  discussion on this list has led me to feel that the best thing for Linksys to 
  do is more restrictive filtering. I have not meant a single person at Linksys 
  that believes this is a good idea. I can not imagine a single combined 
  firewall NAT what would ship with this as the default. I'm pretty sure the 
  Cisco ones won't. I imagine the feeling will be similar at other NAT and FW 
  manufactures. I think that including this statement will more or less 
  guarantee that over 90% of devices shipped do not comply with this 
  recommendation. The obvious solution to this lack of agreement is say 
  that NATs can MAY choose any type of filtering configuration and MAY be 
  configurable. Or perhaps people want to say that they MUST not be address port 
  filtering (though I'm OK if they are). Cullen <not as 
  chair>On 5/24/05 9:33 AM, "Francois Audet" <audet@xxxxxxxxxx> 
  wrote:
  <FONT 
    face=Arial>So you prefer this:
    <FONT 
      face="Verdana, Helvetica, Arial">REQ-7: NATs SHOULD support 
      Endpoint-Independent Filtering, Address-Specific Filtering, and 
       Endpoint-Specific Filtering, as options  configurable by the 
      user. Endpoint-Independent Filtering SHOULD be the 
      default.<FONT 
    face="Verdana, Helvetica, Arial"><FONT 
    face=Arial>I'm fine with this too.<FONT 
    face="Verdana, Helvetica, Arial"><FONT 
    face=Arial>I'm assuming that you are OK with the 
    rest?
    <FONT 
      face="Verdana, Helvetica, Arial"> <FONT 
      face=Tahoma>-----Original Message-----From: Peterson, Jon 
       [<A 
      href="mailto:jon.peterson@xxxxxxxxxxx]">mailto:jon.peterson@xxxxxxxxxxx] 
      Sent: Tuesday, May 24, 2005  01:50To: Audet, 
      Francois [SC100:9T51:EXCH];  BehaveSubject: RE: 
      [Ietf-behave] comments on 
       draft-ietf-behave-nat-udp-01<FONT 
      face="Verdana, Helvetica, Arial">  <FONT 
      color=#0000ff>Regarding just the REQ-7 text, I do think 
      Bryan's suggestion has some  merit. These requirements are intended 
      to constrain NAT implementers, not the  deployers of NATs. The 
      implementers of NATs cannot anticipate what  sort of filtering will 
      be desired; that is something that deployers of NATs  should be able 
      to configure.<FONT 
      face="Verdana, Helvetica, Arial">  <FONT 
      color=#0000ff>Jon  Peterson<FONT 
      face="Verdana, Helvetica, Arial"><FONT 
      face=Arial>NeuStar, Inc.<FONT 
      face="Verdana, Helvetica, Arial">
      <FONT 
        face="Verdana, Helvetica, Arial"><FONT 
        face=Tahoma>-----Original Message-----From: 
         ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx  [<A 
        href="mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx]">mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx]On 
        Behalf Of Francois  AudetSent: Monday, May 23, 2005 
        11:00 AMTo:  'Behave'Subject: RE: 
        [Ietf-behave] comments on 
         draft-ietf-behave-nat-udp-01<FONT 
        face="Verdana, Helvetica, Arial">Thanks to all, 
         This is a formal proposal on how to move forward, with 
         concrete text.  ------------------------ 
         How about this for REQ 7.  In the 
        Requirements section:  REQ-7: In order to maximize 
        application transparencyIt 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.  In the REQ-7 
        justification section would be modified as  follows: 
         REQ-7: The recommendation to use endpoint independent 
         filtering is aimed at 
               maximizing feature 
        transparency,  in particular for applications that 
               receive media 
        simultaneously  from multiple locations (e.g., gaming), 
               or applications that use 
         rendezvous techniques. However, it is also 
               possible that in some 
         circumstances, it may be preferable to have 
               a more stringent filtering 
         behavior. Filtering independently of the 
               external endpoint is not 
        as  secure: an unauthorized packet could get 
               a specific port while the 
        port  was kept open if ti was lucky enough 
               to find the port open. In 
         theory, filtering based on both IP address 
               and port is more secure 
        than  filtering based only on the IP address 
               (because the external 
        endpoint  could in reality be two endpoints behind 
               another NAT, where one of 
        the  two endpoints is an attacker): however, such 
               a policy could infere with 
         applications that use one than one port.  I'd 
        like a Yay or Nay on the text above. 
         ---------------------  Wordy 
        terminology:   As for the  wordy terminology for some 
        of the names of behaviors, I also agree    (the 
        reasons for wordy names are historical). I can  go through the text 
        and simplify.  ------------------------ 
         REQs in-line:   Bryan feels 
         strongly about copying/pasting the REQs from section 12 in-line in 
         the   text as they occur, to help the reader. I 
         personally think it is a reasonable 
           suggestion. Is there any STRONG objection to this? 
        (Cullen in particular,  I'd like to   hear from you). 
         ------------------------- 
         Determinism:   I propose that  to 
        address Bryan's concern, I put a note in section 4.1 and 5.1 
           refering to the Deterministic behavior section. I 
         also propose to change the first   sentence of 
         section 8 to the following:     The 
         classification of NATs is further complicated by the fact that 
        under  some     conditions the same NAT 
         often exhibits different behaviors, especially for 
            mapping and filtering. 
         -------------------------  Again, I'd 
        like a Yay or Nay from people on the points  above. 
         > -----Original Message----- > 
         From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx >  [<A 
        href="mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx]">mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] 
         On Behalf Of > Peterson, Jon > Sent: Friday, May 20, 
        2005 16:48 >  To: Behave > Subject: [Ietf-behave] 
        comments on  draft-ietf-behave-nat-udp-01 > > 
        > > In  light of the recent Last Call discussions 
        about >  behave-nat-udp, I wanted to make a few comments. 
        > > Regarding REQ-7, it seems pretty  clear to me 
        that there is no > immediate  consensus to endorse 
        endpoint-dependent or >  endpoint-independent filtering. 
        Consequently, in the interest  > of time I'd like to make 
        the modest proposal  that REQ-7 > endorse neither, but 
        instead state  that both these modes (and > address-specific 
         filtering) should be supported. Is there > some 
         advantage to privileging one over the other? > 
         > I see no great need to specify the maximum  datagram 
        length > that NATs must process.  > > I find 
        the conceptual  model of behave-nat-udp, which focuses > on 
         functions NATs might perform rather than classifications > 
        of NATs as particular taxonomic entities (Basic, Full Cone, 
         > etc), to be very attractive. That much said, I  do 
        agree with > several commentators that the  resulting 
        functional > descriptions lead to some  very wordy 
        terminologies. There > seems to be  some emerging agreement 
        on shorter terms, and I >  think that would be most welcome 
        to readers. >  > Regarding the terms used in 
        behave-nat-udp  versus > ford-behave-gen, I see no immediate 
         problems with the terms > used in behave-nat-udp.  The 
        distinction between a "map", a > "binding"  and a "NAT 
        session" in ford-behave-gen makes me a > little dizzy, to be 
        honest. I do not find the definition of  > "mapping" in 
        behave-nat-udp to be problematic.  I don't find > the use of 
        the term "session" to  refer to a transport-layer > 
        connection between  two endpoints to be problematic. > 
        Terminology  can be endlessly debated, but it is not clear to 
        > me that we will gain much leverage on our problem space by 
         > spending a few more cycles refining these  terms. 
        > > In Section  4.1, I think it reasonable to define 
        behaviors >  such as "External NAT mapping is endpoint 
        address dependent"  > just in order to disallow them in the 
         requirements section. I > think it is worth being 
         specific about things that we don't > want 
         implementers to do. > > Given the conceptual model 
        of behave-nat-udp, I think the  > distinction between 
        "deterministic" and  "non-deterministic" > NATs in Section 8 
        is  valuable. In fact, I think this > non-determinism 
         is one of the primary grounds to move away > from  a 
        taxonomic model of NATs and into the functional model > espoused 
        by behave-nat-udp. I didn't find Section 8 to be  > 
        particularly obscure when I read it, though no  doubt the text 
        > could be made more  focused. > > Jon 
         Peterson > NeuStar, Inc. > > 
         _______________________________________________ > 
         Ietf-behave mailing list > 
         Ietf-behave@xxxxxxxxxxxxxxxxxxx > 
        https://list.sipfoundry.org/mailman/listinfo/ietf-behave  > 
        > <SPAN 
    style="FONT-SIZE: 12px">
    
    <SPAN 
    style="FONT-SIZE: 10px">_______________________________________________Ietf-behave 
    mailing 
    listIetf-behave@xxxxxxxxxxxxxxxxxxxhttps://list.sipfoundry.org/mailman/listinfo/ietf-behave<FONT 
  size=2><SPAN 
style="FONT-SIZE: 10px">

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 25 May 2005 19:19:24 -0700 (PDT)

I think we are 99% in agreement. Yes, end users should have the choice to buy a NAT that does A, a NAT that does B, or a NAT that is configurable to do A or B and all three of these choices should be an BEHAVE compliant NAT. I'm totally great with that.  But when we start discussing what the user interfaces for wizards to configure NATs look like we are way off the right path. I'll even encourage vendors to make NATs configurable but telling them the the default has to be full cone is just a good way to ensure that there are no BEHAVE compliant NATs. So I am also in agreement with you on we are not going to agree on what the default behavior should be. 

I think we should go with the proposal Francois send out earlier today. 

Cullen <not as chair> 

On 5/25/05 3:48 PM, "Peterson, Jon" <jon.peterson@xxxxxxxxxxx> wrote:

Cullen,
 
I'm not sure I agree that this sort of configuration option is beyond the ken of residential NAT users. I can imagine a very simple knob; users could choose between "more secure" and "more compatible" with a little explanatory text saying that some peer-to-peer applications won't work in the "more secure" mode. Residential NATs, including those coming from Linksys, already have many screens worth of configuration information, many options for port filtering, forwarding, and so on.
 
I do agree that it would be preferable if we could all agree on a default behavior, but realistically, I don't see us arriving at a consensus on this matter. I am persuaded by the argument that some applications will break in the face of address-dependent filtering, but I also believe address-independent filtering weakens security. I really have a hard time seeing how we can expect to deal with the fact that sometimes users want more security, and sometimes they want more compatibility, without suggesting that we make these configurable options. The best situation for applications and end users seems to be one in whch end users are empowered to make the choice.
 
Jon Peterson
NeuStar, Inc.
 
-----Original Message-----
From: Cullen Jennings  [mailto:fluffy@xxxxxxxxx]
Sent: Tuesday, May 24, 2005 6:33  PM
To: Francois Audet; Peterson, Jon; Behave
Subject: Re:  [Ietf-behave] comments on  draft-ietf-behave-nat-udp-01

I can't  imagine how to explain to a residential NAT user what these options even mean  much less how they should or would configure them. The high end enterprise  firewalls already have many configuration options for filtering.  I don't  think the important thing for this group is what NATs can be configured to do  or not do - I'm fine if someone wants to make a configurable NAT. The issues  this group needs to tackle is what is the minimal behavior that an application  can count on getting. If we say the NAT MAY do A or may do B, then that is  fine, the application can't assume that it is A or B but can assume it is one  or the other. Statements about the default configuration SHOULD be B won't  help the application. 

I strongly object to anything that says the  "Endpoint-Independent Filtering SHOULD be the default." - For the Linksys  devices, they will basically never be change from the default. All the  discussion on this list has led me to feel that the best thing for Linksys to  do is more restrictive filtering. I have not meant a single person at Linksys  that believes this is a good idea. I can not imagine a single combined  firewall NAT what would ship with this as the default. I'm pretty sure the  Cisco ones won't. I imagine the feeling will be similar at other NAT and FW  manufactures. I think that including this statement will more or less  guarantee that over 90% of devices shipped do not comply with this  recommendation. 

The obvious solution to this lack of agreement is say  that NATs can MAY choose any type of filtering configuration and MAY be  configurable. Or perhaps people want to say that they MUST not be address port  filtering (though I'm OK if they are). 

Cullen <not as  chair>

On 5/24/05 9:33 AM, "Francois Audet" <audet@xxxxxxxxxx>  wrote:

So you prefer this:

REQ-7: NATs SHOULD support  Endpoint-Independent Filtering, Address-Specific Filtering, and   Endpoint-Specific Filtering, as options  configurable by the  user. Endpoint-Independent Filtering SHOULD be the  default.

I'm fine with this too.

I'm assuming that you are OK with the  rest?

-----Original Message-----
From: Peterson, Jon   [mailto:jon.peterson@xxxxxxxxxxx]  
Sent: Tuesday, May 24, 2005  01:50
To: Audet,  Francois [SC100:9T51:EXCH];  Behave
Subject: RE:  [Ietf-behave] comments on   draft-ietf-behave-nat-udp-01

 
Regarding just the REQ-7 text, I do think  Bryan's suggestion has some  merit. These requirements are intended  to constrain NAT implementers, not the  deployers of NATs. The  implementers of NATs cannot anticipate what  sort of filtering will  be desired; that is something that deployers of NATs  should be able  to configure.

Jon  Peterson

NeuStar, Inc.

-----Original Message-----
From:   ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx  [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx]On  Behalf Of Francois  Audet
Sent: Monday, May 23, 2005  11:00 AM
To:  'Behave'
Subject: RE:  [Ietf-behave] comments on   draft-ietf-behave-nat-udp-01

Thanks to all,  

This is a formal proposal on how to move forward, with   concrete text. 

------------------------  

How about this for REQ 7. 

In the  Requirements section: 

REQ-7: In order to maximize  application transparencyIt 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. 

In the REQ-7  justification section would be modified as  follows:  

REQ-7: The recommendation to use endpoint independent   filtering is aimed at  
       maximizing feature  transparency,  in particular for applications that  
       receive media  simultaneously  from multiple locations (e.g., gaming),  
       or applications that use   rendezvous techniques. However, it is also  
       possible that in some   circumstances, it may be preferable to have  
       a more stringent filtering   behavior. Filtering independently of the  
       external endpoint is not  as  secure: an unauthorized packet could get  
       a specific port while the  port  was kept open if ti was lucky enough  
       to find the port open. In   theory, filtering based on both IP address  
       and port is more secure  than  filtering based only on the IP address  
       (because the external  endpoint  could in reality be two endpoints behind  
       another NAT, where one of  the  two endpoints is an attacker): however, such  
       a policy could infere with   applications that use one than one port. 

I'd  like a Yay or Nay on the text above.  

--------------------- 

Wordy  terminology: 
  As for the  wordy terminology for some  of the names of behaviors, I also agree  
  (the  reasons for wordy names are historical). I can  go through the text  and simplify. 

------------------------  

REQs in-line: 
  Bryan feels   strongly about copying/pasting the REQs from section 12 in-line in   the 
  text as they occur, to help the reader. I   personally think it is a reasonable  
   suggestion. Is there any STRONG objection to this?  (Cullen in particular,  I'd like to 
  hear from you).  

Determinism: 
  I propose that  to  address Bryan's concern, I put a note in section 4.1 and 5.1   
  refering to the Deterministic behavior section. I   also propose to change the first 
  sentence of   section 8 to the following: 
    The   classification of NATs is further complicated by the fact that  under  some 
    conditions the same NAT   often exhibits different behaviors, especially for  
    mapping and filtering.  

Again, I'd  like a Yay or Nay from people on the points  above.  

> -----Original Message----- 
>   From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx 
>  [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx]   On Behalf Of 
> Peterson, Jon 
> Sent: Friday, May 20,  2005 16:48 
>  To: Behave 
> Subject: [Ietf-behave]  comments on  draft-ietf-behave-nat-udp-01 
> 
>  
> 
> In  light of the recent Last Call discussions  about 
>  behave-nat-udp, I wanted to make a few comments.  
> 
> Regarding REQ-7, it seems pretty  clear to me  that there is no 
> immediate  consensus to endorse  endpoint-dependent or 
>  endpoint-independent filtering.  Consequently, in the interest  
> of time I'd like to make  the modest proposal  that REQ-7 
> endorse neither, but  instead state  that both these modes (and 
> address-specific   filtering) should be supported. Is there 
> some   advantage to privileging one over the other? 
>   
> I see no great need to specify the maximum  datagram  length 
> that NATs must process.  
> 
> I find  the conceptual  model of behave-nat-udp, which focuses 
> on   functions NATs might perform rather than classifications 
> etc), to be very attractive. That much said, I  do  agree with 
> several commentators that the  resulting  functional 
> descriptions lead to some  very wordy  terminologies. There 
> seems to be  some emerging agreement  on shorter terms, and I 
>  think that would be most welcome  to readers. 
>  
> Regarding the terms used in  behave-nat-udp  versus 
> ford-behave-gen, I see no immediate   problems with the terms 
> used in behave-nat-udp.  The  distinction between a "map", a 
> "binding"  and a "NAT  session" in ford-behave-gen makes me a 
> little dizzy, to be  honest. I do not find the definition of  
> "mapping" in  behave-nat-udp to be problematic.  I don't find 
> the use of  the term "session" to  refer to a transport-layer 
>  connection between  two endpoints to be problematic. 
> spending a few more cycles refining these  terms.  
> 
> In Section  4.1, I think it reasonable to define  behaviors 
>  such as "External NAT mapping is endpoint  address dependent"  
> just in order to disallow them in the   requirements section. I 
> think it is worth being   specific about things that we don't 
> want   implementers to do. 
> 
> Given the conceptual model  of behave-nat-udp, I think the  
> distinction between  "deterministic" and  "non-deterministic" 
> NATs in Section 8  is  valuable. In fact, I think this 
> non-determinism   is one of the primary grounds to move away 
> from  a  taxonomic model of NATs and into the functional model 
> espoused  by behave-nat-udp. I didn't find Section 8 to be  
> could be made more  focused. 
> 
> Jon   Peterson 
> NeuStar, Inc. 
> 
>   _______________________________________________ 
>   Ietf-behave mailing list 
>   Ietf-behave@xxxxxxxxxxxxxxxxxxx 
>  https://list.sipfoundry.org/mailman/listinfo/ietf-behave  
>  
> 

 _______________________________________________
Ietf-behave  mailing  list
Ietf-behave@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/ietf-behave

---

From: Bryan Ford <[email-masked]>
Date: Thu, 26 May 2005 08:25:21 -0700 (PDT)

On Wednesday 25 May 2005 22:19, Cullen Jennings wrote:
> I think we are 99% in agreement. Yes, end users should have the choice to
> buy a NAT that does A, a NAT that does B, or a NAT that is configurable to
> do A or B and all three of these choices should be an BEHAVE compliant NAT.

I feel very strongly that when it comes to firewalling options incidental to 
the basic NAT function, users should be able to EXPECT that any NAT they buy 
off the shelf will be configurable to do A (Endpoint-Independent Filtering) 
or B (Address-Dependent Filtering), and that the "out-of-the-box" default 
behavior should be one that offers the best security that can be provided 
without fundamentally limiting the application's Internet connectivity 
paradigm.  (Which Address-Dependent Filtering does, by making the application 
only a "second-class network citizen" always dependent on well-known servers 
for all its connectivity).

I fail to see how it is too much to ask vendors to implement both options, 
especially given that you get Endpoint-Independent Filtering from 
Address-Specific Filtering simply by turning off the check on new inbound 
sessions to existing bindings.  We're talking an absolutely trivial 
implementation cost here.

> I'm totally great with that.  But when we start discussing what the user
> interfaces for wizards to configure NATs look like we are way off the right
> path.

Please re-read this part of my earlier message:

> > [Bryan]
> > I'm not suggesting we tell NAT vendors how they should design their user 
> > interfaces or present potential configuration options to the user; I only 
> > presented the above example to illustrate the fact that there _are_ 
> > reasonable ways to make such configuration options accessible even to 
> > unsophisticated users.

You were the one who brought up the topic of "user interfaces ... to configure 
NATs" when you said, "I can't imagine how to explain to a residential NAT 
user what these options even mean much less how they should or would 
configure them."  I was providing an illustrative example to answer your 
question, that's all, and I made that very clear.  Taking my illustrative 
example as the basis to make the claim that "we are way off the right path" 
is totally unfair.

> [Cullen again]
> I'll even encourage vendors to make NATs configurable but telling 
> them the the default has to be full cone is just a good way to ensure that
> there are no BEHAVE compliant NATs. So I am also in agreement with you on
> we are not going to agree on what the default behavior should be.

The key word you're somehow missing is "should".  Please re-read the actual 
proposed text:

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.

Notice that there are no MUSTs here, only a SHOULD and a RECOMMENDED.  With 
the above text, NAT vendors are perfectly permitted to ignore the above 
recommendations and still produce a NAT that they can legitimately call 
BEHAVE-compliant.  The suggested recommendations are there to make it clear 
that Endpoint-Independent Filtering behavior provides the closest thing to 
the full connectivity model the Internet was originally designed to 
implement, and as such should be held up as a standard to be deviated from 
only when there are overriding security concerns.  The text above uses 
SHOULDs instead of MUSTs precisely _because_ we recognize that there are 
sometimes overriding security concerns that warrant deviation from the ideal 
of unrestricted connectivity; nevertheless, the existence of those concerns 
should not prevent us from promoting full connectivity as the standard.

Bryan

---

From: Pyda Srisuresh <[email-masked]>
Date: Thu, 26 May 2005 09:01:42 -0700 (PDT)

Cullen,

you argue that residential NAT vendors will refuse to go with endpoint
independent filtering behavior. You say that as a representive of the Linksys
group within Cisco. You also say that configuration is not an option for
residential NAT vendors such as Linksys. So, how is this a 99% in agreement
with Jon who, I believe, is suggesting a configurable option even for
residential NAT  vendors?

cheers,
suresh

--- Cullen Jennings <fluffy@xxxxxxxxx> wrote:

> path. I'll even encourage vendors to make NATs configurable but telling them
> the the default has to be full cone is just a good way to ensure that there
> are no BEHAVE compliant NATs. So I am also in agreement with you on we are
> not going to agree on what the default behavior should be.
> 
> > I'm not sure I agree that this sort of configuration option is beyond the
> ken
> > of residential NAT users. I can imagine a very simple knob; users could
> choose
> > saying that some peer-to-peer applications won't work in the "more secure"
> > mode. Residential NATs, including those coming from Linksys, already have
> many
> > screens worth of configuration information, many options for port
> filtering,
> > forwarding, and so on.
> >  
> > I do agree that it would be preferable if we could all agree on a default
> > behavior, but realistically, I don't see us arriving at a consensus on this
> > matter. I am persuaded by the argument that some applications will break in
> > the face of address-dependent filtering, but I also believe
> > address-independent filtering weakens security. I really have a hard time
> > seeing how we can expect to deal with the fact that sometimes users want
> more
> > security, and sometimes they want more compatibility, without suggesting
> that
> > we make these configurable options. The best situation for applications and
> > end users seems to be one in whch end users are empowered to make the
> choice.
> >  
> > Jon Peterson
> > NeuStar, Inc.
> >>  
> >> I can't  imagine how to explain to a residential NAT user what these
> options
> >> even mean  much less how they should or would configure them. The high end
> >> enterprise  firewalls already have many configuration options for
> filtering.
> >> I don't  think the important thing for this group is what NATs can be
> >> configured to do  or not do - I'm fine if someone wants to make a
> >> configurable NAT. The issues  this group needs to tackle is what is the
> >> minimal behavior that an application  can count on getting. If we say the
> NAT
> >> MAY do A or may do B, then that is  fine, the application can't assume
> that
> >> it is A or B but can assume it is one  or the other. Statements about the
> >> default configuration SHOULD be B won't  help the application.
> >> 
> >> I strongly object to anything that says the  "Endpoint-Independent
> Filtering
> >> SHOULD be the default." - For the Linksys  devices, they will basically
> never
> >> be change from the default. All the  discussion on this list has led me to
> >> feel that the best thing for Linksys to  do is more restrictive filtering.
> I
> >> have not meant a single person at Linksys  that believes this is a good
> idea.
> >> I can not imagine a single combined  firewall NAT what would ship with
> this
> >> as the default. I'm pretty sure the  Cisco ones won't. I imagine the
> feeling
> >> will be similar at other NAT and FW  manufactures. I think that including
> >> this statement will more or less  guarantee that over 90% of devices
> shipped
> >> do not comply with this  recommendation.
> >> 
> >> The obvious solution to this lack of agreement is say  that NATs can MAY
> >> choose any type of filtering configuration and MAY be  configurable. Or
> >> perhaps people want to say that they MUST not be address port  filtering
> >> (though I'm OK if they are).
> >> 
> >> Cullen <not as  chair>
> >> 
> >>>> REQ-7: NATs SHOULD support  Endpoint-Independent Filtering,
> >>>> Address-Specific Filtering, and   Endpoint-Specific Filtering, as
> options
> >>>> configurable by the  user. Endpoint-Independent Filtering SHOULD be the
> >>>> default.
> >>> 
> >>> I'm fine with this too.
> >>> 
> >>>> Regarding just the REQ-7 text, I do think  Bryan's suggestion has some
> >>>> merit. These requirements are intended  to constrain NAT implementers,
> not
> >>>> the  deployers of NATs. The  implementers of NATs cannot anticipate what
> >>>> sort of filtering will  be desired; that is something that deployers of
> >>>> NATs  should be able  to configure.
> >>>> 
> >>>>  
> >>>>  
> >>>> Jon  Peterson
> >>>> 
> >>>> NeuStar, Inc.
> >>>> 
> >>>>  
> >>>>> 
> >>>>> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx]On  Behalf Of Francois
> >>>>> Audet
> >>>>> REQ-7: The recommendation to use endpoint independent   filtering is
> aimed
> >>>>> at  
> >>>>>        maximizing feature  transparency,  in particular for
> applications
> >>>>> that  
> >>>>>        a more stringent filtering   behavior. Filtering independently
> of
> >>>>> the  
> >>>>>        external endpoint is not  as  secure: an unauthorized packet
> could
> >>>>> get  
> >>>>>        (because the external  endpoint  could in reality be two
> endpoints
> >>>>> behind  
> >>>>>   I propose that  to  address Bryan's concern, I put a note in section
> 4.1
> >>>>> and 5.1   
> >>>>>     The   classification of NATs is further complicated by the fact
> that
> >>>>> under  some

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 26 May 2005 09:33:21 -0700 (PDT)

On 5/26/05 8:25 AM, "Bryan Ford" <baford@xxxxxxx> wrote:

> BEHAVE-compliant.

Ah, I have found the heart of the problem. We don't agree on what SHOULD
means and vendors would like to be fully compliant. Tell you what, how about
we switch the SHOULD to a MAY and Francois has already proposed text that
tells the NAT vendor why this is a good idea.

You