I left out a hyphen in the email alias for the draft authors. Sorry about that! Thanks, Steve -----Original Message----- From: secdir-bounces at ietf.org [ mailto:secdir-bounces at ietf.org] On Behalf Of Stephen Hanna Sent: Tuesday, July 09, 2013 4:53 PM To: The IESG; secdir at ietf.org; draft-ietf-manet-rfc6622bis.all at tools.ietf.org Subject: [secdir] secdir review of draft-ietf-manet-rfc6622-bis I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. And I apologize for missing the IETF Last Call deadline with this email. In my view, this document is Not Ready. This document obsoletes RFC 6622 but the text is confusing. Instead of having one section that explains what changed and the rest of the document just saying how it is now (as if this document is an RFC), the text is forever referring to the old RFC. For example, "This document reports previously assigned TLV types (from [RFC6622]) from the registries defined for Packet, Message, and Address Block TLVs in [RFC5444]." What do you mean "reports"? This document should stand on its own and only refer to RFC 6622 in a few places since RFC 6622 will be obsolete once this document is adopted. Otherwise, you're going to need to add a normative reference to an obsolete RFC! Section 1 contains these contradictory sentences: This document retains the IANA registries, defined in [RFC6622], for recording code points for ICV calculations, and requests an additional allocation from each these registries. This document retains the IANA registries, defined in [RFC6622], for recording code points for timestamps, hash-functions, and cryptographic functions, but does not request any additional allocations from these registries. To resolve IANA's confusion, I suggest that the IANA Considerations section state how things will be after this document is adopted and also include a section in square brackets with clear instructions about what IANA should change relative to what they have now in their registries. The section in square brackets can be marked for deletion by the RFC editor. Changing the name of existing TLVs is confusing! I guess I see why you changed "Packet ICV TLV" to "ICV Packet TLV" but it's still confusing. You should at least mention this change in the section that lists changes since the last version. And you should search your draft for instances of the old names ("Packet ICV TLV", "Packet TIMESTAMP TLV", and so on). There are still some of them left. I see that you changed the normative requirements in some places to make them more strict. For example, you changed a SHOULD to a MUST in section 9.2. That's OK if there's a good reason but this may cause implementations that comply with RFC 6622 to not comply with this new version. Therefore, you should mention any such changes in the "What Changed" section. People who implemented the old version will want to know what they need to change in their implementation. Although this document includes algorithm identifiers for RSA and DSA, there's no provision for conveying certificates. Perhaps the recipient is expected to already have those certificates on hand and to find them somehow (based on the Message Originator Address and the Key Identifier?). If the authors really intend for these algorithms to be useful, they should describe how certificates are handled. At first, I thought there were not Mandatory-To-Implement (MTI) algorithms in this document. Later, I learned that OLSRv2 says that all implementations of that document MUST implement draft-ietf-manet-nhdp-olsrv2-sec-03, which makes certain algorithms in RFC6622bis mandatory. RFC 6622bis should refer to draft-ietf-manet-nhdp-olsrv2-sec-03 and mention that it makes some of the algorithms in RFC 6622bis mandatory to implement. Finally, I would like to point out that implementing draft-ietf-manet-nhdp-olsrv2-sec-03 (which seems to be mandatory for OLSRv2 implementations) means that the ICV uses a "secret key shared by all routers". If any router is compromised, this shared key will be compromised as well so the attacker will be able to forge or modify OLSRv2 packets. Essentially, the compromise of any router will compromise the entire network. Such a security model is not suitable for use on the Internet. Therefore, I suggest that OLSRv2 and all the associated documents be published with Experimental status. If that is not possible, they should be published with an Applicability Statement limiting their use to networks where such a security flaw is acceptable. Thanks, Steve _______________________________________________ secdir mailing list secdir at ietf.org https://www.ietf.org/mailman/listinfo/secdir wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview