Re: 69/8...this sucks -- Centralizing filtering..

[Shane Kerr]

[ apologies for the long post ]

On 2003-03-11 19:57:04 +, [EMAIL PROTECTED] wrote:
> 
> Also, on a side rant hereWhy do all the RIR's have to give out
> whois data in different, incompatible, referal-breaking formats?

The reason for the different formats is partly historical, and
partially a result of the fundamental differences between the RIR's.

The historical reason is that each RIR has a different origin, and the
databases and Whois software comes from that origin.  The RIPE NCC
started with nothing, evolved to RIPE-181, then RPSL, and is now
moving to RPSLng + extensions.  APNIC adopted RIPE NCC software, and
is very nearly compatible.  ARIN's database was inherited from the
InterNIC, and has since evolved into a new, organisation-based model.
I believe LACNIC's database is inherited from the Brazil domain name
registry, so it uses that format (this is the one I am least familiar
with - so I may be in error).

The formats remain different because the RIR's have evolved their
databases to solve problems that are most important in their regions.
For instance, ARIN has chosen a model that reflects registration in a
straightforward way, whereas RPSL is useful for operators wanting to
document policy.

> The next step in my work once my ping sweep is complete (looks like
> that'll be today) is going to be to take a list of what looks like
> it'll be ~1000 IPs and generate a list of the unique networks that
> are broken.  To do this, it'd be nice if there were some key I could
> get from whois, store in a column, select a unique set from, then
> reuse to lookup POCs from whois, and send off the emails.
> 
> registro.br and LACNIC entries start with inetnum: using what I'll
> call brief CIDR, i.e.
> inetnum:  200.198.128/19
> 
> APNIC and RIPE entries start with inetnum:, but use range format.
> i.e.
> inetnum:  203.145.160.0 - 203.145.191.255
> 
> ARIN entries include fields like
> NetRange:   128.63.0.0 - 128.63.255.255 
> CIDR:   128.63.0.0/16 
> 
> The APNIC and RIPE NetRange/inetnum fields are easy enough to deal
> with, but send a whois request for 200.198.128/19 to whois.arin.net
> and you get "No match found".  Send it as 200.198.128, and
> whois.arin.net will refer you to whois.lacnic.net.  Send it to
> whois.lacnic.net as 200.198.128, and you get "Invalid IP or CIDR
> block".
> 
> I realize programming around all this is by no means an
> insurmountable task, but it is a pain.  It'd be ideal if there were
> a unique key field, say Net-ID included in the whois output from all
> the RIR whois servers that could be used to identify the network and
> the appropriate whois server.  i.e.
> 
> NetID: [EMAIL PROTECTED]

In the current situation, users must query up to 4 servers
(whois.apnic.net, whois.arin.net, whois.lacnic.net, and
whois.ripe.net) to find information about an IP address, in some cases
without any way of knowing which RIR has allocated the space.  Each
RIR parses queries and presents results in a different format.

This is not ideal - to put it mildly.

The good news is that we are aware of the problem, and not sitting on
our laurels.  The eventual goal is to answer a query for IP or AS
space at each RIR, using the "native" query and result format, and get
the best possible answer.  We've completed part of the mapping between 
schemas, and after that is finished it's just a matter of writing some
software.  ;)


There is also a technology that might come out of the CRISP IETF
working group:

http://www.ietf.org/html.charters/crisp-charter.html

We (the RIR's) are tracking this work.  Since this involves an actual
protocol difference from our beloved Whois protocol, if it is adopted
it will certainly take longer to adopt.  But there is no reason the
two protocols can't co-exist and complement each other.


If you have any interest in participating in RIPE Database-related
issues, please feel free to join the mailing list:

http://www.ripe.net/ripe/wg/db/index.html

We (meaning the RIPE NCC, especially the database group) take a lot of
our direction from the DB working group.  It's open to all.

-- 
Shane Kerr
Database Group Manager
RIPE NCC

Re: Put part of Google on 69/8 (was Re: 69/8...this sucks)

[Owen DeLong]

It's probably harder for anyone on this list to take BandyRush seriously
than the other posters in question.
:-)

Owen

--On Wednesday, March 12, 2003 22:01 -0500 [EMAIL PROTECTED] wrote:

On Wed, 12 Mar 2003 21:27:51 EST, Andy Dills <[EMAIL PROTECTED]>  said:

Not be offended if somebody didn't know my gender?
Fortunately, none of the simians on the list have objected to being
classified as 'banana eaters' ;)

Re: Put part of Google on 69/8 (was Re: 69/8...this sucks)

[Owen DeLong]

Can you and he please take the gender debate off-list?

Thanks,

Owen

--On Wednesday, March 12, 2003 17:36 -0800 JC Dill <[EMAIL PROTECTED]> 
wrote:

Miss Rothschild wrote:
On 2003-03-11-21:01:00, JC Dill <[EMAIL PROTECTED]> wrote:
(Note to Mr. Dill, this is not intended to pick on you specifically,
it's just a convenient place to butt in)
Ahem.  It's _MS._ Dill, thank you.
Please post with a gender-specific name if you want to take offense
when mis-identified.
It is offensive to many people (both male and female) when someone
automatically assumes that an "unknown" person is male.  Especially since:
  Females aged 2 and up accounted for 50.4 percent of U.S.
  Internet users in May, edging out their male counterparts,
  according to New York-based Internet research firms Media
  Metrix and Jupiter Communications
  [...]

  At Dulles-based America Online Inc., the nation's biggest
  online services company, 52 percent of its 23.2 million
  subscribers worldwide are women.
  [...]

  Some scholars believe the new-found gender parity is just
  another reflection of the social changes of the past few
  decades, when men and women found themselves on more equal
  footing. "That distinction has disappeared, and it is a
  huge revolution in society," says Michael Maccoby, an
  anthropologist and psychoanalyst.


It is doubly offensive when you opine that I have an obligation to
create and use [1] a gender-specific name solely to make things easier
for you and other sexist jerks^W men^W^W induh^H^Hividuals.  What would
you do if my name was Pat or Chris?  Or if YOUR name was Pat or Chris?
Sure you can.  You just need content unimportant enough that no one
(the end users on a network that is still blocking 69/8, AND the
networks that put up the sacrificial target host on a 69/8 IP) is
truly hurt if the connection fails, but important enough that the
failure will lead to the broken networks being fixed and clue being
distributed.
How do I configure my routers and web servers for that?
ObNanog:  Assuming you don't work at Google, if you aren't blocking 69/8
then your network will not be harmed in any way by the implementation of
this proposal.  Thus you need to do nothing special at all.  OTOH, if
you are improperly blocking 69/8, obviously you need to fix that when
you configure your "routers and web servers" (sic).
I'm suggesting that Google explain why they are doing this on a page
linked off their homepage.  If this is done, people ARE going to
notice, and ARE going to find out why.  When it is widely
publicised, it WILL be noticed even more.
Last I checked, Google was a for-profit business, not a charity house.
I'm not sure how doing something that will make them look dumb, and
cost them in valuable ad revenue, etc is in their best interests.
Perhaps you could fill me in here.
If you don't work at Google, then this is none of your concern.

p.s.  Please don't cc me on replies, or on replies to replies, etc.
We have seen time after time that the propagation delays on the NANOG
list, most likely resultant from sub-optimal postfix/majordomo
configuration and/or an overloaded box, make it unsuitable for
realtime communications.  With this in mind, I have taken the liberty
of cc'ing you in my reply, despite your request to the contrary.
I have no urgent need for your reply, I am happy to wait until I receive
email from the list.  I politely made my request very clear, both in my
headers and in the body of my email.  You responded by taking extra
steps to do the exact opposite of what I politely requested.  Then you
have the gall to flame me for my polite request.  This was very rude of
you.
If duplicate messages cluttering your inbox are causing you much
grief,
They are just an annoyance, as is being mistakenly referred to as a
male.  Since you seem to think that these annoyances must be accepted as
part of participating on the net, be prepared to be referred to as Miss
Rothschild by me, now and in the future.  What goes around comes around,
girlfriend.
jc

[1]  JC Dill is my real name.  It is the name on my passport and other
official documents.

Re: 69/8...this sucks

[Niels Bakker]

* [EMAIL PROTECTED] (Charles Sprickman) [Wed 12 Mar 2003, 00:22 CET]:
> Seriously though, somewhere there is a popular site that is non-profit in
> nature that would trade say a month of free access for the hassle of being
> put into a widely-blocked block.

Apparently hack.co.za has recently been resurrected; it's within
69.3/16, owned by Cogent. (Fugly traceroute, too.) I'm sure they'll
appreciate your offer of another mirror!

Regards,


-- Niels.

-- 
subvertise me

Re: Put part of Google on 69/8 (was Re: 69/8...this sucks)

[Valdis . Kletnieks]

On Wed, 12 Mar 2003 21:27:51 EST, Andy Dills <[EMAIL PROTECTED]>  said:

> Not be offended if somebody didn't know my gender?

Fortunately, none of the simians on the list have objected to being
classified as 'banana eaters' ;)


pgp0.pgp
Description: PGP signature

RE: Put part of Google on 69/8 (was Re: 69/8...this sucks)

[Vivien M.]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
> Behalf Of Jack Bates
> Sent: March 12, 2003 9:29 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Put part of Google on 69/8 (was Re: 69/8...this sucks)
> 
> 
> 
> From: "Vivien M."
> 
> > I've had the opposite problem (people thinking I'm female, when I'm
> not...),
> > and it can get quite annoying, I agree.
> >
> Is this a pick up list? Find the guy or gal of your dreams 
> that can think too? I figure that you either earn people's 
> respect or admiration or you don't. Mailing-list sex hasn't 
> ever been an interest of mine. :)

Well, I've gotten [non-serious, I hope] marriage proposals from guys on
Usenet before...

I wouldn't go as far as Ms. Dill and saying it's offensive, but it is
annoying that whenever you call some company and they look you up in their
database, they say "ma'am" instead of "sir" (or, in Ms. Dill's case,
presumably the opposite), and whenever you start posting in a new forum
(Usenet, mailing list, etc), you inevitably have to correct the first person
who refers to you with the wrong gender pronouns, etc, which is always
embarassing for both you and the person who made the mistake...

That said, this is getting horribly off-topic... though perhaps we should
ask whether sex mailing lists are hosted on networks that filter 69/8? :)
(Yes, I know, that wasn't a good attempt at being on topic...)

Vivien
-- 
(Mr.) Vivien M.
[EMAIL PROTECTED]
Assistant System Administrator
Dynamic DNS Network Services
http://www.dyndns.org/ 

Re: Put part of Google on 69/8 (was Re: 69/8...this sucks)

[Jack Bates]

From: "Vivien M."

> I've had the opposite problem (people thinking I'm female, when I'm
not...),
> and it can get quite annoying, I agree.
>
Is this a pick up list? Find the guy or gal of your dreams that can think
too? I figure that you either earn people's respect or admiration or you
don't. Mailing-list sex hasn't ever been an interest of mine. :)

-Jack

Re: Put part of Google on 69/8 (was Re: 69/8...this sucks)

[Andy Dills]

On Wed, 12 Mar 2003, JC Dill wrote:

> It is offensive to many people (both male and female) when someone
> automatically assumes that an "unknown" person is male.  Especially since:
>
>   Females aged 2 and up accounted for 50.4 percent of U.S.
>   Internet users in May, edging out their male counterparts,
>   according to New York-based Internet research firms Media
>   Metrix and Jupiter Communications
>
>   [...]
>
>   At Dulles-based America Online Inc., the nation's biggest
>   online services company, 52 percent of its 23.2 million
>   subscribers worldwide are women.
>
>   [...]
>
>   Some scholars believe the new-found gender parity is just
>   another reflection of the social changes of the past few
>   decades, when men and women found themselves on more equal
>   footing. "That distinction has disappeared, and it is a
>   huge revolution in society," says Michael Maccoby, an
>   anthropologist and psychoanalyst.

Got any statistics for the actual demographic in question (NANOG)?
Probably not. But if you did, they'd support the assumption that an
unknown person is likely male, with extreme statistical significance.

> It is doubly offensive when you opine that I have an obligation to
> create and use [1] a gender-specific name solely to make things easier
> for you and other sexist jerks^W men^W^W induh^H^Hividuals.  What would
> you do if my name was Pat or Chris?  Or if YOUR name was Pat or Chris?

Not be offended if somebody didn't know my gender?

> >>p.s.  Please don't cc me on replies, or on replies to replies, etc.
> >
> > We have seen time after time that the propagation delays on the NANOG
> > list, most likely resultant from sub-optimal postfix/majordomo
> > configuration and/or an overloaded box, make it unsuitable for
> > realtime communications.  With this in mind, I have taken the liberty
> > of cc'ing you in my reply, despite your request to the contrary.
>
> I have no urgent need for your reply, I am happy to wait until I receive
> email from the list.  I politely made my request very clear, both in my
> headers and in the body of my email.  You responded by taking extra
> steps to do the exact opposite of what I politely requested.  Then you
> have the gall to flame me for my polite request.  This was very rude of
> you.

Well, as somebody who rudely runs a mailing list, you should be used to
standard mailing list operating procedure.

> > If duplicate messages cluttering your inbox are causing you much
> > grief,
>
> They are just an annoyance, as is being mistakenly referred to as a
> male.  Since you seem to think that these annoyances must be accepted as
> part of participating on the net, be prepared to be referred to as Miss
> Rothschild by me, now and in the future.  What goes around comes around,
> girlfriend.

Except, you know he's male, and he didn't know you were female. So, you
end up looking like a petty whiner who siezed upon the ability to be
offended, even when there was no cause for it.

Get over it. If my name was Andrea, I wouldn't be pissed if people assumed
I was a woman. I'd correct them and move on.

Andy


Andy Dills  301-682-9972
Xecunet, LLCwww.xecu.net

Dialup * Webhosting * E-Commerce * High-Speed Access

RE: Put part of Google on 69/8 (was Re: 69/8...this sucks)

[Vivien M.]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
> Behalf Of JC Dill
> Sent: March 12, 2003 8:37 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Put part of Google on 69/8 (was Re: 69/8...this sucks)
> 
> It is offensive to many people (both male and female) when 
> someone automatically assumes that an "unknown" person is 
> male.  Especially since:
[snip]
> It is doubly offensive when you opine that I have an 
> obligation to create and use [1] a gender-specific name 
> solely to make things easier for you and other sexist jerks^W 
> men^W^W induh^H^Hividuals.  What would you do if my name was 
> Pat or Chris?  Or if YOUR name was Pat or Chris?

I've had the opposite problem (people thinking I'm female, when I'm not...),
and it can get quite annoying, I agree.

I wonder if perhaps a solution would be doing something I saw a gentleman
from China, IIRC, do on this list quite a while ago. He had added (Mr.) to
his .sig to make it easy for people to figure out his gender. Perhaps this
would be an easyish way to somewhat-subtly warn people of the correct
gender?

Vivien
-- 
(Mr.) Vivien M.
[EMAIL PROTECTED]
Assistant System Administrator
Dynamic DNS Network Services
http://www.dyndns.org/ 

Re: Put part of Google on 69/8 (was Re: 69/8...this sucks)

[JC Dill]

Miss Rothschild wrote:
On 2003-03-11-21:01:00, JC Dill <[EMAIL PROTECTED]> wrote:
(Note to Mr. Dill, this is not intended to pick on you specifically, 
it's just a convenient place to butt in)
Ahem.  It's _MS._ Dill, thank you.
Please post with a gender-specific name if you want to take offense
when mis-identified.
It is offensive to many people (both male and female) when someone
automatically assumes that an "unknown" person is male.  Especially since:
 Females aged 2 and up accounted for 50.4 percent of U.S.
 Internet users in May, edging out their male counterparts,
 according to New York-based Internet research firms Media
 Metrix and Jupiter Communications
 [...]

 At Dulles-based America Online Inc., the nation's biggest
 online services company, 52 percent of its 23.2 million
 subscribers worldwide are women.
 [...]

 Some scholars believe the new-found gender parity is just
 another reflection of the social changes of the past few
 decades, when men and women found themselves on more equal
 footing. "That distinction has disappeared, and it is a
 huge revolution in society," says Michael Maccoby, an
 anthropologist and psychoanalyst.


It is doubly offensive when you opine that I have an obligation to
create and use [1] a gender-specific name solely to make things easier
for you and other sexist jerks^W men^W^W induh^H^Hividuals.  What would
you do if my name was Pat or Chris?  Or if YOUR name was Pat or Chris?
Sure you can.  You just need content unimportant enough that no one
(the end users on a network that is still blocking 69/8, AND the
networks that put up the sacrificial target host on a 69/8 IP) is
truly hurt if the connection fails, but important enough that the
failure will lead to the broken networks being fixed and clue being
distributed.
How do I configure my routers and web servers for that?
ObNanog:  Assuming you don't work at Google, if you aren't blocking 69/8
then your network will not be harmed in any way by the implementation of
this proposal.  Thus you need to do nothing special at all.  OTOH, if
you are improperly blocking 69/8, obviously you need to fix that when
you configure your "routers and web servers" (sic).
I'm suggesting that Google explain why they are doing this on a page
linked off their homepage.  If this is done, people ARE going to
notice, and ARE going to find out why.  When it is widely
publicised, it WILL be noticed even more.
Last I checked, Google was a for-profit business, not a charity house.
I'm not sure how doing something that will make them look dumb, and
cost them in valuable ad revenue, etc is in their best interests.
Perhaps you could fill me in here.
If you don't work at Google, then this is none of your concern.

p.s.  Please don't cc me on replies, or on replies to replies, etc.
We have seen time after time that the propagation delays on the NANOG
list, most likely resultant from sub-optimal postfix/majordomo
configuration and/or an overloaded box, make it unsuitable for
realtime communications.  With this in mind, I have taken the liberty
of cc'ing you in my reply, despite your request to the contrary.
I have no urgent need for your reply, I am happy to wait until I receive
email from the list.  I politely made my request very clear, both in my
headers and in the body of my email.  You responded by taking extra
steps to do the exact opposite of what I politely requested.  Then you
have the gall to flame me for my polite request.  This was very rude of
you.
If duplicate messages cluttering your inbox are causing you much
grief, 
They are just an annoyance, as is being mistakenly referred to as a
male.  Since you seem to think that these annoyances must be accepted as
part of participating on the net, be prepared to be referred to as Miss
Rothschild by me, now and in the future.  What goes around comes around,
girlfriend.
jc

[1]  JC Dill is my real name.  It is the name on my passport and other
official documents.

Re: 69/8...this sucks

[Andy Dills]

On Wed, 12 Mar 2003, Peter E. Fry wrote:

> Andy Dills wrote:
> >
> > Sure. If the NSPs would just filter the bogon routes, nobody else would
> > have to bother. Why is it that they don't?
>
>   Filter (public, private and transit) peers or customers...?  Or
> themselves?

Yes.

Andy


Andy Dills  301-682-9972
Xecunet, LLCwww.xecu.net

Dialup * Webhosting * E-Commerce * High-Speed Access

Re: 69/8...this sucks

[Peter E. Fry]

Andy Dills wrote:
> 
> On Wed, 12 Mar 2003, Randy Bush wrote:
>
> > maybe we should not encourage those who do not have time, talent,
> > and inclination to install bogon route filters that need to be
> > maintained?
> 
> Sure. If the NSPs would just filter the bogon routes, nobody else would
> have to bother. Why is it that they don't?

  Filter (public, private and transit) peers or customers...?  Or
themselves?
  I've had a few customers spontaneously (ahem) come up with remarkably
"Rob Thomas" configs (if any noun can be verbed, can any name be
adjectived?) -- I usually convince them to tone down the filters a bit. 
The funny ones are those who've signed up for a partial table or
default.  Then again, I suppose you can't be too careful.

Peter E. Fry

Re: 69/8...this sucks

[Andy Dills]

On Wed, 12 Mar 2003, Randy Bush wrote:

>
> > The problem is small mom&pop ISPs and companies where the NOC and the
> > senior secretary share a desk, and possibly a name.
>
> maybe we should not encourage those who do not have time, talent,
> and inclination to install bogon route filters that need to be
> maintained?

Sure. If the NSPs would just filter the bogon routes, nobody else would
have to bother. Why is it that they don't?

Andy


Andy Dills  301-682-9972
Xecunet, LLCwww.xecu.net

Dialup * Webhosting * E-Commerce * High-Speed Access

Re: 69/8...this sucks

[Randy Bush]

> The problem is small mom&pop ISPs and companies where the NOC and the
> senior secretary share a desk, and possibly a name.

maybe we should not encourage those who do not have time, talent,
and inclination to install bogon route filters that need to be
maintained?

Re: 69/8...this sucks

[Valdis . Kletnieks]

On Tue, 11 Mar 2003 18:22:14 EST, Charles Sprickman said:

> Hey, I already came up with the slashdot idea.

An excellent choice - the average slashdot reader would resent any implication
that they were using a substandard clueless ISP, and would complain in a most
vociferous manner.. ;)


pgp0.pgp
Description: PGP signature

Re: 69/8...this sucks

[Valdis . Kletnieks]

On Tue, 11 Mar 2003 14:58:10 MST, "Alec H. Peterson" said:

> How about if we all chip in to hire a bunch of out of work consultants to 
> fly to the NOCs of the various backbones who are being boneheaded to 
> educate them with a clue-by-four?

I suspect the problem isn't the backbones that have a NOC.

The problem is small mom&pop ISPs and companies where the NOC and the
senior secretary share a desk, and possibly a name.


pgp0.pgp
Description: PGP signature

Re: Put part of Google on 69/8 (was Re: 69/8...this sucks)

[Tim Thorne]

JC Dill <[EMAIL PROTECTED]> wrote:

>Sure you can.  You just need content unimportant enough that no one (the 
>end users on a network that is still blocking 69/8, AND the networks 
>that put up the sacrificial target host on a 69/8 IP) is truly hurt if 
>the connection fails, but important enough that the failure will lead to 
>the broken networks being fixed and clue being distributed.

With that in mind, perhaps IANA and ICANN can be persuaded to renumber
into new space every time some is allocated? Or if you enjoy helpdesk
staff abused by end users in their thousands, encourage the use of a
.sex tld and house the root in new space.

TT

RE: 69/8...this sucks

[Owen DeLong]

I'm trying to get some time to actually put it in a router and test, but
I believe there is a way to get similar functionality through a combination
of route-map entries.  When I have actual router config (I'll be testing on
Cisco, but if anyone want's to provide me a Juniper testbed, I'll be happy
to try that too), I'll post it.  If I can't, I'll post a public apology
and start beating on vendors to make it possible. :-)
Owen

--On Wednesday, March 12, 2003 11:41 PM +1100 David Luyer <[EMAIL PROTECTED]> 
wrote:

Stephen J Wilcox wrote:
On Wed, 12 Mar 2003, David Luyer wrote:
> Iljitsch van Beijnum wrote:
> > On Tue, 11 Mar 2003, Owen DeLong wrote:
> >
> > > In short, it doesn't.  Longer answer, if the ISP configures
> > > his router correctly, he can actually refuse to accept
> > > advertisements from other sessions that are longer versions
> > > of prefixes received through this session.
> >
> > How???
>
> There is a technically possible (but rather twisted) way you
> could not use the adverts, but not a way to refuse receiving
> them that I know of.
I think youre mixing up with ingress filtering by prefix list
which you can
specify prefix length on and hence ignore longer (or smaller) matches.
The example I provided achieved both ingress and egress filtering
based on routes in a bogon BGP feed, in a way which would even
block when a more-specific route is in the provider's BGP table.
While it didn't actually prevent the routes being in the routing
table (as I said, it doesn't provide a way to stop receiving them),
it does prevent traffic from and to the bogon locations, which is
a significant part of the reason to use bogon lists.
However, yes, it has some deficiencies[1] compared with using the
static bogon lists for route filtering (and ingress/egress); it
does not prevent routing table bloat, and it does not prevent
traffic travelling across your WAN to the point of network egress
only to be dropped.
If you want to actually not receive into your network at all the
BGP routes which match bogons, as I stated earlier, there is no
way I know of to do this via a BGP feed.  The only way to do it
that I know of would be to use either a prefix list or a standard
ACL (you can do anything you can do with a prefix list with a
compiled extended ACL on BGP routes, it's just less clear to
read as an extended ACL).
Although, Owen DeLong has stated that it is possible, so maybe
we should wait for his response :-)
David.

[1] Apart from simply being a completely twisted design.

Re: 69/8...this sucks

[Stephen Sprunk]

Thus spake "Jack Bates" <[EMAIL PROTECTED]>
> After the renumber, I'll
> only have 69/8 space, which means all critical services such as my mail,
> dns, and web servers will all be affected. I hear it now. "I didn't
receive
> mail from so and so!" I check the logs and don't see an established
> connection to my server. So, is the problem that the far mail server lost
> the message, the user emailed the wrong place, or my new IP addresses
> weren't accessible by the far mail server or the dns servers that it uses?

There's several BCPs that tell you to have at least one DNS server and at
least one unfavorable MX off-site.  If you did this, your mail would be
safe, albeit a little slow from misconfigured sites.

S

Stephen Sprunk "God does not play dice."  --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSSdice at every possible opportunity." --Stephen Hawking

Re: Put part of Google on 69/8 (was Re: 69/8...this sucks)

[Stephen Sprunk]

Thus spake "JC Dill" <[EMAIL PROTECTED]>
> p.s.  Please don't cc me on replies, or on replies to replies, etc.  I
> get the list email just fine and I don't need more than one copy of any
> given email.  Really.

1)  nanog can sometimes take hours to forward posts to all members
2)  the people directly involved in the thread reasonably expect to get
responses immediately
3)  seeing your name in the To/Cc line may attach greater importance to the
message
4)  duplicates can be automatically blocked by procmail with:
:0 Wh:.msgid.cache.lock
| formail -D 8192 .msgid.cache

S

Stephen Sprunk "God does not play dice."  --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSSdice at every possible opportunity." --Stephen Hawking

Re: [Re: Put part of Google on 69/8 (was Re: 69/8...this sucks)]

[Joshua Smith]

for all of the $adjective schemes and ideas that have been posted, has
anyone (besides jon and few others affected) been doing anything 
substanitive?
outreach, more than any technical 'magic' that we can come up with, is the
only 'real' solution (subjective real, what is real to me probably doesn't
mean sh*t to you, but, hey, wtf).  the media might be good, perhaps 
some online tech sites (someone with a 'big' name in networking would 
probably be better able to get exposure/contact than a network nobody) - 
there are/were some reporter-types lurking on nanog (are you out there??),
if you are please help.
 
one thing that has been mentioned is the bogon style filtering in various
o/s firewall scripts.  anyone thought to contact the authors of those 
scripts, or of the howtos on places like tldp.org?  or is everyone too 
busy reveling in their technical grandeur

the problem is simple:  outdated filters.
the cause is murkier, but lack of clue is probably the biggest, followed
closely by lack of documentation on the part of previous admins (but we 
all document our work carefully right?!?!)
the solution is simple:  tell people that their filters are out of date
the implementation is difficult only in terms of scale.  none of us have 
the time to call/email or otherwise track down every admin out there, so 
we have to use the tools available to us (unless you really really think
that reinventing the wheel again is a good thing)

my $0.02 usd - this network nobody is now returning you to your regularly
scheduled ego-fest

joshua

Richard A Steenbergen <[EMAIL PROTECTED]> wrote:
> 
> On Tue, Mar 11, 2003 at 04:44:11PM -0800, JC Dill wrote:
> > 
> > Charles Sprickman wrote:
> > 
> > >Seriously though, somewhere there is a popular site that is non-profit
in
> > >nature that would trade say a month of free access for the hassle of
being
> > >put into a widely-blocked block.
> > 
> > The suggestion of putting Yahoo or Google on a 69/8 IP led me to this 
> > idea:
> > 
> > Google could put their *beta* sites on a 69/8 IP, without causing them 
> > (Google) much Internet reachability/connectivity harm, and benefiting 
> > the Internet at large considerably.
> 
> (Note to Mr. Dill, this is not intended to pick on you specifically, 
> it's just a convenient place to butt in)
> 
> JESUS H CHRIST ENOUGH ALREADY... Please stop with the hairbrained ideas to 
> put random things in 69/8 space. These goals are mutually exclusive. You
> can't put important stuff on broken IPs, and you can't fix broken IPs by
> putting unimportant stuff on them. No one is going to move all of the root 
> servers to try and fix a couple outdated filters, and no one who is still 
> running outdated filters is going to notice it because they can't reach 
> Google beta sites.
> 
> These are not just bad ideas, they are STUPID ideas. What happened to the
> days when, before people posted to mailing lists, they thought "will this
> make me look like an idiot in front of engineers across the entire
> planet"? This is quickly not only becoming one of the most all-time
> useless threads ever, but it is continuing to repell the useful people who
> can no longer stand to read NANOG because of crap like this.
> 
> Listen, I have space in 69/8, and it is NOT an epidemic. Back when 64/8 
> was opened up it destroyed a beautiful 64/3 filter on unallocated space, 
> and yet somehow we all made it through just fine. The people who are 
> stupid enough to filter IPs without a plan on keeping those filters up to 
> date deserve their connectivity problems. Maybe next time they'll give 
> consideration to whether they actually need unallocated bogon filters on 
> every last linux server. :)
> 
> -- 
> Richard A Steenbergen <[EMAIL PROTECTED]>   http://www.e-gerbil.net/ras
> GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)



"Walk with me through the Universe,
 And along the way see how all of us are Connected.
 Feast the eyes of your Soul,
 On the Love that abounds.
 In all places at once, seemingly endless,
 Like your own existence."
 - Stephen Hawking -

Re: Put part of Google on 69/8 (was Re: 69/8...this sucks)

[Greg Maxwell]

On Tue, 11 Mar 2003, Adam Rothschild wrote:

> On 2003-03-11-21:01:00, JC Dill <[EMAIL PROTECTED]> wrote:
> > failure will lead to the broken networks being fixed and clue being
> > distributed.
>
> How do I configure my routers and web servers for that?

no ip clue-inhibit
ip bgp redistribute-clue

RE: 69/8...this sucks

[David Luyer]

Stephen J Wilcox wrote:
> On Wed, 12 Mar 2003, David Luyer wrote:
> > Iljitsch van Beijnum wrote:
> > > On Tue, 11 Mar 2003, Owen DeLong wrote:
> > > 
> > > > In short, it doesn't.  Longer answer, if the ISP configures 
> > > > his router correctly, he can actually refuse to accept
> > > > advertisements from other sessions that are longer versions
> > > > of prefixes received through this session.
> > > 
> > > How???
> > 
> > There is a technically possible (but rather twisted) way you
> > could not use the adverts, but not a way to refuse receiving
> > them that I know of.
> 
> I think youre mixing up with ingress filtering by prefix list 
> which you can 
> specify prefix length on and hence ignore longer (or smaller) matches.

The example I provided achieved both ingress and egress filtering
based on routes in a bogon BGP feed, in a way which would even
block when a more-specific route is in the provider's BGP table.
While it didn't actually prevent the routes being in the routing
table (as I said, it doesn't provide a way to stop receiving them),
it does prevent traffic from and to the bogon locations, which is
a significant part of the reason to use bogon lists.

However, yes, it has some deficiencies[1] compared with using the
static bogon lists for route filtering (and ingress/egress); it
does not prevent routing table bloat, and it does not prevent
traffic travelling across your WAN to the point of network egress
only to be dropped.

If you want to actually not receive into your network at all the
BGP routes which match bogons, as I stated earlier, there is no
way I know of to do this via a BGP feed.  The only way to do it
that I know of would be to use either a prefix list or a standard
ACL (you can do anything you can do with a prefix list with a
compiled extended ACL on BGP routes, it's just less clear to
read as an extended ACL).

Although, Owen DeLong has stated that it is possible, so maybe
we should wait for his response :-)

David.

[1] Apart from simply being a completely twisted design.

RE: 69/8...this sucks

[Stephen J. Wilcox]

On Wed, 12 Mar 2003, David Luyer wrote:

> 
> Iljitsch van Beijnum wrote:
> > On Tue, 11 Mar 2003, Owen DeLong wrote:
> > 
> > > In short, it doesn't.  Longer answer, if the ISP configures 
> > > his router correctly, he can actually refuse to accept
> > > advertisements from other sessions that are longer versions
> > > of prefixes received through this session.
> > 
> > How???
> 
> There is a technically possible (but rather twisted) way you
> could not use the adverts, but not a way to refuse receiving
> them that I know of.

I think youre mixing up with ingress filtering by prefix list which you can 
specify prefix length on and hence ignore longer (or smaller) matches.

Steve

> 
> Consider the connection between ISP X and ISP Y.
> 
> ISP Y and is the provider who wants to null route any bogon
> traffic, even if ISP X advertises a more specific route for
> it.
> 
> EBGP session between 192.168.0.1/30 and 192.168.0.2/30.
> 
> ISP Y places 192.168.0.2 into VRF "X-Real".
> Also in VRF "X-Real" is 192.168.1.1
> 
> Now a VRF "X-Bogon" is created containing
> 192.168.1.2 and 192.168.2.1.
> 
> And finally the ISP's Default-IP-Routing-Table or other general
> internet VRF contains 192.168.2.2.
> 
> 192.168.1.1/192.168.1.2 and 192.168.2.1/192.168.2.2 are connected.
> (for example, create virtual interfaces on a GigE representing
> each side of a pair in the relevant VRFs and then loop the
> VLANs of each pair of virtual interfaces -- is there a way
> to create two "paired" loopback interfaces to interconnect VRFs
> rather than extending to a physical connection like I always have?)
> 
> 192.168.1.1 (BGP router in VRF X-Real) and 192.168.2.2 (BGP router
> in Default-IP-Routing-Table) communicate via IBGP route
> reflection.  Either dynamic or static routing can be used to
> ensure 192.158.1.1 and 192.168.2.2 know the way to reach each
> other.
> 
> BGP router 192.168.2.1 (BGP router in X-Bogon) takes ONLY a bogon
> feed, and modifies the received routes to set the next hop either
> into oblivion (eg. out a loopback with no ip unreachables set and
> a deny ip any any ACL) or to a some kind of DoS/worm tracking
> server (since almost all of this traffic will be part of some
> kind of attack or worm, and you will quite probably want to
> know about it; you can also set your default route in your
> regular network to such a server that records all traffic
> received).
> 
> Policy routing is applied on interface 192.168.1.2 saying "set
> IP default next hop 192.168.2.2" and on interface 192.168.2.1
> saying "set IP default next hop 192.168.1.1".
> 
> It would work.  I've done things similar to this example in a
> lab to prove they work.  I wouldn't want to let a configuration
> like this loose on the production internet, though, and anyone
> who would is probably a _Certifiable_ Cisco Internet Engineer.
> 
> David.
> 
> 

RE: 69/8...this sucks

[David Luyer]

Iljitsch van Beijnum wrote:
> On Tue, 11 Mar 2003, Owen DeLong wrote:
> 
> > In short, it doesn't.  Longer answer, if the ISP configures 
> > his router correctly, he can actually refuse to accept
> > advertisements from other sessions that are longer versions
> > of prefixes received through this session.
> 
> How???

There is a technically possible (but rather twisted) way you
could not use the adverts, but not a way to refuse receiving
them that I know of.

Consider the connection between ISP X and ISP Y.

ISP Y and is the provider who wants to null route any bogon
traffic, even if ISP X advertises a more specific route for
it.

EBGP session between 192.168.0.1/30 and 192.168.0.2/30.

ISP Y places 192.168.0.2 into VRF "X-Real".
Also in VRF "X-Real" is 192.168.1.1

Now a VRF "X-Bogon" is created containing
192.168.1.2 and 192.168.2.1.

And finally the ISP's Default-IP-Routing-Table or other general
internet VRF contains 192.168.2.2.

192.168.1.1/192.168.1.2 and 192.168.2.1/192.168.2.2 are connected.
(for example, create virtual interfaces on a GigE representing
each side of a pair in the relevant VRFs and then loop the
VLANs of each pair of virtual interfaces -- is there a way
to create two "paired" loopback interfaces to interconnect VRFs
rather than extending to a physical connection like I always have?)

192.168.1.1 (BGP router in VRF X-Real) and 192.168.2.2 (BGP router
in Default-IP-Routing-Table) communicate via IBGP route
reflection.  Either dynamic or static routing can be used to
ensure 192.158.1.1 and 192.168.2.2 know the way to reach each
other.

BGP router 192.168.2.1 (BGP router in X-Bogon) takes ONLY a bogon
feed, and modifies the received routes to set the next hop either
into oblivion (eg. out a loopback with no ip unreachables set and
a deny ip any any ACL) or to a some kind of DoS/worm tracking
server (since almost all of this traffic will be part of some
kind of attack or worm, and you will quite probably want to
know about it; you can also set your default route in your
regular network to such a server that records all traffic
received).

Policy routing is applied on interface 192.168.1.2 saying "set
IP default next hop 192.168.2.2" and on interface 192.168.2.1
saying "set IP default next hop 192.168.1.1".

It would work.  I've done things similar to this example in a
lab to prove they work.  I wouldn't want to let a configuration
like this loose on the production internet, though, and anyone
who would is probably a _Certifiable_ Cisco Internet Engineer.

David.

Re: 69/8...this sucks

[ed]

> In addition, sometimes the problem is that my user just needs to put the
> crack pipe down. I just don't feel comfortable with this last one anymore,
> though. I can't be sure it's the crack. It could be the IPs. How do I know?

I'm not a major router admin.  I manage a couple dozen /24's and the
supporting gear, but...

It seems one purpose (perhaps remote) of bogon filters is security.  Why
not get someone like CERT to broadcast changes in allocations? I'd bet a
cup of Dunkin' Donuts coffee that the news would quickly get to the
"right" people.

My $two_cents for very large values of $two_cents.
(back to my hole)
-ed -
[EMAIL PROTECTED]

Re: 69/8...this sucks

[Jack Bates]

From: "Andy Dills"

> Are you ok with a solution of patiently waiting for some sort of critical
> mass to occur with each new /8 that gets allocated? Sooner or later,
> enough content will be in 69/8 (and other commonly filtered /8s) that
> people will be forced to fix their filters. But is that the only way?
>
> And would your answer change if you were one of the first networks to be
> assigned space in the new range?
>
I might point out that it can even be worse. The IP addressing I was using
belonged to a provider that I'd used for many, many years. They were pulling
out and sending customers elsewhere, so I bit the bullet and pulled up the
numbers to get my first ARIN assigned addresses. So now I have a /18 that
will be at 90% utilization by the end of the month. I can't delay, as I
can't request more IP addresses until I release the old networks back to the
provider. In essence, I was just forced to screw all my customers. At the
next meeting, might someone kindly mention to ARIN that "initial" requests,
especially renumbers, should not be issued space that is less than a year
off the bogon list?

More than anything, this is what has pissed me off. After the renumber, I'll
only have 69/8 space, which means all critical services such as my mail,
dns, and web servers will all be affected. I hear it now. "I didn't receive
mail from so and so!" I check the logs and don't see an established
connection to my server. So, is the problem that the far mail server lost
the message, the user emailed the wrong place, or my new IP addresses
weren't accessible by the far mail server or the dns servers that it uses?
In addition, sometimes the problem is that my user just needs to put the
crack pipe down. I just don't feel comfortable with this last one anymore,
though. I can't be sure it's the crack. It could be the IPs. How do I know?

-Jack

Re: Put part of Google on 69/8 (was Re: 69/8...this sucks)

[Adam Rothschild]

On 2003-03-11-21:01:00, JC Dill <[EMAIL PROTECTED]> wrote:
> [...]
> > (Note to Mr. Dill, this is not intended to pick on you specifically, 
> > it's just a convenient place to butt in)
> 
> 
> Ahem.  It's _MS._ Dill, thank you.

Please post with a gender-specific name if you want to take offense
when mis-identified.

> Sure you can.  You just need content unimportant enough that no one
> (the end users on a network that is still blocking 69/8, AND the
> networks that put up the sacrificial target host on a 69/8 IP) is
> truly hurt if the connection fails, but important enough that the
> failure will lead to the broken networks being fixed and clue being
> distributed.

How do I configure my routers and web servers for that?

> I'm suggesting that Google explain why they are doing this on a page
> linked off their homepage.  If this is done, people ARE going to
> notice, and ARE going to find out why.  When it is widely
> publicised, it WILL be noticed even more.

Last I checked, Google was a for-profit business, not a charity house.
I'm not sure how doing something that will make them look dumb, and
cost them in valuable ad revenue, etc is in their best interests.
Perhaps you could fill me in here.

> p.s.  Please don't cc me on replies, or on replies to replies, etc.

We have seen time after time that the propagation delays on the NANOG
list, most likely resultant from sub-optimal postfix/majordomo
configuration and/or an overloaded box, make it unsuitable for
realtime communications.  With this in mind, I have taken the liberty
of cc'ing you in my reply, despite your request to the contrary.

If duplicate messages cluttering your inbox are causing you much
grief, prehaps it's time to read up on message filtering using
procmail, formail, and friends.

Regards,
-a

Re: Put part of Google on 69/8 (was Re: 69/8...this sucks)

[Richard A Steenbergen]

On Tue, Mar 11, 2003 at 06:01:00PM -0800, JC Dill wrote:
> 
> Ahem.  It's _MS._ Dill, thank you.

Woops, my apologies _MS._ Dill. The JC is ambiguous.

> Maybe next time you will stop and think "will this make me look like a
> sexist idiot in front of engineers across the entire planet"? before
> posting to a mailing list.  (If the shoe fits, wear it.)

Sexist? Now that's just absurd. I took a guess and lost, big deal. If 
anything, that proves my opinion of your idea has nothing to do with your 
gender. Get over it.

> p.s.  Please don't cc me on replies, or on replies to replies, etc.  I 
> get the list email just fine and I don't need more than one copy of any 
> given email.  Really.

I believe you'll find reply-all is commonly used, get over it. Really.

-- 
Richard A Steenbergen <[EMAIL PROTECTED]>   http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

Re: Put part of Google on 69/8 (was Re: 69/8...this sucks)

[JC Dill]

Richard A Steenbergen wrote:
On Tue, Mar 11, 2003 at 04:44:11PM -0800, JC Dill wrote:

Charles Sprickman wrote:

Seriously though, somewhere there is a popular site that is non-profit in
nature that would trade say a month of free access for the hassle of being
put into a widely-blocked block.
The suggestion of putting Yahoo or Google on a 69/8 IP led me to this 
idea:

Google could put their *beta* sites on a 69/8 IP, without causing them 
(Google) much Internet reachability/connectivity harm, and benefiting 
the Internet at large considerably.
(Note to Mr. Dill, this is not intended to pick on you specifically, 
it's just a convenient place to butt in)


Ahem.  It's _MS._ Dill, thank you.

Maybe next time you will stop and think "will this make me look like a 
sexist idiot in front of engineers across the entire planet"? before 
posting to a mailing list.  (If the shoe fits, wear it.)

JESUS H CHRIST ENOUGH ALREADY... Please stop with the hairbrained ideas to 
put random things in 69/8 space. These goals are mutually exclusive. You
can't put important stuff on broken IPs, and you can't fix broken IPs by
putting unimportant stuff on them. 
Sure you can.  You just need content unimportant enough that no one (the 
end users on a network that is still blocking 69/8, AND the networks 
that put up the sacrificial target host on a 69/8 IP) is truly hurt if 
the connection fails, but important enough that the failure will lead to 
the broken networks being fixed and clue being distributed.

> no one who is still
running outdated filters is going to notice it because they can't reach 
Google beta sites.
I'm suggesting that Google explain why they are doing this on a page 
linked off their homepage.  If this is done, people ARE going to notice, 
and ARE going to find out why.  When it is widely publicised, it WILL be 
noticed even more.

These are not just bad ideas, they are STUPID ideas. 
Where is your bright suggestion?

Listen, I have space in 69/8, and it is NOT an epidemic.
So how are you solving your 69/8 filtering/connectivity problems?

Back when 64/8 
was opened up it destroyed a beautiful 64/3 filter on unallocated space, 
and yet somehow we all made it through just fine. The people who are 
stupid enough to filter IPs without a plan on keeping those filters up to 
date deserve their connectivity problems. 
OK, I'm confused.  I thought that the connectivity problem was, by and 
large, endured by the 69/8 IP users, and not on the networks with 
out-of-date bogon filters.  Please elaborate on how this problem is 
really a connectivity problem for the networks with the bad filters, and 
how they are experiencing and then fixing this problem.  Because from 
all reports here, it's obvious to ME that these networks are totally 
unaware of the issue because it is NOT creating a problem for them!

jc

p.s.  Please don't cc me on replies, or on replies to replies, etc.  I 
get the list email just fine and I don't need more than one copy of any 
given email.  Really.

Re: 69/8...this sucks -- Centralizing filtering..

[Jack Bates]

From: "Iljitsch van Beijnum"

>
> I don't see your point. Packets with bogon sources are just one class of
> spoofed packets. As I've explained earlier S-BGP or soBGP with uRPF will
> get rid of bogons. Neither this or bogon filters on the host will do
> anything against non-bogon spoofed packets.

You're thinking technical. The problem isn't bogon filters per say. The
problem is that someone got it in their head that if you filter packets
using a bogon list, you'll limit the number of possible spoofed packets
allowed into your network. Given than many bots use randomizers, and bogon
networks do cover a large amount of the netspace, this may be true. Then
again, perhaps not. It doesn't matter in the end. The fact remains that
while people may protect the routes from being advertised, many large
providers do not drop packets that do not have valid routes. Because of
this, many firewalls (which don't run BGP) filter based on bogon lists.

Only 1 of the last 6 people I contacted for blocking 69/8 actually had BGP.

-Jack

RE: Put part of Google on 69/8 (was Re: 69/8...this sucks)

[Todd A. Blank]

Wanting to continue to be a part of the solution, and not part of the
problem, I just want to post publicly to the list that we would gladly
donate some IP space from our ARIN direct assignment (which lives in the
69/8 CIDR) to the cause.

If anyone is interested, please contact me off list.

Sincerely,

Todd A. Blank
CTO
IPOutlet LLC
614.207.5853

-Original Message-
From: McBurnett, Jim [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, March 11, 2003 8:00 PM
To: JC Dill; [EMAIL PROTECTED]
Subject: RE: Put part of Google on 69/8 (was Re: 69/8...this sucks)



Idea #2.. 
CNN.com-- Put some of their content.. They would probrably really enjoy 
the publicity.. And that would really be an educational point..
Anybody here from there???


Jim
> The suggestion of putting Yahoo or Google on a 69/8 IP led me to this 
> idea:
> 
> Google could put their *beta* sites on a 69/8 IP, without 
> causing them 
> (Google) much Internet reachability/connectivity harm, and benefiting 
> the Internet at large considerably.
> 
> Set up a page (hopefully linked from www.google.com) that 
> lists all of 
> Google's present beta sites.  
 

Re: Put part of Google on 69/8 (was Re: 69/8...this sucks)

[wireworks]

And I'd like to add I agree.

The problems were wide at first, they have definitely dropped off.

Everyone important, is reachable now it seems.

I can think of maybe one or two small islands who might still be unreachable
but hey if I lived in the troopics I'd be outside with an umbrella drink
too, not changing filters.

Bottom line is that the only way to fix this problem is to move in to the
space, use the space, and contact people when its broken.  Nanog although
perhaps not the best place for this, has helped in this goal for me at least
4 or 5 times and its fixed for everyone not just me.  With all of us
pounding away the problems clear quickly.



- Original Message -
From: "Richard A Steenbergen" <[EMAIL PROTECTED]>
To: "JC Dill" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, March 11, 2003 5:17 PM
Subject: Re: Put part of Google on 69/8 (was Re: 69/8...this sucks)


>
> On Tue, Mar 11, 2003 at 04:44:11PM -0800, JC Dill wrote:
> >
> > Charles Sprickman wrote:
> >
> > >Seriously though, somewhere there is a popular site that is non-profit
in
> > >nature that would trade say a month of free access for the hassle of
being
> > >put into a widely-blocked block.
> >
> > The suggestion of putting Yahoo or Google on a 69/8 IP led me to this
> > idea:
> >
> > Google could put their *beta* sites on a 69/8 IP, without causing them
> > (Google) much Internet reachability/connectivity harm, and benefiting
> > the Internet at large considerably.
>
> (Note to Mr. Dill, this is not intended to pick on you specifically,
> it's just a convenient place to butt in)
>
> JESUS H CHRIST ENOUGH ALREADY... Please stop with the hairbrained ideas to
> put random things in 69/8 space. These goals are mutually exclusive. You
> can't put important stuff on broken IPs, and you can't fix broken IPs by
> putting unimportant stuff on them. No one is going to move all of the root
> servers to try and fix a couple outdated filters, and no one who is still
> running outdated filters is going to notice it because they can't reach
> Google beta sites.
>
> These are not just bad ideas, they are STUPID ideas. What happened to the
> days when, before people posted to mailing lists, they thought "will this
> make me look like an idiot in front of engineers across the entire
> planet"? This is quickly not only becoming one of the most all-time
> useless threads ever, but it is continuing to repell the useful people who
> can no longer stand to read NANOG because of crap like this.
>
> Listen, I have space in 69/8, and it is NOT an epidemic. Back when 64/8
> was opened up it destroyed a beautiful 64/3 filter on unallocated space,
> and yet somehow we all made it through just fine. The people who are
> stupid enough to filter IPs without a plan on keeping those filters up to
> date deserve their connectivity problems. Maybe next time they'll give
> consideration to whether they actually need unallocated bogon filters on
> every last linux server. :)
>
> --
> Richard A Steenbergen <[EMAIL PROTECTED]>   http://www.e-gerbil.net/ras
> GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
>

Re: Put part of Google on 69/8 (was Re: 69/8...this sucks)

[Richard A Steenbergen]

On Tue, Mar 11, 2003 at 04:44:11PM -0800, JC Dill wrote:
> 
> Charles Sprickman wrote:
> 
> >Seriously though, somewhere there is a popular site that is non-profit in
> >nature that would trade say a month of free access for the hassle of being
> >put into a widely-blocked block.
> 
> The suggestion of putting Yahoo or Google on a 69/8 IP led me to this 
> idea:
> 
> Google could put their *beta* sites on a 69/8 IP, without causing them 
> (Google) much Internet reachability/connectivity harm, and benefiting 
> the Internet at large considerably.

(Note to Mr. Dill, this is not intended to pick on you specifically, 
it's just a convenient place to butt in)

JESUS H CHRIST ENOUGH ALREADY... Please stop with the hairbrained ideas to 
put random things in 69/8 space. These goals are mutually exclusive. You
can't put important stuff on broken IPs, and you can't fix broken IPs by
putting unimportant stuff on them. No one is going to move all of the root 
servers to try and fix a couple outdated filters, and no one who is still 
running outdated filters is going to notice it because they can't reach 
Google beta sites.

These are not just bad ideas, they are STUPID ideas. What happened to the
days when, before people posted to mailing lists, they thought "will this
make me look like an idiot in front of engineers across the entire
planet"? This is quickly not only becoming one of the most all-time
useless threads ever, but it is continuing to repell the useful people who
can no longer stand to read NANOG because of crap like this.

Listen, I have space in 69/8, and it is NOT an epidemic. Back when 64/8 
was opened up it destroyed a beautiful 64/3 filter on unallocated space, 
and yet somehow we all made it through just fine. The people who are 
stupid enough to filter IPs without a plan on keeping those filters up to 
date deserve their connectivity problems. Maybe next time they'll give 
consideration to whether they actually need unallocated bogon filters on 
every last linux server. :)

-- 
Richard A Steenbergen <[EMAIL PROTECTED]>   http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

RE: Put part of Google on 69/8 (was Re: 69/8...this sucks)

[McBurnett, Jim]

Idea #2.. 
CNN.com-- Put some of their content.. They would probrably really enjoy 
the publicity.. And that would really be an educational point..
Anybody here from there???


Jim
> The suggestion of putting Yahoo or Google on a 69/8 IP led me to this 
> idea:
> 
> Google could put their *beta* sites on a 69/8 IP, without 
> causing them 
> (Google) much Internet reachability/connectivity harm, and benefiting 
> the Internet at large considerably.
> 
> Set up a page (hopefully linked from www.google.com) that 
> lists all of 
> Google's present beta sites.  
 

Re: 69/8...this sucks

[Andy Dills]

On Tue, 11 Mar 2003, Richard A Steenbergen wrote:

>
> On Tue, Mar 11, 2003 at 11:38:23AM -0800, Owen DeLong wrote:
> >
> > As such, is a BGP feed a panacea?  No.  Is it a step in the right direction?
> > Yes.  Will it solve the problem by itself?  No.  Will it improve the
>
> So, someone feel free to smack me if I'm mentioning something which has
> been discussed already (there isn't enough masochism in the world to make
> me read this entire thread), but...
>
> How exactly is a BGP feed of bogons useful in any way shape form of
> fashion? It doesn't prevent people from announcing more specifics, it
> doesn't do anything about source address bogons, it can't be used to
> packet filter... How exactly would it do anything other than simply not
> having the route at all?

I guess that emperor is a little naked after all :)

Without applying hard-coded bogon filters to your peers (to prevent
receiving longer prefixes in bogon space), it is essentially useless.
http://www.cymru.com/Documents/secure-bgp-template.html lists a nice
template. But then we're back right where we started, may as well just
have a static ACL...unless you can't afford the ACL hit, in which case
filtering announcements from your peers and routing everything bogon into
a traffic sink would be a great solution.

We're all filtering announcements from our peers anyway, right? :)

Andy


Andy Dills  301-682-9972
Xecunet, LLCwww.xecu.net

Dialup * Webhosting * E-Commerce * High-Speed Access

Put part of Google on 69/8 (was Re: 69/8...this sucks)

[JC Dill]

Charles Sprickman wrote:

Seriously though, somewhere there is a popular site that is non-profit in
nature that would trade say a month of free access for the hassle of being
put into a widely-blocked block.
The suggestion of putting Yahoo or Google on a 69/8 IP led me to this 
idea:

Google could put their *beta* sites on a 69/8 IP, without causing them 
(Google) much Internet reachability/connectivity harm, and benefiting 
the Internet at large considerably.

Set up a page (hopefully linked from www.google.com) that lists all of 
Google's present beta sites.  On this page, inform the user that the 
beta sites are hosted on "newly allocated IP addresses" and that if the 
said user can't reach the beta sites, it most likely means that their 
ISP/Company is improperly filtering these newly valid IP addresses, 
Instruct these affected users to contact their IPS's support desk or 
their company's IS department and alert them that they need to update 
their IP filter set to avoid filtering newly released and valid IPs. 
Then also link to a site such as  which 
explains bogon filters, shows how to find the latest lists, and educates 
the filter-clueless on how to subscribe to appropriate announcement 
lists to become aware of updates/changes in what IPs can be safely 
filtered.  Google could also explain that they are doing this to help 
the Internet community fix this problem, and perhaps explain why it is a 
problem.  They would get tons of good press which would help advertise 
Google and their beta projects.

Froogle is a very kewl site that gets better by the day (thanks guys, I 
use it all the time!), and I bet it also gets more traffic by the day. 
This would be a good way for Google to get free publicity for Froogle 
and other beta sites, and get big Internet community "good guy" points 
for helping fix the 69/8 bogon filter problem, without outright breaking 
the highly popular Google websearch site itself.

Is there anyone from Google lurking here on nanog?

jc

(Googling on:  google beta, I discovered that Google itself went beta in 
February of 1999, just 4 years ago.  My, how time flies!)

Re: 69/8...this sucks

[Andy Dills]

On Tue, 11 Mar 2003, Randy Bush wrote:

>
> > Look, there's no quick fix solution here.
>
> so let's see how much of a kludge we can make to show how clever
> we are.

Excellent point...but then, what to do?

Have we given up and decided that addressing the 69/8 (and similar, future
issues) is a social problem that can't be fixed via technical means?

Are you ok with a solution of patiently waiting for some sort of critical
mass to occur with each new /8 that gets allocated? Sooner or later,
enough content will be in 69/8 (and other commonly filtered /8s) that
people will be forced to fix their filters. But is that the only way?

And would your answer change if you were one of the first networks to be
assigned space in the new range?

Andy


Andy Dills  301-682-9972
Xecunet, LLCwww.xecu.net

Dialup * Webhosting * E-Commerce * High-Speed Access

Re: 69/8...this sucks

[william]

To a degree the problem is ability to reach proper persons. I'd like to be 
able to enter as# or ip and immediatly get email for a tech who knows what 
to do. Radb is supposed to provide some of these functionalities, so does 
ip whois, so does dns whois. Usually one of these will get you what you 
need or if nothing else, youd'd look at AS traceroute and contact the 
upstream.

Reality is we do have hierchical structure in ip & as assignments/allocations:
IANA->RIR->LIR->ISP->END-USER but currect information exchange is only 
possible at one level (i.e RIR should know how to contact LIR, ISP should 
know how to contact END-USER). A lot smaller hierchy is with AS numbers - 
IANA->RIR->END-USER. I guess I forgot about all this in my proposal but 
I'll be sure to clarify that when new assignment is received ARIN should 
notify not only their IP subscriber members and end-users (ip assignments)
customers but also all those listed as contacts for ASNs (removing duplicate
emails gathered from all the sources, of course).

Unfortunetly ASN  contact information is one of the least "maintained" as 
far as ARIN data goes. And too bad... In my opinion fairly good way to 
solve the problem would be to make sure that ASN contact info is up to 
date for all RIRs and when new global assignments are made than IANA 
makes the announcement and RIRs pass it along to their AS contacts and as 
backup through longer ip path. I'm fairly certain if info on who to 
contact was up to date at RIRs, the reachibility of this would be well 
over 99% and number of blackholes for users of new ip block would be very 
small.

On Tue, 11 Mar 2003, Alec H. Peterson wrote:

> 
> --On Tuesday, March 11, 2003 16:47 -0500 Randy Bush <[EMAIL PROTECTED]> wrote:
> 
> >
> > so let's see how much of a kludge we can make to show how clever
> > we are.
> 
> How about if we all chip in to hire a bunch of out of work consultants to 
> fly to the NOCs of the various backbones who are being boneheaded to 
> educate them with a clue-by-four?
> 
> Alec
> 
> --
> Alec H. Peterson -- [EMAIL PROTECTED]
> Chief Technology Officer
> Catbird Networks, http://www.catbird.com

Re: 69/8...this sucks

[Charles Sprickman]

On Tue, 11 Mar 2003, Randy Bush wrote:

> so let's see how much of a kludge we can make to show how clever
> we are.

Hey, I already came up with the slashdot idea.

Seriously though, somewhere there is a popular site that is non-profit in
nature that would trade say a month of free access for the hassle of being
put into a widely-blocked block.

Like anything else, until end users complain, nothing happens.

Charles

> randy
>

RE: 69/8...this sucks

[Iljitsch van Beijnum]

On Tue, 11 Mar 2003, Owen DeLong wrote:

> In short, it doesn't.  Longer answer, if the ISP configures his router
> correctly, he can actually refuse to accept advertisements from other
> sessions that are longer versions of prefixes received through this session.

How???

Re: 69/8...this sucks

[Alec H. Peterson]

--On Tuesday, March 11, 2003 16:47 -0500 Randy Bush <[EMAIL PROTECTED]> wrote:

so let's see how much of a kludge we can make to show how clever
we are.
How about if we all chip in to hire a bunch of out of work consultants to 
fly to the NOCs of the various backbones who are being boneheaded to 
educate them with a clue-by-four?

Alec

--
Alec H. Peterson -- [EMAIL PROTECTED]
Chief Technology Officer
Catbird Networks, http://www.catbird.com

Re: 69/8...this sucks

[Randy Bush]

> Look, there's no quick fix solution here.

so let's see how much of a kludge we can make to show how clever
we are.

randy

RE: 69/8...this sucks

[Andy Dills]

On Tue, 11 Mar 2003, Rick Duff wrote:

> I've never posted to the list, just lurk, for over a year now, but this
> has to be said. Can we please take this discussion off-list to private
> conversation. It's gotten worse then spam. I see a nanog message and
> just start deleting them now.

Come on...everybody takes turns being the nanog nazi, but it isn't your
turn yet.

Two suggestions:

Number one, you'll probably find your list reading experience to be far
more pleasurable if you filter. If nothing else, filter each mailing list
you're on into its own box. It allows you to look at nanog mail only when
you want to look at nanog mail. But then you can take it a step further,
and plonk threads or individual posters into the bit bucket (whatever the
Outlook Express equivalent of /dev/null is). I'm being nice; some would
simply shout "man procmail" and stick YOU in their .procmailrc.

Number two, don't complain about posts which are essentially complaints
themselves (albeit with a sense of humor). My post wasn't just a silly
gesture, it was an attempt to point out the ridiculous extremes and insane
overlapping the threads have denegerated into, without falling into the
"shut up and go away. why I can't ping sublimedirectory.com?" cliche.

At the minute, the following concerns and ideas are being tossed about,
which all overlap slightly but not totally, resulting in a ridiculous
mishmash of ideas that have begun to feed on itself (note that these have
all been brought up in different ways, and are not all parts of a single
thread):

sBGP
bogon filtering
centralized scanning for the prevention of abuse
idealistic segmentation of the net into the "pure" and "impure"
lack of reachibility from 69/8

If you step back on some high level, the threads are all about lazy and or
nonexistent network administration, and ways to cope with the impact on
the net we all have to run. But if you read every post, it has degenerated
into an argument over whether or not everything is ready to be a nail for
the LDAP hammer and whether or not people actually understand how sBGP is
proposed to work.

But at the same time, I can't think of a place this stuff would be more
relevant. Which is why it's good to filter...so you still be subscribed to
the list AND not be annoyed.

Andy


Andy Dills  301-682-9972
Xecunet, LLCwww.xecu.net

Dialup * Webhosting * E-Commerce * High-Speed Access

Re: 69/8...this sucks

[Richard A Steenbergen]

On Tue, Mar 11, 2003 at 11:38:23AM -0800, Owen DeLong wrote:
> 
> As such, is a BGP feed a panacea?  No.  Is it a step in the right direction?
> Yes.  Will it solve the problem by itself?  No.  Will it improve the 

So, someone feel free to smack me if I'm mentioning something which has 
been discussed already (there isn't enough masochism in the world to make 
me read this entire thread), but...

How exactly is a BGP feed of bogons useful in any way shape form of
fashion? It doesn't prevent people from announcing more specifics, it
doesn't do anything about source address bogons, it can't be used to
packet filter... How exactly would it do anything other than simply not 
having the route at all?

If and when some vendor adds support for taking the routes from a bgp feed
and using them in a packet filter, sign me up. Until then, I must be
missing something.

-- 
Richard A Steenbergen <[EMAIL PROTECTED]>   http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

Re: 69/8...this sucks

[Larry J. Blunk]

  Appologies for the poor attempt at humor...  However, there
is some useful content at the end of the message.

  Essentially, I think this is one of those problems that can
never fully be solved.  Just as we will never get every last
worm-infected host off the network.

  The best that we can do is provide procedures for those who
filter on unallocated space so than can keep their
filters updated on a timely and accurate basis.

  For those who do not wish to use such procedures, we
should stridently urge them to filter only on martians,
not unallocated space.

 -Larry Blunk
  Merit


> I agree.
> 
> -Original Message-
> From: Rick Duff [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, March 11, 2003 2:09 PM
> To: 'Larry J. Blunk'; 'Andy Dills'
> Cc: 'Ejay Hire'; [EMAIL PROTECTED]
> Subject: RE: 69/8...this sucks 
> 
> 
> 
> I've never posted to the list, just lurk, for over a year now, but this
> has to be said. Can we please take this discussion off-list to private
> conversation. It's gotten worse then spam. I see a nanog message and
> just start deleting them now.
> 
> -rd
> 
> 
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
> Larry J. Blunk
> Sent: Tuesday, March 11, 2003 1:01 PM
> To: Andy Dills
> Cc: Ejay Hire; [EMAIL PROTECTED]
> Subject: Re: 69/8...this sucks 
> 
> 
> 
> > 
> > On Tue, 11 Mar 2003, Ejay Hire wrote:
> > 
> > > Er, guys...  How does this fix the problem of a Malicious user
> > > advertising a more specific bogon route?
> > 
> > Come on...clearly you haven't been paying attention.
> > 
> > You need LDAP filters. LDAP filters and a South Vietnamese revolution
> > against the IRRs for being fragmented and greedy.
> 
>   Careful.  We are watching and are prepared to ruthlessly squash
> any attempted rebellion.
> 
> > 
> > And if that doesn't poison your inverse arp, then multiplex a private
> > bogon server with a centralized host scanner-based DNSBL. Don't forget
> the
> > trailing dot! And don't forget to invert the subnet mask!
> > 
> 
>Hey, I've already thought of all that and captured it in an
> XML schema (with ASN.1 encoding)!  I will be presenting an Internet
> Draft next week at the IETF in the CRISP/RPSEC/GROW/IDR meetings. 
> 
> 
>Seriously...  As has been suggested, I think we need to do
> a better job of identifying the population and type of devices
> that are filtering these prefixes.  Are they really predominately
> BGP speaking routers, or largely some mishmash of non-BGP speaking
> firewalls/proxies/NAT's?
> 
>If it's the former, then a BGP based solution has some merit.
> If the latter, I think it unreasonable to expect these
> firewalls to speak BGP.  What's needed is a canonical
> represention of the bogon list and some tools to generate
> the filter list in the appropriate config format for a number
> target devices.
> 
>There's already a canonical list maintained by Rob Thomas
> in the RADB (see fltr-martian, fltr-unallocated, and
> fltr-bogons).   I've suggested to Rob that he may want
> to include a PGP signature in a remarks section of the object
> to provide a greater level of confidence (hopefully with
> a key that's escrowed somehow -- god forbid anything should
> happen to Rob).  I should also note that some of the
> RIR's have indicated they will be providing more
> precise information on their unallocated space.
> 
>As far as tools go, while IRRToolSet has extensive
> support for RPSL, it may be too complex for a novice
> Net admin.  Perhaps some simple Perl scripts to generate
> filter configs from RPSL filter objects would be useful?
> 
> 
>  Larry Blunk
>  Merit
> 

RE: 69/8...this sucks

[Rick Duff]

I've never posted to the list, just lurk, for over a year now, but this
has to be said. Can we please take this discussion off-list to private
conversation. It's gotten worse then spam. I see a nanog message and
just start deleting them now.

-rd


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Larry J. Blunk
Sent: Tuesday, March 11, 2003 1:01 PM
To: Andy Dills
Cc: Ejay Hire; [EMAIL PROTECTED]
Subject: Re: 69/8...this sucks 



> 
> On Tue, 11 Mar 2003, Ejay Hire wrote:
> 
> > Er, guys...  How does this fix the problem of a Malicious user
> > advertising a more specific bogon route?
> 
> Come on...clearly you haven't been paying attention.
> 
> You need LDAP filters. LDAP filters and a South Vietnamese revolution
> against the IRRs for being fragmented and greedy.

  Careful.  We are watching and are prepared to ruthlessly squash
any attempted rebellion.

> 
> And if that doesn't poison your inverse arp, then multiplex a private
> bogon server with a centralized host scanner-based DNSBL. Don't forget
the
> trailing dot! And don't forget to invert the subnet mask!
> 

   Hey, I've already thought of all that and captured it in an
XML schema (with ASN.1 encoding)!  I will be presenting an Internet
Draft next week at the IETF in the CRISP/RPSEC/GROW/IDR meetings. 


   Seriously...  As has been suggested, I think we need to do
a better job of identifying the population and type of devices
that are filtering these prefixes.  Are they really predominately
BGP speaking routers, or largely some mishmash of non-BGP speaking
firewalls/proxies/NAT's?

   If it's the former, then a BGP based solution has some merit.
If the latter, I think it unreasonable to expect these
firewalls to speak BGP.  What's needed is a canonical
represention of the bogon list and some tools to generate
the filter list in the appropriate config format for a number
target devices.

   There's already a canonical list maintained by Rob Thomas
in the RADB (see fltr-martian, fltr-unallocated, and
fltr-bogons).   I've suggested to Rob that he may want
to include a PGP signature in a remarks section of the object
to provide a greater level of confidence (hopefully with
a key that's escrowed somehow -- god forbid anything should
happen to Rob).  I should also note that some of the
RIR's have indicated they will be providing more
precise information on their unallocated space.

   As far as tools go, while IRRToolSet has extensive
support for RPSL, it may be too complex for a novice
Net admin.  Perhaps some simple Perl scripts to generate
filter configs from RPSL filter objects would be useful?


 Larry Blunk
 Merit

Re: 69/8...this sucks

[Larry J. Blunk]

> 
> On Tue, 11 Mar 2003, Ejay Hire wrote:
> 
> > Er, guys...  How does this fix the problem of a Malicious user
> > advertising a more specific bogon route?
> 
> Come on...clearly you haven't been paying attention.
> 
> You need LDAP filters. LDAP filters and a South Vietnamese revolution
> against the IRRs for being fragmented and greedy.

  Careful.  We are watching and are prepared to ruthlessly squash
any attempted rebellion.

> 
> And if that doesn't poison your inverse arp, then multiplex a private
> bogon server with a centralized host scanner-based DNSBL. Don't forget the
> trailing dot! And don't forget to invert the subnet mask!
> 

   Hey, I've already thought of all that and captured it in an
XML schema (with ASN.1 encoding)!  I will be presenting an Internet
Draft next week at the IETF in the CRISP/RPSEC/GROW/IDR meetings. 


   Seriously...  As has been suggested, I think we need to do
a better job of identifying the population and type of devices
that are filtering these prefixes.  Are they really predominately
BGP speaking routers, or largely some mishmash of non-BGP speaking
firewalls/proxies/NAT's?

   If it's the former, then a BGP based solution has some merit.
If the latter, I think it unreasonable to expect these
firewalls to speak BGP.  What's needed is a canonical
represention of the bogon list and some tools to generate
the filter list in the appropriate config format for a number
target devices.

   There's already a canonical list maintained by Rob Thomas
in the RADB (see fltr-martian, fltr-unallocated, and
fltr-bogons).   I've suggested to Rob that he may want
to include a PGP signature in a remarks section of the object
to provide a greater level of confidence (hopefully with
a key that's escrowed somehow -- god forbid anything should
happen to Rob).  I should also note that some of the
RIR's have indicated they will be providing more
precise information on their unallocated space.

   As far as tools go, while IRRToolSet has extensive
support for RPSL, it may be too complex for a novice
Net admin.  Perhaps some simple Perl scripts to generate
filter configs from RPSL filter objects would be useful?


 Larry Blunk
 Merit

Re: 69/8...this sucks -- Centralizing filtering..

[jlewis]

On Mon, 10 Mar 2003, Ray Bellis wrote:

> Most people seem to think it would be impractical to put the root name
> servers in 69.0.0.0/8
> 
> Why not persuade ARIN to put whois.arin.net in there instead?  It
> shouldn't take the people with the broken filters *too* long to figure
> out why they can't do IP assignment lookups...

The vast majority of broken networks won't care/notice.  A few will assume
ARIN's whois server is broken.  How often do people on forgotten networks
in China and Albania use ARIN's whois server?

Take away the western Internet (all of gtld-servers.net) and they will 
notice the problem.  

>From a whois, it appears Verisign owns gtld-servers.net.  Do they own just 
the domain or all 13 gtld-servers as well?  Anyone from Verisign reading 
NANOG care to comment on the odds of Verisign cooperating and helping 
with the breaking in of new IP ranges?

Also, on a side rant hereWhy do all the RIR's have to give out whois
data in different, incompatible, referal-breaking formats?  The next step
in my work once my ping sweep is complete (looks like that'll be today) is
going to be to take a list of what looks like it'll be ~1000 IPs and
generate a list of the unique networks that are broken.  To do this, it'd
be nice if there were some key I could get from whois, store in a column,
select a unique set from, then reuse to lookup POCs from whois, and send
off the emails.

registro.br and LACNIC entries start with inetnum: using what I'll call
brief CIDR, i.e.
inetnum:  200.198.128/19

APNIC and RIPE entries start with inetnum:, but use range format.  i.e.
inetnum:  203.145.160.0 - 203.145.191.255

ARIN entries include fields like
NetRange:   128.63.0.0 - 128.63.255.255 
CIDR:   128.63.0.0/16 

The APNIC and RIPE NetRange/inetnum fields are easy enough to deal with, 
but send a whois request for 200.198.128/19 to whois.arin.net and you get 
"No match found".  Send it as 200.198.128, and whois.arin.net will refer 
you to whois.lacnic.net.  Send it to whois.lacnic.net as 200.198.128, and 
you get "Invalid IP or CIDR block".

I realize programming around all this is by no means an insurmountable
task, but it is a pain.  It'd be ideal if there were a unique key field,
say Net-ID included in the whois output from all the RIR whois servers
that could be used to identify the network and the appropriate whois
server.  i.e.

NetID: [EMAIL PROTECTED]
 
--
 Jon Lewis [EMAIL PROTECTED]|  I route
 System Administrator|  therefore you are
 Atlantic Net|  
_ http://www.lewis.org/~jlewis/pgp for PGP public key_

RE: 69/8...this sucks

[Scott Granados]

I think Rob's server scans all the registry web pages for announced
changes and then either modifies the list automatically or sets off an
alarm to have the pages and list modified.  I may be corrected but I think
the process is either entirely or mostly automated.


On Tue, 11 Mar 2003, Owen DeLong wrote:

>
> Great.  If you can get _EVERYONE_ to listen to Rob's server, I'm all for
> it.  Frankly, I was unaware of Rob's server.  However, I think it makes
> more sense to have the people maintaining the data distribute the data
> directly from the source.  Right now, I'm betting that Rob's server requires
> someone in Rob's organization to keep up to date on all the RIRs and
> manually
> tweak the contents of his list.
>
> What is the perceived advantage to the extra layer of indirection?
>
> Owen
>
>
> --On Tuesday, March 11, 2003 1:11 PM -0500 Andy Dills <[EMAIL PROTECTED]> wrote:
>
> > On Tue, 11 Mar 2003, Owen DeLong wrote:
> >
> >>
> >> In short, it doesn't.  Longer answer, if the ISP configures his router
> >> correctly, he can actually refuse to accept advertisements from other
> >> sessions that are longer versions of prefixes received through this
> >> session.
> >>
> >> However, it's primarily intended to solve the non-malicious, but somewhat
> >> malignant problem of out-of-date bogon filters by people trying to do the
> >> right thing.
> >
> > So why does it need to be done by somebody "official"? Why make
> > organizations who don't have route servers do this?
> >
> > I've been peering with Rob's bogon server for a little while, and it works
> > great. All of my customers get routes that point the bogons to a traffic
> > sink on my network. If they were so inclined, they could sink that traffic
> > before leaving their network.
> >
> > Andy
> >
> > 
> > Andy Dills  301-682-9972
> > Xecunet, LLCwww.xecu.net
> > 
> > Dialup * Webhosting * E-Commerce * High-Speed Access
> >
>
>
>

RE: 69/8...this sucks

[Rob Thomas]

Hi again, Owen.

] Frankly, I was unaware of Rob's server.

For everyone who hasn't received our copious spam.  :)

http://www.cymru.com/Bogons/

] Right now, I'm betting that Rob's server requires someone in Rob's
] organization to keep up to date on all the RIRs and manually tweak
] the contents of his list.

Actually it requires one server and the tireless service of cron for
most of the work.  :)  However, two of us eyeball it before any
changes are applied.  Better safe than sorry.

While I agree that an "authoritative body" would be best to host
this service, I'm happy to provide it for as long as there is a need.

This is a free service, and not at all cumbersome to the members of
Team Cymru.

Thanks,
Rob.
-- 
Rob Thomas
http://www.cymru.com
ASSERT(coffee != empty);

RE: 69/8...this sucks

[Owen DeLong]

Great.  If you can get _EVERYONE_ to listen to Rob's server, I'm all for
it.  Frankly, I was unaware of Rob's server.  However, I think it makes
more sense to have the people maintaining the data distribute the data
directly from the source.  Right now, I'm betting that Rob's server requires
someone in Rob's organization to keep up to date on all the RIRs and 
manually
tweak the contents of his list.

What is the perceived advantage to the extra layer of indirection?

Owen

--On Tuesday, March 11, 2003 1:11 PM -0500 Andy Dills <[EMAIL PROTECTED]> wrote:

On Tue, 11 Mar 2003, Owen DeLong wrote:

In short, it doesn't.  Longer answer, if the ISP configures his router
correctly, he can actually refuse to accept advertisements from other
sessions that are longer versions of prefixes received through this
session.
However, it's primarily intended to solve the non-malicious, but somewhat
malignant problem of out-of-date bogon filters by people trying to do the
right thing.
So why does it need to be done by somebody "official"? Why make
organizations who don't have route servers do this?
I've been peering with Rob's bogon server for a little while, and it works
great. All of my customers get routes that point the bogons to a traffic
sink on my network. If they were so inclined, they could sink that traffic
before leaving their network.
Andy


Andy Dills  301-682-9972
Xecunet, LLCwww.xecu.net

Dialup * Webhosting * E-Commerce * High-Speed Access

Re: 69/8...this sucks

[Owen DeLong]

Look, there's no quick fix solution here.  It's going to take real
effort and real work.  However, the _REASON_ all those pages reference
sample bogon filters is because there isn't a global bogon filter
that is dynamically updated available.  If there was, and people were
aware of it, they'd use it.  (At least a significant percentage would).
As such, is a BGP feed a panacea?  No.  Is it a step in the right direction?
Yes.  Will it solve the problem by itself?  No.  Will it improve the 
situation?
Yes.  Moving the root servers into that space may expidite solving the 
problem,
but at a _VERY_ significant cost.  Moving the GTLD servers might make a 
little
more sense (at least then, you aren't requireing _EVERYONE_ to update their
hint files), but I still don't think that's a good idea.

Others have suggested that it needs to be available in LDAP.  Some have
suggested DNS.  As far as I'm concerned, the same servers or some group
of servers could easily be set up to publish the authoritative BOGON list
via DNS, BGP, LDAP, HTTP(XML), FTP, and possibly other protocols.
Getting bogged down in the protocol isn't helpful.  Finding a way to make
an authoritative global BOGON list (Note: BOGONS are the 
UNALLOCATED/UNASSIGNED/
RESERVED/INVALID _LARGE_ blocks, _NOT_ every little hole in the allocation
space) that is dynamically updated _IS_ the most practical solution for the
long haul.

Renumbering multiple global resources every time an RIR starts issuing from 
a
new /8 isn't feasible.

Publishing the data over the net is.

Owen

--On Tuesday, March 11, 2003 10:06 AM -0800 Joe Boyce <[EMAIL PROTECTED]> 
wrote:



Monday, March 10, 2003, 7:44:43 PM, you wrote:

H> Well... I am pretty sure Tier1 backbones are up-to-date on the bogon
H> filters :-)
H> As we've already discussed, it's really the smaller networks with
outdated H> bogons or with admins who don't know what they are doing..
Bingo.  No silly bgp feed will fix this problem.  The problem is
all of the small customer networks that have been setup where the
admin at the time installed a slick firewall using what was then
current information and then walked away.
I only see three ways to deal with this issue:

1.  Contact each customer net that we find that is filtering on
outdated information.  I'm sure only the operators that have been
assigned 69/8 space will start doing this (and have), since we are in
fact responding to customer complaints.  This process should be
complete in say, oh, ten years or so.  That should give us enough time
to track them all down.
Oh while we are at that, we might want to contact every operator of
websites that are displaying "sample" firewalls using ipchains,
iptables or ipfw that show 69/8 as a bogon network.  We'll need to get
them to change those webpages to show correct information.  I mean,
why have that information out there so some other clueless admin can
simply start a fresh problem for us.  I figure a couple of years to
fix this too.
2.  Find a way to break all of those customers networks that filter
69/8 so that the response time to fix it is much less than the time
to contact each and every operator.  The only way to do that is to
move something like the root servers into this space.  Yes it's crazy
but it's the only way to break smaller networks.  But once joe sixpack
wonders why he can't get to Yahoo this morning and calls his
consultant, the problem would be resolved a lot faster than it will
take us to track them down and do option 1.
3.  Have us 69/8 address assignees simply live with the problem and
stop complaining in forums such as this.  We're the ones dealing with
the end user complaints about lost connectivity to sites once we've
renumbering a link into this range.  This goes back to option number
1, we'll simply bite the bullet and live with the problem and fix them
as we find them.
I'll admit, I run a small network and was quite happy to receive my
first ARIN assignment some months ago.  I wasn't so happy to find out
that once I renumbered our internal office workstations into this
range I had complaints from other employees about sites they could not
reach (starting with *.ca.gov).  I haven't even put one customer net
into this new range yet and I've already reacted to a couple of dozen
problems that less than 20 employees have found.  I'm honestly scared
to death about renumbering all of my customers now.
H> I think we are just going around the circle/preaching to the choir on
the H> same topic here.. Is this like what... 3rd time we are discussing
H> this whole 69/8 issue :-D? Really, someone needs to get out this 69/8
H> issue on the press.. Just a thought.. heh
I had an email sent to me from a writer from circleid.com (Joe
Baptista) back in late December regarding this issue when the problem
first popped up on Nanog.  As far as I can remember he was going to
write up an article on this situation.  I have no idea what became of
that.
Regards,

Joe Boyce
---
InterStar, Inc. - Shasta.com Internet
Phon

Re: 69/8...this sucks -- Centralizing filtering..

[Iljitsch van Beijnum]

On Tue, 11 Mar 2003, Peter Galbavy wrote:

> > If all routes in the routing table are good (which soBGP and S-BGP can
> > do for you) and routers filter based on the contents of the routing
> > table, hosts will not see any bogon packets except locally generated
> > ones so they shouldn't have bogon filters of their own.

> I believe you are confusing authentication with authorisation.

I don't think I am.

> Having authentic routes does not imply that all the traffic will be
> 'correct'. Various networks will always fail to filter customer traffic at
> ingress etc. and then source address spoofing becomes trivial.

I don't see your point. Packets with bogon sources are just one class of
spoofed packets. As I've explained earlier S-BGP or soBGP with uRPF will
get rid of bogons. Neither this or bogon filters on the host will do
anything against non-bogon spoofed packets.

Re: 69/8...this sucks -- Centralizing filtering..

[Stephen Sprunk]

Thus spake "Ray Bellis" <[EMAIL PROTECTED]>
> Most people seem to think it would be impractical to put the root name
> servers in 69.0.0.0/8
>
> Why not persuade ARIN to put whois.arin.net in there instead?  It
> shouldn't take the people with the broken filters *too* long to figure
> out why they can't do IP assignment lookups...

I'd bet most of the people with broken filters have never heard of ARIN and
still think "the InterNIC" assigns addresses.  We're talking about people
with no network staff; directing technical solutions at the people oblivious
to technology is difficult stuff.

S

Stephen Sprunk "God does not play dice."  --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSSdice at every possible opportunity." --Stephen Hawking

RE: 69/8...this sucks

[Andy Dills]

On Tue, 11 Mar 2003, Owen DeLong wrote:

>
> In short, it doesn't.  Longer answer, if the ISP configures his router
> correctly, he can actually refuse to accept advertisements from other
> sessions that are longer versions of prefixes received through this session.
>
> However, it's primarily intended to solve the non-malicious, but somewhat
> malignant problem of out-of-date bogon filters by people trying to do the
> right thing.

So why does it need to be done by somebody "official"? Why make
organizations who don't have route servers do this?

I've been peering with Rob's bogon server for a little while, and it works
great. All of my customers get routes that point the bogons to a traffic
sink on my network. If they were so inclined, they could sink that traffic
before leaving their network.

Andy


Andy Dills  301-682-9972
Xecunet, LLCwww.xecu.net

Dialup * Webhosting * E-Commerce * High-Speed Access

Re: 69/8...this sucks

[Joe Boyce]

Monday, March 10, 2003, 7:44:43 PM, you wrote:

H> Well... I am pretty sure Tier1 backbones are up-to-date on the bogon
H> filters :-)
H> As we've already discussed, it's really the smaller networks with outdated
H> bogons or with admins who don't know what they are doing..

Bingo.  No silly bgp feed will fix this problem.  The problem is
all of the small customer networks that have been setup where the
admin at the time installed a slick firewall using what was then
current information and then walked away.

I only see three ways to deal with this issue:

1.  Contact each customer net that we find that is filtering on
outdated information.  I'm sure only the operators that have been
assigned 69/8 space will start doing this (and have), since we are in
fact responding to customer complaints.  This process should be
complete in say, oh, ten years or so.  That should give us enough time
to track them all down.

Oh while we are at that, we might want to contact every operator of
websites that are displaying "sample" firewalls using ipchains,
iptables or ipfw that show 69/8 as a bogon network.  We'll need to get
them to change those webpages to show correct information.  I mean,
why have that information out there so some other clueless admin can
simply start a fresh problem for us.  I figure a couple of years to
fix this too.

2.  Find a way to break all of those customers networks that filter
69/8 so that the response time to fix it is much less than the time
to contact each and every operator.  The only way to do that is to
move something like the root servers into this space.  Yes it's crazy
but it's the only way to break smaller networks.  But once joe sixpack
wonders why he can't get to Yahoo this morning and calls his
consultant, the problem would be resolved a lot faster than it will
take us to track them down and do option 1.

3.  Have us 69/8 address assignees simply live with the problem and
stop complaining in forums such as this.  We're the ones dealing with
the end user complaints about lost connectivity to sites once we've
renumbering a link into this range.  This goes back to option number
1, we'll simply bite the bullet and live with the problem and fix them
as we find them.

I'll admit, I run a small network and was quite happy to receive my
first ARIN assignment some months ago.  I wasn't so happy to find out
that once I renumbered our internal office workstations into this
range I had complaints from other employees about sites they could not
reach (starting with *.ca.gov).  I haven't even put one customer net
into this new range yet and I've already reacted to a couple of dozen
problems that less than 20 employees have found.  I'm honestly scared
to death about renumbering all of my customers now.

H> I think we are just going around the circle/preaching to the choir on the
H> same topic here.. Is this like what... 3rd time we are discussing
H> this whole 69/8 issue :-D? Really, someone needs to get out this 69/8
H> issue on the press.. Just a thought.. heh

I had an email sent to me from a writer from circleid.com (Joe
Baptista) back in late December regarding this issue when the problem
first popped up on Nanog.  As far as I can remember he was going to
write up an article on this situation.  I have no idea what became of
that.

Regards,

Joe Boyce
---
InterStar, Inc. - Shasta.com Internet
Phone: +1 (530) 224-6866 x105
Email: [EMAIL PROTECTED]

RE: 69/8...this sucks

[Owen DeLong]

In short, it doesn't.  Longer answer, if the ISP configures his router
correctly, he can actually refuse to accept advertisements from other
sessions that are longer versions of prefixes received through this session.
However, it's primarily intended to solve the non-malicious, but somewhat
malignant problem of out-of-date bogon filters by people trying to do the
right thing.
Owen

Er, guys...  How does this fix the problem of a Malicious user
advertising a more specific bogon route?
-Original Message-
From: Owen DeLong [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 11, 2003 11:22 AM
To: Stephen J. Wilcox
Cc: [EMAIL PROTECTED]
Subject: Re: 69/8...this sucks


On Mon, 10 Mar 2003, Owen DeLong wrote:

It seems to me that it would be relatively simple to solve this problem
by doing the following:
1.  ICANN (or an ICANN designee, such as ARIN) shall issue an ASN range
of 20 ASNs to be used as BOGON-ORIGINATE.
Why not just one or private/reserved?

Because I think there is value in each RIR having their own AS to peer
EBGP with the other RIR's.  I have no problem with this comming from
reserved ASN space (that would be up to ICANN where they pull it from).
As to private, it would have two problems.  One, it would violate the
RFC for private ASNs, and, two, it would likely conflict with existing
internal uses of private ASNs at some carriers.
2.  Each RIR should operate one or more routers with an open peering
policy which will perform the following functions:
A.  Advertise all unissued space allocated to the RIR as
originating from an ASN allocated to -BOGON.
B.  Peer with the corresponding routers at each of the other
RIRs and accept and readvertise their BOGON list through
BGP.
C.  Provide a full BOGON feed to any router that chooses to
peer, but not accept any routes or non-BGP traffic from
those routers.
Of course, configure it wrong and you would end up sending all the junk
that you  would have null routed to your RIR. Sounds messy.
I think there are ways for the RIR to protect themselves from this.

Whats more I can see potential whenever we start creating these kind of
self  propagating blackholes for hackers to introduce genuine address
blocks to create  a DDoS.
Only if the hacker manages to own one or more of the RIR routers providing
the feed.  Remember, they will be configured not to listen to _ANY_
advertisement from any routers other than the other RIR routers that are
known to provide equivalant service for the other RIRs.  As such, assuming
the RIRs run the routers with reasonable security precautions, I don't see
this as being any more of a DDoS risk than any large backbone provider
you can name today.


3.  Any provider which wishes to filter BOGONs could peer with the
closest one or two of these and set up route maps that modify
the next-hop for all BOGONs to be an address which is statically
routed to NULL0 on each of their routers.
How many ebgp sessions do the RIRs need to maintain?? A lot.. and the
maintenance would be a nightmare. Dont think this will work purely
because of  that overhead you create!!
Nope... Yes, there would be _ALOT_ of ebgp sessions, but they wouldn't
be full-table sessions.  They'd be send-only with a small number of
prefixes representing the bogon space.  Also, it is possible to configure
most routers to peer with "all comers" and assign the ones that don't
have a specific configuration to a default peer group.  That peer group
would be configured to advertise-only the bogon list and accept nothing.
With that configuration, the maintenance is near nil.
Owen

Steve

Apologies if this has been discussed before, but, it seems to me that
this is the easiest way to make the data readily available to the
community directly from the maintainers of the databases in a fashion
which is automatically up to date.
There are other ways that dont use BGP peering to create lists that are
more  suitable
Steve

RE: 69/8...this sucks

[Andy Dills]

On Tue, 11 Mar 2003, Ejay Hire wrote:

> Er, guys...  How does this fix the problem of a Malicious user
> advertising a more specific bogon route?

Come on...clearly you haven't been paying attention.

You need LDAP filters. LDAP filters and a South Vietnamese revolution
against the IRRs for being fragmented and greedy.

And if that doesn't poison your inverse arp, then multiplex a private
bogon server with a centralized host scanner-based DNSBL. Don't forget the
trailing dot! And don't forget to invert the subnet mask!

Andy


Andy Dills  301-682-9972
Xecunet, LLCwww.xecu.net

Dialup * Webhosting * E-Commerce * High-Speed Access

RE: 69/8...this sucks

[Ejay Hire]

Er, guys...  How does this fix the problem of a Malicious user advertising a more 
specific bogon route?

-Original Message-
From: Owen DeLong [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 11, 2003 11:22 AM
To: Stephen J. Wilcox
Cc: [EMAIL PROTECTED]
Subject: Re: 69/8...this sucks



> On Mon, 10 Mar 2003, Owen DeLong wrote:
>
>> It seems to me that it would be relatively simple to solve this problem
>> by doing the following:
>>
>> 1.   ICANN (or an ICANN designee, such as ARIN) shall issue an ASN range
>>  of 20 ASNs to be used as BOGON-ORIGINATE.
>
> Why not just one or private/reserved?
>
Because I think there is value in each RIR having their own AS to peer
EBGP with the other RIR's.  I have no problem with this comming from
reserved ASN space (that would be up to ICANN where they pull it from).
As to private, it would have two problems.  One, it would violate the
RFC for private ASNs, and, two, it would likely conflict with existing
internal uses of private ASNs at some carriers.

>> 2.   Each RIR should operate one or more routers with an open peering
>>  policy which will perform the following functions:
>>
>>  A.  Advertise all unissued space allocated to the RIR as
>>  originating from an ASN allocated to -BOGON.
>>
>>  B.  Peer with the corresponding routers at each of the other
>>  RIRs and accept and readvertise their BOGON list through
>>  BGP.
>>
>>  C.  Provide a full BOGON feed to any router that chooses to
>>  peer, but not accept any routes or non-BGP traffic from
>>  those routers.
>
> Of course, configure it wrong and you would end up sending all the junk
> that you  would have null routed to your RIR. Sounds messy.
>
I think there are ways for the RIR to protect themselves from this.

> Whats more I can see potential whenever we start creating these kind of
> self  propagating blackholes for hackers to introduce genuine address
> blocks to create  a DDoS.
>
Only if the hacker manages to own one or more of the RIR routers providing
the feed.  Remember, they will be configured not to listen to _ANY_
advertisement from any routers other than the other RIR routers that are
known to provide equivalant service for the other RIRs.  As such, assuming
the RIRs run the routers with reasonable security precautions, I don't see
this as being any more of a DDoS risk than any large backbone provider
you can name today.

>>
>>
>> 3.   Any provider which wishes to filter BOGONs could peer with the
>>  closest one or two of these and set up route maps that modify
>>  the next-hop for all BOGONs to be an address which is statically
>>  routed to NULL0 on each of their routers.
>
> How many ebgp sessions do the RIRs need to maintain?? A lot.. and the
> maintenance would be a nightmare. Dont think this will work purely
> because of  that overhead you create!!
>
Nope... Yes, there would be _ALOT_ of ebgp sessions, but they wouldn't
be full-table sessions.  They'd be send-only with a small number of
prefixes representing the bogon space.  Also, it is possible to configure
most routers to peer with "all comers" and assign the ones that don't
have a specific configuration to a default peer group.  That peer group
would be configured to advertise-only the bogon list and accept nothing.
With that configuration, the maintenance is near nil.

Owen

> Steve
>
>> Apologies if this has been discussed before, but, it seems to me that
>> this is the easiest way to make the data readily available to the
>> community directly from the maintainers of the databases in a fashion
>> which is automatically up to date.
>
> There are other ways that dont use BGP peering to create lists that are
> more  suitable
>
> Steve
>

Re: 69/8...this sucks -- Centralizing filtering..

[Peter Galbavy]

> If all routes in the routing table are good (which soBGP and S-BGP can
> do for you) and routers filter based on the contents of the routing
> table, hosts will not see any bogon packets except locally generated
> ones so they shouldn't have bogon filters of their own. So this will
> indeed solve the problem for these people.

I believe you are confusing authentication with authorisation.

Having authentic routes does not imply that all the traffic will be
'correct'. Various networks will always fail to filter customer traffic at
ingress etc. and then source address spoofing becomes trivial.

Peter

Re: 69/8...this sucks

[Owen DeLong]

--On Tuesday, March 11, 2003 11:18 AM + [EMAIL PROTECTED] 
wrote:


2. Each RIR should operate one or more routers with an open
peering
   policy which will perform the following functions:
I agree that the RIR is the right source for the data but I think that
BGP  is the wrong protocol for publishing the data. Would you give a BGP
feed  to all of your customers so that they can inject up-to-date bogons
into  their firewall configs? Probably not and besides, the enterprise
folks  wouldn't have a clue what to do with BGP in the first place.
That's why I  have suggested using LDAP to publish the data.
Nothing in my proposal precludes the data from being published via LDAP,
but, if you think the enterprise wouldn't know how to handle the data via
BGP, I gotta tell you, LDAP is much more difficult in my experience.
As to publishing the data to customers, sure.  Why not.  See my previous
post about all-comers BGP peer-groups.
Apologies if this has been discussed before, but, it seems to me that
this
is the easiest way to make the data readily available to the community
directly from the maintainers of the databases in a fashion which is
automatically up to date.
At this point a lot if people agree that the data needs to come directly
from the database maintainers, in our case that's ARIN. And people also
seem to agree that keeping the data automatically up to date is a good
thing. We still have some discussion as to which protocol to use for
publishing the data. I suggest that what is needed now is to engage ARIN
in the discussion and get this on the agenda with them. Technical details
can be worked out later, but now we need a commitment from ARIN that they
can and will make this data available and keep it up to date.
I don't see any reason we have to pick _A_ protocol.  As far as I'm 
concerned,
it could easily be published via LDAP, DNS, _AND_ BGP.  I am already working
on drafting a policy proposal.

Owen

--Michael Dillon

Re: 69/8...this sucks

[Owen DeLong]

On Mon, 10 Mar 2003, Owen DeLong wrote:

It seems to me that it would be relatively simple to solve this problem
by doing the following:
1.  ICANN (or an ICANN designee, such as ARIN) shall issue an ASN range
of 20 ASNs to be used as BOGON-ORIGINATE.
Why not just one or private/reserved?

Because I think there is value in each RIR having their own AS to peer
EBGP with the other RIR's.  I have no problem with this comming from
reserved ASN space (that would be up to ICANN where they pull it from).
As to private, it would have two problems.  One, it would violate the
RFC for private ASNs, and, two, it would likely conflict with existing
internal uses of private ASNs at some carriers.
2.  Each RIR should operate one or more routers with an open peering
policy which will perform the following functions:
A.  Advertise all unissued space allocated to the RIR as
originating from an ASN allocated to -BOGON.
B.  Peer with the corresponding routers at each of the other
RIRs and accept and readvertise their BOGON list through
BGP.
C.  Provide a full BOGON feed to any router that chooses to
peer, but not accept any routes or non-BGP traffic from
those routers.
Of course, configure it wrong and you would end up sending all the junk
that you  would have null routed to your RIR. Sounds messy.
I think there are ways for the RIR to protect themselves from this.

Whats more I can see potential whenever we start creating these kind of
self  propagating blackholes for hackers to introduce genuine address
blocks to create  a DDoS.
Only if the hacker manages to own one or more of the RIR routers providing
the feed.  Remember, they will be configured not to listen to _ANY_
advertisement from any routers other than the other RIR routers that are
known to provide equivalant service for the other RIRs.  As such, assuming
the RIRs run the routers with reasonable security precautions, I don't see
this as being any more of a DDoS risk than any large backbone provider
you can name today.


3.  Any provider which wishes to filter BOGONs could peer with the
closest one or two of these and set up route maps that modify
the next-hop for all BOGONs to be an address which is statically
routed to NULL0 on each of their routers.
How many ebgp sessions do the RIRs need to maintain?? A lot.. and the
maintenance would be a nightmare. Dont think this will work purely
because of  that overhead you create!!
Nope... Yes, there would be _ALOT_ of ebgp sessions, but they wouldn't
be full-table sessions.  They'd be send-only with a small number of
prefixes representing the bogon space.  Also, it is possible to configure
most routers to peer with "all comers" and assign the ones that don't
have a specific configuration to a default peer group.  That peer group
would be configured to advertise-only the bogon list and accept nothing.
With that configuration, the maintenance is near nil.
Owen

Steve

Apologies if this has been discussed before, but, it seems to me that
this is the easiest way to make the data readily available to the
community directly from the maintainers of the databases in a fashion
which is automatically up to date.
There are other ways that dont use BGP peering to create lists that are
more  suitable
Steve

Re: 69/8...this sucks -- Centralizing filtering..

[Iljitsch van Beijnum]

On Tue, 11 Mar 2003, Jack Bates wrote:

> > Fortunately, in this particular case there is a solution on the horizon:
> > S-BGP or soBGP. These BGP extensions authenticate all prefix
> > announcements, so there is no longer any need to perform bogon filtering
> > on routing information. uRPF can then be used to filter packets based on
> > the contents of the routing table.

> A majority of the filters in place are not BGP filters.

Let's stay focussed on the problem at hand. Or are you saying that most
of the _bogon_ filters aren't BGP filters?

> They are firewall
> rulesets designed to filter out hijacked and spoofed IP addresses to limit
> DOS and illegitimate connections. S-BGP and soBGP will not solve the problem
> for these people.

If all routes in the routing table are good (which soBGP and S-BGP can
do for you) and routers filter based on the contents of the routing
table, hosts will not see any bogon packets except locally generated
ones so they shouldn't have bogon filters of their own. So this will
indeed solve the problem for these people.

RE: 69/8...this sucks -- Centralizing filtering..

[Owen DeLong]

Thanks for your support Jim.  I've gotten mixed feedback to my proposal
here for a centralized bogon filter from the RIRs via BGP, but I will
say there's been more support than opposition.  (Most of the support has
been sent to me, not the list, while most of the opposition has been
to the list, however).
I know it's too late to get it into the Memphis meeting, but I think, based
on the amount of support it has received, that I will submit a policy
proposal to ARIN in support of creating the requisite BGP feeds.  I realize
that an ARIN policy alone won't do this (the other RIRs would have to follow
suit), but, if ARIN adopts it, I don't think it will be too hard to get the
other RIRs to follow.  I'm also not familiar with the policy process in the
other RIRs.
I absolutely agree with you about the whois contact stuff.  I think it might
make sense eventually to put a similar requirement for current information 
on
the admin and tech contact, although I don't see putting the same response
and performance strictures on them.  For now, I'm trying to address large
issues in small enogh pieces to get rough consensus around the solution to
each small piece.  Trying to solve the big problems all at once never seems
to achieve rough consensus.

Owen

--On Monday, March 10, 2003 11:19 PM -0500 "McBurnett, Jim" 
<[EMAIL PROTECTED]> wrote:


From Chris Adams:
This isn't meant to be a pick on you (we've got some SWIPs filed
incorrectly that we are working on).  I've just run into more and more
cases where ARIN (or other RIR, but I'm typically interested in ARIN
info) info is out of date.  Maybe ARIN should periodically
send an "are
you there" type email to contacts (like some mailing lists
do).  If that
fails, mail a letter with instructions on how to update your contact
info, and if that fails, delete the invalid contact info - I'd rather
see no contact info than bogus info.
Chris,
If you read PPML, there is a HUGE push via Owen DeLong's Policy
2003-1a to help with some aspects of the whois Contact..
his policy is mainly based on the abuse contact, But I think may
get extended to all contacts eventually...
Owen- Wanta jump in here???
And-- if you feel strong enough to be flamed on the ARIN PPML list
propose a Policy based on your comments.. I for one agree with you..
just give 2 or 3 tries.. If it fails once - retry 24 hours if
it fails again retry 48 hours. If it fails again.. 3 strikes and
your out in the old ball game (add in the music from "take me out to
the ballgame")
Later,
J
That's my 10 cents worth- ya know inflation gets us everywhere...

RE: 69/8...this sucks -- Centralizing filtering..

[Michael Whisenant]

Well Jon,

I spent some time reading your message below, and trying to look
at if I experienced the issue, just what I would have done differently, or
what would have been more meaningful in your initial email blast... Here
are some of my thoughts...

First since you are taking the time to explore where your routes
are reaching, why not send the end user (yes your approach contacts the
end user of the IP addres block not the network provider) a traceroute
showing where the problem is first encountered? Now granted some places
may filter ICMP messages, but it is some more information from which the
end user can start addressing the problem?

Next I would suggest that you look at the tone of your message to
make sure that the reader understands that you have an issue and that you
would like his assistance. Sometimes emails can be viewed as HARSH when
they are meant to be informative and helpful in getting the issue
corrected.

I would personally have run a traceroute with the NANOG traceroute
and also copied the Network ASN where the packets seems to have stopped.
After all that is the most likely source of the filter, right? When I
received your original message that is the first think that I did from an
off network account. You mention that we should update our ARIN listing...
well I do not disagree, but the subnet where the packets stopped would
have had a noc email with 24x7 number to call. Then again so would have
the ASN where the traceroute stopped.

Yes I think that there is interest in understanding new subnet
allocations have universal routing. Clearly in this case when addressing
was first allocted in Aug 2002 this should have become and issue by now...
You suggest that ARIN should do more (lets expand this to any RR), what
would you suggest they do? Do you plan to be at the ARIN meeting in April?
We would welcome your views on this topic be addressed... Take it to a
ARIN advisory council member if you do not plan to attend, they can
champion your cause... they do it well...

On Mon, 10 Mar 2003 [EMAIL PROTECTED] wrote:

> On Mon, 10 Mar 2003, Michael Whisenant wrote:
>
> > First I appreciate your message that you sent to us at NASA late Friday
> > regarding a new address block that you received from ARIN. In that message
> > you suggest that the issue was a BOGON route filter that had not been
> > updated. Then without allowing sufficient time to respond to your message
> > (you sent it to an administrative account and not the NOC) you decided to
> > flame NASA.
>
> My mention of NASA wasn't meant at all as a flame.  It was just an example
> that not all the networks with outdated filters are remote nets in far
> away countries that my customers wouldn't care about.  A few I've
> found are.  I had to look up the country code to find that .al is Albania.
>
> I had actually planned to mention at some point that NASA was the first
> (only so far) network to respond to the few messages I sent out late last
> friday, and that their reported network has already been fixed.  I can
> only assume that none of the previous 94 allocation holders of 69/8 space
> noticed or complained to the right people.
>
> > If you feel that you have any issue reaching a NASA resource then you can
> > send a message to [EMAIL PROTECTED] and/or the tech/org/noc POC on any
> > address space. NISN is NASA's ISP and as such announce via AS297 that
> > address space.
>
> As for sending the message to the wrong addresses, I can only suggest
> updating your ARIN info.  I sent the message to all the POCs (except the
> abuse one) for the relevant NetRange.  This is what I'll be doing when I
> send out the automated messages.  The ones sent friday were done by hand.
>
> Can you elaborate on how a firewall config was the problem?  If whatever
> was done there is commonly done, it may be worth revising my form message
> before I send out a large number of them.
>
> --
>  Jon Lewis [EMAIL PROTECTED]|  I route
>  System Administrator|  therefore you are
>  Atlantic Net|
> _ http://www.lewis.org/~jlewis/pgp for PGP public key_
>
>

Re: 69/8...this sucks -- Centralizing filtering..

[Jack Bates]

From: "Iljitsch van Beijnum"

> Fortunately, in this particular case there is a solution on the horizon:
> S-BGP or soBGP. These BGP extensions authenticate all prefix
> announcements, so there is no longer any need to perform bogon filtering
> on routing information. uRPF can then be used to filter packets based on
> the contents of the routing table.
>
A majority of the filters in place are not BGP filters. They are firewall
rulesets designed to filter out hijacked and spoofed IP addresses to limit
DOS and illegitimate connections. S-BGP and soBGP will not solve the problem
for these people.

-Jack

RE: 69/8...this sucks -- Centralizing filtering..

[Iljitsch van Beijnum]

On Mon, 10 Mar 2003, Todd A. Blank wrote:

> I continue to agree that moving critical resources (see below) to these
> new blocks is the best approach I have seen or heard in the months since
> I made the original post.  This approach punishes the clueless instead
> of the people that already know what the problem is (and have to live
> with it every day).

I think this illustrates very well that the concept of filtering on
statically configured IP address ranges is severely broken and needs to
be replaced with something better.

Fortunately, in this particular case there is a solution on the horizon:
S-BGP or soBGP. These BGP extensions authenticate all prefix
announcements, so there is no longer any need to perform bogon filtering
on routing information. uRPF can then be used to filter packets based on
the contents of the routing table.

In the mean time, I think we need a good best practices document. Way
too many people simply don't know about these kinds of issues, or worse,
know only half, and having a single, authorative set of guidelines would
be extremely helpful, even if it doesn't magically make the problem
disappear.

> I have seen this suggestion once before (maybe even by Jon) and I still
> think it is the best way things will get resolved quickly.

> Maybe we should suggest that ARIN also host some of their stuff on this
> block :-)

Or maybe list the offending IP addresses/ranges in the anti-spam lists?
This should get people's attention without breaking too much important
stuff (who needs email anyway).

Re: 69/8...this sucks

[Michael . Dillon]

> 2. Each RIR should operate one or more routers with an open 
peering
>policy which will perform the following functions:

I agree that the RIR is the right source for the data but I think that BGP 
is the wrong protocol for publishing the data. Would you give a BGP feed 
to all of your customers so that they can inject up-to-date bogons into 
their firewall configs? Probably not and besides, the enterprise folks 
wouldn't have a clue what to do with BGP in the first place. That's why I 
have suggested using LDAP to publish the data. 

>Apologies if this has been discussed before, but, it seems to me that 
this
>is the easiest way to make the data readily available to the community
>directly from the maintainers of the databases in a fashion which is
>automatically up to date.

At this point a lot if people agree that the data needs to come directly 
from the database maintainers, in our case that's ARIN. And people also 
seem to agree that keeping the data automatically up to date is a good 
thing. We still have some discussion as to which protocol to use for 
publishing the data. I suggest that what is needed now is to engage ARIN 
in the discussion and get this on the agenda with them. Technical details 
can be worked out later, but now we need a commitment from ARIN that they 
can and will make this data available and keep it up to date.

--Michael Dillon

Re: 69/8...this sucks

[Stephen J. Wilcox]

On Mon, 10 Mar 2003, Owen DeLong wrote:

> It seems to me that it would be relatively simple to solve this problem by
> doing the following:
> 
> 1.ICANN (or an ICANN designee, such as ARIN) shall issue an ASN range
>   of 20 ASNs to be used as BOGON-ORIGINATE.

Why not just one or private/reserved?

> 2.Each RIR should operate one or more routers with an open peering
>   policy which will perform the following functions:
> 
>   A.  Advertise all unissued space allocated to the RIR as
>   originating from an ASN allocated to -BOGON.
> 
>   B.  Peer with the corresponding routers at each of the other
>   RIRs and accept and readvertise their BOGON list through
>   BGP.
> 
>   C.  Provide a full BOGON feed to any router that chooses to
>   peer, but not accept any routes or non-BGP traffic from
>   those routers.

Of course, configure it wrong and you would end up sending all the junk that you 
would have null routed to your RIR. Sounds messy.

Whats more I can see potential whenever we start creating these kind of self 
propagating blackholes for hackers to introduce genuine address blocks to create 
a DDoS.

> 
> 
> 3.Any provider which wishes to filter BOGONs could peer with the
>   closest one or two of these and set up route maps that modify
>   the next-hop for all BOGONs to be an address which is statically
>   routed to NULL0 on each of their routers.

How many ebgp sessions do the RIRs need to maintain?? A lot.. and the 
maintenance would be a nightmare. Dont think this will work purely because of 
that overhead you create!!

Steve

> Apologies if this has been discussed before, but, it seems to me that this
> is the easiest way to make the data readily available to the community
> directly from the maintainers of the databases in a fashion which is
> automatically up to date.

There are other ways that dont use BGP peering to create lists that are more 
suitable

Steve

Re: 69/8...this sucks

[Stephen J. Wilcox]

On Mon, 10 Mar 2003, E.B. Dreger wrote:

> The suggestion is to move ALL root, and as many TLD as possible,
> servers into the new space.  Nobody has said "move one or two",
> which indeed would be ineffective.

So, you cant get people to fix bogons but you can get them all to fix their dns 
cache files overnight. I dont think so.

And you want to push all the critical servers into a narrow set of IPs, that 
surely must have some implications for DoS more so than a well spread out set.

I dont think your being realistic here and thinking thro properly..

Steve

Re: 69/8...this sucks

[Hank Nussbacher]

At 05:16 PM 10-03-03 -0800, Owen DeLong wrote:

OK... I'm late to this discussion (been mostly ignoring it due to volume in
other places), but, Sean's 911->855 mail makes me wonder...
It seems to me that it would be relatively simple to solve this problem by
doing the following:
1.  ICANN (or an ICANN designee, such as ARIN) shall issue an ASN range
of 20 ASNs to be used as BOGON-ORIGINATE.
2.  Each RIR should operate one or more routers with an open peering
policy which will perform the following functions:
A.  Advertise all unissued space allocated to the RIR as
originating from an ASN allocated to -BOGON.
B.  Peer with the corresponding routers at each of the other
RIRs and accept and readvertise their BOGON list through
BGP.
C.  Provide a full BOGON feed to any router that chooses to
peer, but not accept any routes or non-BGP traffic from
those routers.
3.  Any provider which wishes to filter BOGONs could peer with the
closest one or two of these and set up route maps that modify
the next-hop for all BOGONs to be an address which is statically
routed to NULL0 on each of their routers.
Apologies if this has been discussed before, but, it seems to me that this
is the easiest way to make the data readily available to the community
directly from the maintainers of the databases in a fashion which is
automatically up to date.
As suggested, it has been discussed before.  See:
http://www.ripe.net/ripe/mail-archives/lir-wg/2002/msg00815.html
Unfortunately, the answer I got from RIPE was that they will never do this.
-Hank


Owen

RE: 69/8...this sucks -- Centralizing filtering..

[Dr. Jeffrey Race]

On Mon, 10 Mar 2003 23:19:38 -0500, McBurnett, Jim wrote:
>If you read PPML, there is a HUGE push via Owen DeLong's Policy
>2003-1a to help with some aspects of the whois Contact..
>his policy is mainly based on the abuse contact, But I think may 
>get extended to all contacts eventually...
>Owen- Wanta jump in here???
>
>And-- if you feel strong enough to be flamed on the ARIN PPML list
>propose a Policy based on your comments.. I for one agree with you..

Cleaning up the database, establishing good abuse contacts, and
purging the abusers is the essential first step to the strategy I
draft-outline in .  I hope
volunteers will replicate Owen's efforts at RIPE, APNIC and LACNIC.

As for subject above, all those whose miserable life needs a little
uplift, please turn to  for
your delectation :)

Jeffrey Race

RE: 69/8...this sucks -- Centralizing filtering..

[McBurnett, Jim]

>From Chris Adams:
> This isn't meant to be a pick on you (we've got some SWIPs filed
> incorrectly that we are working on).  I've just run into more and more
> cases where ARIN (or other RIR, but I'm typically interested in ARIN
> info) info is out of date.  Maybe ARIN should periodically 
> send an "are
> you there" type email to contacts (like some mailing lists 
> do).  If that
> fails, mail a letter with instructions on how to update your contact
> info, and if that fails, delete the invalid contact info - I'd rather
> see no contact info than bogus info.
> 

Chris,
If you read PPML, there is a HUGE push via Owen DeLong's Policy
2003-1a to help with some aspects of the whois Contact..
his policy is mainly based on the abuse contact, But I think may 
get extended to all contacts eventually...
Owen- Wanta jump in here???

And-- if you feel strong enough to be flamed on the ARIN PPML list
propose a Policy based on your comments.. I for one agree with you..
just give 2 or 3 tries.. If it fails once - retry 24 hours if
it fails again retry 48 hours. If it fails again.. 3 strikes and 
your out in the old ball game (add in the music from "take me out to 
the ballgame")

Later,
J

That's my 10 cents worth- ya know inflation gets us everywhere...

Re: 69/8...this sucks -- Centralizing filtering..

[Chris Adams]

Once upon a time, Michael Whisenant <[EMAIL PROTECTED]> said:
> You could reach MANY NASA locations, but those at one particular center,
> and that issue was related to a firewall update at ONLY one particular
> center. This filter was placed in after August when the cental bogon was
> removed at the ingress to the network.

The same can be said of many large organizations.

> If you feel that you have any issue reaching a NASA resource then you can
> send a message to [EMAIL PROTECTED] and/or the tech/org/noc POC on any
> address space. NISN is NASA's ISP and as such announce via AS297 that
> address space.

ARIN shows some rather outdated information for some NASA blocks.  For
example, 192.112.230.0/24 still has area code 205 and lists an email
address with a server that no longer exists.  The info listed for
192.112.220.0/22 & 192.112.224.0/20 lists "[EMAIL PROTECTED]" for the
tech contact.

When doing work like this, people are not likely to look in BGP to find
the AS announcing a block and then contact that AS; many ISPs announce
blocks on behalf of their customers and are not necessarily interested
in hearing that a customer has a bogus bogon list.

This isn't meant to be a pick on you (we've got some SWIPs filed
incorrectly that we are working on).  I've just run into more and more
cases where ARIN (or other RIR, but I'm typically interested in ARIN
info) info is out of date.  Maybe ARIN should periodically send an "are
you there" type email to contacts (like some mailing lists do).  If that
fails, mail a letter with instructions on how to update your contact
info, and if that fails, delete the invalid contact info - I'd rather
see no contact info than bogus info.

-- 
Chris Adams <[EMAIL PROTECTED]>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

RE: 69/8...this sucks

[Haesu]

> That's a non-solution that will never happen.  How many networks are going
> to trust joe somebody to inject null routes into their backbone?  Will
> UUNet/Sprint/C&W/Level3/etc. trust me or Rob to tell them what's a bogon
> and what's not?  I really doubt it.  They might have an easier time
> trusting their local RIR, but I wouldn't be surprised if they didn't.

Well... I am pretty sure Tier1 backbones are up-to-date on the bogon
filters :-)

As we've already discussed, it's really the smaller networks with outdated
bogons or with admins who don't know what they are doing..

> Several people pointed that out earlier.  Botched / outdated firewall
> configs may be a bigger problem than BGP filters.  For a glimpse at why,
> see
> http://groups.google.com/groups?q=69.0.0.0%2F8&ie=UTF-8&oe=UTF-8&hl=en&btnG=Google+Search

Yup..

>
> I know some writers watch nanog for potential stories.  Wake up guys, this
> should be one...if not for the news value "ARIN gives out unusable IPs,
> future of the Net in question", then at least for the public service value
> of getting the word out that bogon filters need to be maintained and kept
> up to date or they do more harm than good.

No kidding..

I think we are just going around the circle/preaching to the choir on the
same topic here.. Is this like what... 3rd time we are discussing
this whole 69/8 issue :-D? Really, someone needs to get out this 69/8
issue on the press.. Just a thought.. heh

-hc


>
> --
>  Jon Lewis [EMAIL PROTECTED]|  I route
>  System Administrator|  therefore you are
>  Atlantic Net|
> _ http://www.lewis.org/~jlewis/pgp for PGP public key_
>
>

Re: 69/8...this sucks

[Jack Bates]

From: jlewis
Sent: Monday, March 10, 2003 9:18 PM

> I know some writers watch nanog for potential stories.  Wake up guys, this
> should be one...if not for the news value "ARIN gives out unusable IPs,
> future of the Net in question", then at least for the public service value
> of getting the word out that bogon filters need to be maintained and kept
> up to date or they do more harm than good.
>
And, please in said story, try not to use the term bogon or at least define
it. The term "bogon" gets many funny looks, even from people that have
firewalls filtering them. :)

-Jack

RE: 69/8...this sucks

[jlewis]

On Mon, 10 Mar 2003, Frank Scalzo wrote:

> We don't need the adminstrative headache of ICANN/ARIN/RIRs on this.
> Someone could just do it with a private ASN and advertise the route with
> an arbitrarily null routed next-hop.

That's a non-solution that will never happen.  How many networks are going 
to trust joe somebody to inject null routes into their backbone?  Will 
UUNet/Sprint/C&W/Level3/etc. trust me or Rob to tell them what's a bogon 
and what's not?  I really doubt it.  They might have an easier time 
trusting their local RIR, but I wouldn't be surprised if they didn't.

I realize this sort of thing worked early on with the RBL, but that was 
for a different purpose.  For those who took the RBL via BGP, I suspect 
the benefit of blocking spammers from their networks outweighed the risk 
of RBL abuse and people trusted Vixie to be objective and honest. 

> That doesn't solve the problem of bad filters on firewalls.

Several people pointed that out earlier.  Botched / outdated firewall 
configs may be a bigger problem than BGP filters.  For a glimpse at why, 
see
http://groups.google.com/groups?q=69.0.0.0%2F8&ie=UTF-8&oe=UTF-8&hl=en&btnG=Google+Search

> The problem is lots of books/webpages/templates/etc. say filter bogons.
> People not smart enough to understand the responsibilities of doing so
> implement it and forget it. Instead of trying to beat up on the large

Worse is that there are pages and pages full of links to usenet posts with
these outdated bogon filters.  Books and web pages can be updated.  The
usenet archive isn't going away and won't be revised.  People who don't
know any better are going to continue to misconfigure bogon filters
indefinitely unless something is done to periodically whack some sense
into them.

> Funny the media gets all excited about BGP security and dDos attacks
> against a root nameserver yet no one ever seems to mention the real
> scalability issues like that we can't allocate large parts of the net
> because many network operators aren't bright enough to update filters.

I know some writers watch nanog for potential stories.  Wake up guys, this 
should be one...if not for the news value "ARIN gives out unusable IPs, 
future of the Net in question", then at least for the public service value 
of getting the word out that bogon filters need to be maintained and kept 
up to date or they do more harm than good.

--
 Jon Lewis [EMAIL PROTECTED]|  I route
 System Administrator|  therefore you are
 Atlantic Net|  
_ http://www.lewis.org/~jlewis/pgp for PGP public key_

RE: 69/8...this sucks

[Frank Scalzo]

We don't need the adminstrative headache of ICANN/ARIN/RIRs on this. Someone could 
just do it with a private ASN and advertise the route with an arbitrarily null routed 
next-hop.

That doesn't solve the problem of bad filters on firewalls.

The problem is lots of books/webpages/templates/etc. say filter bogons. People not 
smart enough to understand the responsibilities of doing so implement it and forget 
it. Instead of trying to beat up on the large numbers of people who lack sufficient 
clue, why isn't the pressure turned to the authors that are irresponsibly and blindly 
recommending the wide spread use of these filters? I would think we would have more 
success targeting the people authoring this stuff. There are at most hundreds of 
authors. There is at least thousands of twits...

Funny the media gets all excited about BGP security and dDos attacks against a root 
nameserver yet no one ever seems to mention the real scalability issues like that we 
can't allocate large parts of the net because many network operators aren't bright 
enough to update filters.

Frank

-Original Message-
From: Owen DeLong [mailto:[EMAIL PROTECTED]
Sent: Monday, March 10, 2003 8:16 PM
To: [EMAIL PROTECTED]
Subject: Re: 69/8...this sucks



OK... I'm late to this discussion (been mostly ignoring it due to volume in
other places), but, Sean's 911->855 mail makes me wonder...

It seems to me that it would be relatively simple to solve this problem by
doing the following:

1.  ICANN (or an ICANN designee, such as ARIN) shall issue an ASN range
of 20 ASNs to be used as BOGON-ORIGINATE.

2.  Each RIR should operate one or more routers with an open peering
policy which will perform the following functions:

A.  Advertise all unissued space allocated to the RIR as
originating from an ASN allocated to -BOGON.

B.  Peer with the corresponding routers at each of the other
RIRs and accept and readvertise their BOGON list through
BGP.

C.  Provide a full BOGON feed to any router that chooses to
peer, but not accept any routes or non-BGP traffic from
those routers.


3.  Any provider which wishes to filter BOGONs could peer with the
closest one or two of these and set up route maps that modify
the next-hop for all BOGONs to be an address which is statically
routed to NULL0 on each of their routers.

Apologies if this has been discussed before, but, it seems to me that this
is the easiest way to make the data readily available to the community
directly from the maintainers of the databases in a fashion which is
automatically up to date.

Owen

Re: 69/8...this sucks

[Owen DeLong]

OK... I'm late to this discussion (been mostly ignoring it due to volume in
other places), but, Sean's 911->855 mail makes me wonder...
It seems to me that it would be relatively simple to solve this problem by
doing the following:
1.  ICANN (or an ICANN designee, such as ARIN) shall issue an ASN range
of 20 ASNs to be used as BOGON-ORIGINATE.
2.  Each RIR should operate one or more routers with an open peering
policy which will perform the following functions:
A.  Advertise all unissued space allocated to the RIR as
originating from an ASN allocated to -BOGON.
B.  Peer with the corresponding routers at each of the other
RIRs and accept and readvertise their BOGON list through
BGP.
C.  Provide a full BOGON feed to any router that chooses to
peer, but not accept any routes or non-BGP traffic from
those routers.
3.  Any provider which wishes to filter BOGONs could peer with the
closest one or two of these and set up route maps that modify
the next-hop for all BOGONs to be an address which is statically
routed to NULL0 on each of their routers.
Apologies if this has been discussed before, but, it seems to me that this
is the easiest way to make the data readily available to the community
directly from the maintainers of the databases in a fashion which is
automatically up to date.
Owen

Re: 69/8...this sucks

[Joel Jaeggli]

this has been raised an issue before... but vanity ip address are a very 
very bad idea.

joelja

On Tue, 11 Mar 2003, Brandon Butterworth wrote:

> 
> > You want to move things like gtld servers,
> > yahoo/google (and other 'important' things), including
> 
> Do a deal with some porn hosters, they get 69.69.69.69
> in exchange for advertising tons of free porn there
> on their next spam run - win/win
> 
> brandon
> 

-- 
-- 
Joel Jaeggli  Academic User Services   [EMAIL PROTECTED]
--PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E  --
  In Dr. Johnson's famous dictionary patriotism is defined as the last
  resort of the scoundrel.  With all due respect to an enlightened but
  inferior lexicographer I beg to submit that it is the first.
-- Ambrose Bierce, "The Devil's Dictionary"

Re: 69/8...this sucks

[Brandon Butterworth]

>   You want to move things like gtld servers,
> yahoo/google (and other 'important' things), including

Do a deal with some porn hosters, they get 69.69.69.69
in exchange for advertising tons of free porn there
on their next spam run - win/win

brandon

Re: 69/8...this sucks -- Centralizing filtering..

[Jack Bates]

From: "Ray Bellis"

>
> Why not persuade ARIN to put whois.arin.net in there instead?  It
> shouldn't take the people with the broken filters *too* long to figure
> out why they can't do IP assignment lookups...
>
You are presuming that people are doing IP assignment lookups from the
affected network, sometimes just an affected server. Further more, you
presume that people do IP assignment lookups at all. Clueless people often
don't even know what ARIN is. Just the other day I was asked what Aaron had
to do with the problem I was describing.

-Jack

Re: 69/8...this sucks

[Charles Sprickman]

On Mon, 10 Mar 2003, Jared Mauch wrote:

>   You want to move things like gtld servers,
> yahoo/google (and other 'important' things), including
> things like oscar.toc.aol.com into these.

No, if you really want to stir things up, start an article on slashdot,
let the posters whip themselves into a frenzy, then move slashdot into the
ghetto space the next day.  It's cruel, but it sure would be fun.

And you might even convince the slashdot people to do it.

C

>   This will leave the clueless to buy a clue and
> stimulate the economy ;-)
>
>   - jared
>
> --
> Jared Mauch  | pgp key available via finger from [EMAIL PROTECTED]
> clue++;  | http://puck.nether.net/~jared/  My statements are only mine.
>

Re: 69/8...this sucks -- Centralizing filtering..

[Ray Bellis]

> After this 69.0.0.0/8 thing is sorted out I guess
> we can move the "critical resources" over to 202.0.0.0/7
> to track down all the idiots blocking that range (trying
> to decide if I should put a smilie here).
>
> I nominate the arin.net nameservers.


Most people seem to think it would be impractical to put the root name
servers in 69.0.0.0/8

Why not persuade ARIN to put whois.arin.net in there instead?  It
shouldn't take the people with the broken filters *too* long to figure
out why they can't do IP assignment lookups...

Ray

--
Ray Bellis, MA(Oxon) - Technical Director
community internet plc - ts.com Ltd

Windsor House, 12 High Street, Kidlington, Oxford, OX5 2PJ
tel:  +44 1865 856000   email: [EMAIL PROTECTED]
fax:  +44 1865 856001 web: http://www.community.net.uk/

RE: 69/8...this sucks

[Rob Thomas]

Hi, NANOGers.

] I bet for example we could get Rob Thomas to update his templates to
] include scarier warnings...

For the right amount of coffee, I just might.  ;)  Seriously, I'm all for
it.  Here is what I have on the Bogon List page:

   NOTE WELL!  IANA allocations change over time, so please check
   back regularly to ensure you have the latest filters.  I do
   announce updates to my templates in the FIRST community, as
   well as on lists such as NANOG, isp-routing, isp-security,
   isp-bgp, and cisco-nsp.  I can not stress this point strongly
   enough - these allocations change, as often as every four
   months.  If you do not adjust your filters, you will be unable
   to access perhaps large portions of the Internet.  You have
   been warned!

I don't know how much it helps, but it's there.  I don't mind including
it in all of the templates, monitoring, and bogon data feeds.

Thanks,
Rob.
-- 
Rob Thomas
http://www.cymru.com
ASSERT(coffee != empty);

202/7 (RE: 69/8...this sucks -- Centralizing filtering..)

[E.B. Dreger]

SL> Date: Tue, 11 Mar 2003 11:28:55 +1300 (NZDT)
SL> From: Simon Lyall


SL> After this 69.0.0.0/8 thing is sorted out I guess we can move
SL> the "critical resources" over to 202.0.0.0/7 to track down
SL> all the idiots blocking that range (trying to decide if I
SL> should put a smilie here).

Agree.

I had the pleasure of dealing with someone locally who decided to
5.x.x all mail from 216/8.  At least they were responsive... I
pity people in 202/7. :-(


Eddy
--
Brotsman & Dreger, Inc. - EverQuick Internet Division
Bandwidth, consulting, e-commerce, hosting, and network building
Phone: +1 (785) 865-5885 Lawrence and [inter]national
Phone: +1 (316) 794-8922 Wichita

~
Date: Mon, 21 May 2001 11:23:58 + (GMT)
From: A Trap <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Please ignore this portion of my mail signature.

These last few lines are a trap for address-harvesting spambots.
Do NOT send mail to <[EMAIL PROTECTED]>, or you are likely to
be blocked.

RE: 69/8...this sucks

[E.B. Dreger]

FS> Date: Mon, 10 Mar 2003 17:41:56 -0500
FS> From: Frank Scalzo


FS> What we can REALISTICALLY accomplish is to lean on the people
FS> who publish books/web pages/templates/etc. to include big
FS> scary warnings about using bogon filters and outline WHY they

And all the existing books, webpages, and "set-and-forget"
configs...


Eddy
--
Brotsman & Dreger, Inc. - EverQuick Internet Division
Bandwidth, consulting, e-commerce, hosting, and network building
Phone: +1 (785) 865-5885 Lawrence and [inter]national
Phone: +1 (316) 794-8922 Wichita

~
Date: Mon, 21 May 2001 11:23:58 + (GMT)
From: A Trap <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Please ignore this portion of my mail signature.

These last few lines are a trap for address-harvesting spambots.
Do NOT send mail to <[EMAIL PROTECTED]>, or you are likely to
be blocked.

RE: 69/8...this sucks -- Centralizing filtering..

[jlewis]

On Tue, 11 Mar 2003, Simon Lyall wrote:

> Could someone publish a name of a valid resource (or even pingable ip) in
> 69/8 space? This would allow people to test their (and their upsteams)
> filters quickly while we wait for the list to come out.

69.atlantic.net (69.28.64.8) is a loopback on our Gainesville, FL office 
router.

--
 Jon Lewis [EMAIL PROTECTED]|  I route
 System Administrator|  therefore you are
 Atlantic Net|  
_ http://www.lewis.org/~jlewis/pgp for PGP public key_

Re: 69/8...this sucks -- Centralizing filtering..

[James-lists]

> I'm not trying to start a flame war here, just pointing out
> that a variety of feeds meet many more requirements, and that there
> are several types of data feeds available now.  This includes the
> recently added pure text bogon files, suitable for easy parsing.
> 
> http://www.cymru.com/Bogons/

I have been using Rob's Bogon Route Server peering for several months. 
I love this service. The Bogon Route Server peers with my Zebra Route
Server, which is in full mesh with all my iBGP routers. This allows me more
chances to filter and make sanity checks. 

I was home sick when the last address space was allocated & my routers
updated themselves.

James Edwards
Routing and Security
[EMAIL PROTECTED]
At the Santa Fe Office: Internet at Cyber Mesa

 

RE: 69/8...this sucks

[Frank Scalzo]

Do you really think that people who don't have enough clue to update
their filters are going to be able to figure out why they can't reach
content in 69/8?

Moving all root-servers WOULD fix the problem. Although I doubt anyone
is really going to be willing to make the news by causing that much of
an outage.

What we can REALISTICALLY accomplish is to lean on the people who
publish books/web pages/templates/etc. to include big scary warnings
about using bogon filters and outline WHY they should be careful. I bet
for example we could get Rob Thomas to update his templates to include
scarier warnings like don't do this unless you intend to keep current on
new allocations if you don't know what that means skip this section (I
noticed there is something in the IOS template that says be "VERY"
careful). The warnings should be explicit, and scream don't do this
unless you understand it. Personally I have always thought overzealous
bogon filtering can be dangerous in the wrong hands and thus avoided it.
I don't even trust myself to keep current let alone someone who may pick
up a generic firewall book off the shelf and then think they are an
expert.

-Original Message-
From: Kevin Loch [mailto:[EMAIL PROTECTED] 
Sent: Monday, March 10, 2003 4:22 PM
To: [EMAIL PROTECTED]
Subject: Re: 69/8...this sucks


Stephen J. Wilcox wrote:
> 
>>I repeat my suggestion that a number of DNS root-servers or
gtld-servers
>>be renumbered into 69/8 space.  If the DNS "breaks" for these
neglected
>>networks, I suspect they will quickly get enough clue to fix their
ACLs.
>> 
> Nice idea in principal (from a purist point of view) but its not
practical, I 
> hope your not serious..!
> 

How about making *temporary* allocations to content providers
who vounteer to move some/all content to net-69?  Use an initial
page on your regular net to alert users to "contact their
ISP and have them fix their bogon filter if the below link
doesn't work."  If done right, it might speed up the clean-up.

The only problem would be finding volunteers with sufficient
traffic who are willing to break their site.

I could do this on some of my sites.  They're not Ebay, but
they do get hit from about 40K unique IP's per day, with
a very global distribution. If ARIN is interested, contact
me privately.

KL

Re: 69/8...this sucks -- Centralizing filtering..

[Jack Bates]

From: "Simon Lyall" 

> 
> Could someone publish a name of a valid resource (or even pingable ip) in
> 69/8 space? This would allow people to test their (and their upsteams)
> filters quickly while we wait for the list to come out.
> 
The BrightNet nameservers are both in 69.8.2.0/24 for now.

ns.brightok.net:69.8.2.15
ns2.brightok.net:69.8.2.12

-Jack

Re: 69/8...this sucks -- Centralizing filtering..

[E.B. Dreger]

DR> Date: Mon, 10 Mar 2003 23:10:35 +0100
DR> From: Daniel Roesen


DR> Can you point out where the rule is written that noone is to
DR> announce a prefix with length le 7? Just we don't see it now
DR> doesn't mean we won't see it sometime in the future...

Ditto ge 25.  I might have missed the RFC where that was
specified; AFAIK, it's a de facto standard.

Here's a big difference:  Assume all /8 (except for 0/8, 127/8,
and 224/3) could be aggregated.  How many announcements would be
saved?  I could live with 200-some /8 announcements as a result
of shorter prefixes being deaggregated.  I suspect announcing
uebershort prefixes isn't a big concern.

Let's first address the issue of stray /24 prefixes.  Your
question is interesting in theory, but has little applicability
to operational practices.  It shouldn't be forgotten, and anyone
using an "le 7" filter should stay on top of things...  but I
don't see it as a pressing issue.

Better yet, let RIRs allocate based on prefix length.  Then
Verio-style filters would work great, save for small multihomed
networks.  However, if said multihomed nets used IRRs...

Uhoh.  Combining a handful on NANOG threads probably is a
dangerous thing to do.


Eddy
--
Brotsman & Dreger, Inc. - EverQuick Internet Division
Bandwidth, consulting, e-commerce, hosting, and network building
Phone: +1 (785) 865-5885 Lawrence and [inter]national
Phone: +1 (316) 794-8922 Wichita

~
Date: Mon, 21 May 2001 11:23:58 + (GMT)
From: A Trap <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Please ignore this portion of my mail signature.

These last few lines are a trap for address-harvesting spambots.
Do NOT send mail to <[EMAIL PROTECTED]>, or you are likely to
be blocked.

RE: 69/8...this sucks -- Centralizing filtering..

[Simon Lyall]

On Mon, 10 Mar 2003, Todd A. Blank wrote:
> I continue to agree that moving critical resources (see below) to these
> new blocks is the best approach I have seen or heard in the months since
> I made the original post.  This approach punishes the clueless instead
> of the people that already know what the problem is (and have to live
> with it every day)

After this 69.0.0.0/8 thing is sorted out I guess we can move the
"critical resources" over to 202.0.0.0/7 to track down all the idiots
blocking that range (trying to decide if I should put a smilie here).

I nominate the arin.net nameservers.

Could someone publish a name of a valid resource (or even pingable ip) in
69/8 space? This would allow people to test their (and their upsteams)
filters quickly while we wait for the list to come out.

-- 
Simon Lyall.|  Newsmaster  | Work: [EMAIL PROTECTED]
Senior Network/System Admin |  Postmaster  | Home: [EMAIL PROTECTED]
Ihug Ltd, Auckland, NZ  | Asst Doorman | Web: http://www.darkmere.gen.nz

Re: 69/8...this sucks

[E.B. Dreger]

DB> Date: Mon, 10 Mar 2003 13:58:20 -0800 (PST)
DB> From: Doug Barton


DB> Ah, sorry, I wasn't aware of the full extent of your
DB> crack-smoking-ness.  :) You'll never get all of the root
DB> server operators to agree on this (or much of anything), so

I'm sorry, I'm having trouble grepping my mailbox.  Can you post
a link to the NANOG archives where you mentioned your superior
solution and what exactly is wrong with the idea?

*plonk*


Eddy
--
Brotsman & Dreger, Inc. - EverQuick Internet Division
Bandwidth, consulting, e-commerce, hosting, and network building
Phone: +1 (785) 865-5885 Lawrence and [inter]national
Phone: +1 (316) 794-8922 Wichita

~
Date: Mon, 21 May 2001 11:23:58 + (GMT)
From: A Trap <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Please ignore this portion of my mail signature.

These last few lines are a trap for address-harvesting spambots.
Do NOT send mail to <[EMAIL PROTECTED]>, or you are likely to
be blocked.

Re: 69/8...this sucks -- Centralizing filtering..

[Daniel Roesen]

On Mon, Mar 10, 2003 at 08:28:23PM +, E.B. Dreger wrote:
> Assuming one's upstreams and peers lack 'deny le 7'.

Can you point out where the rule is written that noone is to
announce a prefix with length le 7? Just we don't see it now
doesn't mean we won't see it sometime in the future...


Regards,
Daniel

RE: 69/8...this sucks -- Centralizing filtering..

[Todd A. Blank]

I continue to agree that moving critical resources (see below) to these
new blocks is the best approach I have seen or heard in the months since
I made the original post.  This approach punishes the clueless instead
of the people that already know what the problem is (and have to live
with it every day).

I can't begin to calculate the amount of support time we have burned
contacting the offending networks.  I know the cost has been prohibitive
at best.

I have seen this suggestion once before (maybe even by Jon) and I still
think it is the best way things will get resolved quickly.

Maybe we should suggest that ARIN also host some of their stuff on this
block :-)

Todd
IPOutlet LLC


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Sent: Monday, March 10, 2003 12:52 PM
To: E.B. Dreger
Cc: [EMAIL PROTECTED]
Subject: RE: 69/8...this sucks -- Centralizing filtering..


On Mon, 10 Mar 2003, E.B. Dreger wrote:

> Now, how can we force that?  Sufficient reward for doing so, or
> pain for failure.  Evidently "some people can't reach you" isn't
> enough pain, and having full reachability isn't enough reward.

I think the only way that's relatively guaranteed to be effective is to 
move a critical resource (like the gtld-servers) into new IP blocks when

previously reserved blocks are assigned to RIR's.

I still have a couple hundred thousand IPs to check (I'm going to step
up
the pace and see if I can get through the list today), but I already
have
a list of several hundred IPs in networks that ignore 69/8.  The list
includes such networks as NASA, the US DoD, and networks in China,
Russia,
and Poland.  Those are just a few that I've done manual whois's for.

I haven't decided yet whether I'll send automated messages to all the 
broken networks and give them time to respond and fix their filters, or 
just post them all to NANOG when the list is complete.

Are people interested in seeing the full list (at least the ones I find)
of networks that filter 69/8?

Does Atlantic.Net get an ARIN discount for doing all this leg work? :)
 
--
 Jon Lewis [EMAIL PROTECTED]|  I route
 System Administrator|  therefore you are
 Atlantic Net|  
_ http://www.lewis.org/~jlewis/pgp for PGP public key_

Re: 69/8...this sucks

[Doug Barton]

On Mon, 10 Mar 2003, E.B. Dreger wrote:

> The suggestion is to move ALL root, and as many TLD as possible,
> servers into the new space.  Nobody has said "move one or two",
> which indeed would be ineffective.

Ah, sorry, I wasn't aware of the full extent of your crack-smoking-ness.
:) You'll never get all of the root server operators to agree on this (or
much of anything), so that leaves the root out (even if this were a good
idea, which it isn't). Since for sufficiently useful definitions of "all,"
all of the TLD's are commercial entities, you'll never get them to
volunteer to break their own domains, and their customers would riot if
they did.

Suffice it to say, this idea is never going to happen, although if it
takes energy away from the "ldap is the solution to all problems" thread,
feel free to keep discussing it.

Doug

-- 

If it's moving, encrypt it. If it's not moving, encrypt
it till it moves, then encrypt it some more.

Re: 69/8...this sucks -- Centralizing filtering..

[Russell Heilling]

On Mon, Mar 10, 2003 at 01:39:26PM -0600, Jack Bates wrote:
> 
> Oh, I agree that there are times when BGP is used in a single uplink
> scenario, but it is not common. However, someone pointed me to ip verify
> unicast source reachable-via any which seems to be available on some of the
> cisco Service provider releases. It's an interesting concept and I'm itching
> to play with it. If you aren't in my routing table, then why accept the IP
> address?

I've been using this method to do "loose source verification" for a while 
now, and it's certainly better than nothing, but it doesn't really do as 
much as it should when you only receive a partial table from a peer.  I've 
been toying with the idea of supporting strict reverse path verification 
on peering links by using vrfs.  It works really well in the Lab, but 
migrating the whole network into an MPLS VPN just to get some extra 
source filtering ability seems a little extreme to me for some reason... 
;)

It'd work really well if Cisco allowed the global table as a vrf
import/export target though.

-- 
Russell Heilling
http://www.ccie.org.uk
PGP: finger [EMAIL PROTECTED]


pgp0.pgp
Description: PGP signature

Re: 69/8...this sucks

[Kevin Loch]

Stephen J. Wilcox wrote:

I repeat my suggestion that a number of DNS root-servers or gtld-servers
be renumbered into 69/8 space.  If the DNS "breaks" for these neglected
networks, I suspect they will quickly get enough clue to fix their ACLs.
Nice idea in principal (from a purist point of view) but its not practical, I 
hope your not serious..!

How about making *temporary* allocations to content providers
who vounteer to move some/all content to net-69?  Use an initial
page on your regular net to alert users to "contact their
ISP and have them fix their bogon filter if the below link
doesn't work."  If done right, it might speed up the clean-up.
The only problem would be finding volunteers with sufficient
traffic who are willing to break their site.
I could do this on some of my sites.  They're not Ebay, but
they do get hit from about 40K unique IP's per day, with
a very global distribution. If ARIN is interested, contact
me privately.
KL