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

["Sriram, Kotikalapudi (Fed)" <[e-mail]>]

>Hi!  I think the only item left is the Confederations one…and we might be speaking past each other.



Thanks, Alvaro. My comments are marked with [Sriram-3].



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



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?



[Sriram-3] Please see inline below for the rest of my comments (all marked with [Sriram-3]).





>Yes, I agree that the collusion problem is one that (as you mentioned below) is out of the scope of BGPsec.  You are right that pCount=0 (as proposed below) doesn’t solve the collusion problem – but it does address the following security guarantee that is currently not met in the Confederations case (from 8.1):



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



>In the case of Confederations, it cannot be (currently) verified that all the ASNs in the path intentionally chose to send the update to the next ASN because there is a discontinuity at the border.  For a topology like this: AS1 -> AS2/AS65001 -> AS65002/AS2 -> AS3 (AS2 is the Confederation ID and AS65001 and AS65002 are Members), it can be verified that AS1 intentionally sent the Update to AS2, but there is no explicit indication (even if symbolic: pCount=0) of the intention for AS65001 to “receive” the update, and then be able to send it to AS65002.



>I still think that this continuity issue should be addressed; it nothing more just because the intentionality is mentioned as a security guarantee of BGPsec.



[Sriram-3] Please see solution choices and A and B above and the related discussion.



Chairs: Please poll the WG or make a decision of whether there is consensus (or not) to not solve this continuity issue (maybe from prior discussions on the list).  If the WG decides not to solve this issue (or if it was already discussed), I’m ok with being in the rough.



Related to the above, is the support for private ASNs --- this topic also came up in the review of draft-ietf-sidr-bgpsec-ops, and the GenArt/SecDir reviews.  There are two related points:



1. It is common to use private ASNs in Confederations, but the global RPKI can’t support that.  draft-ietf-sidr-slurm seems to address the issue of local management of private resources in the RPKI.  Given that the signing of Updates is mandated, I think that support of draft-ietf-sidr-slurm is necessary; IOW, I think that draft-ietf-sidr-slurm should be a Normative reference.



[Sriram-3]  OK, will include draft-ietf-sidr-slurm as a normative reference.



2. Private ASNs (as pointed out in the SecDir review) are commonly used for stubs.  This document should include something (I’m thinking in the Ops Section) about the protocol considerations: there must be a ROA from the resource owner for the ISP to properly re-originate the Update, etc..



[Sriram-3]  Agree. I’ll factor in your inputs and those from Joel, Russ, and Randy to include a paragraph on this topic in the ops and mgmt. section.



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



Thank you.



Sriram