RE: SCTP-over-UDP and port 9899

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

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Michael Tuexen
> Sent: Tuesday, November 01, 2011 3:25 PM
> To: Dan Wing
> Cc: [e-mail]; [e-mail]
> Subject: Re: SCTP-over-UDP and port 9899
> 
> On Nov 1, 2011, at 10:56 PM, Dan Wing wrote:
> 
> >> -----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.
> 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?

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

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

-d


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