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: ipv6@ietf.org 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 ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
