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

swmike at swm

Aug 13, 2008, 1:04 PM

Post #1 of 35 (546 views)
Permalink

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

The italian courts seem to have told ISPs there to block ThePirateBay
(bittorrent tracker), and this evening (CET) LLNW (AS22822) originated
88.80.6.0/24 via 6762 (telecom italia) to what I presume is most of
Europe.

Basically same thing that happened when people tried to block YouTube a
few months back (afghanistan?).

How do we hinder this in the short term? I know there are a lot of long
term solutions that very few is implementing, but would the fact that
these mistakes are brought up into the (lime)light by a public shaming
list make ISPs shape up and perform less mistakes?

I am still waiting for a response from LLNW NOC on the issue.

--
Mikael Abrahamsson email: swmike[at]swm.pp.se

jared at puck

Aug 13, 2008, 1:48 PM

Post #2 of 35 (530 views)
Permalink

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

On Wed, Aug 13, 2008 at 10:04:27PM +0200, Mikael Abrahamsson wrote:
>
> The italian courts seem to have told ISPs there to block ThePirateBay
> (bittorrent tracker), and this evening (CET) LLNW (AS22822) originated
> 88.80.6.0/24 via 6762 (telecom italia) to what I presume is most of
> Europe.
>
> Basically same thing that happened when people tried to block YouTube a
> few months back (afghanistan?).
>
> How do we hinder this in the short term? I know there are a lot of long
> term solutions that very few is implementing, but would the fact that
> these mistakes are brought up into the (lime)light by a public shaming
> list make ISPs shape up and perform less mistakes?
>
> I am still waiting for a response from LLNW NOC on the issue.

Sure. I'd also like to see providers actually just shut
off customers that originate stuff like ms-sql slammer
packets still. But it keeps flowing. I'm sure there are
smurf amps and other badness still going. codered anyone?

these are all issues, but operational? depends.
If LLNW is not being filtered by telecom italia, time for
6762 to fix that. If they persist, will you depeer them
as a security risk until they clean up their act?

I'm still amazed at the AS_PATHs that appear
out there and the providers that can't figure out how to
route.

Why AS174 would listen to 3549 routes from AS12713
is beyond me, but it's there.[1]

221.134.222.0/24 1280 174 12713 3549 2914 9498 9583

- jared

1 - http://puck.nether.net/bgp/leakinfo.cgi
- http://puck.nether.net/bgp/stats.cgi?days=3

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

patrick at ianai

Aug 13, 2008, 1:52 PM

Post #3 of 35 (530 views)
Permalink

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

On Aug 13, 2008, at 4:48 PM, Jared Mauch wrote:
> On Wed, Aug 13, 2008 at 10:04:27PM +0200, Mikael Abrahamsson wrote:
>>
>> The italian courts seem to have told ISPs there to block ThePirateBay
>> (bittorrent tracker), and this evening (CET) LLNW (AS22822)
>> originated
>> 88.80.6.0/24 via 6762 (telecom italia) to what I presume is most of
>> Europe.
>>
>> Basically same thing that happened when people tried to block
>> YouTube a
>> few months back (afghanistan?).
>>
>> How do we hinder this in the short term? I know there are a lot of
>> long
>> term solutions that very few is implementing, but would the fact that
>> these mistakes are brought up into the (lime)light by a public
>> shaming
>> list make ISPs shape up and perform less mistakes?
>>
>> I am still waiting for a response from LLNW NOC on the issue.
>
> Sure. I'd also like to see providers actually just shut
> off customers that originate stuff like ms-sql slammer
> packets still. But it keeps flowing. I'm sure there are
> smurf amps and other badness still going. codered anyone?
>
> these are all issues, but operational? depends.

I beg to differ, this is absolutely operational.

> If LLNW is not being filtered by telecom italia, time for
> 6762 to fix that. If they persist, will you depeer them
> as a security risk until they clean up their act?

De-peering won't help if someone is propagating it as a transit
customer route. Filtering the prefix is all you can do.

--
TTFN,
patrick

P.S. Obligatory BCP38 shout-out, even though it's not exactly on-
point. :-)

> I'm still amazed at the AS_PATHs that appear
> out there and the providers that can't figure out how to
> route.
>
> Why AS174 would listen to 3549 routes from AS12713
> is beyond me, but it's there.[1]
>
> 221.134.222.0/24 1280 174 12713 3549 2914 9498 9583
>
>
> - jared
>
> 1 - http://puck.nether.net/bgp/leakinfo.cgi
> - http://puck.nether.net/bgp/stats.cgi?days=3
>
>
> --
> Jared Mauch | pgp key available via finger from jared[at]puck.nether.net
> clue++; | http://puck.nether.net/~jared/ My statements are
> only mine.
>

swmike at swm

Aug 13, 2008, 1:56 PM

Post #4 of 35 (529 views)
Permalink

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

On Wed, 13 Aug 2008, Jared Mauch wrote:

> these are all issues, but operational? depends. If LLNW is not
> being filtered by telecom italia, time for 6762 to fix that. If they
> persist, will you depeer them as a security risk until they clean up
> their act?

I just discovered (via bgplay) that 22822 first originated the prefix via
5511 (france telecom), then it was withdrawn a while later, and then
originated via 6762, and then withdrawn again. An hour or so between these
events.

We all know we don't filter our peers (there is no operationally sane way
of doing this today), so the question is how to make ISPs filter their
customers more sanely.

We have prefix-filters on our customer bgp sessions, so that should be
fairly safe, but I see no good way of doing this towards peers as there is
no uniform way of doing this, and there is no industry consenus how it
should be done.

--
Mikael Abrahamsson email: swmike[at]swm.pp.se

jared at puck

Aug 13, 2008, 2:04 PM

Post #5 of 35 (534 views)
Permalink

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

On Wed, Aug 13, 2008 at 04:52:46PM -0400, Patrick W. Gilmore wrote:
> On Aug 13, 2008, at 4:48 PM, Jared Mauch wrote:
>> On Wed, Aug 13, 2008 at 10:04:27PM +0200, Mikael Abrahamsson wrote:
>>>
>>> The italian courts seem to have told ISPs there to block ThePirateBay
>>> (bittorrent tracker), and this evening (CET) LLNW (AS22822)
>>> originated
>>> 88.80.6.0/24 via 6762 (telecom italia) to what I presume is most of
>>> Europe.
>>>
>>> Basically same thing that happened when people tried to block
>>> YouTube a
>>> few months back (afghanistan?).
>>>
>>> How do we hinder this in the short term? I know there are a lot of
>>> long
>>> term solutions that very few is implementing, but would the fact that
>>> these mistakes are brought up into the (lime)light by a public
>>> shaming
>>> list make ISPs shape up and perform less mistakes?
>>>
>>> I am still waiting for a response from LLNW NOC on the issue.
>>
>> Sure. I'd also like to see providers actually just shut
>> off customers that originate stuff like ms-sql slammer
>> packets still. But it keeps flowing. I'm sure there are
>> smurf amps and other badness still going. codered anyone?
>>
>> these are all issues, but operational? depends.
>
> I beg to differ, this is absolutely operational.

So, I should shut down or depeer networks that
continue to originate the crap to me? (packets, announcements).

>> If LLNW is not being filtered by telecom italia, time for
>> 6762 to fix that. If they persist, will you depeer them
>> as a security risk until they clean up their act?
>
> De-peering won't help if someone is propagating it as a transit customer
> route. Filtering the prefix is all you can do.

Taking this example, if I were to depeer 6762 becuase
they can't keep their routing table clean to me, I suspect
they would look at how to fix the issue. I could just filter their
as-path globally until they contact me to resolve the issue.

I'm not saying I would actually do that, but there is
a question of what level of action should be taken to resolve
these issues, and a timescale for their resolution. I've found
some networks excellent to work with, and others "we'll stop
leaking to you in a few days once we finish escalating
the issue to our tier-n NOC in XXX city".

Honestly, I find that to be kinda lazy considering how
critical the routing infrasturcture is for our survival as an
industry.

> P.S. Obligatory BCP38 shout-out, even though it's not exactly on-point.

I can't agree with this more, If you're not doing u-RPF on your
customer interfaces (t1, ds3, ge, fe, colo, etc..) you should be. The only
excuses are broken software or incapable hardware from your vendor.

Sadly those last two seem to impair the ability to take these
basic network security requirements into account for a network of any
size.

It'll help reduce the possible attack home-base for various spoofing
attacks (including some DNS one, did you hear about it?)

- Jared

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

karnaugh at karnaugh

Aug 13, 2008, 2:05 PM

Post #6 of 35 (529 views)
Permalink

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

On 2008/08/13 10:04 PM Mikael Abrahamsson wrote:
>
> The italian courts seem to have told ISPs there to block ThePirateBay
> (bittorrent tracker), and this evening (CET) LLNW (AS22822) originated
> 88.80.6.0/24 via 6762 (telecom italia) to what I presume is most of Europe.
>
> Basically same thing that happened when people tried to block YouTube a
> few months back (afghanistan?).
>
> How do we hinder this in the short term? I know there are a lot of long
> term solutions that very few is implementing, but would the fact that
> these mistakes are brought up into the (lime)light by a public shaming
> list make ISPs shape up and perform less mistakes?

Can't IANA give $100000 stupidity tax or revoke AS for people that do
this?

sean at donelan

Aug 13, 2008, 2:09 PM

Post #7 of 35 (531 views)
Permalink

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

On Wed, 13 Aug 2008, Mikael Abrahamsson wrote:
> We have prefix-filters on our customer bgp sessions, so that should be fairly
> safe, but I see no good way of doing this towards peers as there is no
> uniform way of doing this, and there is no industry consenus how it should be
> done.

Read your peering contract with the other ISP. It should cover what to do
if this happens.

What? you don't have a peering contract with the other ISP. Well I guess
there is no requirement to keep the peering session established if the
peer does stuff you don't want on your network.

If it hurts when you do something, why do you keep doing it?

randy at psg

Aug 13, 2008, 2:11 PM

Post #8 of 35 (530 views)
Permalink

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

> Can't IANA give $100000 stupidity tax

perhaps those of us in glass houses should not suggest a major throwing
of stones? :)

patrick at ianai

Aug 13, 2008, 2:14 PM

Post #9 of 35 (535 views)
Permalink

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

On Aug 13, 2008, at 5:04 PM, Jared Mauch wrote:
> On Wed, Aug 13, 2008 at 04:52:46PM -0400, Patrick W. Gilmore wrote:

>>> Sure. I'd also like to see providers actually just shut
>>> off customers that originate stuff like ms-sql slammer
>>> packets still. But it keeps flowing. I'm sure there are
>>> smurf amps and other badness still going. codered anyone?
>>>
>>> these are all issues, but operational? depends.
>>
>> I beg to differ, this is absolutely operational.
>
> So, I should shut down or depeer networks that
> continue to originate the crap to me? (packets, announcements).

Saying something is Operational (and on-topic for nanog) does not mean
you should de-peer them.

That said, I will not stop you from de-peering a network who can't
keep its table clean. Your network, your decision.

>>> If LLNW is not being filtered by telecom italia, time for
>>> 6762 to fix that. If they persist, will you depeer them
>>> as a security risk until they clean up their act?
>>
>> De-peering won't help if someone is propagating it as a transit
>> customer
>> route. Filtering the prefix is all you can do.
>
> Taking this example, if I were to depeer 6762 becuase
> they can't keep their routing table clean to me, I suspect
> they would look at how to fix the issue. I could just filter their
> as-path globally until they contact me to resolve the issue.

You wield a much bigger hammer than 99.999% of the people here, and
you know it.

> I'm not saying I would actually do that, but there is
> a question of what level of action should be taken to resolve
> these issues, and a timescale for their resolution. I've found
> some networks excellent to work with, and others "we'll stop
> leaking to you in a few days once we finish escalating
> the issue to our tier-n NOC in XXX city".
>
> Honestly, I find that to be kinda lazy considering how
> critical the routing infrasturcture is for our survival as an
> industry.

While I doubt "shame" will work in all but the most extreme cases, I
believe brokeness does, eventually have an impact. Let's just hope
that impact is not blunted by (for instance) monopoly power, so that
"voting with your wallet" will force network to fix things.

Too bad we know monopoly power is blunting most of the effects. :(

>> P.S. Obligatory BCP38 shout-out, even though it's not exactly on-
>> point.
>
> I can't agree with this more, If you're not doing u-RPF on your
> customer interfaces (t1, ds3, ge, fe, colo, etc..) you should be.
> The only
> excuses are broken software or incapable hardware from your vendor.
>
> Sadly those last two seem to impair the ability to take these
> basic network security requirements into account for a network of any
> size.
>
> It'll help reduce the possible attack home-base for various spoofing
> attacks (including some DNS one, did you hear about it?)

Just thought I'd say "BCP38" again.

--
TTFN,
patrick

jared at puck

Aug 13, 2008, 2:20 PM

Post #10 of 35 (522 views)
Permalink

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

On Wed, Aug 13, 2008 at 05:09:54PM -0400, Sean Donelan wrote:
> On Wed, 13 Aug 2008, Mikael Abrahamsson wrote:
>> We have prefix-filters on our customer bgp sessions, so that should be
>> fairly safe, but I see no good way of doing this towards peers as there
>> is no uniform way of doing this, and there is no industry consenus how
>> it should be done.
>
> Read your peering contract with the other ISP. It should cover what to do
> if this happens.
>
> What? you don't have a peering contract with the other ISP. Well I guess
> there is no requirement to keep the peering session established if the
> peer does stuff you don't want on your network.
>
> If it hurts when you do something, why do you keep doing it?

two things:

1) I didn't mean to call out any specific provider, we all
have challenges. Sorry to my friends at Cogent that may have been
offeneded.

2) I think some people have been a bit too lax in enforcing
their peering policies on this topic. Letting something leak for a few
hours may not matter much for some small business or corner of the world.
Leaking something important, or being nasty with it could be really bad.
Imagine instead of spoofing some nameserver, annoucing the space and
being rogue long enough to push out some huge TTL. Take whitehouse.gov
out for the next 30 days..

Would make life interesting. I can think of other badness to do
but won't enumerate it here.

- Jared (dinner time!)

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

karnaugh at karnaugh

Aug 13, 2008, 11:04 PM

Post #11 of 35 (504 views)
Permalink

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

On 2008/08/13 11:11 PM Randy Bush wrote:
>> Can't IANA give $100000 stupidity tax
>
> perhaps those of us in glass houses should not suggest a major throwing
> of stones? :)

Point taken ;)

jared at puck

Aug 14, 2008, 7:56 AM

Post #12 of 35 (497 views)
Permalink

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

On Wed, Aug 13, 2008 at 05:14:43PM -0400, Patrick W. Gilmore wrote:
> Saying something is Operational (and on-topic for nanog) does not mean
> you should de-peer them.

If it's active and persistent, it would qualify as operational.
Then I can classify the risk. I'm openly wondering if there should be
more aggressive "turn the bad stuff off" happening.

> That said, I will not stop you from de-peering a network who can't keep
> its table clean. Your network, your decision.

I'm still seeing persistent leaks, generally over 10k/day that
are unresolved after a year of collecting this data.

> You wield a much bigger hammer than 99.999% of the people here, and you
> know it.

I'm not posting as my employer, nor purporting to represent them,
but at the same time, wonder what the impact would be if there were more
consistent actions taken by networks when there was badness,
either routing leak or otherwise.

> While I doubt "shame" will work in all but the most extreme cases, I
> believe brokeness does, eventually have an impact. Let's just hope that
> impact is not blunted by (for instance) monopoly power, so that "voting
> with your wallet" will force network to fix things.

I certainly agree on the impact. If there were clear
and predictable reactions to the brokeness, would people actually
take actions to repair the problem?

eg:

200.1.15.0/24 2914 6762 27648 3561 5511 6505 27782

What If I were to respond with a bgp notify (invalid as-path)
to 6762 when they send this route to 2914? Doesn't matter if they're
a customer or a peer, i may not want to get 3561 routes from you.

> Just thought I'd say "BCP38" again.

Router#conf t
Router(config)#interface customer0/1
Router(config)# ip verify unicast source reachable-via rx

- Jared

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

randy at psg

Aug 14, 2008, 8:03 AM

Post #13 of 35 (497 views)
Permalink

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

ok, i can not hold my tongue. sorry.

might there be a formally rigorous approach to this problem? we keep
having it. perhaps there is something solid and real we could do, as
opposed to temp hack after temp hack.

randy

christian at broknrobot

Aug 14, 2008, 8:34 AM

Post #14 of 35 (492 views)
Permalink

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

-----BEGIN PGP MESSAGE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: http://getfiregpg.org

owFdVAtsFFUUbRdaZRIoQfkUxLzwaRHWbgtIC0RA8YNfsEBAIJTZmbe7r52ZN857
s8tWgSIoUiqoAUUQlE8aAxYrgUpbqKCQEotSykeCKRLoR2qBQspXqN43uy3iJvub
ue/cc849dz7q2inGFbtZH3r58It/SbFFnZd5E9OGp2WkD89IHT1iZPoon9/0Z3Hd
fIFoeNLWKR+bsqVSA+lhRPwGtWRDwW4kM0SQLoeRQTkKyEGMeAAjPN/EFsFQgbJ0
yngWoj4UpjZSqUQMpwRNnYIUquu2QXg4JUWSvDZ3o1AgjELU1lQjmSNGdcwDxPAj
jeRg5KOWLmtaGFn4LZtYcF1SbMahyGIeE4tPDqwY4cyDuYI4jRCyZNWLqDcbK5wJ
vjJKjiBgHRs8WQJcJI4DoKcdEHn9JmLYChIFM0kiEfayheG0gUOoo042VOcWA0+Q
bQqS4qwbEY4IQ4qGZUsLS4zLHKsoql2hBjBVQK/zL4rlMS0aJCqACnqYcaEc9LN2
IpIOlWA2MTi8OyQJfcLAKDgxoJmmIUAD7gyY+B5oAzPA7P64/uuOW4rIZoxQA4Cx
6IVYwOYqDYE8gxPNwepgGgTbfATwHJ5ghuTHBrZALEM+onEYCgoRHkCWyeAopZok
MVnHyC9ItDvPUlIQaQ+ImHx0Ph1GOXMTlEGYZGAeolYOg1o3yhaWtJcTy0KeBwRF
eFEDOxn1wheFOgijLJmgzY0gdVAjQwcneoKYCA5TLGJyRxGSbfBN5mAJ0JQkAAIc
kc0ImOASySwkA2YMp+G+KnrCT2ww23IMg41A4CKoDRBTEsAq1rDfARaMDFv3OrNn
1LZgciIsQkuEIxGIgioxchzCUqSlQwWpxOcjiq2JDXIuEz7eSa0mW34A7bBMVmWT
R0j+b7uEUZCVaAcTU1PD0R6QJ4uLIz6qaTTkLD2kILqpkRgZFCkBCiEFRopsM1hw
UXKfpQIiqM+HfBbVkYItJ8IWtbnYLyVgEci7bEjwWu56rHNMrCsmPs4lHjsxUpfu
7U+p2pXdY75SFkw+sun0cy1fr8lM/nxYy8XqtsqB42d7PIfVYxcaugz+YntLQlLL
kJwjeyuaTTm9sltXd9PBM32nHm1a96d747WaksYt+/6+caX+6oTzK0mBJOUdLFnU
q/fD5rvo6MWGTzJLty8Z8PLc87HNavbapJrcn/tfdI2cdS63Z1v5zSmZcROWZyT0
Oj33UlvtvYlLdi3Ox+xkuPX4zpl3d1c9m/HmjTv6zazc1Y2XTzTUlI1uXVx6+OSq
4s+qV2zdv35m0TjfvarypfUHnnu6esGovWOK59zZU53Xv++oc0m329K7zPhDrs3O
rnlm4uC6hvz0D07FVaQeK/zuajCnZMSXiSvrfqnaOzmp6PrQ+cWDzu6c/cqR3AsD
4u9OOr79UM9riwt6lO7Zb259Ku/x0etKEwb3PacU9tbDtn0w0A03DfNuejVYeaso
Z/rYK7OW5GZe/SF/w+59q6f1KziwZmBqn22tg25nTGupO3PiypyU4K45aYGCIWWP
bk4oWVRc2Hxt16eb0/plNZsnvlk7fE1i2q1izyOX3rlZGfj2cn3F1NCCspcS/Xzc
6t/jY8sXxldU9yx86P15bzTX//jkoaE/uV6L37cjY9l7qQs7xbW2VpV5l45Z9XZt
UfeJeuPrfda6zuaFq3L92+zG8tRt10/N80+/x71jd1yy19ecbdqy7vtFckz6zBnm
6X+S5i37sFeP5/NPbazb0Gnhiid8v/72Lw==
=TITY
-----END PGP MESSAGE-----

On Thu, Aug 14, 2008 at 11:03 AM, Randy Bush <randy[at]psg.com> wrote:
> ok, i can not hold my tongue. sorry.
>
> might there be a formally rigorous approach to this problem? we keep
> having it. perhaps there is something solid and real we could do, as
> opposed to temp hack after temp hack.
>
> randy
>
>

christian at broknrobot

Aug 14, 2008, 8:37 AM

Post #15 of 35 (491 views)
Permalink

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

apologies for the encrypted email, pgp acting up..
---

pardon my ignorance, as i may not have the experience _most_ of you do
in the SP community..

but, why wouldn't something like formally requiring
customers/peers/transits/etc to have radb objects as a 'requirement'
for peering/customer bgp services

if you are a new customer and you sign up for bgp, it is clearly
stated in the contract, the customer/provider requesting this service
must maintain objects radb..

in the install process, if the customer does not have radb objects,
bgp sessions remain shutdown until the provider verifies this and
generates filters with rpsl tool

same goes for peers.. if you don't require contracts as not all
networks do, just require irr /radb objects, this one may be more of a
pain, but thats why we go to scripts and automation..

maybe some more work would need to be done to ensure proper ownership
and delegation of number resources in radb, but i dont think that
would be so difficult, would it?

if larger networks adapted to something like this, i think people
would start to follow, as they would have no choice because they
would be cut off from certain routes

christian

On Thu, Aug 14, 2008 at 11:34 AM, Christian Koch
<christian[at]broknrobot.com> wrote:
> -----BEGIN PGP MESSAGE-----
> Version: GnuPG v1.4.8 (Darwin)
> Comment: http://getfiregpg.org
>
> owFdVAtsFFUUbRdaZRIoQfkUxLzwaRHWbgtIC0RA8YNfsEBAIJTZmbe7r52ZN857
> s8tWgSIoUiqoAUUQlE8aAxYrgUpbqKCQEotSykeCKRLoR2qBQspXqN43uy3iJvub
> ue/cc849dz7q2inGFbtZH3r58It/SbFFnZd5E9OGp2WkD89IHT1iZPoon9/0Z3Hd
> fIFoeNLWKR+bsqVSA+lhRPwGtWRDwW4kM0SQLoeRQTkKyEGMeAAjPN/EFsFQgbJ0
> yngWoj4UpjZSqUQMpwRNnYIUquu2QXg4JUWSvDZ3o1AgjELU1lQjmSNGdcwDxPAj
> jeRg5KOWLmtaGFn4LZtYcF1SbMahyGIeE4tPDqwY4cyDuYI4jRCyZNWLqDcbK5wJ
> vjJKjiBgHRs8WQJcJI4DoKcdEHn9JmLYChIFM0kiEfayheG0gUOoo042VOcWA0+Q
> bQqS4qwbEY4IQ4qGZUsLS4zLHKsoql2hBjBVQK/zL4rlMS0aJCqACnqYcaEc9LN2
> IpIOlWA2MTi8OyQJfcLAKDgxoJmmIUAD7gyY+B5oAzPA7P64/uuOW4rIZoxQA4Cx
> 6IVYwOYqDYE8gxPNwepgGgTbfATwHJ5ghuTHBrZALEM+onEYCgoRHkCWyeAopZok
> MVnHyC9ItDvPUlIQaQ+ImHx0Ph1GOXMTlEGYZGAeolYOg1o3yhaWtJcTy0KeBwRF
> eFEDOxn1wheFOgijLJmgzY0gdVAjQwcneoKYCA5TLGJyRxGSbfBN5mAJ0JQkAAIc
> kc0ImOASySwkA2YMp+G+KnrCT2ww23IMg41A4CKoDRBTEsAq1rDfARaMDFv3OrNn
> 1LZgciIsQkuEIxGIgioxchzCUqSlQwWpxOcjiq2JDXIuEz7eSa0mW34A7bBMVmWT
> R0j+b7uEUZCVaAcTU1PD0R6QJ4uLIz6qaTTkLD2kILqpkRgZFCkBCiEFRopsM1hw
> UXKfpQIiqM+HfBbVkYItJ8IWtbnYLyVgEci7bEjwWu56rHNMrCsmPs4lHjsxUpfu
> 7U+p2pXdY75SFkw+sun0cy1fr8lM/nxYy8XqtsqB42d7PIfVYxcaugz+YntLQlLL
> kJwjeyuaTTm9sltXd9PBM32nHm1a96d747WaksYt+/6+caX+6oTzK0mBJOUdLFnU
> q/fD5rvo6MWGTzJLty8Z8PLc87HNavbapJrcn/tfdI2cdS63Z1v5zSmZcROWZyT0
> Oj33UlvtvYlLdi3Ox+xkuPX4zpl3d1c9m/HmjTv6zazc1Y2XTzTUlI1uXVx6+OSq
> 4s+qV2zdv35m0TjfvarypfUHnnu6esGovWOK59zZU53Xv++oc0m329K7zPhDrs3O
> rnlm4uC6hvz0D07FVaQeK/zuajCnZMSXiSvrfqnaOzmp6PrQ+cWDzu6c/cqR3AsD
> 4u9OOr79UM9riwt6lO7Zb259Ku/x0etKEwb3PacU9tbDtn0w0A03DfNuejVYeaso
> Z/rYK7OW5GZe/SF/w+59q6f1KziwZmBqn22tg25nTGupO3PiypyU4K45aYGCIWWP
> bk4oWVRc2Hxt16eb0/plNZsnvlk7fE1i2q1izyOX3rlZGfj2cn3F1NCCspcS/Xzc
> 6t/jY8sXxldU9yx86P15bzTX//jkoaE/uV6L37cjY9l7qQs7xbW2VpV5l45Z9XZt
> UfeJeuPrfda6zuaFq3L92+zG8tRt10/N80+/x71jd1yy19ecbdqy7vtFckz6zBnm
> 6X+S5i37sFeP5/NPbazb0Gnhiid8v/72Lw==
> =TITY
> -----END PGP MESSAGE-----
>
> On Thu, Aug 14, 2008 at 11:03 AM, Randy Bush <randy[at]psg.com> wrote:
>> ok, i can not hold my tongue. sorry.
>>
>> might there be a formally rigorous approach to this problem? we keep
>> having it. perhaps there is something solid and real we could do, as
>> opposed to temp hack after temp hack.
>>
>> randy
>>
>>
>

randy at psg

Aug 14, 2008, 9:02 AM

Post #16 of 35 (490 views)
Permalink

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

bottom line: the irr is a hack, not a formal solution.

rand

brett at the-watsons

Aug 14, 2008, 9:47 AM

Post #17 of 35 (492 views)
Permalink

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

On Aug 14, 2008, at 9:02 AM, Randy Bush wrote:

> bottom line: the irr is a hack, not a formal solution.

I don't think the IRR is so much a hack (it's a tool), but we're
lacking the process and infrastructure to vet/validate that a given
ASN is *authorized* to originate a prefix, and all of the policy bits
(which the IRR has if you use it) associated with which ASNs should
propagate the prefix, etc...

We're lacking the authority and delegation model that DNS has, I think?

-b

tkapela at gmail

Aug 14, 2008, 10:06 AM

Post #18 of 35 (492 views)
Permalink

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

On Thu, Aug 14, 2008 at 11:47 AM, brett watson <brett[at]the-watsons.org> wrote:

> We're lacking the authority and delegation model that DNS has, I think?

Depends who you ask. Some think applying the dns model to bgp (i.e.
within protocol) will ultimately place too great a burden on routing
hardware & associated 'state' infrastructure. I tend to agree with
that position. Perhaps the model we ought to be considering is
something more akin to an external mechanism that automated systems
(i.e. things to crank out prefix-lists/as-path lists) could draw from
during 'refresh' periods, solely dedicated to authorizing prefixes
against origin asn and/or as path (or name your $permutation_here).

I.e. if said new system were to fail, it'd be great if it didn't
affect routing in any way (we can live with a few days of stale lists,
I think).

Greene/Schiller, pipe up - this is your torch, right?

-Tk

drc at virtualized

Aug 14, 2008, 10:30 AM

Post #19 of 35 (491 views)
Permalink

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

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.

DNS:

IANA maintains "." ("dig @ns.iana.org . axfr") and delegates portions
of the namespace to top-level domain registries
Top-level domain registries delegate parts of their namespaces to
second-level domain registries (typically end users)

Address space:

IANA maintains the top-level address registry (http://www.iana.org/assignments/ipv4-address-space/
and http://www.iana.org/assignments/ipv6-unicast-address-
assignments) and delegates portions of the address space to RIRs.
RIRs delegate parts of their address space to LIRs/ISPs/end users.

Of course, ignoring layer 9 politics can be a bit challenging.

Regards,
-drc

david.freedman at uk

Aug 14, 2008, 11:21 AM

Post #20 of 35 (489 views)
Permalink

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

> but, why wouldn't something like formally requiring
> customers/peers/transits/etc to have radb objects as a 'requirement'
> for peering/customer bgp services
>

Step 1 : Enforce IRR for customers *now*.

Step 2 : Enforce trusted replacement for IRR when available

Step 3 : Profit

Not progressing to step 1 today because you think IRR isn't the best
solution is like not deploying IPv6 because you sat on your arse not
deploying it all these years and justify yourself by denouncing the
protocol on every mailing list and IRC channel at every available
opportunity.

Dave.

randy at psg

Aug 14, 2008, 11:22 AM

Post #21 of 35 (489 views)
Permalink

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

> Step 1 : Enforce IRR for customers *now*.
>
> Step 2 : Enforce trusted replacement for IRR when available
>
> Step 3 : Profit
>
> Not progressing to step 1 today because you think IRR isn't the best
> solution is like not deploying IPv6 because you sat on your arse not
> deploying it all these years and justify yourself by denouncing the
> protocol on every mailing list and IRC channel at every available
> opportunity.

[. sorry for preaching. i know you are a fellow choir member ]

for me it separates in to two things

o what i do with my routers today. as you know, i have been pushing
the irr and programmatic configuration since the mid '90s. that is
your step 1.

we have known how to do this for a decade. we don't need a bunch of
talk. we need to shut up and hack.

o what i do with my time. i don't have enough time to spend on both
hacks and rigor, so i concentrate on the design and implementation
of long-term formal and rigorous solutions, to which you allude in
step 2.

randy

brett at the-watsons

Aug 14, 2008, 11:32 AM

Post #22 of 35 (490 views)
Permalink

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

On Aug 14, 2008, at 11:21 AM, David Freedman wrote:

>
>> but, why wouldn't something like formally requiring
>> customers/peers/transits/etc to have radb objects as a 'requirement'
>> for peering/customer bgp services
>>
>
> Step 1 : Enforce IRR for customers *now*.

Right, but I think the bigger issue is not just that "data is in the
IRR" but rather "the data is there, and "some organization" has
validated that 1) the "owner" is authentic, 2) they own the prefixes
they entered, 3) they are authorized to originate the prefixes, and 4)
the policies they entered are valid and agreed to by the other parties."

We have to be able to *trust* the data in the IRR, which I assume is
one of the biggest impediments to being used by everyone: who's going
to validate all that data and how will they do it?

-b

jared at puck

Aug 14, 2008, 12:09 PM

Post #23 of 35 (491 views)
Permalink

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

On Thu, Aug 14, 2008 at 11:32:28AM -0700, brett watson wrote:
> On Aug 14, 2008, at 11:21 AM, David Freedman wrote:
>
>>
>>> but, why wouldn't something like formally requiring
>>> customers/peers/transits/etc to have radb objects as a 'requirement'
>>> for peering/customer bgp services
>>>
>>
>> Step 1 : Enforce IRR for customers *now*.
>
> Right, but I think the bigger issue is not just that "data is in the
> IRR" but rather "the data is there, and "some organization" has
> validated that 1) the "owner" is authentic, 2) they own the prefixes
> they entered, 3) they are authorized to originate the prefixes, and 4)
> the policies they entered are valid and agreed to by the other parties."
>
> We have to be able to *trust* the data in the IRR, which I assume is one
> of the biggest impediments to being used by everyone: who's going to
> validate all that data and how will they do it?

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.

There's many simple things that makes it seem like it's
an impossible task, but there's a saying, if you're not progressing
you're regressing. If the toolset is too complex or doesn't work,
what are YOU doing to make it better for you and/or your customers?

- jared

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

danny at tcb

Aug 14, 2008, 8:29 PM

Post #24 of 35 (469 views)
Permalink

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

On Aug 14, 2008, at 11:30 AM, David Conrad 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. 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.

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).

-danny

danny at tcb

Aug 14, 2008, 8:30 PM

Post #25 of 35 (469 views)
Permalink

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

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.

-danny

1 2

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact lists@gossamer-threads.com