so i have an AS (3130) which peers at the SIX (RSs and some direct). in the hope that leak detectors such as artemis would stop false positives when they see my prefixes announced customer cones of SIX peers, i want to add the SIX peers to my aut-num: policy. export: to AS-SEATTLEIX-RS-CLIENTS announce AS-RG-SEA seems clear and obvious. but import: from AS-SEATTLEIX-RS-CLIENTS accept AS-SEATTLEIX-RS-CLIENTS would seem to allow bill's bait and sushi to announce microsoft to me. and i am not sure that expansive `from` clause is actually allowed. what are others in this space doing? [ and let's not descend into the rat-hole of dissing the IRR. i have heard of this RPKI thing and might try it some day. ] randy --- randy@psg.com `gpg --locate-external-keys --auto-key-locate wkd randy@psg.com` signatures are back, thanks to dmarc header butchery
Randy Bush wrote on 04/10/2021 17:44:
what are others in this space doing?
not using import/export lines in their RS or router configs, for starters. Probably you could count the number of IXPs that inspect import/export lines on the fingers of one hand, and possibly of one finger. Generally speaking, IXPs try to aim for filters based on a single {as-set,IRRDB set} tuple per RS client configured. If you're aiming for bilat bgp sessions, then this functionality would need to be replicated. Nearly 30 years on, this is still the state of the art. Nick
what are others in this space doing?
not using import/export lines in their RS or router configs, for starters. Probably you could count the number of IXPs that inspect import/export lines on the fingers of one hand, and possibly of one finger.
Generally speaking, IXPs try to aim for filters based on a single {as-set,IRRDB set} tuple per RS client configured. If you're aiming for bilat bgp sessions, then this functionality would need to be replicated. Nearly 30 years on, this is still the state of the art.
i am not looking for the SIX to filter, though they do filtering. my issue is 3130 --- SIX --- martha --- RIS artemis runs off a RIS feed martha is telling RIS MARTHA_3130 and artemis is saying that martha is trying to hijack 3130's prefix. i was hoping that, if 3130 said it is peering with martha, artemis would get a clue and stfu randy
Randy Bush wrote on 04/10/2021 21:15:
i was hoping that, if 3130 said it is peering with martha, artemis would get a clue and stfu
right. This was klunked around using the export-via and import-via rpsl constructions (draft-snijders-rpsl-via), which never quite made it to ietf wg adoption status. It did, however, point out how limited RPSL grammar was :( Nick
i was hoping that, if 3130 said it is peering with martha, artemis would get a clue and stfu
right. This was klunked around using the export-via and import-via rpsl constructions (draft-snijders-rpsl-via), which never quite made it to ietf wg adoption status. It did, however, point out how limited RPSL grammar was :(
i was an early and serious fan of rpsl; see my nanog preso from '96 https://archive.psg.com/960530.nanog.ps, yes, postscript, portrait mode, probably on acetate, not comic sans, and not magenta. as i said, early. it was sabatoged, thanks sean; though to make the point that it was not at all authenticated. it has proved useful, though far from a panacea. but i fear that scaling issues, lack of authentication, etc. discouraged work and it is slowly fading. randy
Randy Bush wrote on 07/10/2021 15:26:
it was sabatoged
there was more to it than that. The grammar was too complicated to easily describe common policies and too limited to describe complex policies. The structure was difficult to extend when the routing became more complicated (e.g. mpls, route servers, ipv6, complex ibgp, etc). The tooling was too complicated for anyone to understand properly how it worked and too early to benefit from later additions, e.g. scripting language plugins. If it had been an easy problem domain to fix, it would have been fixed a long time ago, but it wasn't. Nick
On 10/7/21 16:33, Nick Hilliard wrote:
there was more to it than that. The grammar was too complicated to easily describe common policies and too limited to describe complex policies. The structure was difficult to extend when the routing became more complicated (e.g. mpls, route servers, ipv6, complex ibgp, etc). The tooling was too complicated for anyone to understand properly how it worked and too early to benefit from later additions, e.g. scripting language plugins. If it had been an easy problem domain to fix, it would have been fixed a long time ago, but it wasn't.
All the reasons I tried and gave up, back in 2003. Mark.
…like a, say, „single pane of glass”? ;) -- ./
On 5 Oct 2021, at 06:25, Mark Tinka <mark@tinka.africa> wrote:
On 10/4/21 21:55, Nick Hilliard wrote:
Nearly 30 years on, this is still the state of the art.
Not an unlike an NMS... still can't walk into a shop and just buy one that works out of the box :-).
Mark.
Some IX'es set communities telling which member announced that prefix; if SIX is one of those, that can be used to automate origin verification. Rubens On Mon, Oct 4, 2021 at 2:08 PM Randy Bush <randy@psg.com> wrote:
so i have an AS (3130) which peers at the SIX (RSs and some direct).
in the hope that leak detectors such as artemis would stop false positives when they see my prefixes announced customer cones of SIX peers, i want to add the SIX peers to my aut-num: policy.
export: to AS-SEATTLEIX-RS-CLIENTS announce AS-RG-SEA
seems clear and obvious. but
import: from AS-SEATTLEIX-RS-CLIENTS accept AS-SEATTLEIX-RS-CLIENTS
would seem to allow bill's bait and sushi to announce microsoft to me. and i am not sure that expansive `from` clause is actually allowed.
what are others in this space doing?
[ and let's not descend into the rat-hole of dissing the IRR. i have heard of this RPKI thing and might try it some day. ]
randy
--- randy@psg.com `gpg --locate-external-keys --auto-key-locate wkd randy@psg.com` signatures are back, thanks to dmarc header butchery
Hi Randy, On 10/04, Randy Bush wrote:
so i have an AS (3130) which peers at the SIX (RSs and some direct).
in the hope that leak detectors such as artemis would stop false positives when they see my prefixes announced customer cones of SIX peers, i want to add the SIX peers to my aut-num: policy.
I would be astonished if artemis was parsing your import/export expressions, but as an academic exercise...
export: to AS-SEATTLEIX-RS-CLIENTS announce AS-RG-SEA
seems clear and obvious. but
import: from AS-SEATTLEIX-RS-CLIENTS accept AS-SEATTLEIX-RS-CLIENTS
would seem to allow bill's bait and sushi to announce microsoft to me. and i am not sure that expansive `from` clause is actually allowed.
The having an as-set in the peering-expr part is fine, but that particular set appears to contain all of the peers' customer cones, which is not what you want there. Additionally it evaluates down to "any route originated by any customer of any peer, from any customer of any (other) peer". That's not a good filter, as you pointed out ;-) In order to express what you want, the SIX needs to create: - an as-set containing the ASNs of the RS peers (not their customers), e.g. AS33108:AS-PEERS; and - for each peer, a set containing that peer's customer cone, each with name that contains the peer's ASN, e.g. AS33108:AS-PEERS:AS65000. Then you can say something like: import: from AS33108:AS-PEERS accept AS33108:AS-PEERS:PeerAS The fact that the IX operator needs to maintain these sets is a symptom of the same issue that makes it near impossible to construct sane filters for route-server sessions: you have no idea when someone joins, or what they *should* be announcing. One of the many reasons you don't see us on route-servers.
what are others in this space doing?
Mostly, asking people fill-in peeringdb records, and ignoring import/export attributes entirely. However we use roughly the above scheme, just in case someone is reading. Cheers, Ben
participants (6)
-
Ben Maddison -
Mark Tinka -
Nick Hilliard -
Randy Bush -
Rubens Kuhl -
Łukasz Bromirski