Subject: RE: SCTP-over-UDP and port 9899

From: "Dan Wing" <[email-masked]>
Date: Tue, 1 Nov 2011 08:47:30 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Michael Tuexen
> Sent: Monday, October 31, 2011 2:27 PM
> To: Dan Wing
> Cc: [email-masked]; [email-masked]
> Subject: Re: SCTP-over-UDP and port 9899
> 
> On Oct 31, 2011, at 9:10 PM, Dan Wing wrote:
> 
> > http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-udp-encaps-01 and
> its
> > predecessor both say:
> >
> >  "When inserting the UDP header, the source port is 9899, the
> >   destination port is the one stored for the destination address the
> >   packet is sent to or 9899 if no destination address is stored."
> >
> > Why is it important to use a specific source port?  Does that not
> > cause difficulties if there are two (or more) instances of SCTP-
> > over-UDP applications running on the same host?  Does that not
> > cause difficulties, in implementation assumptions, if there are
> > two hosts behind the same NAPT and only one can get UDP/9899
> > forwarded to them?
> Hi Dan,
> 
> for sending out the initial packet of an association, the source
> port is not important.

Then can you strike "the source port is 9899" from the document?

> The peer will send back the response to any
> port. But the destination port of the initial packet is important.
> It must be the same port the peer is accepting UDP packets. It
> can be any port, but then it needs to be negotiated somehow.

Sure, of course.

The 32-bit or 128-bit IP address is already negotiated.  
Negotiating another 16 bits is not onerous.  It isn't easy
with DNS (because neither SRV records nor the ability to
update them is ubiquitous), but lots of protocols already
communicate IP address and port -- BitTorrent, Skype, SIP,
many others.

> Since there is one registered port for SCTP/UDP, I used that.
> But you can use a different one, if negotiated. If you want to
> run two hosts as servers behind a NAT, you need different UDP
> ports. If they are clients, you don't.
>
> > In short, what is the benefit of using 9899 as the source port?
> It is more a default, if nothing else is known. In the socketAPI
> section the remote port is configurable. The local port (at
> least in the FreeBSD/MacOS X implementation) is a parameter
> controller by a sysctl variable. So (currently) a single
> host uses a single port number for all associations.
> 
> Does this makes things clearer?

Not especially, no.

Let's look at, for example, SSH -- the SSH port is 22.   But
there is no need for the *source port* to be 22.  I'm trying
to understand why there is text mentioning anything about
the source port in draft-ietf-tsvwg-sctp-udp-encaps.

-d

> Best regards
> Michael
> > -d

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 1 Nov 2011 17:49:34 +0100

> the source port in draft-ietf-tsvwg-sctp-udp-encaps.
OK, this is a good example. I want 9899 for SCTP/UDP be similar
to 22 for SSH. But there is a difference. I want to support the
case where I have one SCTP stack on a host and this stack uses
a single UDP port number shared between all associations, no
matter which side initiated them. I might not have made that
clear. So it different from SSH where the server binds to a
well known port (or not if otherwise negotiated), the client
uses an arbitrary one. Do you have a suggestion for the wording?

Best regards
Michael

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 1 Nov 2011 10:15:39 -0700

> From: Michael Tuexen [mailto:[email-masked]]
> Sent: Tuesday, November 01, 2011 9:50 AM
> To: Dan Wing
> matter which side initiated them.

But a major use-case for SCTP-over-UDP is when the application
itself has its own SCTP stack.  This is even mentioned in 
your I-D.  For that use-case, the two applications cannot
achieve your desired goal.

> I might not have made that

Yes, remove the wording saying 9899 is the source port.  

Suggest:

  It can be advantageous for all SCTP-over-UDP traffic originated by a
  host to use the same source port (e.g., this reduces the number of
  mappings in firewalls and NATs, among other things).  It is possible
  to use the same UDP source port by using the SCTP header to
  demultiplex the incoming traffic (rather than demultiplexing solely
  on UDP port number). When SCTP-over-UDP is implemented by a shared
  library (e.g., a framework or by the OS itself), this optimization
  is possible.  When SCTP-over-UDP is implemented by an application,
  this optimization is usually not possible.

-d

---

From: Joe Touch <[email-masked]>
Date: Tue, 01 Nov 2011 11:18:14 -0700

On 11/1/2011 10:15 AM, Dan Wing wrote:
...
> Yes, remove the wording saying 9899 is the source port.

Agreed.

FWIW, 9899 is reserved in IANA, but IANA assigns only *destination* ports.

Source ports are not assigned. So just because a port is assigned does 
not mean it has any meaning solely as a source port. Source port meaning 
is based only on the socket-pair tuple (src addr, src port, dst addr, 
dst port).

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 01 Nov 2011 11:20:40 -0700

> FWIW, 9899 is reserved in IANA, but IANA assigns only *destination* ports.

Correction - "reserved" is not meant in the IANA sense. It is "assigned" 
(to SCTP over UDP), specifically.

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 1 Nov 2011 20:58:55 +0100

> achieve your desired goal.
I agree.
>  this optimization is usually not possible.
OK. Thank you very much. What about the following changes:

Adding to the subsection 4.1 (Architectural Considerations):

   Each SCTP stack uses a single local UDP encapsulation port number as
   the source port for all of its outgoing SCTP packets and as the
   destination port for all its incoming SCTP packets.  The IANA
   assinged value of 9989 MAY be used as this port number.  If there is
   only a single SCTP implementation on a host (for example, a kernel
   implementation being part of the operating system), using a single
   UDP encapsulation port number per host can be advantageous (e.g.,
   this reduces the number of mappings in firewalls and NATs, among
   other things).  However, this is not possible if the SCTP stack is
   implemented as part of an application.

Changing the beginning of subsection 4.3 (Encapsulation Procedure):

   When inserting the UDP header, the source port is local UDP
   encapsulation port number of the SCTP stack, the destination port is
   the remote UDP encapsualtion port number stored for the destination
   address the packet is sent to (see Section 4.1).

Does this address your issue completely? I just want to mention that it
might be good to use the IANA assigned number when possible.

Best regards
Michael

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 1 Nov 2011 14:56:44 -0700

> Sent: Tuesday, November 01, 2011 12:59 PM
> To: Dan Wing
..........................................................^^^^^^^^
>    assinged value of 9989 MAY be used as this port number.  If there is
.....^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>    implemented as part of an application.

Remove the suggestion that the IANA port be used as the source port.

> might be good to use the IANA assigned number when possible.

But it is equally good to let the source UDP port be chosen by 
the operating system -- same as with nearly everything else.

-d

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 1 Nov 2011 23:25:24 +0100

>>   destination port for all its incoming SCTP packets.  The IANA
I do understand your point. However:

RFC 4253 (SSH) states:

When used over TCP/IP, the server normally listens for connections on
port 22.

RFC 2616 (HTTP) states:
HTTP communication usually takes place over TCP/IP connections. The
default port is TCP 80 [19], but other ports can be used.

Please note that the local UDP encapsulation port is the destination
port of the received packets. Similar to 80 for HTTP and 22 for SSH.
Since we have an IANA assigned port, I would like to encourage
people to use it when possible. I guess this is OK, or isn't it?

That is why I used a MAY. But I'm open to use any other formulation.
Do you have a suggestion?

Best regards
Michael

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 1 Nov 2011 15:46:17 -0700

> Sent: Tuesday, November 01, 2011 3:25 PM
> To: Dan Wing

For the server, yes, that's okay.  That is what IANA-registered
default ports are all about.

> Do you have a suggestion?

Yes -- be silent about the source port.  Say nothing in the
document about the source port.

-d

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 2 Nov 2011 00:17:21 +0100

> default ports are all about.
But the SCTP stack is neither a client nor a server...
> document about the source port.
I just talk about the local UDP encapsulation port...
However, it is the destination port of incoming packets and
the source port of outgoing packets (as every local port
number is).

Would it be acceptable for you if I replace

Each SCTP stack uses a single local UDP encapsulation port number
as the source port for all of its outgoing SCTP packets
and as the destination port for all its incoming SCTP packets.

by

Each SCTP stack uses a single local UDP encapsulation port number.

However, later on I'm saying that the local UDP port is used
as the source port for outgoing packets. I think I have to say
that, since I need to say what the source and destination port
of the inserted UDP are.

Best regards
Michael

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 1 Nov 2011 19:27:39 -0700

> But the SCTP stack is neither a client nor a server...

"Bullpucky".  Next you're going to say that "peer to peer" 
doesn't have a client and a server.

> that, since I need to say what the source and destination port

Do you understand why I am concerned with specifying the 
source UDP port number?  It gets re-written by NATs, and
the primary reason for this draft is to allow SCTP to work
when behind a NAT.

-d

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 2 Nov 2011 12:35:01 +0100

> doesn't have a client and a server.
No, I mean it seriously: The local UDP encapsulation port number
is a variable of the stack (for example in the FreeBSD kernel
configurable via a sysctl variable). If you want to use one
number if the application will ever call listen() and a different
one it it calls never listen(), how should the stack decide that?
Same for a userland stack...
> the primary reason for this draft is to allow SCTP to work
I'm not sure why you are concerned.
The ID says: Use 9899 when possible as the local encapsulation
port (I'm using MAY). For outgoing packets this local encapsulation
port number is use as the source port by the sending host.
Of course, it can be rewritten on the path to the receiver and
that is fine. The peer will store the possibly changed source
port as its remote encapsulation port number. This is (at least
I think) described in the ID. This is the processing which
you want to be supported, I think, and of course it is.

Just to be clear: If the sender puts some number in the source
port field, it can not be assumed that the same value is there
when the packet is received. I know that and that is handled.

Put it in other words:
* Each SCTP stack chooses a local encapsulation port. Right?
* Why not choose, when possible, the 9899. Possible or not?
I don't see that anything breaks.

Best regards
Michael