123.0.0.0/8 from AS7643 (was - Re: Where are static bogon filters appropriate? was: 96.2.0.0/16 Bogons)

[william(at)elan.net]

Speaking of bogons and more practical daily operation issues, perhaps
you guys can help reaching the fine folks at AS7643 or maybe their
upstream provider can be kind enough to filter out the following:

BGP routing table entry for 123.0.0.0/8, version 14613827
Paths: (1 available, best #1, not advertised outside local AS)
  Not advertised to any peer
  3561 3491 7643 7643 7643 7643

Thanks.

---
William Leibzon
Elan Networks
[EMAIL PROTECTED]

Re: Comcast contact for the East Coast

[Steven M. Bellovin]

On Fri, 02 Mar 2007 21:08:58 -0500
Jim Popovitch <[EMAIL PROTECTED]> wrote:

> On Fri, 2007-03-02 at 17:58 -0800, Ashe Canvar wrote:
> > Could someone from Comcast please contact us
> > ([EMAIL PROTECTED]).
> > 
> > Customers behind Comcast on the east coast cannot get to our
> > 216.219.126.0 prefix in Santa Barbara, CA. Comcast's peering with
> > Cox on ashbbbrj02-ae0.0.r2.as.cox.net may be to blame.
> 
> I'm presently hanging off of Comcast in Atlanta (76.17.105.x) and I
> can ping traceroute and ping 216.219.126.1
> 
As can I from Comcast in NJ.


--Steve Bellovin, http://www.cs.columbia.edu/~smb

RE: Comcast contact for the East Coast

[Andrew.Parris]

> Could someone from Comcast please contact us  
> ([EMAIL PROTECTED]).
>
> Customers behind Comcast on the east coast cannot get to our
> 216.219.126.0 prefix in Santa Barbara, CA. Comcast's peering with Cox
> on ashbbbrj02-ae0.0.r2.as.cox.net may be to blame.

COX has created ticket HD015981407 for this issue.

A show route shows us that traffic destined for target IP 216.219.126.0
is going from ASHBBBRJ02 to ASHBBBRJ01, and then directly to the Equinix
Public Peering Switch in Ashburn, and then stopping.

I will be contacting Equinix shortly to continue troubleshooting.




-J. Andrew Parris
NOC Engineer
Data Network Operations Center
Cox Communications (AS 22773)
1-888-326-9266, Opt. 1

AIM:  coxnocandpa

Re: Comcast contact for the East Coast

[Jim Popovitch]

On Fri, 2007-03-02 at 17:58 -0800, Ashe Canvar wrote:
> Could someone from Comcast please contact us ([EMAIL PROTECTED]).
> 
> Customers behind Comcast on the east coast cannot get to our
> 216.219.126.0 prefix in Santa Barbara, CA. Comcast's peering with Cox
> on ashbbbrj02-ae0.0.r2.as.cox.net may be to blame.

I'm presently hanging off of Comcast in Atlanta (76.17.105.x) and I can
ping traceroute and ping 216.219.126.1

-Jim P.


signature.asc
Description: This is a digitally signed message part

Comcast contact for the East Coast

[Ashe Canvar]

Could someone from Comcast please contact us ([EMAIL PROTECTED]).

Customers behind Comcast on the east coast cannot get to our
216.219.126.0 prefix in Santa Barbara, CA. Comcast's peering with Cox
on ashbbbrj02-ae0.0.r2.as.cox.net may be to blame.

Regards,
Ashe Canvar
Network Engineer
--
Citrix Online (AS16815)
5385 Hollister Avenue
Santa Barbara, CA 93111 USA
--

Re: Where are static bogon filters appropriate? was: 96.2.0.0/16 Bogons

[Roland Dobbins]

On Mar 2, 2007, at 1:18 PM, Sean Donelan wrote:

How much of a problem is traffic from unallocated addresses?   
Backbone operators probably have NetFlow data which they could mine  
to find out.
On the other hand, how much of a problem is obsolete bogon filters  
causing

everytime IANA delegates another block to an RIR?

Or by the way, how much spoofed traffic uses allocated addresses?


No one has done the digging required to answer any of these  
questions, unfortunately.


---
Roland Dobbins <[EMAIL PROTECTED]> // 408.527.6376 voice

  The telephone demands complete participation.

  -- Marshall McLuhan

Re: Where are static bogon filters appropriate? was: 96.2.0.0/16 Bogons

[Daniel Senie]

At 04:18 PM 3/2/2007, Sean Donelan wrote:



On Fri, 2 Mar 2007, Roland Dobbins wrote:

Sometimes, network operators have to take the bull
by the horns and develop their own systems to do a job that vendors
simply don't understand.


Concur - but it seems that many seem to be looking for someone else 
to do this for them (or, perhaps, the lack of someone to do it for 
them as an excuse to do nothing at all).


How much of a problem is traffic from unallocated 
addresses?  Backbone operators probably have NetFlow data which they 
could mine to find out.

On the other hand, how much of a problem is obsolete bogon filters causing
everytime IANA delegates another block to an RIR?

Or by the way, how much spoofed traffic uses allocated addresses?


How do you know, if you're the one being attacked and you have no 
idea if the originating network or their immediate upstream 
implemented BCP38? Shall we just discard ingress filtering? If few 
attacks are using it today, should we declare it no longer relevant? 
At the same time we should ask if we should be x-raying shoes at the 
airport, since there's only been one guy who tried to blow up his 
shoes. The larger security question is, "do you stop looking for old 
threats simply because they're not the most common threats?" How many 
CodeRed packets flow over the Internet on a typical day? I assure you 
it's not zero.


The initial drafts of the document that became BCP38 were written 10 
1/2 years ago, triggered by a serious problem of spoof-based attacks 
that were causing serious problems including serious interruption of 
services. The problem had a solution, but one that required 
cooperation among networks. The operation of the entire Internet 
required cooperation among networks. I don't know to what degree any 
sense of cooperation is left these days. Probably won't matter when 
Google or ATT take over the whole thing. In the mean time, the 
presence of an ACL line or two at the border of each edge network is 
NOT a significant burden. Yes, Cisco and others have implemented uRPF 
that can do the same thing with a bit less typing in some cases. I 
really don't care which mechanism is used. I do care when my network 
is hammered with packets. When I send reports to other networks and 
they can't be sure the packets came from their networks, that's not helpful.


So there, that's my rant about why we might all want to try and keep 
the 'net a cooperative place, and a bit about how ingress filtering 
continues to play a part in that cooperation.


This is pretty far from the topic of the bogon list issue with 96/8 though.

Level(3) IP justifications contact?

[david raistrick]

Folks,

Anyone have a contact inside Level(3)'s IP Justification team?  Telcove or 
Wiltel teams might apply here as well.


I'm getting some serious kickback but not getting any details nor contact 
with anyone who will discuss anything.



Anyone from ARIN who wants to discuss or review this with me would be 
welcome as well..;)


thanks.

...david



---
david raistrickhttp://www.netmeister.org/news/learn2quote.html
[EMAIL PROTECTED] http://www.expita.com/nomime.html

RE: Where are static bogon filters appropriate? was: 96.2.0.0/16 Bogons

[Scott Weeks]

--- [EMAIL PROTECTED] wrote:--
>  I think this really goes to the heart of the matter - the inability/ 
> unwillingness to prioritize and allocate resources to properly  
> implement 'good neighbor' policies which are not perceived as having  
> any financial benefit to the organization.
> 
> So, can this sort of activity somehow be monetized by the SPs,  
> remedied by the vendors, or is it a matter for the standards bodies  
> (or some combination thereof)?

Standards bodies do technology, not policy. This is more of an issue for
regulators or industry associations. To start with, it makes sense to me
that public Internet providers would form some sort of trade association
to develop and publish industry best practices. And to evaluate member
compliance with those practices. This still doesn't fix the problem, but
it provides an opening for legislators to step in and regulate the ISPs
who are not members of the trade association.

No matter how much some on this list may dislike regulation for the
industry, it is inevitable because it is the only way to solve policy
issues like bogon filtering. Either self-regulation through a trade
association or government regulation through an FCC-like body.

As far as monetizing the activity, it will probably take a lawsuit
against one of the incompetent ISPs before network operations management
recognizes why this stuff needs to be MANAGED and not left to the whims
of engineers.





The internet is a global network with participants in every country.  
Throughout human history wars have been fought over one country trying to 
regulate another's resources.  I seriously doubt regulation will work in the 
internet arena for all the same reasons.  Unless, that is, each country 
segments their own piece and regulates that piece.  I doubt anyone wants to see 
the fracturing of the internet into country-sized pieces.

scott

Re: Where are static bogon filters appropriate? was: 96.2.0.0/16 Bogons

[Steven M. Bellovin]

On Fri, 2 Mar 2007 15:37:01 -0600
"Eric Ortega" <[EMAIL PROTECTED]> wrote:

> 
> I think Sean raises a good point. I guess the larger picture is what
> are we trying to protect and what are trying to protect that from. 
> 
Bingo.

The problem isn't with "security people", it's with "security people
who use checklists -- and old ones at that -- in preference to
thinking".

Droids exist in every field


--Steve Bellovin, http://www.cs.columbia.edu/~smb

RE: Where are static bogon filters appropriate? was: 96.2.0.0/16 Bogons

[Eric Ortega]

I think Sean raises a good point. I guess the larger picture is what are we
trying to protect and what are trying to protect that from. 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sean
Donelan
Sent: Friday, March 02, 2007 3:19 PM
To: Roland Dobbins
Cc: NANOG
Subject: Re: Where are static bogon filters appropriate? was: 96.2.0.0/16
Bogons



On Fri, 2 Mar 2007, Roland Dobbins wrote:
>> Sometimes, network operators have to take the bull
>> by the horns and develop their own systems to do a job that vendors 
>> simply don't understand.
>
> Concur - but it seems that many seem to be looking for someone else to 
> do
> this for them (or, perhaps, the lack of someone to do it for them as an 
> excuse to do nothing at all).

How much of a problem is traffic from unallocated addresses?  Backbone 
operators probably have NetFlow data which they could mine to find out. On
the other hand, how much of a problem is obsolete bogon filters causing
everytime IANA delegates another block to an RIR?

Or by the way, how much spoofed traffic uses allocated addresses?

Re: Where are static bogon filters appropriate? was: 96.2.0.0/16 Bogons

[Sean Donelan]

On Fri, 2 Mar 2007, Roland Dobbins wrote:

Sometimes, network operators have to take the bull
by the horns and develop their own systems to do a job that vendors
simply don't understand.


Concur - but it seems that many seem to be looking for someone else to do 
this for them (or, perhaps, the lack of someone to do it for them as an 
excuse to do nothing at all).


How much of a problem is traffic from unallocated addresses?  Backbone 
operators probably have NetFlow data which they could mine to find out.

On the other hand, how much of a problem is obsolete bogon filters causing
everytime IANA delegates another block to an RIR?

Or by the way, how much spoofed traffic uses allocated addresses?

Re: Where are static bogon filters appropriate? was: 96.2.0.0/16 Bogons

[Roland Dobbins]

On Mar 2, 2007, at 7:31 AM, <[EMAIL PROTECTED]> wrote:


Sometimes, network operators have to take the bull
by the horns and develop their own systems to do a job that vendors
simply don't understand.


Concur - but it seems that many seem to be looking for someone else  
to do this for them (or, perhaps, the lack of someone to do it for  
them as an excuse to do nothing at all).


---
Roland Dobbins <[EMAIL PROTECTED]> // 408.527.6376 voice

  The telephone demands complete participation.

  -- Marshall McLuhan

Weekly Routing Table Report

[Routing Analysis Role Account]

This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.
Daily listings are sent to [EMAIL PROTECTED]

For historical data, please see http://thyme.apnic.net.

If you have any comments please contact Philip Smith <[EMAIL PROTECTED]>.

Routing Table Report   04:00 +10GMT Sat 03 Mar, 2007

Analysis Summary


BGP routing table entries examined:  213872
Prefixes after maximum aggregation:  114752
Deaggregation factor:  1.86
Unique aggregates announced to Internet: 103985
Total ASes present in the Internet Routing Table: 24509
Origin-only ASes present in the Internet Routing Table:   21327
Origin ASes announcing only one prefix:   10308
Transit ASes present in the Internet Routing Table:3182
Transit-only ASes present in the Internet Routing Table: 79
Average AS path length visible in the Internet Routing Table:   3.6
Max AS path length visible:  32
Max AS path prepend of ASN (20858)   18
Prefixes from unregistered ASNs in the Routing Table: 4
Unregistered ASNs in the Routing Table:   6
Special use prefixes present in the Routing Table:0
Prefixes being announced from unallocated address space: 12
Number of addresses announced to Internet:   1689261068
Equivalent to 100 /8s, 176 /16s and 20 /24s
Percentage of available address space announced:   45.6
Percentage of allocated address space announced:   62.6
Percentage of available address space allocated:   72.8
Total number of prefixes smaller than registry allocations:  110720

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:48655
Total APNIC prefixes after maximum aggregation:   19591
APNIC Deaggregation factor:2.48
Prefixes being announced from the APNIC address blocks:   45739
Unique aggregates announced from the APNIC address blocks:20424
APNIC Region origin ASes present in the Internet Routing Table:2885
APNIC Region origin ASes announcing only one prefix:786
APNIC Region transit ASes present in the Internet Routing Table:427
Average APNIC Region AS path length visible:3.6
Max APNIC Region AS path length visible: 16
Number of APNIC addresses announced to Internet:  291151232
Equivalent to 17 /8s, 90 /16s and 157 /24s
Percentage of available APNIC address space announced: 72.1

APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911
APNIC Address Blocks   58/7, 60/7, 116/6, 120/6, 124/7, 126/8, 202/7
   210/7, 218/7, 220/7 and 222/8

ARIN Region Analysis Summary


Prefixes being announced by ARIN Region ASes:104281
Total ARIN prefixes after maximum aggregation:61265
ARIN Deaggregation factor: 1.70
Prefixes being announced from the ARIN address blocks:76236
Unique aggregates announced from the ARIN address blocks: 29615
ARIN Region origin ASes present in the Internet Routing Table:11368
ARIN Region origin ASes announcing only one prefix:4354
ARIN Region transit ASes present in the Internet Routing Table:1054
Average ARIN Region AS path length visible: 3.4
Max ARIN Region AS path length visible:  21
Number of ARIN addresses announced to Internet:   319487360
Equivalent to 19 /8s, 10 /16s and 253 /24s
Percentage of available ARIN address space announced:  70.5

ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106
(pre-ERX allocations)  2138-2584, 2615-2772, 2823-2829, 2880-3153
   3354-4607, 4865-5119, 5632-6655, 6912-7466
   7723-8191, 10240-12287, 13312-15359, 16384-17407
   18432-20479, 21504-23551, 25600-26591,
   26624-27647, 29696-30719, 31744-33791
   35840-36863, 39936-40959
ARIN Address Blocks24/8, 63/8, 64/5, 72/6, 76/8, 96/6, 199/8, 204/6,
   208/7 and 216/8

RIPE Region Analysis Summary


Prefixes being announced by RIPE Region ASes: 44188
Total RIPE prefixes after maximum aggregation:28812
RIPE Deaggregation factor: 1.53
Prefixes being announced from the R

Re: 96.2.x.x Issues to websites

[Mike Tancsa]

At 11:43 AM 3/2/2007, John Lubeck wrote:


Sorry for the long list but we are still having issues to following sites.
Looking for someone at American Express and Yahoo (*most complaints with
those two sites). Also it appears a we are getting stopped on AT&T networks.


AT&T has some nice route servers to use / test from

12.0.1.28

Trying 12.0.1.28...
Connected to route-server.cbbtier3.att.net.
Escape character is '^]'.

## route-server.ip.att.net ###
#  AT&T IP Services Route Monitor  ###

The information available through route-server.ip.att.net is offered
by AT&T's Internet engineering organization to the Internet community.
This router has the global routing table view from each of the above
routers, providing a glimpse to the Internet routing table from the
AT&T network's perspective.

This router maintains eBGP peerings with customer-facing routers
throughout the AT&T IP Services Backbone:

 12.123.21.243   Atlanta, GA 12.123.133.124  Austin, TX
 12.123.41.250   Cambridge, MA   12.123.5.240Chicago,IL
 12.123.17.244   Dallas, TX  12.123.139.124  Detroit, MI
 12.123.37.250   Denver, CO  12.123.134.124  Houston, TX
 12.123.29.249   Los Angeles, CA 12.123.1.236New York, NY
 12.123.33.249   Orlando,FL  12.123.137.124  Philadelphia, PA
 12.123.142.124  Phoenix, AZ 12.123.145.124  San Diego, CA
 12.123.13.241   San Francisco, CA   12.123.25.245   St. Louis, MO
 12.123.45.252   Seattle, WA 12.123.9.241Washington, DC

96.2.x.x Issues to websites

[John Lubeck]

Sorry for the long list but we are still having issues to following sites.
Looking for someone at American Express and Yahoo (*most complaints with
those two sites). Also it appears a we are getting stopped on AT&T networks.
Please contact me offline if you have any contacts that deal with the
following sites:

www.americanexpress.com
tw.yahoo.com
hk.yahoo.com
procurement.pbnlink.com
www.fedbizopps.gov
avn.faa.gov
naco.faa.gov
www.usana.com
www.usana2day.com
www.campuscruiser.com
www.mywitcc.com
www.jobrelatedstuff.com
www.mooseintl.org
www.mage-page.com
www.rent.com
www.missingmoney.com
www.sdsportstalk.com
www.wretch.cc
remote.shopko.com
www.premierpyro.com
www.precisionracecomponents.com
www.eftps.com
www.ameriprise.com
www.keepitnice.com

VCAST Online music store 

Thanks in advance for any help you provide.
John Lubeck
Midcontinent Communications 
Network Engineer
605-274-3092
[EMAIL PROTECTED]

RE: Where are static bogon filters appropriate? was: 96.2.0.0/16 Bogons

[michael.dillon]

>  No, the SP can't be the 'Internet  
> firewall' for customers, 

They can if the SP supplies and manages the CPE device. Nowadays, a lot
of functionality could potentially be provided in a CPE device. Hardware
cost and hardware capabilities are no longer barriers to doing this.
There is still software cost, of course, but that can get amortized over
many years and many, many subscribers.

> but protecting one's  
> customers from being spammed/packeted from purported source 
> addresses  
> which are by definition nonsensical (as well as protecting everyone  
> else's customers from same) doesn't seem much to ask.
> 
> What's needed here are better/easier/less brittle mechanisms for  
> same.  Until such time as they're invented and deployed, let's not  
> make the perfect the enemy of the merely good, yes?

Less brittle mechanisms don't need to be invented. There is nothing hard
about putting an operational process in place to manage bogon filtering.
There is also nothing hard about writing some software to update bogon
filters. People do this kind of thing every day in network operations
without much fanfare precisely because it is nothing special. It's just
good operational practice in a company that does not expect its vendors
to spoonfeed them everything.

There's kind of a disease in the telecomms business. Many years ago
someone got the idea that developing telecomms devices and systems was
one business, and operating those devices and systems was another. Over
time this crystalized into the idea that an operator bought platforms
from vendors and then operated those platforms according to the vendor's
instructions. This may be good for the capital investment industry
(banks etc.) but it fails when there is a need for creativity in the
telecomms operator. Sometimes, network operators have to take the bull
by the horns and develop their own systems to do a job that vendors
simply don't understand.

--Michael Dillon

Re: Where are static bogon filters appropriate? was: 96.2.0.0/16 Bogons

[Valdis . Kletnieks]

On Fri, 02 Mar 2007 08:55:42 GMT, [EMAIL PROTECTED] said:
> > one, I'm an example of another, and the advocates of static bogon filters 
> > are
important word alert --> ^^

> policy and management of that policy. Bogon filters are
> an example of a policy implementation.

Note that I didn't say bogon filters were a bad idea.  I said that the
concept of installing a bogon filter and not adjusting it to fit the
changing realities over the years was usually(*) a bad idea.

(*) usually - if your business model allows you to reliably enumerate
the list of sites that you want to talk to, feel free to declare everything
outside the 3 /16s you actually need to talk to a "bogon".  Note that in
the preceding sentence, "reliably" is another important word... :)


pgpES3JuKCMql.pgp
Description: PGP signature

Re: Where are static bogon filters appropriate? was: 96.2.0.0/16 Bogons

[Roland Dobbins]

On Mar 2, 2007, at 4:12 AM, Robert E. Seastrom wrote:

uRPF isn't always adequate for all antispoofing cases, as you know.   
What about iACLs?




bogon
filtering by end sites is the sort of thing that is recommended by
"experts" for whom "security" is an end in and of itself, rather than
a component of the arsenal you bring forth (backups, DR, spares,
multihoming, etc) to improve uptime and business availability and
decrease potential risk.


I don't claim to be an 'expert' at anything, but I most certainly - 
do- recommend bogon filtering, along with multihoming, infrastructure  
self-protection measures (iACLs, rACLs, CoPP, core-hiding, et. al.),  
various antispoofing techniques (all the way down to layer-2 where  
possible), instrumentation and telemetry, anomaly-detection, reaction  
tools, layer-7 things like backup and DR, layer-8 things like  
sparing, and so forth.  And my goal isn't 'security', it's a  
resilient Internet infrastructure which keeps the packets flowing so  
that the users can access the applications which are the point of the  
whole exercise.


I'm not the only one who thinks like that, either.  So, painting us  
all with the same broad brush hardly seems fair, does it?


Rejecting bogon filtering out of hand because it isn't effortless to  
maintain doesn't make much sense to me.  After all, if one's being a  
good Internet neighbor, one's doing ingress filtering (routes and  
packets) from one's customers and egress filtering (routes and  
packets) to one's peers/transits/customers, anyways; one will see  
more churn there than in the bogon lists.


It's also part of the very basic protections which ought to be  
provided to one's customers.  No, the SP can't be the 'Internet  
firewall' for customers, and, no, the SP can't be expected to keep  
the customer magically protected from all the Bad Things which can  
happen to him (and for free, naturally), but protecting one's  
customers from being spammed/packeted from purported source addresses  
which are by definition nonsensical (as well as protecting everyone  
else's customers from same) doesn't seem much to ask.


What's needed here are better/easier/less brittle mechanisms for  
same.  Until such time as they're invented and deployed, let's not  
make the perfect the enemy of the merely good, yes?


---
Roland Dobbins <[EMAIL PROTECTED]> // 408.527.6376 voice

  The telephone demands complete participation.

  -- Marshall McLuhan

Re: Where are static bogon filters appropriate? was: 96.2.0.0/16 Bogons

[Robert E. Seastrom]

Roland Dobbins <[EMAIL PROTECTED]> writes:

> On Mar 1, 2007, at 1:10 PM, Chris L. Morrow wrote:
>
>> So... again, are bogon filters 'in the core' useful? (call 'core' some
>> network not yours)
>
> Antispoofing is 'static' and therefore brittle in nature, people
> change jobs, etc. - so, we shouldn't do antispoofing, either?

Unicast RPF is neither static nor brittle, and we should do it.

I agree with smb though in somewhat less diplomatic terms - bogon
filtering by end sites is the sort of thing that is recommended by
"experts" for whom "security" is an end in and of itself, rather than
a component of the arsenal you bring forth (backups, DR, spares,
multihoming, etc) to improve uptime and business availability and
decrease potential risk.

For people who recommend cures that are as bad as the disease, we
recommend one of these: http://despair.com/consulting.html

---Rob

RE: Where are static bogon filters appropriate? was: 96.2.0.0/16 Bogons

[michael.dillon]

>  I think this really goes to the heart of the matter - the inability/ 
> unwillingness to prioritize and allocate resources to properly  
> implement 'good neighbor' policies which are not perceived as having  
> any financial benefit to the organization.
> 
> So, can this sort of activity somehow be monetized by the SPs,  
> remedied by the vendors, or is it a matter for the standards bodies  
> (or some combination thereof)?

Standards bodies do technology, not policy. This is more of an issue for
regulators or industry associations. To start with, it makes sense to me
that public Internet providers would form some sort of trade association
to develop and publish industry best practices. And to evaluate member
compliance with those practices. This still doesn't fix the problem, but
it provides an opening for legislators to step in and regulate the ISPs
who are not members of the trade association.

No matter how much some on this list may dislike regulation for the
industry, it is inevitable because it is the only way to solve policy
issues like bogon filtering. Either self-regulation through a trade
association or government regulation through an FCC-like body.

As far as monetizing the activity, it will probably take a lawsuit
against one of the incompetent ISPs before network operations management
recognizes why this stuff needs to be MANAGED and not left to the whims
of engineers.

--Michael Dillon

The Cidr Report

[cidr-report]

This report has been generated at Fri Mar  2 21:47:29 2007 AEST.
The report analyses the BGP Routing Table of an AS4637 (Reach) router
and generates a report on aggregation potential within the table.

Check http://www.cidr-report.org/as4637 for a current version of this report.

Recent Table History
Date  PrefixesCIDR Agg
23-02-07209950  135967
24-02-0720  135960
25-02-07210050  135897
26-02-07209843  136231
27-02-07210353  136500
28-02-07210457  136950
01-03-07211223  136851
02-03-07210831  136505


AS Summary
 24416  Number of ASes in routing system
 10302  Number of ASes announcing only one prefix
  1483  Largest number of prefixes announced by an AS
AS7018 : ATT-INTERNET4 - AT&T WorldNet Services
  90547200  Largest address span announced by an AS (/32s)
AS721  : DISA-ASNBLK - DoD Network Information Center


Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as 
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').

 --- 02Mar07 ---
ASnumNetsNow NetsAggr  NetGain   % Gain   Description

Table 210843   1366027424135.2%   All ASes

AS4323  1325  357  96873.1%   TWTC - Time Warner Telecom,
   Inc.
AS4134  1243  309  93475.1%   CHINANET-BACKBONE
   No.31,Jin-rong Street
AS4755  1073  177  89683.5%   VSNL-AS Videsh Sanchar Nigam
   Ltd. Autonomous System
AS9498   959  115  84488.0%   BBIL-AP BHARTI BT INTERNET
   LTD.
AS6478  1123  387  73665.5%   ATT-INTERNET3 - AT&T WorldNet
   Services
AS22773  728   48  68093.4%   CCINET-2 - Cox Communications
   Inc.
AS11492  985  355  63064.0%   CABLEONE - CABLE ONE
AS18566  993  397  59660.0%   COVAD - Covad Communications
   Co.
AS8151  1047  456  59156.4%   Uninet S.A. de C.V.
AS19262  713  180  53374.8%   VZGNI-TRANSIT - Verizon
   Internet Services Inc.
AS6197  1020  509  51150.1%   BATI-ATL - BellSouth Network
   Solutions, Inc
AS7018  1483  974  50934.3%   ATT-INTERNET4 - AT&T WorldNet
   Services
AS18101  530   27  50394.9%   RIL-IDC Reliance Infocom Ltd
   Internet Data Centre,
AS17488  607  125  48279.4%   HATHWAY-NET-AP Hathway IP Over
   Cable Internet
AS19916  568   97  47182.9%   ASTRUM-0001 - OLM LLC
AS17676  503   65  43887.1%   JPNIC-JP-ASN-BLOCK Japan
   Network Information Center
AS15270  506   74  43285.4%   AS-PAETEC-NET - PaeTec.net -a
   division of
   PaeTecCommunications, Inc.
AS4766   731  314  41757.0%   KIXS-AS-KR Korea Telecom
AS2386  1114  743  37133.3%   INS-AS - AT&T Data
   Communications Services
AS4812   435   72  36383.4%   CHINANET-SH-AP China Telecom
   (Group)
AS721632  277  35556.2%   DISA-ASNBLK - DoD Network
   Information Center
AS3602   518  184  33464.5%   AS3602-RTI - Rogers Telecom
   Inc.
AS5668   567  235  33258.6%   AS-5668 - CenturyTel Internet
   Holdings, Inc.
AS16852  397   72  32581.9%   BROADWING-FOCAL - Broadwing
   Communications Services, Inc.
AS7011   795  474  32140.4%   FRONTIER-AND-CITIZENS -
   Frontier Communications, Inc.
AS33588  432  127  30570.6%   BRESNAN-AS - Bresnan
   Communications, LLC.
AS6198   563  268  29552.4%   BATI-MIA - BellSouth Network
   Solutions, Inc
AS7029   514  225  28956.2%   WINDSTREAM - Windstream

BGP Update Report

[cidr-report]

BGP Update Report
Interval: 16-Feb-07 -to- 01-Mar-07 (14 days)
Observation Point: BGP Peering with AS4637

TOP 20 Unstable Origin AS
Rank ASNUpds %  Upds/PfxAS-Name
 1 - AS958320259  1.8%  23.0 -- SIFY-AS-IN Sify Limited
 2 - AS701515718  1.4%   4.0 -- CCCH-AS2 - Comcast Cable 
Communications Holdings, Inc
 3 - AS702 12655  1.1%  17.7 -- AS702 MCI EMEA - Commercial IP 
service provider in Europe
 4 - AS17974   10619  0.9%  30.3 -- TELKOMNET-AS2-AP PT 
TELEKOMUNIKASI INDONESIA
 5 - AS20426   10001  0.9%   10001.0 -- PWC-AS - 
PriceWaterhouseCoopers, LLP
 6 - AS247319822  0.9% 577.8 -- ASN-NESMA National Engineering 
Services and Marketing Company Ltd. (NESMA)
 7 - AS188099561  0.8% 187.5 -- Cable Onda
 8 - AS126547739  0.7% 203.7 -- RIPE-NCC-RIS-AS RIPE NCC RIS 
project
 9 - AS306  7421  0.7%  40.8 -- DNIC - DoD Network Information 
Center
10 - AS145227025  0.6%  52.4 -- Satnet
11 - AS251456562  0.6% 234.4 -- TEKNOTEL-AS tr.teknotel 
AS-Number
12 - AS4788 6510  0.6%  39.2 -- TMNET-AS-AP TM Net, Internet 
Service Provider
13 - AS5786 6383  0.6%  40.1 -- UPRENET - University of Puerto 
Rico
14 - AS4621 6093  0.5%  43.2 -- UNSPECIFIED UNINET-TH
15 - AS8151 6001  0.5%   8.4 -- Uninet S.A. de C.V.
16 - AS5803 5703  0.5%  63.4 -- DDN-ASNBLK - DoD Network 
Information Center
17 - AS111395657  0.5%  14.8 -- CWRIN CW BARBADOS
18 - AS4765 5638  0.5%  33.6 -- WORLDNET-AS World Net & 
Services Co., Ltd.
19 - AS721  5330  0.5%  11.1 -- DISA-ASNBLK - DoD Network 
Information Center
20 - AS4775 5198  0.5%  39.1 -- GLOBE-TELECOM-AS Telecom 
Carrier  /  ISP Plus +


TOP 20 Unstable Origin AS (Updates per announced prefix)
Rank ASNUpds %  Upds/PfxAS-Name
 1 - AS20426   10001  0.9%   10001.0 -- PWC-AS - 
PriceWaterhouseCoopers, LLP
 2 - AS315943700  0.3%3700.0 -- FORTESS-AS Fortess LLC Network
 3 - AS257741509  0.1%1509.0 -- CHAPMORTCORP - CHAPEL MORTGAGE
 4 - AS195801376  0.1%1376.0 -- ZONETEL - ZONE TELECOM, INC.
 5 - AS330251041  0.1%1041.0 -- QE-ASN-01 - Quinn Emanuel 
Urquhart Oliver & Hedges LLP
 6 - AS7345 3811  0.3% 952.8 -- LUCENTTECH - Lucent 
Technologies Inc.
 7 - AS34378 919  0.1% 919.0 -- RUG-AS Razguliay-UKRROS Group
 8 - AS28746 853  0.1% 853.0 -- MSS-UK-AS Multimedia Strategic 
Solutions - UK
 9 - AS4587 2542  0.2% 847.3 -- ONEWORLD2 - One World 
Internetworking, Inc
10 - AS390661580  0.1% 790.0 -- KREDYTBANKUA-AS Kredyt Bank 
(Ukraine) AS
11 - AS213911318  0.1% 659.0 -- TDA-AS
12 - AS9090  657  0.1% 657.0 -- OiT-AS
13 - AS3043 3161  0.3% 632.2 -- AMPHIB-AS - Amphibian Media 
Corporation
14 - AS22140 631  0.1% 631.0 -- T-MOBILE-AS22140 - T-Mobile USA
15 - AS31307 595  0.1% 595.0 -- YKYATIRIM YAPI KREDI YATIRIM
16 - AS247319822  0.9% 577.8 -- ASN-NESMA National Engineering 
Services and Marketing Company Ltd. (NESMA)
17 - AS307071673  0.1% 557.7 -- SICOR-US-CA-IRVINE - SICOR 
Pharmaceuticals, Inc.
18 - AS4271 1028  0.1% 514.0 -- WORX - Networx
19 - AS9648  498  0.0% 498.0 -- ASN-OZONLINE-AU  # 
AS-OZONLINE-AU CONVERTED TO ASN-OZONLINE-AU FOR RPSL COMPLIANCE Australia 
On-Line Pty Ltd
20 - AS29098 491  0.0% 491.0 -- IPSO-AS S.C. IPSO S.A.


TOP 20 Unstable Prefixes
Rank Prefix Upds % Origin AS -- AS Name
 1 - 155.201.48.0/21   10001  0.7%   AS20426 -- PWC-AS - 
PriceWaterhouseCoopers, LLP
 2 - 194.242.124.0/22   3700  0.3%   AS31594 -- FORTESS-AS Fortess LLC Network
 3 - 89.4.128.0/24  3235  0.2%   AS24731 -- ASN-NESMA National Engineering 
Services and Marketing Company Ltd. (NESMA)
 4 - 89.4.129.0/24  3228  0.2%   AS24731 -- ASN-NESMA National Engineering 
Services and Marketing Company Ltd. (NESMA)
 5 - 209.140.24.0/243134  0.2%   AS3043  -- AMPHIB-AS - Amphibian Media 
Corporation
 6 - 89.4.131.0/24  3115  0.2%   AS24731 -- ASN-NESMA National Engineering 
Services and Marketing Company Ltd. (NESMA)
 7 - 203.177.144.0/23   2917  0.2%   AS4775  -- GLOBE-TELECOM-AS Telecom 
Carrier  /  ISP Plus +
 8 - 62.89.226.0/24 1987  0.1%   AS20663 -- INAR-VOLOGDA-AS Autonomous 
System of Vologda
 9 - 135.109.224.0/19   1986  0.1%   AS7345  -- LUCENTTECH - Lucent 
Technologies Inc.
10 - 135.109.0.0/19 1812  0.1%   AS7345  -- LUCENTTECH - Lucent 
Technologies Inc.
11 - 64.95.193.0/24 1656  0.1%   AS30707 -- SICOR-US-CA-IRVINE - SICOR 
Pharmaceuticals, Inc.
12 - 194.42.208.0/201643  0.1%   AS705   -- UUNET - MCI Communic

Re: Where are static bogon filters appropriate? was: 96.2.0.0/16 Bogons

[Roland Dobbins]

On Mar 2, 2007, at 12:55 AM, <[EMAIL PROTECTED]> wrote:


One might argue that if a company is not capable of
setting a policy and managing that policy, then you
should not implement the policy at all.


I think this really goes to the heart of the matter - the inability/ 
unwillingness to prioritize and allocate resources to properly  
implement 'good neighbor' policies which are not perceived as having  
any financial benefit to the organization.


So, can this sort of activity somehow be monetized by the SPs,  
remedied by the vendors, or is it a matter for the standards bodies  
(or some combination thereof)?


---
Roland Dobbins <[EMAIL PROTECTED]> // 408.527.6376 voice

  The telephone demands complete participation.

  -- Marshall McLuhan

RE: Where are static bogon filters appropriate? was: 96.2.0.0/16 Bogons

[michael.dillon]

> Well Steve, it's like this:  There are (a) security experts, 
> (b) "security
> experts", and (c) guys that spend their day making things 
> usable in spite of
> what the rest of the net throws in their AS's direction.  
> You're an example of
> one, I'm an example of another, and the advocates of static 
> bogon filters are
> an example of the third.  Figuring out which is which is left 
> as an exercise
> for the reader...

This makes it sound like we are talking about some 
kind of network security issue. We aren't!

The fundamental issue is OPERATIONS and has to do with
policy and management of that policy. Bogon filters are
an example of a policy implementation. It should be no
surprise to anyone in operations that when technical people
implement a policy which does not actually exist within
the company, there is nobody to manage that policy
implementation and it eventually becomes orphaned.
One might argue that if a company is not capable of
setting a policy and managing that policy, then you
should not implement the policy at all.

--Michael Dillon