>From: Randy Bush <randy(a)psg.com>
>To: Joe Shaw <jshaw(a)insync.net>
>CC: John Fraizer <John.Fraizer(a)EnterZone.Net>,Dan Hollis
><goemon(a)sasami.anime.net>, bandregg@redhat.com,nanog@merit.edu
>Subject: Re: SYN spoofing
>Date: Mon, 2 Aug 1999 17:09:55 +0200 (CEST)
>
>
> > How hard is it really to put a filter on your outbound links that says
> > drop all ip traffic heading out these links that isn't from my IP space?
>
>trivial. only one gotcha. if it is a backbone router, it will fall over
>dead. beyond that, not a problem.
>
>backbone level traffic can not be packet filtered by current real routers.
>but we've had this discussion a few times already.
>
>randy
>
Which is why it's more scaleable to do packet filtering at the edge, and
leave the core to do what it does best...switch packets.
-rb
_______________________________________________________________
Get Free Email and Do More On The Web. Visit http://www.msn.com
If things of this nature should be posted to a different list, please let
me know (the mail addr) and I will post there.
What is the the difference between the CA and CC trees ?? According to
release notes, They each support a different family of PA interfaces etc.
Is this to say that one does not support what the other does ??
TIA
--------------------------------------------------
Brandon Applegate, CCNA : Network Administrator
http://www.one.net : brandon(a)one.net
--------------------------------------------------
Some weeks ago I noticed that 167.216.128.247/32
(www.digisle.net) appears to reach web servers
located in physically different places broadly
dependent on where you see it from.
I presume this is done by advertising the same
prefix from border routers which are in seperate
IGP domains or something (confederations maybe?),
but I wonder what people's views on the concept are,
since it could potentially be quite confusing in
certain circumstances (e.g. debugging routing
problems) ?
Superficially it seems like a 'cool hack' for
geographic content-distribution (which is what
Digital Island do), but up until now I've always
seen this sort of thing done by exploiting NS
record sorting order properties with the kludge
of different A records in the various zonefiles,
and I wondered if doing it with routing policy in
this way is strictly RFC compliant (or for that
matter if anyone cares if it isn't) ?
M.
Hello all,
I'm sure most, if not all of you are familiar with the filters that various
ISP's and NSP's have placed on received BGP announcements. Most famous
for this is/was? SprintLinks filter policy, which is documented at
http://www.sprintlink.net/filter.htm
Recently the subject of announcement filters and route-dampening policy has
become increasing relevant to a number of my customers, especially when
making sound architecture decisions.
Unfortunately, few providers have documented their filter policies (to my
knowledge) as well as SprintLink. I'm not even sure Sprint follows the
policy anymore. I have specific knowledge of several cases where they are
listening to /24's announced by some companies (albeit these are very high
profile, and would easily be justified as exceptions to the rule)
My question to you, and I believe NANOG to be the most appropriate forum
I know of in this regard, is the perenial "what is the current general policy"
in this regard.
I can think of a few ways to get limitted knowledge about providers policies
by checking for received-announcements on edge routers/looking glasses which
receive transit from other providers (e.g. go to an MCI customer and look
for short prefix announcements known to be announced at, say, Mae-East).
Unfortunately, this is not particularly sound, and is high-effort. Further,
it does nothing to address the second question of mine, which is what the
current typical route-dampening policies are.
Third, and this isn't North-American related, so please refer me to better
sources, should they exist, are these policies any different for other
geographic areas? (e.g. will people listen to smaller announcements at
international peering points, do people place different filters for APNIC
address space, etc.)
Finally, what is the typical reconvergence time for BGP in the global Internet
today?
For full disclosure, my company makes high availability and load balancing
products, and I would certainly prefer these questions be answered in certain
ways. I am, however, most interested in the truth so I can give educated
advice to my customers. It seems like it is no longer reasonable to keep
constant track of who is doing what with routing policies, as it isn't a
simple matter of keeping state on 4-8 providers. At least not unless driving
BGP sessions is your day-to-day job. Currently, my best answers (qualified
with "I may be out of date" are
(1) Varies, but a /19 is probably safe, any smaller likely depends on who
you buy transit from.
(2) Default dampening settings.
(3) I don't remember, several ideas were kicked around.
(4) 15-20 minutes, depending on lots of variables.
Thanks for everyones input on this, any pointers are greatly appreciated.
--D
--
-- Darren Bolding darren(a)f5.com --
-- Principal Consultant --
This is an auto-generated mail on Fri Jul 30 12:00:00 PDT 1999
It is not checked before it leaves my workstation. However, hopefully
you will find this report interesting and will take the time to look
through this to see if you can improve the amount of aggregation you
perform.
The report is split into sections:
0) General Status
List the route table history for the last week, list any possibly
bogus routes seen and give some status on ASes.
1) Gains by aggregating at the origin AS level
This lists the "Top 30" players who if they decided to aggregate
their announced classful prefixes at the origin AS level could
make a significant difference in the reduction of the current
size of the Internet routing table. This calculation does not
take into account the inclusion of holes when forming an aggregate
so it is possible even larger reduction should be possible.
2) Weekly Delta
A summary of the last weeks changes in terms of withdrawn and
added routes. Please note that this is only a snapshot but does
give some indication of ASes participating in CIDR. Clearly,
it is generally a good thing to see a large amont of withdrawls.
3) Interesting aggregates
Interesting here means not an aggregate made as a set of
classful routes.
Thanks to xara.net for giving me access to their routing tables once a
day.
Please send any comments about this report directly to me.
Check http://www.employees.org/~tbates/cidr-report.html for a daily
update of this report.
------------------------------------------------------------------------------
CIDR REPORT for 30Jul99
0) General Status
Table History
-------------
Date Prefixes
230799 61494
240799 61486
250799 61391
260799 61592
270799 61488
280799 61707
290799 61808
300799 61912
Check http://www.employees.org/~tbates/cidr.plot.html for a plot
of the table history.
Possible Bogus Routes
---------------------
AS Summary
----------
Number of ASes in routing system: 5372
Number of ASes announcing only one prefix: 2813 (1550 cidr, 1263 classful)
Largest number of cidr routes: 461 announced by AS701
Largest number of classful routes: 841 announced by AS701
1) Gains by aggregating at the origin AS level
--- 30Jul99 ---
ASnum NetsNow NetsCIDR NetGain % Gain Description
AS271 348 147 201 57.8% BCnet Backbone
AS2609 121 28 93 76.9% EUnet-TN
AS174 578 486 92 15.9% Performance Systems International
AS1221 537 445 92 17.1% TELSTRA-AS
AS577 280 189 91 32.5% Bell Canada Backbone
AS3749 153 63 90 58.8% TECNET
AS4293 235 149 86 36.6% IMCI
AS7046 322 237 85 26.4% UUNET-CUSTOMER
AS4200 182 103 79 43.4% AGIS (Apex Global Information Ser
AS7545 141 66 75 53.2% TPG Internet Pty Ltd
AS7496 108 34 74 68.5% Power Up
AS7657 229 156 73 31.9% The Internet Group Limited
AS10928 119 49 70 58.8% UNKNOWN
AS9269 76 16 60 78.9% Hong Kong CTI
AS4755 138 79 59 42.8% Videsh Sanchar Nigam Ltd. India
AS6944 63 6 57 90.5% RapidSite, Inc.
AS4740 307 253 54 17.6% Ozemail Pty Ltd (ASN-OZEMAIL)
AS719 458 406 52 11.4% LANLINK autonomous system
AS2493 159 110 49 30.8% iSTAR Internet, Inc.
AS684 91 46 45 49.5% Manitoba Regional Network Backbon
AS803 78 34 44 56.4% SaskNet Backbone
AS549 215 172 43 20.0% ONet Backbone
AS3737 108 67 41 38.0% PenTeleData Inc. (ASN-PTD)
AS1785 253 215 38 15.0% NYSERNet Backbone
AS209 251 216 35 13.9% Qwest Communications
AS1 495 460 35 7.1% BBNPLANET
AS10724 42 8 34 81.0% UNKNOWN
AS6762 33 2 31 93.9% Telecom Italia international high
AS4307 32 1 31 96.9% SVINET-1
AS11515 32 1 31 96.9% UNKNOWN
For the rest of the previous weeks gain information please see
http://www.employees.org:80/~tbates/cidr-report.html
2) Weekly Delta
Please see
http://www.employees.org:80/~tbates/cidr-report.html
for this part of the report
3) Interesting aggregates
Please see
http://www.employees.org:80/~tbates/cidr-report.html
for this part of the report
Last updated August 1, 1999. All information subject to changes and
corrections at any time. Verify any information before making any
decisions or taking any action. This is not an official statement
by any organization listed. Some organizations may be further along
than indicated here due to delays updating web pages, or since the
last presentation at a public meeting.
Exchange Points
AMS-IX
http://www.ams-ix.net/y2k.html
Has arranged for Y2K upgrades
LINX
http://www.linx.net/Y2Kconf.html
Upgrades and/or testing for Y2K completed
MAEs
EAST http://www.mae.net/
WEST Scheduled to be completed by June 30, 1999
etc. Some have battery backup, some have generators
NAPs
Chicago
http://www.aads.net/
Upgrades and/or testing for Y2K completed
Y2K statement available on paper
SanFrancisco
http://www.pacbell.com/products/business/fastrak/networking/nap/index.html
Upgrade in progress
NewYork(Pensauken)
http://www.sprint.com/
Officially, no comment on NAP readiness
Unofficially Y2K ready
PAIX
Upgrade in progress
Battery backup and generator
On-site staff and radio backup
Address and Name Registries
APNIC
http://www.apnic.com/statement.html
Scheduled to be complete by July 1, 1999
ARIN
http://www.arin.net/
Scheduled to be complete by June 30, 1999
Plan to mirror database at RIPE and APNIC
NSI
http://www.netsol.com/
Scheduled to be completed by June 30, 1999
Battery backup and generator
Root servers
Not broken out by location
Upgrades and/or testing completed
Backup power available
--
Sean Donelan, Data Research Associates, Inc, St. Louis, MO
Affiliation given for identification not representation
