Re: [secdir] secdir review of draft-ietf-lisp-lcaf-15

["Joel M. Halpern" <[e-mail]>]

As I understand it, the multiple representations are deliberate.  I do 
think we should add a little text in the security considerations section 
noting that the representation has to be preserved if the information is 
signed.

Your comment on the algorithm ID in section 4.7 seems cogent.  I will 
let the authors respond.

On 9/24/16 2:53 PM, David Mandelberg wrote:
> 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.
>