From: James M. <jm...@en...> - 2004-06-15 08:45:56
|
On Tue, 15 Jun 2004, Aidas Kasparas wrote: > ... > > I suggest to join them with 'and' keyword. Then it's clear how was it ment > > even for those who see the config file for the first time. Special > > operators like '|' or '+' or whatever else (or even nothing) are not > > self-explaining. > > Wouldn't it be too verbose? > C "LT" and O "GMC" and OU "gws" > Or maybe not. But you don't have this problem if you use the wildcard notation I suggested and which I think is a lot clearer than the treating it component by component as above. -- james |
From: Michal L. <mi...@lo...> - 2004-06-15 11:41:17
|
On Tue, 15 Jun 2004, James Matheson wrote: > On Tue, 15 Jun 2004, Aidas Kasparas wrote: > > ... > > > I suggest to join them with 'and' keyword. Then it's clear how was it ment > > > even for those who see the config file for the first time. Special > > > operators like '|' or '+' or whatever else (or even nothing) are not > > > self-explaining. > > > > Wouldn't it be too verbose? > > C "LT" and O "GMC" and OU "gws" > > Or maybe not. I see, I misunderstood Aidas for the first time... > But you don't have this problem if you use the wildcard notation I > suggested and which I think is a lot clearer than the treating it > component by component as above. Agreed. James' wildcard notation with multiple choices joined by 'or' (and eventually 'and') looks to mu as a better way to go. Michal Ludvig -- * A mouse is a device used to point at the xterm you want to type in. * Personal homepage - http://www.logix.cz/michal |
From: James M. <jm...@en...> - 2004-06-15 09:24:07
|
On Tue, 15 Jun 2004, Michal Ludvig wrote: > On Sat, 12 Jun 2004, Aidas Kasparas wrote: > > > Hmmm. I have just checked -- it is possible to write gramar, where we > > need to specify identification method only if in the next check it is > > different from the previous one. > > Indeed, everything is possible, but ... > > > Therefore > > > > peers_identifier asn1dn "c=lt, o=*" or "c=uk, o=*" or "c=nl, o=*" or > > address 10.20.30.40 or 192.168.100.200 > > use { ... }; > > > > would be legal. > > ... but I'm for a strict syntax. It isn't much more typing and it brings > readability, probably the parser would be simpler and there is less chance > to overlook a mistake in the config. I don't think this matters hugely much either way but I suspect that Michal is right that it's very rare that people are going to want to mix types in a single peers_identifier statement so there is something to be said for the simpler form, ie peers_identifier type "c=lt, o=MyOrg, ou=*, cn=*" or "c=uk, o=MyOrg, ou=*, cn=*" use { ... }; > > We can have | and + as synonims for "or". > > Why? If the manpage says that you should use 'or' there then you really > should. I see no point in having many different ways to write the same > thing. And agreed that we should fix on just one. > ... > > Look, maybe we should use directives: > > > > accept_policy on|off ; # instead of generate_policy on|off > > accept_policy if gateway any gateway any; # your case > > generate_policy mesh; # generate all posible policies between specified > > # local and remote networks > > generate_policy on|off; # warn about old syntax > > Keywords accept_policy and generate policy are mutually exclusive, aren't > they? I.e. with 'accept_policy on' you simply use the policy that the peer > requests, with 'generate_policy something' you generate policies from > 'something' and check if the one requested by the peer fits to any of > them and eventually put the matching one to the kernel, correct? > > If this is how it should work I suggest to only use one keyword for > everything, because you can't have both accept_policy and generate_policy > used at once. I.e. something like: > policy [if addr1 port addr2 port] {accept|ignore|generate [rules]}; As Aidas comments, his generate policy isn't like this and I don't think the above quite represents the semantics for accept policy either. Maybe something like: generate_policy accepting policy_match_mask; and generate_policy for rules; would be clear and satisfy all our wish lists? policy_match_mask specifies which bits of the client supplied policy must match what values, ie conceptually (detailed syntax needs further thought!) where *_p are values in the packet from the client and *_v are config file values: ((client_addr_p & client_addr_mask_v) == client_addr_v) && (client_addr_prefixlen_p <= client_addr_prefixlen_v) && ((client_proto_p == client_proto_v) || (client_proto_v == any)) && ((client_port_p == client_port_v) || (client_port_v == any)) && ((server_addr_p & server_addr_mask_v) == server_addr_v) && (server_addr_prefixlen_p <= server_addr_prefixlen_v) && ((server_proto_p == server_proto_v) || (server_proto_v == any)) && ((server_port_p == server_port_v) || (server_port_v == any)) && > > Shoud we use separate directive "priority xxxxx" or "prio xxxx" in > > {generate|accept}_policy, or allow both? > > Not both please! Agreed. -- james |
From: Ludo S. <lu...@pr...> - 2004-06-15 09:35:59
|
Again I would like to point out that there are two different concepts here: Authentication including filtering allowable policies. and separate: Generation of policies. Please look at my example in: http://sourceforge.net/mailarchive/message.php?msg_id=8694600 Greetings, Ludo. On Tue, 2004-06-15 at 11:24, James Matheson wrote: > On Tue, 15 Jun 2004, Michal Ludvig wrote: > > On Sat, 12 Jun 2004, Aidas Kasparas wrote: > > > > > Hmmm. I have just checked -- it is possible to write gramar, where we > > > need to specify identification method only if in the next check it is > > > different from the previous one. > > > > Indeed, everything is possible, but ... > > > > > Therefore > > > > > > peers_identifier asn1dn "c=lt, o=*" or "c=uk, o=*" or "c=nl, o=*" or > > > address 10.20.30.40 or 192.168.100.200 > > > use { ... }; > > > > > > would be legal. > > > > ... but I'm for a strict syntax. It isn't much more typing and it brings > > readability, probably the parser would be simpler and there is less chance > > to overlook a mistake in the config. > > I don't think this matters hugely much either way but I suspect that > Michal is right that it's very rare that people are going to want to > mix types in a single peers_identifier statement so there is something > to be said for the simpler form, ie > > peers_identifier type "c=lt, o=MyOrg, ou=*, cn=*" > or "c=uk, o=MyOrg, ou=*, cn=*" > use { ... }; > > > > We can have | and + as synonims for "or". > > > > Why? If the manpage says that you should use 'or' there then you really > > should. I see no point in having many different ways to write the same > > thing. > > And agreed that we should fix on just one. > > > ... > > > Look, maybe we should use directives: > > > > > > accept_policy on|off ; # instead of generate_policy on|off > > > accept_policy if gateway any gateway any; # your case > > > generate_policy mesh; # generate all posible policies between specified > > > # local and remote networks > > > generate_policy on|off; # warn about old syntax > > > > Keywords accept_policy and generate policy are mutually exclusive, aren't > > they? I.e. with 'accept_policy on' you simply use the policy that the peer > > requests, with 'generate_policy something' you generate policies from > > 'something' and check if the one requested by the peer fits to any of > > them and eventually put the matching one to the kernel, correct? > > > > If this is how it should work I suggest to only use one keyword for > > everything, because you can't have both accept_policy and generate_policy > > used at once. I.e. something like: > > policy [if addr1 port addr2 port] {accept|ignore|generate [rules]}; > > As Aidas comments, his generate policy isn't like this and I don't think > the above quite represents the semantics for accept policy either. Maybe > something like: > > generate_policy accepting policy_match_mask; > and > generate_policy for rules; > > would be clear and satisfy all our wish lists? > > policy_match_mask specifies which bits of the client supplied policy > must match what values, ie conceptually (detailed syntax needs further > thought!) where *_p are values in the packet from the client and *_v > are config file values: > > ((client_addr_p & client_addr_mask_v) == client_addr_v) && > (client_addr_prefixlen_p <= client_addr_prefixlen_v) && > ((client_proto_p == client_proto_v) || (client_proto_v == any)) && > ((client_port_p == client_port_v) || (client_port_v == any)) && > ((server_addr_p & server_addr_mask_v) == server_addr_v) && > (server_addr_prefixlen_p <= server_addr_prefixlen_v) && > ((server_proto_p == server_proto_v) || (server_proto_v == any)) && > ((server_port_p == server_port_v) || (server_port_v == any)) && > > > > Shoud we use separate directive "priority xxxxx" or "prio xxxx" in > > > {generate|accept}_policy, or allow both? > > > > Not both please! > > Agreed. > > -- > james > > > ------------------------------------------------------- > This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference > Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer > Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA > REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND > _______________________________________________ > Ipsec-tools-devel mailing list > Ips...@li... > https://lists.sourceforge.net/lists/listinfo/ipsec-tools-devel -- Ludo Stellingwerff V&S B.V. The Netherlands ProTactive firewall solution. Tel: +31 172 416116 Fax: +31 172 416124 site: www.protactive.nl demo: http://www.protactive.nl:81/netview.html |