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

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

Thinking about it some more, I now find that your proposed solution of adding a signature with pCount = 0 at the border of the confederation works well and fully addresses these two concerns (the second concern is new).

(1) Your proposed solution addresses the concern you brought up in an earlier message -

https://www.ietf.org/mail-archive/web/sidr/current/msg08081.html

(2) It also keeps confed ASes from failing to validate properly the signature injected at the boundary.  This is explained below.

First let us take note of the following two instructions that are in the spec:

(a)  From page Section 4.3 (page 16):

"When a confederation

   member sends a BGPsec update message to a peer that is a member of

   the same confederation but is a different Member-AS, the

   confederation member puts its (private) Member-AS Number (as opposed

   to the public AS Confederation Identifier) in the AS Number field of

   the Secure_Path Segment that it adds to the BGPsec update message."

(b)  From Section 5.2 (page 25):  (note: this one is part of the method of identifying the Target AS while assembling the data to be hashed for signature validation)

"For each other Signature Segment (N smaller than K), the 'Target

      AS Number' is AS(N+1), the AS number in the Secure_Path segment

      that corresponds to the Signature Segment added immediately after

      the one being processed."

Now I will explain what I mean by (2) above using the same example that you presented earlier:

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

In this example, by "signature injected at the boundary", we mean the signature of AS1 to AS2 (in the update received by AS65001). Let us think about the step where AS65002 is processing the update from AS65001 and validating the "signature injected at the boundary". Following step (a) above, AS65001 put in its own private AS number (i.e. AS65001) in the Secure_Path Segment that it added to the BGPsec update message forwarded to AS65002. Therefore, following step (b), AS65002 identifies AS65001 to be the 'Target AS Number' for the data to be hashed for validating the signature. However, this would falsely result in 'Invalid' outcome for the signature being validated by AS65002. Because AS1 actually signed to AS2 (the public AS number), and hence the 'Target AS Number' is actually AS2.

Now the solution: Your suggested solution says that AS65001 should add a signature where it uses the private key of the public AS (i.e. AS2) to sign and forward the update to itself (AS65001) with pCount = 0. Correspondingly, AS65001 also puts in the public AS number (i.e. AS2) in the Secure_Path Segment that it adds to the BGPsec update message sent to itself. (Please correct me if I misunderstood.) This helps to fully address the problem identified above. (Note that AS65001 follows instruction (a) when it subsequently forwards the update to AS65002, and AS65002 follows instruction (b) while validating. The validation now works without the error identified above.)

If we agree and others on the WG list express no objection or find no fault in this solution, I will be happy to go ahead and add this solution for the confederation case (it requires just a couple of sentences to be added the spec).

Thank you.

Sriram