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

From: "Francois Audet" <[email-masked]>
Date: Mon, 18 Oct 2004 16:58:12 -0700 (PDT)

Thanks 
Senthil. 
See 
below for answers.
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #800000 2px solid; MARGIN-RIGHT: 0px">
  
  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> 
<SPAN 
class=823092923-18102004>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.
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #800000 2px solid; MARGIN-RIGHT: 0px">
  <SPAN 
  class=823092923-18102004> 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. 
<SPAN 
class=823092923-18102004>I'm not sure 
I understand your comment. What do you mean by "applications that do not 
have port information like DNS"? 
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #800000 2px solid; MARGIN-RIGHT: 0px">
  Section 6:Is 
  different ALG behaviors based on UDP is out of scope?
<SPAN 
class=823092923-18102004>Yes. 

<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #800000 2px solid; MARGIN-RIGHT: 0px">
  <SPAN 
  class=823092923-18102004> General comment:NATs have different 
  behavior based on what it is configured to do. So the portpreservation and 
  filtering 
<SPAN 
class=823092923-18102004>Your sentence is 
incomplete...
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #800000 2px solid; MARGIN-RIGHT: 0px">
  <SPAN 
  class=823092923-18102004> 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. 
<SPAN 
class=823092923-18102004>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.
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #800000 2px solid; MARGIN-RIGHT: 0px">
  <SPAN 
  class=823092923-18102004> 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” ?
<SPAN 
class=823092923-18102004>Correct. This is 
a typo. I will make the change.
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #800000 2px solid; MARGIN-RIGHT: 0px">
  <SPAN 
  class=823092923-18102004> 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. 
<SPAN 
class=823092923-18102004>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.
<SPAN 
class=823092923-18102004><FONT face=Arial color=#800000 
size=2> 
<SPAN 
class=823092923-18102004>Is this a 
weakness of RCP itself?
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #800000 2px solid; MARGIN-RIGHT: 0px">
  <SPAN 
  class=823092923-18102004> 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. <SPAN 
  class=823092923-18102004><FONT face=Arial color=#800000 
  size=2> 
  <SPAN 
  class=823092923-18102004> 
<SPAN 
class=823092923-18102004>I'll remove the 
word "Dynamic". It was "dynamic" as opposed to "static NAT binding" (in which 
case there is obviously no timeouts).
<SPAN 
class=823092923-18102004><FONT face=Arial color=#800000 
size=2> 
<SPAN 
class=823092923-18102004>If applications 
are using their own timeouts, then by definition they require their own 
ALG.
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #800000 2px solid; MARGIN-RIGHT: 0px">
  <SPAN 
  class=823092923-18102004> 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.<SPAN 
  class=823092923-18102004><FONT face=Arial color=#800000 
  size=2> 
<SPAN 
class=823092923-18102004>Perhaps our 
wording is a little bit strong. Their might be some other protocols that require 
ALGs that we can't think of. 
<SPAN 
class=823092923-18102004><FONT face=Arial color=#800000 
size=2> 
<SPAN 
class=823092923-18102004>Would replacing 
the "MUST" by a "SHOULD" be appropriate?
<SPAN 
class=823092923-18102004><FONT face=Arial color=#800000 
size=2> 
<SPAN 
class=823092923-18102004>Should we instead 
replace "DNS and IPsec" with something like "protocols who require ALGs such as 
DNS and IPsec"?
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #800000 2px solid; MARGIN-RIGHT: 0px">
  <SPAN 
  class=823092923-18102004>          
  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=Arial color=#800000 size=2> 
<SPAN 
class=823092923-18102004>I assume you 
would like section 10 to cover the timeout for this? Any suggestions on what it 
should say?
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #800000 2px solid; MARGIN-RIGHT: 0px">
  <SPAN 
  class=823092923-18102004> Minor ones:REQ-13 and 
  REQ-13: should be Req-13 and Req-14.<FONT 
  face=Arial color=#800000 size=2> 
<SPAN 
class=823092923-18102004>I'm not sure what 
happened here for this one as I had made that correction before. I assume the 
wrong version was posted.
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #800000 2px solid; MARGIN-RIGHT: 0px">
  <SPAN 
  class=823092923-18102004> Senthil

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 25 Oct 2004 06:59:06 -0700 (PDT)

On 10/18/04 7:57 PM, "Francois Audet" <audet@xxxxxxxxxxxxxxxxxx> wrote:

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

My apologies to Francois on this -  he had already fixed this in a revision
and I lost the change (and some others) in a merge.

Cullen