Digital Island sponsors DoS attempt?

Mailman List Mirror (Read Only)
1

Hello friends,

My IDS was just tripped over 300 times. The decoded packet says:

mailto:abuse@digisle.com for questions
This ICMP ECHO REQUEST/REPLY is part of the real-time network monitoring
performed by Digital Island Inc. It is not an attack. If you have
questions please contact
abuse@digisle.com...........................................................
............................................................................
............................................................................
............................................................................
............................................................................
............................................................................
............................................................................
............................................................................
............................................................................
............................................................................
............................................................................
............................................................................
............................................................................
............................................................................
............................................................................
...............................................

We are not on their network or in any way affiliated with Digital Island,
I'm just curious if anyone else has seen this anomaly, if it is legit, or if
it is a real attack being spoofed from Digital Island...no response from
abuse@digisle.com yet.

Regards,
Christopher J. Wolff, VP, CIO
Broadband Laboratories, Inc.
http://www.bblabs.com
email:chris@bblabs.com
phone:520.622.4338 x234

2

got an ip address and port? it's acl time.

randy

3

I don't know anything about what digital island is doing in
  particular, but for a long time people have struggled with the issue
  of how to offer better quality connectivity to sites off of their
  network.

  The communal nature of the Internet in times gone by provided
  altruistic desires (usually) to provide good connectivity, but as
  the quality becomes directly tied to cost, it is likely to suffer.

  I suspect that DI, like many other companies, is actively monitoring
  external sites to track, study, and hopefully improve connectivity
  quality to them.

  -alan

Thus spake Christopher J. Wolff (chris@bblabs.com)

mailto:abuse@digisle.com for questions
This ICMP ECHO REQUEST/REPLY is part of the real-time network monitoring
performed by Digital Island Inc. It is not an attack. If you have
questions please contact
abuse@digisle.com...........................................................

4

Which ICMP port would you recommend he put in his acl?

Thus spake Randy Bush (randy@psg.com)
on or about Thu, Oct 25, 2001 at 05:56:10PM -0700:

5

If everyone sent out "feelers" we would all have OC3's just to accept the feelers...forget customers.

Reid Fishler
Lightning.net

6

:
: I suspect that DI, like many other companies, is actively monitoring
: external sites to track, study, and hopefully improve connectivity
: quality to them.

So, you suspect that Digisle has come up with a scheme for jiving
latency/path efficiency with as-paths, and integrating that into their own
routing policies? Noone has done this well yet. Those who have tried
have failed to realize the need for standardization, or have decided to
ignore such in the interest of developing a patented, proprietary scheme
(which is, based solely on common sense, doomed).

Conclusion: Digisle's probes are not at all justified. Hopefully, they're
listening.

Admittedly, I may be misreading your theory. If so, please elaborate.

cheers,
brian

7

Hi Brian,

  I know that an ISP can learn infornation about path quality off of
  its network. I also know that many ISPs have no interest in
  learning about quality off of their network.

  You are right that discretely mapping empirical behaviour to datum
  such as AS Path, external_peering_link, and other various variables
  like Time of Day, etc... is difficult.

  Some folks have made progress on this, and use it to make things
  better, some in a manual fashion, some in a more and more automated
  fashion.

  Some people would suggest to solve off-net quality problems by a/
  blaming, or b/ suggesting that the other network increase bandwidth,
  or c/ rerouting. In order to do c/ sometimes it is helpful to learn
  information about different paths, from different vantage points.

  So, I don't really want to delve too deep into the theory of what
  exactly DI is doing, I suspect they'll tell us if they are as clever
  as they seem to be.

  I do know, however, that the gaining information about external
  performance can be useful for optimizing egress traffic flows, both
  on a micro, mid, and macro basis.

  With regards to your suggestion below about standardization, I think
  it would be great if stuff like IPPM, IPDR and such were done in the realm
  of off-net performance. However, let's not confuse operational
  implementations (for example, off-net brains thinking about what to
  do) with standardized protocols required for interacting with
  others. Egress flow optimization can be done autonomous of
  standards, and is, today :slight_smile:

  -alan

Thus spake Brian Wallingford (brian@meganet.net)
on or about Thu, Oct 25, 2001 at 11:41:20PM -0400:

8

I certainly wouldn't dispute DI's right to measure performance to
other places on the Internet. After all, ICMP is an application too,
and as long as it doesn't negatively impact performance, there shouldn't
be anything wrong with it.

However, I would think it common courtesy to contact the network
administrator of a site you intend to measure, particularly if your
measurement tools are likely to trip security alarms.

On Thu, Oct 25, 2001 at 10:19:10PM -0500, Alan Hannan reportedly typed:

9

Now if we only knew how to get (for example) things to work right if the
contact would look like:

"Hi, we have an F5 load balancer, and one of your users just contacted us,
and we were wondering if it were OK for us to try to provide better service
for your user by measuring network latencies before we send the content they
asked us for...."

And I suppose we really *should* also ask all the transit AS's as well...

10

If you have a list of prefix's you intend to measure, it would not be

If.

This list comes from *where*?

What if I pointed out that IBM's AIX implements Path MTU Discovery by sending
an ICMP packet with max MTU and the DF bit set (so it can discover the *max*
MTU even if the first *TCP* packet is not a full MTU long)?

Are you saying that I should contact each prefix that my Listserv machine is
sending mail to, to get permission to negotiate PMTU discovery? Ouch.
That's 600K subscribers, and I need to go look up where their MX entries
point to, figure out what AS the destination is in, and send the AS contact
mail (assuming that 'whois' actually has valid data) - and then repeat for
every new subscriber to a list from an AS we haven't contacted before.

No? That seems silly? How is it any different from 5 PING packets so a site
can decide which server to send stuff from? Where do you draw the line?

transit providers needn't be involved, as transit providers typically
don't measure icmp flows bound to customers.

We've seen cases where transit providers do things like install blackhole
routing because they disagree with a site because of their traffic. This
proves that at least *some* transit providers care about *some* traffic for
*some* reason. Again, where do you draw the line?

11

On Fri, Oct 26, 2001 at 12:48:39PM -0400, Valdis.Kletnieks@vt.edu reportedly typed:

> If you have a list of prefix's you intend to measure, it would not be

If.

This list comes from *where*?

If you intend to measure a set of prefixes using a method that might be
considered intrusive, you have a list of prefixes, no?

The line is drawn with intent and scope.

We aren't talking about 5 ping packets as part of path MTU discovery.
We aren't even talking about 5 ping packets sent as part of a ping
triangulation in response to an http request.

We're talking about intentional measurement of a network, on a scale large
enough to concern a network administrator.

It's really not that hard to know when you're doing the right thing or
the wrong thing. You feel it in your gut. Of course, this is a by-product
of the way you were raised. Either you are taught about common courtesies
or you aren't. Application of the Golden Rule is pretty easy.

If you feel that MTU path discovery is inconsiderate, then I suppose you
should take action that let's you sleep at night. It certainly wouldn't
bug me.

In the end, no one will ever agree on where the line is drawn. This
discussion is dragging on needlessly.

Signing off,

Dave

12

We aren't talking about 5 ping packets as part of path MTU discovery.
We aren't even talking about 5 ping packets sent as part of a ping
triangulation in response to an http request.

We're talking about intentional measurement of a network, on a scale large
enough to concern a network administrator.

The *original* posting was regarding 441 packets in two hours. That's WELL
within the "as part of PMTU" or "triangulation" level. Remember that simple
PMTU discovery is "measurement of a network" too. My point is simply that
some people have a concept of "scale large enough to concern" that needs to
be re-evaluated in today's Internet.

People are just going to have to get used to the idea that in the future,
there will likely be a 5% or 10% of overhead packets for any content transfer.
Remember that IPv6 specifies PMTU Discovery as required, so you'll be seeing
more of that in the future.

Also, people are *vastly* overstating the "but Akamia/Digital Island./etc
will fail to scale". Let's THINK about it for a moment:

1) If nobody from your site is contacting the provider in question, you
don't see traffic - it's not worth it to them to probe if there's no
traffic. As the original note from Digital Island said:

Our network was pinging your system because it appeared to be a name
server with a sufficient number of resolution requests for our
customer web sites to be placed on the list of network nodes to be
constantly observed for Internet congestion.

OK? See? You don't *get* probed until the traffic is ALREADY at a threshold
high enough that it's worth it. And that makes sense - 15 measurement
packets for a 10-packet flow is just plain stupid. You dont want to measure
until you have enough traffic to make it worth it.

2) If there *is* traffic sufficient to make it worth it, any intelligent
measurement system will re-use the values for your net for every ADDITIONAL
user - making it scale BETTER.

So... let's say *everybody* deployed something like this. Let's say
I start watching the traffic out of our 2 /16s. One of a VERY few things
will happen:

a) The other end has such a system, but our 2 /16s dont talk to it often
enough to make it worth it. This has infinite scaleability.

b) For *each* site we contact that *does* have enough traffic to make it
worth it, we incur measurement. This *still* scales better than the actual
traffic, because once we pass the threshold, our pipe has to get fatter
to handle the data, but the measurement traffic is fixed. So (for instance)
if the threshold is "enough traffic that measurement is 4% overhead", if our
traffic doubles, the overhead is now 2%. This scales.

The bottom line is that if you operate with just 2 rules:

1) You don't do measurement until you have a critical mass of traffic from
one prefix, so the overhead at that traffic level is a known "reasonable"
amount (say, 2% - it can't be TOO high in any case, simply because you don't
want measurement traffic swamping any gains you make).

2) You use the measurement for *all* traffic from the prefix.

you can easily show that for *any* amount of traffic, you will never go over
the overhead listed in 1.

So what was the "it doesn't scale" issue again?