AT&T/as7018 now drops invalid prefixes from peers

Tue Feb 12 00:52:46 UTC 2019

Job Snijders writes:
 > Dear Jay, AT&T,
 > 
 > On Mon, Feb 11, 2019 at 09:53:45AM -0500, Jay Borkenhagen wrote:
 > > The AT&T/as7018 network is now dropping all RPKI-invalid route
 > > announcements that we receive from our peers.
 > 
 > Thanks for filtering us! :-)

Any time! :-)

 > If you can share more about the experience in terms of load on the
 > support tiers in your organisation, or questions from peering partners,
 > that could perhaps be helpful information for others in their
 > preparations.
 > 

A few reports of resulting connectivity loss have come in through
various channels: on Jared's outages mailing list, on IRC, through our
customer care ticket system, etc.  

Thusfar I have been very pleased with the reactions folks have had
when we described how our policy change caused us to lose their
affected route announcement.  Everyone so far has understood the
purpose of the RPKI, they understood why the affected route
announcements were deemed invalid and thus were dropped, and best of
all -- they understood what they needed to do to fix things.

We got some very good advice watching this video from your most recent
NLNOG day:

 https://www.youtube.com/watch?v=vrzl__yGqLE

... but there is one place where I disagree with Niels.  He advised
against lowering the local-pref of invalid routes.  I agree that this
should not be anyone's target policy, but it is a useful step along
the way.  To set invalid routes a lower local-pref, one needs to
establish RTR sessions from routers to relying party servers, and to
configure a policy that takes validation state into account.  The
policy here can also set community based on the validation state,
which can help with flow-based traffic analysis.  Then, when you are
comfortable operating RPs that talk RTR to your routers and you're
ready to implement a meaningful policy, it's a simple matter of
changing from:

 if validation-state = invalid
 then
   local-pref = $LOWER
   community = foo
 fi

 to:

 if validation-state = invalid
 then
   drop
 fi

In short: C'mon in!  The water's fine! :-)

Thanks.

						Jay B.