To reply to Julian's mail. I think the issue is more about deployments rather than devices. I know plenty of low-powered devices that have successfully implemented / deployed IPsec, when needed. However, I think the real issue is that in many circumstances, people feel that deployment specific issues are motivation not to implement / use IPsec. Why write the code if it will never be used is often the comment I have heard.
I would think it would be good if most hosts could support IPsec, for many reasons, but there will be some special purpose networks & devices that will never need IPsec. I would like it if we could rather discuss the use of IPsec and the requirements for implementing IPsec in nodes more on a deployment basis rather than a hw specific reason. My thinking is that if a node will need to participate in secure transaction, have and send data that might need to be protected, and to harden the node against certain threat vectors, than a MUST is entirely appropriate. If there are other mechanisms that are used for security, including transport layer security, which are more appropriate and cover the threat vectors that the node may be susceptible to, then that may be more appropriate. If, for some reason, the node will have a specific deployment where security is not needed for any reason, then the requirement drops to a SHOULD. I would still suggest it is SHOULD because the person writing the SW stack will never know all of the scenarios that the node will be deployed. John > -----Original Message----- > From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of > ext Brian E Carpenter > Sent: Saturday, July 24, 2010 2:08 PM > To: Laganier, Julien > Cc: Thomas Narten; ipv6@ietf.org > Subject: Re: Node Requirements: Issue 17 - IPsec/IKE > > On 2010-07-25 05:42, Laganier, Julien wrote: > ... > > So if we could come up with processing power and memory values under > which a device is considered constrained (e.g., less than 50MHz and 8MB > memory) and IPsec downgrades from a MUST to a SHOULD it seems to me > we'd have cleared the way. > > That is truly an engineering decision for a given implementor. > I can't imagine any values we could choose today that would still > be valid twenty years from now; and we need to think of this RFC > still (perhaps) being used in twenty years. > > It's very clear from the IPv4 market, where IPsec/IKE(v2) have > exactly the same value from a security view, that the industry > sees this as a SHOULD requirement. Apart from a vain attempt to > validate the myth that IPv6 is in some way more secure than IPv4, > I can't see any advantage in deviating from a straightforward > RFC 2119 SHOULD. Vendors will do what they will do. > > Brian > -------------------------------------------------------------------- > 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 --------------------------------------------------------------------
