[secdir] secdir review of draft-ietf-mptcp-architecture-04

[Tobias Gondrom <[e-mail]>]

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security
area directors. Document editors and WG chairs should treat these
comments just like any other last call comments.


In general the MPTCP idea and approach look good.
There is a large number of security implications and potential problems
with MPTCP. The draft's security consideration section basically just
refers to two other drafts (draft-ietf-mptcp-threat-06 and
draft-ietf-mptcp-multiaddressed-02) to address and solve them. As these
elements are pretty central, I am not convinced that these references to
"work in progress" drafts are sufficient and only "informative".
Draft draft-ietf-mptcp-threat-06 describes some of the security concerns
in good detail. I would recommend that the progress of the
draft-ietf-mptcp-architecture draft should be halted/delayed until the
referenced drafts (or at least some of them) are released.


There are a number of issues I would like to raise (some of them might
have been answered in one of the several referenced documents or
documents referenced by referenced document):

- section 5.8: Considering the wide range of threats and potential
problems, section "5.8. Security"  3rd paragraph should change "A
multi-addressed Multipath TCP SHOULD be able to"  to "A multi-addressed
Multipath TCP MUST be able to".  These are really mandatory requirements
to make sure MPTCP does not break and is equal to TCP.

- does MPTCP reduce quality of service for other TCP users?
section 2.2.3 states:
"The use of multiple paths MUST NOT unduly harm users using single-path
TCP at shared bottlenecks, beyond the impact that would occur from
another single-path TCP flow."
I fully agree with this concern. However you do not indicate how this
shall be achieved.
Considering the TCP-transparancy paradigm in MPTCP this could conflict
with "fair shared resources" at bottlenecks? Maybe you can elaborate on
how you want to achieve that. I am not sure I can fully see or
understand that from draft-ietf-mptcp-congestion-01 (which btw. you
maybe should reference in section 2.2.3)?
- section 4, paragraph "Congestion Control":
this is referencing to draft-ietf-mptcp-congestion-01, which in turn
claims to have no security considerations and references to
draft-ford-mptcp-multiaddressed-01 (which is experimental and a bit
vague with the security considerations and still work in progress) and a
non-existent [REF] to deal with this problem. This is not satisfying.

- does it lead to traffic shaping (meaning that the network provider
will give individual users different qualities of service for TCP). E.g.
To make MPTCP equal to one TCP, do you have to reduce QoS for some of
its TCP pieces? Or do you identify MPTCP at bottlenecks and allow only
for specific users MPTCP?

- Packet Scheduling:
-- section 4, paragraph "Packet Scheduling" and section 5.3 "Buffer"
thinking about scheduling packets on MPTCP layer means holding TCP
packets back while waiting for others. Does that introduce a new
dimension of memory resource requirements on the receiving machine which
could lead to "flooding" attacks with MPTCP. (E.g. sending a MPTCP where
one TCP packet is missing by intent and making the receiving endpoint
keep all packets keep in memory waiting for the missing subflow packet)?
(also refers to section 5.2.  Reliability and Retransmissions)

- what should happen when two subflow packets (with the same connection
level sequence number) arrive via two different TCP paths? Within the
time until all connection packets have been re-arranged (e.g. while
waiting). Does that mean you can disrupt MPTCP by listening in on one
subflow on one path and sending fake messages that will overlap (in
connection sequence number) with packets from other paths?

- agree with the assessment of section 5.1 on double sequencing ("a
connection level sequence number, and another sequence number for each
subflow").
However:
- could this also make Denial of Service scenarios easier?
(or meaning makes it more difficult for middleboxes to determine whether
a TCP DoS attack is ongoing or a normal MPTCP (MPTCP's several TCP
subflows from one source may look like "flooding" from one source)?

- section "5.6.  Connection Identification":
comment: The Connection id MUST be protected against spoofing, because
for MPTCP aware clients this could be used to divert traffic from a
legitimate client to a non-legitimate client by spoofing to operate
under the same connection id? Normally a server will reply back to the
sender's IP address (the same TCP subflow). With MPTCP an attacker might
inject a second "connection" into the flow and divert answers from the
server to new IP (using the second MPTCP subflow path)?


Kind regards, Tobias