Re: I-D ACTION:draft-nordmark-multi6dt-shim-00.txt

Erik Nordmark <[email protected]> Wed, 03 Nov 2004 11:27:52 -0800
Newsgroups gmane.ietf.multi6
Message-ID <[email protected]>
marcelo bagnulo braun wrote:

> Well, if we allow hosts to accept packets coming from unverified 
> locators and present them as belonging to a different ULP identifier, 
> then not even ingress filtering would prevent such attacks. I mean, 
> today, if ingress filtering is deployed, then the problem of spoofed 
> addresses is reduced. If we allow the reception from unverified 
> locators, ingress filtering won't help any more in this problem.

Agreed.

> OTOH, i understand that there is a long way between the level of 
> security provided by a semi deployed ingress filtering and the level of 
> security resulting from requiring the usage of cga or hbas to verify any 
> incoming locator. Perhaps a cookie would be enough to validate incoming 
> packets (it is clearly not enough to send packet to that locator though)

A hard-to-guess cookie would probably make things stronger than today
in the absense of ingress filtering. Today's ULP have varying 
verification from SCTPs use of a 32-bit verification tag, TCP's reliance 
on the sequence number being in the window, and UDP with nothing (but 
applications using UDP might have something).

> Another point related to this is whether we consider this new incoming 
> locator as a hint to rehome the communication to that new locator. In 
> this case, we need additional certainty i guess.

If it is merely a hint, and there is a cookie to prevent the off-path 
attackers from triggering the hint, that might be sufficient.

    Erik