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

[jouni korhonen <[e-mail]>]

Hi Arnaud,

Thanks for another round of questions & comments. See my answers inline.

On Jul 28, 2009, at 11:02 AM, Arnaud Ebalard wrote:

> 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 ..

Ok.

> - ... not as a key exchange mechanism for L3

Do you have a better candidate if IKE is out of question?

> - Because you map TLS ciphersuites to some enc and hash algs to be
>  used with IPsec.

Hmm.. Didn't we agree already that there is no IPsec per se?

> - 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.

OK. I don't understand what do you mean by "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?

I don't have a good answer to this. Basically, we do not want to run  
the TLS handshake between the MN and the HA. That would have undesired  
implications during the handover.

>
>>> 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 protection of reverse tunneled traffic is used, then any  
modification of UDP encapsulated payload will be detected. Of course  
this requires that integrity check is done.

>
>> 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.

You do integrity verification? The integrity check also covers the  
PType. That is "described" (cough) in section 5.5. I admit that the I- 
D need much more details and clarifications in the next revisions  
regarding these details, but going for +100 pages in the first  
revisions was not that appealing ;) Point taken though.

>
>>> 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.

Well, that is true. However, MOBIKE has not been out that long yet (it  
is getting deployed now though). Again, the experience with  
interfacing with folks deploying mobility & VPN services is that they  
don't like the idea of protecting everything due for whatever reason.  
That usually kills the argument of using mobile VPNs for consumers.

>
>>>> 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.

Parsing is no brainer tbh. But yes, you more or less replicate the  
encapsulation parsing.

>
>>>> 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?, ...).

Point taken. We'll add more clarification about this. Currently only  
the parsing of encapsulation is needed.

>
> 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.

Hm. I seem to have missed it. I'll check that.

Cheers,
	Jouni


>
> Cheers,
>
> a+