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

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

El 03/11/2004, a las 1:28, Erik Nordmark escribió:

> marcelo bagnulo braun wrote:
>
> > Just one additional nit...
> > note that HBAs are particularly restrictive in this aspect, since all 
> > locators need to be known a priori. However, even if you use 
> > alternative schemes that don't impose such restriction, like CGAs, 
> > you still need to add security information at least in the same 
> > packet that carries the new locator.
>
> That requirement isn't obvious to me so I think it would warrant 
> discussion.

agree

> The issue is whether it would be ok for the multi6 shim to pass a 
> packet to the ULP when the source locator has not been verified as 
> belonging to  the peer. We all agree that we need to do such 
> verification before *sending* packets to a new locator, but what about 
> just accepting the packet?

good point

> Things to take into account:
> In today's Internet, when there is no ingress filtering anybody can 
> spoof the source IP address and the packets will be passed by IP to 
> the ULP. However, in today's Internet when there is some ingress 
> filtering it is possible to restrict the nodes which can actually 
> spoof the source IP address to those that are close to the path 
> between the real location of the IP address and the receiving node.

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

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.

regards, marcelo

> If a host wants to prevent packet injection attacks today (such as 
> spoofed RCP RST packets, if it wants to prevent it from all nodes and 
> not depend on ingress filtering, wouldn't it use IPsec?
>
>    Erik
------------------------------------------
Please note that my former email address
mbagnulo@ing.uc3m.es is no longer in use
Please send mail to:
marcelo at it dot uc3m dot es
------------------------------------------