On Sat, Jul 30, 2005 at 11:44:55PM -0700, David S. Miller wrote: > > This bounds the pollution a remote entity could cause to the > number of hash chains we have, and no greater.
Yes that sounds like a good idea. > I wish I could come up with a sane way to use the inetpeer cache to > store this info. Unfortunately we need to key on address _and_ ID. However, this is even better :) Except that I'm confused by what you said here that we need to key on the ID. Why do we need to key on the ID? I would've thought that the saddr is sufficient. > What's more, even if inetpeer could be made to work we would need to > think about inetpeer cache pollution issues similar to the ipc ones we > are trying to discuss here. I actually think inetpeer would be ok in > this regard due to it's "unused list" scheme, but we'd need to double- > check just to make sure. Yep you're absolutely right there. The only reservation I have is the ability of an attacker to throw entries out of the inetpeer cache. But I suppose they can do that anyway through sending spoofed ICMP echo requests. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
