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

From: David Mandelberg <[email-masked]>
Date: Sat, 24 Sep 2016 14:53:23 -0400

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/

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 24 Sep 2016 15:13:15 -0400

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.

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 25 Sep 2016 14:42:15 -0700

> 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.

> relies on these addresses being canonical for security purposes?

Yes, multiple representations is deliberate. I’ll comment in more detail to my response to David’s email.

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

I’ll make the Key Sections more clear. Stay tuned for another response.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 25 Sep 2016 15:15:02 -0700

> comments just like any other last call comments.

Thanks a lot for your comments. See responses inline.

> 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.

> mask lengths, but do not specify that the masked out bits MUST be set to

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? Would you want me to say the high-order bits are added with a mask and the bits not covered by the mask are set to 0?

> ways to encode an address with zero RTRs.

Correct. Since a list of RTRs can be encoded, you could have this encoding (which is valid and needs to be dealt with, hence the language):

afi=1, IPv4 RTR
afi=0, nothing follows
afi=2, IPv6 RTR

The above is a list of 2 RTRs but encoded with 3 entries.

> explicitly creates a second way to encode a semantically identical address.

Right, if an implementation does not support the Geo-Coordinates LCAF encoding but wants to encapsulate to the RLOC encoded, it knows how to skip over the Geo-Coordinates section and get to an AFI encoded address that it knows how to parse and use.

> Section 5.4: There are many different ways to encode equivalent JSON

Maybe, but can you be more clear. I don’t think it is a bug. Do you?

> 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.

> the RLOC-address or LCAF payload?

It cannot because each LCAF-Type has a complex set of attributes. Sometimes a list of RLOCs.

> but that should probably be made explicit.

Yes, I have fixed the text.

> repeated). I have a guess which fields are part of the key section, but

I added some text to clarify this.

> 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.

See enclosed a -16 txt file and rfcdiff.html file.

Thanks again,
Dino

---

From: David Mandelberg <[email-masked]>
Date: Sun, 25 Sep 2016 20:48:54 -0400

> 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…

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.

IESG: This means that I think this document is Ready With Nits.

> 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
format were going to be canonical, then all masked bits (the last octet
in this example) would need to be set to a well-known value (so,
1.2.3.0/24) instead of allowed to be anything.

> Would you want me to say the high-order bits are added with a mask and the bits not covered by the mask are set to 0?

If the format can't be relied on to be canonical, then my point is
irrelevant.

> Maybe, but can you be more clear.

"{}" and "{ }" (note the space) are equivalent in JSON, but not
identical when compared byte-by-byte.

> I don’t think it is a bug. Do you?

As long as nobody relies on these to be canonical, it's not a bug.

> 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.

> I added some text to clarify this.

Thank you. The fields included in a key section were not the ones I
guessed, so the clarification was helpful. (Before your clarification, I
expected it to be everything from Rsvd3 through Key Material.)

> 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…

Should this document reference one or both of those documents?

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 26 Sep 2016 09:43:00 -0700

> 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.

> 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.

> 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

> 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

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 27 Sep 2016 09:50:16 -0700

David, any response. Thanks.

Dino

> On Sep 26, 2016, at 9:43 AM, Dino Farinacci <[email-masked]> wrote:
>

---

From: David Mandelberg <[email-masked]>
Date: Tue, 27 Sep 2016 21:01:32 -0500

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:
>>>> 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.
>>> 
>> 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.
>> 
>>>> 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?
>>> 
>>>> 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.
>>> 
>>>> 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.
>>>

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 27 Sep 2016 19:06:12 -0700

No prob David. Thanks for letting me know a rough ETA.

Dino

> On Sep 27, 2016, at 7:01 PM, David Mandelberg <[email-masked]> wrote:
> 
> Sorry, I'm busy with my dayjob. I don't think I'll have time to get to this until the weekend.
>