Re: [tsvwg] I-D Action: draft-ietf-tsvwg-sctp-dtls-encaps-03.txt

[Michael Tuexen <[e-mail]>]

On 08 Apr 2014, at 20:46, Joe Touch <[e-mail]> wrote:

> Hi, Michael,
> 
> Feedback below. Hopefully useful.
Hi Joe,

thanks for the feedback. It is very useful and will improve the document.

See my comments/response in-line.

Best regards
Michael
> 
> On 4/8/2014 7:06 AM, Michael Tuexen wrote:
>> On 07 Mar 2014, at 20:46, Michael Tuexen <[e-mail]> wrote:
>> 
>> Hi Joe,
>> 
>> thank you for your review. Please find my comments in-line.
>> 
>> Best regards
>> Michael
>> 
>>> WGLC comments from Joe.
>>> 
>>> Best regards
>>> Michael
>>> 
>>> Begin forwarded message:
>>> 
>>>> From: Joe Touch <[e-mail]>
>>>> Subject: Re: Fwd: [tsvwg] I-D Action: draft-ietf-tsvwg-sctp-dtls-encaps-03.txt
>>>> Date: 6 Mar 2014 23:55:24 GMT
>>>> To: Michael Tuexen <[e-mail]>
>>>> Cc: Gorry Fairhurst <[e-mail]>, Randall Stewart <[e-mail]>, Randell Jesup <[e-mail]>, Salvatore Loreto <[e-mail]>
>>>> 
>>>> Hi, Michael,
>>>> 
>>>> On 2/7/2014 7:55 AM, Michael Tuexen wrote:
>>>>> Hi Joe,
>>>>> 
>>>>> Gorry suggested that you might be interested in reviewing the SCTP over DTLS
>>>>> ID, since you are interested in transport tunnels. So would it be possible
>>>>> for you to review the document (it is pretty short)? I would appreciate your
>>>>> review very much!
>>>> ...
>>>>>> 	Filename        : draft-ietf-tsvwg-sctp-dtls-encaps-03.txt
>>>> 
>>>> Comments below. Feel free to post/forward as usual; please cc me if you do, so I can track any followups if needed.
>>>> 
>>>> Joe
>>>> 
>>>> -----
>>>> 
>>>> 1 - I'm not a fan of "stacked headers"; section 1 should have something to say before you jump into 1.1
>> Agreed. Actually the abbreviations are almost useless and the terminology can
>> also be removed. Therefore, section 1 will only contain the overview.
>>>> 
>>>> 1.1 - This section should more clearly explain the need for DTLS encapsulation, given RFC 6951 (SCTP over UDP) - i.e., you want UDP with security. That's implied right now, and should be explicit.
>>>> 
>>>> Why doesn't the entirety of this document not boil down to "run SCTP over UDP as per RFC 6951 except use DTLS instead of UDP? Wouldn't that description then mean you can then omit section 3?
> >
>> One of the important points of RFC 6951 is how to deal with the UDP port numbers.
> 
> The abstract of RFC 6951 seems to indicate otherwise:
> 
>   ...In particular, it does not provide mechanisms
>   to determine whether UDP encapsulation is being used by the peer, nor
>   the mechanisms for determining which remote UDP port number can be
>   used.  These functions are out of scope for this document.
> 
> There's an API for configuring the port number being used, but it doesn't seem to matter what port number is actually used (though 9899 is the default, as per Section 7).
I was not clear enough and maybe the cited text is also not very clear.
Let me be more precisely:

RFC 6951 does not provide a mechanism to figure out if the initiator should use
UDP encapsulation or not. And RFC 6951 does not provide a mechanism to figure
out which UDP port number to use for the initial packet.

However, RFC 6951 does tell you that an SCTP stack has one local UDP encapsulation
port number and needs to store per path for each association a remote UDP encapsulation
port number. See
http://tools.ietf.org/html/rfc6951#section-5.1
RFC 6951 also tells you how to update the remote encapsulation port
number when a packet is received. See
http://tools.ietf.org/html/rfc6951#section-5.4

Therefore the SCTP stack has to manage the UDP port numbers being used. This
is an important part of the UDP encapsulation. Since this is not used when
using DTLS, there is a major difference between the documents.
> 
>> These need to be handled in a specific way as described in RFC 6951. This does
>> not apply here. This document describes how to run SCTP over a connections
>> oriented protocol without providing SCTP with any information about IP addresses
>> and UDP port numbers.
> 
> I can't see why Section 6.1 wouldn't apply equally well here, though. Even when you run over DTLS you still need to pick a transport port number, no?
Yes, but this is not managed by the SCTP stack. This is managed by the DTLS layer.
And I don't think DTLS can deal with UDP port number changes during the communication
as SCTP can. SCTP/UDP as described in RFC 6951 can survive that a NAT box changes
the port number mapping, SCTP/DTLS can't...
> 
>> You might run DTLS over TCP or HTTP or whatever.
>> So I added at the end of the Overview:
>> 
>> <t>Please note that the procedures defined in <xref target='RFC6951'/>
>> for dealing with the UDP port numbers do not apply here.
>> When using the encapsulation defined in this document, SCTP is agnostic
>> about the protocols used below DTLS.</t>
>> 
>>>> 
>>>> 3 - I don't understand "sent down to the DTLS layer"; RFC6951 doesn't say "sent down to UDP". But, as noted, this section isn't needed.
>> Replaced by:
>> When an SCTP packet is provided to the DTLS layer, ...
> 
> OK.
> 
>>>> 
>>>> 4 - The first sentence should be "SCTP over DTLS MUST support DTLS v1.2 or higher [RFC6341]."  T
>> A similar comment was already made resulting in the following text:
>> 
>> The DTLS implementation MUST be based on DTLS 1.2 [RFC6347]. The support of future versions of DTLS is RECOMMENDED if defined.
>> 
>> Is that acceptable?
> 
> Yup.
> 
>>>> 
>>>> The MTU discovery is already in DTLS 1.2 - no need to state, and no need to require that particular solution (e.g., it seems OK if DTLS updates it).
> >
>> I don't think DTLS 1.2 requires you to uses probe packets defined in RFC 6520.
> 
> That's correct; it doesn't -- it leaves PMTU discovery to the application (Sec 4.1.1.1).
Which is SCTP, in this case... One of the options allowed. So are you suggesting just to require
that SCTP the PMTU discovery and take out the option that DTLS does it? I'm fine with that change,
especially because this is exactly what RTCWeb does.
> 
>> What we want to avoid, is that user data is used as probe packets.
> 
> If that's true, you need to motivate it rather than just declaring so.
OK. What about adding:
User messages SHOULD NOT be used as probe packets, because during probing
this results in potential packet loss which increases due to the necessary
retransmissions the delay of the user message transfer.
> 
> I don't understand why it would be true, FWIW. DTLS leaves PMTUD up to the application - which arguably is SCTP here. If the extensions in RFC 6520 are that important, why don't they UPDATE the DTLS spec? (they don't). And why aren't they MUST or SHOULD?
> 
> (I'm disappointed -- but not surprised -- that RFC 6520 appears to have no indication of the status of the extension, e.g., MUST, SHOULD, etc., in relation to the TLS/DTLS spec)
Again: What about just requesting SCTP to do the PMTU here?
> 
>>>> 
>>>> I'm not sure what the issue with probe packets is, but why is this a MUST, rather than just the statement "Probe packets are supported using existing DTLS extensions [RFC6520]"? Again, do you care if there are other DTLS methods for doing this?
> >
>> We do care that RFC 4821 is used with probe packet not being user messages.
>> So RFC 6520 provides one way. Other might be possible in the future.
> 
> Then update the doc in the future; if this is standards-track (and it appears to be intended for that), you should state the MUST of 6520 and leave any future extensions for future authors of an update IMO.
> 
>> So what about
>> For probe packets, the extension defined in <xref target='RFC6520'/> can be used.
> 
> MUST, IMO.
Hmm. This means that the current text is OK:
For probe packets, the extension defined in [RFC6520] MUST be used.

However, it depends on taking out the "DTLS does the PMTUD" option...
> 
>>>> 
>>>> The Path MTU paragraph is already addressed in RFC6951 - why add it here?
> >
>> Because RFC 6951 doesn't apply here.
> 
> Again, I think it really does. You're just adding another layer (DTLS), but ultimately there are two layers you need to be concerned about - DTLS and UDP.
And as explained above: SCTP, when used over DTLS, does not deal with UDP port numbers at all,
however, SCTP, when used over UDP, does...
> 
>>>> 
>>>> The doc should explain why you care about disabling DTLS compression.
>> Hmmm. It is stated:
>> SCTP performs segmentation and reassembly based on the path MTU.
>> If DTLS performs compression, which limit should SCTP use knowing that
>> it fits into the packet.
> 
> The uncompressed size.
> 
> Note that neither PMTUD nor PLMTUD RFCs mention compression, and ROHC doesn't mention MTUD. VJ's compression mentions the interaction, but allows it.
What I don't understand: SCTP send a probe packet of size M, it gets compressed to size m, m is the PMTU,
so it makes it to the peer, and PMTUD concludes that the path MTU >= M.
Now SCTP fragments a user message to size M, however, this time he compressed packet has size m' with
m' > m. The packet is larger than the PMTU and this is really bad...
So how can this work with compression being enabled?
> 
>> And if SCTP performs the path MTU discovery (as in the case of RTCWeb),
>> than it can't detect the the message size of the outgoing packet.
> 
> Sure it can; it measures from the size of the packets sent (compressed), though.
But this size is only known by the DTLS layer and is useless to SCTP, since
it must fragment the messages such that the compressed message would fit.
How could SCTP know?
> 
>>>> 
>>>> The last sentence seems like it should be MUST NOT.
>> No. How can you send probe packets if you can't send packets larger than
>> the current PMTU.
> 
> How can you do PMTU discovery if IP fragments the packets (which you mention in the next sentence)? You need to more carefully discuss how probe packets are generated and avoid outgoing fragmentation (as well as on-path fragmentation). And it would apply only to probes.
Yes, this is how PMTU works. For IPv4, SCTP controls the DF bit.
The only crucial point is that the DTLS layer allows the SCTP to do this. This requires:
* the DTLS layer to pass this information through
* the lower layer of DTLS to provide a way to control the DF bit.
> 
> That's an interaction a layer below DTLS, but you need to address it here too.
Yes. The current document (not yet submitted) contains (based on a discussion at the
IETF meeting):


   If path MTU discovery is performed by the SCTP layer and IPv4 is used
   as the network layer protocol, the DTLS implementation MUST allow the
   DTLS user to enforce that the corresponding IPv4 packet is sent with
   the Don't Fragment (DF) bit set.  If controlling the DF bit is not
   possible, for example due to implementation restrictions, a save
   value for the path MTU has to be used by the SCTP stack.



> 
>>>> 
>>>> I.e., overall, it seems like you get what you need with a simpler first sentence, and the last two only.
>> I don't think so. This document is independent from the UDP encaps one...
> 
> I don't see how you can discuss things like MTU discovery and be independent of any transport discussion at all.
> 
>>>> 
>>>> 5 - same stacked header problem
>> Right. Fixed. I added:
>> <t>This section describes the usage of the base protocol and the applicability
>> of various SCTP extensions. Since SCTP is agnostic about the protocols being
>> used below DTLS, explicit IP addresses MUST NOT be using in the SCTP control
>> chunks. As a consequence, the SCTP associations are single homed.</t>
> 
> Introductory headers shouldn't include requirements. IMO, leave that address requirement for a subsection; the header paragraph should setup the subsections only.
OK. So just:

  This section describes the usage of the base protocol and the
  applicability of various SCTP extensions. 
> 
> Further, this sounds like something that ought to be mentioned in the asbtract and intro - it might severely limit the utility of the approach.
OK. Added:

Using encapsulation method described in this document, SCTP is agnostic
about the protocols being used below DTLS, explicit IP addresses can not
be used in the SCTP control chunks. As a consequence, the SCTP associations
are single homed.

to the abstract and the overview contains already:

<t>Please note that the procedures defined in <xref target='RFC6951'/> 
for dealing with the UDP port numbers do not apply here.
When using the encapsulation defined in this document, SCTP is agnostic
about the protocols used below DTLS.</t>

> 
>>> 
>>>> 
>>>> 5.1 - odd wording on first sentence. seems like you want to say "This doc defines SCTP [RFC4960] in DTLS 1.2."
>> I just want to make clear which specification is used for SCTP. So what about:
>> <xref target='RFC4960'/> specifies SCTP.
>> Is that better?
> 
> Not really; maybe you wan to say:
> 
> This document uses SCTP [RFC4960] with the following restrictions, which are required to reflect...
OK. So it read now:

<t>This document uses SCTP <xref target='RFC4960'/> with the following
restrictions, which are required to reflect that the lower layer
is DTLS instead of IPv4 and IPv6 and that SCTP doesn't deal with the IP
addresses or the transport protocol used below DTLS:

> 
>>>> The issue here is, IMO, more that DTLS is connectionless *vs UDP* (the comparison is more direct).
>> Correct. I changed the wording to:
>> 
>> However, the following restrictions are necessary to reflect that the lower layer
>> is DTLS instead of IPv4 and IPv6
> 
> or UDP over IP as per RFC6951
No. RFC 6951 supports multihoming, RFC 6951 does support UDP port number mapping changes...
> 
>> and that SCTP doesn't deal with the IP
>> addresses or the transport protocol used below DTLS:
> 
> IMO, it's more that it *can't* deal with addresses that far down.
It depends... At least it is not the way intended by this ID...
> 
>> Does that address you issue?
>>>> 
>>>> I would not suggest using abbreviated terminology; you refer to associations only in one place. Why make it hard to understand that you mean "SCTP associations"?
>> Agreed. Using SCTP association here.
> 
> AOK.
> 
>>>> 
>>>> The last bullet in this list is redundant; it's already covered in SCTP over UDP. IMO you're really applying SCTP over UDP to this, so you should refer to RFC6951 as normative and describe this as a superset of that.
>> Again. I don't see RFC 6951 applying here.
> 
> See above; I think it is really relevant, and odd to present this approach as completely distinct from that RFC.
I think it is important to understand the relation... Taking my explanation above into account,
do you still think this is the same?
> 
>>>> 
>>>> 5.2 - redundant with RFC6951 AFAICT
>> See above.
>>>> 
>>>> 5.3 - why not put all the "no explicit addresses in band" somewhere, and include both this and other uses of addresses as examples?
>> Makes sense. I added corresponding text to the section introduction as given above.
> 
> Sure.
> 
> Joe
> 
>>>> 
>>>> -----
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>> 
>