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

[Michael Tuexen <[e-mail]>]

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

> Following up on only the points needed...
Thanks... See inline...
> 
> On 4/8/2014 12:56 PM, Michael Tuexen wrote:
> ...
>>>>>> 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.
> 
> There's a difference, but it's not what I'd consider "major" (it could easily be stated as "do that RFC, except for Sections X and Y").
Well, when implementing it, it is the major part. Adding/Removing the the UDP header is the minor part.
Without the UDP port number handling, I think there wouldn't be a real need for an RFC, since
the header manipulation is pretty obvious to do.
> 
>>>> 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...
> 
> Fair enough, but that's just one section, and easily explained as to why it doesn't apply.
> 
> ...
>>>>>> 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.
> 
> SCTP does RFC1191 only (PMTUD).
That is why the text explicitly requires RFC4821 for PMTU in SCTP.
> 
>> 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.
> 
> I'm wondering why you want to make a specific recommendation as to how to handle MTU discovery, e.g., to require DTLS-level PLMTUD. If you have a reason, IMO include it and justify it.
The text leaves it open, which layer does it. The RTCWeb spec make it clear when used in the RTCWeb context.
In general, I'm open and this is what the text currently says.
However, we need a way of doing it
* without relying on ICMP, since we can't verify the contents
* without affecting the user data transmission with probe packet loss
That is why we want an RFC4821 based algorithm. Either in DTLS or SCTP.
> 
>>>> 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 see why this protocol needs to say that, esp. when RFC4821 doesn't. SCTP isn't a low-latency transport protocol anyway.
But we don't want to add timeouts just because we do PMTU discovery when it is not needed...
> 
>>> 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?
> 
> Same issue; I'm OK with requiring DTLS do PLMTUD, but you need to explain why. Otherwise you're constraining your solution to TDTLS implementations that support PLMTUD - and it's not a current requirement (besides, how could you even know at the SCTP layer?)
What are you suggesting:
(a) Simplify the ID by requiring to do PLMTUD at the SCTP layer
(b) Require PLMTUD either at the SCTP layer or at the DTLS layer and let
    the decision be specified in the corresponding document describing
    the particular use case.

I'm for simplicity and would vote for (a).
> 
>>>>>> 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...
> 
> That's the issue. If you really depend on DTLS support for probe packets, then MUST is fine; otherwise, it's unnecessary.
We can just specify that PLMTUD is done at the SCTP layer. That would simplify things.
> 
>>>>>> 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...
> 
> But again, port numbers are just one part of that other document. You could import the rest of that document by reference and exclude the port number issues.
For me (having both implemented) gives the impression of a similarity, which isn't there...
ICMP feedback, for example: In SCTP/UDP it might be able to process incoming ICMP packets,
since I might be able to verify the SCTP port numbers and the verification tag. With SCTP/DTLS
I can't, since the information is encrypted...
> 
>>>>>> 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,
> 
> SCTP never sends probes. Either the app does, or DTLS does.
When SCTP does PLMTUD, it sends probe packets. These would be packets containing HEARTBEAT chunks
bundled with PADDING chunks (http://tools.ietf.org/html/rfc4820)
> 
>> so it makes it to the peer, and PMTUD concludes that the path MTU >= M.
> 
> The path MTU would be m - compression doesn't affect the fact that the path supported a message (compressed or not) of actual size 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...
> 
> The packet size would be m' (the uncompressed size I was referring to above), and that's what you compare to the actual path MTU.
> 
>> So how can this work with compression being enabled?
> 
> See above. You measure what you see through the path, and compare it to the uncompressed size of the packet. Compression helps performance, but should not be considered as a way to increase effective path MTU.
But whenever SCTP sends down a packet, it is compressed. So it has no way of finding the
packet size. I think the problem is that two packet of uncompressed sizes M' and M'' with
M' > M'' can result in compressed sizes m' and m'' with m' < m''. That is why
PMTUD does work with compression.  
> 
>>>> 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?
> 
> If that's the case, then you have problems with DTLS-layer discovery too.
No. The DTLS overhead is constant (if you don't use compression). So DTLS could
provide a size for which packets would fit into the PMTU.
> 
>>>>>> 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.
> 
> When SCTP runs over IP directly. It won't work when SCTP runs over UDP or SCTP over X.
It does. At least in the FreeBSD based implementation. 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.
> 
> But that doesn't appear to be a feature of DTLS AFAICT.
It is nothing the protocol has to provide, it is a feature provided by the
implementation or not...
> 
>>> 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.
> 
> This adds a requirement to DTLS that doesn't appear to currently exist; that means this extension isn't necessarily compatible with currently compliant DTLS implementations.
Right. However, the limiting factor is not the DTLS stack, but the UDP interface...
> 
>>    ...If controlling the DF bit is not
>>    possible,  for example due to implementation restrictions, a save
> 
> safe?
> 
>>    value for the path MTU has to be used by the SCTP stack.
> 
> Presuming you mean 'safe', there's no such value AFAICT.
Formally correct. Well, RTCWeb has decided on such values: 1280 bytes for IPv6
and 1200 bytes for IPv4 (both at the IP layer). 

> 
> ...
>>>>>> 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?
> 
> Yes. You've explained a few places that are useful to separate, but the rest is relevant.
> 
> Joe
>