[Spud] Comments on draft-hildebrand-spud-prototype-03

[Tom Herbert <[e-mail]>]

Hi Joe,

I was looking at the state machine in the SPU prototype protocol,
especially with regards of how a TCP connection might be mapped to it.
Here are a few comments.

1. For a session it seems like one side is delegated to be the
initiator. The initiator sends the open and sets the session ID which
is reflected by it's peer. We can use an additional bit in the header
to indicate if the sender (source IP address) is the initiator or not.
2. Assuming that there is a clear initiator, the state machine
viewpoint can always be from the initiator and then is common for both
endpoints and any intermediate nodes. So there shouldn't be a need to
consider active or passive opens, or simultaneous opens. sopen would
just be open, and the transition from unknown to running would not be
needed..
3. If the underlying protocol does allow simultaneous opens so that
two sessions are created, presumably some method would be needed by
the underlying protocol to select which session to use for the
connection and close the session.
4. I think there should be an additional opening state. With transition flow:

  1) When open is seen from initiator, go to first opening state.
  2) When open-ack is seen from peer, go to second opening state.
  3) When open-ack is seen from initiator, go to running.

This then matches the completion 3WHS of TCP. For instance, in a SYN
attack the created session states would only get to the second open
state (assuming SYN=>open and then SYN-ACK=>open-ack), so this way we
can differentiate these with sessions with the ones fully established
ones in the underlying protocol.

Thanks,
Tom