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

[David Mandelberg <[e-mail]>]

On 09/26/2016 12:43 PM, Dino Farinacci wrote:
>> On 09/25/2016 06:15 PM, Dino Farinacci wrote:
>>>> 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?
>>>
>>> No not for security purposes. There are multiple ways because we allow some nesting of information as well as allow for compatibility for older implementations that can’t parse some AFIs and LCAFs but is required to parse the AFI-List LCAF type.
>>
>> Ok, then I think it needs to be made clear in the security
>> considerations that this format cannot be relied on to have no more than
>> one representation for the same information.
> 
> Sorry, I am not following your point. The nesting procuedure of LCAFs allow the same type of address to be expressed multiple ways. I can’t tell from your commentary if this is a good thing for security or a bad thing. So please provide some suggested text on what you would like to see in the Security Considerations section.

Ok, here's what I'd like to see. (But remember that this is just a
suggestion. From the SecDir boilerplate: "Document editors and WG chairs
should treat these comments just like any other last call comments.")

It is possible to encode the same address in multiple ways using LCAF.
For example, the IPv4 address 192.0.2.1 can be encoded as "AFI=1,
192.0.2.1", "AFI=LCAF, lcaf-type=AFI-list, AFI=1, 192.0.2.1", or
"AFI=LCAF, lcaf-type=AFI-list, AFI=1, 192.0.2.1, AFI=0". This means that
systems that use LCAF must not assume that two distinct strings of bytes
are distinct LCAF addresses. Additionally, if an LCAF address is
digitally signed or MACed, the specific encoding of the address must be
preserved in order for the signature or MAC to be valid on receipt.

-- 
David Eric Mandelberg / dseomn
http://david.mandelberg.org/