Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Dino Farinacci <farinacci@gmail.com>
In-Reply-To: <D896C233-1414-4635-9DE3-FE10A7BF1E69@gmail.com>
Date: Tue, 27 Sep 2016 09:50:16 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <2979E792-737A-4027-8B79-7080AB533B9B@gmail.com>
References: <17032e8e-f1d0-8fb4-7294-2e2ca5c9fb06@mandelberg.org>
 <2290972B-B93D-496A-8AF3-16B72D19B654@gmail.com>
 <cea887fa-f076-2ada-c9c8-fce548dccfca@mandelberg.org>
 <D896C233-1414-4635-9DE3-FE10A7BF1E69@gmail.com>
To: David Mandelberg <david@mandelberg.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/Pkkldy6Fqlf0eBo1T6nZKUuAA7o>
Cc: The IESG <iesg@ietf.org>, draft-ietf-lisp-lcaf.all@ietf.org,
 secdir@ietf.org
Subject: Re: [secdir] secdir review of draft-ietf-lisp-lcaf-15
Precedence: list

David, any response. Thanks.

Dino

> On Sep 26, 2016, at 9:43 AM, Dino Farinacci <farinacci@gmail.com> =
wrote:
>=20
>> 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.
>>>>=20
>>>> 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?
>>>=20
>>> 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=92t parse some AFIs and LCAFs but is =
required to parse the AFI-List LCAF type.
>>=20
>> 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.
>=20
> 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=92t =
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.
>=20
>> IESG: This means that I think this document is Ready With Nits.
>>=20
>>=20
>>>> 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.
>>>=20
>>> Hmm, by definition, a mask-length of say 24 if a mask of 0xffffff00. =
And in 4.1:
>>>=20
>>> 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.
>>>=20
>>> 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?
>>=20
>> 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
>=20
> I will make this more clear. I added some text.
>=20
>>> 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.
>>>=20
>>> In this respect =93canonical=94 is relative to how LISP defines to =
encode both simple AFI encoded addresses or more complex/flexible =
addresses that accompany information.
>>=20
>> 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.
>=20
> Canonical in this spec means semantically canonical. That is the =
following two IP addresses are equal:
>=20
> AFI=3D1, 1.1.1.1
> AFI=3DLCAF, lcaf-type=3DAFI-list, AFI=3D1, 1.1.1.1
>=20
>>> 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.
>>>=20
>>> 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.
>>=20
>> Should this document reference one or both of those documents?
>=20
> I added text to reference the two documents that use this Security Key =
LCAF Type.
>=20
> I=92ll post a new draft when you get me some text for the Security =
Considerations section. Thanks!
>=20
> Dino
>=20
>>=20
>>=20
>> --=20
>> David Eric Mandelberg / dseomn
>> http://david.mandelberg.org/
>>=20
>=20