do not filter your customers

Nick Hilliard nick at foobar.org
Sat Feb 25 22:15:48 UTC 2012


On 25/02/2012 06:07, Shane Amante wrote:
>  OTOH, I would completely agree with
> Geoff's comment that the policy language of RPSL has the ability to
> express routing _policy_, a.k.a. "intent", recursively across multiple
> ASN's ... (please note that I'm specifically talking about the technical
> capability of the policy language of RPSL, not the actual _data_
> contained in the IRR).

routing policy concerns the interaction of two classes of object (prefixes
and asns) as handled between asns.  Problem is, while you can describe AS
interaction between ASNs and some prefix stuff between ASNs, rpsl doesn't
really have proper support to link the two - i.e. tying prefixes to
specific paths and all that jazz.  Then again, neither do most routers.  It
hardly matters - without a secure means of path validation, the path is
purely advisory and you can only barely trust the peer asn in the path.

So RPSL isn't really a solution for describing how prefixes ought to be
handled to inter-asn connectivity, and even if it were and routers could
handle as->prefix mapping properly, our routers couldn't handle it for
large-scale interconnection links due to configuration management
limitations.  Put simply, managing enormous lists of prefixes and piles of
ASN paths (in regex form) causes router RPs to asplode.   So from the point
of view of prefix distribution control, some sort of live query system is
required.

To this end, rpki with as path validation (if we actually had an
implementation which checked all the boxes in the draft list of
requirements) might work.  My point was that at the moment, it's vapour and
it's not clear at this point that it will ever change into something more
solid, particularly given the challenging feature list that we want it to
cope with, and given the constraints of what people already do with their
policy routing.

And even if it does ever work, it immediately opens up an exquisitely ugly
can of worms at layers 9 and above.  Call me conservative, but I have not
been convinced that RPKI solves more problems than it creates.

Your other concerns about as path validation implementation are indeed
difficult to address.

Nick




More information about the NANOG mailing list