Colleagues, While I agree with Jim in principal, I should add that the entire premise of a "one size fits all" IPv6 node description will probably suffer from being the too low lowest common denominator. To wit, by the definition in 4294, a host runs the gamut of complex servers to UDP speakers attached to simple sensors, e.g., a thermometer. As a result, I am not sure how much impact 4294 will have with industry or government, as the definition is so broad it is almost meaningless. Just my $0.02.
Best Regards, Jeffrey Dunn Info Systems Eng., Lead MITRE Corporation. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bound, Jim Sent: Thursday, February 28, 2008 12:11 PM To: Ed Jankiewicz; ipv6@ietf.org Cc: Brian E Carpenter Subject: RE: the role of the node "requirements" document I believe all IPv6 nodes SHOULD support IPsec. I don't care about the PKI or other managed parts but if they are referenced to IPsec they should have no known protocol interoperability problems, the market will decide and select on that one is my view. This should clearly not mandate USE as others have stated. I also would support a MUST as I agree with Dow and others who can see the value of a MUST but I will not fight to hard if majority wants to move to SHOULD. If it is 50/50 for consensus I will continue to provide data why MUST has to remain. And I want to reiterate and note the important mail from Tony Hain for this polling to others as input to our collective thoughts. Thanks Dow /jim > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Ed Jankiewicz > Sent: Wednesday, February 27, 2008 4:27 PM > To: ipv6@ietf.org > 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 > > ipv6@ietf.org > > 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 > 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 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
