RE: SCTP-over-UDP and port 9899

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

> -----Original Message-----
> From: Michael Tuexen [mailto:[e-mail]]
> Sent: Tuesday, November 01, 2011 12:59 PM
> To: Dan Wing
> Cc: [e-mail]; [e-mail]
> Subject: Re: SCTP-over-UDP and port 9899
> 
> On Nov 1, 2011, at 6:15 PM, Dan Wing wrote:
> 
> >> -----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 agree.
> >
> >> 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.
> 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.

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

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

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

-d

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