Re: threats ID

[Erik Nordmark <erik.nordmark@sun.com>]

On Tue, 2004-01-20 at 03:11, Brian E Carpenter wrote:
> If a network-layer mh solution uses multiple identifiers, then what gets 
> hijacked is an individual identifier, not the node. Thus what is hijacked
> is the subset of sessions in the node using the same identifier. 
> Transport-layer solutions can claim that they reduce that set of sessions 
> to one at a time. 

It is probably true in general that if normal traffic needs to do
X amounts of work per transport connection, than a redirection attacker
needs to do some work proportional to X per transport
connection.
Thus the ability to aggregate the signaling needed for rehoming for
multiple transport connections would affect legitimate traffic just as
much as it would affect an attacker.

> Nevertheless I find it surprising for Matasaka to assert that most of
> the threats in draft-nordmark-multi6-threats-00.txt only apply to
> network layer solutions. Do people have an opinion about that?

It might depend on the details of the transport layer solutions.
Taking the premeditated redirection attack as an example.
If an attacker can guess that port A on node B will talk to port C on
node D in the near future, then premediated redirection attacks can be
launched on a transport solution which identifies the "redirectable
unit" by the 5-tuple.
But if the transport solution uses some hard to guess random component
(an SCTP verification tag is an example; another example would be some
emphemeral IDs) to identify the redirectable unit, then it would be much
harder to perform a premediated redirection attack.

My take on this is that the threats exist in all cases. Different
approaches, and in particular different bindings with transport level
mechanisms, can provide rather different ways of handling the threats.

Should it come to comparing transport vs. layer 3.5 approaches I think
the hardest thing for a transport level approach is for UDP traffic; 
preventing the various threats for UDP isn't much different than
preventing them for IP.

   Erik