Re: [sidr] Confederations and Private ASNs (WAS: AD Review of draft-ietf-sidr-bgpsec-protocol-18)

["Alvaro Retana (aretana)" <[e-mail]>]

On 12/13/16, 7:26 AM, "Sriram, Kotikalapudi (Fed)" <[e-mail]> wrote:



> [Sriram-3] I understand now your main comment about confederation. I think there are

> two ways to address it (of course I hope other people chime in as well):

>

> Choice A: The pCount = 0 solution that you have suggested.

>

> But I feel that this is somewhat a cosmetic solution. In your example, it can be perhaps

> questioned whether the signature with pCount = 0 from AS2 to AS65001 does actually fit

> the security guarantee from Section 8.1 that you’ve cited.  Because AS2 (the AS with the

> public ASN) did not produce that signature directly. Instead AS65001 played proxy for

> AS2 -- which is of course part of the original solution anyway. So we may consider choice

> B below.



Well, the PE with both AS2 and AS65001 *is* both AS2 *and* AS65001…so I don’t see it as a proxy.



> Choice B: Include a caveat to the statement in Section 8.1. For instance, we modify it as

> follows:

>

> For each AS in the path, a BGPsec speaker authorized by the holder

>      of the AS number intentionally chose (in accordance with local

>      policy) to propagate the route advertisement to the subsequent AS

>      in the path (except for a minor caveat that applies in the case of BGPsec speakers

>       in a  confederation). The caveat applies because a BGPsec speaker

>       in a confederation-member AS can be a proxy receiver and signer for the public AS

>       (identified by the public AS number of the confederation). Therefore, a signature that > appears to

>      correspond to an AS with the public AS number may actually

>      be proxy produced by a member AS that has an internal AS number

>      not matching the public AS number. The confederation-member ASes

>      are cognizant of this and hence it poses no security concern

>      within the confederation, and it is transparent to ASes outside

>      the confederation (see Section 4.3).

>

> [Sriram-3] Do you feel Choice B makes sense?



Personally, I don’t like Choice B because it reads: “we guarantee X, except in a scenario where the signatures are not what they seem”…   It doesn’t give me a warm a fuzzy feeling, especially when we’re talking about a security-related document.



This is where I would like the Chairs/rest of the WG to pitch in.



…

> [Sriram-3]  Perhaps I should wait for some more IESG LC reviews to roll in before I include

> this set of changes and those from Russ (Gen-ART) and Nevil (OPS-DIR)? Please advise.



The IETF LC ends tomorrow.  Include the changes with anything you receive by tomorrow.



Thanks!



Alvaro.