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
