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

["Alvaro Retana (aretana)" <[e-mail]>]

On 12/21/16, 12:47 PM, "Sriram, Kotikalapudi (Fed)" <[e-mail]> 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.