The following is a proposed approach to addressing this issue.
Notionally, we should distinguish between two cases:
a) where the Responding node is already prepared to store per-flow state after
receiving a single (Query) message. This would include any cases where the node
has NSLP data queued to send.
b) where the responding node is not prepared to store per-flow state until
receiving a properly formed Confirm message.
In case (a), it is reasonable for the protocol to demand that the Responding
node runs a retransmission timer to resend the Response message until a Confirm
is received. The problem of the amplification attack should be handled by
requiring the cookie mechanism to enable the node receiving the Response to
discard it efficiently if it does not match a previously sent Query.
In case (b) (which is probably the more commonplace one where Confirm messages
are wanted at all), a retransmission timer should not be required. However, we
can assume that the next signalling message will be in the direction Querying
Node -> Responding Node (if there is no 'next signalling message' the fact that
the Confirm has been lost is moot). In this case, the responding node will start
to receive messages at the GIMPS level for a flow/NSLP combination for which
there is no stored routing state (since this state is only created on receipt of
a Confirm).
The consequence of this is that the error condition is detected at the
Responding node when such a message arrives without the need for a specific
timer. Recovery requires a Confirm to be retranmitted and successfully received.
The ideal mechanism to cause this would be for the Responding node to be able to
reject the incoming message with an error "No Routing State Exists" back to the
Querying node, which would interpret this as caused by a lost Confirm; the
Querying node needs to be able to regenerate the Confirm from local state
without getting a Response (e.g. in particular it needs to remember the
Responder Cookie value).
|
