Last Call Review of draft-ietf-lisp-lcaf-15
review-ietf-lisp-lcaf-15-secdir-lc-mandelberg-2016-09-29-00

Hi,

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.

I found one issue in various parts of the document (described below),
but I'm not sure it's relevant to security. If it is, then I think this
document is Almost Ready. If not, then I think this document is Ready
With Nits.

There are multiple places in the document where it's possible to encode
semantically equivalent information in multiple ways, despite the word
"canonical" being in the title of the document. Is there anything that
relies on these addresses being canonical for security purposes?

Multiple places in the document (sections 4.1, 4.5, and 4.8) specify
mask lengths, but do not specify that the masked out bits MUST be set to
zero.

Section 4.4: The description of RTR RLOC Address gives two different
ways to encode an address with zero RTRs.

Section 4.10.5: If I understand the compatibility mode correctly, this
explicitly creates a second way to encode a semantically identical address.

Section 5.4: There are many different ways to encode equivalent JSON
data here.

Section 6 (Security Considerations): There is no discussion of these
addresses being canonical, and what other systems might or might not
rely on these addresses being canonical.


I also have some questions/nits:

Section 3: Shouldn't the LCAF sort-key of {afi, LCAF-Type} also include
the RLOC-address or LCAF payload?

Section 4.3: Altitude is described as a signed integer, but this
document doesn't specify the encoding. I assume it's two's complement,
but that should probably be made explicit.

Section 4.7: The Key Count description talks about "Key sections," but
doesn't say which fields are part of the key section (and can thus be
repeated). I have a guess which fields are part of the key section, but
it's not entirely clear.

Section 4.7: The Key Algorithm description doesn't point to a registry
of valid values or otherwise say how to interpret values in that field.

-- 
David Eric Mandelberg / dseomn


http://david.mandelberg.org/





Attachment:


signature.asc




Description:

 OpenPGP digital signature