Subject: [Ietf-behave] port-type preservation?

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 28 Sep 2004 23:16:08 -0700 (PDT)

Folks,

An interesting thread has been going on on the mmusic list, which is 
relevant to behave. The discussion was around NAT preservation of 
port-types, where the types are (for UDP) "well-known" from 0 to 1023, 
"registered" from 1024 to 49151, and "dynamic/private" from 49152 
through 65535. See:

http://www.ietf.org/mail-archive/web/mmusic/current/msg02902.html

If a NAT sees an outbound packet with one of these types, does it 
attempt to maintain the preservation? That is, should an outbound packet 
within the dynamic range always map to a port in the dynamic range?

I think the behave draft should probably say something about this. I 
suspect its probably a good idea to preserve the port-type.

-Jonathan R.
--
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
jdrosen@xxxxxxxxxxxxxxx                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 30 Sep 2004 10:07:53 -0700 (PDT)

Hi Jonathan,

I'm not sure I understand the logic.

Why would a well-known value be mapped to ANOTHER registered value? Are you saying
that we would map, say, the registered value for http to the registered value for,
say, FTP? 

I was thinking that what we need to say is that there is a mapping (i.e.,
in cases where the port number is not preserved), it shall always map to
the dynamic range.

I'm sure I'm misunderstanding what you are saying or missing something
obvious...

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@xxxxxxxxxxxxxxx] 
> Sent: Thursday, September 30, 2004 07:52
> To: Audet, Francois [SC100:9T51:EXCH]
> Cc: 'ietf-behave@xxxxxxxxxxxxxxxxxxx'
> Subject: Re: [Ietf-behave] port-type preservation?
> 
> 
> Almost.
> 
> What I'm saying is, if the source port on the private side is in the 
> dynamic range, the source port on the public side should 
> probably be in 
> that range. If the source port is in the registered range, so 
> too should 
> the source port on the public side, and same for the well-known range.
> 
> -Jonathan R.
> 
> Francois Audet wrote:
> 
> > So, if I understand correctly, you want us to put in the Behave 
> > document something saying that port binding assignments are 
> to be done 
> > from the dynamic/private port range 49152-65535?
> > 
> > Right?
> > 
> >  > -----Original Message-----
> >  > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx
> >  > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of  > 
> > Jonathan Rosenberg  > Sent: Tuesday, September 28, 2004 23:16
> >  > To: 'ietf-behave@xxxxxxxxxxxxxxxxxxx'
> >  > Subject: [Ietf-behave] port-type preservation?
> >  >
> >  >
> >  > Folks,
> >  >
> >  > An interesting thread has been going on on the mmusic 
> list, which is
> >  > relevant to behave. The discussion was around NAT preservation of
> >  > port-types, where the types are (for UDP) "well-known" from 0
> >  > to 1023,
> >  > "registered" from 1024 to 49151, and "dynamic/private" from 49152
> >  > through 65535. See:
> >  >
> > attempt to maintain the preservation? That is, should an outbound 
> > packet within the dynamic range always map to a port in the dynamic 
> > range?
> > 
> > _______________________________________________
> > Ietf-behave mailing list
> > Ietf-behave@xxxxxxxxxxxxxxxxxxx
> > https://list.sipfoundry.org/mailman/listinfo/ietf-behave
> > 
> 
> --

---

From: "Francois Audet" <[email-masked]>
Date: Sat, 2 Oct 2004 11:42:25 -0700 (PDT)

So, how do we achieve closure?

I think we can safely say:

(1) Bindings MUST NOT be assigned from the Well-known port range (0-1023). 

What do we say beyond that? I see the following alternatives:

(2a) Nothing. 

(2b) It is RECOMMENDED that a NAT SHOULD NOT map into ports in the registered range that are in fact registered.

(2c) It is RECOMMENDED that a NAT assing bindings from the Dynamic port range first, before using ports from the registered range.

I doubt that 2b-2c would be acceptable, considering current usage in major OSs, but they are only recommendations.

I'm happy with 2a, 2b and 2c, but my preference is 2a.

Jonathan? Dan?

-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@xxxxxxxxxxxxxxx]
Sent: Fri 10/1/2004 6:55 PM
To: Audet, Francois [SC100:9T51:EXCH]
Cc: 'Dan Wing'; 'ietf-behave@xxxxxxxxxxxxxxxxxxx'; 'Cullen Jennings'
Subject: Re: [Ietf-behave] port-type preservation?

Francois Audet wrote:

> Thanks Dan, this is extremelly useful.
> 
> My conclusions are:
> 
> (1) Bindings MUST NOT be assigned from the Well-known port range 
> (0-1023). I think
>     everybody agrees with that.

Yes. Thinking about it more, it doesn't make any sense to every assign 
ports in this range.

> 
> (2) I would tend to conclude that the bindings could be assigned from 
> any other
>     ports, depending on implementation, i.e. any ephemeral port or 
> dynamic port,
>     which means the whole 1024-65535.
> 
> I would therefore say that in the text, we will that UDP bindings MUST 
> not be assigned
> from the well-known port range (0-1023) and shall be assigned from the 
> 1024-65535
> range (without getting into details of ephemeral versus registered/dynamic.

Well, lets think about that.

As Dan pointed out, not all service ports are in the well-known range. 
Many aer in the registered range. Is there a reason to believe that its 
not ok to map a source port into 53, but it would be ok to map it into 
5060? The same concerns would apply - things in the network mistaking 
this packet as a response to a query on the service port.

Ideally, I would say that a NAT shouldn't map into well-known port or 
into ports in the registered range that are in fact registered. I 
suspect that this is an unreasonable requirement, since no nat vendor is 
going to want to periodially download the iana port assignment page and 
figure out whether a new port is assigned.

-Jonathan R.

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 7 Oct 2004 09:52:04 -0700 (PDT)

<FONT face=Arial color=#800000 
size=2>Personally, I'm also leaning on option 3 (which does not preclude a 
vendor using a configurable range within that: it's just we won't talk about it 
in the spec).
<BLOCKQUOTE 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #800000 2px solid; MARGIN-RIGHT: 0px">
  
  <FONT 
  face=Tahoma size=2>-----Original Message-----From: Cullen Jennings 
  [mailto:fluffy@xxxxxxxxx] Sent: Thursday, October 07, 2004 
  07:30To: Audet, Francois [SC100:9T51:EXCH]; 'Robert Sanders'; 
  Jonathan RosenbergCc: BehaveSubject: Re: [Ietf-behave] 
  port-type preservation?<FONT 
  face="Verdana, Helvetica, Arial">What do 
  people think of suggesting a configurable range that defaults to the dynamics 
  range and if the range is not configurable then do option 3. On NATs where you 
  are likely to run out, you are also likely to have admins that might change 
  the configuration. I don't know  if I like this idea or not, I lean 
  towards option 3.  On 10/5/04 3:15 PM, "Francois Audet" 
  <audet@xxxxxxxxxxxxxxxxxx> wrote:
  <FONT 
    face=Arial>Thanks Robert/Jonathan,<FONT 
    face="Verdana, Helvetica, Arial"><FONT 
    face=Arial>On your point 3 below, we already had agreed in a previous 
    discussions that "port preservation MAY be used". So I think we are 
    covered.<FONT 
    face="Verdana, Helvetica, Arial"><FONT 
    face=Arial>I think everybody agrees that recommending using the dynamic 
    range first is a good idea.<FONT 
    face="Verdana, Helvetica, Arial"><FONT 
    face=Arial>The suttle point yet to settle is after using all the dynamic 
    range, should we recommend:
    
      <FONT 
      face=Arial>Using  only the registered range (never the well-known 
      range) 
      <FONT 
      face=Arial>Using  the registered range first, and then the well-know 
      range upon  exhaustion<FONT 
      face="Verdana, Helvetica, Arial"> 
      <FONT 
      face=Arial>Using  either the registered or weel-known (don't 
      differentiate between the  two)<SPAN 
    style="FONT-SIZE: 12px">I don't think 
    anybody is arguing for 1. I think Jonathan is arguing for 3 and I'm OK with 
    it.If anybody has a preference, please let me know, otherwise I'll go 
    for 3.
    <FONT 
      face="Verdana, Helvetica, Arial"> <FONT 
      face=Tahoma>-----Original Message-----From: 
       ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx  [<A 
      href="mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx]">mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] 
      On Behalf Of Robert  SandersSent: Tuesday, October 
      05, 2004 14:14To: Jonathan  RosenbergCc: 
      BehaveSubject: Re: [Ietf-behave] port-type 
       preservation?<FONT 
      face="Verdana, Helvetica, Arial">Jonathan Rosenberg 
      wrote: 
      <FONT 
        face="Verdana, Helvetica, Arial">So, my  point was, if you believe 
        that this is a problem (and one might argue that  it is not), then 
        I see exactly the same problem for the registered ports. If  a NAT 
        maps a random UDP session onto 5060, then packets in and out of the 
         NAT will be mis-classified by anything that happens to be 
        listening as SIP.  <SPAN 
      style="FONT-SIZE: 12px">True, and 
      various firewalls and "Intrusion Prevention" devices  will react 
      badly to traffic appearing to be from certain services that does  not 
      conform to its expectation of that protocol.  For example, our 
       office's Checkpoints will drop malformed UDP packets from/to port 
      5060.   (As a matter of fact, it will drop many well-formed and 
      valid SIP packets from  that port, but that's a different story.) 
       This is not Checkpoint's ALG;  we have that 
      disabled. 
      <FONT 
        face="Verdana, Helvetica, Arial">Now, one  might argue that this 
        whole misclassification is nonsense, and that in an  era of NAT and 
        firewall bypassing by tunnelling over port 443, anyone who is 
         relying on ports for traffic classification is getting what they 
        deserve. I  believe there is still a fair amount of useful traffic 
        classification by  port that is happening, but YMMV. 
        <FONT 
      face="Verdana, Helvetica, Arial">I think that port-based  traffic 
      classification at the enterprise edge for security purposes is a 
       significant issue, which can be alleviated by using dynamic ports. 
         The intersection between applications common enough to 
      deserve  application-specific classification or filtering, and those 
      apps which use  "well known" ports from the dynamic range, should be 
      miniscule.If NATs  only map ports into the dynamic range, 
      then there is the potential scarcity  issue on very large NATs 
      mentioned before.  If they only prefer the  dynamic range, then 
      the behavior might be unpredictable (from a single host's  point of 
      view) on very large NATs which have exhausted their dynamic range 
       ports.  However, prefer-dynamic is at least as predictable as 
      having the  NAT randomly map into the entire registered+dynamic 
      range, and may avoid  falsely triggering some security 
      checks.So I'd propose this  modification of the rules that 
      Francois suggested: (1) Bindings which alter the source 
      port MUST NOT be assigned  from the Well-known port range 
      (0-1023). (2) It is RECOMMENDED that a NAT assign 
      bindings from the  Dynamic port range first, before using ports from 
      the registered  range.(3) A NAT MAY preserve a source port 
      exactly in a binding,  even if that port is from the well-known or 
      registered range.Rule 3  covers the Linux/Netfilter behavior, 
      which is a useful one for any protocol  which can use random source 
      ports.regards,  --  RobertP.S. By the 
      way, for those who are wondering who I am, I'm one  of the folks 
      involved in implementing EarthLink's recently announced free  (Free 
      World Dial-like) VoIP service.  My concerns right now are dominated 
       by voice/video and IM, plus a few other apps such as p2p sharing and 
       gaming.<SPAN 
    style="FONT-SIZE: 12px">
    
    <SPAN 
    style="FONT-SIZE: 10px">_______________________________________________Ietf-behave 
    mailing 
    listIetf-behave@xxxxxxxxxxxxxxxxxxxhttps://list.sipfoundry.org/mailman/listinfo/ietf-behave<FONT 
  size=2><SPAN 
style="FONT-SIZE: 10px">

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 7 Oct 2004 09:56:23 -0700 (PDT)

Makes sense to me.

We'll include.

> Sent: Thursday, October 07, 2004 09:54
> To: Cullen Jennings
> Cc: Audet, Francois [SC100:9T51:EXCH]; 'Robert Sanders'; Behave
> I think its fair to say that I'm arguing for 3.
> 
> Probably far more important than merely the recommendation is a 
> discussion on the issues; I don't want to preclude a nat vendor from 
> doing something smart, like actually tracking the ports that 
> are really 
> used amongst the ones that are registered (I think the vast 
> majority are 
> not in any real usage). Understanding why wading into the 
> well-known or 
> registered ranges can be problematic, is the key to allowing that.
> 
> -Jonathan R.
> 
> Cullen Jennings wrote:
> 
> > 
> > What do people think of suggesting a configurable range 
> that defaults 
> > to
> > the dynamics range and if the range is not configurable 
> then do option 
> > 3. On NATs where you are likely to run out, you are also 
> likely to have 
> > admins that might change the configuration. I don't know  
> if I like this 
> > idea or not, I lean towards option 3.  
> > 
> > 
> > On 10/5/04 3:15 PM, "Francois Audet" 
> >     Thanks Robert/Jonathan,
> >     On your point 3 below, we already had agreed in a previous
> >     covered.
> >     I think everybody agrees that recommending using the 
> dynamic range
> >     first is a good idea.
> > 
> >     The suttle point yet to settle is after using all the 
> dynamic range,
> >     should we recommend:
> > 
> >        1. Using  only the registered range (never the 
> well-known range)
> >        2. Using  the registered range first, and then the well-know
> >           range upon  exhaustion
> >        3. Using  either the registered or weel-known (don't
> >           differentiate between the  two)
> > 
> >     I don't think anybody is arguing for 1. I think 
> Jonathan is arguing
> >     for 3 and I'm OK with it.
> >     If anybody has a preference, please let me know, 
> otherwise I'll go
> >     for 3.
> > 
> > 
> >          
> >         *From:*  ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx
> >          [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] 
> *On Behalf Of
> >         *Robert  Sanders
> >         *Sent:* Tuesday, October 05, 2004 14:14
> >         *To:* Jonathan  Rosenberg
> >         *Cc:* Behave
> >         *Subject:* Re: [Ietf-behave] port-type  preservation?
> > 
> >         Jonathan Rosenberg wrote:
> >          
> > 
> >             So, my  point was, if you believe that this is a problem
> >             (and one might argue that  it is not), then I 
> see exactly
> >             the same problem for the registered ports. If  
> a NAT maps a
> >             random UDP session onto 5060, then packets in 
> and out of the
> >             listening as SIP.
> >         True, and various firewalls and "Intrusion 
> Prevention" devices
> >          will react badly to traffic appearing to be from certain
> >         services that does  not conform to its expectation of that
> >         protocol.  For example, our  office's Checkpoints will drop
> >         malformed UDP packets from/to port 5060.   (As a 
> matter of fact,
> >         it will drop many well-formed and valid SIP packets 
> from  that
> >         port, but that's a different story.)  This is not 
> Checkpoint's
> >         ALG;  we have that disabled.
> > 
> >          
> > 
> >             Now, one  might argue that this whole 
> misclassification is
> >             nonsense, and that in an  era of NAT and 
> firewall bypassing
> >             by tunnelling over port 443, anyone who is  
> relying on ports
> >             for traffic classification is getting what they 
> deserve. I
> >              believe there is still a fair amount of useful traffic
> >         I think that port-based  traffic classification at the
> >         enterprise edge for security purposes is a  
> significant issue,
> >         which can be alleviated by using dynamic ports.    The
> >         intersection between applications common enough to deserve
> >          application-specific classification or filtering, and those
> >         apps which use  "well known" ports from the dynamic range,
> >         should be miniscule.
> > 
> >         If NATs  only map ports into the dynamic range, 
> then there is
> >         the potential scarcity  issue on very large NATs mentioned
> >         before.  If they only prefer the  dynamic range, then the
> >         behavior might be unpredictable (from a single 
> host's  point of
> >         view) on very large NATs which have exhausted their dynamic
> >         range  ports.  However, prefer-dynamic is at least as
> >         predictable as having the  NAT randomly map into the entire
> >         registered+dynamic range, and may avoid  falsely 
> triggering some
> >         security checks.
> > 
> >         So I'd propose this  modification of the rules that Francois
> >         suggested:
> >          
> > 
> >         (1) Bindings which alter the source port MUST NOT 
> be assigned
> >          from the Well-known port range (0-1023).
> >          
> > 
> >         (2) It is RECOMMENDED that a NAT assign bindings from the
> >          Dynamic port range first, before using ports from the
> >         registered  range.
> >         (3) A NAT MAY preserve a source port exactly in a 
> binding,  even
> >         if that port is from the well-known or registered range.
> > 
> >         Rule 3  covers the Linux/Netfilter behavior, which 
> is a useful
> >         one for any protocol  which can use random source ports.
> > 
> >         regards,
> >           --  Robert
> > 
> >         P.S. By the way, for those who are wondering who I 
> am, I'm one
> >          of the folks involved in implementing EarthLink's recently
> >         announced free  (Free World Dial-like) VoIP service.  My
> >         concerns right now are dominated  by voice/video 
> and IM, plus a
> >         few other apps such as p2p sharing and  gaming.
> > 
> > 
> >     
> --------------------------------------------------------------
> ----------