Subject: Re: [BEHAVE] SCTP NAT questions and concerns

From: "Dan Wing" <[email-masked]>
Date: Tue, 16 Dec 2008 18:13:57 -0800

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Michael Tüxen
> Sent: Friday, November 21, 2008 11:53 AM
> To: Jonathan Lennox
> Cc: Behave WG
> Subject: Re: [BEHAVE] SCTP NAT questions and concerns
> 
> On Nov 21, 2008, at 1:45 PM, Jonathan Lennox wrote:
> 
> > On Friday, November 21 2008, "Michael Tüxen" wrote to "Jonathan  
> > Lennox, Randall Stewart, Behave WG" saying:
> >
> >> No. Both sides need to know the port number and external address
> >> used by the peer. The port numbers do not change, so it is mostly
> >> the IP-address which needs to be learned. See section 12.5 of
> >> 
> http://www.ietf.org/internet-drafts/draft-ietf-behave-sctpnat-00.txt
> >> for the message flow.
> >
> > I'm confused about the step in that flow described as:
> >
> >                VTag != Int-VTag, but Ext-VTag == 0, find entry.
> >
> > What happens if there are multiple entries matching the 
> local port and
> > remote address and port, from different internal hosts?
> This would mean that the are multiple clients behind the left NAT
> choosing the same random port number that want to communicate with
> the same peer behind the right NAT at the same time! I consider this
> pretty unlikely, but we can restrict these entry to one.

With the carrier grade NATs being considered by many ISPs to
deal with upcoming IPv4 exhaustion, and the translation boxes
to deal with the transition from IPv4 to IPv6, I worry that

> The left NAT box can send an ABORT back...

Which forces the host to choose a different port, until it
chooses one that isn't already in use by anyone else behind
that same NAT.  But, worse, it forces the host to re-do its
rendezvous with its peer (that is, tell the peer the new
port).  Additional discussion of this in the draft would
be worthwhile; currently it only says:

   However, it is possible that there is already a NAT control block
   with the same External-Address, External-Port, External-VTag,
   Internal-VTag but different Private-Address.  In this case the INIT
   SHOULD be dropped and an ABORT MAY be sent back.
                                  ^^^

it seems the NAT *needs* to send back an ABORT in that case, or
else the host will unnecessarily re-transmit its INIT until it
silently times out, right?

-d

_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 16 Dec 2008 18:13:51 -0800

> Sent: Friday, November 21, 2008 11:06 AM
> To: Jonathan Lennox
> Cc: Behave WG
> On Nov 21, 2008, at 9:51 AM, Jonathan Lennox wrote:
> 
> > On Thursday, November 20 2008, "Randall Stewart" wrote to "Bruce  
> > Lowekamp, Behave WG" saying:
> >
> >> On Nov 20, 2008, at 3:59 PM, Bruce Lowekamp wrote:
> >>> My understanding of the current situation is that ports in sctp  
> >>> never
> >>> change (essentially port overloading is always used), but  
> >>> connections
> >>> are identified by vtag.  That means that an unsolicited 
> connection  
> >>> can
> >>> never be delivered inbound, however it also means that 
> simultaneous
> >>> open essentially always works through exchange of vtags through an
> >>> ice-like mechanism.
> >>
> >> Its not an ICE like mechanism.. its is the basic protocol. The  
> >> protocol
> >> is designed to handle all the collision cases of 
> simultaneous open  
> >> and
> >> that is what we do here.. .it is in the draft I believe.. feedback
> >> would be appreciated...
> >
> > I believe the point Bruce was making is that for simultaneous-open  
> > to work
> > (when both endpoints are behind NATs), each party's vtag needs to be
> > communicated via the rendezvous server, just as its port and  
> > external IP
> > address is.

Michael,

In section 12.5, I see the following:

 NAT A creates entry:
        +---------+--------+-----------+----------+--------+-----------+
 NAT A  |  Int    |  Int   |    Priv   |   Ext    |   Ext  |    Ext    |
        |  VTag   |  Port  |    Addr   |   VTag   |   Port |    Addr   |
        +---------+--------+-----------+----------+--------+-----------+
        |  1234   |    1   |  10.0.0.1 |     0    |    2   | 100.0.0.1 |

        +---------+--------+-----------+----------+--------+-----------+

                         INIT[Initiate-Tag = 1234]
                101.0.0.1:1 ----------------> 100.0.0.1:2
                                 Ext-VTag = 0

I believe the line:

                101.0.0.1:1 ----------------> 100.0.0.1:2

should have "10.0.0.1" on the left (rather than "101.0.0.1")?

Also, it appears the state table shows the internal host has port 1, but 
the external mapping has port 2 -- a different port.  Is that right?

-d

> >
> >>> I missed the discussion of the issue in Section 6, "Handling of
> >>> internal port number collisions" during the presentation.  My  
> >>> reading
> >>> of this section is that it requires every host on the internet
> >>> implementing sctp to implement this new NAT_SUPPORTED 
> tag, otherwise
> >>> two hosts behind the same NAT cannot exchange data with 
> them.  Is  
> >>> SCTP
> >>> at a point where this global change is considered feasible?
> >>
> >> The NAT supported tag is only needed when:
> >>
> >> 1) Two hosts behind a nat decide to talk to  the same server
> >> 2) Both hosts of course are talking to the same IP address and port
> >> 3) Both hosts pick the same source port
> >> 4) Both hosts pick the same vtag...
> >>
> >> It is unlikely but it can happen.. and this is where the  
> >> NAT_SUPPORTED
> >> tag comes in.. it basically disables the restart feature of an  
> >> association.
> >
> > For this to work, is it required that the remote server also  
> > implements
> > NAT_SUPPORTED?
> >
> > -- 
> > Jonathan Lennox
> > [email-masked] / [email-masked]