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

If IPsec was so good to MIP and RFC 4285-type solution was so insufficient,
we would have seen IPsec support defined for MIPv4.... 

Alper

> -----Original Message-----
> From: Arnaud Ebalard [mailto:arno@natisbad.org]
> Sent: Friday, November 21, 2008 6:50 PM
> To: Alper Yegin
> Cc: charliep@computer.org; mext@ietf.org
> Subject: 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