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

From: "Francois Audet" <[email-masked]>
Date: Tue, 24 May 2005 09:34:01 -0700 (PDT)

So you 
prefer this:

  REQ-7: NATs SHOULD support Endpoint-Independent<SPAN 
  class=686262816-24052005> Filtering, Address-Specific Filtering, and 
  Endpoint-Specific Filtering, as options 
  configurable by the user. <FONT 
  size=2>Endpoint-Independent Filtering SHOULD be the 
default.
I'm fine 
with this too.
I'm 
assuming that you are OK with the rest?
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #800000 2px solid; MARGIN-RIGHT: 0px">
  
  <FONT 
  face=Tahoma size=2>-----Original Message-----From: Peterson, Jon 
  [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=Arial color=#0000ff 
  size=2>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=Arial color=#0000ff 
  size=2> 
  Jon 
  Peterson
  <FONT face=Arial color=#0000ff 
  size=2>NeuStar, Inc.
  <BLOCKQUOTE dir=ltr 
  style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
    <FONT face=Tahoma 
    size=2>-----Original Message-----From: 
    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
    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 <FONT 
    size=2>       a NAT have an "Endpoint 
    independent filtering" behavior. <FONT 
    size=2>       If a more stringent filtering 
    behavior is desired, it is RECOMMENDED <FONT 
    size=2>       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 <FONT 
    size=2>       maximizing feature transparency, 
    in particular for applications that <FONT 
    size=2>       receive media simultaneously 
    from multiple locations (e.g., gaming), <FONT 
    size=2>       or applications that use 
    rendezvous techniques. However, it is also <FONT 
    size=2>       possible that in some 
    circumstances, it may be preferable to have <FONT 
    size=2>       a more stringent filtering 
    behavior. Filtering independently of the <FONT 
    size=2>       external endpoint is not as 
    secure: an unauthorized packet could get <FONT 
    size=2>       a specific port while the port 
    was kept open if ti was lucky enough <FONT 
    size=2>       to find the port open. In 
    theory, filtering based on both IP address <FONT 
    size=2>       and port is more secure than 
    filtering based only on the IP address <FONT 
    size=2>       (because the external endpoint 
    could in reality be two endpoints behind <FONT 
    size=2>       another NAT, where one of the 
    two endpoints is an attacker): however, such <FONT 
    size=2>       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 <FONT 
    size=2>    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 <FONT 
    size=2>> Sent: Friday, May 20, 2005 16:48 > 
    To: Behave > Subject: [Ietf-behave] comments on 
    draft-ietf-behave-nat-udp-01 > <FONT 
    size=2>> > > In 
    light of the recent Last Call discussions about > 
    behave-nat-udp, I wanted to make a few comments. <FONT 
    size=2>> > 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 <FONT 
    size=2>> 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 <FONT 
    size=2>> 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 <FONT 
    size=2>> 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. > <FONT 
    size=2>> 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 <FONT 
    size=2>> 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. <FONT 
    size=2>> > 
    _______________________________________________ > 
    Ietf-behave mailing list > 
    Ietf-behave@xxxxxxxxxxxxxxxxxxx > <A 
    href="https://list.sipfoundry.org/mailman/listinfo/ietf-behave" 
    target=_blank>https://list.sipfoundry.org/mailman/listinfo/ietf-behave

---

From: Bryan Ford <[email-masked]>
Date: Tue, 24 May 2005 14:03:48 -0700 (PDT)

On Tuesday 24 May 2005 12:33, Francois Audet wrote (in response to Jon 
Peterson's message):
> 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.

Excellent - thanks.  One more minor note: although the text above that I 
suggested recommends that NATs support all three filtering behaviors, I don't 
have any strong attachment to the third, most restrictive behavior - 
"Endpoint-Specific Filtering" - and as far as I can tell no one else on this 
list really appears to either.  So I would like to suggest the following 
minor alteration, which would weaken that part of the recommendation (while 
keeping it as an allowable implementation option):

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

But I don't have strong feelings either way on this point; either of the above 
two versions of REQ-7 are fine with me.

Thanks,
Bryan

>
> 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
> 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.
>
> ------------------------
>
> 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.
>
> 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
> 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
>
> <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
> > 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
> > 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
>
> <https://list.sipfoundry.org/mailman/listinfo/ietf-behave>

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 24 May 2005 18:33:13 -0700 (PDT)

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.

-----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, 

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

       (because the external endpoint  could in reality be two endpoints behind 
       another NAT, where one of the  two endpoints is an attacker): however, such 

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

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. 

>  [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx]  On Behalf Of 
> Peterson, Jon

---

From: Pyda Srisuresh <[email-masked]>
Date: Wed, 25 May 2005 09:25:07 -0700 (PDT)

Whatever conclusion we come to, I believe the draft ought to include the
rationale behind. Without the raionale, the reader who looks at the RFC two
years from now will be at a loss as to why the requirement was made the way it
was. My comments inline.

cheers,
suresh

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

> 
> 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. 

[suresh] Agreed. 

>                                                            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." - 

[suresh] I am OK with requiring the default behavior to be one of endpoint
Address dependent filtering (i.e, Addres restricted Cone NAT behavior) or
endpoint independent filtering (i.e., full COne NAT behavior). In the case of
the former. it would be nice if the NAT could selectively enable endpoint
independent filtering (i.e., Full Cone NAT behavior) for specific applications
(such as peer-to-peer applications).

>                           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.

[suresh] You meant the opposite right. Endpoint independent (i.e., Full-Cone
NAT behavior) is less restrictive.

>                                                                          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.
> 
[suresh] I do not buy the above argument. NAT vendors, especially the vendors
that supply to residential customers have catered predominantly to
client-server applications thus far. Peer-to-peer application support has not
been a priority. As more residential customers are seeking peer-to-peer
application support on their NAT devices, the NAT vendors will change the tune
according to the market needs.

As Bryan said, the argument that Full Cone NAT behavior is less secure is
rather weak. Once a host initiated a UDP based application, the application
should be prepared to receive UDP datagrams from any IP address out there and
drop datagrams that it does not care for. That is how it is with the Internet
without NATs. The behavior ought not to be any different by virtue of keepign
the NATs. I doubt if there are any applicatiosn out there that assume a NAT and
depend on NATs to provide the Address restricted filtering behavior to them.

Cullen - Is there a specific concern why Linksys would want to refuse to
provide endpoint independent filterign behavior as the default? That would be
useful in bringing the discussion to a close.

> 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>
> 

cheers,
suresh
> 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.
> >>  
> >>>  
> Audet

---

From: Bryan Ford <[email-masked]>
Date: Wed, 25 May 2005 10:33:09 -0700 (PDT)

On Tuesday 24 May 2005 21:33, Cullen Jennings wrote:
> even mean much less how they should or would configure them.

I can - it doesn't need to involve explaining the minute technical details 
involved, just the fact that there is a security/connectivity tradeoff.  
Residental NAT/router vendors already typically provide an easy-to-use 
"configuration wizard" of some kind that walks the users through the process 
of configuring the upstream link, entering ISP account names/passwords, etc.  
It would be easy to include a page (some might already have one in fact) that 
looks something like this:

Configuration Wizard Step #: Security Level

        Some of the optional security features that your new
        LinkGear router provides may interfere with the
        functioning or connectivity of popular applications.
        You may choose to enable these features for maximum
        protection of your private network, or disable them
        to ensure maximum application compatibility while still
        providing strong protection for your private network.
        Click the "Advanced" button for more technical details
        or to configure individual security features.

        Security Level:
          *  High security, but Application-Friendly behavior
          o  Maximum security

        Note: If you choose "Maximum security" now, and later
        find that some applications do not work as well as
        desired, you may wish to change it back to "High security."

    +-------------+        +-------------+    +-------------+
    |   Advanced  |        |   Next ->   |    |    Cancel   |
    +-------------+        +-------------+    +-------------+

This page doesn't need to control just the Endpoint-Independent vs Restricted 
Filtering behavior, but might also control other behaviors that involve a 
security/connectivity tradeoff, all of which can presumably be configured 
separately via the "Advanced" button by those users who actually do know what 
they are doing.

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.

> The high end 
> 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.

By this reasoning, many of the other recommendations in the behave-udp draft 
should be eliminated because they are only "recommendations" and not 
"requirements" that applications can depend on with certainty.  REQ-4, for 
example, says that 'It is RECOMMENDED that a NAT have a "Port parity 
preservation" behavior of "Yes".'  Since port parity preservation is only 
RECOMMENDED, applications can't depend on it, right?  Therefore, by your 
reasoning REQ-4 should be eliminated, shouldn't it?  The same goes for REQ-2, 
REQ-3(a), REQ-9, and REQ-11.

The point is that there are sometimes good reasons to include recommendations 
that aren't absolute requirements, and I've already detailed what I feel are 
good reasons for having Endpoint-Independent Filtering be the recommended 
default even if applications can't depend on _always_ having 
Endpoint-Independent Filtering behavior.  I won't rehash those arguments 
again here.

> SHOULD be the default." - For the Linksys devices, they will basically
> never be change from the default.

Let's let Linksys decide that, and focus instead on doing the right thing from 
the perspective of what this working group is trying to accomplish.  The 
title of this working group is "Behavior Engineering for Hindrance 
Avoidance."  Recommending Endpoint-Independent Filtering is consistent with 
the goal of "Avoiding Hindrance" to applications.  Address-Specific 
Filtering, in contrast, _is_ a hindrance to application functioning and 
connectivity, and in fact it is a hindrance that is technically completely 
non-essential to the correct operation of a NAT: it is purely a firewall 
behavior.  Recommending firewall behavior is officially outside the scope of 
this WG, whereas making recommendations toward enhancing application 
connectivity and "avoiding hindrance" is very much in-scope.  It seems very 
clear to me where this working group's priorities need to be.

Arguing that we shouldn't make recommendations consistent with the working 
group's basic purpose and charter, purely on the basis that there is likely 
to be some vendor resistance, just seems fatalistic to me.  If you don't 
think the specifications this working group produces have a chance of 
influencing the vendors, why bother with the working group at all?  Even if 
many vendors choose not to adopt the proposed advice that 
"Endpoint-Independent Filtering SHOULD be the default", the existence of that 
recommendation will still at least make them stop and think twice about the 
security/connectivity tradeoffs involved.  And it might perhaps at least get 
them to implement Endpoint-Independent Filtering as a configuration option, 
where otherwise they probably wouldn't have implemented it at all.

It is reasonable to expect security to be a top concern for NAT vendors, but 
given this working group's charter it is appropriate and essential that this 
group conterbalance those security concerns with reasonable recommendations 
that promote application connectivity and "hindrance avoidance".  Existing 
industry momentum isn't a good excuse to ignore our charter.

Cheers,
Bryan

---

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

> according to the market needs.

Well you may be right that applications will change the NATs that people buy
- but I was not arguing if you were right or wrong. I was just saying none
of these people I listed above believe that full cone is the way to go. You
are right that peer-to-peer will become more important - that is the whole
point of Behave. However, full cone is not required for applications to work
with BEHAVE compliant NATs. The residential vendors do want the xbox games
to work, and the PS2 games, and SIP, and Skype, and on and on, and they
think they will be able to get these to work and provide the "improved"
security. I will if the "improved" really is better below.

> depend on NATs to provide the Address restricted filtering behavior to them.

Uh yah, we more or less discussed this one to death.  Nice argument in
theory but somewhat worse in practice. Let's say you have skype running
behind a full cone NAT and that skype turns out to have a buffer overflow
bug. If you are behind a full cone NAT anyone can attack you. If you are
behind an address restricted NAT, they can not attack you unless they can
guess an address you have have connected to and can spoof a packet from it.
Both of these are often tricky.

> useful in bringing the discussion to a close.

Yes

1) It is perceived as less secure than their competitors.

I understand you don't believe the first, but they do. I brought up the
point but what if people want to run servers and the response what a feeling
that folks that want to run a server behind a NAT are generally competent
enough to go and statically forward a port on the NAT to that server. Here
they more or less end up defining a server as something only someone who
could forward a port would run. This is a totally circular definition of a
server and void of any logic but welcome to my world.

Cullen <not as chair>

---

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

> reasonable ways to make such configuration options accessible even to
 
Just as a side note of irrelevant information ... You do realize that many
residential NATs (mostly ones embedded in DLS and Cable modems) are
configured and locked by the service provider and the end user can not
effect the configuration of them. Given that for most applications it is
what happens on the outermost NAT this is a bit of a bummer. Perhaps we
should specify that they MUST be configurable by the end user using UPnP :-)

Cullen <not as chair>

---

From: Pyda Srisuresh <[email-masked]>
Date: Thu, 26 May 2005 08:51:54 -0700 (PDT)

> On Tuesday 24 May 2005 21:33, Cullen Jennings wrote:
<... stuff deleted>

> Endpoint-Independent Filtering behavior.  I won't rehash those arguments 
[suresh] I have the same kind of dilemma that Bryan has.

An argument has been made several times on this list that residential NATs are
not up for configurtion. And, residential NAT vendors are a big beneficiary of
the  BEhave WG. 

Putting the two together, it seems SHOULDs (i..e, recommendations) and MAYs
have little relevance in the WG drafts. Any cofigurability recommendations
(SHOULDs) are being argued out. Now, is this the right thing to do for us as a
WG, given that the beneficiaries of the WG outght to include configurable,
non-residential NAT vendors too.

Question to the WG: Should we make distinction between configurable NAT devices
vs non-configurable NAT devices when making the behave requirements? I am only
refering to the cases where this disctinction seems warranted. The
recommendations may vary, depending upon whether a NAt device is configurable
or not.

cheers,
suresh

---

From: Bryan Ford <[email-masked]>
Date: Thu, 26 May 2005 09:01:27 -0700 (PDT)

On Wednesday 25 May 2005 22:46, Cullen Jennings wrote:
> >> 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.
> >
> > [suresh] I do not buy the above argument. NAT vendors, especially the
> > vendors that supply to residential customers have catered predominantly
> > to client-server applications thus far. Peer-to-peer application support
> > has not been a priority. As more residential customers are seeking
> > peer-to-peer application support on their NAT devices, the NAT vendors
> > will change the tune according to the market needs.
>
> Well you may be right that applications will change the NATs that people
> buy - but I was not arguing if you were right or wrong. I was just saying
> none of these people I listed above believe that full cone is the way to
> go.

If these people you mention feel so strongly this way, why aren't they 
participating on this list and expressing support for your POV?  I suspect 
most of them simply haven't actually taken the time to think through the 
security/connectivity tradeoffs carefully, especially with an eye toward the 
long-term effects of different connectivity paradigms on the Internet, 
because that's not they're job - their job is to implement NATs that the 
marketing folks can sell right NOW.  And as Suresh points out, marketing 
trends change with the winds.

It's _our_ job to think about the long-term effects of different NAT behaviors 
on the overall functionality and robustness of the Internet and make 
recommendations that will hopefully over time reduce the harm that NATs are 
causing.  That's what this WG was set up to accomplish.  Address-Specific 
Filtering constitutes basic harm to the connectivity of the Internet, and we 
need to make it clear that such connectivity restrictions, while sometimes 
justifiable, should not be implemented lightly or without the user's consent.

> > rather weak. Once a host initiated a UDP based application, the
> > application should be prepared to receive UDP datagrams from any IP
> > address out there and drop datagrams that it does not care for. That is
> > how it is with the Internet without NATs. The behavior ought not to be
> > any different by virtue of keepign the NATs. I doubt if there are any
> > applicatiosn out there that assume a NAT and

If you are behind a full cone NAT the attacker still needs to guess the public 
port number on the NAT you are using to communicate, and any decent NAT will 
make this port number unpredictable.  In fact, as I pointed out before, it 
will often be just as easy if not easier for an attacker to guess the remote 
server's IP address and port number you are talking with than to guess the 
public NAT port you are using, because the server's IP address and port 
number are often well-known: e.g., it's typically one of a small number of 
servers operated by the company selling the application you're running, which 
anyone running that application can easily find.  When the application is 
talking with well-known servers whose addresses and port numbers can easily 
be found or guessed, Address-Dependent Filtering provides absolutely zero 
added security.

> > provide endpoint independent filterign behavior as the default? That
> > would be useful in bringing the discussion to a close.
>
> Yes
>
> I understand you don't believe the first, but they do.

This is all the more reason we should do what we can to influence this 
(mis)perception rather than just giving in to it or endorsing it.

> I brought up the 
> point but what if people want to run servers and the response what a
> feeling that folks that want to run a server behind a NAT are generally
> competent enough to go and statically forward a port on the NAT to that
> server. Here they more or less end up defining a server as something only
> someone who could forward a port would run. This is a totally circular
> definition of a server and void of any logic but welcome to my world.

Plus, it's really really hard to go statically configure a forwarding port on 
a NAT you don't control: e.g., an ISP-deployed NAT.  These kinds of 
misperceptions are something we need to be working against intelligently, not 
just throwing our hands up and proclaiming the Internet's "first-class 
connectivity for all hosts" paradigm to be officially and permanently dead.

Bryan

Joel: "Is there any risk of brain damage?"
Howard: "Well, technically, the procedure _is_ brain damage."

---

From: Bryan Ford <[email-masked]>
Date: Thu, 26 May 2005 09:38:14 -0700 (PDT)

On Thursday 26 May 2005 11:51, Pyda Srisuresh wrote:
> An argument has been made several times on this list that residential NATs
> are not up for configurtion. And, residential NAT vendors are a big
> beneficiary of the  BEhave WG.

I think that most residential NATs that are sold as stand-alone products, such 
as the typical boxed Linksys NAT-router, DO have a great many configuration 
options and would have no problem adding filtering behavior as one more.

The "configuration-locked" residental NATs Cullen was referring to I think are 
generally only low-end devices that ISPs provide on sign-up to their 
services.  If the customer doesn't choose the NAT that they use anyway, 
there's no issue with the customer perceiving one NAT to be "more secure" 
than another and making a purchasing decision on that basis.

> Question to the WG: Should we make distinction between configurable NAT
> devices vs non-configurable NAT devices when making the behave
> requirements? I am only refering to the cases where this disctinction seems
> warranted. The recommendations may vary, depending upon whether a NAt
> device is configurable or not.

I think that the proposed recommendation text already does a pretty reasonable 
job of covering the various important cases.  Let me split apart the 
recommendation's two sentences just for clarity:

REQ-7:
    (a) NATs SHOULD support Endpoint Independent Filtering and Address 
        Dependent Filtering, and MAY support Address and Port Dependent 
        Filtering, as options configurable by the user.
    (b) It is RECOMMENDED 
        that Endpoint Independent Filtering be the default.

Now consider some of the important cases:

* Boxed retail residential NATs: vendor has no reason not to heed 
recommendation (a).  Vendor may choose not to heed (b) if he perceives that 
customers are choosing his box more on the basis of security than on 
application compatibility and that being able to market the box as providing 
maximum security is the overriding concern.  But then a competing vendor may 
decide to heed both (a) and (b) and market their box as being more compatible 
or application-friendly.  All fine and appropriate.

* Non-configurable ISP-supplied NATs: vendor chooses not to heed 
recommendation (a) because he perceives low implementation cost and minimal 
behavioral variation across customers to be overriding concerns that demand 
non-configurability.  Nevertheless, recommendation (b) makes it clear that 
Endpoint Independent Filtering is the preferred behavior, and since the ISP 
isn't in the business of selling NATs and isn't giving its customers choice 
between NATs anyway, the ISP has little or no reason not to heed 
recommendation (b) and make the NAT (always) provide Endpoint Independent 
Filtering.

* Larger NAT routers: vendor has no reason not to heed either (a) or (b) if 
the box is marketed primarily as a NAT or general-purpose router.  Vendor 
might have reason not to heed (b) if the box is marketed primarily for its 
firewall functionality, making security paramount.

In essence, as long as the two sentences of REQ-7 are treated as 
semi-independent sub-recommendations, I think the text already has reasonable 
and fairly obvious interpretations regardless of which type of NAT we're 
talking about.  Perhaps explicitly separating the two recommendations into 
(a) and (b) points as above would be worthwhile in order to make it clear 
that, if a vendor chooses not to heed one point, he should still heed the 
other if possible.

Cheers,
Bryan