RE: threats ID

["marcelo bagnulo" <mbagnulo@ing.uc3m.es>]

> 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.

good point

> Transport-layer solutions can claim that they reduce that set of sessions
> to one at a time.
>
> 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?
>

well, i may have induced also this perception...
I haven't really made an analysis about if the threats mentioned in Erik's
draft only apply to IP layer solution, but it is just that i have always
asumed that this draft had these type of solutions in mind, so that its
analysis applied to this type of solution. Sorry if i generated some
confusion here.
OTOH, Masataka's draft states clearly in the tittle that it is considering
the thransport layer solutions.

> In any case this does not prevent combining the two drafts, which will
> be much easier for readers, e.g.:
>
> Part 1: threats that only affect network layer solutions
> Part 2: threats that affect both network and transport layer solutions
> Part 3: threats that only affect transport layer solutions
>

Yes, or other option is to make an analysis for IP layer solutions and
another for transport layer, but in any case IMHO we should clearly
undestand the differences between the two cases.

regards, marcelo

>    Brian
>
> marcelo bagnulo wrote:
> >
> > Hi Masataka,
> >
> > please consider the differences between performing a hijack
> attack on MIP
> > (layer 3 solution) or performing a hijack attack on SCTP
> (transport layer
> > solution)
> >
> > in the first case the complete end node is hijacked (that is
> its IP address
> > that is its identifier) and in the second case only a given
> connection is
> > hijacked
> >
> > threats are different and security required is different
> >
> > ( i am really tring to agree with your draft here :-)
> >
> > regards, marcelo
> >
> > > -----Mensaje original-----
> > > De: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]En
> > > nombre de Masataka Ohta
> > > Enviado el: martes, 20 de enero de 2004 1:42
> > > Para: mbagnulo@ing.uc3m.es
> > > CC: Brian E Carpenter; Multi6 List
> > > Asunto: Re: threats ID
> > >
> > >
> > > Marcelo;
> > >
> > > > IMHO both drafts complement themselves pretty well because
> Erik & Tony's
> > > > draft essentially analyze the threats from a IP layer
> perspective and
> > > > Masataka's draft analize the threats from a transport layer
> perspective.
> > >
> > > The problem for Erik and Tony, then, is that IP layer of
> > > multi6 is no different from the current one.
> > >
> > > > After some mail exchanges with Pekka N., my understanding is
> > > that that there
> > > > is an important distinction to be made between these two cases when
> > > > considering the hijacking attack.
> > >
> > > Good.
> > >
> > > Can you answer the following simple question?
> > >
> > > What, do you think, is being hijacked?
> > >
> > > Connections?
> > >
> > > Note that, unless you extensibly modify IP layer, there is no
> > > connections there.
> > >
> > > > The point is that in transport layer
> > > > solutions, the hijcack attack is limited to the existent established
> > > > connection while in the IP layer (shim layer also)
> solutions the attack
> > > > applies to the complete endnode.
> > >
> > > Wrong. Attack is always applied to the end.
> > >
> > > > Because the attack applies to the endnode,
> > > > the attacker can do things like establishing aconnection
> > > creating some state
> > > > so that futuer communications initated by the victim are also
> > > redirected.
> > >
> > > Establishing a connection is a functionality of the transport
> > > layer.
> > >
> > > > That is in IP layer solutions the complete identity of the victim
> > >
> > > There is no IP layer solutions.
> > >
> > > Just like NAT operates not only at the IP layer but also at the
> > > transport and applicaiton layers, shim layers are not only at
> > > the IP layer.
> > >
> > > > So I guess that i agree with Masataka that a return routability
> > > check with a
> > > > cookie is enough to redirect a connection but IMHO this is
> not enough to
> > > > redirect a complete identity at the IP layer level.
> > > > I mean time shifting attacks may be acceptable as long they can
> > > only affect
> > > > a connection.
> > >
> > > "Time shifting attack" is meaningful if only there is persistent
> > > relationship, that is connection, that it is not at the
> > > connectionless layer.
> > >
> > >                                               Masataka Ohta
> > >
> > >
> > >
>
> --
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> Brian E Carpenter
> Distinguished Engineer, Internet Standards & Technology, IBM