Mailing List Archive: nsp: inet

Prefix Pollution

Index | Next | Previous | View Threaded

Michael.Dillon at radianz

Dec 14, 2004, 5:57 AM

Post #1 of 7 (5727 views)
Permalink

Prefix Pollution

I generally agree with Randy's viewpoint on this.
However, I think that the problem of pollution arises
from people's behavior and there are some social
engineering actions that can help. For instance
back in 2001 there was a lot of publicity about the
problem but then around the time that Cengiz presented
his findings, it seemed like the telecom collapse
had solved the problem. I think a lot of people who
could be cleaning up their announcements have
put this mentally on the back burner.

>i proposed to rodney today, there are three types of prefix
>pollution.
> o pure crap, such as that we see on top of the weekly
> report
> o someone traffic engineering
> o legitimate holes (someone moving from at&t's 12/8)

I like this. If we can come up with some reasonable
definitions for this then perhaps we can talk
Team Cymru into providing these "prefix attributes"
as yet another feed. The bogon feed has a
growing profile and the fact that RIRs regularly
release new /8's helps keep this issue alive.
I wouldn't want this to be just jumbled with the
bogon feed, but a separate feed of "prefix pollution"
would be just about right.

The big task is going to be identifying the
traffic engineering and the legitimate holes.
That's where this list could be helpful so that
people can explain what they are really doing
with their shorter prefixes in case they get
misclassified.

--Michael Dillon

jzp-inetops at rsuc

Dec 14, 2004, 6:27 AM

Post #2 of 7 (5478 views)
Permalink

Prefix Pollution [In reply to]

On Tue, Dec 14, 2004 at 10:58:14AM +0000, Michael.Dillon [at] radianz wrote:
[snip]
> The big task is going to be identifying the
> traffic engineering and the legitimate holes.
> That's where this list could be helpful so that
> people can explain what they are really doing
> with their shorter prefixes in case they get
> misclassified.

I many be a bit stodgey in this regard, but what comprises
'legitimate traffic engineering' that needs to be seen in
the DFZ?

It is trivial to leak deaggregates to one's providers
tagged NO_EXPORT. Beyond the radius of $s flowing, what
is 'legitimate'? And 'company already doing it at a
flag day' or 'company who employs $person' aren't
acceptable answers.

The litmus test of 'breaks reachability' isn't much of a
bar, as people are going out of their way to do that with
no discernable benefit.

Likely some combination of 'breaks reachability' and 'not
trivially reduced by as-path' needs to be concocted, as
there are many many trivial examples that from N arbitrary
ASNs away have no differentiation in path. I'm not even
talking about 'global corporation carving their legacy
allocations up' or 'global entity behind nat/firewall
exposing small slices as DMZes'... off the top of my head,
Nestle US:

route-views.oregon-ix.net>sho ip bgp 165.131.0.0/16 lo | inc /
* 165.131.118.0/23 196.7.106.245 0 0 2905 701 7018 31880 ?
* 165.131.124.0/23 196.7.106.245 0 0 2905 701 7018 31880 ?
* 165.131.174.0/23 196.7.106.245 0 0 2905 701 7018 31880 ?
route-views.oregon-ix.net>sho ip bgp quote-reg "_31880" | inc /
* 165.131.118.0/23 196.7.106.245 0 0 2905 701 7018 31880 ?
* 165.131.124.0/23 196.7.106.245 0 0 2905 701 7018 31880 ?
* 165.131.174.0/23 196.7.106.245 0 0 2905 701 7018 31880 ?
route-views.oregon-ix.net>sho ip bgp quote-reg "_31880" | ex 7018
BGP table version is 23826096, local router ID is 198.32.162.100
Status codes: s suppressed, d damped, h history, * valid, > best, i -
internal,
S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
route-views.oregon-ix.net>

joe

--
RSUC / GweepNet / Spunk / FnB / Usenix / SAGE

ralph at istop

Dec 14, 2004, 7:47 AM

Post #3 of 7 (5480 views)
Permalink

Prefix Pollution [In reply to]

On Tue, 14 Dec 2004, Michael.Dillon [at] radianz wrote:

> However, I think that the problem of pollution arises
> from people's behavior and there are some social
> engineering actions that can help.

Many customers are not aware of Arin's /22 policy, and for those that are
aware, there's often no incentive to apply for their own block.

For example I had a customer that was reassigned a /23 and /24 from my
/19. They were multi-homed, and were also reassigned IPs from another
transit provider. We charge a modest amount for reassignments ($35/mth
per /24) but the other provider (like most) doesn't.

After the /22 policy came out I told the customer they should get their
own /22. They didn't. Eventually I told them I was taking back the IPs
and gave them 2 months to renumber. The whole process took so much work I
can see why most networks would rather just do nothing. Updating RR
objects isn't too bad since it is automated, but upstream filter updates
generally are not. In many cases it takes more than just an email to an
upstream to get filter changes done.

I susupect the big networks don't even know which customers would qualify
for direct assignment, so nothing will happen in this case.

One simple thing I think that would help is if transit providers set their
filters to allow for aggregation. Let's say I'm announcing 67.8.64.0/22.
My upstreams will add this to their filters
... permit 67.8.64.0/22
Why not add this instead?
... permit 67.8.64.0/18 le 22

Overall though, I think it's a rather steep uphill battle...

-Ralph

randy at psg

Dec 14, 2004, 9:46 AM

Post #4 of 7 (5486 views)
Permalink

Prefix Pollution [In reply to]

>> i proposed to rodney today, there are three types of prefix
>> pollution.
>> o pure crap, such as that we see on top of the weekly
>> report
>> o someone traffic engineering
>> o legitimate holes (someone moving from at&t's 12/8)
>
> I like this. If we can come up with some reasonable
> definitions for this then perhaps we can talk
> Team Cymru into providing these "prefix attributes"

absolutely no need. engage brain, please.

> The big task is going to be identifying the
> traffic engineering and the legitimate holes.

they are self-identifying. shift brain to second
gear.

or just read the rest of my message.

a hardcore <bleep> such as i might just filter them all

a friendlier type might just dump longer prefixes if they
had the same origin asn (the new part of the suggestion)

a southern californian might only dump a longer prefix
if it has the same next hop as the covering prefix

randy

jzp-inetops at rsuc

Dec 14, 2004, 10:14 AM

Post #5 of 7 (5484 views)
Permalink

Prefix Pollution [In reply to]

On Tue, Dec 14, 2004 at 06:45:57AM -0800, Randy Bush wrote:
[snip]
> a hardcore <bleep> such as i might just filter them all
>
> a friendlier type might just dump longer prefixes if they
> had the same origin asn (the new part of the suggestion)
>
> a southern californian might only dump a longer prefix
> if it has the same next hop as the covering prefix

Part of 'what action should i take' also falls under 'what
is least effort'. MD pointed on that other list to the
CAIDA Atoms work [http://www.caida.org/projects/routing/atoms/]
which is very cool, but requires one of
- non-realtime offline processing [boo]
- vendors to incorporate their own proprietary and buggy code
to do the same thing [in a glacial epoch]
- people to junk vendors and solder their own interface boards
in the garage [didn't we do that before?]

...so many times the analysis comes back to "accept everything
and only react to outside-influence-of-the-moment" or "follow
allocation guidelines for a baseline filter and adjust as
business needs dictate".

Does either approach nescessarily lead to better stability and
goodput? I have my opinions based on my experiences, but am not
so full of hubris to think mine is the only point of view that
counts. A HUGE portion of my poking-the-stick into this nest
isa to see if there are hornets in it [."yes this is still 'an
issue' and somehow we were collectively asleep at the wheel of
the DFZ"] or not [."no, the general consensus is that if you
haven't upgraded in the last X years, and can't budget for
unpredicatble growth, then get out of the game"].

Joe, setting religion on the shelf for a bit to get data

--
RSUC / GweepNet / Spunk / FnB / Usenix / SAGE

randy at psg

Dec 14, 2004, 10:32 AM

Post #6 of 7 (5489 views)
Permalink

Prefix Pollution [In reply to]

> Part of 'what action should i take' also falls under 'what
> is least effort'. MD pointed on that other list to the
> CAIDA Atoms work [http://www.caida.org/projects/routing/atoms/]
> which is very cool, but requires one of
> ...

which is why it is, sadly, kinda operationally irrelevant.
bummer that.

> ...so many times the analysis comes back to "accept everything
> and only react to outside-influence-of-the-moment" or "follow
> allocation guidelines for a baseline filter and adjust as
> business needs dictate".

you don't think what was discussed on c-nsp is
o simple enough code the vendors might get it right on
the third try, and
o has the knobs you need to set reasonable (to you)
policy?

if not, why not?

randy

jzp-inetops at rsuc

Dec 15, 2004, 10:28 PM

Post #7 of 7 (5477 views)
Permalink

Prefix Pollution [In reply to]

On Tue, Dec 14, 2004 at 07:32:11AM -0800, Randy Bush wrote:
[snip]
> > ...so many times the analysis comes back to "accept everything
> > and only react to outside-influence-of-the-moment" or "follow
> > allocation guidelines for a baseline filter and adjust as
> > business needs dictate".
>
> you don't think what was discussed on c-nsp is
> o simple enough code the vendors might get it right on
> the third try, and
> o has the knobs you need to set reasonable (to you)
> policy?
>
> if not, why not?

I'm under the weather so need to re-read both the pseudo-code
that was bounced around and draft-hardie-bounded-longest-match
to give an informed reponses. I am compelled to not let the
attempt to have real discussion here fall down just because
of my lack of input. My gut feeling is that for some deployments
where this is a concern [multihoming smaller enterprises],
restricting to next-hop would not be appropriate and that a
knob for next-hop or neighbor-AS would be needed. Given the
nature of current vendor-implementations of ebgp policy knobs
and the way folks have cleverly deployed them, I would think
not closing too many doors would be in the best interest of
all.

So yes I'd suggest giving operators enough rope to hang
themselves if they go overboard, by providing supressing
remote more-specifics ['bounding the longest match'] on a
number of policy axes:
next-hop [straightforward seen as the Right Thing]
router-id [.not nescessarily the same as above - also consider
the wildly useful variation of router-id to trigger the
neighbor's supression anologous to the clever use of RPF
to trigger blackholes today]
neighbor AS [to address local next-hop related complexities]
MED ("i wish to get the more-specifics if my neighbor tells me
there is value")
Origin (similar to above point)

It essentially comes down to how much 'sameness' is needed to
consider them identical? If we don't cover for minor variances
lower down the decisions tree then suddenly those 'lower points'
become very significant knobs to turn. I can see people arguing
with me about that [MED and origin]; I can table that for now.

Router ID seems natural and trivial if we're already inspecting
next-hop. I will strenuously argue that neighbor ASN be considered,
specifically to speak to Mr Donacaster's point. This provides
the simple multihoming the end-customers automatic control over
attemtps to siphon their traffic; consquently there is no economic
incentive for those customers' providers to tacitly encourage table
pollution. In the simplified case of
- two multihomed enterprises, one of which
(a) announces extra crap and the other
(b) who doesn't want to hear it
and
- two transit carriers, one of which
(c) deploys the new feature and the other which
(d) does not

+-- C --+
/ \
A --- D --- B

C presents A's long prefix to B
D presents A's long and short prefixes to B
B has paralel links ro D, attached to the same border
within B and disparate aggregation devices in D.
supression based on next-hop or even router-id couldn't
comparison wouldn't help poor B. based on AS would.

Neighbor-AS-based comparison also simplifies configuration
[ports and therefore next-hop migrate more frequently
than ASNs do], and we are told time and again that root
causes of most network issues are configuration-wrangling
related.

In the long term, we [or our memetic descendants] are likely
to be discussing the centralized nature of this point on the
decision tree and a RIB-vs-FIB issue just as we all went round
the separating-a-distributed-FIB-from-centralized-RIB maypole
in the mid->latter 90s.

Cheers,

joe

--
RSUC / GweepNet / Spunk / FnB / Usenix / SAGE

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads