On Wed, 21 Jul 2010 10:36:36 +0200 a...@natisbad.org (Arnaud Ebalard) wrote:
> Hi Thomas, > > Thomas Narten <nar...@us.ibm.com> writes: > > > Thoughts? > > 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*). 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. > > 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 > RFC 5386 / Better-Than-Nothing Security goes some way to addressing that. Obviously not as secure as properly identified peers, but as the name says (far) better than nothing. I also think we should observe what seemed to have happened with the DECT standards. Encryption was optional, so when I went to try to find a DECT phone with it, I couldn't easily find one (and didn't). Cryto does add a cost, however the scales of economy caused by mandating it reduce that cost. I'm also not completely sure the embedded platform load concern is a strong one anymore. The IEEE have mandated 128 bit AES encryption for the 802.15.4 / LoWPAN standards, and they're targeted at low power embedded platforms. So while I think the reasons to loosen the IPsec requirement are fairly valid, I'd be concerned that it would cause the "DECT problem" to happen. > > Proposed new text: > > > > 10. Security > > > > This section describes the specification of IPsec for IPv6 nodes. > > > > Achieving security in practice is a complex undertaking. > > Operational procedures, protocols, key distribution mechanisms, > > certificate management approaches, etc. are all components that > > impact whether security is actually achieved in practice. More > > importantly, deficiencies or a poor fit in any one individual > > component can significantly reduce the overall effectiveness of an > > particular security approach. > > > > IPsec provides channel security at the Internet layer, making it > > possible to provide secure communication for communication flows > > between pairs of internet hosts. IPsec provides sufficient > > flexibility and granularity that individual TCP connections can > > (selectively) be protected, etc. > > > > IKEv2 is the key management protocol for IPsec. Although manual > > keying can be used with IPsec in some cases, the overall > > applicability of statically configured keys is limited. Thus, IPsec > > without IKEv2 has only limited value. > > > > 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. > - Except for advanced users, SSH serves a single purpose: remote > connections for administration. I don't know if it should be kept > here. > > 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. > > A "MUST support IPsec and IKE" would be a step in the good direction. > > > 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. > > Cheers, > > a+ > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
