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

From: "Francois Audet" <[email-masked]>
Date: Tue, 5 Oct 2004 15:16:02 -0700 (PDT)

Thanks 
Robert/Jonathan,
<FONT face=Arial color=#800000 
size=2> 
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=Arial color=#800000 
size=2> 
I 
think everybody agrees that recommending using the dynamic range first is a good 
idea.
<FONT face=Arial color=#800000 
size=2> 
The 
suttle point yet to settle is after using all the dynamic range, should we 
recommend:

  Using 
  only the registered range (never the well-known range)
  Using 
  the registered range first, and then the well-know range upon 
  exhaustion
  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.
<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: 
  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?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 
    NAT will be mis-classified by anything that happens to be 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 classification by 
    port that is happening, but YMMV. 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.

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 7 Oct 2004 08:15:01 -0700 (PDT)

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:

Thanks Robert/Jonathan,
 
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.
 
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:
Using  only the registered range (never the well-known range) 
Using  the registered range first, and then the well-know range upon  exhaustion 
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.

-----Original Message-----
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  NAT will be mis-classified by anything that happens to be 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 classification by  port that is happening, but YMMV. 
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.

_______________________________________________
Ietf-behave mailing list
Ietf-behave@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/ietf-behave

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 7 Oct 2004 09:54:25 -0700 (PDT)

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.  

    Thanks Robert/Jonathan,

    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.
    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.
         
        -----Original Message-----
        *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?

            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.  

        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
            classification by  port that is happening, but YMMV.
        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:

        (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.
    ------------------------------------------------------------------------
    _______________________________________________
    Ietf-behave mailing list
    Ietf-behave@xxxxxxxxxxxxxxxxxxx
    https://list.sipfoundry.org/mailman/listinfo/ietf-behave

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