Re: [MEXT] Review of draft draft-patil-mext-mip6issueswithipsec-01

[[e-mail] (Arnaud Ebalard)]

Hi Jouni,

jouni korhonen <[e-mail]> writes:

> [snip] relying on TLS (or even DTLS) for MIPv6 is IMHO a bad design
> idea.
>
> Looks bad why? Please, list the points that lead to this conclusion. I
> would help us greatly.

- Because TLS has been designed to secure transport streams ..
- ... not as a key exchange mechanism for L3
- Because you map TLS ciphersuites to some enc and hash algs to be
  used with IPsec.
- Because, pratically, you create yet another variation of what EAP-TLS
  does, but using HTTP and without reusing the guaranteed key material
  generated by TLS.

Again, can you argue why you don't directly use DTLS instead of some
TLS+ESP headers variations?

>> o In 5.4.2, "The MN or the HA MAY switch between the encryption and
>>   plain text at any time based on local policies": what if an attacker
>>   knows the SPI and the sequence number. Can she start sending
>>   plaintext packets to one or another endpoint just by changing the
>>   ptype?
>
> Anyone who gets on the link between the MN and the HA, could inject
> false packets if payload protection is not used. This would be true
> for plain MIP6 as well when IPsec is not used.

Sure. But my concern is about the reverse scenario. Protection of data
is used. 

> If user payload protection (as per I-D) is used, then the change of
> PType will be noticed and those forged packets get dropped.

How? As pointed previously, there is nothing about the equivalent of
Security Policies discussed in the draft and you have that sentence:
"The MN or the HA MAY switch between the encryption and plain text at
any time based on local policies". IMHO, this is unclear to say the
least. 

>> At some point, considering you drop RO, I wonder why not going for one
>> of the following solutions instead of keeping MIPv6 in the picture:
>
> No one so far (from the MIP6 point of view) I have worked with has
> seriously requested it. Anyway, with the solution the I-D proposes, if
> the CN also implements the HAC functionality, the MN could bootstrap a
> security context with the CN and talk directly to the CN.
>
> RO can be brought in, but I am not sure if it is worth the effort in
> this particular I-D.

Maybe it is just me but without RO, mobility can be provided to clients
by a common VPN software.

>>> We believe that it does not require changes to the security engine on
>>> the host. It is a solution which uses the APIs and libraries of TLS
>>> on
>>> the host without having to modify them.
>>> The problem with IPsec/IKEv2 and MIP6 is that we end up having to
>>> modify the security subsystem to make it work and this is not a
>>> feasible option in all instances.
>>
>> One of the problem you have with MIPv6 are the required interactions
>> with IPsec/IKE, for instance in order to update the SA endpoints. In
>> draft-korhonen-mext-mip6-altsec-01.txt, you skip this point and do not
>> explain how the interactions with the IPsec stack are done. Can you
>> clarify?
>
> There is no interaction with IPsec stack.

So you reuse ESP format but have no interaction with the IPsec stack. Am
I correct on the following: you reimplement in userland all the ESP
related parsing which is available in the kernel stack.

>>> The number of messages exchanged to setup the IPsec SA is an
>>> issue. Especially when you compare it with the registration process
>>> required for MIP4. So if you compare the number of steps for
>>> registration of an MN for MIP6 vs MIP4, you would see the difference.
>>
>> Can you compare the amount of traffic exchanged between a MN and a HA
>> using IKEv2 to setup the SA with the traffic exchanged in an alternate
>> solution, say draft-korhonen-mext-mip6-altsec-01.txt?
>
> You mean the IKEv2 generated traffic between MN and HA versus TLS-
> based generated traffic between the MN and the HAC? We could provide
> such.

Yes. Thanks. 

>>> I think we can do simpler security solution than IPsec/IKEv2 which
>>> would simplify the implementation vastly while preserving the
>>> security
>>> aspects of the MN-HA communications.
>>
>> At the moment, draft-korhonen-mext-mip6-altsec-01 relies on TLS,
>> IPsec,
>> HTTP, BNF, RFC3948, ... and an additional box.
>
> TLS and HTTP. BNF processing is part of HTTP parsing anyway.
>
> From Section 5.4.
> "Actually, when data protection is used, the construction of the
> packet on the wire is the same as an UDP encapsulated ESP packet in a
> tunnel mode as defined in [RFC3948]."
>
> This does not mandate anything. It is an example. Will be removed to
> avoid the confusion.

Ack. But I think you should clarify what (from the IPsec stack) needs to
be reimplemented in userland (ESP parsing, SADB?, SPD?, ...).

BTW, I think my question on how movement is handled (what needs to be
done on HA and MN) was worth asking. It was skipped in your reply.

Cheers,

a+