NNSquad - Network Neutrality Squad
[ NNSquad ] Re: Speculation, how AT&T can implement "copyright filtering" and far far worse
Richard Clarke was at NN2008 -- he's at the intersection of ATT and Homeland security http://www.truthnews.us/?p=136. If you search you'll find out that he's traveled with this baggage and, perhaps, at ATT his mission meets ability to implement. Be afraid, very afraid. Better, be happy, very happy. Don't think dark thoughts and far more important, don't express your fears lest ... Too bad NN2008 treated him very gently. -----Original Message----- From: nnsquad-bounces+nnsquad=bobf.frankston.com@nnsquad.org [mailto:nnsquad-bounces+nnsquad=bobf.frankston.com@nnsquad.org] On Behalf Of Xetheriel Angelknight Sent: Thursday, January 31, 2008 21:32 To: Warren Kumari Cc: Kevin McArthur; nnsquad@nnsquad.org; Cliff Sojourner Subject: [ NNSquad ] Re: Speculation, how AT&T can implement "copyright filtering" My issues with any and all of this are 2 fold: 1. Third parties (Music Industry, Movie Industry, etc) trying to force the ISP's to become internet police. 2. ISP's trying to leverage throttling/shaping/etc to make a quick buck off of content providers and/or customers. ISP's have a responsibility, one that has always remained the same: Provide the service you claim to offer, at the speed you claim to offer. ISP's should now, and always be common carriers. Gun Manufacturers are not required to regulate who gets to buy or use guns, so why should ISP's have to police the internet? My 2 cents. On Jan 31, 2008 8:09 PM, Warren Kumari <warren@kumari.net> wrote: > > On Jan 31, 2008, at 12:57 PM, Brett Glass wrote: > > > At 11:04 PM 1/30/2008, Cliff Sojourner wrote: > > > >> it's really simple, don't mess with my bits, or else you are liable > >> for the content. > > > > With all due respect, this is simply not true. Merely by looking at > > the headers, without knowing the content of the packets, a provider > > can tell that you are violating the contract you made with it. And > > it has absolutely every right to enforce that contract. > > > >> don't mess with my bits means no packet forgery, > > > > A RST packet is not "forgery." > > A RST packet *is* a forged packet if the source IP address in the > packet is not an IP address of the machine that generated the packet... > > > Remember, a TCP session is identified by a tuple consisting of a > > source address (the source of the initial SYN), the destination > > address (the destination of the initial SYN), and the port numbers > > used by the two communicating processes. The protocol provides no > > other way of identifying that specific connection or issuing a > > command telling the participants to terminate it. > > Um, yes, thats kinda the whole point, isn't it? The protocol was > designed so that the endpoints are the only devices that need to > understand connection state, or cause a transition in state... RFC793 > lists the situations that should trigger the sending of a RST packet > -- basically they can be summarized as "you get a packet that is not > valid in the current context of the state machine" (the packet refers > to a connection that is not fully open, the sequence number lies > outside the window, you determine that your own state machine is > inconstant, etc. The reception of a packet that had an incorrect > "security level, or compartment, or precedence" used to also cause a > transition to reset state, but that was relaxed in some .) > > > Quoting from RFC793 (Section 3.4. Establishing a connection, Page 35): > > Reset Generation > > As a general rule, reset (RST) must be sent whenever a segment > arrives > which apparently is not intended for the current connection. A reset > must not be sent if it is not clear that this is the case. > > > A RST packet is a legitimate way of terminating a connection which > > violates the provider's terms of service. > > > While protocols have evolved over time, I know of nothing that says > that an intermediate system (or other) can send an RST to signal that > a session should be torn down. > > Claiming that forging a RST is a "legitimate" way of terminating a > connection is like saying that holding someone up with a gun is a > legitimate way of making money... Just because it works doesn't make > it right... > > > W > > > > > >> and no disruption of payload bits. > > > > It's perfectly legitimate to change the payload when doing caching, > > when inserting an announcement for the users, and for many other > > reasons. Our ISP's terms of service, to which all our users agree, > > explicitly grant us permission to do this. > > > >> providers can shape the traffic, according to our agreed terms of > >> service, but they must be clearly stated and agreed to. you can > >> not shape by source or destination. > > > > Why not? Limiting the rate of traffic from spammers or abusers is a > > good thing. > > > >> tell me again, what is all the discussion about? > > > > Apparently, it is about attempts to regulate the Internet. Not by > > providers, but by third parties who would like to regulate and > > micromanage ISPs. > > > > --Brett Glass > > > >