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 whois.radb.net 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 router. 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 {0.0.0.0/0} 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 {0.0.0.0/0} 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 {0.0.0.0/0}, etc, etc, etc.

Gerald Winters already pointed out a few. I'll note that you can examine the PAIR output from the Route Servers (http://www.rsng.net/rs-views) 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 - jeffhaas@merit.edu