Two more issues related to R1bis that came to my mind: 1 - Is it important to defend a peer from a fake R1bis?I mean, R1bis may enable some attacks similar to sending a fake TCP RST packet. If a peer receives a R1bis packet refering to an established context, it will try to restablish the context, sending an I2 packet. If we assume that the R1bis packet is fake and that the validator is not correct, the receiver will siliently discard the I2 packet. At this point the receiver will try to resend the I2 packet or try to send an I1 packet again. I2 will continue to be discarded, but I1 packet will get a R2 reply, which imho will be good enough in this case. I guess that this covers this case pretty good, so i don't think that anything else is needed.
2 - Do we want that the failure detection probes trigger a context recovery mechanisms i.e. R1bis?
In the considered scenario, when the initial path between the ulids is working fine, the transmission of probes to verify that the current path is working may result in triggering the context recovery mechanisms i.e. the transmission of a R1bis packet. Such behaviour may not be the optimum for dealing with the case of the server that wants to discard the clients contexts, in order to let the clients to handle fault tolernace (the scenario suggested by Iljitsch in the ams meeting). A possibility for dealing with this would be that probes that verify that the current path is working do not contain context specific information (as oposed to probes used for exploring the alternative paths, that in order to be used for flooding prevention must carry context specific information). I know that this would imply a change in the failure detection protocol in Jari's draft, but maybe it would be worth to consider this issue.
Regards, marceloPS: agree that interaction with context confusion mechanisms needs to be be clearly understood in order to get the full picture about this R1bis thing
El 10/11/2005, a las 4:06, Erik Nordmark escribió:
marcelo bagnulo braun wrote:So, the proposal would be to: Define a new type of messages: R1bisDefine types of validator mechanisms , which are identified by the 3 most significant bits of the validator valueSo 3 bits instead of 1 bit is so that we can have some future extensibility?Define an alternative validator mechanism for this message, that includes as inputs the following values:- the Secret S - The responder (B) nonce - the locator pair - the context tag contained in the received packet (CTpac)Define that the initiator nonce used for R1bis packets is the hash of the locator pair and CTpacGood suggestion.Define generation and processing of the R1bis packet accordingly.I guess there is a detail which is whether R1bis is a different message type than R1, or whether use a bit in R1 to indicate bis vs. normal.My suggestion is to use a different message type for R1bis.- Perhaps A is already using this context tag for another context. In this case, A simply starts a regular 4 way handshake to establish the context again I guess that the last option seems the preferred alternative...Hopefully the case when the context tag is use we have the option to use the "context confusion" recovery mechanism, which handles other cases when a context tag has been reused...I have to think about this some more. Erik