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

From: "Dan Wing" <[email-masked]>
Date: Fri, 2 Dec 2011 22:41:46 -0800

> -----Original Message-----
> From: Michael Tuexen [mailto:[email-masked]]
> Sent: Wednesday, November 02, 2011 4:35 AM
> To: Dan Wing
> Cc: [email-masked]; [email-masked]
> Subject: Re: SCTP-over-UDP and port 9899
> 
> On Nov 2, 2011, at 3:27 AM, Dan Wing wrote:
> 
> >>> For the server, yes, that's okay.  That is what IANA-registered
> >>> default ports are all about.
> >> 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.
> 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...

Probably just a terminology disagreement.  To my mind, everything
is client/server, based on who sends the first packet (the client)
and who receives the first packet (server).

> >>>> That is why I used a MAY. But I'm open to use any other
> formulation.
> >>>> Do you have a suggestion?
> >>>
> >>> Yes -- be silent about the source port.  Say nothing in the
> >>> 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.
> >
> > 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.
> I'm not sure why you are concerned.

Because I don't understand why the I-D insists on specifying
the source port (no other protocol does, that I'm aware of),
and it will cause problems when multiple SCTP-over-UDP
clients are running on the same host.  One of them will likely
be written to insist, strongly, that it get port 9899. 

If there is no reason/benefit/value/advantage to use source 
port 9899, then please remove the text from the I-D.  This
follows the dictum that a standard is finished when everything
unnecessary has been removed and it still works. 

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

-d

> Best regards
> Michael
> > -d
> >> Best regards
> >> Michael
> >>> -d
> >>>> Best regards
> >>>> Michael
> >>>>> -d
> >>>>>> Best regards
> >>>>>> Michael
> >>>>>>> -d
> >>>>>>>> Best regards
> >>>>>>>> Michael
> >>>>>>>>> -d
> >>>>>>>>>> Best regards
> >>>>>>>>>> Michael
> >>>>>>>>>>> -d

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 04 Dec 2011 11:37:28 +0200

I agree with Dan. Using a fixed source port does not appear to be useful.

---

From: Michael Tuexen <[email-masked]>
Date: Sun, 4 Dec 2011 11:34:01 +0100

> be written to insist, strongly, that it get port 9899. 
The text I have in the CVS version reads:

<t>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 assigned 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.</t>

I think we agree on the section except for the sentence:

The IANA assigned value of 9989 MAY be used as this port number.

I think this is as weak as possible.

It is already made clear that running multiple SCTP stacks on a
host make it not possible to use the same port for all stacks.
> unnecessary has been removed and it still works. 
I agree with this statement. However, I think there is some value:

sctp.fh-muenster.de runs a stack with UDP encapsulation with a public address.
So I can reach that machine from home (behind a NAT) without any negotiation by
assuming/hoping that it uses 9989. Also multiple  local boxes (behind a NAT)
each use 9989 as the local bound port. But the point here is that I'm only running one
stack per host.

If we remove the above sentence, I have no idea which port to try and
can only use UDP encapsulation in combination with some other protocol
giving me the port number.

Would you find the following be acceptable for you:

<t>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.
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) and the IANA assigned value of 9989 MAY
be used as this port number.
However, this is not possible if the SCTP stack is implemented as
part of an application.</t>

This only mentions 9989 in case of running a single stack...

So do you see any value in my above usage scenario?

Sorry for insisting on this... I do see some value and would like to
understand what I'm misunderstanding...

Best regards
Michael

---

From: Michael Tuexen <[email-masked]>
Date: Sun, 4 Dec 2011 12:23:44 +0100

> I agree with Dan. Using a fixed source port does not appear to be useful.
I'm not suggesting a fixed port. I'm only suggesting that when the stack
(possibly under the assumption that there is only one on the host, i. e.
a kernel based) binds a UDP socket, it MAY use 9989.

Best regards
Michael

---

From: Randy Stewart <[email-masked]>
Date: Sun, 4 Dec 2011 11:02:23 -0500

I agree with Michael here. Having the port assigned by IANA as a MAY
is only a weak reference. It does *not* restrict anyone from using any
port. His argument is sound, in the lack of any other knowledge  you should try
the IANA port.

I would imagine the http document *probably* mentions the IANA assigned port 80, not
saying you *must* use it… but mentioning it so that apps have a choice of port of
last resort so to speak.

I see no difference here.. and think the current wording makes sense…

R

>>>> I don't see that anything breaks.

-----
Randall Stewart
[email-masked]

---

From: Randy Stewart <[email-masked]>
Date: Sun, 4 Dec 2011 11:24:19 -0500

one follow up here, when I say the current wording, I mean
whats in the current draft as put by Michael in this thread…

R

-----
Randall Stewart
[email-masked]

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sun, 4 Dec 2011 16:15:58 -0700

+1

Hannes Tschofenig wrote:                                 (Sun, 04 Dec 2011 11:37:28)

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: Chris Benson <[email-masked]>
Date: Tue, 6 Dec 2011 12:39:04 -0800 (PST)

Hi folks,

I believe that Michael's statement regarding port number is 
not restrictive, and contains a possibly useful suggestion 
for a port number.

I think Michael's I-D is clearer for containing a suggestion
of using its own IANA assigned port number than it would be 
without mentioning it.  To me it is clear that the specified
port number isn't REQUIRED, but is just a SUGGESTION.  It is
necessary to choose one local encapsulation port number 
(assuming one local SCTP).  I'd be happy to use the IANA 
assigned port 9989, because there possibly a better chance 
that it will be available to me, and not already in use as
a fixed port number of some other unrelated protocol.

There are plenty of protocols with similar or analogous 
statements, usually for recommended listener server port 
selection, which is another way of saying that HTTP servers 
SHOULD use port 80 as their source port etc.  M3UA, SUA, M2PA 
etc. all specify [recommend] one "source port" for data sent
from the role of server.

It shouldn't cause too much grief, because as a suggestion 
only, it can safely be ignored by any 9989-haters.

With thanks, from Chris.

On Sun, 4 Dec 2011, Randy Stewart wrote:

>>  Date: Sun, 4 Dec 2011 11:02:23 -0500
>>  From: Randy Stewart <[email-masked]>
>>  To: Michael Tuexen <[email-masked]>
>>  Cc:  <[email-masked]>, Dan Wing <[email-masked]>

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 6 Dec 2011 15:10:38 -0800

> From: Chris Benson [mailto:[email-masked]]
> Sent: Tuesday, December 06, 2011 12:39 PM
> To: Michael Tuexen
> Cc: [email-masked]; Dan Wing; Randy Stewart
> (assuming one local SCTP). 

Maybe we are finally getting to the root of the problem.  I
hope so.

I will ask:  why is it necessary to have one local encapsulation
port number?

For example, why can't I use source port 5555 from my IPv4
interface and use source port 8888 from IPv6 interface?  What
breaks?

Afterall, a NAT44 or NAT64 (and 4rd, Dual-IVI, and SD-NAT,
and every other IPv4 address sharing technique on the table)
will rewrite whatever local UDP encapsulation port that is 
chosen by the application developer, anyway.  

> I'd be happy to use the IANA

An ephemeral, chosen by the operating system, will always
be free and available to be used.

> SHOULD use port 80 as their source port etc. 

RFC1945, which I believe is the canonical and earliest 
HTTP reference, only says:

   On the Internet, HTTP communication generally takes place over TCP/IP
   connections. The default port is TCP 80 [15], but other ports can be
   used.

It says nothing about the source port. 

No HTTP browser, that I have ever encountered, uses a source
port of 80.  Can you cite one?

> M3UA, SUA, M2PA

It's not that I hate 9989.  It's that I want to understand why
the document is making any sort of statement or recommendation
for the source port.  

-d

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 7 Dec 2011 10:35:13 +0100

> I will ask:  why is it necessary to have one local encapsulation
Interesting question.
> interface and use source port 8888 from IPv6 interface?  What
Nothing. We can do that. However, the sending stack must know which
local port to use. Basing this decision on IPv4/IPv6 works.
If you prefer, we can use a port per protocol family. That might
help if you use per protocol UDP sockets and does not make things
much more complex. I'm willing to include that in the next revision
if you like.
However, would you agree with it? Or do you have a local port
per association / per association/path in mind? That would be
much more complex to implement...
> chosen by the application developer, anyway.  
And that is not a problem, even with one port per stack.
> It says nothing about the source port. 
True it does. It is about the source port of the server....
> port of 80.  Can you cite one?
But would break anything if a browser would do it?
It wouldn't help, since the client is always initiating the
TCP communication. But for an SCTP you don't know which side
your application will be. So does it hurt?
> the document is making any sort of statement or recommendation
Let me phrase it differently (to avoid that the wording is a problem):

Currently the stack uses one UDP socket. The stack has to bind a local
port. Under the condition that the is only one stack per host, what
is bad to suggest to use 9989, but not require it?

Best regards
Michael

---

From: Randy Stewart <[email-masked]>
Date: Wed, 7 Dec 2011 05:54:46 -0500

Dan:

In-line…

> port of 80.  Can you cite one?

Dan, this seems the root of the problem for you. I.e. the document
suggests using this as a source port. I guess I have always thought
of it as a destination port…. since you have to have the stack
listen on one port for incoming data. And once the stack receives
a packet from a peer on that port, it must reply using that same port
as the source right?

I don't know of any HTTP server that is listening on port 80 that does
not, after accepting the connection, send reply messages with a source
address of port 80.

Could a stack initiate outbound INIT's on various UDP ports, sure, but where
would it send to if it knew nothing else? the defined IANA port… unless the
user specified some other port.

Now the down side, if its a kernel stack, of using multiple ports would be of
course you are burning up UDP ports in conjunction with every SCTP port.. which makes
no sense. for an O/S stack you are going to pick one port and use it. It does not
have to be the IANA port, but 99.99% of implementations that are in the kernel *will* use
the IANA port by default I bet. Which means they create one and only one socket inside
the kernel and send and receive *all* in and outbound SCTP packets to/from that port.

I just don't see why you are so concerned over such loose wording in the document. 

Michael wrote it was currently:

in the document. 

Would you be happier with the following?

 as the destination port for all its incoming SCTP packets.

I think it boils down to the same thing.. since if its a single implementation
on a O/S its only going to have one port. I guess if you wanted to use up
UDP ports for no reason you could use different ports as well but that would
be rather silly IMO.

R

-----
Randall Stewart
[email-masked]

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 7 Dec 2011 11:55:08 -0800

> From: Randy Stewart [mailto:[email-masked]]
> Sent: Wednesday, December 07, 2011 2:55 AM
> To: Dan Wing
> Cc: 'Chris Benson'; 'Michael Tuexen'; [email-masked]
> In-line.
> suggests using this as a source port. 

Yes, that is the root of the problem.

> I guess I have always thought
> of it as a destination port..  since you have to have the stack

Yes, it has to reply on the same port.  It cannot reply on the
source port 9899.  Or else things will break.  TFTP does that sort
of thing with its port 69, which doesn't work so hot for TFTP 
across a NAT.

I don't want the same kind of breakage with SCTP-over-UDP.  I
want SCTP-over-UDP to work across a NAT.

> not, after accepting the connection, send reply messages with a source

The I-D's current text does not make such a distinction.

> would it send to if it knew nothing else? the defined IANA port. unless
> the

Because it has caused problems for NAT traversal with other protocols,
and I do not want it to cause problems for SCTP-over-UDP.

> the SCTP stack is implemented as part of an application.</t>

That text looks great -- it removes any mention of the source
port, which has been my concern.  Thanks.

-d

> >>>> saying you *must* use it. but mentioning it so that apps have a
> >> choice of port of
> >>>> last resort so to speak.
> >>>>
> >>>> I see no difference here.. and think the current wording makes
> >> sense.
> >>>>
> >>>> R

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 7 Dec 2011 21:24:38 +0100

> port, which has been my concern.  Thanks.
Fine great, I'm happy with the text.
But it is clear to you that

the source port of outgoing packets is the same as the destination
port of incoming packets.

Or do you think that this is not true?

Best regards
Michael

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 7 Dec 2011 12:35:02 -0800

> Fine great, I'm happy with the text.

Great.

-d

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 7 Dec 2011 21:48:24 +0100

>> Fine great, I'm happy with the text.
Is it acceptable for you that the SCTP stack uses only
a single UDP port or do you want a single port per
protocol family or even more ports?

Best regards
Michael

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 7 Dec 2011 13:10:12 -0800

> Sent: Wednesday, December 07, 2011 12:48 PM
> To: Dan Wing
> Cc: 'Randy Stewart'; 'Chris Benson'; [email-masked]

I assume you're asking because you're thinking of SCTP
running on those several interfaces.  With that in mind,
whatever port a SCTP-over-UDP is listening on is likely
to be rewritten by NAT (or other address sharing, e.g.,
dIVI, 4rd, etc.).  So, the SCTP-over-UDP clients cannot
require that a single SCTP-over-UDP server have the
same UDP port from the perspective of the SCTP-over-UDP
client.  Instead, the server's UDP port needs to be 
communicated to the SCTP-over-UDP client within SCTP 
itself using either (a) SCTP's existing AddAddress mechanism 
-- which would need to be extended to accomodate/know/learn 
of the UDP rewriting that occurred on that pathor some, or
(b) other means such as DNS SRV records.

-d

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 7 Dec 2011 22:25:01 +0100

> running on those several interfaces.  With that in mind,
Well, I'm thinking about SCTP/UDP/IPv4 and SCTP/UDP/IPv6.
Do you have any other stack in mind? I think the ID only
talks about these two above stacks.
> dIVI, 4rd, etc.).  So, the SCTP-over-UDP clients cannot
I don't care about any rewriting by NATs. This is already
covered by the ID. I'm thinking about how many UDP sockets
you expect an SCTP stack to use for en/decapsulation.
One socket dealing with IPv4 and IPv6? Then one port is enough.
One for IPv4 and another one for IPv6? Then you have
2 bind calls which might make is hard to bind the same
port number.
Currently on Mac OS X I bind both sockets (kernel sockets)
to the same port. If one binding fails I close the other one
and report an error.
> (b) other means such as DNS SRV records.
Hmmm. I have the feeling that I'm missing something? How can you
put the UDP port number into the SCTP payload? The port numbers
might get rewritten by a NAT box and this wouldn't rewrite the
SCTP payload. That is why the SCTP just uses as the destination
port of outgoing packets what the source port of incoming packets was.

Best regards
Michael

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 7 Dec 2011 15:40:08 -0800

> Sent: Wednesday, December 07, 2011 1:25 PM
> To: Dan Wing

Yep, agreed.

> to the same port.

Ok.

> If one binding fails I close the other one
> and report an error.

That seems problematic.  What do you expect the caller to
do when it receives that error?  Give up and go home, or 
call you again?

> Hmmm. I have the feeling that I'm missing something?

What you have in the I-D (with the text change Randall suggested)
will work fine when the SCTP-over-UDP server has a publicly-
routed IP address and lovely things like that.

If, in the future, we have SCTP-over-UDP servers that are
behind their own NAT, things get more complicated.  I am
thinking of this complication, and thinking of ways to solve
it.  It's something we don't necessarily need to write down
yet, and certainly don't need to fix yet.  

But, we may.  It depends on if IPv4 really go away.

> How can you
> put the UDP port number into the SCTP payload?

That's a separate(able) problem.  Answers can include UPnP 
IGD, PCP, STUN, and other spiffy protocols for NAT traversal.

> The port numbers

Yeah, somewhere around 99% of transport protocols do that, too.

-d