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

From: Senthil Sivakumar <[email-masked]>
Date: Wed, 20 Oct 2004 16:40:45 -0700 (PDT)

At 05:54 PM 10/20/2004 -0400, Francois Audet wrote:

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. 
There are NATs that do that 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). 

I would vote for the first one, I don't see any reason where NATs must
have to support
an ALG. 

Senthil

Any views of which approach is best?

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 20 Oct 2004 18:41:26 -0700 (PDT)

I guess I was beaten to it... Thanks Saikat!

Indeed, the reason we gave hairpinning a MUST is that it "fixes" problems 
that happen when applications don't use ICE. There are certainly other examples.

Of course, doing ICE will ensure that you always have the optimum path.

Your suggestion (2) is something that we discussed earlier, and decided against
because there were too many cases where it didn't help and where it may
break the deterministic behavior rule.

Please see the archive: http://list.sipfoundry.org/archive/ietf-behave/maillist.html#00129

-----Original Message-----
From: Kaushik Biswas [mailto:kbiswas@xxxxxxxxx] 
Sent: Wednesday, October 20, 2004 17:51
To: Audet, Francois [SC100:9T51:EXCH]
Cc: 'Senthil Sivakumar'; 'Dan Wing'; 'Behave'
Subject: RE: [Ietf-behave] New draft on UDP unicast behavior 

In addition, couple of points:

(1) Why should hairpinning be a must:
REQ-9: A NAT MUST support "Hairpinning" behavior. Hairpinning allows two endpoints on the internal side of the NAT to communicate even if they only use each other's external IP addresses    and ports. 

This may be a nice-to-have support in a NAT, but why should it be a must.

The inside host A should be trying to reach the inside host B, via the private-address and not via the NAT'd address of B. Why come through NAT and add an extra-hit in processing-time.

(2) Also, why don't we mandate the RTP/RTCP port-allocation to be successive. For eg: if the request is for the embedded media-port = 20000, then NAT should allocate n-successive ports. If NAT is supporting port-preservation then 20000, 20001,..., should be allocated. If it is not supporting port-preservation then the next n-successive free ports in the range 1024 - 65535.

Thanks,
Kaushik

At 07:50 PM 10/20/2004 -0400, Francois Audet wrote:

OK, I think we have concensus on the following. 

11 - Requirements 

   REQ-3c:  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. 

REQ-10:  If a NAT includes ALGs, all of those ALGs MUST be 
         disabled by default. 
  
    REQ-10a:  If a NAT includes ALGs, it is RECOMMENDED that 
              the NAT allow the user to enable or disable each 
              ALG separately.  

11.1 - Requirements discussion 

   REQ-3c:  Certain applications expect the source UDP port to be 
            in the well-known range. See RFC 2623 for an example. 

REQ-10:  NAT ALGs may interfere with UNSAF methods. 
  
    REQ-10a:  This requirement allows the user 
              to enable ALGs which are necessary to aid operation 
              of some applications without enabling ALGs which 
              interfere with operation of other applications. 
_______________________________________________
Ietf-behave mailing list
Ietf-behave@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/ietf-behave