Hi Arnaud.

> IPsec and IKE have seen limited deployment on IPv4 networks due to the
> lack of E2E there, caused by NAT (client/server model and deployment of
> TLS for protecting *applications*).

I think there is more to lack of deployment than the above. There are
many reasons why IKEv1 and IPsec are not more widely deployed than
they are.

> Additionally, I also agree that IKEv1 specification documents (RFC
> 2407, 2408 and 2409) were a pain. PKI were not deployed and this was
> a problem too.

> Today, IPv6 provides E2E connectivity between end hosts. The work
> performed by ipsecme WG on IKEv2 specification to merge previous IKEv1
> documents into something consistent (RFC 4306, RFC 4718 and now ikev2bis
> document) is impressive. PKI are now widely deployed, even if we still
> miss some global credential services. Now, most stacks (windows, linux,
> mac os x, ...) have IPv6 and IPsec available. Basically, IPv6, IPsec and
> IKE are already available on all devices which can and have any interest
> to run those.

This is way over stated. IKEv2 is just now starting to see
implementations. Usage is even further behind.

I just went to the IPv6 ready logo site and searched for IKEv2 on the
list of devices that have acheived Phase II certification. I didn't
find a single entry. (http://cf.v6pc.jp/logo_db/approved_list_ph2.php)

IKEv2 simply is not ready yet for usage on a significant scale. If you
look at the deployed based of IP devices (or even focussing on those
that support IPv6), very few of them support IKEv2 today.

> Now, the (IMHO only) remaining problems with IPsec and IKE on IPv6
> networks are the following:

>  - lack of global credential services (if some @google reads this ...).
>  - ability for end user to configure things easily, i.e. simple and
>    *usable* management interfaces

If there are still significant gaps in our ability to use IPsec and
IKEv2, that again suggests to me that it is premature to mandate it in
all devices. It is simply premature to do so, from an overall
readiness perspective.

> >    A range of security technologies and approaches proliferate today
> >    (e.g., IPsec, TLS, SSL, SSH, HTTPS, etc.) No one approach has

>  - I don't understand why you make a difference between SSL, TLS and
>    HTTPS. It's simply TLS.

OK, I need to clean this up. I could also mention SASL here, HTTP
digest, etc.

>  - Except for advanced users, SSH serves a single purpose: remote
>    connections for administration. I don't know if it should be kept
>    here.

But it is an example of a security technology that is being used to
secure a class of applications, for which IPsec could also be used,
but is not. And I suspect that IPsec will not displace such usage.

> In the end, you basically have IPsec at layer 3 and TLS at layer 4. I
> should also add the following: we use TLS in a very restricted way on
> the Internet today, for client/server communications and in fact mainly
> for browser/server communications. Mutual authentication is seldom,
> logic and configuration is per apps, ...

> >    emerged as an ideal technology for all needs. It seems clear that
> >    for the foresable future, that situation will not change. Moreover,
> >    IPsec is not viewed as the ideal security technology for all
> >    approaches and is unlikely to displace the others. That is, IPsec
> >    is not viewed as a good choice for all security needs.

> IMHO, the thing is not to mandate the *use* of an *IP security* solution
> in people' architectures and products, but to provide the guarantee that
> such a compatible IP security solution is available on the different
> systems we buy and deploy.

> AFAICT, IPsec/IKE is the only IP security solution we have. We know it
> works. It's mainly a matter of guaranteed availability, like for
> IPv6. If one has the guarantee to find that on all common IPv6 devices,
> then you get interoperability and deployment.

I agree with this. But I've also come to the conclusion that for a
class of devices, mostly characterized by small footprint and limited
functionality, there are cheaper alternatives to providing security
than requiring the use of IPsec and IKEv2.

E.g., should home gateways be required to support IKEv2 in order for
you to configure it?

> A "MUST support IPsec and IKE" would be a step in the good
  direction.

Well, that is the question for this thread!

> >    Previously, IPv6 mandated implementation of IPsec and recommended
> >    the key management approach of IKE. This document updates that
> >    recommendation by making support of both IPsec and IKEv2 a SHOULD
> >    for IPv6 nodes. In particular, it is recognized that there are a
> >    range of device types and environments where other approaches to
> >    security than IPsec can be more appropriate. This is particularly
> >    the case for smaller specialized, single-purpose devices that
> >    support only very limited applications or run on constrained
> >    hardware. In other environments, support for IPsec and IKEv2 should
> >    be considered a very strong SHOULD, if not a MUST.

> I think the text is well written and captures the main issue, which is
> IMHO related to RFC 2119: small devices that cannot run TLS or IPsec/IKE
> due to their hardware limitations prevent the use of a "MUST". Because
> we do not have another keyword in the context of RFC documents, "SHOULD"
> is the only solution if we keep those devices in the global scope of
> "IPv6 nodes".

> To me, the problem with the "strong SHOULD" is that it will not prevent
> anyone to ship an IPv6 system with TLS-enabled apps (i.e. no hardware
> limitations) and not IPsec/IKE at all while still claim compatibility
> with the standard.

That is the balancing act we are trying to achieve.

Note though that there are other profiles being developed outside of
the IETF that are focussed on specific deployments or
environments. They are free to mandate IKE even if we do not. E.g, in
the US, the DoD and the USGv6 profiles mandate IPsec and IKEv2. 3GPP
is another example.

But for an IETF recommendation, we have a broader class of devices to
make recommendations for, and a wider range of potential usages.

Thomas
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to