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

[Joe Touch <[e-mail]>]

Following up on only the points needed...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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