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

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

Hi Alvaro,



I said in my previous post:

"(2) It also keeps confed ASes from failing to validate properly the signature injected at the boundary."




I retract my observation that the document had a problem in that

"confed ASes fail to validate properly the signature injected at the boundary."

The document does not have that problem. My apologies for not being careful earlier.

Confed ASes do validate properly the signature injected at the boundary :)

Because the document says the following in Section 4.3 (page 18):



When validating a received BGPsec update message, confederation
   members need to make the following adjustment to the algorithm
   presented in Section 5.2<https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-protocol-20#section-5.2>.  When a confederation member processes
   (validates) a Signature Segment and its corresponding Secure_Path
   Segment, the confederation member must note the following.  For a
   signature produced by a peer BGPsec speaker outside of a
   confederation, the 'Target AS Number' will always be the AS
   Confederation Identifier (the public AS number of the confederation)
   as opposed to the Member-AS Number.


So let us focus back on only your original concern.
If we need the solution of "confed AS signing to itself with  pCount = 0",
it would be only to address your original concern of an apparent discontinuity.
I looked at the implications of the solution once again.
While it may be easy to describe it in terms of sender actions,
the solution would have ripple effects in several places in the document.


So I wish to take another fresh look at your concern with your help,
and try to understand if there isn't another way to address it.


The example scenario is:
AS1 -> AS2/AS65001 -> AS65002/AS2 -> AS3 (AS2 is the Confederation ID and AS65001 and AS65002 are Members)


With the current specification, we have the following sequence of signed updates:
(Notation: (S-i-j) means signature from AS i to AS j,
P is the prefix; and most recent AS appears in the right most position)


#1  AS1 to AS2/AS65001:  P [AS1 {(S-1-2)}]


#2  AS2/AS65001 to AS2/AS65002:  P [AS1, AS65001 {(S-1-2), (S-65001-65002)}],


#3  AS2/AS65002 to AS3:  P [AS1, AS2, {(S-1-2), ( S-2-3)}]
(Secure_Path Segment and Signature within the confed are stripped)


The discontinuity you are concerned about is in the middle (2nd) update above, i.e.,
the first signature is from AS1 to AS2 while the second signature is from AS65001 to AS65002.
Am I right?


But then you have observed the following earlier:


"Well, the PE with both AS2 and AS65001 *is* both AS2 *and* AS65001...so I don't see it as a proxy."
https://www.ietf.org/mail-archive/web/sidr/current/msg08107.html


Given this observation, would you accept that there is no discontinuity in update #2 above
since AS65001 is AS2?


If this is acceptable, then can we assert that the security guarantee is Section 8.1
is good inside confederations as well with the understanding that each member AS
is also the public AS of the confed? For instance, AS65002 is cognizant that
AS65001 is also AS2. So AS65002 does not see a discontinuity.


Thank you.


Sriram