Re: Monitoring dark address space?

[Paul Vixie]

[EMAIL PROTECTED] (David A.Ulevitch) writes:

> I was wondering how many of you are running some sort of detection tool 
> on "dark address" space on your network?

h, h, me!

> In an effort to curb malicious outbound non-spoofed traffic from "owned"
> client machines I think one of the easiest methods we have is to look for
> scans in what should be dead space.

you're right.

> The source-address spoofed traffic is easy to drop, the "legal" traffic
> is a bit more complex and I'm looking for non-inline methods of curbing
> this traffic.

since this space has no dns records pointing into it, the only traffic it
will see is from errors/typo's, and network scanners.  some scanners use
pseudorandom selection, some are serial, but none are nonmalicious.

> My questions are:
> 
> 1) Are you doing this and if so, what tools are you using?  Some sort 
> of simple listening device with thresholds would probably do the trick 
> if one machine monitored an entire /24 or some random /32's out of a 
> /16.

in freebsd ipfw:

  pipe 1 config mask src-ip 0x buckets 32768 bw 10Mbit/sec
  pipe 1 ip from any to x.y..0.0/16 in
  fwd 127.0.0.2 ip from any to x.y.0.0/16 in

"pipe 1" is just there for measurement purposes, and ddos prevention.
the address i fwd it to is an extra loopback alias defined in rc.conf:

  ifconfig_lo0_alias0="inet 127.0.0.2 netmask 255.255.255.255"

this box also runs zebra to inject this /16 into the local OSPF, which
elsewhere triggers some router of jabley's to inject it into BGP.  there
are two listeners, both written locally, that are started in rc.local by
scripts that look like this:

  while :; do
( src/httpk/i386/httpk -b reject-all.vix.com -t 3 -h 127.0.0.2 \
-s http -f endoftheline.html -l |
  tee tee | src/httpk/pgit.pl ) > log 2> err
sleep 45
  done

and this:

  while :; do
( src/smtpk/smtpk -l 127.0.0.2 |
  tee tee |
  src/smtpk/pgit.pl ) > log 2> err
sleep 2
  done

the "tee" file is sort of unreadable.  for httpk it looks like this:

  src [209.148.235.157].3083; dst [149.20.195.105].80; Sat Apr 17 03:55:07 2004
  GET / HTTP/1.1
  Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
  User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)
  Host: 149.20.195.105
  Connection: Keep-Alive

whereas for smtpk it looks like this:

  Message-ID: <[EMAIL PROTECTED]>
  To: <[EMAIL PROTECTED]>
  From: [EMAIL PROTECTED]
  Subject: Hey, what's up?
  Date: Sun, 11 Apr 2004 13:47:24 -1900
  MIME-Version: 1.0
  Content-Type: text/plain;
charset="Windows-1252"
  Content-Transfer-Encoding: 7bit
  X-Priority: 3
  X-MSMail-Priority: Normal
  X-Mailer: Microsoft Outlook Express 5.00.3018.1300
  X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300
  
  [222.156.12.131] -> [204.152.191.0] none <[EMAIL PROTECTED]> \
(78) 1081855616.285020
  <[EMAIL PROTECTED]>
  --

the postgres databases thus populated are much prettier, as are the "log"
files produced by the respective "pgit.pl" scripts.

> 2) What techniques seem to be better? Monitoring an entire /24 or 
> picking a distributed selection of IPs from a /16? (using a /24 or /25 
> is much easier on the administrative end of things from where I sit...)

i've tried /24's and i've tried covering-routes for well populated /21's
and the thing that works really the best is an unused research-purposes /16.

> 3) What sort of threshold metrics for considering something to be 
> malicious have you found to be good?  (ports/second, ip/second, etc)

the false positives are less than one in ten million.  "blackhole 'em all."

> 4) Are there downsides to this (aside from false positives, which would 
> hopefully be rare in truly dark address space).

it's a l-l-lotta d-d-data, m-m-man.  otoh, between this and postprocessing
my maillogs looking for wormspoor, i have a personal blackhole list with
almost a million hosts on it now, and about 20% of the ones who probe my
smtpk (which always accepts all mail you send it) later try to spam my main
mail server (which is in a different netblock).  i'd say i've learned quite
a lot about how spammers and wormers work together nowadays.

  httpk=# select count(*) from trans where srcaddr<<='209.148.235.0/24';
   count 
  ---
  21
  (1 row)

ahhh, postgresql and its inet/cidr datatypes.  (try 'em, you'll like 'em.)
-- 
Paul Vixie

RE: Lazy network operators

[Michel Py]

> Paul Vixie wrote:
> ipv4 CIDR also had the effect of making end users fear
> their provider-assigned IP addresses, and the real incentive
> for ipv4 NAT deployment wasn't a lack of ipv4 address space
> but rather a lack of interest in provider-assigned ("lockin")
> addressing.

Indeed, and it did take many going through the pain of renumbering once
to understand this. Lots have been burned, and most won't make the same
mistake twice: if they ever have to implement IPv6 the one thing they
won't go with is "lockin" addressing.


> it's still quite astounding to me that when we finish
> deploying ipv6 we'll still have provider assigned
> addresses that customers are afraid to use beyond the
> edge of their campus, and we'll still have the age-old
> tension between "i could get global routing for that
> address block" and "i could qualify with my RIR to
> obtain that address block (and afford the fees)".

Not astounding to me; IPv6 has never been designed with
the end-user in mind, because said users are typically
not represented in the IETF. Nothing different from the
telephone: we just got cell phone number portability,
and it certainly did not come out from a telco initiative.


> Iljitsch van Beijnum wrote:
> I mean, if you're going to use NAT, why switch to
> IPv6 in the first place?

Answer: stay with IPv4.


> Paul Vixie wrote:
> reasons will vary from "because my vendors are pushing it"
> to "because it has some feature that makes my life easier"

At this point in time none of the features is worth the
infrastructure upgrade cost.

> to "because some application my users are asking for only works on
ipv6"

Still have to see one, as most application writers are not
stupid enough to waste their time writing an IPv6-only app
that will successfully capture 50% of the IPv6 market which
happens to be 0% of the total market.

> to "because it will help me justify next year's IT budget".

Don't even need that one, there are plenty of other and
more important things I can toss in next year's budget.
Besides, in terms of budget, it is risky business to ask
For something that does not provide ROI quickly.

> one reason that won't be on the list is "because i cannot
> otherwise get enough address space to become fully locked
> into my current transit provider."

Indeed.

> and i don't imagine the site-local address ranges will be
> given to a RIR, so folks who decide to number their
> enterprise in that range and then speak to "the internet"
> through an as-yet-unannounced ipv6-nat product will just
> do that.

Indeed, and there are actually blocks that are better choices than the
former site-local range for that (because they are not deprecated).


> Iljitsch van Beijnum wrote:
> IETF multi6 wg is working on this problem. Hopefully it's
> possible to come up with something that offers both
> scalability and functionality, as current PI and PA
> paradigms each only offer one.

I hard that song for the last ten years. Bottom line is, it's too late
now.


> Paul Vixie wrote:
> so exactly where the multi6 group is planning to sell
> their results, I can't imagine.

I came to the same conclusion earlier. Besides the technical challenges,
there were and still are too many people in the loop that wanted it to
fail in the first place.

Michel.

Re: google.

[Jeff Shultz, WIllamette Valley Internet]

** Reply to message from "Micah McNelly" <[EMAIL PROTECTED]> on Fri, 16
Apr 2004 15:08:27 -0700

> is anyone having google reachability issues?
> 
> /m

Based on a traceroute I pulled as soon as I realized it, I think Savvis
had a router problem. See hops 11 through 30. 

<[EMAIL PROTECTED]:/etc:633>$ traceroute 216.239.53.99
traceroute to 216.239.53.99 (216.239.53.99), 30 hops max, 40 byte
packets
 1  wvi-gw.wvi.com (204.119.27.254)  1 ms  4 ms  1 ms
 2  d1-2-0-30.a01.ptldor02.us.ra.verio.net (206.58.80.161)  5 ms  2 ms 
5 ms
 3  ge-1-0-0.r01.ptldor01.us.bb.verio.net (129.250.30.145)  5 ms  5 ms 
5 ms
 4  p4-6-1-0.r04.sttlwa01.us.bb.verio.net (129.250.3.37)  10 ms  10 ms 
7 ms
 5  bpr2-so-5-2-0.SeattleSwitchDesign.savvis.net (208.173.50.65)  52 ms
51 ms  52 ms
 6  acr2-so-6-0-0.Seattle.savvis.net (208.172.81.186)  51 ms  51 ms  53
ms
 7  dcr1-loopback.SantaClara.savvis.net (208.172.146.99)  54 ms  73 ms 
53 ms
 8  bhr1-pos-0-0.SantaClarasc5.savvis.net (208.172.156.74)  53 ms  56
ms  53 ms
 9  csr23-ve240.SantaClarasc4.savvis.net (216.34.3.98)  80 ms  81 ms 
79 ms
10  bhr1-g8-2.SantaClarasc4.savvis.net (216.34.3.97)  53 ms  61 ms  53
ms
11  * csr21-ve240.SantaClarasc4.savvis.net (216.34.3.2)  80 ms *
12  bhr1-g3-0.SantaClarasc4.savvis.net (216.34.3.17)  58 ms  53 ms  53
ms
13  * * *
14  bhr1-g3-0.SantaClarasc4.savvis.net (216.34.3.17)  53 ms  53 ms  55
ms
15  * * *
16  bhr1-g3-0.SantaClarasc4.savvis.net (216.34.3.17)  53 ms  61 ms  53
ms
17  * * csr21-ve240.SantaClarasc4.savvis.net (216.34.3.2)  81 ms
18  bhr1-g3-0.SantaClarasc4.savvis.net (216.34.3.17)  53 ms  53 ms  53
ms
19  * * csr21-ve240.SantaClarasc4.savvis.net (216.34.3.2)  82 ms
20  bhr1-g3-0.SantaClarasc4.savvis.net (216.34.3.17)  54 ms  53 ms  53
ms
21  * * *
22  bhr1-g3-0.SantaClarasc4.savvis.net (216.34.3.17)  56 ms  53 ms  53
ms
23  * * *
24  bhr1-g3-0.SantaClarasc4.savvis.net (216.34.3.17)  53 ms  53 ms  54
ms
25  * * csr21-ve240.SantaClarasc4.savvis.net (216.34.3.2)  83 ms
26  bhr1-g3-0.SantaClarasc4.savvis.net (216.34.3.17)  56 ms  53 ms  58
ms
27  * csr21-ve240.SantaClarasc4.savvis.net (216.34.3.2)  87 ms *
28  bhr1-g3-0.SantaClarasc4.savvis.net (216.34.3.17)  55 ms  53 ms  53
ms
29  * csr21-ve240.SantaClarasc4.savvis.net (216.34.3.2)  82 ms *
30  bhr1-g3-0.SantaClarasc4.savvis.net (216.34.3.17)  54 ms  53 ms  56
ms
-- 
Jeff Shultz
Network Technician
Willamette Valley Internet

Re: google.

[Mike Lewinski]

Micah McNelly wrote:

is anyone having google reachability issues?
See today's UF:

http://ars.userfriendly.org/cartoons/?id=20040416

Re: google.

[Dan Hollis]

On Fri, 16 Apr 2004, Micah McNelly wrote:
> is anyone having google reachability issues?

We noticed for a while today that google was unreachable by any path 
except sprint. Seems ok now though.

-Dan

google.

[Micah McNelly]

is anyone having google reachability 
issues?
 
/m

Re: Lazy network operators

[Petri Helenius]

Iljitsch van Beijnum wrote:

So why are they sending their people to the IETF to work on mobile 
IPv6?? (Current MIPv6 spec is version 24 clocking in at 170 pages, 
implementing that can't be much fun.)

They do that for job security. Bluetooth 1.0 is in excess of 1000 
pages.  Not to mention some of the 3GPP stuff.

Pete

Re: Lazy network operators

[Niels Bakker]

>> On the other hand, we've had DDoS prevention mechanisms (based on
>> multiple rate-limiters, for different kinds of packets) deployed for
>> over 6 months now.  They seem to work just fine, are always active,
>> and require no state in the network.

* [EMAIL PROTECTED] (Paul Vixie) [Fri 16 Apr 2004, 17:14 CEST]:
> you know how to rate-limit without state in the network?  please explain.

Unlike PNAT, you don't need to look at packets traveling both ways.
This is a plus, I suppose.


-- Niels.

Re: Lazy network operators

[Iljitsch van Beijnum]

On 16-apr-04, at 17:45, Paul Vixie wrote:

Unless I'm very much mistaken, this transition mechanism ("NAT-PT")
translates from IPv6 to IPv4 and vice versa, NOT from IPv6 to IPv6.

sure, but abusing tools for purposes other than what they were made 
for is
how most IT directors earn their salaries (though they don't call it 
that.)
I'm not entirely convinced, but replace NAT with a bunch of proxies and 
you basically have the same thing...

and i don't imagine the site-local address ranges will be given to a 
RIR,
so folks who decide to number their enterprise in that range and then 
speak
to "the internet" through an as-yet-unannounced ipv6-nat product will 
just
do that.
I'd love to be around and watch sparks fly when they start asking for 
the same ugly hacks in IPv6 that make NAT work to the degree that it 
does in IPv4.  :-)

IETF multi6 wg is working on this problem. Hopefully it's possible to 
come
up with something that offers both scalability and functionality, as
current PI and PA paradigms each only offer one.

as someone who cared deeply about this at one time and who watched 
A6/DNAME
become a fly on the windshield of ietf backroom politics, i wish you 
luck.
Thank you.

it's important to remember that large network owners don't care about 
this,
It looks to me like many do...

and they are the ones who tell the vendors what to build.  someone who 
wants
to build a 3G network doesn't want A6/DNAME or any other added 
complexity
adding logic and bugs to their handhelds or their cell towers.
So why are they sending their people to the IETF to work on mobile 
IPv6?? (Current MIPv6 spec is version 24 clocking in at 170 pages, 
implementing that can't be much fun.)

someone who
wants to sell a lot of business-DSL is happier if their customers are 
locked
in.  so exactly where the multi6 group is planning to sell their 
results, i
can't imagine.
Maybe to the customers of those business DSL shops? And easier 
multihoming sells more circuits, so I doubt we'll hear people with 
glass or copper in the ground complain.

Re: Lazy network operators

[Petri Helenius]

Paul Vixie wrote:

it's important to remember that large network owners don't care about this,
and they are the ones who tell the vendors what to build.  someone who wants
to build a 3G network doesn't want A6/DNAME or any other added complexity
adding logic and bugs to their handhelds or their cell towers.  someone who
wants to sell a lot of business-DSL is happier if their customers are locked
in.  so exactly where the multi6 group is planning to sell their results, i
can't imagine.
 

Maybe it would go the way of the POTS, ask the regulator to help and 
something will happen in a decade after the marketshares have been divided?

Pete

Re: Lazy network operators

[Paul Vixie]

> Yes, this is a problem. I'm not sure NAT is the solution, though. I mean,
> if you're going to use NAT, why switch to IPv6 in the first place?

reasons will vary from "because my vendors are pushing it" to "because it
has some feature that makes my life easier" to "because some application
my users are asking for only works on ipv6" to "because it will help me
justify next year's IT budget".  one reason that won't be on the list is
"because i cannot otherwise get enough address space to become fully locked
into my current transit provider."

> Unless I'm very much mistaken, this transition mechanism ("NAT-PT")
> translates from IPv6 to IPv4 and vice versa, NOT from IPv6 to IPv6.

sure, but abusing tools for purposes other than what they were made for is
how most IT directors earn their salaries (though they don't call it that.)

and i don't imagine the site-local address ranges will be given to a RIR,
so folks who decide to number their enterprise in that range and then speak
to "the internet" through an as-yet-unannounced ipv6-nat product will just
do that.

> > ... we'll still have the age-old tension between "i could get global
> > routing for that address block" and "i could qualify with my RIR to
> > obtain that address block (and afford the fees)".
> 
> IETF multi6 wg is working on this problem. Hopefully it's possible to come
> up with something that offers both scalability and functionality, as
> current PI and PA paradigms each only offer one.

as someone who cared deeply about this at one time and who watched A6/DNAME
become a fly on the windshield of ietf backroom politics, i wish you luck.

it's important to remember that large network owners don't care about this,
and they are the ones who tell the vendors what to build.  someone who wants
to build a 3G network doesn't want A6/DNAME or any other added complexity
adding logic and bugs to their handhelds or their cell towers.  someone who
wants to sell a lot of business-DSL is happier if their customers are locked
in.  so exactly where the multi6 group is planning to sell their results, i
can't imagine.

Re: Lazy network operators

[Paul Vixie]

> On the other hand, we've had DDoS prevention mechanisms (based on
> multiple rate-limiters, for different kinds of packets) deployed for
> over 6 months now.  They seem to work just fine, are always active,
> and require no state in the network.

you know how to rate-limit without state in the network?  please explain.

Monitoring dark address space?

[David A . Ulevitch]

NANOG,

I was wondering how many of you are running some sort of detection tool 
on "dark address" space on your network?  In an effort to curb 
malicious outbound non-spoofed traffic from "owned" client machines I 
think one of the easiest methods we have is to look for scans in what 
should be dead space.  The source-address spoofed traffic is easy to 
drop, the "legal" traffic is a bit more complex and I'm looking for 
non-inline methods of curbing this traffic.

My questions are:

1) Are you doing this and if so, what tools are you using?  Some sort 
of simple listening device with thresholds would probably do the trick 
if one machine monitored an entire /24 or some random /32's out of a 
/16.

2) What techniques seem to be better? Monitoring an entire /24 or 
picking a distributed selection of IPs from a /16? (using a /24 or /25 
is much easier on the administrative end of things from where I sit...)

3) What sort of threshold metrics for considering something to be 
malicious have you found to be good?  (ports/second, ip/second, etc)

4) Are there downsides to this (aside from false positives, which would 
hopefully be rare in truly dark address space).

Off-list replies are fine and I'll summarize after a few days.

thanks,
davidu

  David A. Ulevitch - Founder, EveryDNS.Net
  Washington University in St. Louis
  http://david.ulevitch.com -- http://everydns.net

Re: NSP-SEC BOF CFP

[Susan Harris]

> Merike & I are chairing the NSP-SEC BOF at NANOG
> in SF in a few weeks.  Anyone with topics you'd
> like to see discussed, or topics you'd like to discuss,
> please let us know ASAP.

BTW, more info about NSP-SEC here:

https://puck.nether.net/mailman/listinfo/nsp-security

Re: Lazy network operators

[Iljitsch van Beijnum]

On 16-apr-04, at 8:47, Paul Vixie wrote:

preventing DDoS and IP source address forgery each also break what 
the
IAB calls "the end-to-end model".

How so?

I was thinking of RFC 1958:

   An end-to-end protocol design should not rely on the maintenance of
   state (i.e. information about the state of the end-to-end
   communication) inside the network.

While this is given as an argument in favour of datagrams (vs. 
circuits)
as the best transport model, any stateful NAT or firewall violates it,
any router or loadbalancer flow-quota violates it, and pretty much 
anything
that can be done to protect against DDoS violates it.
To quote Steve Deering: there is good state and there is bad state. 
State that is created by looking at the actual communication and then 
recreated when it's lost isn't necessarily evil. (Although I agree that 
when this stuff is taken too far it breaks e2e, for instance a Pix that 
will happily chop off part of a DNS packet when it decides said packet 
is too long.)

(dunno if you heard, but in spite of 128 bits of address space, the
enterprise user community is now asking for IPv6 NAT.)

I hadn't, pointer please?

 comes to mind.
Ok, you won't hear me say that Tim doesn't know what he's talking 
about... But this can mean all kinds of things, ranging from "everyone 
will use NAT with IPv6" to "there is probably a misguided soul or two 
who will try this".

but moreso the folks looking at deployment who absolutely don't want 
another
IPv4-like lockin, where provider-assigned addresses mean a huge 
renumbering
effort in order to change upstreams, and the expectation that globally
routeable address blocks will not be available, or will not be cost
effective, for enterprise or small-ISP use.
Yes, this is a problem. I'm not sure NAT is the solution, though. I 
mean, if you're going to use NAT, why switch to IPv6 in the first 
place?

nowadays ietf is working on
what they call NAT-PT as a "transition" strategy, with a new set of 
heads
stuffed into the same old sand, whereby the designers think that 
network
owners are only going to use it until the ipv6 transition is complete.
Unless I'm very much mistaken, this transition mechanism translates 
from IPv6 to IPv4 and vice versa, NOT from IPv6 to IPv6.

it's still quite astounding to
me that when we finish deploying ipv6 we'll still have provider 
assigned
addresses that customers are afraid to use beyond the edge of their 
campus,
and we'll still have the age-old tension between "i could get global 
routing
for that address block" and "i could qualify with my RIR to obtain that
address block (and afford the fees)".
IETF multi6 wg is working on this problem. Hopefully it's possible to 
come up with something that offers both scalability and functionality, 
as current PI and PA paradigms each only offer one.

The Cidr Report

[cidr-report]

This report has been generated at Fri Apr 16 21:44:13 2004 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
09-04-04133208   93271
10-04-04133231   93284
11-04-04133153   93021
12-04-04133240   93272
13-04-04133257   93290
14-04-04133326   93436
15-04-04133395   93472
16-04-0418   93463


AS Summary
 16945  Number of ASes in routing system
  6817  Number of ASes announcing only one prefix
  1416  Largest number of prefixes announced by an AS
AS7018 : ATTW AT&T WorldNet Services
  73611264  Largest address span announced by an AS (/32s)
AS568  : DISOUN DISO-UNRRA


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

 --- 16Apr04 ---
ASnumNetsNow NetsAggr  NetGain   % Gain   Description

Table 133415935373987829.9%   All ASes

AS4134   695  139  55680.0%   CHINANET-BACKBONE
   No.31,Jin-rong Street
AS4323   709  199  51071.9%   TWTC Time Warner Telecom
AS7018  1416  985  43130.4%   ATTW AT&T WorldNet Services
AS7843   533  113  42078.8%   ADELPH-13 Adelphia Corp.
AS6197   685  301  38456.1%   BNS-14 BellSouth Network
   Solutions, Inc
AS27364  405   33  37291.9%   ARMC Armstrong Cable Services
AS701   1297  934  36328.0%   UU UUNET Technologies, Inc.
AS22909  382   31  35191.9%   CMCS Comcast Cable
   Communications, Inc.
AS6198   562  226  33659.8%   BNS-14 BellSouth Network
   Solutions, Inc
AS9583   436  116  32073.4%   SATYAMNET-AS Satyam Infoway
   Ltd.,
AS22773  359   40  31988.9%   CXAB Cox Communications Inc.
   Atlanta
AS9929   338   31  30790.8%   CNCNET-CN China Netcom Corp.
AS1239   944  641  30332.1%   SPRN Sprint
AS4355   384   99  28574.2%   ERSD EARTHLINK, INC
AS6140   379  111  26870.7%   IMPSA ImpSat
AS17676  307   45  26285.3%   JPNIC-JP-ASN-BLOCK Japan
   Network Information Center
AS6478   293   44  24985.0%   ATTW AT&T WorldNet Services
AS209761  520  24131.7%   QWEST-4 Qwest
AS1221   865  631  23427.1%   ASN-TELSTRA Telstra Pty Ltd
AS6347   376  145  23161.4%   SAVV SAVVIS Communications
   Corporation
AS25844  243   17  22693.0%   SASMFL-2 Skadden, Arps, Slate,
   Meagher & Flom LLP
AS14654  2264  22298.2%   WAYPOR-3 Wayport
AS11305  241   31  21087.1%   INTERL-80 Interland
   Incorporated
AS3356   895  692  20322.7%   LEVEL3 Level 3 Communications
AS4766   454  253  20144.3%   KIX Korea Internet Exchange
   for "96 World Internet
   Exposition
AS9443   358  169  18952.8%   INTERNETPRIMUS-AS-AP Primus
   Telecommunications
AS2386   432  244  18843.5%   ADCS-1 AT&T Data
   Communications Services
AS4519   205   22  18389.3%   MAASCO Maas Communications
AS6327   206   28  17886.4%   SHAWC-2 Shaw Communications
   Inc.
AS20115  584  409  17530.0%   CC04 Charter Communications

Total  15970 7253 871754.6%   Top 30 total


Possible Bogus Routes

24.138.80.0/20   AS11260 AHSICHCL Andara High Speed Internet c/o Halifax 
Cable Ltd.
24.246.0.0/17AS7018  ATTW AT&T WorldNet Services
24.246.128.0/18  AS7018  ATTW AT&T WorldNet Services
60.254.0.0/20AS23889 MAURITIUS-TELECOM-AS-AP MAURITIUS TELECOM
64.22.0.0/18 AS3561  CWU Cable & Wireless USA
64.46.0.0/18 AS7850  IHIGHW iHighway.net, Inc.
64.46.4.0/22 AS11711 TULARO TULA

Re: Lazy network operators

[Pekka Savola]

On Fri, 16 Apr 2004, Paul Vixie wrote:
> > > preventing DDoS and IP source address forgery each also break what the
> > > IAB calls "the end-to-end model".
> > 
> > How so?
> 
> I was thinking of RFC 1958:
> 
>An end-to-end protocol design should not rely on the maintenance of
>state (i.e. information about the state of the end-to-end
>communication) inside the network.
> 
> While this is given as an argument in favour of datagrams (vs. circuits)
> as the best transport model, any stateful NAT or firewall violates it,
> any router or loadbalancer flow-quota violates it, and pretty much anything
> that can be done to protect against DDoS violates it.

"Protect" is an absolute term.  Do you mean, "eliminate completely"?  
That is obviously an impossibility with or without state-based 
mechanisms.

On the other hand, we've had DDoS prevention mechanisms (based on
multiple rate-limiters, for different kinds of packets) deployed for
over 6 months now.  They seem to work just fine, are always active,
and require no state in the network.

The biggest problem is obviously ensuring that the rate-limiter does
not starve (too badly) the legitimate users of the same class.  
Having multiple classes helps with that, but will likely be less
effective when the attackers get smarter to choose attacks which are
indistinguishable from mainstream applications.

-- 
Pekka Savola "You each name yourselves king, yet the
Netcore Oykingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

NSP-SEC BOF CFP

[Danny McPherson]

Folks,
Merike & I are chairing the NSP-SEC BOF at NANOG
in SF in a few weeks.  Anyone with topics you'd
like to see discussed, or topics you'd like to discuss,
please let us know ASAP.
Thanks!

-danny & merike