Subject: Re: [multipathtcp] WGLC for draft-ietf-mptcp-attacks

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 23 Jun 2014 11:17:38 +0200

Hi,

sorry for the dealy in replying.
Thanks for the comments, replies below.

El 02/04/14 09:54, Yoshifumi Nishida escribió:
> Hi, I have read draft-ietf-mptcp-attacks-00.txt.
> Please check my comments below. Also, please point out if I miss something.
>
>
> Technical Comments:
>
> 1: As described in Section 7, we have an intention to archive the same
> security level as RFC5061.
>     However, if we adopt 1) enhancement, the security level will be
> lower than this. Hence, I think we cannot recommend this.
>
>     Similarly, if MPTCP MUST work through NATs, I think we cannot
> recommend 3) and 4) enhancements.
>     From these reasons, I'm wondering if we really need to have 1), 3)
> and 4) enhancements in Section 2.1.
>     At least, I prefer to have some texts that they are not recommended
> in order to be consistent.

ok, i added the following text at the end of section 2.1

<t>Out of the 4 options described above, option 2 is recommended as it 
achieves a higher security level while
     preserving the required functionality (i.e. NAT compatibility).</t>

> 2: In 2) enhancement in section 2.1, it seems that HMAC will be
> created with the key of the receiver of the ADDR_ADDR message.
>     Is there any reason that the key of the sender is not used here? I
> think the HMAC in MP_JOIN uses both keys.

The idea is to use the same key as used in the JOIN.

I rephrased it to:

To include the HMAC of the address contained in the ADD_ADDR option 
concatenated with the key
of the receiver and the key of the sender (in the same way they are used 
for generating the HMAC of the JOIN message)
of the ADD-ADDR message.

>
> 3: In 3) enhancement in section 2.1, I might miss something, but I
> couldn't see the security benefits to include the destination address
> of the message in the HMAC as attackers can get this info.

Right, i got mixed up, i meant the address in the ADD addr that is 
alreayd in option 2, i will remove this option
> 4: In 4) enhancement in section 2.1, I'm not sure why we want to
> utilize MP_JOIN message here.
>     I think you might want to put more texts here.
the attack described requires the rewriting of the dest address in the 
mp join to work, so protecting it would solve the problem

> 5: In Section 5, 5 possible enhancements include TCPCrypt are simply listed.
>     However, in Section 7, it is mentioned that TCPCrypt seems a
> promising one. Is there any reason behind this?

Right, the text states the securing the payload seems the right way to 
go as it is compatible with nats. of the approaches suggested, only 
tcpcrypt and ssl secure the payload (but ssl was not mentioned) i 
changed the text to include the ssl approach int he promising ones, 
makes sense?

>
> Editorial Comments:
>
> 1: Section 3, I think we don't need to put '?' in the threat level.
>     Also, it seems that "(as it is hard..)" sentence is not necessary
> as it is described in the description.

ok
>
> 2: Section 3, "This, because" -> This is because

ok

> 3: Section 4.1, "(like 3)" -> I think you mean "(as described in Section 3.1)"
no, i meant 3 subflows, i made that explicit

> 4: Section 6.1, NATS -> NATs

ok

> 5: Section 7, SCPT -> SCTP

ok

>
> 6: Section 7, "Security enhancements for MPTCP" -> I think this is
> subsection title. If so, please provide the section number.

ok

I will submit a new version with these changes.

Regards, marcelo

> Regards,
> --
> Yoshi
>
>
> On Thu, Mar 27, 2014 at 9:41 PM, Yoshifumi Nishida
> <[email-masked]> wrote:
>> Hello,
>>
>> As mentioned in the London meeting, we start WGLC on draft-ietf-mptcp-attacks.
>> The WGLC will run until * April 14th *. The intended status of the
>> document is Informational.
>>
>> Please provide your feedback to the ML before the deadline.
>> The draft is available at:
>> http://tools.ietf.org/html/draft-ietf-mptcp-attacks-00
>>
>> Regards,
>> --
>> Yoshi & Phil
> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp
>

---

From: Yoshifumi Nishida <[email-masked]>
Date: Mon, 23 Jun 2014 22:05:41 -0700

Hi Marcelo,

OK. I think the texts you propose make sense to me.
Thanks for the clarification.

Regards,
--
Yoshi

On Mon, Jun 23, 2014 at 2:17 AM, marcelo bagnulo braun <[email-masked]>
wrote:

> Right, i got mixed up, i meant the address in the ADD addr that is alreayd
> in option 2, i will remove this option
>
> the attack described requires the rewriting of the dest address in the mp
> join to work, so protecting it would solve the problem
>
>
>
> Right, the text states the securing the payload seems the right way to go
> as it is compatible with nats. of the approaches suggested, only tcpcrypt
> and ssl secure the payload (but ssl was not mentioned) i changed the text
> to include the ssl approach int he promising ones, makes sense?
>
>
>
>> Editorial Comments:
>>