Mailing List Archive: NANOG: users

Public shaming list for ISPs announcing other ISPs IP space by mistake

1 2

View All

Index | Next | Previous | View Threaded

drc at virtualized

Aug 14, 2008, 9:59 PM

Post #26 of 35 (357 views)
Permalink

Re: Public shaming list for ISPs announcing other ISPs IP space by mistake [In reply to]

Danny,

On Aug 14, 2008, at 8:29 PM, Danny McPherson wrote:
>> On Aug 14, 2008, at 9:47 AM, brett watson wrote:
>>> We're lacking the authority and delegation model that DNS has, I
>>> think?
>> If one were to ignore layer 9 politics, it could be argued the
>> authority/delegation models between DNS and address space are quite
>> analogous.
> TODAY IANA has an operational role in DNS, they don't have
> an operational role in Internet routing.

Yep. IANA does indeed have a limited operational role in the DNS (in
that currently IANA directly operates .int, ip6.arpa, urn.arpa,
uri.arpa, and iris.arpa) and no direct operational role in routing.

Of course, the statement was about the authority and delegation model,
not about operational roles.

> This is certainly not layer
> 9, and most certainly the most fundamental change to the Internet
> routing system that RPKI or similar systems would introduce.

Not sure it is 'the most fundamental change', but it is indeed a
significant change. That's sort of the point: RPKI is designed to
allow for validation which isn't possible now.

> To be clear: IANA and RIRs allocate or assign address space
> today, they don't control any routing on the Internet (and their
> own internal ASNs and IPs don't count).

Indeed. And if RPKI is deployed in a way that is useful for validation
of routing announcements in real time, this will obviously change,
regardless of whether there is a single root for the address space or
multiple roots. However, it seems to me that the decision as to
whether there is a single root or multiple roots is deeply rooted (pun
intended) in layer 9.

But perhaps that's just me.

Regards,
-drc

danny at tcb

Aug 14, 2008, 10:07 PM

Post #27 of 35 (356 views)
Permalink

Re: Public shaming list for ISPs announcing other ISPs IP space by mistake [In reply to]

On Aug 14, 2008, at 10:59 PM, David Conrad wrote:
>
> Yep. IANA does indeed have a limited operational role in the DNS
> (in that currently IANA directly operates .int, ip6.arpa, urn.arpa,
> uri.arpa, and iris.arpa) and no direct operational role in routing.
>
> Of course, the statement was about the authority and delegation
> model, not about operational roles.
> ...
> Not sure it is 'the most fundamental change', but it is indeed a
> significant change. That's sort of the point: RPKI is designed to
> allow for validation which isn't possible now.
> ...
> Indeed. And if RPKI is deployed in a way that is useful for
> validation of routing announcements in real time, this will
> obviously change, regardless of whether there is a single root for
> the address space or multiple roots. However, it seems to me that
> the decision as to whether there is a single root or multiple roots
> is deeply rooted (pun intended) in layer 9.
>
> But perhaps that's just me.

OK, so we were talking past one another. I agree with everything
you said above, and simply meant to highlight the fact that RPKI
validation will change things (quite necessarily, IMO), and folks
need to be paying attention to this.

-danny

jmalcolm at uraeus

Aug 15, 2008, 4:53 AM

Post #28 of 35 (354 views)
Permalink

Re: Public shaming list for ISPs announcing other ISPs IP space by mistake [In reply to]

Jared Mauch writes:
> No really, the reason for some leaks isn't because so-and-so was
>never a customer, they were. 5 years ago. nobody removed the routes from
>the IRR or AS-SET or <insert method here> and now the route is learned via
>some other location and it's bypassed your perimiter security and
>infiltrated your BGP.

The issue of cleaning up legacy state for former customers applies to
many things beyond route announcements - though the latter may be one
of the more visible remnants. I suspect relatively few companies can
accurately and completely track the state associated with a customer
such that it can be removed once the customer billing stops. (Or they
stop paying.) This really needs to be automated and the backend
databases need a way to associate records with particular billing
entities, or else you will find yourself slowly cleaning up after past
customers at inconvenient moments for years.

Joe

david.freedman at uk

Aug 15, 2008, 7:49 AM

Post #29 of 35 (356 views)
Permalink

Re: Public shaming list for ISPs announcing other ISPs IP space by mistake [In reply to]

Danny McPherson wrote:
>
> On Aug 14, 2008, at 1:09 PM, Jared Mauch wrote:
>>
>> You're missing a step:
>>
>> janitor.
>>
>> No really, the reason for some leaks isn't because so-and-so was
>> never a customer, they were. 5 years ago. nobody removed the routes
>> from
>> the IRR or AS-SET or <insert method here> and now the route is learned
>> via
>> some other location and it's bypassed your perimiter security and
>> infiltrated your BGP.
>
> I agree, how many of you folks that use IRRs have
> ever deleted an IRR object? Heck, some ISPs even
> add them based on existence of advertised routes.

Agree, IRR objects do get dirty and require cleaning up,

The company I work for makes a good effort at this which
starts by measuring how dirty they are:

http://noc.eu.clara.net/routing.php

The problem is caused by a combination of both us and our downstreams
not cleaning properly.

Over the past few months I've been working on a personal project to
clean our IRR objects by making the system which generates them talk
closer to the system which bills people. (*)

Part of this work has meant going through the pain of providing an
internal WHOIS service since we decided that it was the best way of
storing data without re-inventing the wheel.

This said, if you are not using IRR (at least for your customers) then
PLEASE START DOING SO, you'll have plenty of time to worry about keeping
it up to date once you can get you or your organisation to grips with it.

Dave.

* if you are interested you can compare AS-CLARANET macro in the ripedb
with AS-CLARANET macro in the ripe testdb (test-whois.ripe.net), This
object will launch in the next few weeks.

>
> -danny
>
>

mksmith at adhost

Aug 16, 2008, 8:28 AM

Post #30 of 35 (345 views)
Permalink

Re: Public shaming list for ISPs announcing other ISPs IP space by mistake [In reply to]

>>
>> janitor.
>>
>> No really, the reason for some leaks isn't because so-and-so was
>> never a customer, they were. 5 years ago. nobody removed the
>> routes from
>> the IRR or AS-SET or <insert method here> and now the route is
>> learned via
>> some other location and it's bypassed your perimiter security and
>> infiltrated your BGP.
>
> I agree, how many of you folks that use IRRs have
> ever deleted an IRR object? Heck, some ISPs even
> add them based on existence of advertised routes.
>
> -danny
>
Even better, how many have tried to get another provider to remove legacy
objects from days gone by when someone was adding objects on your behalf? I
have objects that date back to 1998 that are completely bogus and I can't do
squat about it.

Mike

jlewis at lewis

Aug 17, 2008, 12:44 PM

Post #31 of 35 (340 views)
Permalink

Re: Public shaming list for ISPs announcing other ISPs IP space by mistake [In reply to]

On Thu, 14 Aug 2008, Danny McPherson wrote:

> I agree, how many of you folks that use IRRs have
> ever deleted an IRR object? Heck, some ISPs even
> add them based on existence of advertised routes.

On that topic, how do you delete IRR objects when the person who created
them used a unique maintainer object and is no longer around to provide
the password for the maintainer object?

----------------------------------------------------------------------
Jon Lewis | I route
Senior Network Engineer | therefore you are
Atlantic Net |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________

jared at puck

Aug 17, 2008, 12:55 PM

Post #32 of 35 (342 views)
Permalink

Re: Public shaming list for ISPs announcing other ISPs IP space by mistake [In reply to]

On Sun, Aug 17, 2008 at 03:44:40PM -0400, Jon Lewis wrote:
> On Thu, 14 Aug 2008, Danny McPherson wrote:
>
>> I agree, how many of you folks that use IRRs have
>> ever deleted an IRR object? Heck, some ISPs even
>> add them based on existence of advertised routes.
>
> On that topic, how do you delete IRR objects when the person who created
> them used a unique maintainer object and is no longer around to provide
> the password for the maintainer object?

This is what the human at most db-admin aliases is for.

I know that we staff humans behind our alias to respond to
such queries.

- Jared

--
Jared Mauch | pgp key available via finger from jared [at] puck
clue++; | http://puck.nether.net/~jared/ My statements are only mine.

thegameiam at yahoo

Aug 17, 2008, 5:34 PM

Post #33 of 35 (341 views)
Permalink

Re: Public shaming list for ISPs announcing other ISPs IP space by mistake [In reply to]

--- On Sun, 8/17/08, Jared Mauch <jared [at] puck> wrote:
> On Sun, Aug 17, 2008 at 03:44:40PM -0400, Jon Lewis wrote:

> > On that topic, how do you delete IRR objects when the
> person who created
> > them used a unique maintainer object and is no longer
> around to provide
> > the password for the maintainer object?
>
> This is what the human at most db-admin aliases is for.
>
> I know that we staff humans behind our alias to respond to
> such queries.

Or this points to the utility of creating your own internal RRd server, and peering with the public IRRs.

David Barak
Need Geek Rock? Try The Franchise:
http://www.listentothefranchise.com

billn at billn

Aug 18, 2008, 11:52 AM

Post #34 of 35 (339 views)
Permalink

Re: Public shaming list for ISPs announcing other ISPs IP space by mistake [In reply to]

On Sun, 17 Aug 2008, Jared Mauch wrote:
>>> I agree, how many of you folks that use IRRs have
>>> ever deleted an IRR object? Heck, some ISPs even
>>> add them based on existence of advertised routes.
>>
>> On that topic, how do you delete IRR objects when the person who created
>> them used a unique maintainer object and is no longer around to provide
>> the password for the maintainer object?
>
> This is what the human at most db-admin aliases is for.
>
> I know that we staff humans behind our alias to respond to
> such queries.
>

Absent any kind of network wide enforcement, why don't you just roll
participation and compliance with this into your peering contracts, with
propagation? Require your peers to have it, and ask that they pass the
requirement on. This isn't rocket science, clearly, because even I
understand it. All it takes it a couple of larger entities to set the bar,
and drag everyone up. Some of this may amount to teaching your peers to
fish, but if everyone wins, thanks for contributing.

Require peers to support IRR objects.
Require them to have an alias that points at an always existing human.
Require them to maintain their entries.

And then do it yourself so they can see how it's done.

- billn

deepak at ai

Aug 18, 2008, 12:04 PM

Post #35 of 35 (339 views)
Permalink

Re: Public shaming list for ISPs announcing other ISPs IP space by mistake [In reply to]

> Absent any kind of network wide enforcement, why don't you just roll
> participation and compliance with this into your peering contracts, with
> propagation? Require your peers to have it, and ask that they pass the
> requirement on. This isn't rocket science, clearly, because even I
> understand it. All it takes it a couple of larger entities to set the
> bar, and drag everyone up. Some of this may amount to teaching your
> peers to fish, but if everyone wins, thanks for contributing.
>
> Require peers to support IRR objects.
> Require them to have an alias that points at an always existing human.
> Require them to maintain their entries.
>
> And then do it yourself so they can see how it's done.

The business process would read:

"New procedures will reduce the operational cost of our operations by xx%".

"All peering contracts renewed or executed after [date] will comply to
document xxxx".

Revised customer IP provisioning procedures:

"Insert new customer IP info into our local IRR. Customer IPs will not
work if this is not done."

"Press here to cause us to spin our configuration builder."

Deepak

1 2

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads