RE: Reasonable to use crypto in all communications? (Re: Fwd: Minutes/Notes)

["marcelo bagnulo" <marcelo@it.uc3m.es>]

> Using an unprotected identifier (or a pointer to a cached
> identifier) allows an attacker to send packets that may
> be delivered to a wrong socket.  I don't see anything new there.
>
> Allowing an unprotected packet to set up or change
> identifier -> locator mapping seems to be dangerous.

This is the case i was thinking about, i.e. packets carrying both id and
locator unprotected (and that haven?t been previously bound in a secure way)

If this is dangerous, a possibility is to use some sort of crypto for each
node that you are communicating with in order to perform the binding. the
other possibility is some sort of RR check, as you mention below. Other
choices?

My original question was if a solution that rerquires crypto for each
communication (not for every packet) is acceptable.

The problem with RR check is that it has to be done periodically in order to
prevent time shifting attacks. However, in the multi-homed case, perhaps
this could be avoided. I mean, an important difference between mobility and
multi-homing is that in multi-homing all the possible addresses are known in
advance. this means that they can be exchanged when the communication with
the other end is initiated. This reduces the critical packets to the initial
ones. So perhaps a solution that performs a RR check to all possible
addresses of a communication when the communication is initiated would be
acceptable. There are still some time shifting attacks that have to be
considered though.

Perhaps crypto would provide a simpler solution anyway

Regards, marcelo

>
> Return routability based on a cryptographic challenge-response
> that binds the different addresses genuinely together looks
> like a secure enough solution.  However, it is hard to
> implement in fewer than 3-4 messages (1.5 to two round trips)
> without opening a resource exhaustion danger at the passive end.
> An IP layer resource exhaustion attack would be more severe
> than a TCP layer one, IMHO.
>
> --Pekka Nikander
>
>