I concur with Jeffrey regarding the email objective to the IETF below. The IETF develops specifications and guidelines (being loose here with the term). Our role is to "not" standardize deployment practices. The market uses this SDO work here to define their deployment scenarios for their business. GM, Boeing, USG and DOD, Wal-Mart, British Telecom, SKT, Toyota, etc. are all businesses and they will adopt what is mandatory or not-mandatory to support their missions and goals. What the market does depend on from us in the IETF is interoperability across the specifications, though I would expand that to the capabilties of connectivity, interoperability, discovery, security, and end-to-end. However, if we can learn from the market for the case being node requirements, within this discussion, that is a prudent and useful exercise to pursue as an input data point to us, and John's position to us I think reflects this quite well.
Regarding IPsec: IPv6 can restore the capability of end-to-end between two nodes without NAT methods being used, through globally routable addresses, which is required by several technology trends in the market (not enough address space with IPv4). Using IPsec encryption (the market will determine the PKI is my view) a user can encrypt/decrypt end-to-end their data below the IP header in the case where there is zero trust for any middle node within the end-to-end network path, and any edge distributed firewalls (my view of where they are headed at the secure edge) simply passes IPsec traffic through as a policy and trusts the IPsec connection. At Danvers, I think 1995, I was against IPsec being mandatory for IPv6 and the primary reason (not the only one I also liked SKIP and other issues :--)) was it was to much of a MUST to put on IPv6 development in the market at that time as an implementor at that time. I and others lost that debate in the IETF. Today it is different the "network stack s" to support IPv6 for the most part have all been developed within any commercial product (clearly more work is requiired above the network stack) I am aware of at this time. If IPsec is a MUST my view is that today most of it has been developed by most commercial products, and it does state from this SDO IPsec is required for proper secure operations at the IP Layer. Today I think it should be a MUST and for node requirements from the IETF view. For the market it will become a MUST product requirement or commercial products simply will loose to their competitors who do support IPsec, and that is how the free market economy should work, and the IETF should not try to influence that aspect of the market. My view is all enterprises should mandate IPsec and if they do there is nothing we can do about that in the IETF. But, we should make sure IPsec supports the IETF requirements we deem necessary for any protocol specification. /jim > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Dunn, Jeffrey H. > Sent: Monday, February 25, 2008 11:28 PM > To: Manfredi, Albert E; Brian E Carpenter > Cc: [email protected] > Subject: RE: Updates to Node Requirements-bis > > Colleagues, > > Although I do not speak for either DISA or NIST, I believe > that the spirit of Jeremy's request was that the > specifications (RFCs) required by the DISA and NIST documents > be considered for inclusion in the updated node requirements > document. I am working on he deltas between the NIST draft 1 > and 2, and the DISR. > > Best Regards, > > Jeffrey Dunn > Info Systems Eng., Lead > MITRE Corporation. > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Manfredi, Albert E > Sent: Monday, February 25, 2008 8:30 PM > To: Brian E Carpenter > Cc: [email protected] > Subject: RE: Updates to Node Requirements-bis > > > -----Original Message----- > > From: Brian E Carpenter [mailto:[EMAIL PROTECTED] > > To: Manfredi, Albert E > > > > I would agree that someone should reconcile, or at least > identify, > > > all the differences, although I don't know that it should be the > > > IETF. > > > The IETF's job is to make the Internet work better (RFC 3935) so we > > obviously have to give that priority. It would certainly be > useful to > > understand why the DISA and NIST profiles differ from the IETF's > > profile, but aligning with DISA and NIST shouldn't be a goal in > itself > > as far as I can see. > > Typically, the NIST requirements seem more stringent. My only > point is that if any explanation for differences is deemed > desirable, I would expect that DISA or NIST be the ones who > explain why these differences were introduced. I think we > agree. The IETF can only guess at reasons. > > > > Same applies to IKEv2. The IETF does not mandate its use, while > NIST > > > does. > > > > See RFC 4301 section 3.2 *last* paragraph. The problem is that the > > real world is slow to move to IKEv2. It's important to > describe what's > > real, I think. The NIST requirement is "interesting" given > the state > > of products. > > I-D 4294-bis says in Section 9.4: > > 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 [RFC4306] 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. > > So automatic key exchange is not considered mandatory by the > IETF in all cases, but it is mandatory in the NIST Profile. > At least, that's how I read that. > > > > My assumption is that this rationale, protection of routing > > > protocols, is why now NIST is mandating that routers support ESP, > > > now that AH has been demoted to a MAY. A brief > clarification would > > > be welcome. > > > > Would you want to ship a router that couldn't protect the network > > layer? > > Depends what you mean. A router located in a non-secure space > can be expected to protect the way it populates its routing > tables. That's about it, though. AH seemed a good way to do > that, but ESP, for the purpose of protecting RIPng or OSPFv3 > messages, should be fine too, I think. > > Expecting more than that seems like wishful thinking, IF the > routers are in non-secure spaces. Encypting spoofed messages > coming from non-secure hosts does not make these any more > secure. What would make these more secure is ESP > host-to-host, or ESP tunneled between security gateways. > > > > Another mandate in the NIST IPv6 Profile is that both > tunneling and > > > dual stack mechanisms be supported in Government networks. > > > That's an operational issue, not a node requirement. Would > you want to > > ship a stack that could support a dual stack but not use it > to tunnel? > > Yes. If I provide a special-purpose network that provides > dual-stack, why should I have the added burden of supporting > tunneling that I will never use? My preferred approach is to > not require features that won't be used, but allow them to be > added if necessary, in the future. This saves development > time and testing efforts. > > Bert > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
