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

[David Mandelberg <[e-mail]>]

Sorry, I'm busy with my dayjob. I don't think I'll have time to get to 
this until the weekend.

On 2016-09-27 11:50, Dino Farinacci wrote:
> David, any response. Thanks.
> 
> Dino
> 
>> On Sep 26, 2016, at 9:43 AM, Dino Farinacci <[e-mail]> 
>> 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.
>> 
>>> IESG: This means that I think this document is Ready With Nits.
>>> 
>>> 
>>>>> 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.
>>>> 
>>>> Hmm, by definition, a mask-length of say 24 if a mask of 0xffffff00. 
>>>> And in 4.1:
>>>> 
>>>> IID mask-len:  if the AFI is set to 0, then this format is not
>>>>     encoding an extended EID-prefix but rather an instance-ID range
>>>>     where the 'IID mask-len' indicates the number of high-order bits
>>>>     used in the Instance ID field for the range.
>>>> 
>>>> It is clear that the high-order bits are used that cover the 
>>>> mask-length and the low-order bits are ignored. Is this not clear to 
>>>> you?
>>> 
>>> That part is clear to me. I just meant that the document as written
>>> appears to allow 1.2.3.4/24 to be equivalent to 1.2.3.7/24. If the
>> 
>> I will make this more clear. I added some text.
>> 
>>>> 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.
>>>> 
>>>> In this respect “canonical” is relative to how LISP defines to 
>>>> encode both simple AFI encoded addresses or more complex/flexible 
>>>> addresses that accompany information.
>>> 
>>> Ok. I interpreted canonical to be a security property of the 
>>> addresses,
>>> i.e., that if two addresses are not bytewise equal, then they must 
>>> not
>>> have the same meaning. If that's not what you meant by canonical, 
>>> then I
>>> think the security considerations should say that, so that nobody 
>>> tries
>>> to rely on that property in the future.
>> 
>> Canonical in this spec means semantically canonical. That is the 
>> following two IP addresses are equal:
>> 
>> AFI=1, 1.1.1.1
>> AFI=LCAF, lcaf-type=AFI-list, AFI=1, 1.1.1.1
>> 
>>>> 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.
>>>> 
>>>> We have put that in a use-case document. This Security Key LCAF is 
>>>> used by 2 use-cases. It is used for LISP-DDT and for lisp-crypto. In 
>>>> the lisp-crypto document we have a registry for cipher suites used.
>>> 
>>> Should this document reference one or both of those documents?
>> 
>> I added text to reference the two documents that use this Security Key 
>> LCAF Type.
>> 
>> I’ll post a new draft when you get me some text for the Security 
>> Considerations section. Thanks!
>> 
>> Dino
>> 
>>> 
>>> 
>>> --
>>> David Eric Mandelberg / dseomn
>>> http://david.mandelberg.org/
>>> 
>> 

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