North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Using RPSL in real life with the IRR's

  • From: Jeff Haas
  • Date: Mon Jun 26 13:51:01 2000

On Mon, Jun 26, 2000 at 12:36:06AM -0700, Julian Eccli wrote:
> To help me understand and also ensure I am correct with my
> interpretation of RPSL I queried the database and
> started to examine many of the large carriers objects.  What I noticed
> is not a single one I have run across does more than implement a very
> basic import and export policy.

The fact that the policies are "basic" is not actually a bad
thing.  For simplistic prefix filtering the representative policies
are fine.  More complex policies get heinously messy to represent
for large tier-1 carriers if they try to put their metrics in
the aut-num objects, especially if they are not using RtConfig
to generate the actual policy.

This doesn't mean that one can't use the simplistic policies for
filtering.  If you examine the peval tool from the RAToolset, you'll
find that this is useful to generating the prefix lists.  Further
application of internal tools on the output from this tool work quite
nicely and do you the service of not exposing internal policy to the
whole Internet - a requirement that many larger providers have.

So, if you don't see anything complicated, don't despair - its
a valid way of applying the policy.  I'm often ecstatic if the
larger providers represent their externally viewable AS adjacencies
in their aut-num objects, even if their "action pref" statements
are content free.

> Considering the posibilities of abuse
> and mistakes I would assume the larger/medium carriers would have
> someone dedicated full time to ensure the flood gates aren't open to
> their networks and their clients.

There are certain tier-1 providers that still mostly manage their
prefix filters manually.  The ISP I was formerly employed at
dreaded calling one of these providers to adjust our filtering
to announce a new prefix because more often than not they'd break
our peering session - and often other providers off the main Detroit

How about some live examples of filtering policies in the real world
from an existing route server peer:

Lets pick on one provider to give an example - RCN (AS6079) who
peers with the route servers at Mae-west.  Their policy exhibits
all the characteristics that bother you about the "simplistic"
policies you're worried about.  We see something simple in their
policy like:

aut-num:       AS6079
import:        from AS5696
               action pref=1;
               accept ANY AND NOT {}

This tells us that 6079 has an adjacency with 5696 and that they
want to accept ANY routes.  This could tell us one of three things
(and I'm not making any suppositions or value judgements here):

1. RCN supposedly trusts Goodnet to Do The Right Thing.
2. RCN doesn't trust Goodnet to have their routes registered and
   thus doesn't want to exclude any valid routes.  This does mean
   they'll also get the invalid ones. 
3. Given that goodnet is also a transit provider and RCN may be using
   goodnet transit routes (use the BGP luke...), RCN can't simply
   use a simplistic filter.  This is because they don't only want
   routes originated by goodnet, but also the transit routes.

Scenario 3 is where IRR filtering becomes very problematic.  The
first problem is where insufficient information is registered to
construct good filters.  The second problem is representing the full
range of the routes you wish to receive the full mesh of the Internet
from a given provider, especially as you near the "core".

Depending on how your tool expands "ANY", you could simply get 
a promiscuous route filter (permit all) or you could get all
routes registered in the IRR (messy!).

For transit level connectivity IRR filtering can be outright dangerous
at the moment.  Declare your policy but filter at the edges first.

To pick on something a little less promiscuous:

aut-num:       AS6079
import:        from AS3967
               action pref=1;
               accept AS-EXODUS AND NOT {}

This policy is far less promiscuous.  It includes (from inspection)
routes that are likely to be originated as customers and some route-sets
where they trust others to tell them which AS's are theirs.  In this
instance, the IRR works well, even at an exchange point, so long
as both parties register their routes.

> My real question is:  Can anyone point me to a policy(s) that use
> more than the general import/export policies such as import: from
> AS#### action pref=100; accept AS#### (or usually ANY) AND NOT
> {}, etc, etc, etc.

Gerald Winters already pointed out a few.

I'll note that you can examine the PAIR output from the Route Servers
( for an example on how preferences
in one's aut-num objects affects proxied route policy.  Other providers
who use RtConfig may have other experience to share.

> If I have interpreted RFC-2622 correctly for what the language can do
> it seems that many of the problems in the discussion 'using IRR tools
> for BGP route filtering' would be under much tighter policy control.
> Of course if the IRR databases were more up to date, many of the
> queries I made had dates that said they had not been changed since
> 1994.

There is crap in the IRR.  This _will_ change.

> Julian

Jeffrey Haas - Merit RSng project - [email protected]