[IP] Re: RST packets as good network management

[David Farber <dave@farber.net>]

________________________________________
From: Valdis.Kletnieks@vt.edu [Valdis.Kletnieks@vt.edu]
Sent: Thursday, April 24, 2008 12:15 PM
To: David Farber
Cc: ip
Subject: Re: [IP] Re: RST packets as good network management

On Thu, 24 Apr 2008 08:11:47 PDT, Brett Glass said:

> As a longtime programmer, network architect, and system
> administrator (in other words, not just a theorist but someone who
> actually runs networks), I must disagree with this statement, which
> uses a loaded term ("forgery") and is inappropriately pejorative.
>
> Firstly, our dialup routers always send out RST packets on existing

<a number of very true comments regarding the actual use of RST packets>

> In short, sending back a RST packet has been around for many, many
> years and is a standard action of a firewall.

The part that Brett glosses over is that, in general, these *proper* uses
of RST fall into two classifications:

1) In the case of firewalls and similar appliances, the RST is issued by
a piece of hardware under the same administrative control as the device on
whose behalf the RST is being issued.  It's *my* firewall, and *my* device,
so I presumably have authorized the firewall to issue packets on behalf
of my device.

2) In the case of "dialup router issues RST for departed connections",
the device issuing the RST is able to *definitively* say "No, that connection
is no longer operational because an endpoint has gone away".

In the problematic case, Comcast is issuing RST when neither of the above
are true - the connection is from a machine administered by the end user,
not Comcast, and to another machine not administered by Comcast (in other
words, if Comcast was issuing an RST for a connection to a Comcast-owned
server, that would be OK, but it's not).  Additionally, Comcast is issuing
the RST when it knows full well the connection is still valid (in fact, if
Comcast knew the connection to be deceased, it wouldn't be bothering to
send the RST).

Or to cite RFC793:

  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.

  There are three groups of states:

    1.  If the connection does not exist (CLOSED) then a reset is sent
    in response to any incoming segment except another reset.  In
    particular, SYNs addressed to a non-existent connection are rejected
    by this means.

(This is the "dialup router issues a RST for a dead connection" scenario)

    If the incoming segment has an ACK field, the reset takes its
    sequence number from the ACK field of the segment, otherwise the
    reset has sequence number zero and the ACK field is set to the sum
    of the sequence number and segment length of the incoming segment.
    The connection remains in the CLOSED state.

    2.  If the connection is in any non-synchronized state (LISTEN,
    SYN-SENT, SYN-RECEIVED), and the incoming segment acknowledges
    something not yet sent (the segment carries an unacceptable ACK), or
    if an incoming segment has a security level or compartment which
    does not exactly match the level and compartment requested for the
    connection, a reset is sent.

(This arguably covers firewalls and other filters)

    If our SYN has not been acknowledged and the precedence level of the
    incoming segment is higher than the precedence level requested then
    either raise the local precedence level (if allowed by the user and
    the system) or send a reset; or if the precedence level of the
    incoming segment is lower than the precedence level requested then
    continue as if the precedence matched exactly (if the remote TCP
    cannot raise the precedence level to match ours this will be
    detected in the next segment it sends, and the connection will be
    terminated then).  If our SYN has been acknowledged (perhaps in this
    incoming segment) the precedence level of the incoming segment must
    match the local precedence level exactly, if it does not a reset
    must be sent.

    If the incoming segment has an ACK field, the reset takes its
    sequence number from the ACK field of the segment, otherwise the
    reset has sequence number zero and the ACK field is set to the sum
    of the sequence number and segment length of the incoming segment.
    The connection remains in the same state.

    3.  If the connection is in a synchronized state (ESTABLISHED,
    FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT),
    any unacceptable segment (out of window sequence number or
    unacceptible acknowledgment number) must elicit only an empty
    acknowledgment segment containing the current send-sequence number
    and an acknowledgment indicating the next sequence number expected
    to be received, and the connection remains in the same state.

    If an incoming segment has a security level, or compartment, or
    precedence which does not exactly match the level, and compartment,
    and precedence requested for the connection,a reset is sent and
    connection goes to the CLOSED state.  The reset takes its sequence
    number from the ACK field of the incoming segment.

Hmm.. I still haven't seen a spot where Comcast's behavior is allowed....

-------------------------------------------