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.
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 o
--- 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 pas
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 del
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 maintai
>>
>> 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 an
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
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
>opera
> 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
> 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. f
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
>infi
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 prefixe
> > 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
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 th
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
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 addre
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
le
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 sp
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
>>>
>>
>> S
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 n
> 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
> 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 progress
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 "."
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 & a
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 th
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
bottom line: the irr is a hack, not a formal solution.
rand
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 se
-BEGIN PGP MESSAGE-
Version: GnuPG v1.4.8 (Darwin)
Comment: http://getfiregpg.org
owFdVAtsFFUUbRdaZRIoQfkUxLzwaRHWbgtIC0RA8YNfsEBAIJTZmbe7r52ZN857
s8tWgSIoUiqoAUUQlE8aAxYrgUpbqKCQEotSykeCKRLoR2qBQspXqN43uy3iJvub
ue/cc849dz7q2inGFbtZH3r58It/SbFFnZd5E9OGp2WkD89IHT1iZPoon9/0Z3Hd
fIFoeNLWKR+bs
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
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 t
> > 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,
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
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 ;)
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 perfor
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, a
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
> Can't IANA give $10 stupidity tax
perhaps those of us in glass houses should not suggest a major throwing
of stones? :)
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 pee
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 th
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 h
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 2
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 ital
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.
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
45 matches
Mail list logo
