At the risk of opening a can of worms (or at least seeing a cylindrical hollow metal labeled "Caution: contains worms")...
I believe the larger issue is, that Authentication is orthogonal to Authorization. As it currently stands, only Authentication has been given any consideration, per se. The two things being Authenticated are: o Origination (prefix + ASN, and maybe other identifying elements such as IP addresses of routers), and o ASNs in the AS_PATH. What is not explicitly being discussed, is, the question of "What is $foo Authorized to do?". E.g. The implicit assumption is, Only ASN==X is allowed to originate prefixes whose AS_PATH "starts" (ends) with X. And, the other implicit assumption is, the only thing any ASN is permitted to do, is to prepend its own ASN to the AS_PATH, (zero or) one or more times. However, it may be worth considering all the other things that are done by ASNs currently: o Private ASNs being stripped (private leaf ASNs) o Confederations o Route Servers o ECMP and friends o other vendor-specific or multi-vendor stuff being done to the AS-Path (replace-as, as-sets, etc.) Rather than dogmatically ignoring these issues, or declare them "out of scope!!!", I would prefer to see a rational discussion on whether there is a suitable place in the system, to facilitate some way of handling these cases, in a way that does not weaken the security model. Basically, rather than just say, "Okay, if you want to do this, turn off BGPSEC", I think there is value in saying, "To do this, you need to add $X to $Y to authorize this activity", so that RPs are able to reconcile what they receive, with what the RPKI-encoded data says they should expect. For example: Say that ASs A, B, and C, exchange routes via a route-server AS S. Each of A, B, and C encode something that says, roughly: "I am okay with NLRIs I send to S, have S omitted from the AS_PATH", and, "I am okay with S sending me NLRIs that have S omitted, so long as the immediate AS after S, also allows S to omit itself". So, a signature block "R B S C Q" can be reconciled with an AS_PATH of "R B C Q", by seeing the S sig, and the rules for C->S and S->B allow this, established respectively by all of C, S, and B. The difference between this, and the whole "pCount==0" thing, is that the above is an explicit policy encoded in the RPKI, which can be validated more than one hop away from S. The "pCount==0" logic is only truly verifiable by the immediate recipient, and then only by the operator's personal implementation for enforcing local policy (which itself be weak or faulty). A recipient of an BGPSEC_Signatures_Block which has any pCount==0 in the middle, currently has no way of ascertaining the legitimacy of that occurrence. The Signature Block (AS/N) of "R/1 B/1 S/0 C/1 Q/1" is consistent with an AS_PATH of "R B C Q", but there is no way to know if this is in fact sensible. For other examples: Private ASNs are, by definition, not unique. However, it would still be nice to be able to identify their owners, e.g. by IP address, and validate ASN substitutions by RPKI, based on Origination/Signature data. Proxy Origination would also be nice to have Authorization of Delegation (to sign), possibly chained. E.g. A delegates signature_origination to B, who delegates signature_origination to C. Prefixes assigned to A, could be signed by C, but would validate only if the signed AS_PATH was "C B A". I'm sure there are plenty of other use cases, which match up with actual operator practices today. If the mechanics of this can be done in a scalable and secure manner, this will greatly enhance deployment likelihood, and ease deployment itself. (This is where the IETF in general, can redeem itself for its past sins. Don't ignore real needs, regardless of how tempting it is to keep designs "pure".) IMHO. Brian P.S. This kind of complex stuff really begs face-to-face meeting time. It is hard to convey intent via messages. Oh, the irony... On Thu, Apr 12, 2012 at 11:59 PM, Jakob Heitz <jakob.he...@ericsson.com>wrote: > On Wednesday, April 11, 2012 7:21 AM, Jeffrey Haas <> wrote: > > > In the case where the paths are not congruent (which shouldn't happen > > unlike the AS4_PATH case in RFC 4893 - we don't tunnel bgpsec across > > other BGP), we probably have some sort of hard error case. One > > reasonable assumption is > > that a non-BGPSEC speaker mucked with the AS_PATH - perhaps an iBGP > > speaker doing path manipulations for policy. IMO, the proper > > behavior here is to *not* propagate the route at a BGPSEC ASBR > > boundary; any BGP speaker that manipulates the AS_PATH in such a way > > as to break the congruency of ASes between AS_PATH and signature MUST > > be a BGPSEC speaker. > > > > The above still doesn't deal with common deployment considerations > > such as as-override, replace-as and remove-private. > > This just highlights the semantic difference between the BGPSEC > path and the AS_PATH. > > They may be different legitimately. This is why we need both. > > A receiver can make its own decision whether the difference > between the paths should cause path invalidation or not. > If a sender is legitimately manipulating an AS_PATH, then the > receiver should know about it and use this knowledge to help > in the decision. > > -- > Jakob Heitz. > _______________________________________________ > Idr mailing list > i...@ietf.org > https://www.ietf.org/mailman/listinfo/idr >
_______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
