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

[Jared Mauch]

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 [EMAIL PROTECTED]
clue++;  | http://puck.nether.net/~jared/  My statements are only mine.

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

[Patrick W. Gilmore]

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 [EMAIL PROTECTED]
clue++;  | http://puck.nether.net/~jared/  My statements are  
only mine.

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

[Mikael Abrahamsson]

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 Abrahamssonemail: [EMAIL PROTECTED]

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

[Colin Alston]

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 $10 stupidity tax or revoke AS for people that do 
this?

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

[Jared Mauch]

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 [EMAIL PROTECTED]
clue++;  | http://puck.nether.net/~jared/  My statements are only mine.

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

[Sean Donelan]

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?

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

[Randy Bush]

> Can't IANA give $10 stupidity tax

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

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

[Patrick W. Gilmore]

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

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

[Jared Mauch]

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 [EMAIL PROTECTED]
clue++;  | http://puck.nether.net/~jared/  My statements are only mine.

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

[Colin Alston]

On 2008/08/13 11:11 PM Randy Bush wrote:

Can't IANA give $10 stupidity tax


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


Point taken ;)

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

[Jared Mauch]

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/242914 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 [EMAIL PROTECTED]
clue++;  | http://puck.nether.net/~jared/  My statements are only mine.

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

[Randy Bush]

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

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

[Christian Koch]

-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 <[EMAIL PROTECTED]> 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
>
>

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

[Christian Koch]

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
<[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
>>
>>
>

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

[Randy Bush]

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

rand

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

[brett watson]

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

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

[Anton Kapela]

On Thu, Aug 14, 2008 at 11:47 AM, brett watson <[EMAIL PROTECTED]> 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

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

[David Conrad]

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

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

[David Freedman]

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

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

[Randy Bush]

> 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

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

[brett watson]

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

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

[Jared Mauch]

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  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 [EMAIL PROTECTED]
clue++;  | http://puck.nether.net/~jared/  My statements are only mine.

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

[Danny McPherson]

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

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

[Danny McPherson]

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

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

[David Conrad]

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

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

[Danny McPherson]

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

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

[Joe Malcolm]

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

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

[David Freedman]

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

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

[Michael Smith]

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

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

[Jon Lewis]

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_

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

[Jared Mauch]

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 [EMAIL PROTECTED]
clue++;  | http://puck.nether.net/~jared/  My statements are only mine.

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

[David Barak]

--- On Sun, 8/17/08, Jared Mauch <[EMAIL PROTECTED]> 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


  

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

[Bill Nash]

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

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

[Deepak Jain]

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


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

route policy (Re: Public shaming list for ISPs announcing other ISPs IP space by mistake)

[Mikael Abrahamsson]

On Wed, 13 Aug 2008, Mikael Abrahamsson wrote:

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?


My thoughts on the prefix filtering issue would be that we need some kind 
of system that works along the same principles as DNSSEC and SPF, ie 
a holder of IP space can publish that they would like everybody to filter 
in a certain way for announcements for that perticular prefix, and then 
the other end can do so if they want to. This needs to be automatic and 
quick, ie a change in RADB policy should be reflected in the real world in 
minutes (preferrably) or hours (more realistically perhaps) and not in 
days or months.


This might already be in place, I don't know other than RIPE, but in RIPE 
you can register a route object with a certain IP space, and IP space can 
have multiple route objects. The thing here is that to implement this 
policy in IOS creates *huge* rulesets that are really cumbersome and 
cluttery. Also, people tend not to rebuild these very often, so for 
customer routes, doing a handover between ISPs when moving PI space might 
involve outages and days of limited connectivity. Also, change of policy 
doesn't isn't reflected unless a route is cleared (soft though) which 
involves re-hashing a lot of routes very often if filters are updated 
often.


I also think that the information in RADB doesn't really contain 
everything I would need in it, so it might need to be extended, but this 
is easier than getting a new framework into our routers (routing policy 
server?) that might work in near realtime. Is there work being done that 
could realistically be implemented anytime soon? Does benefit outweigh the 
potential catastrophies that might happen when rolling out and running 
such a system?


Perhaps it's too late for IPv4 in this aspect, but it might be feasable 
for IPv6? Fewer prefixes and (hopefully) no break-outs, would mean PA 
blocks could be filtered hard, and if larger ISPs do hard filtering based 
on RADB, ISPs getting into IPv6 would need to get their prefixes properly 
registered there before getting IPv6 working to any extent.


Anyhow, as people are continuing to use null routes to enforce regulatory 
demands (likely cause for the latest outages) this problem will most 
likely escalate.


This would also help with  
problem I guess.


--
Mikael Abrahamssonemail: [EMAIL PROTECTED]

Re: route policy (Re: Public shaming list for ISPs announcing other ISPs IP space by mistake)

[Jared Mauch]

On Thu, Aug 14, 2008 at 08:03:28AM +0200, Mikael Abrahamsson wrote:
> On Wed, 13 Aug 2008, Mikael Abrahamsson wrote:
>
>> 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?
>
> My thoughts on the prefix filtering issue would be that we need some kind 
> of system that works along the same principles as DNSSEC and SPF, ie a 
> holder of IP space can publish that they would like everybody to filter  
> in a certain way for announcements for that perticular prefix, and then  
> the other end can do so if they want to. This needs to be automatic and  
> quick, ie a change in RADB policy should be reflected in the real world 
> in minutes (preferrably) or hours (more realistically perhaps) and not in 
> days or months.

There was an idea years ago about utilizing a domain (rdi.int) for
this.

eg:

dig any 267.rdi.int.

> This might already be in place, I don't know other than RIPE, but in RIPE 
> you can register a route object with a certain IP space, and IP space can 
> have multiple route objects. The thing here is that to implement this  

Herein is the value, the RIR (RIPE) is also the holder of the policy.
With ARIN, this is not the case, there is RADB and a number of other RR's
that are out there for varying reasons, some personal and some business.

> policy in IOS creates *huge* rulesets that are really cumbersome and  
> cluttery. Also, people tend not to rebuild these very often, so for  
> customer routes, doing a handover between ISPs when moving PI space might 
> involve outages and days of limited connectivity. Also, change of policy  
> doesn't isn't reflected unless a route is cleared (soft though) which  
> involves re-hashing a lot of routes very often if filters are updated  
> often.

I think in this web 2.0 world, everything you're speaking of
can be a challenge but not be impossible.  The problem I see is there are
no good tools.  Take http://prefix.pch.net/ for example.

This can help you audit the routes that are going to be placed
in a prefix-list.  How do you integrate something like this into your
business policy?  Have customers submit a web form for their routes?  It's
easy when your customer is AS267, but what if your customer is something
larger like telstra?

> Perhaps it's too late for IPv4 in this aspect, but it might be feasable  
> for IPv6? Fewer prefixes and (hopefully) no break-outs, would mean PA  

I think it's a matter of having a semi-uniform industry policy
that is generally agreeable.  I don't want to see the ANS-days case where
you could not route without RADB and some fancy scripts probing their bay
networks devices with snmp sets.

But I do agree that we need a better toolset built.  Now
the question is, who can/will do this?  How can it be shared?

If I can make this backend uglyness called "RADB/irrd" invisible
to my customers, will that help?

> blocks could be filtered hard, and if larger ISPs do hard filtering based 
> on RADB, ISPs getting into IPv6 would need to get their prefixes properly 
> registered there before getting IPv6 working to any extent.
>
> Anyhow, as people are continuing to use null routes to enforce regulatory 
> demands (likely cause for the latest outages) this problem will most  
> likely escalate.
>
> This would also help with  
> problem I guess.

Yeah, the challenge here is those that are unwilling to take
action threaten the entire industry as it only takes a few bad actors
to disrupt the network currently, and if you do it correctly, who is
going to trust the infrastructure that we operate?

- Jared

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

Re: route policy (Re: Public shaming list for ISPs announcing other ISPs IP space by mistake)

[Brandon Butterworth]

> > My thoughts on the prefix filtering issue would be that we need some kind 
> > of system that works along the same principles as DNSSEC and SPF, ie a 
> > holder of IP space can publish that they would like everybody to filter  
> > in a certain way for announcements for that perticular prefix, and then  
> > the other end can do so if they want to. 

http://blog.wired.com/27bstroke6/2008/08/experts-accuse.html

"The Internet Assigned Numbers Authority -- which coordinates the
internet -- has been prototyping a system to sign the root-zone file
for the last year, but they can't do the same for the internet's top
servers without approval from the Department of Commerce"

Sounds like some work that could be recycled (and save being wasted
if it's decided to have Verisign do the dnssec instead)

>   Herein is the value, the RIR (RIPE) is also the holder of the policy.
> With ARIN, this is not the case, there is RADB and a number of other RR's
> that are out there for varying reasons, some personal and some business.

Yes, RIPE rock. Please make it all not suck.

>   I think in this web 2.0 world, everything you're speaking of
> can be a challenge but not be impossible.  The problem I see is there are
> no good tools.

In 2.0 world someone would make routetubebookparty and sell out to Google
for millions, VCs line up here (the owner is as close to owning the
internet as anyone)

>   This can help you audit the routes that are going to be placed
> in a prefix-list.  How do you integrate something like this into your
> business policy?  Have customers submit a web form for their routes?  It's
> easy when your customer is AS267, but what if your customer is something
> larger like telstra?

probably signed lumps of XML, people can make it however they want

>   If I can make this backend uglyness called "RADB/irrd" invisible
> to my customers, will that help?

I presume this would replace all the old stuff

brandon

Re: route policy (Re: Public shaming list for ISPs announcing other ISPs IP space by mistake)

[David Conrad]

Hi,

On Aug 14, 2008, at 6:38 AM, Brandon Butterworth wrote:

http://blog.wired.com/27bstroke6/2008/08/experts-accuse.html

"The Internet Assigned Numbers Authority -- which coordinates the
internet -- has been prototyping a system to sign the root-zone file
for the last year, but they can't do the same for the internet's top
servers without approval from the Department of Commerce"

Sounds like some work that could be recycled (and save being wasted
if it's decided to have Verisign do the dnssec instead)


Just to be clear, the stuff at https://ns.iana.org/dnssec/status.html  
will be used for more than the root, e.g., .ARPA, children of .ARPA,  
IANA.ORG, etc., regardless of who ends up signing the root.


Regards,
-drc

Re: route policy (Re: Public shaming list for ISPs announcing other ISPs IP space by mistake)

[Pekka Savola]

On Thu, 14 Aug 2008, Brandon Butterworth wrote:

Herein is the value, the RIR (RIPE) is also the holder of the policy.
With ARIN, this is not the case, there is RADB and a number of other RR's
that are out there for varying reasons, some personal and some business.


Yes, RIPE rock. Please make it all not suck.


Unfortunately, RIPE DB will allow anyone to add any route objects for 
prefixes that are not under the RIPE management :-(.  For example, 
anyone could add route objects for most of DNS root server prefixes.


For those prefixes that are managed by RIPE, it's good.  But the above 
feature dilutes the trustworthiness of RIPE DB slightly...


--
Pekka Savola "You each name yourselves king, yet the
Netcore Oykingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

Re: route policy (Re: Public shaming list for ISPs announcing other ISPs IP space by mistake)

[Brandon Butterworth]

> > Yes, RIPE rock. Please make it all not suck.
> 
> Unfortunately, RIPE DB will allow anyone to add any route objects for 
> prefixes that are not under the RIPE management :-(.  For example, 
> anyone could add route objects for most of DNS root server prefixes.

Little details get used to avoid fixing bigger problems, see the
please stop sucking bit.

If there was somewhere else the aliens had to be registered then they
could be dropped from RIPE

brandon

Re: route policy (Re: Public shaming list for ISPs announcing other ISPs IP space by mistake)

[Pekka Savola]

On Fri, 15 Aug 2008, Brandon Butterworth wrote:

Yes, RIPE rock. Please make it all not suck.

Unfortunately, RIPE DB will allow anyone to add any route objects for
prefixes that are not under the RIPE management :-(.  For example,
anyone could add route objects for most of DNS root server prefixes.


Little details get used to avoid fixing bigger problems, see the
please stop sucking bit.

If there was somewhere else the aliens had to be registered then they
could be dropped from RIPE


I'm not sure I follow.  Many of these aliens are in fact registered in 
RADB, so AFAICS, there that is no reason for them to be registered in 
RIPE DB.


On the other hand, some want to register them in RIPE DB because some 
operators just want to use RIPE DB e.g. for data consistency etc. 
reasons.  But putting data without practically any authorization in 
RIPE DB doesn't seem to be a useful model in the long run.


--
Pekka Savola "You each name yourselves king, yet the
Netcore Oykingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

Re: route policy (Re: Public shaming list for ISPs announcing other ISPs IP space by mistake)

[Brandon Butterworth]

> I'm not sure I follow. 

I agreed with you.

> Many of these aliens are in fact registered in 
> RADB, so AFAICS, there that is no reason for them to be registered in 
> RIPE DB.
>
> On the other hand, some want to register them in RIPE DB because some 
> operators just want to use RIPE DB e.g. for data consistency etc. 
> reasons.  But putting data without practically any authorization in 
> RIPE DB doesn't seem to be a useful model in the long run.

As the reason they should not be in RIPE is RIPE doesn't hold the
ownership data I suggested they move to a RIPE alike
which does hold their ownership, afaik RADB doesn't

Seems pretty simple, RIPE delegates the space and maintains owners so
is a natural place for their owner to record their allowed use. So ARIN
and others need to do the same, thus all space is covered and then
can me munged into whatever will enforce the use be it router based
signed advertisements or an out of band system that applies controls
to the routers directly or via a humanoid.

brandon

Re: route policy (Re: Public shaming list for ISPs announcing other ISPs IP space by mistake)

[Randy Bush]

> I'm not sure I follow.  Many of these aliens are in fact registered in
> RADB, so AFAICS, there that is no reason for them to be registered in
> RIPE DB.

when ripe will not mirror the irr segment in which they do register.

randy

Re: route policy (Re: Public shaming list for ISPs announcing other ISPs IP space by mistake)

[Sandy Murphy]

On Fri, 15 Aug 2008 13:56:09 +0300 (EEST), Pekka Savola wrote:

>I'm not sure I follow.  Many of these aliens are in fact registered in 
>RADB, so AFAICS, there that is no reason for them to be registered in 
>RIPE DB.
>
>On the other hand, some want to register them in RIPE DB because some 
>operators just want to use RIPE DB e.g. for data consistency etc. 
>reasons.  But putting data without practically any authorization in 
>RIPE DB doesn't seem to be a useful model in the long run.

As I understand things, the "without practically any authorization"
model holds for *everything* registered in the RADB.  Right?


If that's not a useful model for the RIPE DB, what about the RADB?

--Sandy

P.S.  Not to pick on the RADB.  Most IRRs, as I understand it,
enforce little in the way of authorization.  It's just that the RADB
was mentioned.