Re: UK ISPs not cooperating with law enforcement

[Peter Galbavy]

> The issue at the core is whether ISPs should just roll over and cough up
> anything to law enforcement, any time, without valid warrants.

I am sure that such a cosmopolitan bunch as NANOG will also understand that
EU Data Protection laws give people quite a big comeback when they find
someone has not treated their personal information in the way they are
entitled to expect. While the US may be the litigous society in truth, we
are catching up quite fast here on this front...

Policy was, many years ago, when we were 'all' at Demon that we would
*never* hand out any logs until there was a court order. Period. At that
point we would roll over and stick our paws in the air... subtle hints from
the police and others were met with this policy.

Of course, the RIP Act brings big brother truly to life now. If only the
civil service would stop infighting long
enough to implement it ;-)

Peter

Re: 69/8...this sucks

[Michael . Dillon]

> According to ARIN's whois server, there are 95 subdelegations for 
> NET-69-0-0-0-0...we're the 95th.

Clearly this problem is going to get a lot worse before it gets better. 
And since most network operators are not on NANOG or USENET or any other 
mailing list, there are really only two means of contact. Either every 
affected party probes the net, identifies misconfigured networks and 
contacts them one by one using email, phone and letters. Or we use the 
press to make the problem and solution widely visible. 

In either case, I think it would be a mistake to just fix the immediate 
problem of a few ISPs needed full reachability from 69/8 space. Since we 
have to put the effort into this problem, let's try to fix the general 
problem, not just a small part of it.

The general problem is that ever large numbers of devices are getting IPv4 
address ranges hard-coded into their configurations with no process in 
place for reviewing and changing those configurations. These devices are 
not just routers but also firewalls and application servers. 

In order to solve the general problem we need to make it easy for people 
to review and change their configurations. This is not a lot different 
from the problems that DNS solved. When you configure a device with a 
domain name, the device will dynamically review and update the IP address 
that it uses for communication. No human intervention is necessary.

Essentially, what we need is something that provides a capability similar 
to DNS except that it works for IP address ranges, not for individual IP 
addresses. This is where ARIN comes in. Because ARIN has the top-level 
authority for IP address ranges in North America, they are the *ONLY* 
organization that can authoritatively identify who an IP address range is 
delegated to. 

I have suggested that ARIN should set up an LDAP server to publish the 
delegation of all their IP address space updated on a daily basis. And 
that organizations which sub-delegate space, i.e. ISPs, should also run 
LDAP servers as part of a delegation hierarchy similar to DNS. This type 
of referral LDAP is part of the IETF standard and has been implemented by 
most LDAP software vendors. Because LDAP is a widespread technology that 
is used in the enterprise for identification and authentication, there is 
a high likelihood that the suppliers of firewalls and application servers 
will build in support for querying the ARIN delegation hierarchy.

> I realize ARIN can't guarantee global routability of IP space, but 
should
> they continue to give out IP blocks they absolutely know are not fully
> routable on the internet today?

ISPs make addresses routable. ARIN is not an ISP. ARIN members are ISPs. 
ARIN does not compete with its members.

Therefore, ARIN should focus on the problem of how to publish 
authoritative data about which IP addresses should be routable. The 
appropriate technology combined with the appropriate publicity will create 
demand from enterprise network admins which will drive all ISPs and device 
vendors to fix the problem.

If anyone wants to discuss this further, then I suggest that the upcoming 
ARIN meeting in Memphis is the ideal venue to do so.

--Michael Dillon

Re: Building Cited for Housing Fuel Tanks Catches Fire [NYT]

[Michael . Dillon]

> > An electrical fire broke out in the basement of an office tower
> > in TriBeCa yesterday, four months after building inspectors said
> > they had discovered illegal diesel fuel tanks installed on the
> > upper floors of the tower.

> basement.  roof.  what is it i am not getting here?  osama bin
> elevator?  the ratcheting (rat shing?) up of the american
> press hysteria?

Diesel fuel from a leaky roof tank will eventually drip down to the 
basement.

Heat from a basement fire will eventually rise up to the roof and cause 
diesel fuel tanks to explode.

In any case, this problem should be solved by the city government in a 
large city. It is a fact that large cities are large telecomm hubs. It is 
a fact that large telecomm hubs need guaranteed power supplies. It is a 
fact that the individual players in telecomm want to be located near each 
other in large cities (same building, same block). The solution to this 
whole mess is for the city government to run a special power utility that 
operates a pair of safe and highly secure diesel power generating plants 
which provide dual entrance service to telecomm hotels in a specific area 
of the city. That way folks can install equipment with no batteries and no 
generators because they are getting triply redundant and diverse power 
(utility, and 2 city diesel generation plants).

We eliminate the dangers of hydrogen fumes and exploding batteries and 
flammable diesel.

BTW, has anyone done any studies of heat generation in routers and 
switches to identify which bits of the hardware generate the most heat 
(i.e. consume the most power) and which functions generate the most heat? 
Maybe there are opportunities for dramatically reducing power consumption 
by changing the way we configure our networks.

--Michael Dillon

Re: Port 445 issues (was: Port 80 Issues)

[Vadim Antonov]

I'm just waiting for hakerz to finally figure out that having the port
number a hash of host address will effectively make port-based 
"notch" filtering useless. Usin


On Sun, 9 Mar 2003, Sean Donelan wrote:
 
> Blocking ports in the core doesn't stop stuff from spreading.  There are
> too many alternate paths in the core for systems to get infected through.
> In reality, backbones dropped 1434 packets as a traffic management practice
> (excessive traffic), not as a security management practice (protecting
> users).
 

Re: Building Cited for Housing Fuel Tanks Catches Fire [NYT]

[Bradley Dunn]

[EMAIL PROTECTED] wrote:
In any case, this problem should be solved by the city government in a 
large city. It is a fact that large cities are large telecomm hubs. It is 
a fact that large telecomm hubs need guaranteed power supplies. It is a 
fact that the individual players in telecomm want to be located near each 
other in large cities (same building, same block). The solution to this 
whole mess is for the city government to run a special power utility that 
operates a pair of safe and highly secure diesel power generating plants 
which provide dual entrance service to telecomm hotels in a specific area 
of the city. That way folks can install equipment with no batteries and no 
generators because they are getting triply redundant and diverse power 
(utility, and 2 city diesel generation plants).
And why exactly should taxpayers subsidize telecom hotels?

(And don't say it won't need to be subsidized, because if it can be 
profitable without subsidies stop posting to nanog and start talking to 
investors.)

Bradley

Re: 923Mbits/s across the ocean

[Douglas F. Calvert]

On Sat, 2003-03-08 at 15:58, [EMAIL PROTECTED] wrote:
> That's the argument that pentagon used to justify buying $40 lightbulbs. 
> Does not work, sorry.

That is not the argument used to justify buying 40 lightbulbs. They do
not actually purchase 40 lightbulbs, the prices that you see in rag
magazine reports has to do with how the budgets are handled. If you can
budget a multi-billion dollar organization and put in reasonable price
and performance controls there are many schools that would hire you
after you revolutionized public administration and the DoD...


-- 
Douglas F. Calvert <[EMAIL PROTECTED]>

Re: UK ISPs not cooperating with law enforcement

[Roland Perry]

In message <[EMAIL PROTECTED]>, Peter
Galbavy <[EMAIL PROTECTED]> writes

>Policy was, many years ago, when we were 'all' at Demon that we would
>*never* hand out any logs until there was a court order. Period. At that
>point we would roll over and stick our paws in the air... subtle hints from
>the police and others were met with this policy.

Yes, the current situation in the UK is that there are (for hacking
enquiries, but not financial matters) no police "powers" other than a
court order, but many CSPs (voice telcos especially) are sympathetic to
special pleading from the police that revealing information about their
customers is justified if it's the only way progress a criminal
investigation.

http://www.linx.net/misc/dpa28-3form.html

The recent issue with Scotland Yard might suggest that this pleading had
been unsuccessful, but they didn't then go and get a court order (for
whatever reason).

>Of course, the RIP Act brings big brother truly to life now. If only the
>civil service would stop infighting long
>enough to implement it ;-)

It was the Minister (Blunkett) who stopped the implementation, due to
police politics... For once, the civil servants were innocent.
-- 
 Roland Perry | tel: +44 20 7645 3505 | [EMAIL PROTECTED]
Director of Public Policy | fax: +44 20 7645 3529 | http://www.linx.net
 London Internet Exchange | mbl: +44 7909 68 0005 |   /contact/roland

RE: 923 Mbps across the Ocean ...

[Pete Templin]

-Original Message-
From: Marshall Eubanks [mailto:[EMAIL PROTECTED]
Sent: Friday, March 07, 2003 3:58 PM
To: David G. Andersen
Cc: Mikael Abrahamsson; [EMAIL PROTECTED]
Subject: Re: 923 Mbps across the Ocean ...

BTW, when I did  VLBI for the Navy, we used to move literally tons of
tapes around the world
per month and achieved sustained bandwidths > 1 Gbps, albeit with
FED-EX, not routers.

Does this take into account the delay from encapsulating the tapes into a FED-EX 
packet and assigning the appropriate layer 1 header, then the queueing delays 
experienced while awaiting an open buffer on the next FED-EX truck?

Pete Templin
IP Network Engineer
TexLink Communications
(210) 892-4183
[EMAIL PROTECTED]

Re: 923 Mbps across the Ocean ...

[Marshall Eubanks]

Yes. The whole system was organized around the FedEx shipping schedule, 
including
when the trucks would show up in Wiamea Canyon, Kauai  (no later than 
noon, local time).
Labels would be preprinted and boxes would be ready to go, as there was 
about 1/2 hour
from end of tape spin to beginning of the shipping window.

On Monday, March 10, 2003, at 09:53  AM, Pete Templin wrote:

-Original Message-
From: Marshall Eubanks [mailto:[EMAIL PROTECTED]
Sent: Friday, March 07, 2003 3:58 PM
To: David G. Andersen
Cc: Mikael Abrahamsson; [EMAIL PROTECTED]
Subject: Re: 923 Mbps across the Ocean ...
BTW, when I did  VLBI for the Navy, we used to move literally tons of
tapes around the world
per month and achieved sustained bandwidths > 1 Gbps, albeit with
FED-EX, not routers.
Does this take into account the delay from encapsulating the tapes into 
a FED-EX packet and assigning the appropriate layer 1 header, then the 
queueing delays experienced while awaiting an open buffer on the next 
FED-EX truck?

Pete Templin
IP Network Engineer
TexLink Communications
(210) 892-4183
[EMAIL PROTECTED]
 Regards
 Marshall Eubanks
T.M. Eubanks
Multicast Technologies, Inc.
Phone : 703-293-9601   Fax : 703-293-9609
e-mail : [EMAIL PROTECTED]
http://www.multicasttech.com
 Our New Multicast Workshop :
 http://www.multicasttech.com/workshop

Re: 69/8...this sucks

[E.B. Dreger]

> Date: Mon, 10 Mar 2003 09:46:33 +
> From: Michael.Dillon


> I have suggested that ARIN should set up an LDAP server to
> publish the delegation of all their IP address space updated

Not bad, but will the lazy ISPs set up an LDAP server to track
changes they aren't tracking now?  Will those with erroneous
filters magically change simply because of LDAP?  I still contend
the answer is is a boot to the head that screams to them, "Update
your freaking filters!"


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: Building Cited for Housing Fuel Tanks Catches Fire [NYT]

[E.B. Dreger]

BD> Date: Mon, 10 Mar 2003 02:43:15 -0800
BD> From: Bradley Dunn


BD> (And don't say it won't need to be subsidized, because if it
BD> can be profitable without subsidies stop posting to nanog and
BD> start talking to investors.)

s/investors/Congress or an ex-airline Begging Consultant/


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

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

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

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

[Mark Segal]

What surprises me most about this entire thread is the lack of centralized
filtering.

Since most service providers should be thinking about a sink hole network
for security auditing (and backscatter),  why not have ONE place where you
advertise all unreachable, or better yet -- a default (ie everything NOT
learned through BGP peers), and just forward the packets to a bit bucket..
Which is better than an access list since, now we are forwarding packets
instead of sending them to a CPU to increase router load. 

I don't think ARIN can help the situation.  ISPs just need to remove the
access lists from each router in the network and centralize them.

Regards,
mark

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


> -Original Message-
> From: E.B. Dreger [mailto:[EMAIL PROTECTED] 
> Sent: March 10, 2003 10:17 AM
> To: [EMAIL PROTECTED]
> Subject: Re: 69/8...this sucks
> 
> 
> 
> > Date: Mon, 10 Mar 2003 09:46:33 +
> > From: Michael.Dillon
> 
> 
> > I have suggested that ARIN should set up an LDAP server to 
> publish the 
> > delegation of all their IP address space updated
> 
> Not bad, but will the lazy ISPs set up an LDAP server to 
> track changes they aren't tracking now?  Will those with 
> erroneous filters magically change simply because of LDAP?  I 
> still contend the answer is is a boot to the head that 
> screams to them, "Update your freaking filters!"
> 
> 
> Eddy
> --
> Brotsman & Dreger, Inc. - EverQuick Internet Division 
> Bandwidth, consulting, e-commerce, hosting, and network building
> Phone: +1 (785) 865-5885 Lawrence and [inter]national
> Phone: +1 (316) 794-8922 Wichita
> 
> ~
> Date: Mon, 21 May 2001 11:23:58 + (GMT)
> From: A Trap <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Please ignore this portion of my mail signature.
> 
> These last few lines are a trap for address-harvesting 
> spambots. Do NOT send mail to <[EMAIL PROTECTED]>, or you 
> are likely to be blocked.
> 

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

[E.B. Dreger]

MS> Date: Mon, 10 Mar 2003 10:27:35 -0500
MS> From: Mark Segal


MS> Since most service providers should be thinking about a sink
MS> hole network for security auditing (and backscatter),  why
MS> not have ONE place where you advertise all unreachable, or
MS> better yet -- a default (ie everything NOT learned through
MS> BGP peers), and just forward the packets to a bit bucket..
MS> Which is better than an access list since, now we are
MS> forwarding packets instead of sending them to a CPU to
MS> increase router load.

Chris Morrow and Brian Gemberling (a.k.a. dies) have some fine
instructions on how to do just that.  Rob Thomas has a bogon
route server that comes in handy.

The problem with only a default:  Think when a rogue ISP decides
to advertise an unused netblock and utilize that IP space for
malicious purposes.  A route exists... do we trust it?


MS> I don't think ARIN can help the situation.  ISPs just need to

Probably not.  Nor should they need to.  Although perhaps they
could allocate other netblocks, and they _do_ charge a fair
amount for PI space... ;-)


MS> remove the access lists from each router in the network and
MS> centralize them.

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

I'm looking forward to Jon Lewis (or others) providing some stats
about just how bad the problem is... being fortunate enough not
to have [any clients in] 69/8 space I can't comment first-hand on
the severity of the problem.


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: Abstract of proposed Internet Draft for Best Current Practice (please comment)

[E.B. Dreger]

DJR> Date: Mon, 10 Mar 2003 22:17:56 +0700
DJR> From: Dr. Jeffrey Race


DJR> Please read the details in the text.  It is all spelt out
DJR> there.

I'm glad someone has spelt out how we can find our way out of the
spam maize.  Hopefully the details are explained with sufficient
granularity, and without a lot of chaff.

I didn't get a PhD from any Ivy League school, let alone in
spelling.  Of course, I don't claim to have all the answers,
either.

If your proposal works, shall we send flours?


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: Abstract of proposed Internet Draft for Best Current Practic e (please comment)

[David Barak]

--- "Dr. Jeffrey Race" <[EMAIL PROTECTED]> wrote:
> Please read the details in the text.  It is all
> spelt out there.

Well, when I read the abstract, I also got the
impression that the approach recommended was to
"filter first, ask questions later."

There were a few flaws in the assumptions:
1) Profitable, well-run companies always use BCPs.
   Simply put, unless you define "profitable and
well-run" to mean "uses BCPs" what you will find is
that some networks which have an admirable adherence
to best practices afte often not profitable, while
many networks which do not are quite profitable.

2) A consensus-based emergent governance will solve
the problem.  
   
   This is a fallacy, as Douglas Hofstadter
demonstrated in Metamagical Themas: he ran an iterated
prisoner's dilemma-type game among logicians (!) to
see whether they would all demonstrate cooperative
behavior, and to his surprise (but not to anyone
else's), they did not.  In fact, if the ISP community
were to sign on to such a system in the same ratio as
the logicians did in Hofstadter's experiment, we would
have the exact same solution which we have now: which
is a multitude of small-scale approximate solutions to
the same problem.
  The second piece of the fallacy is the idea that
emergent systems can be predicted: there is a reason
they're called "Emergent" systems - they arise from
the discrete actions of the constituent members rather
than from design.  Any attempt to build a system to
have a certain outcome is by definition not an
emergent system.

3) The abstract does come across as overzealous - if
you are proposing a "draft," you should expect to
receive positive and negative comments.  In fact, you
should probably modify the draft to answer the
negative comments received.

4)The area of the "spamverse" would steadily shrink in
importance and relevance.

   Even assuming that everything else were as you
describe, and that the BCP ISPs would be willing to
suffer the customer pain of not being able to
communicate with the non-BCP ISPs, what would keep the
spammers from finding another technological solution? 
Why would you think that they would not employ their
(considerable) technical skill to getting around any
mechanism we employ?  
  The Cantor Diagonal method could apply here: it is
impossible to predict every possible situation.  The
spammers are highly motivated (big $$), and the simple
fact which most people ignore is this:

  Spam works

If Spam didn't generate money, people wouldn't do it. 
I think that any solution will have to involve getting
people to not respond to spam, and steadily raising
the cost of sending mass email, so that there will be
a financial disincentive to do so.

Just my $.02.


=
David Barak
-fully RFC 1925 compliant-

__
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/

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

[Haesu]

> Since most service providers should be thinking about a sink hole network
> for security auditing (and backscatter),  why not have ONE place where you
> advertise all unreachable, or better yet -- a default (ie everything NOT
> learned through BGP peers), and just forward the packets to a bit bucket..
> Which is better than an access list since, now we are forwarding packets
> instead of sending them to a CPU to increase router load.
>
> I don't think ARIN can help the situation.  ISPs just need to remove the
> access lists from each router in the network and centralize them.


I totally agree with you. However, as always, centralized systems, while
ease management and scalability, everything becomes a trust issue and a
single point of failure or source of problems...

May be, this could be a subscription based type of service, something like
RADB, where everyone subscribes into a central filtering list that is
managed by a seperate organization? I really like the Rob's bogon
route-server setup.

-hc

 >
> Regards,
> mark
>
> --
> Mark Segal
> Director, Data Services
> Futureway Communications Inc.
> Tel: (905)326-1570
>
>
> > -Original Message-
> > From: E.B. Dreger [mailto:[EMAIL PROTECTED]
> > Sent: March 10, 2003 10:17 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: 69/8...this sucks
> >
> >
> >
> > > Date: Mon, 10 Mar 2003 09:46:33 +
> > > From: Michael.Dillon
> >
> >
> > > I have suggested that ARIN should set up an LDAP server to
> > publish the
> > > delegation of all their IP address space updated
> >
> > Not bad, but will the lazy ISPs set up an LDAP server to
> > track changes they aren't tracking now?  Will those with
> > erroneous filters magically change simply because of LDAP?  I
> > still contend the answer is is a boot to the head that
> > screams to them, "Update your freaking filters!"
> >
> >
> > Eddy
> > --
> > Brotsman & Dreger, Inc. - EverQuick Internet Division
> > Bandwidth, consulting, e-commerce, hosting, and network building
> > Phone: +1 (785) 865-5885 Lawrence and [inter]national
> > Phone: +1 (316) 794-8922 Wichita
> >
> > ~
> > Date: Mon, 21 May 2001 11:23:58 + (GMT)
> > From: A Trap <[EMAIL PROTECTED]>
> > To: [EMAIL PROTECTED]
> > Subject: Please ignore this portion of my mail signature.
> >
> > These last few lines are a trap for address-harvesting
> > spambots. Do NOT send mail to <[EMAIL PROTECTED]>, or you
> > are likely to be blocked.
> >
>

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

[Mark Segal]

> From: E.B. Dreger [mailto:[EMAIL PROTECTED] 
>   
> The problem with only a default:  Think when a rogue ISP 
> decides to advertise an unused netblock and utilize that IP 
> space for malicious purposes.  A route exists... do we trust it?
But that kinda filtering should be done at BGP route ingress by, you, or the
transit provider of choice.

I'm not suggesting that a default is the only way.  It just happens to be a
good lazy way for the people who can't seem to find the time to check the
IANA web page at least once a quarter.. :).

Regards,
Mark


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

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

[Mark Segal]

> -Original Message-
> From: Haesu [mailto:[EMAIL PROTECTED] 
>
> I totally agree with you. However, as always, centralized 
> systems, while ease management and scalability, everything 
> becomes a trust issue and a single point of failure or source 
> of problems...
Single point of failure? Not sure I agree with you.. What happens if your
sink hole disapears? Your filtering goes out.. O no.. Please not that.
Hardley think that is even a reason for a noc to page you... :). 

Regards,
Mark

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

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

[Haesu]

Perhaps I should have been more clear on what I was saying.. Sorry about
that..

What I really meant by single pt. of failure was... problems of losing the
filtering list if the central system is down... Granted, this would not
cause any network issues..

-hc

On Mon, 10 Mar 2003, Mark Segal wrote:

>
>
> > -Original Message-
> > From: Haesu [mailto:[EMAIL PROTECTED]
> >
> > I totally agree with you. However, as always, centralized
> > systems, while ease management and scalability, everything
> > becomes a trust issue and a single point of failure or source
> > of problems...
> Single point of failure? Not sure I agree with you.. What happens if your
> sink hole disapears? Your filtering goes out.. O no.. Please not that.
> Hardley think that is even a reason for a noc to page you... :).
>
> Regards,
> Mark
>
> --
> Mark Segal
> Director, Data Services
> Futureway Communications Inc.
> Tel: (905)326-1570
>

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

[Joe Abley]

On Monday, Mar 10, 2003, at 10:54 Canada/Eastern, Haesu wrote:

Since most service providers should be thinking about a sink hole 
network
for security auditing (and backscatter),  why not have ONE place 
where you
advertise all unreachable, or better yet -- a default (ie everything 
NOT
learned through BGP peers), and just forward the packets to a bit 
bucket..
Which is better than an access list since, now we are forwarding 
packets
instead of sending them to a CPU to increase router load.

I don't think ARIN can help the situation.  ISPs just need to remove 
the
access lists from each router in the network and centralize them.
I totally agree with you. However, as always, centralized systems, 
while
ease management and scalability, everything becomes a trust issue and a
single point of failure or source of problems...
I can think of two organisations which could probably take care of a 
good chunk of the problem, if people were prepared to leave it up to 
them. The routing system is already largely dependent on the 
interoperability of bugs produced by these people, and so arguably no 
additional trust would be required.

One organisation has a name starting with "j", and the other starts 
with "c".

Joe

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

[Christopher L. Morrow]

On Mon, 10 Mar 2003, Mark Segal wrote:

>
> What surprises me most about this entire thread is the lack of centralized
> filtering.

Central as in 'ALL INTERNET USES MY FILTERING SERVICE' or... 'My network
uses my filter service and your network uses yours'?

>
> Since most service providers should be thinking about a sink hole network
> for security auditing (and backscatter),  why not have ONE place where you
> advertise all unreachable, or better yet -- a default (ie everything NOT
> learned through BGP peers), and just forward the packets to a bit bucket..

This can be VERY dangerous, the default part atleast. At one point we, as
an experiment in stupidity (it turns out) announced 0/1 (almost default).
We quickly recieved well over 600kpps to that announcement. This in a very
steady stream... When one announces a very large block like this there are
always unintended  consequences :( There is alot of traffic spewed out to
non-available address space, this traffic is very large when aggregated :)

> Which is better than an access list since, now we are forwarding packets
> instead of sending them to a CPU to increase router load.

Yes, routes to null0 or to a dead interface/collection host are much nicer
than acls. So, for this perhaps instead of acls uRPF would be a solution
for the implementor?

>
> I don't think ARIN can help the situation.  ISPs just need to remove the
> access lists from each router in the network and centralize them.
>

Or, have an 'automated' manner to deploy/audit/change said acls? RAT
perhaps or some other 'automated' router config checking/deployment tool?

> Regards,
> mark
>
> --
> Mark Segal
> Director, Data Services
> Futureway Communications Inc.
> Tel: (905)326-1570
>
>
> > -Original Message-
> > From: E.B. Dreger [mailto:[EMAIL PROTECTED]
> > Sent: March 10, 2003 10:17 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: 69/8...this sucks
> >
> >
> >
> > > Date: Mon, 10 Mar 2003 09:46:33 +
> > > From: Michael.Dillon
> >
> >
> > > I have suggested that ARIN should set up an LDAP server to
> > publish the
> > > delegation of all their IP address space updated
> >
> > Not bad, but will the lazy ISPs set up an LDAP server to
> > track changes they aren't tracking now?  Will those with
> > erroneous filters magically change simply because of LDAP?  I
> > still contend the answer is is a boot to the head that
> > screams to them, "Update your freaking filters!"
> >
> >
> > 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: [Re: 69/8...this sucks -- Centralizing filtering..]

[Joshua Smith]

interesting idea, enable it by default, with the option to turn it off
(i hope)...

my-big-fat-router# conf t
my-big-fat-router(config)# no ip clueless

Joe Abley <[EMAIL PROTECTED]> wrote:
> 
> 
> On Monday, Mar 10, 2003, at 10:54 Canada/Eastern, Haesu wrote:
> 
> >> Since most service providers should be thinking about a sink hole 
> >> network
> >> for security auditing (and backscatter),  why not have ONE place 
> >> where you
> >> advertise all unreachable, or better yet -- a default (ie everything 
> >> NOT
> >> learned through BGP peers), and just forward the packets to a bit 
> >> bucket..
> >> Which is better than an access list since, now we are forwarding 
> >> packets
> >> instead of sending them to a CPU to increase router load.
> >>
> >> I don't think ARIN can help the situation.  ISPs just need to remove 
> >> the
> >> access lists from each router in the network and centralize them.
> >
> > I totally agree with you. However, as always, centralized systems, 
> > while
> > ease management and scalability, everything becomes a trust issue and a
> > single point of failure or source of problems...
> 
> I can think of two organisations which could probably take care of a 
> good chunk of the problem, if people were prepared to leave it up to 
> them. The routing system is already largely dependent on the 
> interoperability of bugs produced by these people, and so arguably no 
> additional trust would be required.
> 
> One organisation has a name starting with "j", and the other starts 
> with "c".
> 
> 
> Joe
> 



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

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

[E.B. Dreger]

CLM> Date: Mon, 10 Mar 2003 17:30:27 + (GMT)
CLM> From: Christopher L. Morrow


CLM> This can be VERY dangerous, the default part atleast. At one
CLM> point we, as an experiment in stupidity (it turns out)
CLM> announced 0/1 (almost default).  We quickly recieved well
CLM> over 600kpps to that announcement. This in a very steady

Announced via IGP or BGP?  I hope/assume the former, but am
somewhat surprised at the traffic volume... even for UUNet.


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

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

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

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

[Christopher L. Morrow]

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

>
> CLM> Date: Mon, 10 Mar 2003 17:30:27 + (GMT)
> CLM> From: Christopher L. Morrow
>
>
> CLM> This can be VERY dangerous, the default part atleast. At one
> CLM> point we, as an experiment in stupidity (it turns out)
> CLM> announced 0/1 (almost default).  We quickly recieved well
> CLM> over 600kpps to that announcement. This in a very steady
>
> Announced via IGP or BGP?  I hope/assume the former, but am
> somewhat surprised at the traffic volume... even for UUNet.

bgp, no-export.

>
>
> Eddy
> --
> Brotsman & Dreger, Inc. - EverQuick Internet Division
> Bandwidth, consulting, e-commerce, hosting, and network building
> Phone: +1 (785) 865-5885 Lawrence and [inter]national
> Phone: +1 (316) 794-8922 Wichita
>
> ~
> Date: Mon, 21 May 2001 11:23:58 + (GMT)
> From: A Trap <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Please ignore this portion of my mail signature.
>
> These last few lines are a trap for address-harvesting spambots.
> Do NOT send mail to <[EMAIL PROTECTED]>, or you are likely to
> be blocked.
>

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

[jlewis]

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

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

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

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

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

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

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

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

[Michael . Dillon]

>> I don't think ARIN can help the situation.  ISPs just need to remove 
the
>> access lists from each router in the network and centralize them.

>I totally agree with you. However, as always, centralized systems, while
>ease management and scalability, everything becomes a trust issue and a
>single point of failure or source of problems...

Yeah, who would you trust to maintain a centralized database of IP address 
ranges?

>May be, this could be a subscription based type of service, something 
like
>RADB, where everyone subscribes into a central filtering list that is
>managed by a seperate organization? 

Yup, you're right. This should be done by a 3rd party organization, not an 
ISP. I wonder whether there are any 3rd party organizations trusted by 
ISPs that have experience in maintaining a database of IP address ranges?

ARIN, perhaps?

>I really like the Rob's bogon
>route-server setup.

That's probably because you are a router geek. I have nothing against 
Rob's setup but I know that the vast majority of geeks know nothing about 
route-servers and have no incentive to learn about them. But they all know 
what LDAP is, some of them already run LDAP servers and the rest probably 
plan to learn more about LDAP some day. We could leverage that widespread 
knowledge of LDAP by publishing route data (or any other data regarding 
attributes of IP address ranges) using the IETF standard LDAPv3 protocol.

In fact, I know that Rob is considering setting up an LDAP server as an 
alternative way to offer bogon data. I think this is a great idea as a 
testbed, i.e. offer the data through many protocols and see which is most 
popular. Howevere, I think that when it does become popular, it needs to 
be integrated with ARIN's authoritative database of IP address 
delegations.

-- Michael Dillon

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

[Michael . Dillon]

>What I really meant by single pt. of failure was... problems of losing 
the
>filtering list if the central system is down... Granted, this would not
>cause any network issues..

We know how to set up central authorities without central systems or 
obvious single points of failure. For instance, the DNS has a single root 
authority but there are 13 distributed servers publishing authoritative 
data. And not all of those servers are single systems. For some time now 
Vixie's root server has been at least two systems using his own FreeBSD 
kernel hack to handle load balancing and failover.

Also, people are beginning to realize that having a local cache of 
authoritative data is a wise thing and is not very difficult to do. That's 
why ISC is now offering a replica service for network operators to set up 
local copies of Vixie's F root server.

I would expect that the LDAP service for IP address range attributes would 
leverage all of this knowledge about architecture. LDAP may a more 
versatile protocol than DNS but it is clearly from the same family tree of 
directory service protocols and there are no major roadblocks preventing 
it from being deployed in a sane fashion.

--Michael Dillon

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

[Rob Thomas]

Hi, NANOGers.

] But they all know what LDAP is...

I don't know that I'd say that.  I'll bet they all are more familiar
with HTTP and DNS (both have bogon feeds available).  I view LDAP as
yet another way to share the data, not the ultimate way to share the
data.  I'm not trying to start a flame war here, just pointing out
that a variety of feeds meet many more requirements, and that there
are several types of data feeds available now.  This includes the
recently added pure text bogon files, suitable for easy parsing.

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

] In fact, I know that Rob is considering setting up an LDAP server as an

Yep, it is high on my burgeoning to-do list.  :)

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

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

[Stephen J. Wilcox]

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

You have been busy!

> I haven't decided yet whether I'll send automated messages to all the 
> broken networks and give them time to respond and fix their filters, or 
> just post them all to NANOG when the list is complete.
> 
> Are people interested in seeing the full list (at least the ones I find)
> of networks that filter 69/8?

Why not do a weekly report of some sort. Post a summary to nanog with a 
reference to the website containing the full list. If you can group them by ASN 
you can do a report a la cidr-report of top 20 offenders and include that in 
your nanog post.

I think this would be a good way to sustain momentum in your worthy cause..

Steve

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

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

[Michael . Dillon]

>I can think of two organisations which could probably take care of a 
>good chunk of the problem, if people were prepared to leave it up to 
>them. The routing system is already largely dependent on the 
>interoperability of bugs produced by these people, and so arguably no 
>additional trust would be required.

Cisco is already a member of ARIN. If anyone out there buys Juniper 
routers, perhaps you might suggest that they also join ARIN and work 
together with Cisco and the network operators to move this forward.

--Michael Dillon

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

[Joe Boyce]

Monday, March 10, 2003, 9:52:06 AM, you wrote:

jlo> I think the only way that's relatively guaranteed to be effective is to
jlo> move a critical resource (like the gtld-servers) into new IP blocks when 
jlo> previously reserved blocks are assigned to RIR's.

I agree with you.  But then since I've been allocated 69/8 I guess you
can say I'm a bit biased.

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

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

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

Again, since I've been recently allocated in the 69/8 range, I'd love
to see this completed list.

We've only renumbered our internal workstations into this range, so
no customer nets are affected as of yet.  But we are about to plunge
into our renumbering, so I'm sure customers are going to start yelling
then.

However, I think this is going to be an on-going problem, even if the
gtld-servers were renumbered into 69/8.

Do a simple Google search on ip firewalling.  You'll find lots of
examples using ipchains, iptables, etc, that show example configs.
These example configs usually show 69/8 as a bogon network and
recommends filtering them.

So, in my opinion it's only going to be a matter of time before some
network administrator looking to implement a firewall stumbles across
one of these broken sample configs and breaks connectivity to me
again.

In essence, it's going to be an ongoing problem, sure we can fix
networks now that we know are broken, but it's going to be an ongoing
problem that we are going to have to deal with.

Regards,

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

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

[Jack Bates]

From: "Mark Segal"

> Since most service providers should be thinking about a sink hole network
> for security auditing (and backscatter),  why not have ONE place where you
> advertise all unreachable, or better yet -- a default (ie everything NOT
> learned through BGP peers), and just forward the packets to a bit bucket..
> Which is better than an access list since, now we are forwarding packets
> instead of sending them to a CPU to increase router load.
>
It would be nice if vendors had a variant to (in cisco terms) ip verify
unicast reverse-path that would work in asymmetrical networks. If you only
have a single link to the internet, the command works well, but then why
would you ever run bgp for a single uplink?

-Jack

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

[Barry Raveendran Greene]

> CLM> From: Christopher L. Morrow
> 
> CLM> This can be VERY dangerous, the default part atleast. At one
> CLM> point we, as an experiment in stupidity (it turns out)
> CLM> announced 0/1 (almost default).  We quickly recieved well
> CLM> over 600kpps to that announcement. This in a very steady
> 
> Announced via IGP or BGP?  I hope/assume the former, but am
> somewhat surprised at the traffic volume... even for UUNet.


I'm not surprised. My experience with defaults in ISPs is the same. The router
advertising the default (or any large prefix) becomes a "packet vacuum" for any
spoofed source packet returning backscatter and all those other auto-bots and
worms looking for vulnerable machines. It turns the router into a sink hole.

What saves many providers today is that these large route injections are spread
across all their peering routers. This is like anycasting the prefix
advertisements. People are discussing is putting these advertisements on
anycasted Sink Holes. So instead of having the CIDR prefixes and the Null 0
lock-ups on the peering routers, you would put them on anycast Sink Hole
routers. The anycast spreads the packet black hole load over several sink holes
spread over the network. 

Barry

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

[McBurnett, Jim]

I saw it version of this earlier:

Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)#ip route clueless

No seriously..
What if that customer has a VPN design with a dial backup behind their firewall.
Using BGP to suck down a default route from the provider, 
when that default route goes away, then the internal router initiates the dial 
backup solution to the remote network. 
They should not be sending out any BGP routes though..
But.. See example above... 

OR

They are in the process of preparing for Multi-homeing and just
have not got it up yet... You know one provider is toiling with the
T-1 facility FOC etc..

Sure this is somewhat unusual, but I have seen it, and corrected it...

Jim
>It would be nice if vendors had a variant to (in cisco terms) ip verify
>unicast reverse-path that would work in asymmetrical networks. 
>If you only
>have a single link to the internet, the command works well, 
>but then why
>would you ever run bgp for a single uplink?
>
>-Jack
>
>

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

[Jack Bates]

From: "McBurnett, Jim"

>
> No seriously..
> What if that customer has a VPN design with a dial backup behind their
firewall.
> Using BGP to suck down a default route from the provider,
> when that default route goes away, then the internal router initiates the
dial
> backup solution to the remote network.
> They should not be sending out any BGP routes though..
> But.. See example above...
>


> Sure this is somewhat unusual, but I have seen it, and corrected it...
>
Oh, I agree that there are times when BGP is used in a single uplink
scenario, but it is not common. However, someone pointed me to ip verify
unicast source reachable-via any which seems to be available on some of the
cisco Service provider releases. It's an interesting concept and I'm itching
to play with it. If you aren't in my routing table, then why accept the IP
address?

-Jack

Re: 69/8...this sucks

[Jeff S Wheeler]

On Fri, 2003-03-07 at 23:15, Jack Bates wrote:
> In defense of ARIN, the ice on a net block has to be broken at some point.
> They could wait 3 years and notify every list every hour of every day for
> those 3 years and there would still be many networks filtering those
> networks. The only way to catch it is to notice the block and make contact
> with the network. In many cases, personal contact is necessary as emails are
> often misunderstood or ignored.
I repeat my suggestion that a number of DNS root-servers or gtld-servers
be renumbered into 69/8 space.  If the DNS "breaks" for these neglected
networks, I suspect they will quickly get enough clue to fix their ACLs.

Add Eddy's suggestion that the addresses all end in .0 or .255 and you
have a fine machine for cleaning up a few old, irritating problems.

--
Jeff S Wheeler <[EMAIL PROTECTED]>

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

[McBurnett, Jim]

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

Well, If you don't access my address and I happen to be 
a poor ole 69/8 or 
then your customers may not be able to get to me...
But there are an aweful lot of ifs to this ^^.
And I don't remember that command syntax at all

Yea, I want to test that too..
Maybe I can make a visit to the local Cisco office and borrow
some time in the Lab I want to see this is action, and how it
may affect my routing... or maybe I can get a quick answer from the local
CCIEs...

Hey have you checked the Feature Navigator and seen which versions it
is in?  Catch me off-list

Later,
J

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

[Michael Whisenant]

Jon et al,

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.

You could reach MANY NASA locations, but those at one particular center,
and that issue was related to a firewall update at ONLY one particular
center. This filter was placed in after August when the cental bogon was
removed at the ingress to the network.

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.


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

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

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

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

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

Does Atlantic.Net get an ARIN discount for doing all this leg work? :)

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

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

[E.B. Dreger]

BRG> Date: Mon, 10 Mar 2003 11:17:55 -0800
BRG> From: Barry Raveendran Greene


BRG> EBD> Announced via IGP or BGP?  I hope/assume the former,
BRG> EBD> but am somewhat surprised at the traffic volume... even
BRG> EBD> for UUNet.

BRG> I'm not surprised. My experience with defaults in ISPs is
BRG> the same. The router advertising the default (or any large
BRG> prefix) becomes a "packet vacuum" for any spoofed source
BRG> packet returning backscatter and all those other auto-bots
BRG> and worms looking for vulnerable machines. It turns the
BRG> router into a sink hole.

Assuming one's upstreams and peers lack 'deny le 7'.


BRG> What saves many providers today is that these large route
BRG> injections are spread across all their peering routers. This
BRG> is like anycasting the prefix advertisements. People are
BRG> discussing is putting these advertisements on anycasted Sink
BRG> Holes. So instead of having the CIDR prefixes and the Null 0
BRG> lock-ups on the peering routers, you would put them on
BRG> anycast Sink Hole routers. The anycast spreads the packet
BRG> black hole load over several sink holes spread over the
BRG> network.

IMHO, this is a good thing.


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

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

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

Re: 69/8...this sucks

[Stephen J. Wilcox]

On 10 Mar 2003, Jeff S Wheeler wrote:

> 
> On Fri, 2003-03-07 at 23:15, Jack Bates wrote:
> > In defense of ARIN, the ice on a net block has to be broken at some point.
> > They could wait 3 years and notify every list every hour of every day for
> > those 3 years and there would still be many networks filtering those
> > networks. The only way to catch it is to notice the block and make contact
> > with the network. In many cases, personal contact is necessary as emails are
> > often misunderstood or ignored.
>
> I repeat my suggestion that a number of DNS root-servers or gtld-servers
> be renumbered into 69/8 space.  If the DNS "breaks" for these neglected
> networks, I suspect they will quickly get enough clue to fix their ACLs.
> 
> Add Eddy's suggestion that the addresses all end in .0 or .255 and you
> have a fine machine for cleaning up a few old, irritating problems.

Nice idea in principal (from a purist point of view) but its not practical, I 
hope your not serious..!

Steve

Re: 69/8...this sucks

[jlewis]

On 10 Mar 2003, Jeff S Wheeler wrote:

> I repeat my suggestion that a number of DNS root-servers or gtld-servers
> be renumbered into 69/8 space.  If the DNS "breaks" for these neglected
> networks, I suspect they will quickly get enough clue to fix their ACLs.

Moving a number of them won't do anything.  Broken networks would just use
the ones they can reach.  Moving the root-servers isn't a good option
anyway since lots of Bind setups are distributed with a . hints file
containing A records for the root-servers, and these hints files are 
updated probably less frequently than bogon filters.

Since the root-servers have been reduced to refering queries to the
gtld-servers and nstld servers and perhaps others, these latter servers
would be the ones to move that would cause no pain for networks that work,
and immediate notification and motivation to fix filters for networks with 
outdated filters.

I don't suppose there's even a slim chance of this happening?

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

[E.B. Dreger]

JSW> Date: 10 Mar 2003 15:23:52 -0500
JSW> From: Jeff S Wheeler


JSW> I repeat my suggestion that a number of DNS root-servers or
JSW> gtld-servers be renumbered into 69/8 space.  If the DNS
JSW> "breaks" for these neglected networks, I suspect they will
JSW> quickly get enough clue to fix their ACLs.
JSW>
JSW> Add Eddy's suggestion that the addresses all end in .0 or
JSW> .255 and you have a fine machine for cleaning up a few old,
JSW> irritating problems.

I suggest a rotation like so:

Jan-Apr: 69.w.w.0
Apr-Jul: 69.x.x.255
Jul-Oct: 70.y.y.0
Oct-Jan: 70.z.z.255

where the middle two octets are predetermined ahead of time.

IIRC, some RFC recommends updating the root zone cache monthly...
following this would ensure one had proper root/gTLD addresses.

The above also would break DNS for broken networks for a two
month stretch... long enough to flush out bad rules.


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

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

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

Re: 69/8...this sucks

[E.B. Dreger]

SJW> Date: Mon, 10 Mar 2003 20:35:51 + (GMT)
SJW> From: Stephen J. Wilcox


SJW> Nice idea in principal (from a purist point of view) but its

No?


SJW> not practical, I hope your not serious..!

I am.


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

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

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

Re: 69/8...this sucks

[Jared Mauch]

On Mon, Mar 10, 2003 at 08:49:04PM +, E.B. Dreger wrote:
> 
> JSW> Date: 10 Mar 2003 15:23:52 -0500
> JSW> From: Jeff S Wheeler
> 
> 
> JSW> I repeat my suggestion that a number of DNS root-servers or
> JSW> gtld-servers be renumbered into 69/8 space.  If the DNS
> JSW> "breaks" for these neglected networks, I suspect they will
> JSW> quickly get enough clue to fix their ACLs.
> JSW>
> JSW> Add Eddy's suggestion that the addresses all end in .0 or
> JSW> .255 and you have a fine machine for cleaning up a few old,
> JSW> irritating problems.
> 
> I suggest a rotation like so:
> 
>   Jan-Apr: 69.w.w.0
>   Apr-Jul: 69.x.x.255
>   Jul-Oct: 70.y.y.0
>   Oct-Jan: 70.z.z.255
> 
> where the middle two octets are predetermined ahead of time.
> 
> IIRC, some RFC recommends updating the root zone cache monthly...
> following this would ensure one had proper root/gTLD addresses.
> 
> The above also would break DNS for broken networks for a two
> month stretch... long enough to flush out bad rules.
> 

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

This will leave the clueless to buy a clue and
stimulate the economy ;-)

- jared

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

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

[jlewis]

On Mon, 10 Mar 2003, Michael Whisenant wrote:

> First I appreciate your message that you sent to us at NASA late Friday
> regarding a new address block that you received from ARIN. In that message
> you suggest that the issue was a BOGON route filter that had not been
> updated. Then without allowing sufficient time to respond to your message
> (you sent it to an administrative account and not the NOC) you decided to
> flame NASA.

My mention of NASA wasn't meant at all as a flame.  It was just an example
that not all the networks with outdated filters are remote nets in far
away countries that my customers wouldn't care about.  A few I've
found are.  I had to look up the country code to find that .al is Albania.  

I had actually planned to mention at some point that NASA was the first
(only so far) network to respond to the few messages I sent out late last
friday, and that their reported network has already been fixed.  I can
only assume that none of the previous 94 allocation holders of 69/8 space
noticed or complained to the right people.

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

As for sending the message to the wrong addresses, I can only suggest 
updating your ARIN info.  I sent the message to all the POCs (except the 
abuse one) for the relevant NetRange.  This is what I'll be doing when I 
send out the automated messages.  The ones sent friday were done by hand.

Can you elaborate on how a firewall config was the problem?  If whatever
was done there is commonly done, it may be worth revising my form message
before I send out a large number of them.

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

RE: 69/8...this sucks

[McBurnett, Jim]

>From EB Dreger
>
>I suggest a rotation like so:
>
>   Jan-Apr: 69.w.w.0
>   Apr-Jul: 69.x.x.255
>   Jul-Oct: 70.y.y.0
>   Oct-Jan: 70.z.z.255
>
>where the middle two octets are predetermined ahead of time.
>
>IIRC, some RFC recommends updating the root zone cache monthly...
>following this would ensure one had proper root/gTLD addresses.
>
>The above also would break DNS for broken networks for a two
>month stretch... long enough to flush out bad rules.
>
>
>Eddy

Okay, let's assume that we all agree to this..
Who are the players?
ARIN, gTLD Owners, and who else?
Let's get some emails fired off..
Who is going to ARIN in Memphis?
Jack? Dr Race?  Volunteers to broach this?

Any gTLD owners on list?
Let's go for it..
I think this is a great Idea...

Maybe we need to look at applying this elsewhere


J

Re: 69/8...this sucks

[Doug Barton]

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

>
> JSW> Date: 10 Mar 2003 15:23:52 -0500
> JSW> From: Jeff S Wheeler
>
>
> JSW> I repeat my suggestion that a number of DNS root-servers or
> JSW> gtld-servers be renumbered into 69/8 space.  If the DNS
> JSW> "breaks" for these neglected networks, I suspect they will
> JSW> quickly get enough clue to fix their ACLs.
> JSW>
> JSW> Add Eddy's suggestion that the addresses all end in .0 or
> JSW> .255 and you have a fine machine for cleaning up a few old,
> JSW> irritating problems.
>
> I suggest a rotation like so:
>
>   Jan-Apr: 69.w.w.0
>   Apr-Jul: 69.x.x.255
>   Jul-Oct: 70.y.y.0
>   Oct-Jan: 70.z.z.255

This wouldn't actually accomplish what you're trying to do. The resolvers
that couldn't reach those root and/or TLD servers that are behind the
'broken' networks would simply shift their traffic to the ones that they
could reach. The only thing you'd accomplish by this is an increased load
on the root/TLD servers that are in their normal locations.

Doug

-- 

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

RE: 69/8...this sucks

[McBurnett, Jim]

>> IIRC, some RFC recommends updating the root zone cache monthly...
>> following this would ensure one had proper root/gTLD addresses.
>> 
>> The above also would break DNS for broken networks for a two
>> month stretch... long enough to flush out bad rules.
>> 
>
>   You want to move things like gtld servers,
>yahoo/google (and other 'important' things), including
>things like oscar.toc.aol.com into these.
>
>   This will leave the clueless to buy a clue and
>stimulate the economy ;-)
>
>   - jared

Hey if it will be a great Stimulas package I bet we could get
congressional research funding to try it. ;)

J

Re: 69/8...this sucks

[Valdis . Kletnieks]

On Mon, 10 Mar 2003 16:00:01 EST, "McBurnett, Jim" said:

> > This will leave the clueless to buy a clue and
> >stimulate the economy ;-)
> Hey if it will be a great Stimulas package I bet we could get
> congressional research funding to try it. ;)

Note the obvious bootstrapping problem with most Congresscritters :)


pgp0.pgp
Description: PGP signature

Re: 69/8...this sucks

[E.B. Dreger]

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


DB> This wouldn't actually accomplish what you're trying to do.

No?


DB> The resolvers that couldn't reach those root and/or TLD
DB> servers that are behind the 'broken' networks would simply
DB> shift their traffic to the ones that they could reach. The

And which would those reachable ones be?


DB> only thing you'd accomplish by this is an increased load
DB> on the root/TLD servers that are in their normal locations.

A:  69.0.1.255
B:  69.22.233.255
C:  69.87.152.255
:   :   :
M:  69.255.254.255

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.


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

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

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

Re: 69/8...this sucks

[Kevin Loch]

Stephen J. Wilcox wrote:

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

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

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

[Russell Heilling]

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

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

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

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


pgp0.pgp
Description: PGP signature

Re: 69/8...this sucks

[Doug Barton]

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

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

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

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

Doug

-- 

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

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

[Todd A. Blank]

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

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

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

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

Todd
IPOutlet LLC


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


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

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

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

previously reserved blocks are assigned to RIR's.

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

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

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

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

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

[Daniel Roesen]

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

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


Regards,
Daniel

Re: 69/8...this sucks

[E.B. Dreger]

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


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

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

*plonk*


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

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

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

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

[Simon Lyall]

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

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

I nominate the arin.net nameservers.

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

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

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

[E.B. Dreger]

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


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

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

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

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

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

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


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

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

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

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

[Jack Bates]

From: "Simon Lyall" 

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

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

-Jack

RE: 69/8...this sucks

[Frank Scalzo]

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

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

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

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


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

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

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

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

KL

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

[James-lists]

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

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

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

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

 

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

[jlewis]

On Tue, 11 Mar 2003, Simon Lyall wrote:

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

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

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

RE: 69/8...this sucks

[E.B. Dreger]

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


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

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


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

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

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

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

[E.B. Dreger]

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


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

Agree.

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


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

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

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

RE: 69/8...this sucks

[Rob Thomas]

Hi, NANOGers.

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

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

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

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

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

scope of the 69/8 problem

[E.B. Dreger]

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


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

I'm eager to see stats indicating how large the problem is.  If
the problem is this severe, it seems all the more wrong to let
innocent third parties suffer due to what IP space was bestowed
upon them.

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.


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.

Fwd: Re. Port 445 issues (was: Port 80 Issues)

[Jonathan Claybaugh]

A fine gentleman in New Zealand passed this information along.  A nice 
in-depth analysis.
A sign of infection seems to be heavy outbound traffic on 5800 and 5900, which 
could be useful if you want to stop an outbound flood without null routing 
the destination network.


-Original Message-
From: Arjen De Landgraaf
Sent: Monday, 10 March 2003 12:18 p.m.
To: 'Jonathan Claybaugh'; [EMAIL PROTECTED]
Subject: RE: Port 445 issues (was: Port 80 Issues)


E-Secure-IT issued a security alert on Saturday New Zealand Time.
Info:

This attack is currently intensifying. (See the DShield port 445 graph
website at the bottom of this alert for info on increase.)

For updates we strongly advise subscribers to activate their alert
notifications on the E-Secure-IT folder:
"Port 445 Worm info" in location:
http://www.e-secure-it.co.nz/dscgi/ds.py/View/Collection-2519

New info on 445 will not be placed in this Virus Alert folder anymore, but
only in the new port 445 folder instead.
This is done to keep the "virus alerts"  free for not 445 related alerts.

Analysis (combined info from messages collected in the port 445 folder):

Early indication of possible infection:

1. Your infrastrucutre contains server(s) running Windows 2000 or NT
2. Server(s) have (incoming) port 445 open
3. Outgoing ports 5800 and 5900 opened (activated by worm)
4. Server(s) sending large quantities of packets to 445 out with consecutive
IP's as destination addresses.
5. Servers contain a Dvldr32.exe executable (responsible for outgoing
packets)

Other indications(see also file analysis further down this alert):

Possible Abnormal files installed:  file size

dvldr32.exe  %windir%/system32(NT/2K)%windir%/system(9x)
745,984
explorer.exe  %windir%/fonts212,992
omnithread_rt.dll %windir%/fonts  57,344
VNCHooks.dll %windir%/fonts   32,768
rundll32.exe %windir%/fonts   29,336
cygwin1.dll %windir%/system32(NT/2K)944,968
cygwin1.dll %windir%/system(9x) 944,968
C:\WINDOWS\Start Menu\Programs\Startup\inst.exe
684,562
C:\WINNT\All Users\Start Menu\Programs\Startup\inst.exe
684,562

Possible Register changes:

The regedit table is modified as follows:
REGEDIT4

[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run]
"TaskMan"="C:\\WINDOWS\\Fonts\\rundll32.exe"
"Explorer"="C:\\WINDOWS\\Fonts\\explorer.exe"
[HKEY_CURRENT_USER\Software\ORL]

[HKEY_CURRENT_USER\Software\ORL\WinVNC3]
"SocketConnect"=dword:0001
"AutoPortSelect"=dword:0001
"InputsEnabled"=dword:0001
"LocalInputsDisabled"=dword:
"IdleTimeout"=dword:
"QuerySetting"=dword:0002
"QueryTimeout"=dword:000a
"Password"=hex:[here we do some shields]
"PollUnderCursor"=dword:0001
"PollForeground"=dword:0001
"PollFullScreen"=dword:0001
"OnlyPollConsole"=dword:0001
"OnlyPollOnEvent"=dword:0001

[HKEY_CURRENT_USER\Software\ORL\VNCHooks]
[HKEY_CURRENT_USER\Software\ORL\VNCHooks\Application_Prefs]
[HKEY_CURRENT_USER\Software\ORL\VNCHooks\Application_Prefs\EXPLORER.EXE]

Dvldr32.exe analysis:

Dvldr32.exe is packed by Aspack. This virus, which is written by MS VC6.0,
send out amount of packages with the aim to
infect the network. This File also  include 3 executable files. Two of them
are "Psexesvc" and "Remote process lancher".

They are command tools which published by Sysinternals Corporation. They
don't create to the file system, and been called
by the Dvldr32.exe only. Another program is a install package   which made
by a uncommon install tool. The package include
5 files,3 of them (Explorer.exe,VNCdll32.dll and Omnithread_rt.dll) are
networking managerial tools which belong to the
corporation AT&T.
Rundll32.dll is not the normal one in the Microsoft operating system. It
maybe a Linux's program which transplanted to

Windows.

Spread principle:
When running , the program will select 2 IP sections in random and connect
the target host's port on 445 to get networking
package.  Once the target machine's administrator's password is null or in
the list following here , the program will copy itself
to its system.

Passwords tried by worm to enter system:

No password
"admin"
"Admin"
"password"
"Password"
"1"
"12"
"123"
"1234"
"12345"
"123456"
"1234567"
"12345678"
"123456789"
"654321"
"54321"
"111"
"00"
""
.""
""
"pass"
"passwd"
"database"
"abcd"
"abc123"
"oracle"
"sybase"
"123qwe"
"server"
"computer"
"Internet"
"super"
"123asd"
"ihavenopass"
"godblessyou"
"enable"
"xp"
"2002"
"2003"
"2600"
"0"
"110"
"11"
"121212"
"123123"
"1234qwer"
"123abc"
"007"
"alpha"
"patrick"
"pat"
"administrator"
"root"
"sex"
"god"
"foobar"
"a"
"aaa"
"abc"
"test"
"test123"
"temp"
"temp123"
"win"
"pc"
"asdf"
"secret"
"qwer"
"yxcv"
"zxcv"
"home"
"xxx"
"owner"
"login"
"Login"
"pwd"
"pass"
"love"
"mypc"
"mypc123"
"admi

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

[Ray Bellis]

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


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

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

Ray

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

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

Re: 923Mbits/s across the ocean

[Iljitsch van Beijnum]

On Sun, 9 Mar 2003, Richard A Steenbergen wrote:

> On the send size, the application transmitting is guaranteed to utilize
> the buffers immediately (ever seen a huge jump in speed at the beginning
> of a transfer, this is the local buffer being filled, and the application
> has no way to know if this data is going out to the wire, or just to the
> kernel). Then the network must drain the packets onto the wire, sometimes
> very slowly (think about a dialup user downloading from your GigE server).

Actually this is often way too fast as the congestion window doubles
with each ACK. This means that with a large buffer = large window and a
bottleneck somewhere along the way, you are almost guaranteed to have
some serious congestion in the early stages of the session and lower
levels of congestion periodially later on whenever TCP tries to figure
out how large the congestion window can get without losing packets.

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.

> 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. (TCP then
simply announces a window of 0 to the other side so the communication
effectively stops until the application reads some data and a >0 window
is announced.) If not, the kernel would be required to buffer unlimited
amounts of data in the event an application fails to read it from the
buffer for some time (which is a very common situation).

> locally. Jumbo frames help too, but their real benefit is not the
> simplistic "hey look theres 1/3rd the number of frames/sec" view that many
> people see. The good stuff comes from techniques like page flipping, where
> the NIC DMA's data into a memory page which can be flipped through the
> system straight to the application, without copying it throughout. Some
> day TCP may just be implemented on the NIC itself, with ALL work
> offloaded, and the system doing nothing but receiving nice page-sized
> chunks of data at high rates of speed.

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.

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

Iljitsch van Beijnum

RE: scope of the 69/8 problem

[Cutler, James R]

RE:  "If the roots and gTLDs are truly unwilling to help..."

The cost of installing entirely new root hints files on every
Internet-attached name server around the world is ridiculously large.  It
has nothing to do with willing.

Perhaps, if the problem were defined in proper terms, and a solution
involving moving, for example, .net or .org to the blackballed space were
made to the registry/DNS owners, a discussion of real possible events could
ensue.  

In the meantime, most of the discussion in this thread is wasted time and
going to the wrong targets.

-
James R. Cutler,  EDS
800 Tower Drive, Troy, MI 48098
1 248 265 7514
[EMAIL PROTECTED]


-Original Message-
From: E.B. Dreger [mailto:[EMAIL PROTECTED] 
Sent: 2003-03-10, Monday 6:23 PM
To: [EMAIL PROTECTED]
Subject: scope of the 69/8 problem



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


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

I'm eager to see stats indicating how large the problem is.  If the problem
is this severe, it seems all the more wrong to let innocent third parties
suffer due to what IP space was bestowed upon them.

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.


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

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

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

Re: 69/8...this sucks

[Charles Sprickman]

On Mon, 10 Mar 2003, Jared Mauch wrote:

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

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

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

C

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

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

[Jack Bates]

From: "Ray Bellis"

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

-Jack

RE: scope of the 69/8 problem

[E.B. Dreger]

CJR> Date: Mon, 10 Mar 2003 18:58:29 -0500
CJR> From: "Cutler, James R"


CJR> The cost of installing entirely new root hints files on
CJR> every Internet-attached name server around the world is
CJR> ridiculously large.  It has nothing to do with willing.

The cost of having 69/8 space is said to be ridiculously large,
and falls on the unfortunate recipients.  Both the root zone and
hints are PGP-signed; transfer could be automated.

I found the "check/update root hints" citation with a bit of
Google... the grasshopper book, 4th edition, page 157.  So it's
not an RFC, but rather a recommendation.


CJR> Perhaps, if the problem were defined in proper terms, and a

I thought it had been.


CJR> solution involving moving, for example, .net or .org to the
CJR> blackballed space were made to the registry/DNS owners, a
CJR> discussion of real possible events could ensue.

Yes.

This has been suggested.  Granted, little distinction has been
made between root/TLD.  The TLDs would be much easier to
implement than the roots.


CJR> In the meantime, most of the discussion in this thread is
CJR> wasted time and going to the wrong targets.

Perhaps.  ARIN, root operators, gTLD ops, IANA members, etc. are
known to read NANOG.  Of course, more direct lists exist...


Last post from me on this.


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

[Richard A Steenbergen]

On Tue, Mar 11, 2003 at 12:41:15AM +0100, Iljitsch van Beijnum 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. (TCP then
> simply announces a window of 0 to the other side so the communication
> effectively stops until the application reads some data and a >0 window
> is announced.) If not, the kernel would be required to buffer unlimited
> amounts of data in the event an application fails to read it from the
> buffer for some time (which is a very common situation).

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

> > locally. Jumbo frames help too, but their real benefit is not the
> > simplistic "hey look theres 1/3rd the number of frames/sec" view that many
> > people see. The good stuff comes from techniques like page flipping, where
> > the NIC DMA's data into a memory page which can be flipped through the
> > system straight to the application, without copying it throughout. Some
> > day TCP may just be implemented on the NIC itself, with ALL work
> > offloaded, and the system doing nothing but receiving nice page-sized
> > chunks of data at high rates of speed.
> 
> 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.

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

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

[Brandon Butterworth]

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

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

brandon

Re: 69/8...this sucks

[Joel Jaeggli]

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

joelja

On Tue, 11 Mar 2003, Brandon Butterworth wrote:

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

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

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

[Sean Donelan]

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.

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: 69/8...this sucks

[Owen DeLong]

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

RE: 69/8...this sucks

[Frank Scalzo]

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

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

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

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

Frank

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



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

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

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

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

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

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

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


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

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

Owen

Issue with 208.192.0.0/8 - 208.196.93.0/24?

[chuck goolsbee]

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: 69/8...this sucks

[jlewis]

On Mon, 10 Mar 2003, Frank Scalzo wrote:

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

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

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

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

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

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

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

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

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

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

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

[Christopher L. Morrow]

On Mon, 10 Mar 2003, chuck goolsbee wrote:

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

traceroutes often die when there are firewalls and/or router acls

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

the /8 is kinda large for me to test 'right now' but this one /32 looks
ok:

xxx.corp.us.uu.net:t 208.196.93.204 80
Trying 208.196.93.204...
Connected to 208.196.93.204 (208.196.93.204).
Escape character is '^]'.

That seems to be a good port 80 connection. route-server.ip.att.net shows
this prefix as:

BGP routing table entry for 208.196.93.0/24, version 107200
Paths: (19 available, best #19, table Default-IP-Routing-Table)
  Advertised to non peer-group peers:
  12.161.130.230
  7018 701 14462, (received & used)

Have you bothered to call ASN 14462 ?

arin 14462

OrgName:EVS Holding Company, Inc.
OrgID:  EHC-8
Address:1415 RT 70, Suite 620
City:   Cherry Hill
StateProv:  NJ
PostalCode: 08034
Country:US

ASNumber:   14462
ASName: CYSHOP-COMMERCE
ASHandle:   AS14462
Comment:
RegDate:1999-12-16
Updated:1999-12-16

TechHandle: MB745-ARIN
TechName:   Byrnes, Michael
TechPhone:  +1-856-429-9249
TechEmail:  [EMAIL PROTECTED]

Perhaps Michael Byrnes is lurking and can help you?

>
> --
> --chuck goolsbee
> geek wrangler, digital.forest inc, bothell, wa 
>

Re: 69/8...this sucks

[Jack Bates]

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

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

-Jack

RE: 69/8...this sucks

[Haesu]

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

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

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

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

Yup..

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

No kidding..

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

-hc


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

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

[Chris Adams]

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

The same can be said of many large organizations.

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

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

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

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

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

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

[chuck goolsbee]

OK... so I'm an idiot... end of a long day, apologies. The /8 was a 
jump to a bonehead conclusion on my part. The /24 & IP in question 
remains unreachable on any port from here, but I did get enough 
offlist clueXfours to follow up offlist  and soothe our client for 
the time being.

Thanks folks,

--
--chuck goolsbee
geek wrangler, digital.forest inc, bothell, wa 

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

[McBurnett, Jim]

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

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

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

Later,
J

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

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

[Vivien M.]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
> Behalf Of Sean Donelan
> Sent: March 10, 2003 7:51 PM
> To: [EMAIL PROTECTED]
> Subject: 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.
> 
> 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.

You're comparing two different situations, though:
In your case, the people in the hotel that is doing the blocking will be the
ones experiencing the problems. They notice that they can't reach
1-8xx-xxx-, so they call up the hotel management and yell. Hotel
management calls the person in charge of their PBX, and the problem would be
fixed. I could be wrong (hey, I'm in the DNS business, not the PSTN), but I
can't imagine the 1-8xx number calling the hotel and getting the impression
that the 1-8xx number's provider has problems...
In the 69.0.0.0/8 case, though, the problem is bidirectional. You have
people whose ISP/firewall/etc blocks access to 69.0.0.0/8 - presumably, if
they can't reach some box on 69.0.0.0, they'll yell at their ISP (and, most
likely, at the operator of the thing they're trying to reach, too, but said
operator can tell them to yell at their ISP). But, you also have people on
69.0.0.0 who aren't able to reach other sites due to filtering on the other
end, and those people are likely to yell at their ISP and blame their ISP
for something the ISP can't fix.
That second situation, I think, is the situation that this thread is about,
and your hotel analogy doesn't address that.

With the hotel analogy, basically, the people affected are the ones who have
the relationship with the operator of the broken piece of hardware, not the
ones with the 1-8xx number (though, if you want to be picky, you could argue
they might lose a bit of business to this).
With the 69.x.x.x situation, the people affected are the ones with the 69 IP
space, and they don't have a relationship with whoever has the misconfigured
hardware. 

Maybe moving the GTLD servers would be overkill... But certainly, the idea
of asking Google or Yahoo to move seems like a good one. If people can't
reach Google or Yahoo, they'll make their ISP look into the issue, and fix
their filters. 

A random comment now I have been dragged into this thread: this issue is not
new with 69.0.0.0/8. When we first got a block from 66.* from an ISP about
two years ago, we had problems too with various people (mostly end users,
though, I think) firewalling 66.*, and yet ARIN had been assigning 66.*
blocks for probably a year or so before we got that IP space. Fortunately
for us, though, most problems seemed to be people who wanted to reach us not
being able to, and not us not being able to reach sites we wanted to talk
to. Still, I suspect the Linux Firewall HOWTO was in large part responsible
for the problems we had... 

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

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

[Dr. Jeffrey Race]

On Mon, 10 Mar 2003 19:14:07 -0800, chuck goolsbee wrote:
>Forgive the intrusion...
Forgiven
>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


[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
 1  192.168.1.1 (192.168.1.1)  0 ms  0 ms  8 ms
 2  10.20.12.9 (10.20.12.9)  55 ms  55 ms  55 ms
 3  ppp-203.144.161.5.revip.asianet.co.th (203.144.161.5)  39 ms  5
 4  ppp-203.144.144.157.revip.asianet.co.th (203.144.144.157)  54 m
ms
 5  ppp-203.144.144.2.revip.asianet.co.th (203.144.144.2)  242 ms
s
 6  211.180.13.225 (211.180.13.225)  133 ms  133 ms  125 ms
 7  210.120.192.136 (210.120.192.136)  133 ms  133 ms  132 ms
 8  203.255.234.198 (203.255.234.198)  258 ms 203.255.234.210 (203.
 266 ms 203.255.234.198 (203.255.234.198)  266 ms
 9  203.255.234.36 (203.255.234.36)  250 ms  258 ms  258 ms
10  67.104.60.49 (67.104.60.49)  258 ms  258 ms  281 ms
11  p4-3-0.MAR2.Fremont-CA.us.xo.net (207.88.80.13)  258 ms  258
12  p4-0-0.RAR2.SanJose-CA.us.xo.net (65.106.5.137)  273 ms  266
13  p0-0-0-1.RAR1.SanJose-CA.us.xo.net (65.106.1.65)  266 ms  281
14  p0-0.IR1.PaloAlto-CA.us.xo.net (65.106.5.194)  273 ms  336 ms
15  206.111.12.150 (206.111.12.150)  265 ms  266 ms  258 ms
16  157.at-5-1-0.XR1.SAC1.ALTER.NET (152.63.51.58)  1031 ms  273
17  0.so-0-1-0.XL1.SAC1.ALTER.NET (152.63.53.241)  266 ms *  281
18  0.so-3-0-0.TL1.SAC1.ALTER.NET (152.63.53.250)  273 ms  274 ms
19  0.so-1-2-0.TL1.NYC9.ALTER.NET (152.63.10.77)  352 ms  335 ms
20  0.so-3-0-0.XL1.NYC1.ALTER.NET (152.63.27.29)  321 ms  321 ms
21  0.so-0-0-0.XR1.NYC1.ALTER.NET (152.63.19.85)  336 ms  336 ms
22  207.ATM6-0.GW11.NYC1.ALTER.NET (152.63.29.185)  360 ms  352 m
23  * * *
24  *
[dies]

[C:\]host 208.196.93.204
208.196.93.204 = ecobeauty.org


Jeffrey Race

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

[Dr. Jeffrey Race]

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

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

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

Jeffrey Race

RE: Abstract of proposed Internet Draft for Best Current Practice (please comment)

[Cutler, James R]

"Well-managed...profitably." leaves out a lot of companies.

Also

>>is there a forthcoming section on criterium for demonstrating 
>>reformation by the sp and/or 'offending' user?
>
>The criterion is stated: no more complaints

Implies that a simple "j'accuse" is enough to create a denial of service.  I
prefer the US to Napoleonic codes, where an accusation is insufficient to
prove guilt.

-
James R. Cutler,   EDS
800 Tower Drive, Troy, MI 48098
248-265-7514
[EMAIL PROTECTED]

-Original Message-
From: Peter Galbavy [mailto:[EMAIL PROTECTED] 
Sent: Friday, March 07, 2003 9:06 AM
To: Dr. Jeffrey Race
Cc: [EMAIL PROTECTED]
Subject: Re: Abstract of proposed Internet Draft for Best Current Practice
(please comment)




quote:
> Well-managed, ethical members of the internet industry already conduct 
> their businesses, successfully and profitably, according to the 
> principles specified in the Practice. The proposed Practice simply 
> aims to raise the entire industry to the level of today's best 
> players.

I object to this wording; even without reading *any* other part of your
document, I am already very cautious about it's contents simply because of
the implication of your statement above. This is very much one of those
political "you're either with us or against us" declarations.

So - if you don't so it 'our way' then you must be unethical and
badly-managed. At least.

Peter

RE: Abstract of proposed Internet Draft for Best Current Practic e (please comment)

[Dr. Jeffrey Race]

On Mon, 10 Mar 2003 09:11:31 -0500, Cutler, James R wrote:

>Implies that a simple "j'accuse" is enough to create a denial of service.  
I
>prefer the US to Napoleonic codes, where an accusation is insufficient to
>prove guilt.

Please read the details in the text.  It is all spelt out there.

Jeffrey Race