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

From: "Alper Yegin" <[email-masked]>
Date: Fri, 21 Nov 2008 18:04:10 +0200

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.

Alper

 

_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: [email-masked] (Arnaud Ebalard)
Date: Fri, 21 Nov 2008 08:50:03 -0800

>    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
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 21 Nov 2008 18:59:08 +0200

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:[email-masked]]
> Sent: Friday, November 21, 2008 6:50 PM
> To: Alper Yegin
> Cc: [email-masked]; [email-masked]
> Subject: Re: [MEXT] RFC 3775bis: mandate on the use of IPsec
> 
>

---

From: [email-masked] (Arnaud Ebalard)
Date: Fri, 21 Nov 2008 10:28:18 -0800

> we would have seen IPsec support defined for MIPv4....

Maybe the lack of security in MIPv4 and the inability to *simply* couple
the protocol w/ IPsec/IKE is one of the reason you don't see it deployed
in the wild (meaning in corporate networks, home networks, internet,
...). Maybe the tighter integration with IPsec/IKE we have in MIPv6 will
help *deploying* the protocol outside closed domains. What do you think?

Note that I could have answered the following way: MIPv4 had FA too, but
those have not been kept in MIPv6. It is another sign of the changes
brought by IPv6 networks and an example of the differences in the design
of MIPv4 and MIPv6.

MIPv6 has been designed with the new ability brought by IPv6 (flat
networks, no NAT, i.e. E2E) and in order to allow a deployment on
*common* networks. RFC 4285 probably simplifies (from your point of
view) what is proposed by 3775, 3776, 4877, ... but it limits the  
protocol in its possible deployment to those specific networks.

Note that I am not arguing against 4285. I just consider that it is best
suited for networks with specific hypothesis (closed domains, with link
layer security).

Cheers,

a+

---

From: Hesham Soliman <[email-masked]>
Date: Sun, 23 Nov 2008 10:33:30 +1100

Alper, 

We can't remove the mandate for using IPsec. Not only is it too late, there
is currently no better alternative. Please don't compare with 4285. I'm not
against having something else and was a strong advocate of CGA-based schemes
but 4285, is not a credible alternative for a PS.
Other options can be added later and SDOs may choose to mandate it for their
networks. I don't even know if that will be a good idea for interoperability
but it's certainly much more doable than removing the mandate.

In the meantime, there are other things that can be done to remove the
interaction between MIP6 and IPsec implementations, like for instance not
using IP in IP encapsulation for the BU..

Until there is a credible alternative to be compared, we can't really
discuss lowering the mandate for IPsec. Currently there is no credible PS
document. 

Hesham

---

From: "Alper Yegin" <[email-masked]>
Date: Sun, 23 Nov 2008 15:49:42 +0200

Hesham,

"mandatory to implement" is fine.
"mandatory to use" is not fine. 

And that was not mean that RFC 4285 shall be upgraded to standards track.

I hope this brief clarification helps.

Alper

> From: Hesham Soliman [mailto:[email-masked]]
> Sent: Sunday, November 23, 2008 1:34 AM
> To: Alper Yegin; [email-masked]
> Cc: [email-masked]