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

The draft is ready for publication, but a number of modifications have been made as part of the IESG review that require a short WGLC on the changes.

[Ballot comment]
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.

[Ballot comment]
"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?

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot discuss]
Stephen's comment notwithstanding, I think his question is worthy of a very serious DISCUSSion: There is no provided rendezvous mechanism specified if an implementation does not use the well-known UDP port (9899), unless it is 4.4 (in that one end must be running on the well-known port and the other end must be the initiator). This is not interoperable, and it leads to all sorts of weird language in 4.1: implementations "MUST store a remote UDP encapsulation port number per destination address for each SCTP association"? That sounds like nonsense: If I am able to use a dynamic rendezvous mechnmism, I may not have to store anything at all. And "9899 MAY be used as this port number"? It SHOULD be used as the port number, unless you want to be non-interoperable (i.e., have a remote port number that you need to discover out of band). This seems like a serious failing in this protocol, and there's nothing in the document or in the writeup that explains this. Please do explain.

[Ballot comment]
I agree with Adrian's comment that the figures are unnecessary. I strongly agree with Adrian and Barry that the language in 4.3 is simply describing standard UDP behavior. The MUSTs (to me) are just silly.

[Ballot comment]

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.

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot comment]
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?

[Ballot discuss]
"For IPv4, the UDP checksum SHOULD be computed and the SCTP checksum
MUST be computed, whereas for IPv6, the UDP checksum and the SCTP
checksum MUST be computed."


Given that this is by definition SCTP tunneling over UDP (that
is the UDP port it runs on) I would like to understand
why are the more relaxed UDP tunnel c/s considerations
approved last week not applied here?

SCTP already has a CRC32 and a cookie to make sure it is delivered
correctly so a 16bit checksum seems to add very little additional protection
for a lot of work by the encapsulating device.

IANA has reviewed draft-ietf-tsvwg-sctp-udp-encaps-07 and has the following comments:

IANA has a question regarding this document.

UDP port 9899 (sctp-tunneling) is already registered and the IANA Considerations section of the current draft correctly notes this. However, there appears to be no reference to TCP in the current document.
Is port 9899 needed for both TCP and UDP or simply UDP?

Do the authors desire to have Lyndon Ong as the Assignee and Contact for port 9899? Per RFC6335, [IESG] should be the Assignee for assignments done through RFCs published and [IETF_Chair] should be the Contact.

IANA understands that there are no other IANA Considerations related
to this document.

Note: The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (UDP Encapsulation of SCTP Packets) to Proposed Standard


The IESG has received a request from the Transport Area Working Group WG
(tsvwg) to consider the following document:
- 'UDP Encapsulation of SCTP Packets'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-01-22. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document describes a simple method of encapsulating SCTP Packets
  into UDP packets and its limitations.  This allows the usage of SCTP
  in networks with legacy NAT not supporting SCTP.  It can also be used
  to implement SCTP on hosts without directly accessing the IP-layer,
  for example implementing it as part of the application without
  requiring special privileges.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-udp-encaps/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-udp-encaps/ballot/


No IPR declarations have been submitted directly on this I-D.

Result of the AD review:

Section 4.1., paragraph 2:

> Each SCTP stack uses a single local UDP encapsulation port number as
> the destination port for all its incoming SCTP packets.  The IANA
> assigned value of 9899 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.

  It is possible to get a specific port number, even if you are an
  application. I think the statement is missing that only the first
  app asking for it (First come first serve) can get the port 9899,
  or any similar statment saying the same.


Section 4.4., paragraph 1:

> When an encapsulated packet is received, the UDP header is removed.
> Then a lookup is performed to find the association for the received
> SCTP packet.  The UDP source port is stored as the encapsulation
> port for the destination address the SCTP packet is received from
> (see Section 4.1).

  Is the UDP source port always stored whenever a UDP packet is
  received on the UDP destination port? This sentence is somewhat
  underspecified and might also be subject to open a security
  hole. E.g., when each UDP packet is updating this, someone could
  divert the outgoing traffic. This can also dangerous even if
  SCTP/UDP-encapsulated packets are received. We should discuss this
  a bit more by email.


Section 4.4., paragraph 2:

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

  Is it mandatory to perform this action? If yes, the normative
  language is missing.

A note about implementations of this draft:
This draft is implemented in FreeBSD and released in 9.1. It is also
implemented in the Mac OS X kernel implementation (a port of the FreeBSD
one), which is available from
http://sctp.fh-muenster.de
and also available in the userland stack based on the FreeBSD kernel
implementation.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why
is this the proper type of RFC? Is this type of RFC indicated in the
title page header?

This document is intended as a PS.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary
This document describes a simple method of encapsulating SCTP Packets
into UDP packets and its limitations. This allows the usage of SCTP
in networks with legacy NAT not supporting SCTP. It can also be used
to implement SCTP on hosts without directly accessing the IP-layer,
for example implementing it as part of the application without
requiring special privileges.

Working Group Summary
There was consensus to adopt this as a WG document alongside other drafts
in the Behave WG on NAT/NAPT traversal and agreement by the WG to publish
this.

Document Quality
The document is complete.

Personnel Who is the Document Shepherd? Who is the Responsible Area Director?
I am the document shepherd, G Fairhurst. The responsible AD is Wes Eddy.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

This draft was adopted as a work item 21 Sept 2011. WGLC completed Friday
20th April 2012, there was discussion and the draft was updated in
response to discussion. There was agreement on these amendments. The
specification in the document is believed to be implemented in FreeBSD.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

None.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes - they have confirmed conformance to BCP 78/79.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

As far as I know, no IPR disclosures have been submitted.

(9) How solid is the WG consensus behind this document? Does it represent
the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

The document has WG support and there is consensus to publish.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

N/A.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

No.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

Not applicable.

(13) Have all references within this document been identified as
either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in the
Last Call procedure.

No.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

There are no IANA requirements because this draft mentions only an already
allocated port.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

None.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.
Not applicable.