[ NNSquad ] Re: Speculation, how AT&T can implement "copyright filtering"

[Warren Kumari <warren@kumari.net>]

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