[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [dccp] dccp spec expert review (Minshall, main spec)
Hi Greg, list,
On to half-open connections. This was a great catch, thanks for bringing it
up. Does anyone see any bugs in the following proposed solution?
(For those coming late, the half-open connection problem is where one
endpoint thinks the connection is open and the other thinks the connection
is closed, because it has rebooted or otherwise shut connection state.)
> the "half-open" connection dance is one of the subtlest in TCP. Figure 10,
> page 34, of RFC793, shows how it works. it may be that all the steps of the
> tango are not necessary, though it's always seemed to me that they are.
>
> i *think* you want to think carefully about this, and make sure it works in
> DCCP. it isn't clear to me that it works, but i may be missing something.
DCCP as specified does have problems with respect to half-open connections,
but I think some simple changes will make everything work.
TCP handles half-open connections as follows, depending on the TCB state,
and ignoring security and precedence.
1. In CLOSED state, it responds to any segment with a RST.
2. In an "unsynchronized" state (LISTEN, SYN-SENT, or SYN-RECEIVED), it
responds to unexpected segments (i.e. segments with invalid sequence
numbers) with a RST.
3. In a "synchronized" state (ESTABLISHED et al), it responds to unexpected
segments with an ACK acknowledging the last valid sequence number.
This leads to sequences like the following [RFC 793], where A crashes and
tries to reopen a connection that B thinks is open already.
TCP A TCP B
1. (CRASH) (send 300,receive 100)
2. CLOSED ESTABLISHED
3. SYN-SENT --> <SEQ=400><CTL=SYN> --> (??)
4. (!!) <-- <SEQ=300><ACK=100><CTL=ACK> <-- ESTABLISHED
5. SYN-SENT --> <SEQ=100><CTL=RST> --> (Abort!!)
6. SYN-SENT CLOSED
7. SYN-SENT --> <SEQ=400><CTL=SYN> -->
Now, DCCP handles a packet with an "invalid" sequence number by sending an
Ack that acknowledges GSN, the greatest valid sequence number received.
This is exactly analogous to TCP's behavior in a synchronized state.
Packets with "valid" sequence numbers are treated according to the table in
Section 5.3.
A sequence number is valid iff it lies within a Loss Window of GSN. This
leads to the first problem. What about unsynchronized states, namely
CLOSED, LISTEN, and REQUEST? What sequence numbers are valid here? Let us
say that *all* packets are processed according to the Section 5.3 table in
those states. (In fact, this was sort of implicit in the text already, in
that no other approach would make sense.)
The second problem is that in Section 5.3, the "Rst" action does not say
what sequence number should be used on the sent Resets. TCP uses the
invalid segment's Acknowledgement Number, but that won't work for us, since
some DCCP packets have no Acknowledgement Number. Instead, let us say that
the Resets have Sequence Number 0, and redefine sequence number validity so
that Resets with Sequence Number 0 are valid iff their Acknowledgement
Numbers are valid.
That essentially brings us to TCP's state of affairs. For instance, the
example above would work as follows in DCCP:
DCCP A DCCP B
1. (CRASH) (send 300,receive 100)
2. CLOSED OPEN
3. REQUEST --> <Request SEQ=400> --> (??)
4. (!!) <-- <Ack SEQ=300 ACK=100> <-- OPEN
5. REQUEST --> <Reset SEQ=0 ACK=300> --> (Abort!!)
6. REQUEST CLOSED
7. REQUEST --> <Request SEQ=401> -->
The other examples in the TCP RFC look like this:
DCCP A DCCP B
1. (CRASH) (send 300,receive 100)
2. (??) <-- <Data SEQ=300> <-- ESTABLISHED
3. --> <Reset SEQ=0 ACK=300> --> (ABORT!!)
Active Side Causes Half-Open Connection Discovery
DCCP A DCCP B
1. LISTEN LISTEN
2. ... <Request SEQ=Z> --> SYN-RECEIVED
3. (??) <-- <Response SEQ=X ACK=Z> <-- SYN-RECEIVED
4. --> <Reset SEQ=0 ACK=X> --> (return to LISTEN!)
5. LISTEN LISTEN
Old Duplicate SYN Initiates a Reset on two Passive Sockets
These changes protect us against most stray packets, but we can do a little
better still by redefining sequence number validity for some states. For
example, in the REQUEST state, a DCCP-Response that does not acknowledge
one of our Requests is invalid, aside from any Loss Window.
Here are some other changes all this leads to:
* Section 5.2 says that DCCP MAY ignore invalid packets, and MAY send an
rate-limited Ack. This should change to SHOULD send a rate-limited Ack.
* Section 5.2 might specify that, at the start of a connection, the Loss
Window should not include packets before the first sequence number received
from the other party.
* Section 5.3 should say that all packets are processed according to the
table in states CLOSED, LISTEN, and REQUEST.
* Section 5.3 should specify which sequence numbers are valid in REQUEST
and RESPOND states.
* The table in Section 5.3 says that the server in OPEN or SERVER-CLOSE
state should respond to new DCCP-Requests with valid sequence numbers with
DCCP-Reset packets. This is not different from TCP's behavior -- if a SYN
arrives inside a window, the connection should be aborted. But we could
conceivably treat such packets as "invalid" instead, and respond with
rate-limited Acks.
Thanks again,
Eddie
_______________________________________________
dccp IETF mailing list: dccp@ietf.org
list info: https://www1.ietf.org/mailman/listinfo/dccp
wg charter: http://www.ietf.org/html.charters/dccp-charter.html