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

[Michael Tuexen <[e-mail]>]

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.
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. 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, ...
>> 
>> 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?
>> 
>> 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.
What we want to avoid, is that user data is used as probe packets.
>> 
>> 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.

So what about
For probe packets, the extension defined in <xref target='RFC6520'/> can be used.
>> 
>> The Path MTU paragraph is already addressed in RFC6951 - why add it here?
Because RFC 6951 doesn't apply here.
>> 
>> 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.
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.
>> 
>> 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.
>> 
>> 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...
>> 
>> 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>
> 
>> 
>> 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?
>> 
>> 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 and that SCTP doesn't deal with the IP
addresses or the transport protocol used below DTLS:

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