Hi, My first choice was (in respect with RFC 2119): - a MUST for IPsec Because IPsec is the security architecture for the IP layer. - a SHOULD for IKEv2 Because, o Anti-replay service available for AH and ESP requires automated SA management (cf. RFC 4301) o Regarding scalability/deployment, IKEv2 is useful o Some IPv6 nodes may have constraints (e.g. 6lowpan nodes), even if I believe that constraints, with time and improvement of technologies, disappear in the end.
but seeing that some people deliberately interpret "SHOULD" as a "MAY" (i.e. the good technical reason to avoid the implementation of the protocol is in fact only a political/company/personal - make your choice - reason), I've decided to change my mind: - a MUST for IPsec - a MUST for IKEv2 Best regards. JMC. 2010/7/20 Thomas Narten <nar...@us.ibm.com>: > Folks, > > A revised version of draft-ietf-6man-node-req-bis-05.txt has been > published, but it's Security section needs work. In particular, the WG > needs to answer the following questions: > > - Should IPsec be a SHOULD or MUST? > - What about IKEv2? > > Let me start with some background: > > RFC 4294 says the following: > >> 8. Security >> >> This section describes the specification of IPsec for the IPv6 node. >> >> 8.1. Basic Architecture >> >> Security Architecture for the Internet Protocol [RFC-4301] MUST be >> supported. >> >> 8.2. Security Protocols >> >> ESP [RFC-4303] MUST be supported. AH [RFC-4302] MUST be supported. > > ... > >> 8.4. Key Management Methods > >> An implementation MUST support the manual configuration of the >> security key and SPI. The SPI configuration is needed in order to >> delineate between multiple keys. >> >> Key management SHOULD be supported. Examples of key management >> systems include IKEv2 [RFC-4306] and Kerberos; S/MIME and TLS include >> key management functions. >> >> Where key refresh, anti-replay features of AH and ESP, or on-demand >> creation of Security Associations (SAs) is required, automated keying >> MUST be supported. >> >> Key management methods for multicast traffic are also being worked on >> by the MSEC WG. > > There are a couple of problems with the above text. > > First, AH [RFC4302] is listed as a MUST. This is old/obsolete. The > newer versions of the IPsec architecture have changed this to a > MAY. ESP now includes integrity protection, so one can achieve > authentication via ESP and NULL encryption. Thus, the node > requirements document will change AH to a MAY. (This should not be a > controversial change.) > > The real issue though is as follows: > > The key managment recommendation is only a SHOULD, yet doesn't > actually recommend one particular protocol. That said, the only > available key management protocol is effectively IKE. Thus, the Node > Requirements recommendation is a SHOULD for IKE (and IKEv2 in > particular). > > But, RFC 4301 (the Security Architecture) is listed as a MUST. If one > looks at 4301 closely, it effectively mandates IKEv2 (see > http://www.ietf.org/mail-archive/web/ipsec/current/msg06259.html). That > is, the IPv6 Node Requirements RFC says SHOULD for IKEv2, yet > indirectly also says MUST for IKEv2. Talk about wanting it both > ways... > > Some more thoughts. > > 1) Mandating IPsec (just ESP) without also supporting a key management > protocol has rather limited applicability. For many years, the IPv6 > WG has insisted on IPsec being a MUST (for strong security), but in > the absence of key management, that requirement (IMO) rings hollow. > > 2) The IPv6 WG has in the past been hesitant to mandate IKE for all > hosts. This was viewed as a difficult requirement for some > devices. Although there are more implementations of IKE today, I > suspect there would still be hesitation to mandate IKE on all > nodes. > > 3) We've gained a lot of experience with security and security > protocols over the last decade. If there is one overarching > lesson, it's that security isn't easy, and it's not just about > protocols. It's also about key distribution, certificates, > operational practices, etc. > > Moreover, it is now recognized that with security, there is no > one-size-fits-all panacea. We have a plethora of security > technologies (ssh, ssl, tls, IPsec, etc.) and some really are more > appropriate for some applications than others. So IPsec is not > going to turn out to be the single "holy grail" security > technology. It has its place, and I expect we'll see a lot more > usage of it over the next decade, but it is not likely to displace > all other approaches. And for some classes of devices and > applications, other security protocols will be more appropriate > than IPsec. > > 4) The breadth and range of devices that support IP is simply > staggering. Many are small, and some are so small, they really do > have legitmate issues with supporting IKEv2. Does it make sense for > the IETF to mandate that an iPod run IPsec and/or IKE? Sensor > devices? Personally, I don't think so. > > Even the current recommendation that IPsec/ESP be a MUST seems a > bit like ivory-tower syndrome. IPsec does make sense in a lot of > environments, but simply isn't required in all devices. And having > the IETF say it is required hasn't forced all vendors to implement > IPsec in their devices. > > Thus, it is my recommendation that the next version of the node > requirements document make support for IPsec and IKE both SHOULDs > only, with a lot more explanatory text that makes it clear that there > are some types of devices where IPsec is not necessarily the best > choice. > > Thoughts? > > 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 > 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. > > 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. > > > 10.1. Requirements > > Security Architecture for the Internet Protocol [RFC4301] SHOULD be > supported by all nodes. Those nodes implementing the Security > Archecture MUST support ESP [RFC4303] and MAY support AH > [RFC4302]. In addition, such nodes SHOULD implement IKEv2 [RFC4306]. > > 10.2. Transforms and Algorithms > > The current set of mandatory-to-implement algorithms for ESP and AH > are defined in 'Cryptographic Algorithm Implementation Requirements > For ESP and AH' [RFC4835]. IPv6 nodes implementing IPsec MUST > conform to the requirements in [RFC4835]. > > 10.3. Key Management Methods > > An implementation MUST support the manual configuration of the > security key and SPI. The SPI configuration is needed in order to > delineate between multiple keys. > > Where key refresh, anti-replay features of AH and ESP, or on-demand > creation of Security Associations (SAs) is required, IKEv2 keying > MUST be supported. > -------------------------------------------------------------------- > 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 --------------------------------------------------------------------
