Increase in packet loss from the west coast

[Sean Donelan]

I've been seeing an increase in packet loss across a few different
providers out of San Francisco/Seattle on the west coast.  Did anyone
lose some transport out west?

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

[no subject]

[Stephen Gill]

Hi Owen,
This is exactly the service Team Cymru is currently offering with the
bogon route-server project.  Specific details and instructions on how to
request access can be found at the following URL:

http://www.cymru.com/BGP/bogon-rs.html

In a nutshell, this is a reliable and secure method of ensuring your
bogon routes are kept up-to-date.  Changes to the bogon route-server are
validated by at least two other individuals.  Team Cymru validate all
changes to the bogon lists and supporting documents prior to
implementation of such changes.  That said, bogons are updated almost
immediately and at no cost to you.

This is a *FREE* offering, as such there are NO guarantees or SLAs.  The
current list of 15 peers have been quite pleased with the reliability
and service.  We are also working on adding redundant bogon
route-servers in the very near future.  If anyone is willing to donate
gear or bandwidth to the cause, please don’t hesitate to contact us.

As always, the master bogon reference page can be found here: 

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

Feel free to send any queries, suggestions, or concerns to the entire
team at [EMAIL PROTECTED]

Thanks!
Steve, for Team Cymru.
-- 
Stephen Gill
[EMAIL PROTECTED]

-Original Message-
Date: Tue, 11 Mar 2003 08:48:07 -0800
From: Owen DeLong <[EMAIL PROTECTED]>
Subject: RE: 69/8...this sucks -- Centralizing filtering..
 
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

Re: 69/8 problem -- Would CNN care?

[Jared Mauch]

On Tue, Mar 11, 2003 at 02:06:49PM -0500, Lee Watterworth wrote:
> 
> 
> Over the last few years CNN has covered many internet tech articles -- various 
> worms, attacks and outages.  
> 
> Think they would care to do a story on this problem?  

This is one that requires more detail than CNN can fit in a blurb
inbetween their 'war mode' news blurbs.

This is more of a npr-like story.  you need that in-depth love
to explain how and why people should care.

- jared

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

69/8 problem -- Would CNN care?

[Lee Watterworth]

Over the last few years CNN has covered many internet tech articles -- various worms, 
attacks and outages.  

Think they would care to do a story on this problem?  

-Lee

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: scope of the 69/8 problem

[jlewis]

On Tue, 11 Mar 2003, Stephen Sprunk wrote:

> Come on, you're asking the root and/or TLD operators to renumber their
> servers -- not a trivial task -- every few months to intentionally disable
> their own service for what amounts to an academic experience.

Not for academic experience, but to encourage people to fix their broken 
filters.  And while renumbering a large network might be non-trivial, 
changing the IP or adding an IP alias on 13 individual servers should be 
a trivial operation.

> These folks are in the business of running a critical system that requires
> 100% uptime for hundreds of millions of users, and they do a damned good
> job.  Let them do it in peace, and find some other "must have" service (like
> porn) to put in 69/8.

100% uptime for the service, not for each individual server.

So now the 69/8 holders, in addition to driving a campaign to get others 
to fix their networks, should offer free hosting to porn sites?  How about 
free hosting for spamvertized sites?...oh wait, that might make the 
problem worse :)
 
--
 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..

[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: 923Mbits/s across the ocean

[Stephen Sprunk]

Thus spake "Iljitsch van Beijnum" <[EMAIL PROTECTED]>
> This is the part about TCP that I've never understood: why does it
> send large numbers of packets back-to-back? This is almost never a
> good idea.

Because until you congest the network to the point of dropping packets, a
host has no idea how much bw is actually available.  Exponential rate
growith finds this value very quickly.

> Hm, I don't see this happening to a usable degree as TCP has no
> concept of records. You really want to use fixed size chunks of
> information here rather than pretending everything's a stream.

A record-oriented, reliable transport would make many protocols much easier
to implement.  Too bad SCTP hasn't seen wider use.

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: scope of the 69/8 problem

[Stephen Sprunk]

Thus spake "E.B. Dreger" <[EMAIL PROTECTED]>
> If the roots and gTLDs are truly unwilling to help, and a handful
> of entities can't cooperate, I have serious concerns why they
> have been handed responsibility for such a critical piece of
> infrastructure.  I'd expect "it's too hard to be a good netizen"
> whining on other lists... but NANOG?  Roots and TLDs?
>
> Perhaps this is an omen of the Internet yet to come.  Oh joy.

Come on, you're asking the root and/or TLD operators to renumber their
servers -- not a trivial task -- every few months to intentionally disable
their own service for what amounts to an academic experience.

These folks are in the business of running a critical system that requires
100% uptime for hundreds of millions of users, and they do a damned good
job.  Let them do it in peace, and find some other "must have" service (like
porn) to put in 69/8.

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: OT: Increasing Cell Phone Signal inside a NOC?

[Bradley Dunn]

[EMAIL PROTECTED] wrote:
I'm sure a lot of people have the same problem as we are having... Our 
NOC and Server Equipment is located in "No Cell Phone signal" zone of 
our building (It's amazing what metal walls, Server Racks and HVAC 
Systems will do to Cellphone Signals).  I was wondering if anyone out 
there has found a device that will be able to repeat the Cell Phone 
signal back into our NOC & Server Area's???
You'd probably need a lot of indoor usage to convince your carrier to do 
it, but you could ask them to deploy a picocell in your space. For example:
http://www.nokia.com/networks/product_catalog/pc_product_highlights/1,5567,,00.html?prod_id=RAS00010&path=mcat&mcat=5&scat=48260
Again, you'd need your cell carrier's cooperation for this.

Bradley

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: Increasing Cell Phone Signal inside a NOC?

[Mike Damm]

Wait; let me get this strait... you want people calling you on your cell
when you're working in the NOC?

Check out http://cellantenna.com/ for a solution that will run you anywhere
from a grand on up. I haven't tested it myself though.

-Mike


---
Michael Damm, MIS Department, Irwin Research & Development
V: 509.457.5080 x298 F: 509.577.0301 E: [EMAIL PROTECTED]

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, March 11, 2003 9:56 AM
To: [EMAIL PROTECTED]
Subject: OT: Increasing Cell Phone Signal inside a NOC?


I'm sure a lot of people have the same problem as we are having... Our NOC
and Server Equipment is located in "No Cell Phone signal" zone of our
building (It's amazing what metal walls, Server Racks and HVAC Systems will
do to Cellphone Signals).  I was wondering if anyone out there has found a
device that will be able to repeat the Cell Phone signal back into our NOC &
Server Area's??? 

Any advice would be greatly appreciated! 

Spencer 


Spencer Wood, Network Manager
Ohio Department Of Transportation
1320 Arthur E. Adams Drive
Columbus, Ohio 43221 
E-Mail: [EMAIL PROTECTED]
Phone: 614.644.5422/Fax: 614.887.4021/Pager: 866.591.9954 
* 

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: OT: Increasing Cell Phone Signal inside a NOC?

[Andrew Dorsett]

On Tue, 11 Mar 2003 [EMAIL PROTECTED] wrote:

> I'm sure a lot of people have the same problem as we are having... Our NOC
> and Server Equipment is located in "No Cell Phone signal" zone of our
> building (It's amazing what metal walls, Server Racks and HVAC Systems
> will do to Cellphone Signals).  I was wondering if anyone out there has
> found a device that will be able to repeat the Cell Phone signal back into
> our NOC & Server Area's???

Well we need a little bit more information.  Who is the cellular provider?
What modes are you trying to operate the cell in?

Just a for instance and to let you know that those systems do exist.  For
an iden system, Southern LINC sells this:
http://www.southernlinc.com/largemultiple.asp

Andrew
---
<[EMAIL PROTECTED]>
http://www.andrewsworld.net/
ICQ: 2895251
Cisco Certified Network Associate

"Learn from the mistakes of others. You won't live long enough to make all of them 
yourself."

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

OT: Increasing Cell Phone Signal inside a NOC?

[Spencer . Wood]

I'm sure a lot of people have the same
problem as we are having... Our NOC and Server Equipment is located in
"No Cell Phone signal" zone of our building (It's amazing what
metal walls, Server Racks and HVAC Systems will do to Cellphone Signals).
 I was wondering if anyone out there has found a device that will
be able to repeat the Cell Phone signal back into our NOC & Server
Area's???

Any advice would be greatly appreciated!

Spencer


Spencer Wood, Network Manager
Ohio Department Of Transportation
1320 Arthur E. Adams Drive
Columbus, Ohio 43221 
E-Mail: [EMAIL PROTECTED]
Phone: 614.644.5422/Fax: 614.887.4021/Pager: 866.591.9954

*

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: Question concerning authoritative bodies.

[Andy Walden]

On Tue, 11 Mar 2003 [EMAIL PROTECTED] wrote:

> On Tue, 11 Mar 2003, Ron da Silva wrote:
>
> > Hmm...I would argue that every operator needs to run their own DNSBL.
>
> If you only DNSBL IPs after you receive spam from them, you have to get
> spammed by every IP before it's blocked.  Why not reject mail from IPs
> that have spammed others before they spam you and your customers?  Though

I expect this is different in Ron's case since in a single day he gets
enough spam to be equivlent to every IP address once. :) So whats an extra
day right..

Now if AOL would allow their DNSBL to be mirrored...

andy

--
PGP Key Available at http://www.tigerteam.net/andy/pgp

RE: Move all 9-1-1 to 8-5-5

[McBurnett, Jim]

After working at a CLEC for a while, I must say that 
I know of very few PBXs that can do this, that the avg 
customer can afford.. Of course the 
BIG Lucent Definity series, maybe a few of it's peers..
But the Lucent/AT&T partner/Magix systems, I am nearly 
positive(99.9%) they can't.. And forget about those 
4 line toshiba's.

Anyway that is not a discussion for this list...

Jim

>-Original Message-
>From: Mark Segal [mailto:[EMAIL PROTECTED]
>Sent: Tuesday, March 11, 2003 9:04 AM
>To: [EMAIL PROTECTED]
>Subject: RE: Move all 9-1-1 to 8-5-5
>
>
>
>> Whenever the North American Numbering Planning Administration 
>> releases a new toll-free prefix (e.g. 1-800, 1-888, 1-877, 
>> 1-866) there is always a lengthy delay for individuals 
>> operating some telephone switches to update their routing 
>> tables.  Its common to be in hotels, and find the hotel PBX 
>> doesn't recognize a recent toll-free prefix.
>
>Yes.. But most people don't run translations for all NPA-NXXs 
>on their 4
>line PBX
>
>Regards,
>Mark
>
>--
>Mark Segal
>Director, Data Services
>Futureway Communications Inc.
>Tel: (905)326-1570
>
>
>> 
>> So to "fix" this problem, why don't we move all 9-1-1 numbers 
>> to the new toll-free prefix, which will break stuff for 
>> people who don't update their PBX's promptly.  When they find 
>> out they can't report a fire in the hotel because their PBX 
>> is blocking the new prefix, then they'll fix the PBX.
>> 
>> Let's get real, no one is going to break any "critical" 
>> resource just for the purpose of making people fix their systems.
>> 
>> 
>> Rob's bogon lists are good, but unless you have the processes 
>> in place to keep it update to date (or hire an consulting 
>> firm to do it for you), its about as useful as putting a list 
>> of "invalid" phone numbers in your PBX. The lists change all 
>> the time, and unless you are a full-time LERG expert, it will 
>> probably get quickly out of date.
>> 
>> Of course, we can always use LDAP to keep all the PBX's updated.
>> 
>

Re: Question concerning authoritative bodies.

[jlewis]

On Tue, 11 Mar 2003, Ron da Silva wrote:

> Hmm...I would argue that every operator needs to run their own DNSBL.

Can you elaborate on why?  IMO, there are definite benefits to 
centralized, shared DNSBLs, especially if testing is involved.  Many can 
benefit from the work done by a few and not have to duplicate the work.

If you only DNSBL IPs after you receive spam from them, you have to get 
spammed by every IP before it's blocked.  Why not reject mail from IPs 
that have spammed others before they spam you and your customers?  Though 
I have problems with the way it's been run, I think that's the idea behind 
bl.spamcop.net.  If they could just restrict nominations to a more clueful 
group of users, such a system could be very effective for blocking spam 
everywhere as soon as one system gets hit.  For spam from open relays and 
proxies, a centralized DNSBL that tests the IPs that talk to servers using 
it can be just as, if not more, effective.

> It would be very difficult to convince any operator to give up control
> of defining their own DNSBL (or even not having one at all).

You can use a central DNSBL without giving up total control.  Shortly 
after I configured servers to use a DNSBL for the first time, I recognized 
the need for a local DNSWL and have continued to use one ever since.  When 
I setup other people's servers to use DNSBLs, I help them setup a DNSWL 
and explain how to maintain it.
 
--
 Jon Lewis [EMAIL PROTECTED]|  I route
 System Administrator|  therefore you are
 Atlantic Net|  
_ http://www.lewis.org/~jlewis/pgp for PGP public key_

Re: Question concerning authoritative bodies.

[Ron da Silva]

On Sun, Mar 09, 2003 at 02:59:05PM -0500, [EMAIL PROTECTED] wrote:
> 
> I suspect AOL and Earthlink run their own DNSBLs primarily for the second
> reason.  How would you convince them to trust and give up control to a
> central authority?
> 
> Even if IANA were to create or bless some existing DNSBL and decree that
> all IP address holders will submit to testing or have their space revoked
> (yeah, that'll happen) there would still be those who weren't happy with
> the central DNSBL thus creating demand for additional ones.

Hmm...I would argue that every operator needs to run their own DNSBL.
Some operators will simply mirror a central authority, others will
ignore some or all of the data in the central authority and the simple
case for some operators is to have an empty set.

It would be very difficult to convince any operator to give up control
of defining their own DNSBL (or even not having one at all).

-ron

RE: Issue with 208.192.0.0/8 - 208.196.93.0/24?

[McBurnett, Jim]

Easy, question..

Sure I could do that, I could run NMAP, Nessus, or any number of probes
to check the validity of the host reachability. N-Stealth... and the list goes on.
BUT if a host is denying pings from the world round and it stops trace a couple hops 
away
maybe a BOGON filter or ACL or 

Well If I can't http to it, and I can't ping it from multiple peering points, there
is a filter somewhere..  It can't even be accessed via the Worldcom UUNet network..
H..
Yeah you can telnet to it... Yeah I got to it via telnet... 
Anyway.. Normally if you can't Ping it and can't HTTP to a web server

J
>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
>Sent: Tuesday, March 11, 2003 8:50 AM
>To: McBurnett, Jim
>Cc: chuck goolsbee; [EMAIL PROTECTED]
>Subject: RE: Issue with 208.192.0.0/8 - 208.196.93.0/24?
>
>
>>
>> Is anyone from Alter.net lurking?
>> Just for grins I went to the DIGEX looking glass and I could 
>not ping it 
>> from MAE-Central, PAIX , MAE-East and also from AT&T Cerf router
>> below are some of the traces.. Always dies on Alter... I wonder.
>> Alter? 
>
>Brilliant. Why did not you try "telnet  80"?
>
>Just because random packets spewed by traceroute are dropped 
>on the floor
>does not mean that the site is dead. 
>
>Alex
>
>

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: Issue with 208.192.0.0/8 - 208.196.93.0/24?

[Callis, Adam]

>From your traceroute, you ascertain that the traffic is traversing the UUNET
Backbone and is stopping just past the edge of the UUNET GW (Gateway) router
as it leaves the UUNET Backbone.

Thanks,
Adam


-Original Message-
From: McBurnett, Jim [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 11, 2003 8:43 AM
To: chuck goolsbee; [EMAIL PROTECTED]
Subject: RE: Issue with 208.192.0.0/8 - 208.196.93.0/24?



   
Is anyone from Alter.net lurking?
Just for grins I went to the DIGEX looking glass and I could not ping it 
from MAE-Central, PAIX , MAE-East and also from AT&T Cerf router
below are some of the traces.. Always dies on Alter... I wonder.
Alter? 

route-server>trac 208.196.93.204

Type escape sequence to abort.
Tracing the route to ecobeauty.org (208.196.93.204)

  1 mdf1-gsr12-1-gig-1-1.lax1.attens.net (12.129.192.237) [AS 17233] 0 msec
4 msec
 0 msec
  2 mdf1-gsr12-1-gig-1-1.lax1.attens.net (12.129.192.237) [AS 17233] 0 msec
0 msec
 0 msec
  3 gar3-p320.la2ca.ip.att.net (12.122.255.249) [AS 7018] 0 msec 4 msec 0
msec
  4 gbr5-p90.la2ca.ip.att.net (12.123.28.193) [AS 7018] 4 msec 0 msec 0 msec
  5 tbr2-p013501.la2ca.ip.att.net (12.122.11.153) [AS 7018] 4 msec 0 msec 4
msec
  6 ggr1-p3100.la2ca.ip.att.net (12.122.11.222) [AS 7018] 0 msec 4 msec 4
msec
  7 POS4-3.BR1.LAX9.ALTER.NET (204.255.168.61) [AS 701] 4 msec 4 msec 4 msec
  8 0.so-0-1-0.XL2.LAX9.ALTER.NET (152.63.113.18) [AS 701] 4 msec 4 msec 4
msec
  9 0.so-0-0-0.TL2.LAX9.ALTER.NET (152.63.115.146) [AS 701] 4 msec 4 msec 4
msec
 10 0.so-6-0-0.TL2.NYC9.ALTER.NET (152.63.13.10) [AS 701] 76 msec 76 msec 76
msec
 11 0.so-3-0-0.XL2.NYC1.ALTER.NET (152.63.29.113) [AS 701] 76 msec 76 msec
76 msec
 12 0.so-0-0-0.XR2.NYC1.ALTER.NET (152.63.19.97) [AS 701] 76 msec 76 msec 76
msec
 13 208.ATM7-0.GW11.NYC1.ALTER.NET (152.63.29.189) [AS 701] 76 msec 80 msec
76 mse
c
 14  *  *  *
and it dies..
 03/11/03 08:28:24 Fast traceroute 208.196.93.204
Trace 208.196.93.204 ...
 1 66.191.223.2  0ms0ms0ms  TTL:  0
(cpe-66-191-223-002.spart.sc.charter.com ok)
 2 66.168.32.41  0ms0ms0ms  TTL:  0
(cpe-66-168-32-041.spart.sc.charter.com ok)
 3 12.123.21.78 10ms0ms0ms  TTL:  0  (gbr6-p80.attga.ip.att.net
bogus rDNS: host not found [authoritative])
 4 12.122.12.25 10ms0ms0ms  TTL:  0
(tbr1-p013601.attga.ip.att.net bogus rDNS: host not found [authoritative])
 5 12.122.12.30  0ms   10ms0ms  TTL:  0  (ggr1-p340.attga.ip.att.net
bogus rDNS: host not found [authoritative])
 6 204.255.174.149   0ms   10ms   10ms  TTL:  0  (POS5-2.BR2.ATL5.ALTER.NET
ok)
 7 152.63.82.19410ms0ms   10ms  TTL:  0
(0.so-2-3-0.XL2.ATL5.ALTER.NET ok)
 8 152.63.10.106 0ms   10ms   10ms  TTL:  0
(0.so-0-0-0.TL2.ATL5.ALTER.NET ok)
 9 152.63.146.4220ms   20ms   20ms  TTL:  0
(0.so-7-0-0.TL2.DCA6.ALTER.NET ok)
10 152.63.34.13020ms   20ms   20ms  TTL:  0
(0.so-5-0-0.CL2.DCA1.ALTER.NET ok)
11 152.63.42.11030ms   20ms   20ms  TTL:  0
(194.at-4-0-0.CL2.PHL1.ALTER.NET ok)
12 152.63.38.20120ms   20ms   30ms  TTL:  0  (POS7-0.GW6.PHL1.ALTER.NET
ok)
And away to the bit bucket...
   

>-Original Message-
>From: chuck goolsbee [mailto:[EMAIL PROTECTED]
>Sent: Monday, March 10, 2003 10:14 PM
>To: [EMAIL PROTECTED]
>Subject: Issue with 208.192.0.0/8 - 208.196.93.0/24?
>
>
>
>Forgive the intrusion...
>
>We have a customer who uses some merchant services off of 
>208.196.93.204, which seems to be unreachable via any location I try. 
>Emails to UUnet's NOC are unaswered and the guy I talked to on the 
>phone @ UU wouldn't open a ticket because I'm not a customer (but his 
>traces were dying in the same place as mine:
>
>207.ATM6-0.GW11.NYC1.ALTER.NET (152.63.29.185))
>
>Can anybody out there hit that IP (208.196.93.204) at the moment? Or 
>indeed much of anything in that /8?
>
>
>-- 
>--chuck goolsbee
>geek wrangler, digital.forest inc, bothell, wa 
>

RE: Move all 9-1-1 to 8-5-5

[jlewis]

On Tue, 11 Mar 2003, Mark Segal wrote:

> Yes.. But most people don't run translations for all NPA-NXXs on their 4
> line PBX

And your misconfigured PBX won't likely stop me from calling you...just 
you from calling me.  Bad bogon filters stop or prevent traffic in both 
directions.

If anyone has a better idea for shifting the burden to and thus creating 
motivation for those with broken filters to fix them now, by all means, 
share your idea.

If you don't have a better idea yet, go ask ARIN for some space.  They
have lots of 69/8 left.  Maybe when you're in the club, you'll be more
motivated to think of ways to quickly encourage others to fix their
networks.

--
 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: Issue with 208.192.0.0/8 - 208.196.93.0/24?

[chuck goolsbee]

Brilliant. Why did not you try "telnet  80"?

Just because random packets spewed by traceroute are dropped on the floor
does not mean that the site is dead.


As I stated to many in off-list mail last night, we were unable to 
get to that IP on any port. It was not just traceroute. My original 
email was indeed lacking in regard to suggesting cluefullness on my 
part. No need to beat on others because *I* tempted them into looking 
less than brilliant by not providing enough original info.

The issue was sorted out after some offlist communication... once 
relevant info was communicated. Clients are happy and making 
transactions again just fine.

My apologies again for any misunderstanding.
Thanks again to those that helped out.
--chuck

I'm stapling this to a 2x4 and administering it to my forehead to 
remind me about proper communication with this group:
--

traceroute is a disconcertingly blunt hammer; that we continue to use it
to essentially nail moving jello to a wall says more about us than about
anything on the Internet.  --k claffy, At 8:43 -0700 10/17/02 on NANOG

Re: Bogon and anti-spoof filters

[Jack Bates]

From: "Simon Brilus"

>
> Does anyone have any idea of the processing overhead that would be placed
on
> a Cisco 7507 if you applied bogon and anti-spoof filters on a 100BT
> interface that faced the Internet, assuming VIP4-80 engines and 256Mb of
> memory?
>
It's not too bad. If it will support everything else you are doing, as it
isn't as versatile, the VIP8 (or was it 6; no coffee yet) is primarily
designed to handle complex access lists, or so an SE once told me. It didn't
handle the other functionality I needed, so i stayed with the 4.

-Jack

Re: Issue with 208.192.0.0/8 - 208.196.93.0/24?

[Peter Galbavy]

Stephen J. Wilcox <[EMAIL PROTECTED]> wrote:
> posts. Perhaps clueful folk should sneak off and form nanog-clueful
> mailing list ;) 

S the'll all want one.

Peter

RE: Move all 9-1-1 to 8-5-5

[Mark Segal]

> Whenever the North American Numbering Planning Administration 
> releases a new toll-free prefix (e.g. 1-800, 1-888, 1-877, 
> 1-866) there is always a lengthy delay for individuals 
> operating some telephone switches to update their routing 
> tables.  Its common to be in hotels, and find the hotel PBX 
> doesn't recognize a recent toll-free prefix.

Yes.. But most people don't run translations for all NPA-NXXs on their 4
line PBX

Regards,
Mark

--
Mark Segal
Director, Data Services
Futureway Communications Inc.
Tel: (905)326-1570


> 
> So to "fix" this problem, why don't we move all 9-1-1 numbers 
> to the new toll-free prefix, which will break stuff for 
> people who don't update their PBX's promptly.  When they find 
> out they can't report a fire in the hotel because their PBX 
> is blocking the new prefix, then they'll fix the PBX.
> 
> Let's get real, no one is going to break any "critical" 
> resource just for the purpose of making people fix their systems.
> 
> 
> Rob's bogon lists are good, but unless you have the processes 
> in place to keep it update to date (or hire an consulting 
> firm to do it for you), its about as useful as putting a list 
> of "invalid" phone numbers in your PBX. The lists change all 
> the time, and unless you are a full-time LERG expert, it will 
> probably get quickly out of date.
> 
> Of course, we can always use LDAP to keep all the PBX's updated.
> 

Re: Issue with 208.192.0.0/8 - 208.196.93.0/24?

[Stephen J. Wilcox]

> Remember:  The majority of the posters here probably have roughly
> as much (but not as much) of an ego as you, yet a _lot_ more
> experience and skills to back it up.  I think the results are

Altho sometime I have to wonder especially with some of the recent posts. 
Perhaps clueful folk should sneak off and form nanog-clueful mailing list ;)

Steve



> obvious.
> 
> Consider being an early adopter of IPv8.
> 
> 
> 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: Issue with 208.192.0.0/8 - 208.196.93.0/24?

[alex]

>
> Is anyone from Alter.net lurking?
> Just for grins I went to the DIGEX looking glass and I could not ping it 
> from MAE-Central, PAIX , MAE-East and also from AT&T Cerf router
> below are some of the traces.. Always dies on Alter... I wonder.
> Alter? 

Brilliant. Why did not you try "telnet  80"?

Just because random packets spewed by traceroute are dropped on the floor
does not mean that the site is dead. 

Alex

RE: Issue with 208.192.0.0/8 - 208.196.93.0/24?

[McBurnett, Jim]

   
Is anyone from Alter.net lurking?
Just for grins I went to the DIGEX looking glass and I could not ping it 
from MAE-Central, PAIX , MAE-East and also from AT&T Cerf router
below are some of the traces.. Always dies on Alter... I wonder.
Alter? 

route-server>trac 208.196.93.204

Type escape sequence to abort.
Tracing the route to ecobeauty.org (208.196.93.204)

  1 mdf1-gsr12-1-gig-1-1.lax1.attens.net (12.129.192.237) [AS 17233] 0 msec 4 msec
 0 msec
  2 mdf1-gsr12-1-gig-1-1.lax1.attens.net (12.129.192.237) [AS 17233] 0 msec 0 msec
 0 msec
  3 gar3-p320.la2ca.ip.att.net (12.122.255.249) [AS 7018] 0 msec 4 msec 0 msec
  4 gbr5-p90.la2ca.ip.att.net (12.123.28.193) [AS 7018] 4 msec 0 msec 0 msec
  5 tbr2-p013501.la2ca.ip.att.net (12.122.11.153) [AS 7018] 4 msec 0 msec 4 msec
  6 ggr1-p3100.la2ca.ip.att.net (12.122.11.222) [AS 7018] 0 msec 4 msec 4 msec
  7 POS4-3.BR1.LAX9.ALTER.NET (204.255.168.61) [AS 701] 4 msec 4 msec 4 msec
  8 0.so-0-1-0.XL2.LAX9.ALTER.NET (152.63.113.18) [AS 701] 4 msec 4 msec 4 msec
  9 0.so-0-0-0.TL2.LAX9.ALTER.NET (152.63.115.146) [AS 701] 4 msec 4 msec 4 msec
 10 0.so-6-0-0.TL2.NYC9.ALTER.NET (152.63.13.10) [AS 701] 76 msec 76 msec 76 msec
 11 0.so-3-0-0.XL2.NYC1.ALTER.NET (152.63.29.113) [AS 701] 76 msec 76 msec 76 msec
 12 0.so-0-0-0.XR2.NYC1.ALTER.NET (152.63.19.97) [AS 701] 76 msec 76 msec 76 msec
 13 208.ATM7-0.GW11.NYC1.ALTER.NET (152.63.29.189) [AS 701] 76 msec 80 msec 76 mse
c
 14  *  *  *
and it dies..
 03/11/03 08:28:24 Fast traceroute 208.196.93.204
Trace 208.196.93.204 ...
 1 66.191.223.2  0ms0ms0ms  TTL:  0  
(cpe-66-191-223-002.spart.sc.charter.com ok)
 2 66.168.32.41  0ms0ms0ms  TTL:  0  
(cpe-66-168-32-041.spart.sc.charter.com ok)
 3 12.123.21.78 10ms0ms0ms  TTL:  0  (gbr6-p80.attga.ip.att.net bogus 
rDNS: host not found [authoritative])
 4 12.122.12.25 10ms0ms0ms  TTL:  0  (tbr1-p013601.attga.ip.att.net bogus 
rDNS: host not found [authoritative])
 5 12.122.12.30  0ms   10ms0ms  TTL:  0  (ggr1-p340.attga.ip.att.net bogus 
rDNS: host not found [authoritative])
 6 204.255.174.149   0ms   10ms   10ms  TTL:  0  (POS5-2.BR2.ATL5.ALTER.NET ok)
 7 152.63.82.19410ms0ms   10ms  TTL:  0  (0.so-2-3-0.XL2.ATL5.ALTER.NET ok)
 8 152.63.10.106 0ms   10ms   10ms  TTL:  0  (0.so-0-0-0.TL2.ATL5.ALTER.NET ok)
 9 152.63.146.4220ms   20ms   20ms  TTL:  0  (0.so-7-0-0.TL2.DCA6.ALTER.NET ok)
10 152.63.34.13020ms   20ms   20ms  TTL:  0  (0.so-5-0-0.CL2.DCA1.ALTER.NET ok)
11 152.63.42.11030ms   20ms   20ms  TTL:  0  (194.at-4-0-0.CL2.PHL1.ALTER.NET ok)
12 152.63.38.20120ms   20ms   30ms  TTL:  0  (POS7-0.GW6.PHL1.ALTER.NET ok)
And away to the bit bucket...
   

>-Original Message-
>From: chuck goolsbee [mailto:[EMAIL PROTECTED]
>Sent: Monday, March 10, 2003 10:14 PM
>To: [EMAIL PROTECTED]
>Subject: Issue with 208.192.0.0/8 - 208.196.93.0/24?
>
>
>
>Forgive the intrusion...
>
>We have a customer who uses some merchant services off of 
>208.196.93.204, which seems to be unreachable via any location I try. 
>Emails to UUnet's NOC are unaswered and the guy I talked to on the 
>phone @ UU wouldn't open a ticket because I'm not a customer (but his 
>traces were dying in the same place as mine:
>
>207.ATM6-0.GW11.NYC1.ALTER.NET (152.63.29.185))
>
>Can anybody out there hit that IP (208.196.93.204) at the moment? Or 
>indeed much of anything in that /8?
>
>
>-- 
>--chuck goolsbee
>geek wrangler, digital.forest inc, bothell, wa 
>

Re: Issue with 208.192.0.0/8 - 208.196.93.0/24?

[E.B. Dreger]

DJR> Date: Tue, 11 Mar 2003 14:01:51 +0700
DJR> From: Dr. Jeffrey Race


DJR> [C:\]ping 208.196.93.204
DJR> [C:\]host 208.196.93.204

1. You read the NANOG FAQ, yes?  Please explain your post.

2. Did TCP attempts to various well-known ports stay in SYN_SENT,
   switch to CONNECTED, or return a RST?  Or did you not try?

Thanks for proving that experience in one sphere doesn't bring
any free credibility in another.  You posted what you should not,
and gave the wrong answer at that.

If you want to go around bragging "i'm mad l33t, yo" without
skills to back it up, I suggest IRC as a better medium.

Remember:  The majority of the posters here probably have roughly
as much (but not as much) of an ego as you, yet a _lot_ more
experience and skills to back it up.  I think the results are
obvious.

Consider being an early adopter of IPv8.


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: Issue with 208.192.0.0/8 - 208.196.93.0/24?

[alex]

> >Emails to UUnet's NOC are unaswered and the guy I talked to on the 
> >phone @ UU wouldn't open a ticket because I'm not a customer (but his 
> >traces were dying in the same place as mine:
> >
> >207.ATM6-0.GW11.NYC1.ALTER.NET (152.63.29.185))
> >
> >Can anybody out there hit that IP (208.196.93.204) at the moment? Or 
> >indeed much of anything in that /8
> 
> 
> [C:\]ping 208.196.93.204
> PING 208.196.93.204: 56 data bytes
> 
> 208.196.93.204 PING Statistics
> 7 packets transmitted, 0 packets received, 100% packet loss
> 
> [C:\]tracerte 208.196.93.204
>  0  192.168.1.1 (192.168.1.1)  0 ms  0 ms  0 ms

[skip]

> 24  *
> [dies]
> 
> [C:\]host 208.196.93.204
> 208.196.93.204 = ecobeauty.org

And we are supposed to take "The Ultimate Diagnosis" from a person who
would not think of using tcptrace, telnetting into port 80 or to see if that
was an ACL? Phlease.


Alex

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: Move all 9-1-1 to 8-5-5

[Michael . Dillon]

>Rob's bogon lists are good, but unless you have the processes in place to
>keep it update to date (or hire an consulting firm to do it for you), its
>about as useful as putting a list of "invalid" phone numbers in your PBX.
>The lists change all the time, and unless you are a full-time LERG 
expert,
>it will probably get quickly out of date.

>Of course, we can always use LDAP to keep all the PBX's updated.

Well, we use DNS to keep all of our resolvers updated with the latest IP 
address changes and it works so well that most people never even think 
about what is happening under the hood unless they are renumbering. 

Compare this to what happens when the root hints file changes. In that 
case you need processes and people or, more likely, you wait until 
something breaks and then hire a consultant who updates your root hints 
file for a nice fee. This is not the model I would use to solve the bogon 
problem.

--Michael Dillon

Re: Bogon and anti-spoof filters

[Simon Brilus]

CPU typically 22%
Free memory 97Mb

And I would assume access-lists

TTFN

Simon

- Original Message -
From: "Neil J. McRae" <[EMAIL PROTECTED]>
To: "Simon Brilus" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, March 11, 2003 9:57 AM
Subject: Re: Bogon and anti-spoof filters


>
> > Does anyone have any idea of the processing overhead that would be
placed on
> > a Cisco 7507 if you applied bogon and anti-spoof filters on a 100BT
> > interface that faced the Internet, assuming VIP4-80 engines and 256Mb of
> > memory?
>
> I assume you mean interface filters? If so I'd have thought that a
> 7507 would cope with this, but it depends on the rest of the boxs
> load etc.
>
> Regards,
> Neil.

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

69/8 compelling content?

[Simon Waters]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Surely the guys with 69/8 merely need to acquire compelling content.

Offer some free hosting to whatever your favourite busy free service is.

Something like freechess.org, or even www.asstr.org ;-)

I think starting with the root DNS is silly, start with what people
really care about! I use to remove the games from my Office servers when
they were short of space, amazing how quickly disk space returned, the
same technique may work on larger scale.
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE+bbs9GFXfHI9FVgYRAmUdAJ93Jy6e/+vvM+Gj6x8/XsJ90E0IJgCeIT0U
XNwinPrjKf3jjzt8bzW9vU0=
=BLJm
-END PGP SIGNATURE-

Re: 923Mbits/s across the ocean

[Iljitsch van Beijnum]

On Mon, 10 Mar 2003, Richard A Steenbergen wrote:

> > > On the receive size, the socket buffers must be large enough to
> > > accommodate all the data received between application read()'s,

> > That's not true. It's perfectly acceptable for TCP to stall when the
> > receiving application fails to read the data fast enough.

> Ok, I think I was unclear. You don't NEED to have buffers large enough to
> accommodate all that data received between application read()'s, unless
> you are trying to achieve maximum performance. I thought that was the
> general framework we were all working under. :)

You got me there.  :-)

It seemed that you were talking about more general requirements at this
point, though with the upper and lower limits for kernel buffer space
and all.

> > Hm, I don't see this happening to a usable degree as TCP has no concept
> > of records. You really want to use fixed size chunks of information here
> > rather than pretending everything's a stream.

> We're talking optimizations for high performance transfers... It can't
> always be a stream.

Right. But TCP is a stream protocol. This has many advantages, nearly
all of which are irrelevant for high volume high bandwidth bulk data
transfer.

I can imagine a system that only works in one direction and where the
data is split into fixed size records (which would ideally fit into a
single packet) where each record is acknowledged independently (but
certainly not for each individual packet). I would also want to take
advantage of traffic classification mechanisms: first the data is
flooded at the maximum speed at the lowest possible traffic class.
Everything that doesn't make it to the other end is then resent slower
with a higher traffic class. If the network supports priority queuing
then this would effectively sponge up all free bandwidth without
impacting regular interactive traffic. If after a few retries some data
still didn't make it: simply skip this for now (but keep a record of the
missing bits) and keep going. Many applications can live with some lost
data and for others it's probably more efficient to keep running at high
speed and repair the gaps afterwards.

> > > IMHO the 1500 byte MTU of ethernet
> > > will still continue to prevent good end to end performance like this for a
> > > long time to come. But alas, I digress...

> > Don't we all? I'm afraid you're right. Anyone up for modifying IPv6 ND
> > to support a per-neighbor MTU? This should make backward-compatible
> > adoption of jumboframes a possibility. (Maybe retrofit ND into v4 while
> > we're at it.)

> Not necessarily sure thats the right thing to do, but SOMETHIG has got to
> be better than what passes for path mtu discovery now. :)

We can't replace path MTU discovery (but hopefully people will start to
realize ICMP messages were invented for another reason than job security
for firewalls). But what we need is a way for 10/100 Mbps 1500 byte
hosts to live with 1000 Mbps 9000 byte hosts on the same subnet. I
thought IPv6 neighbor discovery supported this because ND can
communicate the MTU between hosts on the same subnet, but unfortunately
this is a subnet-wide MTU and not a per-host MTU, which is what we
really need.

Iljitsch

Re: Bogon and anti-spoof filters

[Neil J. McRae]

> Does anyone have any idea of the processing overhead that would be placed on
> a Cisco 7507 if you applied bogon and anti-spoof filters on a 100BT
> interface that faced the Internet, assuming VIP4-80 engines and 256Mb of
> memory?

I assume you mean interface filters? If so I'd have thought that a
7507 would cope with this, but it depends on the rest of the boxs
load etc. 

Regards,
Neil.

Bogon and anti-spoof filters

[Simon Brilus]

Does anyone have any idea of the processing overhead that would be placed on
a Cisco 7507 if you applied bogon and anti-spoof filters on a 100BT
interface that faced the Internet, assuming VIP4-80 engines and 256Mb of
memory?

Simon Brilus
Internet and Operations Manager
Bulldog Communications Ltd.
www.bulldogdsl.com

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