Violation of Acceptable Use Policies

Almost every major Internet provider's acceptable use policy prohibits
the sending of unsolicited bulk e-mail. ISPs have been encouraged to
terminate the accounts of people who engage in the sending of unsolicited
bulk e-mail. Several third-party groups maintain RBL's of groups which
send unsolicited bulk e-mail.

http://www.cnn.com/2003/WORLD/meast/01/11/sproject.irq.email/index.html

Which ISP gets to tell the US Military their connection is being pulled
because Iraq complained about unsolicited bulk e-mail?

I'll be more interested in seeing what the military does when people start
mass spamming US military addresses (doesn't every us soldier/sailor/airman
have an email address? I seem to remmeber that they do for contact with
relatives).

It would be pretty easy for someone to pay a spammer (probably outside the
US) to mail a million US military addresses with interesting stuff on US
foreign policy, warcrimes regulations and zionist conspiricies. Even
the URLs for a few mainstream European newspapaers' websites might be
useful.

Not to mention the "Anthrax in NYC, News blackout" type of chain letter
spreading panic.

I thought the US tried to avoid using tactics which it was more vulnerable
to? This was originally why there was a ban on assassinations.

ObOperational: Does anyone have a pointer to "war footing" practices?
Things like gaving prepared links to News websites, reduced maintenance,
rumor control and the like?

BTW: New Zealand does have soldiers fighting in Afganistan and had peace
keepers in East Timor so that chances of us being directly targetted
(NZers were killed in a Bali bombing) are good.

Which ISP gets to tell the US Military their connection is being pulled
because Iraq complained about unsolicited bulk e-mail?

Genuity? :slight_smile:

traceroute to www.defenselink.mil (131.84.1.60), 30 hops max, 40 byte
packets

<snip>
15 p2-0.vienna1-nbr2.bbnplanet.net (4.24.4.214) [AS1] 12 ms 13 ms 17 ms
16 p1-0.vienna1-cr7.bbnplanet.net (4.0.2.146) [AS1] 18 ms 13 ms 12 ms
17 * * *
18 * * *

Jeffrey Meltzer wrote:

Genuity? :slight_smile:

traceroute to www.defenselink.mil (131.84.1.60), 30 hops max, 40 byte
packets

<snip>
15 p2-0.vienna1-nbr2.bbnplanet.net (4.24.4.214) [AS1] 12 ms 13 ms 17 ms
16 p1-0.vienna1-cr7.bbnplanet.net (4.0.2.146) [AS1] 18 ms 13 ms 12 ms
17 * * *
18 * * *

Perhaps you need to "improve" your traceroute? :wink:

FFT: Tracing route to www.defenselink.mil
Hop FFT trace to dod.gov (131.84.1.60):
1 ln-gateway.centergate.com (206.117.161.1) 127.7ms
2 isi-acg.ln.net (130.152.136.1) 187.0ms
3 isi-1-lngw2-pos.ln.net (130.152.80.30) 2.2ms
4 ge-2-3-0.a02.lsanca02.us.ra.verio.net (198.172.117.161) 2.8/*ms
5 xe-1-0-0.r21.lsanca01.us.bb.verio.net (129.250.29.136) 3.0ms
6 p16-1-1-0.r21.snjsca04.us.bb.verio.net (129.250.2.187) 11.1ms
7 p16-1-1-2.r21.plalca01.us.bb.verio.net (129.250.2.198) 11.6ms
8 p16-1-0-0.r00.plalca01.us.bb.verio.net (129.250.3.85) 11.5ms
9 p4-0.uunet.plalca01.us.bb.verio.net (129.250.9.98) 16.6ms
10 0.so-2-0-0.XL1.SAC1.ALTER.NET (152.63.52.250) 16.5ms
11 0.so-3-0-0.TL1.SAC1.ALTER.NET (152.63.53.250) 16.3ms
12 0.so-1-1-0.TL1.DCA6.ALTER.NET (152.63.1.117) 93.6ms
13 0.so-2-2-0.XL1.DCA8.ALTER.NET (152.63.41.137) 93.5ms
14 POS6-0.GW2.DCA8.ALTER.NET (152.63.39.173) 93.4ms
** [neglected] no reply packets received from TTLs 15 through 16
17 [target] dod.gov (131.84.1.60):80 94.7ms

FFT's trace took 13.67 seconds. Resolution required 0.53 seconds.

Rodney Joffe wrote:

> 16 p1-0.vienna1-cr7.bbnplanet.net (4.0.2.146) [AS1] 18 ms 13 ms 12 ms

                         ^^^^^^^^^

Perhaps you need to "improve" your traceroute? :wink:

14 POS6-0.GW2.DCA8.ALTER.NET (152.63.39.173) 93.4ms

                       ^^^^^
Doh. Sorry. Failed to pay attention. Must try harder.

Oddly enough, from Oregon route-views:

BGP routing table entry for 131.84.0.0/16, version 26724
Paths: (50 available, best #41)
  Not advertised to any peer
  267 2914 1 140
    204.42.253.253 from 204.42.253.253 (204.42.253.253)
      Origin IGP, metric 2, localpref 100, valid, external
      Community: 267:2914 2914:420 2914:2000 2914:3000
  4513 701 140
    195.66.224.82 from 195.66.224.82 (209.10.12.222)
      Origin IGP, metric 23302, localpref 100, valid, external
  8297 6453 701 140
    195.219.96.239 from 195.219.96.239 (195.219.96.239)
      Origin IGP, localpref 100, valid, external
  3257 1 140
    213.200.87.254 from 213.200.87.254 (213.200.87.40)
      Origin IGP, metric 910, localpref 100, valid, external
  9942 1 140
    203.194.0.5 from 203.194.0.5 (203.194.0.5)
      Origin IGP, localpref 100, valid, external
      Community: 9942:120 9942:204 9942:8060
  16150 8434 3257 1 140
    217.75.96.60 from 217.75.96.60 (217.75.96.60)
      Origin IGP, localpref 100, valid, external

As reported at the Sprint 2002 NANOG I was the working group lead for the
ISP disaster recovery working group. We prepared a document on steps
ISPs should take in preparation for a disaster, but its not generally
available. However, the paper really didn't contain any surprises.

Around the world ISPs have learned how to operate in the middle of wars
and unrest over the last 10 years. B92 in the former Yugoslavia was one
of the more vocal ISPs operating during a military conflict. EUnet and
other ISPs were also active through much of the conflict. There are
several other continuing conflicts around the world which don't reach the
level of full scale military action.

One of the few publically available documents about operating a
public network during a disaster is

ANSI T1.202-1998 Internetwork Operations Guidelines for Network Management
of the Public Switched Networks under Disaster Conditions

These guidelines encompass the cooperative intercompany network
management actions (that may be) required during emergency conditions
associated with disasters that threaten life or property and cause
congestion in the public switched networks (PSNs). Network management
actions should optimize the integrity of the PSNs while obtaining the
maximum use of the network capability during a disaster condition. These
guidelines address the network actions required to relieve congestion in
the PSN caused by failures resulting from the disaster conditions.
Examples of disaster conditions that would benefit from these guidelines
are: natural disasters (such as hurricanes, earthquakes, floods, and the
like), major accidents (such as transportation, industrial, or
environmental), or civil disturbances (such as terrorist acts or other
similar events).

:Around the world ISPs have learned how to operate in the middle of wars
:and unrest over the last 10 years. B92 in the former Yugoslavia was one
:of the more vocal ISPs operating during a military conflict.

Not to nitpick, but the entire B92 AS disappeared off the network
for the duration of the conflict about 2-3 weeks before the
ceasefire. Weren't they disconnected on order of the police? (If
memory serves).

:EUnet and
:other ISPs were also active through much of the conflict. There are
:several other continuing conflicts around the world which don't reach the
:level of full scale military action.

It's hard to tell how well they stood up, most notably Beotel.
We (Will Waites and I) watched for route withdrawals from AS's
registered in the Belgrade area, and due to aggregation, it was
very difficult to tell whether any of them were actually reachable
using BGP information alone. The one notable change we saw was the
withdrawal of all of B92's routes and didn't see them come back
up, though we stopped moniting when the bombing stopped, as we
were just trying to corelate route withdrawals and CNN bombing
reports.

So, from what we saw the Internet fared fairly well in Belgrade, however,
without IGP information, or pings of actual hosts, this is still up for
debate.

Not to nitpick, but the entire B92 AS disappeared off the network
for the duration of the conflict about 2-3 weeks before the
ceasefire. Weren't they disconnected on order of the police? (If
memory serves).

They were up and down a few times, but mostly they were very vocal. They
weren't a facilities based provider, so when the PTT shut off their
circuit they seemed to pop back up somewhere else several times.

So, from what we saw the Internet fared fairly well in Belgrade, however,
without IGP information, or pings of actual hosts, this is still up for
debate.

Cheswick had some more data showing networks going offline througout the
conflict.

What was interesting wasn't networks went down. But how quickly people
were able to use whatever facilities which were still working to bring
up some service. Satellite, fiber, copper, dial, etc.