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

[Yoshifumi Nishida <[e-mail]>]

Hi Christoph,

On Tue, Jun 7, 2016 at 11:22 PM, Christoph Paasch <[e-mail]> wrote:

> Hello Yoshifumi,
>
> > On Jun 7, 2016, at 8:04 AM, Yoshifumi Nishida <[e-mail]>
> 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.
>

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.



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

> 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