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

From: "Francois Audet" <[email-masked]>
Date: Wed, 20 Oct 2004 14:54:44 -0700 (PDT)

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.

        The rationale would be for applications such as rcp which bizarely use the source
        port for some weak authentication.

        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? 

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?

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 20 Oct 2004 15:38:32 -0700 (PDT)

<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. <SPAN 
  class=659271522-20102004><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>