New subject: State Machine: Interaction with state installation

4 Mar 2005

      Hi Elwyn,
Pls. see inline.
----- Original Message ----- 
From: "Elwyn davies" elwynd@dial.pipex.com
...
Hi.
Having got to the details of generating RESPONSE messages, I think we have
some problems to sort out.
There are (at least) two separate issues:

There are two separate ways (timings) in which MRS is established at

the
...
responder node (the downstream end).
1a. If the node is being paranoid about DoS attacks, the response to a
query
...
message should make minimal impact on the state in the responder node.
Although this is not spelt out in detail in the draft, the implication is
that the RESPONSE message should be generated but nothing about it should
be
...
recorded if this is possible.  I presume that the intention would be to
generate a RESPONSE cookie which could be verified as having been
generated
...
by the responding node, that it was generated recently and that it hasn't
been tampered with just on the basis of the cookie alone without needing
any
...
independently stored specific state.  In particular, we shouldn't start
timers or create a FSM. The only thing that we have to ensure is that the
node is ready to accept a connection when the upstream node initiates a MA
(if it is going to).  This is presumably true even if there is an existing
MA??  The response should be sent in Dmode irrespective of whether there
is
...
an existing MA if this scheme is adopted.  If and when a confirm arrives
(see issue 2) we go straight to Established state and setup all the MRS.
The Confirm can be checked to verify that it contains a RESPONDER cookie
that this node generated recently without needing the specific state -
hence
...
the cookie needs to be cryptographically generated based on local time,
node
...
identification and a private secret, allowing it to be decoded on the
basis
...
of the single private secret ... no exchange of this secret is needed.
Yes. Full handshake should be completed in D_mode.
...
1b. For less paranoid nodes, the scheme as in the FSM draft and diagrams
applies.  Will anybody adopt the less paranoid scheme?
I think the draft states the possibility for even looser scheme for the
responding node:
Section 4.4.1 states that responding node could establish a routing state
after receiving of Query message.
...

There is some confusion (IMO) as regards whether the CONFIRM message is

sent in Dmode when there is a new MA being setup.  In draft -05, section
5.1
...
seems to imply that CONFIRMS are only sent on pre-existing MAs in Cmode,
whereas Section 4.4.1 says that the GIMPS-Confirm is the first message
sent
...
over the new MA.  It is not clear which of these ought to be right:
Yes it is not clear.In the FSM draft and diagrams comfirm message of MA is
always sent over this MA.
Still in section 7.4. it is stated that a combination of two defences
against DoF attacks is used:
1. Receiving of confirm message over a secure channel
2. Response cookie
This might be interpreted as that Confirm message is sent over newly
established MA?
...
In fact
for case 1a above to work, the CONFIRM message has to be carrying the
querying nodes NAO which will only happen in Dmode. This is because in
case
...
1a, the querying node's NAO from the query message is not stored.  This
could of course be solved alternatively by including the query node's NAO
in
...
all CONFIRM messages.
Since the MA, from which the CONFIRM message is received, is associated with
a NAO of the quering node, there is no need to include the NAO in the
confirm again. Isn't this the reason for which NAO is intentionaly removed
from C_mode response and confirm messages.?/ section 4.4.2/
Greetings,
Tseno_
...
On the other hand, it will be much easier to tie up
the new MA's downstream end with the relevant MRS if the CONFIRM message
emerges from the new connection.  If the CONFIRM message arrives
separately
...
in Dmode, the responder node has to link the newly created (but quiescent)
connection (TCP socket) with the relevant MA state and the correct MRI.
This involves complex inspection of the peer address for the connection
etc., and it might not be so easy with other sorts of connection.
The FSMs currently reflect case 1b and the use of the newly established MA
to send a Cmode CONFIRM.  Supporting 1a and Dmode CONFIRMS will need some
changes (depending on what view is taken of the CONFIRM issue).
Comments?
Regards,
Elwyn

Nsis_imp mailing list
Nsis_imp@informatik.uni-goettingen.de
https://user.informatik.uni-goettingen.de/mailman/listinfo/nsis_imp

Re: [Nsis_imp] State Machine: Interaction with state installation