Thomas, Please see some comments below:
Thomas Narten wrote: > > 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. >From my perspective the cost of implementing IKEv2 on a device is congruent to >the cost of implementing any other key management protocol. E.g., TLS is about >as complex. So maybe it boils down on whether we want to mandates that a mean >to secure the internetwork layer is available on every IPv6 node. I think so. > 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. Sure. > 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. Fair enough. In which case somebody can choose application or transport layer security instead of network layer security. Still, there is a class of scenarios where network layer security is the best fit, and we should be mandating that these are available for use, when it makes sense. > 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. If I'm going to use an iPod to remotely connect to my home network, it would make sense that it supports IPsec to provide a VPN function. That way all IP traffic is protected. That being said I agree that for constrained devices it might be desirable not to implement IPsec and IKE. The question is, should we lower the node requirements bar for all devices because of constrained devices. 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. If we remove from requirements documents every feature that hasn't been implemented by all vendors, then we could just remove everything. Conversely, if all vendors were implementing every feature of the requirement document, why would we need one in the first place? The point of the requirement document is to recommend implementation of a set of IPv6 features to improve system level interoperability. > 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. >From my perspective IPsec is only choice for network layer security. There are >some scenarios where network layer security is not the best choice to secure a >system, and there one can choose to use application or transport layer >security. We should still make sure that every IPv6 node has means to protect its network layer, and make both IPsec and IKEv2 MUST implement. I'd be fine with documenting an exception for constrained nodes where it is not possible to fulfill the requirements, e.g., "Support of both IPsec and IKEv2 is a MUST for IPv6 nodes, except for constrained devices that cannot support implementations of IPsec and IKE." --julien -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
