Subject: [multipathtcp] ADD_ADDR HMAC ambiguity

From: Christoph Paasch <[email-masked]>
Date: Wed, 20 May 2020 09:40:23 -0700

Hello,

Todd Malsbary from Intel is looking at the HMAC-support for ADD_ADDR in
RFC8684. And it appears that there can be an ambiguity on how to interpret
the truncation.

We want to clarify this and make sure all implementations,... are on the
same page with the intention of the RFC:

RFC8684, Section 3.4.1 says:
" The Truncated HMAC parameter present in this option is the rightmost
  64 bits of an HMAC, negotiated and calculated in the same way as for
  MP_JOIN as described in Section 3.2. "

Now, in Section 3.2 it mentions:
" This specification defines that HMAC as defined in [RFC2104] is used,
  along with the SHA-256 hash algorithm [RFC6234], and that the output
  is truncated to the leftmost 160 bits (20 octets). "

One can read these in two different ways:

In Section 3.4.1, the truncation to the rightmost 64 bits is based on the
full 256-bit HMAC-output or whether it is rather the 64 rightmost bits of
the leftmost 160bits (the ones mentioned in Section 3.2).

Can we clarify which of the two options is the correct one?

I personally interpret it as "right most 64 bits of the 256-bit HMAC-output".

Thanks,
Christoph

---

From: Alan Ford <[email-masked]>
Date: Wed, 20 May 2020 21:38:18 +0100

Hi Christoph,

Your interpretation is the intended one.

3.4.1 says "rightmost 64 bits of an HMAC” … the HMAC is 256 bits in both 3.2 and 3.4.1. The truncation is the separate from the definition of the HMAC algorithm used.

Best regards,
Alan

> On 20 May 2020, at 17:40, Christoph Paasch <cpaasch=[email-masked]> wrote:
> 
> Hello,
> 
> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp