On Fri, Feb 18, 2011 at 2:21 PM, Russ White <r...@cisco.com> wrote: > >> what matters: AS-PATH >> how it looks: every AS which sees this route, and propogates it to >> external peers, attests to that fact. > > Wrong. As someone who has been long involved in the writing of BGP > specs, and someone who has worked, for a long time, on BGP, I can tell > you that the "semantic of BGP" has never been that the AS Path is used > for anything other than determining if the path is loop free. Anyone who
i wasn't claiming anything about bgp semantics, that was sandy. I didn't disagree with her, but it wasn't central to my message. You clipped out the part of the message I replied to, which was only related to your response: " If you're going to say, "secure the semantics," then secure all of them. If you're going to say, "secure the data," then figure out what matters in terms of how the data looks, and secure that." > tells you that the "BGP semantic" is that the update has traversed the > path shown in the AS Path attribute simply doesn't understand BGP. > > A few examples showing this simply isn't the case. > > 1. Private AS Stripping. At certain edges, a provider may peer with an > organization that does not have an AS number. In these cases, the > peering organization may use a private AS Number, which is then stripped > by the upstream. In all such cases, the AS Path does not --by > intention-- represent the "path of the update." for origin validation (not this conversation, but...) the ISP here would have a ROA issued by the address-owner... so this isn't a problem. The as-path is still a clear indicator here, since the customer is a leaf... the fact that their ASN doesnt show up isn't a problem, especially since the roa/origin-validation would nicely tell us that the ASN we do so as the first (right-most) element is "ok". > 2. Local AS No Prepend. In some situations, it's useful (and good) to > send an update that has another AS in the path than the AS number you're > peering on. This occurs, for instance, in L3VPNs, and when providers are > merging two different AS numbers. If this were a real "threat" to BGP > and it's operation, then this feature wouldn't have been built by any > vendors --but it was created, at the request of service providers (some > of whom are now arguing that the AS Path is somehow untouchable). again, not a problem, presumably the AS stamped in the path is signed by the ASN Owner, whether they say: "X" but are really "Y" isn't a concern, they still have (in a possible endtime) cert issued down a tree we can validate. They are still attesting to the fact that they saw and passed along the route announcement in question. (see the second half of the sentence you are responding to here) (for all intents and purposes this looks like your next point, confeds) > > 3. Confederations. In the case where an organization decides to break > their network up into multiple administrative domains, or to combine > multiple administrative domains, several autonomous systems --with > public, routable AS numbers-- may be configured into a confederation. In (it's not required that the asn's in a confed be "public routable", routable doesn't mean anything either here, ASNs... this is a redherring though) > this case, the AS Path continues to have the AS numbers through which > the update passes added to the attribute. The "additional" AS numbers > are stripped off at the opposite edge of the confederation. Once again, > the AS Path is not anything special here, it's just another attribute, > and it certainly does not represent the path the update takes through > the network. sure, and again, on exit the autonomous system (with the distinct routing policy and administrative domain) stamps it saying: "Yup, was here." they attest to this (again in my endtime of choice) in a manner I can validate. (see the second half of the sentence you are responding to here) > 4. Wide AS'. According to RFC4893, the way in which BGP will migrate > from narrow AS numbers to wide AS numbers is: For any speaker that peers > with a speaker in an AS that doesn't support wide numbers, place the AS > path in a community, and place a "holder" AS number in the AS Path. When > receiving an update with a community containing portions of the AS Path, > move these portions back into the AS Path proper. Again, the AS Path is > not seen as something that "cannot be touched or changed," but rather a > simple attribute designed to show one specific thing --loop freeness. > There is no concept here of the AS Path showing the route the update > itself, took. yup, this issue we have talked about some, I don't recall the details, someone should think about this more... but again: "I saw this route, I am passing it along" is really what matters. (see the second half of the sentence you are responding to here) > 5. AS Sets. If a speaker aggregates a group of NLRIs into a single > advertisement, the speaker can/should build an AS Set to indicate the > group of AS' from which the NLRIs represented in the aggregate were > collected. Again, the AS Path doesn't have anything to do with "the path > the update took through the network." and because AS-Sets are opaque when it comes to security semantics (which asn in the set is responsible for what part of the aggregate?) they are excluded from the discussion, and on the road to deprecation. > I could go on giving examples, but to state, "BGP's semantic is that the > AS Path represents the path through which the update has traveled," is > simply untrue. eh... but it is. one more time around the mulberry bush? -chris > :-) > > Russ > > _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
