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

[Joe Touch <[e-mail]>]

Hi, Michael,

Feedback below. Hopefully useful.

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

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

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

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

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)

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

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

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

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

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

That's an interaction a layer below DTLS, but you need to address it 
here too.

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

Further, this sounds like something that ought to be mentioned in the 
asbtract and intro - it might severely limit the utility of the approach.

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

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

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

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

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

>>>
>>> -----
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>