From: Matthew G. <mg...@sh...> - 2006-06-26 23:58:04
|
Scott Lamb wrote: > I'm working on porting racoon to the (proprietary) Mentat kernel > stack. Its policy database works...differently...so I'm examining > racoon's use of the policy database. Ideally, I could simply remove > it all. > > From the manual page and source code, this seems limited to: > > * "generate_policy". Is it just me, or is this option insecure? I'd Sort of ... it says so in the man page. I think the worst that can happen here is a limited form of dos by a host that has passed phase1. > expect that in the absence of a policy entry (as when the initiator > is down), an attacker could trivially connect to the responder with > no encryption or authentication, forging the initiator's IP address. No. You still need to match a valid sainfo section before a policy would be generated. The sainfo section defines what encryption/authentication parameters are acceptable. > Is there some way I'm missing that this is prevented, or maybe some > big convenience win that outweighs it for some people? The generate_policy option is useful for dynamic clients in conjunction with anonymous or semi anonymous sainfo sections. It exists because you can't define specific security policies if you don't know what the peer address or assigned private modecfg addresses will be. For site to site tunnels, an administrator would omit the generate_policy option from the remote section as it serves little purpose. You should be able to use semi anonymous sainfo sections to prevent invalid destination ids from being used during policy generation. I am working on a patch that will prevent invalid source ids from being used during policy generation for dynamic peers. > (I just ripped out 965 lines of code associated with this feature.) Why rip anything out? It would be better to make changes in a way that will still enable you to track ipsec-tools cvs. -Matthew |