[32272] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

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

daemon@ATHENA.MIT.EDU (Mathew Butler)
Wed Nov 15 18:43:43 2000

Message-ID: <F062E72E4BA2D4119F1700B0D03D205F39C4@MAIL>
From: Mathew Butler <mbutler@tonbu.com>
To: 'Sean Donelan' <sean@donelan.com>, akyol@akyol.org
Cc: nanog@merit.edu
Date: Wed, 15 Nov 2000 15:31:40 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C04F5C.34A22140"
Errors-To: owner-nanog-outgoing@merit.edu


This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C04F5C.34A22140
Content-Type: text/plain;
	charset="iso-8859-1"

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:sean@donelan.com]
Sent: Wednesday, November 15, 2000 2:51 PM
To: akyol@akyol.org
Cc: nanog@merit.edu
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" <sean@donelan.com>
> To: <heas@shrubbery.net>
> Cc: <nanog@merit.edu>
> 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*!@ 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.
> >
> >
> >



------_=_NextPart_001_01C04F5C.34A22140
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: [doable?] peer filtering (was Re: Trusting BGP =
sessions)</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>If I'm understanding, Sean's suggesting a two-tier =
system:</FONT>
</P>

<P><FONT SIZE=3D2>1) Providers tell each other, in an =
administratively-verifiable manner, what routes they have authorization =
to announce;</FONT></P>

<P><FONT SIZE=3D2>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.</FONT></P>

<P><FONT SIZE=3D2>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.</FONT></P>

<P><FONT SIZE=3D2>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.&nbsp; (i.e., &quot;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.&quot;&nbsp; and, &quot;Routing and peering relationships =
between networks shall be noted in this registry.&quot;)</FONT></P>

<P><FONT SIZE=3D2>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 &quot;Maintaining =
Internet Routing Relationships&quot; -- 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).</FONT></P>

<P><FONT SIZE=3D2>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.&nbsp; It would also require the ability for that =
title to arbitrarily change hands.</FONT></P>

<P><FONT SIZE=3D2>(The larger issue is, &quot;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?&quot;)</FONT></P>

<P><FONT SIZE=3D2>-Mat Butler</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Sean Donelan [<A =
HREF=3D"mailto:sean@donelan.com">mailto:sean@donelan.com</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Wednesday, November 15, 2000 2:51 PM</FONT>
<BR><FONT SIZE=3D2>To: akyol@akyol.org</FONT>
<BR><FONT SIZE=3D2>Cc: nanog@merit.edu</FONT>
<BR><FONT SIZE=3D2>Subject: Re: [doable?] peer filtering (was Re: =
Trusting BGP sessions)</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>No I'm not suggesting basing it on what a provider is =
currently </FONT>
<BR><FONT SIZE=3D2>advertising.&nbsp; But rather on what the provider =
has registered and</FONT>
<BR><FONT SIZE=3D2>is authorized to announce.&nbsp; The set of =
authorized routes may be</FONT>
<BR><FONT SIZE=3D2>the same or a superset of what the routes the =
provider is currently</FONT>
<BR><FONT SIZE=3D2>announcing.</FONT>
</P>

<P><FONT SIZE=3D2>If you want asymetric routes, you can register and =
authorize traffic</FONT>
<BR><FONT SIZE=3D2>via either route; and then dynamically announce =
which route you want</FONT>
<BR><FONT SIZE=3D2>to use moment to moment.</FONT>
</P>

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

</BODY>
</HTML>
------_=_NextPart_001_01C04F5C.34A22140--


home help back first fref pref prev next nref lref last post