Skip to main content

UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication
draft-ietf-tsvwg-sctp-udp-encaps-14

Yes

(Martin Stiemerling)
(Wesley Eddy)

No Objection

(Gonzalo Camarillo)
(Ralph Droms)
(Robert Sparks)
(Ron Bonica)
(Russ Housley)

Abstain


Note: This ballot was opened for revision 09 and is now closed.

Martin Stiemerling Former IESG member
Yes
Yes (for -09) Unknown

                            
Richard Barnes Former IESG member
Yes
Yes (2013-03-15 for -13) Unknown
"Each SCTP stack uses a single local UDP encapsulation port number as the destination port for all its incoming SCTP packets."

I understand what you mean here, but I wonder how this squares with the usage of SCTP/UDP in RTCWEB, where port numbers are negotiated.  It seems like in that scenario, you could end up with different SCTP associations using different port numbers.  Is this what you actually mean?
Wesley Eddy Former IESG member
Yes
Yes (for -09) Unknown

                            
Barry Leiba Former IESG member
No Objection
No Objection (2013-01-29 for -09) Unknown
I have just a few non-blocking comments, which I think will make the document clearer.  Please consider them seriously, and feel free to chat with me about them:

-- Section 3.1 --
   A crucial point for implementing SCTP in user space is controlling
   the source address of outgoing packets.  This is not an issue when
   using all available addresses.  However, this is not the case when
   also using the address management required for NAT traversal
   described in Section 4.7.

The last sentence is somewhat unclear about the referent of "this", and if I interpret it correctly it uses a confusing double-neagative.  I presume you mean that it is not the case that controlling the source address is not an issue.  Or, that is, that it *is* an issue.  The crucial point itself is also a little unclear: is it that source address has to be controlled?  Or is it a question of who controls the source address?  Or something else?  Does this work (adjust as necessary if I did not understand correctly)?:

NEW?
   A crucial point for implementing SCTP in user space is that the
   source address of outgoing packets needs to be controlled.  This
   is not an issue when using all available addresses.  However, it
   is an issue when also using the address management required for
   NAT traversal, described in Section 4.7.

-- Section 4.1 --
   Using a single UDP encapsulation port
   number per host is not possible if the SCTP stack is implemented as
   part of an application.

Why not; can you explain (or re-phrase)?  Is it maybe this?:

NEW?
   Using a single UDP encapsulation port
   number per host is not possible if the SCTP stack is implemented as
   part of each application, and there are multiple applications.

-- Section 4.3 --
   When inserting the UDP header, the source port [...]

Might this be better said as, "Within the UDP header"?

   The length of the UDP packet MUST be the length of the SCTP packet
   plus the size of the UDP header.

This is just stating how UDP works, isn't it?  That would be made clearer (and doesn't need the MUST) if it's said this way, I think:

NEW
   Because the SCTP packet is the UDP payload, the length of the UDP
   packet is the length of the SCTP packet plus the size of the UDP
   header.

-- Section 4.4 --
   Please note that when a non-encapsulated SCTP packet is received, the
   encapsulation of outgoing packets belonging to the same association
   and the corresponding destination address MUST be disabled.

I don't understand this.  How can a non-encapsulated SCTP packet be received over UDP?  Or are you saying that a plain SCTP packet might come on the same port because of an error on the sending side?  Or something else?  Please clarify this.  (I also think "please note" has a softening tone that seems to be wrong with the MUST at the end of the sentence.  But maybe that's just me, so don't worry about that too much.)

-- Section 4.5 --

No problem here, just making sure I understand an implication of this:

   be discarded silently.  This means in particular that the SCTP stack
   MUST NOT rely on receiving ICMP or ICMPv6 messages.  Implementation
   constraints could prevent processing received ICMP or ICMPv6
   messages.

That seems to mean that SCTP stacks have to be specifically aware that they are being tunnelled over UDP, and be tolerant of missing ICMP messages in that case... is that right?  Or is it expected that *all* SCTP stacks will be tolerant of that anyway?

-- Section 4.6 --
Nit... Awkward English alert:

   If the implementation does not allow to control the dont't fragment
   (DF)-bit contained in the IPv4 header

"Does not allow" shouldn't take an infinitive.  This reads better:

NEW
   If the implementation does not allow control of the don't fragment
   (DF) bit contained in the IPv4 header

-- Section 4.8 --
   If the implementation supports the sending and receiving of the ECN
   bits for the IP protocols being used by an SCTP association, the ECN
   bits MUST NOT be changed during sending and receiving.  In the other
   case, ECN MUST NOT be used for such an SCTP association.

In what other case?  That would seem to say that if the implementation doesn't support sending and receiving ECN bits, ECN MUST NOT be used.  And that *really* seems to go without saying.  Is there something else you mean here, and I don't understand?
Benoît Claise Former IESG member
No Objection
No Objection (2013-02-07 for -09) Unknown
I'm really with Adrian here: "The solution we want to see is not SCTP in UDP. It's SCTP."
I understand the chicken and egg problem.
However, I believe this document solves the issue of the SCTP not being adopted, instead of trying to push for SCTP adoption (or let the market decide). Aren't we opening the Pandora box by allowing this document as a Standard Track document? Basically, I could see new  IETF protocol RFCs, along with companion documents on how to encapsulate this in well know protocols in order to speed up deployment and avoid implementations in all sort of middleboxes... 

So no objection at the condition that this document goes experimental.
Otherwise, I will probably abstain.
Brian Haberman Former IESG member
No Objection
No Objection (2013-02-05 for -09) Unknown
I agree with Pete's DISCUSS point.
Gonzalo Camarillo Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Joel Jaeggli Former IESG member
No Objection
No Objection (2013-03-14 for -13) Unknown
I assume that the use of some non-9899 port is done through explict configuration. I don't have any particular objection to leaving that undefined.
Pete Resnick Former IESG member
(was Discuss) No Objection
No Objection (2013-03-15 for -13) Unknown
The authors and I have discussed this extensively. The following is my attempt at a full rewrite of 5.1 to capture the excellent explanation that the authors gave me, but I expect (given my lack of expertise in the area) that it will take further rewriting by the authors to make it correct. That said, we don't need to further DISCUSS this topic; the authors, the chairs, Martin, and myself are all in agreement about what should be written, so I have balloted NO OBJECTION and I will leave it to Martin, the chairs, and the authors to work out the details.  Again, the following is only a suggestion; re-edit to suit:

   UDP encapsulated SCTP is normally communicated between SCTP stacks
   using the IANA-assigned UDP port number 9899 (sctp-tunneling) on both
   ends. There are circumstances where other ports may be used on either
   end: As stated earlier, implementations in the application space
   might be required to use other than the well-known port, and NAT
   traversal may even rewrite port numbers. Discovery of alternate ports
   is outside of the scope of this document, but this section describes
   considerations for SCTP stack design in light of their potential use.

   Each SCTP stack uses a single local UDP encapsulation port number as
   the destination port for all its incoming SCTP packets, using the
   same port number for all local IP addresses available to the stack.
   While not necessarily required for the protocol, this greatly
   simplifies implementation design, since different ports for each
   address would require an implementation to choose the appropriate
   port while doing source address selection. Using a single local UDP
   encapsulation port number per host is not possible if the SCTP stack
   is implemented as part of each application, there are multiple
   applications, and some of the applications want to use the same IP-
   address.

   An SCTP implementation supporting UDP encapsulation MUST maintain a
   remote UDP encapsulation port number per destination address for each
   SCTP association. Again, because the remote stack may be using other
   than the well-known port, each port may be different from each stack,
   but because of remapping of ports by NATs, the remote ports
   associated with different remote IP addresses may not be identical,
   even if they are associated with the same stack.

   Implementation note: Because the well-known port might not be used,
   implementations need allow other port numbers to be specified as a
   local or remote UDP encapsulation port number through APIs.

Minor change to 5.3

   Within the UDP header, the source port MUST be the local UDP
   encapsulation port number of the SCTP stack, the destination port
   MUST be the remote UDP encapsulation port number stored for the
   association and the destination address to which the packet is sent
   (see Section 5.1).

Strike the word "stored". It's unneeded. If you insist, I like the word "maintained" better.
Ralph Droms Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Robert Sparks Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Ron Bonica Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Russ Housley Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Sean Turner Former IESG member
No Objection
No Objection (2013-02-06 for -09) Unknown
The author and secdir reviewer seem to have worked out some agreed changes.  Please add them in the next revision.
Stephen Farrell Former IESG member
No Objection
No Objection (2013-02-02 for -09) Unknown
I've not fully followed the mega-thread on Stewart's DISCUSS
so apologies if something here overlaps with that (and feel
free to entirely ignore any such thing and handle it in the
other thread). OTOH, this was almost a DISCUSS so I'd really
like to get an answer but not quite enough to try block
progress on this. 

- I don't get how a node knows which non default UDP port to
use on the remote node, nor why some method for doing that
does not need to be discussed here. (Perhaps its elsewhere
which'd be fine, but I don't get it being ok to omit that.)
If no standard or de-facto discovery mechanism is defined,
then doesn't that mean that the default port is basically all
that'll work really? And doesn't that in turn mean that any
kernel SCTP implementation effectively MUST support
encapsulation on that port, if this spec is to be at all
usable and that effectively only one application per host
will be able to listen for clients on that port?  Or perhaps
what you want is that each application using sctp would also
register the same UDP port (where possible) for SCTP
encapsulation.  If so, then I think you ought say that so
that coders and IANA are aware of it.

nits:

3.1: s/when proving/when providing/

4.8: I didn't get the point of this section and "In the other
case..." seems ambiguous.
Stewart Bryant Former IESG member
(was Discuss) No Objection
No Objection (2013-03-11 for -12) Unknown
Thank you for addressing my concern
Adrian Farrel Former IESG member
Abstain
Abstain (2013-01-30 for -09) Unknown
Please don't take this the wrong way, but I struggled to see why we
are bothering with this as a Standards Track document.  Rather than
get in the way of this work with a Discuss, I am Abstaining. But
here are my concerns and comments...

---

While I have no doubt that this mechanism will work and can be used to
address the problems stated, I do find it really weird that we are
publishing "how to encapsualte the great-but-no-longer-new SCTP in
dumb old UDP in order to address problems of non-support of SCTP."

Isn't it odd that 12 years after the publication of RFC 2960 as a 
standards track RFC we are addressing problems of "legacy NATs" that
don't support SCTP? Isn't it more likely that the adoption of SCTP is
in question?

As for the ability to implement SCTP without direct access to the IP-
layer...  Well, really!  Surely we can move on beyond that? It isn't
rocket science to access the IP-layer, but maybe the issue (again) is
one of adoption of SCTP?

---

Section 4.2

Do we really need figures 1 and 2?
The message is: The payload of the UDP packet is the SCTP Common Header
followed by one or more SCTP chunks.

---

Section 4.3
Is there anything here that is not standard UDP behavior?

---

Section 4.6

If the SCTP header fills up the UDP packet such that no SCTP chunk can
be included?

---

Isn't this a tunnelling technology? Although 4.8 talks about ECN, it is
concerned with SCTP use of ECN. Shouldn't the document (according to TSV
best practice) discuss congestion on the tunnel?

---

Section 5 should be moved out to an Appendix so as to not confuse the
content of the standards track document.