Improve MP_HMAC

[veselinrak]

Text updated to clarify key generation for different suboptions and to correct/clarify several other issues.

[markusa]

In the course of discussing the HMAC-SHA256 calculation, I noticed that the HMAC usage for MP_JOIN differs from that of MP_ADDADDR and MP_REMOVEADDR in that no HMAC is assigned for the first MP_JOIN. There are good reasons for this, as the nonces have to be exchanged first. I don't think we contradict this with our text at the moment, but I suspect that because we don't say this explicitly in the MP_HMAC or MP_JOIN section, the reader might think that an MP_HMAC must already be sent with the first MP_JOIN. The first place where it becomes clear is in the handshake example in figure 21.

Can you please check that https://github.com/tsvwg/ietf-multipath-dccp/pull/280/commits/74c94b7f55b452a2602118eb64e6a8fb5868b298 is addressing this correctly?

I also wonder if it could happen that multiple MP_HMACs are mixed in the third DCCP ack of the subsequent subflow handshake (Fig. 21) when an MP_ADDADDR or MP_REMOVEADDR is added? Is this a possible scenario and is there a need to refine the text explaining how received MP_HMACs must be processed?

@abrunstrom @NathalieRM @veselinrak

[abrunstrom]

Looking at Fig. 21 I am now confused. There it looks like the MP_HMAC is sent alone, but from the MP_HMAC section and our earlier discussions I thought it always followed another sub-option? If sent alone it should be ignored.

[markusa]

Looking at Fig. 21 I am now confused. There it looks like the MP_HMAC is sent alone, but from the MP_HMAC section and our earlier discussions I thought it always followed another sub-option? If sent alone it should be ignored.

I think the definition in Fig. 21 makes sense as it also follows the MPTCP HMAC authentication scheme for MP_JOIN. First the nonces RA and RB must be available before MP_HMAC can be used. The question is, what texts or passages need to be changed to eliminate your confusion?

Is it for example the sentence: Therefore, a MP_HMAC MUST directly follow its associated multipath option.? @abrunstrom

[NathalieRM]

Hi @Markus,

I think this text MP_HMAC MUST be set when using MP_JOIN in the second and third step of the handshake of a subsequent subflow as illustrated in {{handshaking}}. is not completely accurate. As Anna stated, in the third step we are not using any MP_JOIN, that is just a DCCP-Ack packet with no MP_OPTION. I would propose something like MP_HMAC MUST be sent when using MP_JOIN within a DCCP-Response Packet (See Section 4.2.6 for details). instead.

Apart from that, I agree with you with the fact that the Handshaking procedure makes sense as it is, and we just need to clarify that the MP_HMAC is not always sent along with other suboptions. In addition to the text you already outlined, I would say it is also necessary to change this text The MP_HMAC suboption is used to provide authentication for the MP_JOIN, MP_ADDADDR, and MP_REMOVEADDR suboptions, my suggestion would be The MP_HMAC suboption is used to provide authentication for the MP_ADDADDR, and MP_REMOVEADDR suboptions. In addition, it provides authentication for subflows joinning an existing MP_DCCP connection, as described in the second and third step of the handshake of a subsequent subflow in {{handshaking}}.

[abrunstrom]

We also just added text saying

In the event that an MP_HMAC cannot be associated with a suboption, this MP_HMAC MUST be ignored.

This addition is no longer correct as stated and needs to be more fine grained.

It is also a bit confusing what A is in the handshaking figure. If the text describing the HMAC is correct, A is not the same A as described in the MP_HMAC section. Do we need to also include the A from the handshake figure in the MP_HMAC section?

[markusa]

@NathalieRM I adopted your suggestion from https://github.com/tsvwg/ietf-multipath-dccp/pull/280#issuecomment-1863616121 in https://github.com/tsvwg/ietf-multipath-dccp/pull/280/commits/c02e45998beaf48dd5307236faf2af25a743b796

@abrunstrom I modified the sentence you mentioned in https://github.com/tsvwg/ietf-multipath-dccp/pull/280#issuecomment-1865272204 to cover the aspect of the single MP_HMAC sent in response to a MP_JOIN in https://github.com/tsvwg/ietf-multipath-dccp/pull/280/commits/ef9e5e9f933069d563598fc888af3401d0144fd2.

@abrunstrom Can you please explain what is confusing about "A" in the handshaking figure? We already introduce the terms "Host A" and "B" in Figure 2, and I thought we would use them consistently from then on.