Subject: RE: [Ietf-behave] New draft on UDP unicast behavior

From: "Francois Audet" <[email-masked]>
Date: Wed, 20 Oct 2004 15:52:35 -0700 (PDT)

Hi 
Dan,
<FONT face=Arial color=#800000 
size=2> 
If I 
understand correctly, you want REQ-10 to be:
<FONT face=Arial color=#800000 
size=2> 
<FONT face=Arial color=#800000 
size=2>REQ-10: NAT MUST have the capability to turn off individually all ALGs it 
supports.
<FONT face=Arial color=#800000 
size=2>    REQ-10a: as per the current 
text
    <FONT face=Arial 
color=#800000 size=2>REQ-10-b: It is RECOMMENDED that all ALGs be turned off by 
default.
<FONT face=Arial color=#800000 
size=2> 
I'm OK 
with 3c's re-wording. I assume that you are arguing for a reference to RFC 2623 
in the justification section for requirement 3c, correct?
<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: Dan Wing 
  [mailto:dwing@xxxxxxxxx] Sent: Wednesday, October 20, 2004 
  15:38To: Audet, Francois [SC100:9T51:EXCH]; 'Senthil 
  Sivakumar'Cc: 'Behave'Subject: RE: [Ietf-behave] New 
  draft on UDP unicast behavior 
   
  <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: Francois Audet 
    [mailto:audet@xxxxxxxxxxxxxxxxxx]Sent: Wednesday, October 20, 
    2004 2:55 PMTo: 'Dan Wing'; 'Senthil Sivakumar'Cc: 
    'Behave'Subject: RE: [Ietf-behave] New draft on UDP unicast 
    behavior 
    Hi guys, 
    Let's try to summarize the latest issues from the email 
    exchange. 
    REQ-3c: If the NAT changes the source port, it MUST NOT 
    allocate the new <FONT 
    size=2>        port from within the range 
    of 0-1023. 
            I assume that the 
    proposal is to change it to something like "If the NAT 
            changes the 
    source port, it MUST NOT allocate the new port from within 
            the range 
    of 0-1023 unless the original port was within that range, in which 
    case         the 
    NAT MAY allocate the new port from within the 0-1023 
    range. <FONT face=Verdana 
    color=#0000ff size=2> 
  <FONT face=Verdana color=#0000ff 
  size=2>More straightforward wording, with the same meaning, might 
  be:
  <FONT face=Verdana color=#0000ff 
  size=2>        If the host's source port 
  was in the range 0-1023, the NAT's source port must also be in the same 
  range.  If the host's source port was in the range 1024-65535, the 
  NAT's source port must also be in that range.
  <FONT face=Verdana color=#0000ff 
  size=2>In that way this requirement doesn't talk about changing the source 
  port; we can talk about that in another requirement.
  <BLOCKQUOTE dir=ltr 
  style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
    <FONT face=Verdana color=#0000ff 
    size=2> 
     
            The rationale 
    would be for applications such as rcp which bizarely use the source 
            port for some 
    weak authentication. <FONT 
    face=Verdana color=#0000ff size=2> 
  <FONT face=Verdana color=#0000ff 
  size=2>RCP runs over TCP, so RCP isn't a good justification for this 
  UDP-focused document.
  <FONT face=Verdana color=#0000ff 
  size=2>However, NFS and RPC run over UDP.  A good cite is RFC2623, "NFS 
  Version 2 and Version 3 Security Issues and the NFS Protocol's Use of 
  RPCSEC_GSS and Kerberos V5", notably section 2.1.
  <BLOCKQUOTE dir=ltr 
  style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
            While I don't 
    really care, I am not terribly keen on this idea. Seems to me that 
            it is extremely 
    unlikely that rcp would work with any commercial NAT today as I 
            have a hard time 
    believing that NATs would preserve the well-known port range today. 
    
            Any other views 
    on this topic? 
  <FONT face=Verdana color=#0000ff 
  size=2>Furthermore, such a behavior in a NAT allows any device behind the 
  NAT to pretend to be the client that's authorized in the .rhosts 
  file.  This seems like an idea worse than normal r-services unless 
  you trust any and all devices behind the NAT to be friendly.  Oh, 
  and you also need to trust that nobody else will get that NAT's IP address 
  (which is one of the weaknesses of r-services 
  authentication).
  <FONT face=Verdana color=#0000ff 
  size=2> 
  <FONT face=Verdana color=#0000ff 
  size=2>To bring us back to UDP, though, NFS and RPC have a similar 
  weakness.
  <BLOCKQUOTE dir=ltr 
  style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
    <FONT face=Verdana color=#0000ff 
    size=2> 
     
    REQ-10: A NAT MUST have the capability to turn off 
    individually all ALGs it supports, <FONT 
    size=2>        except for DNS and 
    IPsec. 
            This definitively 
    needs tweaking. The question is do we make it more or less 
            explicit. 
    Do we say "A NAT MUST have the capability to turn off individually 
    all         ALGs 
    it supports." (full stop). Or do we say "A NAT MUST have the capability 
    to         turn 
    off individually all ALGs it supports unless there is a clear reason for 
    not         doing 
    so described in an IETF RFC" (or something like that). 
            Any views of 
    which approach is best? <FONT 
    face=Verdana color=#0000ff size=2> 
     
  <FONT face=Verdana color=#0000ff 
  size=2>I haven't seen any arguments for, or descriptions of, UDP ALGs that are 
  necessary for a NAT to function.  Without such arguments the 
  text should recommend ALGs be turned off in the default configuration -- 
  that is, the NAT shouldn't require the user go into a screen or enter a 
  command to disable any ALG, but rather the user should have to _enable_ an ALG 
  explicitly if the user needs an ALG for their application to work over the 
  NAT.
  <FONT face=Verdana color=#0000ff 
  size=2> 
  <FONT face=Verdana color=#0000ff 
  size=2>Once we begin tackling TCP in a separate document, we will undoubtably 
  uncover a few needs for ALGs (FTP comes to mind).
  <FONT face=Verdana color=#0000ff 
  size=2>-d
  <FONT face=Verdana color=#0000ff 
  size=2>

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 20 Oct 2004 16:34:27 -0700 (PDT)

> If I understand correctly, you want REQ-10 to be:
>
> REQ-10: NAT MUST have the capability to turn off individually
> all ALGs it supports.
>    REQ-10a: as per the current text
>    REQ-10-b: It is RECOMMENDED that all ALGs be turned off
> by default.

No, I'm asking that REQ-10-b say that _all_ ALGs must be turned off by
default.  (As you know, "Recommended" is a synonym for "Should" in RFC2119).

In draft-ietf-behave-nat-01, REQ-10 currently reads:

 :     REQ-10: A NAT MUST have the capability to turn off
 :     individually all ALGs it supports, except for DNS and IPsec.
 :
 :        REQ-10a: Any NAT ALG for SIP MUST be turned off by default.

I am suggesting replacing it with the following text:

 : REQ-10:  If a NAT includes ALGs, all of those ALGs MUST be
 :          disabled by default.
 :
 :    REQ-10a:  If a NAT includes ALGs, it is RECOMMENDED that
 :              the NAT allow the user to enable or disable each
 :              ALG separately.  This requirement allows the user
 :              to enable ALGs which are necessary to aid operation
 :              of some applications without enabling ALGs which
 :              interfere with operation of other applications.

> I'm OK with 3c's re-wording.  I assume that you are arguing for
> a reference to RFC 2623 in the justification section for requirement
> 3c, correct?

Right.  A non-normative reference to RFC2623 should be sufficient to explain
why REQ-3C recommends preserving the well-known port range for the source
UDP port.

-d

-----Original Message-----
From: Dan Wing [mailto:dwing@xxxxxxxxx]
Sent: Wednesday, October 20, 2004 15:38
To: Audet, Francois [SC100:9T51:EXCH]; 'Senthil Sivakumar'
Cc: 'Behave'
Subject: RE: [Ietf-behave] New draft on UDP unicast behavior

-----Original Message-----
From: Francois Audet [mailto:audet@xxxxxxxxxxxxxxxxxx]
Sent: Wednesday, October 20, 2004 2:55 PM
To: 'Dan Wing'; 'Senthil Sivakumar'
Cc: 'Behave'
Subject: RE: [Ietf-behave] New draft on UDP unicast behavior

Hi guys,
Let's try to summarize the latest issues from the email exchange.
REQ-3c: If the NAT changes the source port, it MUST NOT allocate the new
        port from within the range of 0-1023.
        I assume that the proposal is to change it to something like "If the
NAT
        changes the source port, it MUST NOT allocate the new port from
within
        the range of 0-1023 unless the original port was within that range,
in which case
        the NAT MAY allocate the new port from within the 0-1023 range.
More straightforward wording, with the same meaning, might be:
        If the host's source port was in the range 0-1023, the NAT's source
port must also be in the same range.  If the host's source port was in the
range 1024-65535, the NAT's source port must also be in that range.
In that way this requirement doesn't talk about changing the source port; we
can talk about that in another requirement.

        The rationale would be for applications such as rcp which bizarely
use the source
        port for some weak authentication.
RCP runs over TCP, so RCP isn't a good justification for this UDP-focused
document.
However, NFS and RPC run over UDP.  A good cite is RFC2623, "NFS Version 2
and Version 3 Security Issues and the NFS Protocol's Use of RPCSEC_GSS and
Kerberos V5", notably section 2.1.
        While I don't really care, I am not terribly keen on this idea.
Seems to me that
        it is extremely unlikely that rcp would work with any commercial NAT
today as I
        have a hard time believing that NATs would preserve the well-known
port range today.
        Any other views on this topic?
Furthermore, such a behavior in a NAT allows any device behind the NAT to
pretend to be the client that's authorized in the .rhosts file.  This seems
like an idea worse than normal r-services unless you trust any and all
devices behind the NAT to be friendly.  Oh, and you also need to trust that
nobody else will get that NAT's IP address (which is one of the weaknesses
of r-services authentication).

To bring us back to UDP, though, NFS and RPC have a similar weakness.

REQ-10: A NAT MUST have the capability to turn off individually all ALGs it
supports,
        except for DNS and IPsec.
        This definitively needs tweaking. The question is do we make it more
or less
        explicit. Do we say "A NAT MUST have the capability to turn off
individually all
        ALGs it supports." (full stop). Or do we say "A NAT MUST have the
capability to
        turn off individually all ALGs it supports unless there is a clear
reason for not
        doing so described in an IETF RFC" (or something like that).
        Any views of which approach is best?

I haven't seen any arguments for, or descriptions of, UDP ALGs that are
necessary for a NAT to function.  Without such arguments the text should
recommend ALGs be turned off in the default configuration -- that is, the
NAT shouldn't require the user go into a screen or enter a command to
disable any ALG, but rather the user should have to _enable_ an ALG
explicitly if the user needs an ALG for their application to work over the
NAT.

Once we begin tackling TCP in a separate document, we will undoubtably
uncover a few needs for ALGs (FTP comes to mind).
-d