DMARC ViolationAS21299 - 46.42.196.0/24 ASN prepending 255 times

Thu Mar 31 23:20:06 UTC 2022

Matthew Petach wrote:
>
>
>
> Unfortunately, the reason crazy-long prepends actually propagate so
> widely in the internet core is because most of those decisions to prefer
> your peer's customers are done using a relatively big and heavy hammer.

IOW if your peer or customer has prepended 5 times or more, dont 
LOCAL_PREF or maybe even de-LOCAL_PREF it

<very good advice snipped>
>
> For the most part--if you think LOCAL_PREF is the right knob to use 
> for moving
> traffic, it probably means you need to go back and rethink your 
> traffic engineering
> approach.   ^_^;
>
> Matt

I think more and perhaps different knobs were and still are needed.

Here is an idea, as part of the all extra processing updates have to go 
through nowadays, how about a long call back to each AS in the path 
using some sort of standardized service, perhaps published via DNS, sort 
of an automated looking glass results compared to update-out. And then 
the receiver, however many AS's away starts to get a much clearer 
picture of the intent all the through and maybe perhaps some much better 
intelligent automated properly reactive internet wide traffic 
engineering standards will emerge.

Until then I think a slew of standardized communities that elicit near 
universal and predictable standard reactions is probably the best bet. 
The problem is that shifting too much control to the advertiser makes it 
a non-starter from the point of view of the receiver, and then you can 
forget about deployment.

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.

Joe