IRR for IX peers

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

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

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

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

Hi Randy,

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 :wink:

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

hi ben,

a SIX peer's customer could be the feed to RIS

randy

Hi Randy,

a SIX peer's customer could be the feed to RIS

Sure, but how do you describe the policy between your peer and their
customer in your aut-num?! That's not a thing.

yup

these rat holes are a pita

randy

Not an unlike an NMS... still can't walk into a shop and just buy one that works out of the box :-).

Mark.

…like a, say, „single pane of glass”? :wink:

Oh dear Lord :-)...

Mark.

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 :frowning:

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 :frowning:

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

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

All the reasons I tried and gave up, back in 2003.

Mark.