RE: SCTP-over-UDP and port 9899

["Dan Wing" <[e-mail]>]

> -----Original Message-----
> From: Michael Tuexen [mailto:[e-mail]]
> Sent: Tuesday, November 01, 2011 9:50 AM
> To: Dan Wing
> Cc: [e-mail]; [e-mail]
> Subject: Re: SCTP-over-UDP and port 9899
> 
> 
> On Nov 1, 2011, at 4:47 PM, Dan Wing wrote:
> 
> >> -----Original Message-----
> >> From: [e-mail] [mailto:[e-mail]] On
> Behalf
> >> Of Michael Tuexen
> >> Sent: Monday, October 31, 2011 2:27 PM
> >> To: Dan Wing
> >> Cc: [e-mail]; [e-mail]
> >> 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.
> 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.

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

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


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