Hi, I agree with Brian as for the Address config DHC or RA MAY be used and SLAAC is MUST.
Regards, Prasad Gorja Technical Project management Freescale Semiconductor -----Original Message----- From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of ipv6-requ...@ietf.org Sent: Friday, July 23, 2010 11:49 PM To: ipv6@ietf.org Subject: ipv6 Digest, Vol 75, Issue 21 If you have received this digest without all the individual message attachments you will need to update your digest options in your list subscription. To do so, go to https://www.ietf.org/mailman/listinfo/ipv6 Click the 'Unsubscribe or edit options' button, log in, and set "Get MIME or Plain Text Digests?" to MIME. You can set this option globally for all the list digests you receive at this point. Send ipv6 mailing list submissions to ipv6@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/ipv6 or, via email, send a message with subject or body 'help' to ipv6-requ...@ietf.org You can reach the person managing the list at ipv6-ow...@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of ipv6 digest..." Today's Topics: 1. Re: Issue 20: Node Requirements - DHC vs. RA text (Brian E Carpenter) 2. RE: Issue 20: Node Requirements - DHC vs. RA text (john.lough...@nokia.com) 3. RE: Issue 20: Node Requirements - DHC vs. RA text (STARK, BARBARA H (ATTLABS)) 4. RE: Node Requirements: Issue 17 - IPsec/IKE (basavaraj.pa...@nokia.com) 5. Re: Node Requirements: Issue 17 - IPsec/IKE (Arnaud Ebalard) 6. Re: Node Requirements: Issue 17 - IPsec/IKE (Jean-Michel Combes) ---------------------------------------------------------------------- Message: 1 Date: Fri, 23 Jul 2010 09:27:16 +1200 From: Brian E Carpenter <brian.e.carpen...@gmail.com> Subject: Re: Issue 20: Node Requirements - DHC vs. RA text To: Thomas Narten <nar...@us.ibm.com> Cc: ipv6@ietf.org Message-ID: <4c48b7b4.3070...@gmail.com> Content-Type: text/plain; charset=UTF-8 > To summarize, the current document > - retains SLAAC as a MUST > - lists DHC (for address config) as a MAY > - makes DHC for other configuration a SHOULD. > - lists rfc5006bis (DNS RA Config) as a SHOULD > > Thoughts? That seems compatible with reality, although I'd expect most software writers to treat DHC as a "MUST implement" in practice. Brian ------------------------------ Message: 2 Date: Fri, 23 Jul 2010 05:46:33 +0200 From: <john.lough...@nokia.com> Subject: RE: Issue 20: Node Requirements - DHC vs. RA text To: <brian.e.carpen...@gmail.com>, <nar...@us.ibm.com> Cc: ipv6@ietf.org Message-ID: <1f18d6510cf0474a8c9500565a7e41a22d4d24c...@nok-eumsg-02.mgdnok.nokia.co m> Content-Type: text/plain; charset="us-ascii" I think for general purpose nodes, ones that can expect to be deployed in a number of different scenarios (or are mobile / nomadic), I would agree with Brian. When a node attaches to a network, it will not know before hand what kind of configuration is supported by the network. John > -----Original Message----- > From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf > Of ext Brian E Carpenter > Sent: Thursday, July 22, 2010 2:27 PM > To: Thomas Narten > Cc: ipv6@ietf.org > Subject: Re: Issue 20: Node Requirements - DHC vs. RA text > > > > To summarize, the current document > > - retains SLAAC as a MUST > > - lists DHC (for address config) as a MAY > > - makes DHC for other configuration a SHOULD. > > - lists rfc5006bis (DNS RA Config) as a SHOULD > > > > Thoughts? > > That seems compatible with reality, although I'd expect most software > writers to treat DHC as a "MUST implement" in practice. > > Brian > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- ------------------------------ Message: 3 Date: Fri, 23 Jul 2010 09:20:54 -0400 From: "STARK, BARBARA H (ATTLABS)" <bs7...@att.com> Subject: RE: Issue 20: Node Requirements - DHC vs. RA text To: "Thomas Narten" <nar...@us.ibm.com> Cc: ipv6@ietf.org Message-ID: <750bf7861ebbe048b3e648b4bb6e8f4f14ec2...@crexc50p> Content-Type: text/plain; charset="US-ASCII" > To summarize, the current document > - retains SLAAC as a MUST > - lists DHC (for address config) as a MAY > - makes DHC for other configuration a SHOULD. > - lists rfc5006bis (DNS RA Config) as a SHOULD I would prefer if nodes were required (MUST) to support one or the other mechanism for DNS config. Given SLAAC is a must, it would probably make the most sense to make rfc5006 the must. My goal is predictability. From a service provider help desk perspective, if I'm trying to troubleshoot a customer who can't get their Internet connection working, and I discover that they can ping an IPv4 address (and somehow also test they can ping an IPv6 address), but not a FQDN, then my next steps are much easier if I can predict how DNS is acquired. This is not an uncommon scenario in IPv4. Having to figure out if the device supports DNS by RA or DHCPv6, and has one or the other or both enabled, adds unnecessary steps and complexity to troubleshooting. The routers the service provider ships would also have to be default configured to provide the identical DNS info through both mechanisms. All of this extra effort could be avoided (and better user experience provided) if one of the mechanisms were required. Barbara ------------------------------ Message: 4 Date: Fri, 23 Jul 2010 18:58:53 +0200 From: <basavaraj.pa...@nokia.com> Subject: RE: Node Requirements: Issue 17 - IPsec/IKE To: <nar...@us.ibm.com>, <juli...@qualcomm.com> Cc: ipv6@ietf.org Message-ID: <faab54171a6c764e969e6b4cb3c2add21c18dee...@nok-eumsg-03.mgdnok.nokia.co m> Content-Type: text/plain; charset="us-ascii" IPsec and IKEv2 are network layer protocols that are available in the security toolkit. And so are TLS, ssh, Kerberos etc. The IETF cannot force the choice of a security protocol on applications or other protocols that need security. The choice of using IPsec and IKEv2 is available at all times. But it may not be the best fit in all cases. SDOs, application and protocol developers should be free to choose from the available options. An application may be deployed with different security mechanisms in different environments. A good example is IPsec VPNs as well as SSL VPNs. Use of IPsec on host devices today is primarily for a single usecase, i.e VPN connectivity. IPsec is used within the core of a network for many purposes. Some end-hosts may be constrained and mandating IPsec/IKEv2 in order to be IPv6 compliant is unwarranted. And other end-hosts which do support IPsec/IKEv2 may use it for some use cases and applications. But it should not be the IETFs role to mandate that it be the security protocol used in all cases. Hence a SHOULD require is sufficient in the context of IPv6 node-requirements. -Raj -----Original Message----- From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of ext Thomas Narten Sent: Wednesday, July 21, 2010 3:12 PM To: Laganier, Julien Cc: ipv6@ietf.org Subject: Re: Node Requirements: Issue 17 - IPsec/IKE Hi Julien. Just commenting on your last point.. > 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." The difficulty with such wording is we now start arguing about what a "constrained device" is. This is a judgement call, and is often not about whether it can be done, but whether it should be done at the expense of some other feature deemed more valuable to device's main function. Or by increasing the cost of the device (by adding more memory, etc.) I do like the idea of clarifying that network layer security is a good general thing and that IPsec/IKE is the solution for that. But this still begs the question in that network layer security is simply not a requirement for all applications and usages of an IP device (IMO). Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- ------------------------------ Message: 5 Date: Fri, 23 Jul 2010 19:38:51 +0200 From: a...@natisbad.org (Arnaud Ebalard) Subject: Re: Node Requirements: Issue 17 - IPsec/IKE To: <basavaraj.pa...@nokia.com> Cc: nar...@us.ibm.com, juli...@qualcomm.com, ipv6@ietf.org Message-ID: <87eieu85ec....@small.ssi.corp> Content-Type: text/plain; charset=us-ascii Hi, <basavaraj.pa...@nokia.com> writes: > IPsec and IKEv2 are network layer protocols that are available in the > security toolkit. And so are TLS, ssh, Kerberos etc. TLS, ssh and Kerberos are available in "the security toolkit" but they are not network layer protocols. IP and IPsec are. > The IETF cannot force the choice of a security protocol on > applications or other protocols that need security. That's correct and that's not what the node requirements doc is about: it's about mandating *support*, and not use. > The choice of using IPsec and IKEv2 is available at all times. In order for that to be true, you need system that *support* the protocols, i.e. implement it. This is what you are trying to prevent even for system that have enough resources. > But it may not be the best fit in all cases. SDOs, application and > protocol developers should be free to choose from the available > options. Completely true. And having IPsec and IKEv2 available on a system will never prevent someone to use TLS. It's even likely they will use the same libraries/foundations. > An application may be deployed with different security mechanisms in > different environments. A good example is IPsec VPNs as well as SSL > VPNs. > > Use of IPsec on host devices today is primarily for a single usecase, > i.e VPN connectivity. IPsec is used within the core of a network for > many purposes. That's the point. Having IPsec/IKE *available* on all nodes leaves room for the deployment of the protocol for E2E security. Additionally, it does not prevent at all the use of additional mechanisms. It will never replace TLS or ssh, because they serve different purposes. > Some end-hosts may be constrained and mandating IPsec/IKEv2 in order > to be IPv6 compliant is unwarranted. I think we all agree on that. The problem is not IPsec/IKEv2 here.It's not constrained devices either. It's the fact that we do not have an easy way (in RFC keywords) to mandate support for all devices if they can reasonably do it w/o making constrained devices look like they are not IPv6 nodes because they cannot have it. > And other end-hosts which do support IPsec/IKEv2 may use it for some > use cases and applications. But it should not be the IETFs role to > mandate that it be the security protocol used in all cases. Again, I don't understand your position: having IPsec/IKEv2 available on systems that have sufficient resources to run those does not impose its *use*. It just guarantees that it is available if you need it. Cheers, a+ ------------------------------ Message: 6 Date: Fri, 23 Jul 2010 20:19:36 +0200 From: Jean-Michel Combes <jeanmichel.com...@gmail.com> Subject: Re: Node Requirements: Issue 17 - IPsec/IKE To: Thomas Narten <nar...@us.ibm.com> Cc: ipv6@ietf.org Message-ID: <aanlktikfptfqrv4-ntq91_zuaymp2glxx7tutqkv0...@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 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 > -------------------------------------------------------------------- > ------------------------------ _______________________________________________ ipv6 mailing list ipv6@ietf.org https://www.ietf.org/mailman/listinfo/ipv6 End of ipv6 Digest, Vol 75, Issue 21 ************************************ -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
