[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
about R1bis
Hi all,
Warning: this is quite long email. I didn't expected that this was a so
complex issue, but this is the best i could came up with
One of the issues that are still open is how to detect context loss and
recover it.
* Issue description: (background information, skip till next bullet *
if you already know what R1bis is)
So far the approach selected is to detect context loss when a packet
that refers to a non-existent context is received. In other words, A
detects that it has lost a context when it receives a packet referring
to a context that is not available.
However, in order to be able to tell that a given packet is referring
to a non existent context, the packet must contain some information
that indicate that a context associated to this packet is supposed to
exist. This implies that data packets carrying the ULIDs in the address
fields won't be useful to detect context loss, since they are regular
ipv6 packets without any bits indicating that an associated context is
supposed to be available at the receiver. OTOH, shim control packets
and data packets carrying the shim payload header will be useful to
detect context loss.
This means that the approach selected for context loss detection would
work as follows:
A shim enabled node will detect that it has lost a context that is
still being used by the peer when it receives a shim control packet or
a data packet containing the shim payload header that refer to a non
existent context.
A consequence of this approach, is that before a rehoming (i.e. when
locators == ULIDs) only the shim control packets will be able to detect
a context loss, and assuming that the shim control traffic will be
limited, it is likely that frequently context loss will remain
undetected until a failure occurs (this of course depends on the
traffic pattern, since if periodic probes are required for failure
detection, these will also be useful for detecting context loss)
However, once that the communication has been rehomed, all data packets
will be useful for detecting context loss.
Now, without additional considerations, this behavior would be hardly
acceptable, since context loss can only be (reasonably well) detected
once that we really need it to be available.
The approach proposed to complement this failure detection mechanism is
a context recovery mechanism that allows the peer to rebuild the lost
context.
At this point, this would work as follows:
- Regular IPv6 communication is established between A and B
- Shim context is set up
- Peer A losses the context
- a failure occurs
- packets containing the shim payload header are sent
- Upon the reception of packets, A detects that it does not have a
context for incoming packet
- A informs B about the missing context
- B reestablishes the context using the context information it has
available.
The question at this points is how to perform the last two points:
one option would be to define a No context error message to let A
inform B about the missing context and then let B use the 4 way
exchange to establish the context again.
However, considering that we are in the situation that we need to use
the context asap, because a failure has already occurred, it seems wise
to explore the possibility of reducing the number of packets needed to
reestablish the context. In particular, the possibility of using a
(possibly modified) R1 packet as indication from A to B that a context
has been lost.
In other words, that upon the reception of a packet referring to a non
existent context, the receiver return a R1 bis packet, so that the peer
can continue with the rest of the context establishment exchange (i.e.
I2 and eventually R2)
The result is a 3 packet exchange instead of a 5 packet exchange.
* About R1bis
The question now is whether R1 bis can be R1 as it is defined or some
modifications to the R1 packet are needed.
The considered case, we have A and B shim peers that have established a
context and suppose that B has lost the context.
At this point, A sends a packet referring to the missing context and B
replies with a R1: the question is whether B can properly generate a R1
packet or there is some information that B is lacking?
First of all, let's assume that any packet sent from A to B referring
to the context contains information about the context tag assigned by B
to identify the context. This is so, because packets that refer to the
context are shim control packet or data packets containing the shim
payload header. The shim payload header carries the context tag, so no
problem here. The question is if all shim control packet carry the
context tag. While this is not clear yet, we will assume that for the
time being:
## Hypothesis 1: all shim control packets and all data packets
## carrying the payload header carry the respective context tag
Now, upon the reception of this packet, B detects that no context
associated to this packet exists. At this point, does B has the
required information to build a R1 packet?
R1 packet contains the following information:
- Responder (B) nonce
- Initiator (A) nonce
- Responder (B) validator, which generation is suggested
in the draft to require:
- Secret S
- Responder (B) nonce
- Initiator (A) assigned context tag
- ULID pair
- Locator pair
According to the draft the goal of the validator is that:
the responder can verify that the validator it receives back in the
I2 message is indeed one that 1) it computed, 2) it computed for the
particular context, and 3) that it isn't a replayed I2 message.
So which of this information is available in B?
Clearly all the information about B is likely to be available, in
particular, B knows:
- The Responder nonce
- The Secret S
OTOH, the information about A is not available, in particular:
- The Initiator nonce
- the Initiator assigned context tag (note that the context tag
contained in the received packet that referred to the lost context
carried the context tag assigned by B to the context, not the one
assigned by A)
Besides, the packet may or may not contain the ULIDs in the address
fields: in particular, if it was a data packet with the payload
extension, then the address fields did not contain the ulids. If it was
a control packet, B has no way to tell if the addresses contained in
the address fields were the ulids or not.
So, B knows the locator pair but it cannot be certain in general that
it knows the ulid pair (it can only be certain in the case of the the
payload header that it does not know the ulids)
Now, we know that B cannot produce a R1 packet since there is some
information missing.
The next question is whether the information available at B is enough
to build a R1bis packet that provides the required functionality with
the required level of protection.
We will first consider the information required for generating a proper
validator.
B could generate a validator as the hash of the following information:
- the Secret S
- The responder (B) nonce
- the locator pair
- the context tag contained in the received packet (CTpac)
Now is this validator good enough?
As mentioned above, a validator should fulfill the following conditions:
The responder can verify that the validator it receives back in the
I2 message is indeed one that:
1) it computed,
No problem with this one, since the secret S
ensures that only the responder is able to
generate this validator
2) it computed for the particular context,
This basically means that it must be possible to determine
to which this validator is associated, so that it results
impossible to an attacker to generate multiple contexts
with a single validator.
In other words, that one validator is used to create,
at most a single context.
A possible approach for this would be to remember
which validators have been issued and which of those
have been used. However, this is not the selected
approach, because it would require keeping track of
generated validators, which would require generating
state for each I1 message received, and thus opening
the door to DoS attacks.
The selected approach is to include information that
identifies a single context in the input of the hash
function that generates the validator.
These two considerations imply that enough information
to uniquely identify a context after that it is created must
be included in the validator, so that once that the context
associated to a given validator is created, it is possible
to identify future attempts of context generation using
the same validator.
The question at this point is which of the available
information will be stored once the context is created and
which information is enough to identify a single context.
Clearly a locator pair and any of the two context tags fulfill
those two conditions, since they will be stored as part of the
context state once it is created and they are enough to
identify a single context.
In regular R1 validators, the initiators context tag is used.
In this case, B (the responder) does not knows A (the
initiator) context tag, but it does know the context tag CTpac
that B used for the lost context.
So the options at this point are:
- use CTpac as the context tag assigned by B to the new context
The difficulties with this approach are:
- Perhaps B is already using this context tag value for
another context. The possibility here would be that
B issues a No context error message and that
the context is restablished using full 4 way handshake.
- After B replies with R1bis, B will not keep any state
about this reply, in particular about the context tag
So, this implies that an I2bis packet would be
required that it informs B about the context tag that it
should use for this context that is being created.
Potentially, this context tag value may have been used
by B since it issued R1bis and received I2bis . Same as
the previous case, fall back to full 4 way handshake
- use CTpac as the context tag assigned by A to this context
The difficulties with this approach are:
- A should change the context tag used for this context.
Not big deal here, i guess.
- 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...
3) that it isn't a replayed I2 message.
Since we are including the responder nonce, we can protect against I2
replayed attacks
So, a possible approach seems to use a different input for the
validator of R1bis packets, which input would be:
- the Secret S
- The responder (B) nonce
- the locator pair
- the context tag contained in the received packet (CTpac)
In addition, upon the reception of this R1bis packet, node A needs to
verify if the CTpac has been locally assigned for any context.
If CTpac is already in use, then initiate a regular context
establishment exchange, sending a regular I1 packet.
If CTpac is not being used, then assign CTpac as the locally assigned
context tag for this context that is being recovered, and delete it as
the remotely assigned context tag, and continue sending an I2 packet.
(Note that CTpac does not need to be included in R1bis, since A already
knows CTpac because it is contained in the existent context state.)
However, at least a flag or a new type is needed to differentiate R1
packet from R1bis packet, in order to let a to perform the different
packet processing
It should be noted that this change in the validator input only affects
B.
This means, that only B have to know that different information was
included in the validator input, so no need to inform A that a
different input was used in the validator. In order to distinguish this
validator type from the one used in regular R1 packets, it would be
possible to include, let's say, 3 bits in the validator, to indicate
the type of validator used. Node A does not need to understand the
semantics of those 3 bits, but just need to be copied to the I2 packet.
the responder will be able to read those 3 bits and find the proper
mechanism to verify the validator.
We have now defined a new way to create a validator for a R1bis packet
with the available information. In addition, regular R1 packets also
carry the Initiators nonce, that it is not available when building a
R1bis packet. We will next analyze alternative options to provide
similar features than the ones achieved by including the initiator
nonce.
In order to do that, we need first to understand what the initiator
nonce is protecting from.
In the draft it is stated that nonces are used to prevent replay
attacks.
So, what type of replay attacks can be made in the shim scenario?
Suppose that I1 packet does not includes a initiator nonce.
In this case, an attacker could send a replayed R1 packet and the
initiator would take it for a true packet, since it has no way to
verify that this is a replay.
The initiator could then continue sending the I2.
If the I2 makes it to the receiver, it will be silently discarded,
because the responder nonce included in the message does not match with
the one included in the validator, so the result is a DoS attack, where
the initiator cannot establish a shim context.
Is there other attack that the initiator nonce is preventing?
In order to provide some kind of protection to this type of attacks, it
would be possible to craft some kind of initiator nonce from the
information contained in the received packet that was referring to the
non existent context.
A possibility would be to use CTpac as initiators nonce. In this case,
the attacks described above would be limited to attackers that were
once on path, and that have discovered the context tag. Another option
would be to use as an initiator nonce a hash of (the locator pair and
CTpac). In this case, the attacker would need to find out the current
locator pair, and the context tag. Probably this is good enough
protection for this type of attacks.
So, the proposal would be to:
Define a new type of messages: R1bis
Define types of validator mechanisms , which are identified by the 3
most significant bits of the validator value
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 CTpac
Define generation and processing of the R1bis packet accordingly.
comments?