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