Created a new section 4.4.5 specifically addressing the issue, and trimmed
associated text in 4.3.2/5.3.3/6. The new section is as follows:

4.4.5.  Routing State Failures

   A GIST node can receive a message from a GIST peer, which can only be
   correctly processed in the context of some routing state, but where
   no corresponding routing state exists.  Cases where this can arise
   include:

   o  Where the message is random traffic from an attacker, or
      backscatter (responses to such traffic).

   o  Where routing state has been correctly installed but the peer has
      since lost it, for example because of aggressive timer settings at
      the peer, or because the node has crashed and restarted.

   o  Where the routing state has never been correctly installed in the
      first place, but the sending node does not know this.  This can
      happen if the Confirm message of the handshake is lost.

   It is important for GIST to recover from such situations promptly
   where they represent genuine errors (node restarts, or lost messages
   which would not otherwise be retransmitted).  Note that only
   Response, Confirm, Error and Data messages ever require routing state
   to exist, and these are considered in turn:

   Response:  A Response can be received at a node which never sent (or
      has forgotten) the corresponding Query.  If the node wants routing
      state to exist, it will initiate it itself; a diagnostic error
      would not allow the sender of the Response to take any corrective
      action, and the diagnostic could itself be a form of backscatter.
      Therefore, an error message MUST NOT be generated, but the
      condition MAY be logged locally.

   Confirm:  For a Responding node which implements delayed state
      installation, this is normal behaviour, and routing state will be
      created provided the Confirm is validated.  Otherwise, this is a
      case of a non-existent or forgotten Response, and the node may not
      have sufficient information in the Confirm to create the correct
      state.  The requirement is to notify the Querying node so that it
      can recover the routing state.

   Data:  This arises when a node receives Data where routing state is
      required, but either it does not exist at all, or it has not been
      finalised (no Confirm message).  To avoid Data being black-holed,
      a notification must be sent to the peer.

   Error:  Some error messages can only be interpreted in the context of
      routing state.  However, the only error messages which require a
      response within the protocol are routing state error messages
      themselves.  Therefore, this case should be treated the same as a
      Response: an error message MUST NOT be generated, but the
      condition MAY be logged locally.

   For the case of Confirm or Data messages, if the state is required
   but does not exist, the node MUST reject the incoming message with a
   "No Routing State" error message (Appendix A.4.4.5).  There are then
   three cases at the receiver of the error message:

   No routing state:  The condition MAY be logged but a reply MUST NOT
      be sent (see above).

   Querying node:  The node MUST restart the GIST handshake from the
      beginning.

   Responding node:  The node MUST delete its own routing state and
      SHOULD report an error condition to the local signalling
      application.

   The rules at the Querying or Responding node make GIST open to
   disruption by randomly injected error messages, similar to blind
   reset attacks on TCP (cf. [45]), although because routing state
   matching includes the SID this is mainly limited to on-path
   attackers.  If a GIST node detects a significant rate of such
   attacks, it MAY adopt a policy of using secured messaging
   associations to communicate for the affected MRIs, and only accepting
   "No Routing State" error messages over such associations.