From: Aidas K. <a.k...@gm...> - 2004-06-14 13:30:24
|
James Matheson wrote: >>peers_certfile [plain_rsa|x509] "filename" ; >># defaults to x509 (if possible to implement default value, dunno) >># may be used more than once >># X509 may contain multiple certs (when using my patch) I am pretty confident, that it is possible to have backwards compatibility and make x509 optional keyword. >> >> >>peers_identifier [address|asn1dn|fqdn|user_fqdn|keyid] "identifier" >># may be used more than once >># asn1dn may use wildcards per section > > > There's potentially the use clause to add to this, ie > > peers_identifier [address|asn1dn|fqdn|user_fqdn|keyid] "identifier" > use { ... } > > and to avoid repetition of the same "use" statements, it would make sense > to allow a list of identifiers, eg > > peers_identifier [address|asn1dn|fqdn|user_fqdn|keyid] > "identifier1" or "identifier2" or "identifier3" > use { ... } Maybe comma (,) would be better than "or"? How about requiring type before each identifier? Then it would be possible to combine peers, identified by different methods, to use one use-block. > > >>generate_policy [on|where...|"scriptname"] > > > I think it would be better to stick to general form > generate_policy keyword [args] > so the above would become > generate_policy (on|off|where|script) [args] > (keeping () for grouping and [] for optional) > Re scripting vs in-racoon implementation I thought for long time in January, tought yesterday, and I still do not like script aproach. Why? 1) in 95+% cases one needs to setup security policies and nothing else (therefore script's potential flexibility would not be used); 2) script would be complex (it needs not only setup policies, but eventually this script needs to be called to remove the policies it has set up); in case config has changed, this script most likely will try to remove wrong policies, and if control never leaves racoon, it could keep relationship between dynamic policies and information about peer; 3) there will be two places where every peer has to be configured -- in racoon.conf and in script's config/body; 4) script will be much (at least order of magnitude) slower; 5) code for most of in-racoon implementation is almost there. > >># "where" would be used both for limiting and defining policies >> >># syntax: ..where { >># remote_networks [limited_to] address [/ mask [/ prefix_limits]] >>[\[port\]] [ul_proto] >># local_networks [limited_to] address [/ mask [/ prefix_limits]] >>[\[port\]] [ul_proto] >># Each of these may be used more than once >># } > > > I'd envisaged this only dealing with the case of limiting policies and > which address is which might, as in sainfo, by implied rather than made > explicit by a keyword, eg > > src_address[/prefix] [mask maskval] [[port]] ul_proto \ > dest_address[/prefix] [mask maskval] [[port]] ul_proto > > Here certain special values are going to have to be allowed, eg > peer_ip and local_ip for addresses, any for ul_proto (probably more > consistent with the sainfo case than making ul_proto optional). What is the reason to have ul_proto repeated twice? There should be method to give priority at which generated policies should be inserted. I would suggest to use "gateway" instead of "peer_ip" and "local_ip". Can you please explain, what meaning of "where" is meant to be used in generate_policy where 10.20.30.0 mask 24 any 192.168.192.0 mask 24 any; My english is not good enought to understand. Maybe limited_to ? You suggest to have generate_policy inside peers_identifier ... use { <here> }; am I right? -- Aidas Kasparas IT administrator GM Consult Group, UAB |