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

From: David Mandelberg <[email-masked]>
Date: Sat, 1 Oct 2016 13:28:06 -0400

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/

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 1 Oct 2016 11:30:53 -0700

> On Oct 1, 2016, at 10:28 AM, DavidMandelberg <[email-masked]> wrote:
> 

Okay so based in this text I finally get the point of your comment. 

But what you state is not true. These addresses are content in a message. If a message is signed and includes an address if the signer, that address is from the Io header. 

And no matter how the address is encoded, it always shows up as AFI=1 and an IPv4 address. 

Dino

---

From: David Mandelberg <[email-masked]>
Date: Sat, 1 Oct 2016 14:53:38 -0400

> And no matter how the address is encoded, it always shows up as AFI=1 and an IPv4 address. 

Gotcha, it seems I misunderstood how LCAF will be used. Sorry for the noise.

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 1 Oct 2016 12:31:48 -0700

So are we good to go?

Have a look at the last HTML diff file I sent and let me know if we are in sync. 

Per Deborah's suggestion I'll post a draft on Wed after the last call deadline. 

Dino

> On Oct 1, 2016, at 11:53 AM, David Mandelberg <[email-masked]> wrote:
>

---

From: David Mandelberg <[email-masked]>
Date: Sat, 1 Oct 2016 22:34:46 -0400

Looks good to me, thanks!

On 10/01/2016 03:31 PM, Dino Farinacci wrote:
> _______________________________________________
> secdir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
>