North American Network Operators Group

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

RE: [doable?] peer filtering (was Re: Trusting BGP sessions)

  • From: Mathew Butler
  • Date: Wed Nov 15 18:44:40 2000

Title: RE: [doable?] peer filtering (was Re: Trusting BGP sessions)

If I'm understanding, Sean's suggesting a two-tier system:

1) Providers tell each other, in an administratively-verifiable manner, what routes they have authorization to announce;

2) From moment to moment, the routes that come in across BGP are filtered on a provider-by-provider basis against the information that was shared in the administratively-verifiable manner.

The 'administratively verifiable manner' could be a registry, or it could be an automated mailing list that all network operators could subscribe to that required digital signatures on each update, or it could be anything else.

The simplest form would be a registry that only accepted secure updates from the people authorized to update their part of it, and a registry oversight that ensured compliance with Internet and legal policy.  (i.e., "No one is allowed to advertise routes through their network to other networks unless they have a routing or peering relationship with the other networks in question."  and, "Routing and peering relationships between networks shall be noted in this registry.")

My personal belief is that there needs to be one person at each network operations center who knows (and is told) everything about what's going on related to this, and should have a large percentage of his/her time blocked out to "Maintaining Internet Routing Relationships" -- and that it should become a matter of course that if this function is not performed properly, that tertiary and carrier networks should not be held responsible for filtering out any routing based on 'stale data' (in this case, we could define 'stale data' to be 28 days old, or some arbitrary number).

This would require, of course, the ability for a 'registry refresh' command to be issued by an organization's Routing Liaison to update the last-checked times for -all- entries owned by that organization.  It would also require the ability for that title to arbitrarily change hands.

(The larger issue is, "can a Registry be created such that it is easy enough to use that people will be willing to use it, that it is responsive enough to advertise changes in a quick manner, that is flexible enough to understand and take action on all the non-standard problems that people will come up with, and which is able to be legally and contractually bound to perform those duties in an accountable fashion?")

-Mat Butler

-----Original Message-----
From: Sean Donelan [mailto:[email protected]]
Sent: Wednesday, November 15, 2000 2:51 PM
To: [email protected]
Cc: [email protected]
Subject: Re: [doable?] peer filtering (was Re: Trusting BGP sessions)



No I'm not suggesting basing it on what a provider is currently
advertising.  But rather on what the provider has registered and
is authorized to announce.  The set of authorized routes may be
the same or a superset of what the routes the provider is currently
announcing.

If you want asymetric routes, you can register and authorize traffic
via either route; and then dynamically announce which route you want
to use moment to moment.

On Wed, 15 November 2000, "Bora Akyol" wrote:
> If I understand you correctly, you want to filter inbound traffic from a
> service provider to another based on what that service provider is
> advertising and based on the decision process that we run.
>
> How do you suggest we handle asymmetric routes?
>
> Bora
>
> ----- Original Message -----
> From: "Sean Donelan" <[email protected]>
> To: <[email protected]>
> Cc: <[email protected]>
> Sent: Wednesday, November 15, 2000 2:05 PM
> Subject: Re: [doable?] peer filtering (was Re: Trusting BGP sessions)
>
>
> >
> > On Wed, 15 November 2000, john heasley wrote:
> > >
> > > great, that must be why these problems dont occur.  which solution are
> > > you using?  i'm not flinging s*[email protected] over the fence; i'm truely interested.
> >
> >
> > If the problem is truely no router vendor make a router capable of
> > holding a fully filtered route table we need to tell the router vendors
> > this is a mandatory requirement or we won't buy their routers.  Remember,
> > once upon a time when no router could handle more than 30,000 routes or
> > 64,000 routes.  Once the router vendors were told what was needed, they
> > built a box to meet that need.
> >
> > It is not a given that no router will never support filtering a full
> > tier-1 ISP's route table.  Its just no one has made it a requirement.
> >
> > Lets make it a requirement of the router vendors.
> >
> >
> >