>>> 4285 relies on the MN and HA obtaining keys via an out-of-band mechanism
>>> (which for all practical purposes is access network specific). So I disagree
>>> that 4285 relies on MIP6 signaling for key exchange. 4285 simply uses the
>>> keys to compute the authenticator that is carried in the BU. So I don't see
>>> how you believe that 4285 is more tightly coupled than IPsec/IKE.
>>
>> => Well, both mechanisms don't couple key exchange with MIPv6, but 4285 uses
>> a MIPv6 option to authenticate the messages whereas IPsec doesn't. So 4285
>> is more coupled to MIPv6 than IPsec. 4285 can't be used with any other
>> protocol so I'm not sure why you don't think it's tightly coupled to MIPv6.
>
> But the authentication option within the MIP6 signaling essentially makes
> the protocol devoid of dependency on IPsec. And that's a strong +ve from an
> implementation and simplicity perspective. The auth-option specified in 4285
> is intended for MIP6 signaling messages. So I don't see why it needs to be
> used by some other protocol.
=> we're getting away from the initial subject, I was responding to your
comment about the need to separate Auth and key exchange from MIP6
signalling. IPsec and IKE do that, 4285 doesn't. That's my comment. So I
find it confusing that you ask for this separation while supporting 4285
type authentication.
Whether 4285 is a good idea (I don't think it is for all the reasons
discussed on the mext list) is another subject I think.
Hesham
>
> -Raj
>
>
>>
>> Hesham
>>
>>>
>>> -Raj
>>>
>>>> If
>>>> you're for separation then your support for 4285-like mechanisms confuses
>>>> me. Your statement above is a justification for the exact opposite of what
>>>> you're asking us to consider.
>>>>
>>>> Hesham
>>>>
>>>>>
>>>>> -Raj
>>>>>
>>>>>
>>>>>>
>>>>>> On 3/3/10 7:55 AM, "basavaraj.pa...@nokia.com"
>>>>>> <basavaraj.pa...@nokia.com>
>>>>>> wrote:
>>>>>>
>>>>>>> While there are many reasons that can be attributed to the lack of
>>>>>>> implementations and use, one that I would like to raise is the the
>>>>>>> concern with the overly complex security model that MIP6/DSMIP6 relies
>>>>>>> on today. MIP6/DSMIP6 requires IPsec and IKE/IKEv2 (RFC3776/4877) to
>>>>>>> secure the signaling between the MN and HA. The fundamental purpose of
>>>>>>> MIP6/DSMIP6 is to provide mobility to hosts. At a very high level the
>>>>>>> MIP6/DSMIP6 protocol boils down to the ability to setup a tunnel
>>>>>>> between the MN and HA and update the MN tunnel end-point whenever
>>>>>>> there is a change in the associated IP address (CoA). The signaling to
>>>>>>> establish the tunnel needs to be secure. But using a protocol like
>>>>>>> IKEv2 and IPsec to achieve this security is just an overkill.
>>>>>>
>>>>>> Well, it has its advantages too. Being able to connect to the home agent
>>>>>> from an unsecure WiFi access is one of them.
>>>>>>
>>>>>> Vijay
>>>>>
>>>>> _______________________________________________
>>>>> MEXT mailing list
>>>>> m...@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/mext
>>>>
>>>>
>>>
>>
>>
>
_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
