Hannigan, Martin wrote:
Yes, but last time you said you were going to use _other peoples_ ASN's to test with and allow these
announcements beyond your borders.
Is this still the case?
The probing AS (call it Z) announces one of its prefixes to the Internet with an AS-path that is not just Z but Z {a,b,c...}, where a,b,c,... are the numbers of other ASes in the Internet.
For the technique to be useful, the numbers in the set must belong to ASes that actually receive Z's announcements. These ASes will not use or propagate the route, effectively "disappearing" from the Internet as far as the prefix is concerned. This causes alternate and backup paths, not normally visible, to become active for that prefix.
By looking at RIS and RV and the looking glasses of other ASes, Z can then see who propagates the prefix, where its announcements go, if other ASes have particular preferences for particular paths to it, and so on.
Apart from the different AS-path, the prefix is announced in the same way as all the other prefixes belonging to Z.
So yes, the ASes inserted in the AS-set are operated by others, and yes, the announcements are sent out to the Internet at large.
Regards,
Lorenzo
* Lorenzo Colitti:
So yes, the ASes inserted in the AS-set are operated by others, and yes,
the announcements are sent out to the Internet at large.
This approach is highly questionable. Any responsible ISP should kick
you off the net for announcing AS path containing ASNs without
permission from the real owner/assignee.
And it also makes clear why it didn't pop up in GRH, as when you insert
the GRH ASN 8298 it won't be announced to GRH and thus it doesn't get
detected and as quite a number of people check only there it can go
quite unnoticed in the IPv6 tables...*
Sidetracking: BGP should never accept a path from another peer
containing the ASN of a directly connected peer... does it or not?
Greets,
Jeroen
* = every path above 12, aspath sets get decompressed, get listed as a
possible ghost so it would pop up.
Jeroen Massar wrote:
And it also makes clear why it didn't pop up in GRH, as when you insert
the GRH ASN 8298 it won't be announced to GRH and thus it doesn't get
detected and as quite a number of people check only there it can go
quite unnoticed in the IPv6 tables...*
Actually, we never inserted AS8298 in any of the AS-sets we announced, so you should have seen them...
Sidetracking: BGP should never accept a path from another peer
containing the ASN of a directly connected peer... does it or not?
Hmm, I don't know. It wouldn't likely be selected as best path, of course, but why shouldn't it be accepted?
Regards,
Lorenzo
People have been prepending non-local ASNs onto covered routes as a crude inter-domain TE hammer for years. The sky has not fallen.
Joe