DMARC ViolationAS21299 - 46.42.196.0/24 ASN prepending 255 times

Fri Apr 1 17:42:13 UTC 2022

> -----Original Message-----
> From: NANOG <nanog-bounces+athompson=merlin.mb.ca at nanog.org> On
> Behalf Of Joe Maimon
> Sent: Thursday, March 31, 2022 6:20 PM
> Subject: Re: DMARC ViolationAS21299 - 46.42.196.0/24 ASN prepending 255
> times
>
> [...]
> I think more and perhaps different knobs were and still are needed.

YES.  YESYESYES.

Having said that, I am currently able to express my local traffic policies (roughly 1/3 due to one particular upstream hamstrung by their parent company, 1/3 due to NREN, 1/3 due to local IXP) using prepends of no more than +2 (both outbound and inbound, which I gather might be somewhat unusual).  That includes dealing with a "special" issue because both my local NREN RAN and I are both connected to the local IXP, and to a mutual downstream, which produces an interesting double-triangle topology, and this topology produces surprising emergent behaviours that I haven't seen described anywhere.

Prior to some reorganization (and several compromises) I needed +5 on both inbound and outbound (usually not at the same time) to adequately steer normal traffic.

Prepending is, IMHO literally, the abuse of a mechanism not initially designed to express complex policies.  It's a 1-dimensional tool in a space that really needs a 2- or 3-dimensional tool.

LOCAL_PREF is not useful for me and my upstreams, downstreams and peers: I have not yet found a scenario where it fixes any of my problems without creating even greater ones.  My traffic-steering issues ~all exist n>3 hops away, not directly with my BGP peers.

So prepending remains the only useful, usable knob I have.  And it's not a great knob for this, which I think might be the one thing everyone here can agree on!

> through nowadays, how about a long call back to each AS in the path

I'm not really loving that solution more than prepends, but at least it's something different?

> Would be nice to be able to publish your community scheme as simply
> conforming with RFCX and the to configure peers with process-rfcX
> statement and be mostly done.

That's a LONG way off!  Not that any other solution isn't equally far off, so... <shrug>  Gotta start somewhere, I guess!

I don't have any better suggestions, other than I wish the LOCAL_PREF crowd could understand that it doesn't solve all the world's problems.  (Neither of my commercial upstreams currently admit to supporting communities that control it, anyway!)

Frustrated at the state of the world today,
-Adam

Adam Thompson
Consultant, Infrastructure Services
MERLIN
100 - 135 Innovation Drive
Winnipeg, MB, R3T 6A8
(204) 977-6824 or 1-800-430-6404 (MB only)
athompson at merlin.mb.ca
www.merlin.mb.ca