Subject: [multipathtcp] Comments regarding the threat ID

From: Michael Tuexen <[email-masked]>
Date: Sun, 3 Oct 2010 19:29:56 +0200

Hi Marcelo,

here are my comments.

1. Even the base SCTP specification allows to send messages on all paths,
   if the user requests it. So the last sentence of the paragraph related
   to SCTP in section 3 is not correct.

2. In section 4 you write
   We assume that a MPTCP connection will use a sequence number for the data,
   even if the data is exchanged through different paths.
   I would add "use a single sequence number".
   I would also add that MPTCP provides an in-order delivery service of bytes.

3. The security of MPTCP should not rely on ingres filtering. Instead, I would
   prefer that having ingres filtering does not break the protocol.
   The text at the top of page 11 seems to indicate that deleting an address
   using the implicit address management requires the sender to send the
   message from the removed address. This might not be possible anymore if
   the node does not own the address anymore.
   In the case of SCTP the procedure is a follows: If a DEL-IP request is sent
   the the address to be deleted is provided as 0.0.0.0, than all addresses
   of the association except for the source address are deleted.

4. Section 5, last paragraph. It is important, that the reachability test can
   not be spoofed by the attacker. In the case of SCTP, we send a message
   with a 64-bit nonce (in a HEARTBEAT). 

5. In section 6 you write:
   However, it is not enough to achieve full hijacking of the connection,
   since part of data will be still delivered to IP1, so it would reach
   Node 1 and not the Attacker.
   This is correct from the transport layer perspective. But consider
   the application layer. If the attacker A manages that some data gets
   delivered to A and acknowledged. Then Node 1 will never receive
   this amount of data and can not deliver anything to the applications
   anymore. So from an applications point of view, it is a DoS.

6. It would be good if a receiver could react in an appropriate way
   when receiving an ACK for data is has not sent yet.

7. I agree with section 7. It might be good to make clear that the
   ADD/DEL messages should have sequence numbers which are protected
   by the HMAC. Therefore an attacker can not replay such a message (with
   possibly modified source addresses).

8. You might want to consider adding hocks for a shared secret. Then you
   could use for example TLS and the key extractor to derive some shared
   key which you could use to increase the security.

9. NiTs:
   Analisys -> Analysis in the abbreviated page title.
   The figure on page 11 needs some polishing.
   sublfow -> subflow (page 13)
   sublfows -> subflows (page 13)
   Reccomendation -> Recommendation (page 14)

Best regards
Michael

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 04 Oct 2010 17:13:43 +0200

Hi Michael,

Thanks for the thorough review

Replies below...

>     to SCTP in section 3 is not correct.
right, i removed that sentence.

>     I would also add that MPTCP provides an in-order delivery service of bytes.
ok, i have added the two changes.

> 3. The security of MPTCP should not rely on ingres filtering.

I have added the following text to clarify that we should not base the 
security on ingress filtering:

However, it should be noted that ingress filtering
deployment is far from universal, and as such it is
unwise to rely on it as a basis for the protection of MPTCP.

>   Instead, I would

I have added the following text to make this explicit:

<list><t>In addition, further consideration
about the interaction between ingress filtering and
implicit mode signaling is needed in the case that
we need to remove an address that is
no longer available from the MPTCP connection.
In particular a host attached to a network that
performs ingress filtering and using implicit
signaling would not be able to remove an address
that is no longer available (either because of a
failure or due to a mobility event) from an ongoing
MPTCP connection.</t></list>

I don't think we need to enter in this draft in the discussion whether 
removing the address is really needed or not, as this probably belong to 
the MPTCP design and not striclty related to security.

>     of the association except for the source address are deleted.
ah, nice

>     with a 64-bit nonce (in a HEARTBEAT).
Ok, i have added a sentence describing how SCTP does it.

>     anymore. So from an applications point of view, it is a DoS.
Right, i have added a sentence stating that in the document

>     when receiving an ACK for data is has not sent yet.
mmm, i am not sure, i follow, this is the context of which attack? I can 
see this in the context of flooding attacks, but we have already 
suggested to perform the reachability check for that...

>     possibly modified source addresses).
Ok, i have added the following text:

<t>A mechanism to prevent replay attacks using these messages should be 
provided e.g. a sequence number protected by the HMAC</t>

>     key which you could use to increase the security.

done, added the following text:

<t>MPTCP security mechanism should support using a pre-shared key to be 
used in the keyed HMAC, providing a higher level of protection than the 
previous one.</t>

>     Reccomendation ->  Recommendation (page 14)

fixed

Regards, marcelo

---

From: Michio Honda <[email-masked]>
Date: Mon, 4 Oct 2010 17:04:17 +0100

Hi, 
> mmm, i am not sure, i follow, this is the context of which attack? I can see this in the context of flooding attacks, but we have already suggested to perform the reachability check for that...

In our quick result of middlebox experiment, ack number that the sender has not sent yet passed through 90 paths.  
("path" means a combination of source address, destination address and destination port here)
13 paths blocked such acks.
3 paths replied the sequence number that indicates as if they received correct ack number.  

Thanks,
- Michio

---

From: Michael Tuexen <[email-masked]>
Date: Fri, 8 Oct 2010 13:25:03 +0200

Hi Macelo,

just one comment (everything else removed) inline.

Best regards
Michael

> mmm, i am not sure, i follow, this is the context of which attack? I can see this in the context of flooding attacks, but we have already suggested to perform the reachability check for that...

We left this out in the initial spec for SCTP. But I think it is better to specify how
to behave when the peers acks data which has never be sent. In SCTP we ABORT the
association.

I wasn't mentioning this in relation to a particular attack (flooding attacks would be
relevant ones), but as a general comment for security considerations. I'm mentioning
this for MPTCP, since MPTCP has a sequence number across all paths, I think.

Best regards
Michael