[tsvwg] First review of draft-ietf-tsvwg-multipath-dccp-09

[Olivier Bonaventure <[e-mail]>]

Hello,

As requested by Markus and Gorry, I did a first review of 
draft-ietf-tsvwg-multipath-dccp-09. I'm not involved in any 
implementation effort for MPDCCP and my review is independant of 
implementation considerations. It would be interesting to have reviews 
from implementors who are no co-authors of the draft.

The proposed multipath extension uses several of the techniques included 
in Multipath TCP. This choice has advantages (Multipath TCP is known and 
works) but also drawbacks (the constraints on Multipath TCP are 
different than the constraints on DCCP).

I will start my review with the high level design choices and then will 
discuss the organisation of the document and then more minor details.

Note that I will be offline until mid-August and won't be able to 
immediately respond if you react to this email.

Best regards,


Olivier

High level design choices
-------------------------

MPDCCP uses subflows like MPTCP and HMAC to authenticate addresses.

My first concern is the utilization of the Token in MPDCCP which is 
derived from the keys exchanges during the handshake. This design was 
required in MPTCP because there was no space in the extended SYN header 
to carry a connection identifier. In MPTCP, this forces the server to 
check for hash collissions when generating keys. There is no need to 
included this complexity in MPDCCP. MPDCCP would be clearer and probably 
easier to implement with a connection identifier that is selected by the 
host that receives MP_JOIN requests and could be exchanged durign the 
second phase of the handshake for example.

My second concern is the utilization of a single Multipath option. In 
MPTCP, this was required to deal with middleboxes. I'm not sure that 
there are middleboxes that understand DCCP and interfere with it.

The draft does not clearly specify how the sub-options can be used and 
whether there is an ordering of the different options. For example, to 
advertise an address, the DCCP packet must contain MP_SEQ, MP_ADDR and 
MP_HMAC, but the ordering of the options is not strictly defined. The 
difficulty comes when a single packet contains several MP_ADDR, MP_PRIO 
and other types of options that require confirmation.

The semantics of the confirmation of some options is not clearly 
defined. My suggestion would be to use options that contain all the 
required information, i.e. sequence, address and HMAC for MP_ADDR. This 
would simplify the processing of the option and reduces the error cases 
that a receiver would need to handle (imagine a fuzzer that creates 
MPDCCP options in any order, the receiver needs to handle them correctly).

Another concern with the confirmed options is whether the 
acknowledgements are for individual options or cumulative (i.e. ack 123 
acks 121, 122 and 123) ? The wrap of the MP_SEQ sequence number also 
needs to be defined in the text. What happens when a host sends 3 
options that require confirmation, but the first and the second are 
lost. Do they need to be delivered in sequence at the peer, do we need 
to wait for retransmissions ? What happens if a retransmission is lost 
several times, is there a risk of deadlock ?

The document defines several types of keys, including ECDH keys. 
However, if Diffie Hellman keys are used, it should clearly indicate 
that these keys are not authenticated and thus an on-path middlebox 
could do a MITM on the MPDCCP connection.


Document organisation
---------------------

Section 2 should be expanded to provide a high level overview of the 
operation of the protocol. There are parts in sections 3.3, 3.4, 3.5 
that are required to understand the discussion in 3.2.

The document should probably define more precisely the state that a DCCP 
implementation should maintain on a per connection or pet path basis and 
how the different multipath options affect this state (in particular 
whether the state is modified when an option is sent bot not yet 
confirmed and what happens when options are received out-of-sequence)

Although the document insists on compatibility with existing DCCP 
applications, I'm not aware of widespread dccp applications. It could be 
useful to have a companion document that describes sample mpdccp 
implementations.


Minor details
-------------


Abstract

I would not place references in an abstract

Introduction

It would make sense to compare MPQUIC also in the introduction. MPQUIC 
supports streams and datagrams and progresses well within the IETF with 
several implementations and interoperability tests planned. MPQUIC is 
also planned for ATSSSv2

1.3

I would suggest to allow mpdccp to support a limit in the number of 
subflows that a host can support. MPTCP does not directly provide this, 
but MPQCUI does this by allocating CIDs. MPDCCP could at least have an 
error message that indicates that there are too may subflows. An 
implementation cannot easily support an unlimited number of subflows and 
this has security implications.

2.

First para, I would not use the term subflo here

3.1

The document discusses the possibility of having different versions of 
MPDCCP, but it is not clear which version is specified by the document. 
Is it version 0 ? Is so, then let's stick to version 0 and explain how 
version 1 could be defined and negotiated. Figure 4 is miselading for me.

3.2.1

The word dataset is unclear and not defined. You might define the 
abstract state that a MPDCCP implementation should support

The semantics of the confirmation of messages needs to be clearly defined.

The para "The length of the MP_CONFIRM ... MP_ADDADDR." is unclear

MP_SEQ is maintained per connection and not per path. Is it used for 
reordering of data packets or only for control packets ? Please specify 
how sequence number wraps

For MP_ADDADDR, you might explain that each host maintains a list of 
unique address identifiers and that it manages them as it wishes.

3.2.3

The MPDCPP connection stays alive at the data level when a subflow is 
closes, but for how long ?

FAST_CLOSE must be received on all subflows. What happens is FAST_CLOSE 
is not received on one subflow. In MPTCP, the FAST_CLOSE operation was 
defined this way to cope with middleboxes that track RST, this might not 
be required here


The last two paras of this section are unclear

3.2.4

Does a host needs to support all these key mechanisms ?

3.2.6

This version of MPDCCP only defines one HMAC based on SHA-256. If SHA256 
gets deprecated for any reason, would this require a new version of MPDCCP ?

I would suggest to add some pseudocode to clarify how the data from the 
options is processed. Please also indicate that you use the network 
order representation of the addresses

3.2.7

The period and the rtt smoothing algorithms are unclear. Are they part 
of the CID ?

assuming a packet lost after path_delta/2 ignores jitter

3.2.8

An on-path middlebox can extract the keys used by the hosts as in MPTCP. 
This should be discussed in the middlebox section because this could 
have an impact if one day MPDCCP mbox are designed

3.3

What is the motivation for sending key-A and key-B in the second phase 
of the handshake ?

3.8

If MPDCCP uses the minimum MPS accross all paths, there is a risk that 
an on-path attack on one path forces the utilization of very small 
packets on all paths. MPDCCP should be able to detect this attack and 
drop paths with a too low MPS