[100946] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

RE: Creating a crystal clear and pure Internet

daemon@ATHENA.MIT.EDU (Fred Reimer)
Tue Nov 27 10:22:50 2007

Date: Tue, 27 Nov 2007 10:18:47 -0500
In-Reply-To: <Pine.GSO.4.64.0711270928320.13074@clifden.donelan.com>
From: "Fred Reimer" <freimer@ctiusa.com>
To: "Sean Donelan" <sean@donelan.com>, <nanog@merit.edu>
Errors-To: owner-nanog@merit.edu


This is a multipart message in MIME format.

------=_NextPart_000_0058_01C830DE.E5CEAFE0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

No offense, but I think this is an overly political topic, and we
just saw that politics are not supposed to be discussed.  There
is a huge political debate on what ISP's should and should not be
doing to traffic that flows through their systems.  There are
other groups, like NNsquad, where these types of conversations
are welcome, but even there on the forums, not the mailing list.

But, if it's not viewed as political then...

Your analogy is flawed, because the Internet is not a pipe system
and ISP's are not your local water utility.  And, there are many
different ways that water utilities are handled in different
parts of the world.  In the US, most if not all water utilities
are handled by the government, usually the county government
where I'm from.  ISP's are not government run, and can't be
compared to a water utility for that simple reason.  They don't
have the same legal (again, an issue that is not supposed to be
discussed, according to the AUP) requirements nor the legal
protections available to governments (you can't sue most
governments).

And my personal opinion is that ISP's should not do anything to
the traffic that passes through their network as far as
filtering.  The only discriminatory behavior that should be
allowed is for QoS, to treat specific types or traffic in a
different manner to give preferential treatment to specific
classifications of traffic.  My definition of QoS for the
purposes of this discussion, if it is allowed to continue, would
not include shaping or policing.  If an ISP says you have a 5Mb
downstream and a 512K upstream, you should actually be allowed to
send 512K upstream all the time.  However, that's not to say that
an ISP should not be able to classify traffic as scavenger over a
particular threshold, and preferentially drop that traffic at
their overprescribed uplink if that is a bottleneck.  The end
user should also be allowed to specify their own QoS markings,
and they should be honored as long as they don't go over specific
thresholds as imposed, and documented, by the ISP.  For example,
the customer should be able to self-classify certain traffic as
high priority (VoIP) and certain as low (P2P), but if the
customer classified all traffic as high priority the ISP is free
to remark anything over a set threshold (say 128K) as a lower
priority, but NOT police it.

If you want to use an analogy, ISP's are more like >private< road
systems and owners, using >public< lands that have been given a
right to use said >public< lands for >private< profits with
specific restrictions.  Some restrictions may be that you can't
discriminate on the payload (and kind of identifying category for
passengers, such as race, ethnicity, gender, etc, which in the
network world would map to type of protocol or payload content,
such as P2P traffic or email), but that you can create an HOV
lane for high occupancy vehicles (QoS).  Of course, ISP's are
allowed to make sure the vehicles are in proper working condition
(checking that various layer headers are in compliance).  Much
like with the self-marking of traffic with QoS tags, the customer
should also be able to make their own decision and pack two other
people in the car in order to get into that HOV lane.  However,
if the users of the road try and pack everything into the HOV
lane, they can be reclassified (busses may have to pay a higher
fee to use the road).

However, in this world of religious warfare (another banned
topic, I'm sure!) it is recognized that a certain level of
profiling is acceptable.  So, it may be O.K. for ISP's to profile
and deny traffic depending on the payload only for specific types
of traffic that have been shown to cause issues, and/or only be
present for nefarious reasons.  Examples may be known signatures
for virus attacks, worms, or Trojans.  Other examples may be
identifying characteristics for SPAM (I'm reluctant to say
"excessive email traffic" because I don't believe that is a
proper identifying characteristic, I should be able to run my own
SMTP server and send out as much legitimate email as I want).

I realize that my views probably won't be shared by the vast
majority of ISP's, and hence are overly political for this group.
That's why I think any discussion is not necessarily on-topic.

Thanks,

Fred Reimer, CISSP, CCNP, CQS-VPN, CQS-ISS
Senior Network Engineer
Coleman Technologies, Inc.
954-298-1697



> -----Original Message-----
> From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]
> On Behalf Of Sean Donelan
> Sent: Tuesday, November 27, 2007 9:39 AM
> To: nanog@merit.edu
> Subject: Creating a crystal clear and pure Internet
> 
> 
> 
> Some people have compared unwanted Internet traffic to water
> pollution,
> and proposed that ISPs should be required to be like water
> utilities and
> be responsible for keeping the Internet water crystal clear
> and pure.
> 
> Several new projects have started around the world to
> achieve those goals.
> 
> ITU anti-botnet initiative
> 
> http://www.itu.int/ITU-
> D/cyb/cybersecurity/projects/botnet.html
> 
> France anti-piracy initiative
> 
> http://www.culture.gouv.fr/culture/actualites/index-
> olivennes231107.htm

------=_NextPart_000_0058_01C830DE.E5CEAFE0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII0jCCAlow
ggHDoAMCAQICEDgc4bZh+DFAeNH3ZafQrNkwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx
JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ
ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MTExMzIyNTA0MloXDTA4MTExMjIyNTA0
MlowRDEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEhMB8GCSqGSIb3DQEJARYSZnJl
aW1lckBjdGl1c2EuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDG7T14kRf/E/jhYP46
xx95dcE0oAfYjhgzmGfX1qE684Gv0euprLFwA3yAi5DD3NPEAT27ybC0yt6jKDfcG/RttPMuaYff
hFCail9at7Ks+IJ3k3qxXIUL1NfTvCBVcaZQIKG1f1ixnswU5EG0b1BrZFK+h+zBYrQSyPweI723
6wIDAQABoy8wLTAdBgNVHREEFjAUgRJmcmVpbWVyQGN0aXVzYS5jb20wDAYDVR0TAQH/BAIwADAN
BgkqhkiG9w0BAQUFAAOBgQBXNff7f5oxFCz14HLPRfXkvtD3Iu6t+fQUktfOO9dfSF8FVke46Y1S
jIyQOvFYrR8I/EYGfFeKFCYWvWja5jndOSwSdfHSnhwWzWjCIkA7zkd34wXlr5HZrfj8LPqximQa
D47IyB6xINI+R2FDzqKCdx5b0NtXa4u2JcqLm40ahTCCAy0wggKWoAMCAQICAQAwDQYJKoZIhvcN
AQEEBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNh
cGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp
b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBD
QTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw05NjAxMDEw
MDAwMDBaFw0yMDEyMzEyMzU5NTlaMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD
YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYD
VQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVy
c29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0
ZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANRp19SwlGRbcelH2AxRtupykbCEXn0t
DY97Et+FJXUodDpCLGMnn5V7S+9+GYcdhuqj3bnOlmQawhRuRKx85o/oTQ9xH0A4pgCjh3j2+ZSG
Xq3qwF5269kUo11uenwMpUtVfwYZKX+emibVars4JAhqmMex2qOYkf152+VaxBy5AgMBAAGjEzAR
MA8GA1UdEwEB/wQFMAMBAf8wDQYJKoZIhvcNAQEEBQADgYEAx+ySfk749ZalZ2IqpPBNEWDQb41g
WGGsJrtSNVwIzzD7qEqWih9iQiOMFw/0umScF6xHKd+dmF7SbGBxXKKs3Hnj524ARx+1DSjoAp3k
mv0T9KbZfLH43F8jJgmRgHPQFBveQ6mDJfLmnC8Vyv6mq4oHdYsM3VGEa+T40c53ooEwggM/MIIC
qKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVy
biBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgw
JgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUg
UGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRo
YXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTEl
MCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl
cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSm
PFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnw
K4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e2
0TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDig
NqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDAL
BgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0G
CSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQc
UCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u
9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIC+DCCAvQCAQEwdjBiMQswCQYDVQQGEwJa
QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl
IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEDgc4bZh+DFAeNH3ZafQrNkwCQYFKw4DAhoF
AKCCAdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcxMTI3MTUx
ODQ3WjAjBgkqhkiG9w0BCQQxFgQUeyh6ckWML4segTDnd+/4hllm8gAwZwYJKoZIhvcNAQkPMVow
WDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkG
A1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA4HOG2YfgxQHjR92Wn0KzZMIGH
BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0
aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n
IENBAhA4HOG2YfgxQHjR92Wn0KzZMA0GCSqGSIb3DQEBAQUABIGAGiTf6wKUkL+lEvBLyi7kKEwV
2gWSerFVN416rCRoGR7wsdKe/Pc+EKYWLk9BZcfTMhwRKt2ul62vn1GtkDHpLtoqJZuAsRF313zc
kqnhmNZIye63jBlnchyi9ov0pik/QSqc+r/WROSa71G0ikKwBeVo9xt5Oksna28ET1zZN1YAAAAA
AAA=

------=_NextPart_000_0058_01C830DE.E5CEAFE0--


home help back first fref pref prev next nref lref last post