[secdir] secdir review of draft-ietf-manet-rfc6622-bis

[Stephen Hanna <[e-mail]>]

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