CogentCo

Mon Nov 18 20:50:49 UTC 2002

On Mon, 18 Nov 2002 14:46:51 -0500 (EST), Mike (meuon) Harrison wrote:

>It also appears to block Gnutella and similar protocols.

	You should never sign an IP access agreement that doesn't give you access to 
the filtering rules that affect your traffic. Ideally, you should strongly 
avoid agreements that don't let you opt out of filtering you don't want.

	Here's the type of language we typically insist on. If a provider won't 
agree to this type of language, odds are very high they plan to filter your 
in strange ways or aren't serious about providing business-class IP services.

1) XXXXXX agrees to provide YYYYYYYY with information about any filtering
rules that apply to traffic to or from YYYYYYYY. Such information shall
include a precise description of what types of traffic the filter affects.

2) Where possible, XXXXXX agrees to provide YYYYYYYY with 2 business days
advanced notice to any planned filtering changes. In the event that XXXXXX
makes an emergency or expedited filtering change that affects traffic to or
from YYYYYYYY, XXXXXX agrees to notify YYYYYYYY as soon as practical.

3) In the event XXXXXX makes a filtering change that affects traffic to or
from YYYYYYYY, and such change is not justified by technical necessity or
emergency, XXXXXX agrees to, at YYYYYYYY's request, either remove the filter 
or exempt traffic to and from YYYYYYYY's network from the filter.

To qualify as an emergency filter, a filter must be temporary. Technical 
necessity includes, but is not limited to, the following types of
filtering:

A) Dropping packets with invalid source addresses. This would include
RFC1918 or unassigned addresses.

B) Dropping packets at the request of the originator or recipient of those
packets.

The following types of filtering are not considered technical necessity:

A) Blocking specific ports or protocols because an exploit or attack might
use them in the absence of knowledge of a specific attack source or
destination. This would including blocking a particular TCP or UDP port in
response to its being used by a trojan or probe.

B) Blocking specific types of packets (by port or protocol) even though they
are technically valid IP packets with valid source and destination addresses
for purposes of disabling particular applications or protocols. This would
include, for example, blocking packets with an IP type of 255 (raw IP).

	A dialup account is one thing. But 100Mbps business-class access is another 
story. You should know exactly what's happening to *your* traffic.

	DS