On 12/21/16, 12:47 PM, "Sriram, Kotikalapudi (Fed)"
<[email protected]> 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.
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
