Hi all, My fear is that if implementations on e.g. sensors show that IPSec is not affordable for this kind of device, and we put an unconditional MUST, in a few years from now we will have billions of device which do not respect RFC4294. With a SHOULD it is the same kind of issue, billions of device will be the exception.
Julien -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ed Jankiewicz Sent: mercredi 27 février 2008 13:27 To: [email protected] Cc: Brian E Carpenter Subject: Re: the role of the node "requirements" document I lean towards (3) because IPsec without IKE or something is unmanageable. I could support MUST or SHOULD, or a conditional statement, and would prefer linking to IKEv2 as part of the package. Thomas hinted at the "chicken and egg" problem with IKEv2 - we'd like to mandate it to encourage implementation, but hesitate to mandate something that hardly exists in the near future... But I would go along with Brian's sentiment about IETF not dictating use; that has been said a few times in various ways during this discussion. Reality is even if 4294 is not updated, it makes no difference to the actual implementation and use of IPsec; if revision says nothing about IPsec, it makes no difference. If the revision says SHOULD or MUST, probably makes no difference. Implementors will make their own choices as will buyers of products. Brian E Carpenter wrote: > On 2008-02-28 09:34, James Carlson wrote: > >> Dow Street writes: >> >>> 1. the Internet *does not* need a mandatory security mechanism at >>> the IP layer 2. the Internet *does* need a mandatory security >>> mechanism at the IP layer, but IPsec is not the right one because it >>> is too heavyweight 3. the Internet *does* need a mandatory security >>> mechanism at the IP layer, but IPsec *alone* is insufficient >>> (without IKE, key mgmt, etc) 4. I don't care about the architecture >>> of the Internet, because I intend to develop devices that are never >>> connected to the global Internet (and therefore play no role in >>> defining the Internet architecture or adhering to Internet best >>> practices). >>> >> I suppose I'm closest to (1) in your list, but I'd still phrase it >> differently. >> >> 5. IP itself works properly without IPsec -- and demonstrably so. >> It's not a _requirement_; it's not something that without which IP >> simply fails to operate. It's desirable, and likely highly >> desirable, but it's not a fundamental issue. >> > > I'm close to this position too, but even closer to > > 6. As long as the IETF specifies a way of securing the IP layer, it's > an implementation, procurement and operational issue whether it gets > used. Words in an RFC have no control over that. > > And don't forget what Thomas said about keying. > > Brian > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > -- Ed Jankiewicz - SRI International Fort Monmouth Branch Office - IPv6 Research Supporting DISA Standards Engineering Branch 732-389-1003 or [EMAIL PROTECTED] -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
