Subject: [apps-discuss] Review of: draft-ietf-tsvwg-sctp-udp-encaps

From: Dave Crocker <[email-masked]>
Date: Sat, 02 Feb 2013 10:57:47 -0800

Howdy.

I have been selected as the Applications Area Directorate reviewer for 
this draft.  (For background on appsdir, please see

http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ).

Please resolve these comments along with any other Last Call comments 
you may receive. Please wait for direction from your document shepherd 
or AD before posting a new version of the draft.

Document:

    draft-ietf-tsvwg-sctp-udp-encaps-09

Title:

    UDP Encapsulation of SCTP Packets

Reviewer:

    D. Crocker <[email-masked]>

Review Date:

    2 Feb 2013

Summary:

      As a transport-level protocol, SCTP can encounter barriers at the 
endpoints, through inadequate API or privilege access to raw IP 
services, or at intermediaries such as NATs that do not support SCTP. 
Tunneling is the usual solution to these type of barriers.  The current 
draft specifies encapsulation for tunneling SCTP and discusses 
operational concerns.

      The specification is usable in its current form.  Revision, per 
the below comments, would improve its clarity, especially for 
less-knowledgeable readers.

      Also, a long-standing issue for use of UDP is the upper-layer 
requirement to provide congestion control and reliability mechanisms, 
since UDP doesn't.  In the case of a tunneled transport service, like 
SCTP, this is obviously a trivial issue.  However given the 
long-standing UDP concern, I suggest adding a pro-forma sentence to make 
this explicit.  Something like:

           "SCTP provides the necessary congestion control and 
reliability service that UDP does not perform."

Detailed comments:

> 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.
> 1.  Introduction
>
>    This document describes a simple method of encapsulating SCTP packets
>    into UDP packets.  SCTP as defined in [RFC4960] runs directly over
>    IPv4 or IPv6.  There are two main reasons for encapsulating SCTP
>    packets:
>
>    o  Allow SCTP traffic to pass legacy NATs, which do not provide

pass -> pass through

>       native SCTP support as specified in [I-D.ietf-behave-sctpnat] and
>       [I-D.ietf-tsvwg-natsupp].

> 3.1.  Portable SCTP Implementations
...
>    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

What is meant by "using all available addresses"?

>    also using the address management required for NAT traversal
>    described in Section 4.7.

> 3.2.  Legacy NAT Traversal
>
>    Using UDP encapsulation allows SCTP communication when traversing
>    legacy NATs (i.e those NATs not supporting SCTP as described in
>    [I-D.ietf-behave-sctpnat] and [I-D.ietf-tsvwg-natsupp]).  It is
>    important to realize that for single homed associations it is only
>    necessary that no IP addresses are listed in the INIT and INIT-ACK

This seems to be a normative directive, but it does not use normative 
language. Perhaps:

      For single-homed associations IP addresses MUST NOT be listed in
      the INIT and INIT-ACK

>    chunks.  To use multiple addresses, the dynamic address
>    reconfiguration extension described in [RFC5061] MUST be used with
>    wildcard addresses in combination with [RFC4895].

wildcard addresses -> wildcard source addresses (?)

>    For multi-homed SCTP association the address management as described
>    in Section 4.7 MUST be performed.
>
>    SCTP sends periodically HEARTBEAT chunks on all idle paths.  These

      periodically  -> periodic

>    can be used to keep the NAT state alive.

      can be used to keep -> can keep

>
> 4.  SCTP over UDP
>
> 4.1.  Architectural Considerations
>
>    An SCTP implementation supporting UDP encapsulation MUST store a
>    remote UDP encapsulation port number per destination address for each
>    SCTP association.

Must store it /where/?

Or perhaps this isn't really a normative specification statement but 
rather an architectural discussion that provides a basis for the later 
specification details?  If so, remove the normative language here.

>
>    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 (sctp-tunneling) 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).  Using a single UDP encapsulation port
>    number per host is not possible if the SCTP stack is implemented as
>    part of an application.
>
> 4.2.  Packet Format
>
>    To encapsulate an SCTP packet, a UDP header as defined in [RFC0768]
>    is inserted between the IP header as defined in [RFC0791] and the
>    SCTP common header as defined in [RFC4960].

Interesting perspective.  It casts UDP as crating a shim layer.  I 
suppose that's what tunneling actually is...

>    Figure 1 shows the packet format of an encapsulated SCTP packet when
>    IPv4 is used.

> 4.3.  Encapsulation Procedure
...
>    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 the protections provided by the SCTP checksum, why is a UDP 
checksum needed?  (Note the logic of dropping checksum from IPv6...)

> 4.4.  Decapsulation Procedure
>
>    When an encapsulated packet is received, the UDP header is removed.
>    Then a lookup is performed to find the association for the received

Where is the lookup algorithm specified?  In particular, what 
information is used to perform the lookup.

>    SCTP packet.  After finding the SCTP association (which includes
>    checking the verification tag), the UDP source port MUST be stored as
>    the encapsulation port for the destination address the SCTP packet is
>    received from (see Section 4.1).
>
>    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.

"Please note" is appropriate for a comment, not a strongly normative 
statement.  That is, I think it undermines the reader's understanding 
that this is a normative requirement.

> 4.6.  Path MTU Considerations
>
>    If an SCTP endpoint starts to encapsulate the packets of a path, it
>    MUST decrease the Path MTU of that path by the size of the UDP
>    header.  If it stops encapsulating them, the Path MTU SHOULD be
>    increased by the size of the UDP header.

How can a user-level SCTP control Path MTU, particularly when it's 
access to the IP layer (and presumably ICMP) is limited?

Perhaps you mean "adjust SCTP's use of the provided Path MTU"?  That is, 
provide a calculation on top of what the infrastucture says is available?

>    When performing Path MTU discovery as described in [RFC4820] and
>    [RFC4821] it MUST be taken into account that one cannot rely on the
>    feedback provided by ICMP or ICMPv6 due to the limitation laid out in
>    Section 4.5.

Normative language in a sentence like this is actually not very helpful, 
since it does not specify what behaviors are being dictated.  Where is 
the guidance that says what it means for this to "be taken into account"?

>    If the implementation does not allow to control the dont't fragment

      does not allow to control the dont't fragment
      ->
      does not allow control of the don't fragment

>    (DF)-bit contained in the IPv4 header, then Path MTU discovery can't
>    be used.  In this case, an implementation specific value should be
>    used instead.

Does this implementation-specific activity require some sort of 
coordination between the end-points?

>
> 4.7.  Handling of Embedded IP-addresses
>
>    When using UDP encapsulation for legacy NAT traversal, IP addresses
>    that might require translation MUST NOT be put into any SCTP packet.
>
>    This means that a multi homed SCTP association is setup initially as
>    a singled homed one and the protocol extension [RFC5061] in
>    combination with [RFC4895] is used to add the other addresses.  Only
>    wildcard addresses are put into the SCTP packet.

This is the second reference to the use of wildcard for this.  Since 
inclusion of actual addresses is needed for correlation/rendezvous 
functions, it would help to have a pointer or discussion about how the 
correlation/rendezvous is done when wildcarding is done.

>    When addresses are changed during the lifetime of an association
>    [RFC5061] MUST be used with wildcard addresses only.

> 5.  Socket API Considerations
>
>    This section describes how the socket API defined in [RFC6458] is

since the section is informational, rather than normative, I suggest:

      is -> can be

>    extended to provide a way for the application to control the UDP
>    encapsulation.

> 7.  Security Considerations
>
>    Encapsulating SCTP into UDP does not add any additional security
>    considerations to the ones given in [RFC4960] and [RFC5061].
>
>    Firewalls inspecting SCTP packets must also be aware of the
>    encapsulation and apply corresponding rules to the encapsulated
>    packets.

"must"?  normative?

The problem with this, whether normative or not, is that the purpose of 
this encapsulation is to transit intermediaries that don't support SCTP. 
  That's a conflicting goal and probably is worth noting.

>    An attacker might send a malicious UDP packet towards an SCTP end-
>    point to change the encapsulation port for a single remote address of

d/
-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

---

From: Dave Crocker <[email-masked]>
Date: Sun, 03 Feb 2013 07:15:09 -0800

Michael,

Thanks for the speedy response.  More comments inline.

We probably don't need to iterate further.  As I said in the review, the 
doc is workable as is; I'm only suggesting changes that seem to me will 
improve clarity a bit.

d/

On 2/3/2013 5:42 AM, Michael Tuexen wrote:
> On Feb 2, 2013, at 7:57 PM, Dave Crocker wrote:
> If the SCTP endpoint can use all addresses configured at the IP layer.
 >
> In socket terms: You bound the socket to the wildcard address (0.0.0.0 or ::0).

I guess I suggest adding this bit of clarification, although it might 
help to change 'use' to something more specific, possibly like:

      This is not an issue when the SCTP implementation is able to bind 
to any possible address configured at the IP layer.

I'm not sure I'm interpreting the details correctly; if not, just use my 
text as an exemplar for the type of clarification I'm suggesting.

(In case it isn't obvious, I tend to do review-oriented reading with any 
eye towards /mis/interpretation by a less-expert reader...)

> No. The addresses used in the ASCONF/ASCONF-ACK chunks described in RFC 5061
> are wildcard addresses.

Ok.  Then perhaps:

      MUST be used with wildcard addressed used in the ASCONF/ASCONF-ACK 
chunks described in RFC 5061, in combination with [RFC4895].

> I think different SCTP implementation will have different data structures for
> variable which are per remote address.
 >
>>> Or perhaps this isn't really a normative specification statement but rather an architectural discussion that provides a basis for the later specification details?  If so, remove the normative language here.
 >
> It is important that this port number is a variable per destination address
> for each SCTP association, not just one per association or so.
> It make clear how to store the variable. Later in the text it is only described how
> you modify and use the variable. So do you want me to change the MUST to a must?

OK.  Then I suggest moving this away from using normative language, 
since the issue is higher-level, rather than specific.  Something along 
the lines of:

      UDP encapsulation for SCTP permits use of different UDP port 
numbers.  Consequently, an implementation's maintenance of tunneling 
state information requires retention of the port number used by the 
remote side of the tunneling exchange.

>>> Given the protections provided by the SCTP checksum, why is a UDP checksum needed?  (Note the logic of dropping checksum from IPv6...)

> We don't need any kind of error protection, just being able to interop.
> When requiring to disable the UDP checksum for IPv4, at least on FreeBSD,
> this is a host wide configuration option. For IPv6 it will delay each
> connection setup in case not all nodes involved support disabled
> checksums. On FreeBSD at least, disabling UDP checksum for IPv6 is
> not supported currently. So you would have the penalty always.

The problem with the current language is that it doesn't provide a 
context for the SHOULD.  I'm not sure what language to suggest to 
clarify this.  Something like "SHOULD support UDP checksum to the extent 
needed for interoperability" seems poor...

>> Where is the lookup algorithm specified?  In particular, what information is used to perform the lookup.
 >
> This is the generic lookup each SCTP stack perform when a packet is received.
> Conceptually, you take the source and destination address and port number to
> find the association and path and then verify the v-tag.

Ah.  The current text looked like it was specifying something new.  So 
I'll suggest:

    Then the generic lookup is performed, as done by a SCTP stack when a 
packet is received.

>>> "Please note" is appropriate for a comment, not a strongly normative statement.  That is, I think it undermines the reader's understanding that this is a normative requirement.

> This comment was already raised. The text has been changed (for the next revision) to
> <t>When a non-encapsulated SCTP packet is received by the
> SCTP stack, the encapsulation of outgoing packets belonging
> to the same association and the corresponding destination
> address MUST be disabled.</t>

wfm.

>>> How can a user-level SCTP control Path MTU, particularly when it's access to the IP layer (and presumably ICMP) is limited?

> Some operating systems allow an application to set the DF bit. That is all you need.
> Implementing PathMTU discovery should not rely on ICMP or ICMv6. SCTP can send
> probe packets consisting of HEARTBEAT and PADDING chunks. If no corresponding
> HEARTBEAT-ACK is received, the probe packet was lost.
>>
>> Perhaps you mean "adjust SCTP's use of the provided Path MTU"?  That is, provide a calculation on top of what the infrastucture says is available?
 >
> It depends if the infrastructure can provide it. SCTP does provide this functionality.

Well, I'm not sure what to suggest.  I think the current language 
implicitly encourages the kind of confusion I experienced.  But the 
topic isn't straightforward.

I think of Path MTU as a mechanism that is independent of other 
services, such as transport, and that those other services are clients 
of the Path MTU value.  That's why I suggested casting this as 
"modifying what is produced".

Mumble.  Sorry I can't offer something more coherent.

>> This is the second reference to the use of wildcard for this.  Since inclusion
 >> of actual addresses is needed for correlation/rendezvous functions, 
it would
 >> help to have a pointer or discussion about how the 
correlation/rendezvous is
 >> done when wildcarding is done.
 >
> No, RFC 4895 provides a security mechanism required by RFC 5061. RFC 5061
> requires the use of RFC 4895.
> Using wildcard addresses avoids embedding IP addresses in the SCTP packet.
> When using wildcard addresses you are referring to the source address
> of the SCTP packet.

The current language seems to mix references to the two sides of the 
exchange; use of the passive tense, with "are put", further obscures 
which side does what.

> Changed. However, in RFC 6525 we used "needs to be extended". Would that
> be acceptable to you?

wfm.

> The sentence as above was suggested the the sec review.
>>
>> The problem with this, whether normative or not, is that the purpose of this encapsulation is to transit intermediaries that don't support SCTP.  That's a conflicting goal and probably is worth noting.
> As stated above, this sentence was suggested by the sec review.
> I don't agree that it is a necessarily a contradiction. Since the
> firewall supports SCTP (it can inspect them), you wouldn't use UDP
> to get through it.

I understand the security orientation that produced the text.  But as 
you note, if the firewall is SCTP aware, then you probably won't be 
using UDP to transit the firewall.  That makes the document irrelevant 
to the case this text covers...

(I'm counting NAT and Firewall as likely to be the same box.)

I think the security considerations concern is better served by simply 
noting that UDP encapsulation can serve to hide the use of SCTP from 
firewalls along the path, if the firewall is not SCTP aware.  A 
statement like this highlights the issue but does not attempt to dictate 
how to deal with it.

d/

---

From: Michael Tuexen <[email-masked]>
Date: Sun, 3 Feb 2013 14:42:05 +0100

> Howdy.
Hi Dave,

thanks a lot for your comments. See my answers in-line.

Best regards
Michael
> 
> I have been selected as the Applications Area Directorate reviewer for this draft.  (For background on appsdir, please see
> 
> Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft.
> 
> 
> Document:
> 
> 
>     As a transport-level protocol, SCTP can encounter barriers at the endpoints, through inadequate API or privilege access to raw IP services, or at intermediaries such as NATs that do not support SCTP. Tunneling is the usual solution to these type of barriers.  The current draft specifies encapsulation for tunneling SCTP and discusses operational concerns.
> 
>     The specification is usable in its current form.  Revision, per the below comments, would improve its clarity, especially for less-knowledgeable readers.
> 
>     Also, a long-standing issue for use of UDP is the upper-layer requirement to provide congestion control and reliability mechanisms, since UDP doesn't.  In the case of a tunneled transport service, like SCTP, this is obviously a trivial issue.  However given the long-standing UDP concern, I suggest adding a pro-forma sentence to make this explicit.  Something like:
> 
>          "SCTP provides the necessary congestion control and reliability service that UDP does not perform."
OK, added as the last sentence in the Introduction section.
>>   o  Allow SCTP traffic to pass legacy NATs, which do not provide
Added to the CVS version. I will be included in the next revision.
> This seems to be a normative directive, but it does not use normative language. Perhaps:
> 
OK.
>>   SCTP sends periodically HEARTBEAT chunks on all idle paths.  These
Changed in the CVS version.
>     can be used to keep -> can keep
Changed in the CVS version.
> Interesting perspective.  It casts UDP as crating a shim layer.  I suppose that's what tunneling actually is...
> 
> 
> Normative language in a sentence like this is actually not very helpful, since it does not specify what behaviors are being dictated.  Where is the guidance that says what it means for this to "be taken into account"?
RFC 4821 provides the specification for doing path MTU discovery and RFC 4820
defines the SCTP probe packets used for implementing path MTU discovery based
on RFC 4821 for SCTP. 
>     does not allow control of the don't fragment
Already changed for next revision.

> Does this implementation-specific activity require some sort of coordination between the end-points?
No.
> This is the second reference to the use of wildcard for this.  Since inclusion of actual addresses is needed for correlation/rendezvous functions, it would help to have a pointer or discussion about how the correlation/rendezvous is done when wildcarding is done.

---

From: Michael Tuexen <[email-masked]>
Date: Sun, 3 Feb 2013 23:06:17 +0100

On Feb 3, 2013, at 4:15 PM, Dave Crocker wrote:

> We probably don't need to iterate further.  As I said in the review, the doc is workable as is; I'm only suggesting changes that seem to me will improve clarity a bit.
OK, let me go through your comments and let you know what I take...

Best regards
Michael
> I guess I suggest adding this bit of clarification, although it might help to change 'use' to something more specific, possibly like:
> 
>     This is not an issue when the SCTP implementation is able to bind to any possible address configured at the IP layer.
> 
> I'm not sure I'm interpreting the details correctly; if not, just use my text as an exemplar for the type of clarification I'm suggesting.
I think
This is not an issue if the SCTP stack can use all addresses configured
at the IP-layer as source addresses.
makes it clearer.
> 
> (In case it isn't obvious, I tend to do review-oriented reading with any eye towards /mis/interpretation by a less-expert reader...)
> 
> 
>     MUST be used with wildcard addressed used in the ASCONF/ASCONF-ACK chunks described in RFC 5061, in combination with [RFC4895].
The next rev will contain:

To use multiple addresses, the dynamic address reconfiguration extension
described in <xref target='RFC5061'/> MUST be used only with wildcard addresses
in the ASCONF chunks in combination with <xref target='RFC4895'/>.
> OK.  Then I suggest moving this away from using normative language, since the issue is higher-level, rather than specific.  Something along the lines of:
> 
>     UDP encapsulation for SCTP permits use of different UDP port numbers.  Consequently, an implementation's maintenance of tunneling state information requires retention of the port number used by the remote side of the tunneling exchange.
This would replace a (for me) clear statement with one from which I don't get what
I wanted to say. So I prefer to keep the text as it is.
> The problem with the current language is that it doesn't provide a context for the SHOULD.  I'm not sure what language to suggest to clarify this.  Something like "SHOULD support UDP checksum to the extent needed for interoperability" seems poor...
Since this issue is still discussed with Stewart, let's wait for the outcome of that discussion.
> Ah.  The current text looked like it was specifying something new.  So I'll suggest:
> 
>   Then the generic lookup is performed, as done by a SCTP stack when a packet is received.
Next rev will contain:
Then the generic lookup is performed, as done by an SCTP stack
whenever a packet is received, to find the association
for the received SCTP packet.
> Well, I'm not sure what to suggest.  I think the current language implicitly encourages the kind of confusion I experienced.  But the topic isn't straightforward.
> 
> I think of Path MTU as a mechanism that is independent of other services, such as transport, and that those other services are clients of the Path MTU value.  That's why I suggested casting this as "modifying what is produced".
> 
For me path MTU discovery is a function provided by the transport layer...
> >> of actual addresses is needed for correlation/rendezvous functions, it would
> >> help to have a pointer or discussion about how the correlation/rendezvous is
RFC 5061 describes that the source address of the packet is used if a
wildcard address is provided in the ASCONF chunk.
> The current language seems to mix references to the two sides of the exchange; use of the passive tense, with "are put", further obscures which side does what.
> 
> 
> I understand the security orientation that produced the text.  But as you note, if the firewall is SCTP aware, then you probably won't be using UDP to transit the firewall.  That makes the document irrelevant to the case this text covers...
> 
I'm not... I think the sec review wanted to make sure that an attacker does not
circumvent the SCTP rules by encapsulating the packets in UDP. This is what
the text makes sure.
> 
> I think the security considerations concern is better served by simply noting that UDP encapsulation can serve to hide the use of SCTP from firewalls along the path, if the firewall is not SCTP aware.  A statement like this highlights the issue but does not attempt to dictate how to deal with it.
I don't this that this is the intention of the text. So I leave it as it is.