[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: about draft-ietf-shim6-proto-01.txt
El 20/10/2005, a las 15:30, Erik Nordmark escribió:
marcelo bagnulo braun wrote:
In section 5.4 R1 Message Format
It may make sense to allow the responder to include the locator set
in the R1 message, so that the initiator can acknowledge the
reception of the locator set (otherwise, the locator set of the
responder is sent in R2 which remains unacknowledged).
This isn't a problem AFAICT. If the initiator doesn't receive R2 it
will
retransmit I2. The ULP packets from responder to initiator can still
flow, since they haven't failed over to use an alternate locator pair
yet.
right
Worst case would be a packet loss when we want to switch to
alternate locators immediately as part of the context establishment
(when the responder might start sending payload messages before the
initiator has received the lost R2.)
yes, but this would also be covered by the context loss recovery
mechanism that is being considered, right? i mean, the peer could
reestablish the context with an alternative locators (and the same
ulids)
Not clear actually.
If the initiator hasn't received R2, it still has a context for its
context tag (the one it sent in I1 and I2). The payload packets will
have that context tag.
The initiator just doesn't have the peer context tag and the peer's
locator list yet.
So perhaps the reception of a data packet need to verify that the shim
context state in "ESTABLISHED" (reminds me that we need to write down
the state machine) in which case it would capture that it hasn't
received the R2 yet.
not sure i am following you completely...
so, before the established state, the communication is not protected by
the shim, so it wouldn't be possible to recover so far so good...
an initiator moves to established state once that it receives R2, right?
but when does the responder moves to established state?
actually this depends on what is being signed.
one possiblity is that the responder signs the locator list (without
any context specific information). In this case, the responder
doesn't need to sign the locator list each time it sends a R1,
resulting in less processing.
the questions that are open here are reply attacks and if we need to
sign also the locator list version...
You would be subject to replay attacks of that signed list if you
don't include something live in the signature (the context tag, a
nonce, or something else)
yes, that may be an issue, perhaps we need to look this more in depth..
i was thinking that the signature would include the locator list
generation value, so that the right value must be placed there, but
that this is independent from the actual context i.e. a responder may
have a set of locator list generation values that it uses for the
initial locator lists that are exchanged during the host pair
establishment exchange. For these values it has a precomputed signature
with its locator set, so that it doesn't need to resign the locator set
each time...
this would provide some replay protection but limited, perhaps we need
more. we can always include the context tag and solve the problem but
this would imply that a signature is required for each context (when
cgas are used of course)
but as i mention, i guess that the first thing would be to identify the
potential replay attacks...
first of all, we are talking about replay attacks performed by an
attacker that once was on path, because if not, it does not has the
context tag i.e. no possibility to send any shim control packet at all.
In addition, we are considering the case of an attacker that obtains a
previous LLU message containing a locator set signed by the cga and
that it includes this previous locator set and its signature in a
message with the new context tag.
Now, in any case, as far as we talked here, the locator set is accepted
as potential source addresses just checking the context tag, right? (so
no difference here made if including or not including the context tag
in the signature)
The next step would the include those locators as potential destination
addresses. However, before doing that, the node that has received the
fake llu message will perform a reachability test to those addresses
(in order to prevent flooding)
If there is nobody there to answer, then the address won't be used.
If the host is reachable there, no problem neither.
I guess that the problematic case would be where the attacker manages
to receive the packets addressed to this locator that once was used by
the shim node.... in fixed environments this may not be an issue, but
perhaps in mobile environments, this may be a problem (an attacker
following the track of a mobile user and using the addresses that it
leaves behind...) considering that cgas are likely to be used in a
mobile scenario, it may make sense to consider this... what do you
think?
the other threat here is to replay an old message containing all
stalled locators, resulting in a dos attack. In this case, verifying
the cga signature wouldn't help for protecting from this dos attack (i
guess i make sense to take a decision considering both aspects... i
mean, if we decide to go for a verification of cga signature upon
reception to limit dos attacks caused by the introduction of all false
locators in the locator set, we may also decide to include the context
tag in the signature in order to prevent dos attacks caused by old llu
messsages.)
So full protection with cgas could be achieved by including the context
tag in the signature and verifying cga signature of received locator
set upon reception of the llu message. The cost for this is that we
need to: afford the cost of verifying locator sets that won't be
immediately used (and may will never be used). Include a context tag on
the locator set signature, so each time a locator is established, we
need to sign the locator set.
Or, we bite the bullet and have a larger context tag and ignore the
source locator in the lookup.
But in both cases we have an issue with injection of bad Update
messages. What prevents the on-path attacker from injecting such a
message and replacing the CGA parameter set with something, which
when
verified, will fail the verification?
nothing, but in this case we can detect that the message was false
and keep the last locator list that was verified
If we want to allow lazy verification where a host doesn't verify a
locator until it is about to use it to send to, then the whole list
might never be verified.
I don't know if this makes sense with HBA or CGA locators - presumably
for those the verification is just as cheap to do for the whole list
at once as doing it for one locator at a time.
Not really the case for hbas...
i mean for cgas, the full locator set list will be signed so verifying
one is the same that verifying all of them
OTOH, hbas can be verified once at the time. I mean, for hbas, the
verification needed is that the locator to be used is contained in the
same hba set than the ulid.
The hba verification procedure allows through a single hash operation
to verify this i.e. if two addresses belong to the same hba set.
n verifications would require n hashes i.e. generating the whole hba
set again
(in other words, there is an optimized mechanism defined that allows to
verify if two addresses belong to the same hba set with a cost of one
hash operation i.e. that does not require regenerating the whole hba
set (with n hash operations)
regards, marcelo