On Nov 20, 2019, at 5:15 PM, Paolo Abeni <pabeni@redhat.com> wrote:

On Wed, 2019-11-20 at 15:52 +0800, Christoph Paasch wrote:
So, let me try to compile a list of things that came up. Please correct or add anything:

Thank you for doing this!

Clarifying that the reception of a DATA_ACK means that the server
successfully received the MP_CAPABLE (Text "If B has data to send
first, then the reliable delivery of the ACK can be inferred by the
receipt of this data with an MPTCP DATA_ACK inside the DSS option
(Section 3.3).)

Ack! :) Plus perhaps stating explicitly that client CAN send DSS
instead of MP_CAPABLE + data len after the above.

Should we vouch to disallow early or late DSS mappings that are
covering a TCP-sequence space different than the packet they are
being sent on (cfr., our discussion on/around September 25th)

+1, this will simplify and clean-up the implementation, and I do not
see benefit from supporting such mappings.

ADD_ADDR-option size - last  week we discussed this briefly and I
replied by mail that the size-problem is actually for the non-Echo
option. In that one there is no way to get around it and all the bits
need to be presented. Do you agree on that?

Sorry for the lack of feedback. I originally misread the RFC the other
way, but the text is actually very clear.

To be 110% honest, I don't see why HMAC is needed here, assuming
ADD_ADDR comes after MP_JOIN/MP_CAPABLE, we already authenticated both
peers, and if an attacker can inject malicious TCP packets inside the
stream we are at loss no matter what.

The problem here is that an attacker that is off-path would be able to get himself on-path with an ADD_ADDR-attack (described at https://tools.ietf.org/html/rfc7430#section-2) and thus can observe all traffic. Sure, he still needs to guess sequence-numbers and port-numbers, but with a TCP-window of 2MB it is not all that hard.

That's why the IETF considered that attack serious enough to fix it.

I plan to send this list to the working-group by the end of the week. I keep you in CC. @all - please add anything else you can think of.


Cheers,
Christoph


Thanks,

Paolo