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

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

Hi Alvaro,

Please see my comments inline below.

>From: Alvaro Retana (aretana) [mailto:[e-mail]] 
>Sent: Friday, December 09, 2016 5:00 PM
….

>Hi!  I think the only item left is the Confederations one…
….

>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):
….

In the latest version-21 of the draft that I uploaded last Friday, 
I have incorporated the solution that you have proposed, 
namely, adding a signature with pCount = 0, 
at the border of the confederation (see 2nd, 3rd, and 4th paragraphs 
added newly in Section 4.3, page 18).

As I see it, this solution offers the following three benefits:

1. It eliminates the discontinuity issue at the confederation boundary and 
hence facilitates maintaining the security guarantee within confederations as well.

2. It allows for tolerance to lack of proper configuration in a BGPsec speaker
in an interior AS in a confederation, i.e. when such a BGPsec speaker
is not configured to know its confederation’s public AS number.

So it addresses the following comment you made earlier:
“In this network AS65003 (for example) only needs to know (i.e. be configured) 
that AS65001 and AS65004 as confederation peers, 
and not the specific knowledge of which is the confederation ID.”
https://www.ietf.org/mail-archive/web/sidr/current/msg08126.html 

(Randy’s post also seemed to hint that this tolerance would be useful:
https://www.ietf.org/mail-archive/web/sidr/current/msg08127.html )

3. A common description of the validation algorithm (Section 5.2) applies to
all BGPsec speakers. That is, no exceptions need to be stated for 
BGPsec  speakers inside a confederation.
(Previously we had described such exceptions in Section 4.3,
but now they are not needed any more and hence deleted.)

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

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

There are two new paragraphs in the ops and mgmt. section (Section 7, page 30)
that discuss proper handling of private ASNs that may be used for stub ASes 
or inside confederations.

Please let me know if I missed anything or if you would like to suggest 
any wording improvements.

Thank you.

Sriram