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

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Fri, 9 Dec 2016 22:00:28 +0000

[Changed the Subject to specifically discuss Confederation support, and hopefully get some attention from the WG.]

Sriram:

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

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.

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.

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

Thanks!

Alvaro.

On 12/5/16, 1:35 PM, "Sriram, Kotikalapudi (Fed)" <[email-masked]<mailto:[email-masked]>> wrote:

Personally, I would have preferred if you actually solved the problem. One solution is to borrow from draft-ietf-sidr-as-migration and forward sign from the Confederation AS (the public number) to the Member-AS with pCount=0.  Note that this operation would take place inside the border Confederation router, so there are no issues with pCount=0 and the full path continuity is preserved.[*] Chairs: I think that this part (whether it is solved or not) should also be bounced by the WG.…

[Sriram-2] Please see discussion at the top of this email. I am afraid, the solution you propose will not work. The first AS in the Confederation can still tunnel the update to the second AS it is colluding with, and the second AS “forward signs from the Confederation AS (the public number) to the Member-AS with pCount=0”. So the problem you originally identified doesn’t go away.

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Tue, 13 Dec 2016 12:26:05 +0000

>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

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

      in the path.

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

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

[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

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Thu, 15 Dec 2016 16:09:21 +0000

On 12/13/16, 7:26 AM, "Sriram, Kotikalapudi (Fed)" <[email-masked]> 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):

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

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

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

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Tue, 20 Dec 2016 22:56:09 +0000

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

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Tue, 20 Dec 2016 23:37:27 +0000

Hi!

I am (obviously) fine with it.

Thanks!

Alvaro.

Thumb-typed and autocorrected..

> On Dec 20, 2016, at 5:56 PM, Sriram, Kotikalapudi (Fed) <[email-masked]> wrote:
>

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Wed, 21 Dec 2016 17:47:03 +0000

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:

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

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Wed, 21 Dec 2016 19:28:27 +0000

On 12/21/16, 12:47 PM, "Sriram, Kotikalapudi (Fed)" <[email-masked]> wrote:

Sriram:

Hi!

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

…

|

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

Yes.

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

No, it is not ok to me.

Even though in theory all the routers in a confederation know the confederation ID, in practice the only reason that it is needed is if an external (to the confederation) peering session exists in that member AS.  In other words, it is possible to configure a router to be an “internal” member (i.e. not having any external-to-the-confederation peers) by only indicating the confederation peers and not the confederation ID.

For example, extending the network above:

AS1 -> AS2/AS65001 -> AS65003 -> AS65004 -> AS65002/AS2 -> AS3

(AS2 is the Confederation ID and AS65001, AS65002 AS65003, AS65004 are Members)

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.  In fact, if AS65003 was configured with the wrong confederation ID (AS4, for example), everything would still work with no issues, because the confederation ID wouldn’t be used in the existing peering sessions.

IOW, AS65003 doesn’t necessarily always know that AS65001 is also AS2.  It may not know the confederation ID at all, or it may even think that AS65001 is also some other AS.

Yes, I have to admit that we could argue whether either case/or both (of not knowing the proper confederation ID) is a misconfiguration…but the fact persists that there is no explicit indication that AS2 intended to send the Update to AS65001 (even if they are, or should be, the same box).

This is where I think we’re again at a place where we’re probably agreeing to disagree – and where more input from the WG would be great.   I am happy to be in the rough if the WG agrees with you.

Thanks!

Alvaro.

---

From: Randy Bush <[email-masked]>
Date: Thu, 22 Dec 2016 09:52:58 +0900

> IOW, AS65003 doesn’t necessarily always know that AS65001 is also AS2.
> It may not know the confederation ID at all, or it may even think that
> AS65001 is also some other AS.

and this is within spec.  we have no measure of how common this is, and
it would be hard to measure due to the problem of vantage points.  such
is life with bgp.

randy

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Thu, 29 Dec 2016 17:14:56 +0000

Hi Alvaro,

Please see my comments inline below.

>From: Alvaro Retana (aretana) [mailto:[email-masked]] 
>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

---

From: Randy Bush <[email-masked]>
Date: Fri, 30 Dec 2016 08:02:20 +0900

> This document should include something (I’m thinking in the Ops
> Section) about the protocol considerations: there must be a ROA from

that is not the core of the problem.  the bgpsec protocol doc has to
specifically say that the public AS upon receiving the update from the
private AS
  o if the private signed to the public, public should check sig, then
    strip it and then might sign as the originating AS or might not.  on
    what criteria does it decide?
  o if the private did not sign, the public might sign or it might not.
    on what criteria does it decide?

as i said, once you burn that in, i will hack the ops doc

randy

---

From: Randy Bush <[email-masked]>
Date: Fri, 30 Dec 2016 08:23:39 +0900

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

the issue is not how the confed AS validates ROAs of the private ASs in
the confed.  that is trivial and supported by existing software.  my
questions revolve around path processing.

4.3 confuses me by using 'private' ambiguously.  i have tried to read
that section yet again and drowned in the mass of words.  perhaps more
coffee will help; but i am not optimistic.  i pity the implementors.

randy