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
--------------------------------------------------------------------
