Assigned issue 34.
> >>For Section 8, RFCs 2401, 2402, and 2406 are currently being > >>revised by the IPsec group; that should be mentioned. > > Ok. I agree that it is good to alert the reader to the > fact that some of the documents may have updated RFCs > available. Thanks. > > >>The crypto algorithm requirements should be better aligned > >>with recommendations from the IPsec wg. There's a draft that > >>lists 3DES as SHOULD, not MAY. > > The problem is that the requirements have been aligned with > the recommendations of the IPsec, as they exist in *RFCs*. > Not drafts. > > I personally think that we need to recommend and inform > about better alternatives, even if such alternatives do not > yet exist as RFCs or if they are not mandated by keywords. > This is what we have done -- the document talks about 3DES, > AES, etc. > > However, there has been general resistance in the WG (maybe even the > ADs) for us to mandate anything beyond the current normative RFCs. It > was felt that the original RFCs should rather be updated than the > node requirements document made to impose additional requirements. > If the IESG thinks its okay for us to mandate stronger algorithms > than what the current IPsec RFCs say, then I'm going to be > *very* happy. > > But if, not then I think its up to the IPsec WG to advance their > documents and mandate the algorithms that they think are > appropriate. > > >>I think that IKEv? should be a SHOULD, not a MAY. While the > >>IESG hasn't yet seen draft-bellovin-mandate-keymgmt, it will > >>soon and it describes automated key management as a "strong > >>SHOULD". That's certainly the consensus in the security area. > > This is also related to the question of what the current > RFCs say. In the case of IKE, I'm actually uncertain what > the keyword is -- it is not immediately clear to me from the > document. Perhaps it is to others, I would appreciate comments > on this! I think we should use a keyword that the current > RFCs have, whatever that is. > > Anyway, I think the node requirements document is somewhat > different than a usual IETF protocol document. In the RFC for > for protocol FOO, there are some security issues and those > are solved with the support of some security mechanisms. > > But here, the specific security issues appear within the > RFCs that we refer to, and the necessary security mechanisms > are introduced there as well. So when talking about FOO > and IKE, we know that IKE addresses FOO's issues. But in > the case of the node requirements document, the security > issues either have been addressed in the relevant RFCs, or > those RFCs should be reissued and corrected. > > Additional stuff can be extremely useful for the nodes, but it > may not address any IPv6-specific issue. For instance, if we > required IKE, TLS, and S/MIME, this would make sure that > those are available to the IPv6 nodes, but none of them would > help addressing the security issues in, say, IPv6 ND. > > So I guess what I am looking for is some guidance on whether > this document should focus on the IPv6 specific part, or give > a more general requirements. I think we need to choose between > > (1) "We, the IETF, think that in order to do IPv6, you > need <THIS>.", and > (2) "We, the IETF, think that in order to do IPv6, you > need <THIS> and the user on a node surely needs > also <THAT>." > > I'm fine doing it either way, but we need to agree what > the scope is. -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
