Subject: [multipathtcp] q about draft-paasch-mptcp-application-authentication-00

From: Yoshifumi Nishida <[email-masked]>
Date: Tue, 7 Jun 2016 08:04:19 -0700

Hello,
I might need a bit more time to think about this, but I currently have a
few questions on the draft.

1: I am wondering if this is an asymmetric scheme. I mean, if it can be
possible to use a token with G flag on one side, while a key without G flag
is used on the other side. It seems to me that the draft is a bit unclear
on this point, but I am guessing this might be typical for load-balancer
use case. I don't see incentive for client to use G flag in this case.

2: How we should react if G and H flags are set in a packet?

3: key-A and key-B in figure 2 might be token-A and token-B? (presume G
flag is used)

Thanks,
--
Yoshi

---

From: Christoph Paasch <[email-masked]>
Date: Tue, 07 Jun 2016 23:22:30 -0700

Hello Yoshifumi,

> On Jun 7, 2016, at 8:04 AM, Yoshifumi Nishida <[email-masked]> wrote:
> 1: I am wondering if this is an asymmetric scheme. I mean, if it can be possible to use a token with G flag on one side, while a key without G flag is used on the other side. It seems to me that the draft is a bit unclear on this point, but I am guessing this might be typical for load-balancer use case. I don't see incentive for client to use G flag in this case.

it was intended to be an asymmetric scheme. I agree that the use of the G-bit is not very clear in the draft.

The way I see it is that the client signals to the server its capabilities. It may thus set the G and the H bit at the same time. The server then chooses which mode it uses and thus should only reply in the SYN/ACK with one of the bits set.

We will clarify this in the draft.

> 2: How we should react if G and H flags are set in a packet? 

See above.

> 3: key-A and key-B in figure 2 might be token-A and token-B? (presume G flag is used)

When the G-flag was set in the MP_CAPABLE-handshake, key-A and key-B in Figure 2 are the keys provided by the application.

If the H-flag however is set in the handshake, key-A and key-B are the ones used in the MP_CAPABLE handshake. We do fallback to the "regular" MPTCP handshake in case the H-flag is set.

Does this answers your question?

Cheers,
Christoph

> 
> Thanks,
> --
> Yoshi
> 
> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp

---

From: Alan Ford <[email-masked]>
Date: Wed, 8 Jun 2016 09:08:05 +0100

The rfc6824bis draft already lays the groundwork for negotiating crypto
capabilities:

   For crypto negotiation, the responder has the choice.  The initiator
   creates a proposal setting a bit for each algorithm it supports to 1
   (in this version of the specification, there is only one proposal, so
   bit "H" will be always set to 1).  The responder responds with only 1
   bit set -- this is the chosen algorithm.

We are just making use of this!

Regards,
Alan

On 8 June 2016 at 07:22, Christoph Paasch <[email-masked]> wrote:

> The way I see it is that the client signals to the server its
> capabilities. It may thus set the G and the H bit at the same time. The
> server then chooses which mode it uses and thus should only reply in the
> SYN/ACK with one of the bits set.
>
> When the G-flag was set in the MP_CAPABLE-handshake, key-A and key-B in
> Figure 2 are the keys provided by the application.
>
> If the H-flag however is set in the handshake, key-A and key-B are the
> ones used in the MP_CAPABLE handshake. We do fallback to the "regular"
> MPTCP handshake in case the H-flag is set.
>

---

From: Yoshifumi Nishida <[email-masked]>
Date: Thu, 9 Jun 2016 23:46:30 -0700

Hi Christoph,

> We will clarify this in the draft.

Thanks for the clarification. I got it.
I was thinking about something like the followings, that's why I asked if
it's an asymmetric.

             Host A
                                   Host B

     ----------------------                      ----------
     Address A1                                   Address B1
     ----------                                  ----------
         |                                              |
         |            SYN + MP_CAPABLE (H flag)         |
         |--------------------------------------------->|
         |<---------------------------------------------|
         |       SYN/ACK + MP_CAPABLE(token-B,G flag)   |
         |                                              |
         |     ACK + MP_CAPABLE(Key-A, token-B,H flag)  |
         |--------------------------------------------->|

                  ----------

                  Address A2

                  ----------

         |             |                                |
         |             |   SYN + MP_JOIN(Token-B, R-A)  |
         |             |------------------------------->|
         |             |<-------------------------------|
         |             | SYN/ACK + MP_JOIN(HMAC-B, R-B) |
         |             |                                |
         |             |     ACK + MP_JOIN(HMAC-A)      |
         |             |------------------------------->|
         |             |<-------------------------------|
         |             |             ACK                |

   HMAC-A = HMAC(Key=(Key-A+ (Token-B or B'), Msg=(R-A+R-B))
   HMAC-B = HMAC(Key=(Token-B or B' +Key-A), Msg=(R-B+R-A))

You might think this is ridiculous or problematic, but I was just thinking
about load-balancer use case and curious about the possibility.
>From host A's point of view, it probably doesn't know whether host B is
behind a balancer or not.
So, I thought host A is less motivated to upgrade the application in order
to support load balancer.
You might presume host A will upgrade the app for TLS or some other
reasons, but I thought it might not be always true.

> See above.

Sorry. This is minor thing, but I thought you might want to describe how to
react when you see G and H are set in SYN/ACK or ACK.

Thanks,
--
Yoshi