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

From: Senthil Sivakumar <[email-masked]>
Date: Mon, 18 Oct 2004 17:31:29 -0700 (PDT)

Inline.
At 07:57 PM 10/18/2004 -0400, Francois Audet wrote:
Thanks
Senthil. 
See below for answers.

Some comments.

A large portion of this document seems to talk about the generic
behavior of NAT and could very well be extended to TCP (or other layer 4
protocols that have a L4 identifier).
Any specific reasons to restrict it to UDP
only? 

Yes. Another document will
look at TCP and other transport. The scope of this document is
specifically restricted to UDP. This was discussed earlier and it was a
concensus to look initially only at UDP for this document.

 Section 3.1 
There is another flavor of NAT behavior in the IP address pooling
case.
NATs would overload on one address for several internal clients
whenever possible. But the NAT uses a different address for for the same
host applications that do not have port information. (DNS for example).
This is neither an arbitrary behavior nor a strict behavior. It is
somewhat adaptive , IMO. 

I'm not sure I understand
your comment. What do you mean by "applications that do not have
port information like DNS"? 
Some applications embed port and address in the payload, some just the
address. When you are doing PAT
the applications that does not embed port (like DNS), NATs are forced to
use a new address from the address
pool.

Section 6:
Is different ALG behaviors based on UDP is out of scope?

Yes. 

 General comment:
NATs have different behavior based on what it is configured to do. So
the port
preservation and filtering 

Your sentence is
incomplete...

 Section 11:

General comments.

Are the requirements mentioned in this section the default behavior
of NATs? I don t think that would be acceptable to all vendors. The
default behavior is very much dependent on a particular configuration of
NAT. Changing existing behavior is always a challenge, so you could say
some thing like a NAT should be able to behave in the mode specified by
IETF , where the vendors could still preserve their current behavior and
provide the new behavior based on what mode is turned on. I think it
could be argued that it would again make NATs 
non- deterministic,  but that would give NAT vendors a
motivation to follow the 
new behavior without having to drastically change the existing
behavior. 

Indeed, I don't see any
reason why a vendor woulnd't be able to do what you just describe. I
would even say that for "backward compatibility", vendors will
certainly be enclined to do what you just describe. They could decide to
have a new "RFC XXX conformance" 
mode.
Changing an existing default behavior is not an easy task because it
upsets a lot of customers. So
there has to be a transitional path where you support the new behavior
and slowly move them all
to the new behavior. 

 Specific ones.
REQ-2b: A NAT MUST NOT have an "IP address pooling"
behavior of
         "No".
I could not figure out what the IP address
pooling behavior of No is. Did you mean to say arbitrary ?

Correct. This is a typo. I
will make the change.

 REQ-3c: If the NAT changes the source port, it MUST NOT
         allocate the new
port from within the range of 0-1023.

We tried this and atleast one application (rcp) is broken when we do
this, where the server expects the source port to be in the low
range.  So there may be application dependencies with this behavior.

Hum. This is kind of
interesting. I assume you are talking about port 469 "Radio Control
Protocol"? It seems to me that RCP would then not work with any NAT
unless there is some sort of ALG.
 
No, when you do a remote copy behind a NAT (doing overloading). A rcp
client uses the source port < 1024,
and the server port is rshell port 514. 

Is
this a weakness of RCP itself?

I could not find any information in the RFC that mandates this, but it
could very well
be an implementation issue. I have seen this with Solaris.

 REQ-5: A dynamic NAT UDP binding timer MUST NOT expire in
less

      than 2 minutes.

What do you mean by dynamic NAT UDP binding? There are applications
that dictate how long the binding stays and what happens if the
application s timeout is less than 2 minutes.

I'll remove the word
"Dynamic". It was "dynamic" as opposed to
"static NAT binding" (in which case there is obviously no
timeouts).
 
If applications are using their
own timeouts, then by definition they require their own
ALG.
Right, so the ALGs would have to use the timeouts indicated in the
message itself, which might be
less than the timeout specified above.

 REQ-10: A NAT MUST have the capability to turn off
individually
      all ALGs it supports, except for DNS
and IPsec.

Can we say that all the ALG s working in the well known port range
should be on by default? And all ALG s listening on reserved ports and
ephemeral ports should be off by
default. 

Perhaps our wording is a
little bit strong. Their might be some other protocols that require ALGs
that we can't think of. 

Right, I think it would vary from vendor to vendor, so it will be nice if
we could word it in a generic way.

Would replacing the
"MUST" by a "SHOULD" be appropriate?
 
I agree.

Should
we instead replace "DNS and IPsec" with something like
"protocols who require ALGs such as DNS and
IPsec"?
Ok.

          REQ-10a: Any
NAT ALG for SIP MUST be turned off by default.

Section 12.

General Comments. 

NATs can store the out-of-order fragments for a period of time until
the first fragment arrives. This timeout could be a tunable one. I would
like to see that this document recommending the handling out-of-order
fragments. 

I assume you would like
section 10 to cover the timeout for this? Any suggestions on what it
should say?
Yes, section 10 would be appropriate. The text could be something
like,

"It is RECOMMENDED that NATs doing PAT should support out-of-order
fragments. 
This requires the NAT to store the non-initial fragments until the first
fragment arrives,
which contains the actual L4 information. Saving the out-of-order
fragments potentially
opens up the NAT to DoS attacks and hence NATs should store the fragments
only
wait for a period of time for the initial fragment to arrive. If the
initial fragment does not
arrive within that time period, the NAT should discard all the
out-of-order fragments. 
This fragmentation timeout could be a configurable parameter. The default
is suggested
to be 20 seconds".

Senthil

Minor ones:

REQ-13 and REQ-13: should be Req-13 and
Req-14.

I'm not sure what happened
here for this one as I had made that correction before. I assume the
wrong version was posted.

Senthil

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 19 Oct 2004 21:17:24 -0700 (PDT)

I'm 
leaving this in HTML in the hopes it's still somewhat 
legible...
<FONT face=Verdana color=#0000ff 
size=2> 
<FONT face=Verdana color=#0000ff 
size=2>Comments inline.
<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 Senthil 
  SivakumarSent: Monday, October 18, 2004 5:32 PMTo: 
  Francois AudetCc: 'Behave'Subject: RE: [Ietf-behave] New 
  draft on UDP unicast behavior Inline.At 07:57 PM 
  10/18/2004 -0400, Francois Audet wrote:
  Thanks 
    Senthil. See below for 
    answers. 
    
      Some comments.
      A large portion of this document seems to talk about the generic 
      behavior of NAT and could very well be extended to TCP (or other layer 4 
      protocols that have a L4 identifier). 
      Any specific reasons to restrict it to UDP only?<FONT face=arial 
      color=#800000 size=2> <FONT face=arial 
    color=#800000 size=2>Yes. Another document will look at TCP and other 
    transport. The scope of this document is specifically restricted to UDP. 
    This was discussed earlier and it was a concensus to look initially only at 
    UDP for this document. 
    
       Section 3.1 
      There is another flavor of NAT behavior in the IP address pooling 
      case. 
      NATs would overload on one address for several internal clients 
      whenever possible. But the NAT uses a different address for for the same 
      host applications that do not have port information. (DNS for example). 
      This is neither an arbitrary behavior nor a strict behavior. It is 
      somewhat adaptive , IMO. <FONT face=arial color=#800000 
    size=2>I'm not sure I understand your comment. What do you mean by 
    "applications that do not have port information like DNS"? 

  Some applications embed port and address in the payload, some just 
  the address. When you are doing PATthe applications that does not embed 
  port (like DNS), NATs are forced to use a new address from the 
  addresspool.<FONT face=Verdana 
  color=#0000ff size=2> 
   
<FONT face=Verdana color=#0000ff 
size=2>Help me understand if I'm interpreting your statement correctly.  
Are you're saying:
<FONT face=Verdana color=#0000ff 
size=2> 

  <FONT 
  face=Verdana color=#0000ff size=2>DNS queries don't have the source UDP port 
  in them, thus NATs have to use different source UDP ports for each DNS query 
  so the NAT can successfully demultiplex the DNS 
  answers.<FONT face=Verdana 
  color=#0000ff size=2> 
<FONT 
face=Verdana color=#0000ff size=2>?
<SPAN 
class=605155603-20102004> 
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">

      Section 6: 
      Is different ALG behaviors based on UDP is out of 
    scope?Yes. 
    
       General comment: 
      NATs have different behavior based on what it is configured to do. So 
      the port 
      preservation and filtering <FONT face=arial 
    color=#800000 size=2>Your sentence is incomplete... 
    
       Section 11:
      General comments.
      Are the requirements mentioned in this section the default behavior of 
      NATs? I don t think that would be acceptable to all vendors. The default 
      behavior is very much dependent on a particular configuration of NAT. 
      Changing existing behavior is always a challenge, so you could say some 
      thing like a NAT should be able to behave in the mode specified by IETF , 
      where the vendors could still preserve their current behavior and provide 
      the new behavior based on what mode is turned on. I think it could be 
      argued that it would again make NATs 
      non- deterministic,  but that would give NAT vendors a motivation 
      to follow the 
      new behavior without having to drastically change the existing 
      behavior. Indeed, I 
    don't see any reason why a vendor woulnd't be able to do what you just 
    describe. I would even say that for "backward compatibility", vendors will 
    certainly be enclined to do what you just describe. They could decide to 
    have a new "RFC XXX conformance" mode.Changing an 
  existing default behavior is not an easy task because it upsets a lot of 
  customers. Sothere has to be a transitional path where you support the new 
  behavior and slowly move them allto the new behavior. 

       Specific ones. 
      REQ-2b: A NAT MUST NOT have an "IP address pooling" behavior of 
               "No". 
      I could not figure out what the IP address pooling 
      behavior of No is. Did you mean to say arbitrary 
    ?Correct. This is a 
    typo. I will make the change. 
    
       REQ-3c: If the NAT changes the source port, it MUST NOT 
               allocate the new port 
      from within the range of 0-1023.
      We tried this and atleast one application (rcp) is broken when we do 
      this, where the server expects the source port to be in the low 
      range.  So there may be application dependencies with this behavior. 
      Hum. This is kind of 
    interesting. I assume you are talking about port 469 "Radio Control 
    Protocol"? It seems to me that RCP would then not work with any NAT unless 
    there is some sort of ALG. No, when you do a 
  remote copy behind a NAT (doing overloading). A rcp client uses the source 
  port < 1024,and the server port is rshell port 514. 
  Is 
    this a weakness of RCP itself? 

  I could not find any information in the RFC that mandates this, but 
  it could very wellbe an implementation issue. I have seen this with 
  Solaris.<FONT face=Verdana color=#0000ff 
  size=2> 

<FONT face=Verdana color=#0000ff 
size=2>I'm familiar with RCP; thanks for pointing out that application's 
use of ports below 1024!
 
<FONT face=Verdana color=#0000ff 
size=2>I think we should discuss the R protocols briefly in the 
document, but also mention that they're essentially obsolete due to their poor 
security model.
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">

       REQ-5: A dynamic NAT UDP binding timer MUST NOT expire in 
      less
            than 2 minutes.
      What do you mean by dynamic NAT UDP binding? There are applications 
      that dictate how long the binding stays and what happens if the 
      application s timeout is less than 2 minutes. <FONT face=arial 
      color=#800000 size=2>
      <FONT face=Verdana color=#0000ff 
    size=2> <FONT face=arial color=#800000 
    size=2>I'll remove the word "Dynamic". It was "dynamic" as opposed to 
    "static NAT binding" (in which case there is obviously no 
    timeouts). If 
    applications are using their own timeouts, then by definition they require 
    their own ALG.
  Right, so the ALGs would have to use the timeouts indicated in the 
  message itself, which might beless than the timeout specified above.<SPAN 
  class=605155603-20102004><FONT face=Verdana color=#0000ff 
  size=2> 

<FONT face=Verdana color=#0000ff 
size=2>ALGs are out of scope of this document, 
though. 
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">

       REQ-10: A NAT MUST have the capability to turn off individually 
            all ALGs it supports, except for DNS 
      and IPsec.<FONT face=Verdana 
      color=#0000ff size=2> 
<FONT face=Verdana color=#0000ff 
size=2>What is this DNS ALG -- is it an RFC2694 ALG?  If it is, the Draft 
needs to be specific.  If it isn't, the Draft needs to describe the 
specific behavior of this DNS "ALG".
<FONT face=Verdana color=#0000ff 
size=2> 
<FONT face=Verdana color=#0000ff 
size=2>As this draft is only supposed to cover UDP, I don't understand the need 
for an IPsec ALG in REQ-10.
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">

      Can we say that all the ALG s working in the well known port range 
      should be on by default? And all ALG s listening on reserved ports and 
      ephemeral ports should be off by default.<FONT face=arial color=#800000 
      size=2> <FONT face=arial color=#800000 
    size=2>Perhaps our wording is a little bit strong. Their might be some other 
    protocols that require ALGs that we can't think of. 
  Right, I think it would vary from vendor to vendor, so it will be 
  nice if we could word it in a generic way.<SPAN 
  class=605155603-20102004><FONT face=Verdana color=#0000ff 
  size=2> 

  <FONT face=Verdana color=#0000ff 
    size=2><FONT 
    face=Verdana color=#0000ff size=2><FONT face=Verdana color=#0000ff 
    size=2>Would replacing the 
    "MUST" by a "SHOULD" be appropriate? 
  I agree.<FONT face=Verdana 
  color=#0000ff size=2> 
   
<FONT face=Verdana color=#0000ff 
size=2>If we use SHOULD, we need to explain in the Draft why the 
requirement isn't a MUST; otherwise implementors will ignore the SHOULD 
because they don't understand the implications of their 
decision.
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  Should 
    we instead replace "DNS and IPsec" with something like "protocols who 
    require ALGs such as DNS and IPsec"?
  Ok.<FONT face=Verdana color=#0000ff 
  size=2> 
   
<FONT face=Verdana color=#0000ff 
size=2>We need to describe the functions of these ALGs, though, as I mentioned 
earlier. 
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">

                REQ-10a: Any 
      NAT ALG for SIP MUST be turned off by default.
      Section 12.
      General Comments. 
      NATs can store the out-of-order fragments for a period of time until 
      the first fragment arrives. This timeout could be a tunable one. I would 
      like to see that this document recommending the handling out-of-order 
      fragments. 
      <FONT face=Verdana color=#0000ff 
      size=2> <FONT face=arial color=#800000 
    size=2>I assume you would like section 10 to cover the timeout for this? Any 
    suggestions on what it should say?
  Yes, section 10 would be appropriate. The text could be something 
  like,"It is RECOMMENDED that NATs doing PAT should support 
  out-of-order fragments. This requires the NAT to store the non-initial 
  fragments until the first fragment arrives,which contains the actual L4 
  information. Saving the out-of-order fragments potentiallyopens up the NAT 
  to DoS attacks and hence NATs should store the fragments onlywait for a 
  period of time for the initial fragment to arrive. If the initial fragment 
  does notarrive within that time period, the NAT should discard all the 
  out-of-order fragments. This fragmentation timeout could be a configurable 
  parameter. The default is suggestedto be 20 seconds".<SPAN 
  class=605155603-20102004><FONT face=Verdana color=#0000ff 
  size=2> 
<FONT face=Verdana color=#0000ff 
size=2>An additional threshold should be a certain percentage of free memory on 
the NAT, too.
<FONT face=Verdana color=#0000ff 
size=2> 
<FONT face=Verdana color=#0000ff 
size=2>We should be clear if we recommend the NAT send the packets to the host 
in the same order they were received, or if it should attempt to reconstitute 
them, or what.
<FONT face=Verdana color=#0000ff 
size=2> 
<FONT face=Verdana color=#0000ff 
size=2>-d
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
   Senthil

      Minor ones:
      REQ-13 and REQ-13: should be Req-13 and Req-14.<FONT face=arial 
      color=#800000 size=2> 
       I'm 
    not sure what happened here for this one as I had made that correction 
    before. I assume the wrong version was posted. 

      Senthil

---

From: Senthil Sivakumar <[email-masked]>
Date: Tue, 19 Oct 2004 22:13:43 -0700 (PDT)

At 09:17 PM 10/19/2004 -0700, Dan Wing wrote:
I'm
leaving this in HTML in the hopes it's still somewhat
legible...
 
Comments inline.

-----Original Message-----
From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx
[mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx]On
Behalf Of Senthil Sivakumar
Sent: Monday, October 18, 2004 5:32 PM
To: Francois Audet
Cc: 'Behave'
Subject: RE: [Ietf-behave] New draft on UDP unicast behavior

Inline.
At 07:57 PM 10/18/2004 -0400, Francois Audet
wrote:
Thanks Senthil. 
See below for answers. 
Some comments.

 Section 3.1 

Help me understand if I'm
interpreting your statement correctly.  Are you're
saying:

DNS queries don't have the source UDP port in them, thus NATs have to
use different source UDP ports for each DNS query so the NAT can
successfully demultiplex the DNS
answers.

?
Nope, I am saying that the DNS replies embed just the IP addresses and
not ports. When NAT is
operating as a PAT, it cannot overload on the address only, it also needs
the port. But now, I 
realize that ALGs are out of the scope of this document this is may not
be a relevant discussion
in this document, since we are discussing the DNS ALG here.

Section 6: 

 General comment: 

 Section 11:

General comments.

 Specific ones. 

 

Is

I could not find any information in the RFC that mandates this, but it
could very well
be an implementation issue. I have seen this with
Solaris. 

I'm familiar with RCP; thanks
for pointing out that application's use of ports below 1024!
 
I think we should discuss the
R protocols briefly in the document, but also mention that they're
essentially obsolete due to their poor security
model.
Believe me, there are a lot of people using it and they will complain..

      than 2 minutes.

 

I'll remove the word
 
less than the timeout specified
above. 

ALGs are out of scope of this
document, though. 

What is
this DNS ALG -- is it an RFC2694 ALG?  If it is, the Draft needs to
be specific.  If it isn't, the Draft needs to describe the specific
behavior of this DNS "ALG".
 
Yes it is the one defined in 2694. But that is why I thought being more
generic might be a good idea
without naming any ALG in particular. 

As
this draft is only supposed to cover UDP, I don't understand the need for
an IPsec ALG in REQ-10.

 

Would replacing the
 
I agree.

If we use SHOULD, we need to
explain in the Draft why the requirement isn't a MUST; otherwise
implementors will ignore the SHOULD because they don't understand the
implications of their decision.

Should we instead replace "DNS and IPsec" with something
like "protocols who require ALGs such as DNS and
IPsec"?
Ok. 

We need to describe the
functions of these ALGs, though, as I mentioned earlier.

Or don't call out these ALGs specifically. Just say that "all ALGs
supported by the NAT
should be off by default except for the ones that listen on well-known
ports."

          REQ-10a: Any

Section 12.

General Comments. 

 

I assume you would like section
10 to cover the timeout for this? Any suggestions on what it should
say?
Yes, section 10 would be appropriate. The text could be something
like,

An additional threshold
should be a certain percentage of free memory on the NAT,
too.
 
We should be clear if we
recommend the NAT send the packets to the host in the same order they
were received, or if it should attempt to reconstitute them, or
what.

I think they should be sent out in proper order but there should be no
attempt to reassemble them. A couple
of reasons I could think of are that 

1. reassembled fragments might again be fragmented.
2. reassembling is really a host functionality and a middle box should
not be required to do that.

Senthil

-d

Senthil
Minor ones:

 

I'm not sure what happened here
for this one as I had made that correction before. I assume the wrong
version was posted. 

Senthil

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 20 Oct 2004 09:48:06 -0700 (PDT)

Converted to ASCII to make this thread easier to follow, and removed
previous bits and pieces of the thread.

Senthil Sivakumar wrote:

>>Dan Wing wrote:
>>
>>Help me understand if I'm interpreting your statement correctly.  Are
you're saying:
>>
>>   DNS queries don't have the source UDP port in them,
>>   thus NATs have to use different source UDP ports for
>>   each DNS query so the NAT can successfully demultiplex
>>   the DNS answers.
>>
>> ?
>
> not ports.  When NAT is operating as a PAT, it cannot overload on the
> address only, it also needs the port.  But now, I realize that ALGs
> are out of the scope of this document this is may not be a relevant
> discussion in this document, since we are discussing the DNS ALG here.

...

>> I'm familiar with RCP; thanks for pointing out that application's
>> use of ports below 1024!
>>
>> I think we should discuss the R protocols briefly in the document, but
>> also mention that they're essentially obsolete due to their poor
>> security model.
>

All of the R-Services (rlogin, rsh, rexec, rwho) run over TCP, though,
don't they?  So I believe they're out of scope for this document.

Other than NFS's and RPC's similar reliance on ports < 1024, I'm not
aware of any UDP-based application that expects the UDP source port to
be < 1024.

>>>      all ALGs it supports, except for DNS and IPsec.
>>
>> What is this DNS ALG -- is it an RFC2694 ALG?  If it is, the Draft
>> needs to be specific.  If it isn't, the Draft needs to describe
>> the specific behavior of this DNS "ALG".
>
> Yes it is the one defined in 2694. But that is why I thought being
> more generic might be a good idea without naming any ALG in particular.

The charter of BEHAVE is to make NATs more consistent in their behavior
so applications can rely on the NAT's behavior.  If an application
doesn't know how the NAT will interfere with a certain application (such
as DNS), we haven't achieved our goal.  So we need to be explicit.

>> We need to describe the functions of these ALGs, though, as
>> I mentioned earlier.
>
> Or don't call out these ALGs specifically.  Just say that "all
> ALGs supported by the NAT should be off by default except for
> the ones that listen on well-known ports."

I disagree.

We need to enumerate the ones we "like" -- if there are any -- and
describe their proper behavior.

Defining the Proper Behavior, and the fact that all protocols evolve
(DNS SRV RR, as a good example), is why we don't want to get involved in
defining 'proper' ALG behavior, and is also why ALGs are nearly always a
really, really bad idea.

There is also a lot of intellectual property around ALGs and each vendor
believes their method is better than other methods, because each belives
their method provides more transparancy than competitors'.

>> We should be clear if we recommend the NAT send the packets to the
>> host in the same order they were received, or if it should attempt to
>> reconstitute them, or what.
>
> I think they should be sent out in proper order but there should be
> no attempt to reassemble them.  A couple of reasons I could think of
> are that
>
> 1. Reassembled fragments might again be fragmented.
> 2. Reassembling is really a host functionality and a middle box should

Sure, that sounds reasonable to add to the I-D.  I personally don't expect
the packets will get fragmented again unless they exceed 1500 bytes, but
it's not worth worrying about too much either way.

-d

---

From: Senthil Sivakumar <[email-masked]>
Date: Wed, 20 Oct 2004 11:09:31 -0700 (PDT)

At 09:48 AM 10/20/2004 -0700, Dan Wing wrote:
Converted to ASCII to make this thread easier to follow, and removed
previous bits and pieces of the thread.

...

All of the R-Services (rlogin, rsh, rexec, rwho) run over TCP, though,
don't they?  So I believe they're out of scope for this document.
Yes you are right most of them are TCP based, but the point I am
trying to make is that there are weird behaving applications like these
that existed for a long time that may not work with the proposed
behavior.

Other than NFS's and RPC's similar reliance on ports < 1024, I'm not
aware of any UDP-based application that expects the UDP source port to
be < 1024.
Me neither, at this time.

The charter of BEHAVE is to make NATs more consistent in their behavior
so applications can rely on the NAT's behavior.  If an application
doesn't know how the NAT will interfere with a certain application (such
as DNS), we haven't achieved our goal.  So we need to be explicit.
So, how should we be explicit here ? I made a comment that a lot of text
in this document is generic NAT behavior and nothing to do with
UDP only. Req 10 above is one such requirement. I don't see why do
we have to name any ALGs or discuss their functions. Also, I am told
that ALGs are out of the scope of this document.
I disagree.

We need to enumerate the ones we "like" -- if there are any -- and
describe their proper behavior.
I don't understand what you are disagreeing with here, is it the
recommendation that the ALGs listening on the well known ports
should be on by default?
Defining the Proper Behavior, and the fact that all protocols evolve
(DNS SRV RR, as a good example), is why we don't want to get involved in
defining 'proper' ALG behavior, and is also why ALGs are nearly always a
really, really bad idea.
I don't suggest that we need to define the behavior of ALG by any means.

Senthil

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 20 Oct 2004 12:02:40 -0700 (PDT)

> Me neither, at this time.

Okay, I see your point.

It agree it might be useful to encourage NATs to preserve the source UDP
port if it's below 1024, just in the event there are non-standard
applications that use this as a (weak) distributed authentication
mechanism.

At the same time, it would be good to encourage UDP applications to
quit doing this stuff.  However, that pedagogy around application
design probably doesn't belong in -ietf-behave-nat-.

> that ALGs are out of the scope of this document.

I don't see the need for either a DNS or IPsec ALG in a NAT, but perhaps
I'm missing something.

The only interesting thing around some protocols is the NAT could expect
a single outgoing UDP message will elicit a single UDP response, and the
NAT could then immediately close its NAT binding (and free up the
associated resources).  This seems a bit risky in the event the
application evolves so that a single outgoing UDP messages causes more
than one incoming UDP message, but that kind of evolution seems unlikely
for protocols such as DNS and NTP.  I guess what I'm saying is we should
soften the MUST for the two minute UDP timeout to a SHOULD and explain
the few permitted exceptions to the two minute rule.

Beyond that, I don't see any use for application awareness for DNS in
a NAT.

> recommendation that the ALGs listening on the well known ports

To meet BEHAVE's goals, I don't see how we can allow ALGs in a NAT
unless we enumerate what each application layer gateway's permitted
behavior is for each application.

For an example of how an underspecified ALG can do harm, let's say some
NAT vendors all use 192.168.1.* as the local network interface on their
NAT, and both vendors have a DNS ALG (which is permitted if BEHAVE says
that ALGs can exist on well-known ports), and:

* vendor A's DNS ALG rewrites any incoming DNS response that references
192.168.1.* as NXDOMAIN, because there aren't any configured servers
on this NAT.

* vendor B's DNS ALG rewrites incoming DNS SRV resource records that
reference 192.168.1.* as the NAT's public IP address, and creates an
associated binding on the NAT which maps to the internal host and
internal port that that was specified in the SRV.

* vendor C does a the same thing to vendor C, but also examines TXT
records looking for 192.168.1.* address and port combinations and
rewrites them and installs a NAT binding.

> I don't suggest that we need to define the behavior of ALG by any means.

I'm saying that *if* the BEHAVE document explicitly or implicitly allows an
ALG, the BEHAVE document needs to define the proper behavior of those ALGs.

I'm not convinced that BEHAVE needs to allow an ALG, though.

-d

---

From: Bryan Ford <[email-masked]>
Date: Mon, 28 Feb 2005 07:08:48 -0800 (PST)

Just a quick comment on an earlier part of the UDP unicast discussion, which 
I'm just now trying to catch up with... :)

> design probably doesn't belong in -ietf-behave-nat-.

True.  This pedagogy belongs in -behave-app-, and I've made a note to add some 
mention of this in the next rev of draft-ford-behave-app-??.txt.  Perhaps as 
part of a slightly longer discussion of how apps can properly secure 
cross-NAT connections including those created by hole punching.

Also...

On Tuesday 26 October 2004 08:31, Dan Wing wrote:
> BEHAVE needs a "how a UDP application can use a BEHAVE-capable NAT"
> document, which would provide guidance.  For example, it could explain
> things such as:
>
>   - use symmetric UDP behavior (for RTP applications, this would be
>     draft-wing-mmusic-symmetric-rtprtcp-01).
>   - use RFC3605 ("Real Time Control Protocol (RTCP) attribute in Session
>     Description Protocol (SDP)")
>   - keep NAT bindings alive by sending UDP messages from inside-to-
>     outside
>   - learn public NAT bindings using STUN
>   - know when STUN isn't necessary (for example, many folks think
>     STUN is necessary for SIP signaling itself, but STUN is for the
>     media stream).
>   - leak RTP and RTCP packets early (either RTP No-Op packets, silence
>     packets, STUN packets to the peer, STUN packets to the STUN server)
>   - when on hold or silence suppression, leak media to keep NAT
>     binding open
>
> many of these apply to VoIP applications, but many also apply to any
> other application behind a BEHAVE NAT that wants to use UDP as its
> transport.

Yes - excellent list; I've copied it into my "to-do" notes for 
draft-ford-behave-app-??.txt, to work on when I have the time.  (Text 
suggestions from you or others is welcome, of course.)

> I would like to see such a document added to the WG's agenda.

I've been assuming that this topic is more-or-less covered by this existing WG 
item:

Dec 05  Produce a BCP that discusses protocol design techniques for using the 
existing set of NAT traversal approaches 

...or is this different from what you had in mind?

Cheers,
Bryan

---

From: Dan Wing <[email-masked]>
Date: Mon, 28 Feb 2005 08:19:01 -0800 (PST)

On Feb 28, 2005, at 7:08 AM, Bryan Ford wrote:
...
I would like to see such a document added to the WG's agenda.
I've been assuming that this topic is more-or-less covered by this 
existing WG
item:

Dec 05  Produce a BCP that discusses protocol design techniques for 
using the
existing set of NAT traversal approaches

Same thing.

-d