Re: [MEXT] RFC 3775bis: mandate on the use of IPsec

"Alper Yegin" <alper.yegin@yegin.org> writes:

> Another issue with RFC 3775 is with the following text:
>
>    The mobile node and the home agent MUST use an IPsec security
>    association to protect the integrity and authenticity of the Binding
>    Updates and Acknowledgements. 
>
> Given the presence of RFC 4285 (and its adoption) it does not make sense to
> mandate "use of IPsec." It's not like we expect RFC 4285 users to run it on
> top of IPsec because RFC 3775 mandates use of IPsec J
>
> Note that we already took care of this with RFC 5213 which says:
>
>    The mobile access gateway and the local mobility anchor MUST
>    implement IPsec for protecting the Proxy Mobile IPv6 signaling
>    messages [RFC4301].  IPsec is a mandatory-to-implement security
>    mechanism.  However, additional documents may specify alternative
>    mechanisms and the mobility entities can enable a specific mechanism
>    for securing Proxy Mobile IPv6 signaling messages, based on either a
>    static configuration or after a dynamic negotiation using any
>    standard security negotiation protocols.

IPsec has been chosen as the solution to protect MIPv6 signaling and
data (3775, 3776, 4877, ...). One good argument (IMHO) was that IPv6
node are all expected to implement IPsec. Maybe we can argue on this
IPv6 requirement for constrained devices but mext is not the place to do
that.

AFAICT, afterwhile, some specific captive environments with security at
the link level and specific habits felt the need to have a lighter,
possibly less powerful (in term of evolution and security wise)
solution. [whyauth] explains that perfectly, IMHO. 4285 is a *specific*
solution dedicated to a specific set of environments.

MIPv6 security mechanisms (based IPsec/IKE) probably have their own
drawbacks (requiring availability and integration between those
components) but it covers most cases and generic networks. For instance,
w/ a RFC4285-only based MIPv6 (no IPsec), which L3 security mechanism
would be available to protect the communications between MN and HA?

BTW, arguing against IPsec as the MIPv6 security protocol in the context
of 3775bis does not make sense.

Cheers,

a+

[whyauth] : http://tools.ietf.org/html/draft-ietf-mip6-whyauthdataoption-07.html
_______________________________________________
MEXT mailing list
MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/mext