From: VANHULLEBUS Y. <va...@fr...> - 2005-01-29 18:37:28
|
Ok, let's start a new thread, because everybody answered to everybody, and because some solutions were unclear. First, I just checked again all drafts, and I made a mistake: Draft 04 IS the first of the "bad" list, and not the last of the "good draft list", as I said before and as I commited on the 0.5 branch (I just fixed that on the 0.5 and HEAD branchs). Here is the situation afaik: - ipsec-tools V 0.3 announces support for drafts 00 and 02 (and announces a dummy support for "RFC XXXX"), but does really support draft 02 only. - ipsec-tools V 0.4 announces support for the same drafts as V 0.3, but, as responder, allows drafts 00, 02-08, and the same "dummy RFC"). Support for drafts 02-08 should work, support for drafts 00-01 won't work. - ipsec-tools V 0.5 can support all drafts and the RFC. - Drafts 04+ are "bad" as they use IANA numbers (for NAT-D / NAT-OA payloads type) which have been assigned to another RFC. - Other implementations / products / vendors / etc... will probably support the RFC soon, but afaik, quite none supports the RFC now, and there will probably be some customers which can't upgrade their products. - Most other implementations I saw supports drafts 00 or drafts 02. - Supporting a draft version at least means one more ViD to support (yes, I know there is IKE-Frag for that, but this is an *extension*, so we can't suppose any peer will support that). - I think default configuration should be *clean*, and shouldn't consider things such as "some customers may want that": if some users want an option, they can enable it ! For example, for the product I'm working on, we'll enable support for drafts 00-03, and I don't care about adding some extra --enable-natt_XX on the configure command line, because it will be done once only in a Makefile ! * Solution 1 ("my" solution): --enable-natt => RFC only --enable-natt-compat => RFC + draft 00 + draft 02 Other drafts by adding --enable-natt_XX (and an --enable-natt-bad-drafts ?) * Solution 2 ("Manu's solution"): --enable-natt => RFC + Drafts 00-03 --enable-natt-rfc => RFC only Guess still --enable-natt_XX for the others (and/or --enable-natt-bad-drafts ?) * Solution 3: What is done now ? * Hybrid Solution : --enable-natt => "compat" mode of solution 1 --enable-natt-rfc => RFC only. Still --enable-natt_XX for the others. Yvan. |
From: <ma...@ne...> - 2005-01-29 19:01:35
|
VANHULLEBUS Yvan <va...@fr...> wrote: > * Solution 2 ("Manu's solution"): Yes, I vote for that! :-P -- Emmanuel Dreyfus Le cahier de l'admin BSD 2eme ed. est dans toutes les bonnes librairies http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php ma...@ne... |
From: F. S. <fre...@la...> - 2005-01-29 19:38:31
|
(Mmmh... Manu, sorry for the reply in your mailbox, I botched the reply once again. I'm blaming my head cold.) Saturday, January 29, 2005, 8:01:19 PM, you wrote: > VANHULLEBUS Yvan <va...@fr...> wrote: >> * Solution 2 ("Manu's solution"): > Yes, I vote for that! :-P Same here. And, as I said before, IMHO, it should be made into configuration directives whenever it's possible - that is "--enable-natt" and a new "nat-traversal-spec" or something, with values like rfc and draft0x... Of course, I realise that's some heavy work, and not realisable immediately. Fred Damn head cold - hope I'm coherent, here. -- You know those days where you just lose all interest in reality, & you drop back into ROM monitor mode & respond to all enquiries with 'wibble'? (Lionel Lauer in the SDM) |
From: VANHULLEBUS Y. <va...@fr...> - 2005-01-30 16:03:11
|
On Sat, Jan 29, 2005 at 07:37:22PM +0100, VANHULLEBUS Yvan wrote: [....] > * Solution 1 ("my" solution): > > --enable-natt => RFC only > --enable-natt-compat => RFC + draft 00 + draft 02 > Other drafts by adding --enable-natt_XX (and an > --enable-natt-bad-drafts ?) > > > * Solution 2 ("Manu's solution"): > > --enable-natt => RFC + Drafts 00-03 > --enable-natt-rfc => RFC only > Guess still --enable-natt_XX for the others (and/or > --enable-natt-bad-drafts ?) > > > * Solution 3: > > What is done now ? > > > * Hybrid Solution : > > --enable-natt => "compat" mode of solution 1 > --enable-natt-rfc => RFC only. > Still --enable-natt_XX for the others. I didn't vote for solutions: - Hybrid solution, or maybe Manu's Solution (but drafts 00 and 02 should be enough for most cases, including old ipsec-tools versions) for the 0.5 release, as it seems I'm the only one to suggest "my" solution. - "My" solution for next releases (starting from 0.6 or 0.7), when RFC support will be done by most products. Yvan. |
From: <ma...@ne...> - 2005-01-30 17:27:30
|
VANHULLEBUS Yvan <va...@fr...> wrote: > - "My" solution for next releases (starting from 0.6 or 0.7), when RFC > support will be done by most products. Even when most software editors will have published updated software that support the RFC, we'll still have older client software lying around. In most real life situation, it's difficult to have all the client upgraded to a given version. Of course, as a system administrator you can break backward compatibility to force an upgrade, but this costs time to everyone. While I consider it legitimate for security reasons, I find it unacceptable when it's just for aestethics reasons. That's why I'll still configure for drafts 00-04 and RFC even when clients with support for the RFC will be available. I guess many administrators will behave like me ("no need to force an upgrade of my clients if there is no problem to fix"), so that's why I'll still advocate for this setting to be the default later. But we can talk about this later :) -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz ma...@ne... |
From: VANHULLEBUS Y. <va...@fr...> - 2005-01-30 18:11:46
|
On Sun, Jan 30, 2005 at 06:27:27PM +0100, Emmanuel Dreyfus wrote: > VANHULLEBUS Yvan <va...@fr...> wrote: [....] > That's why I'll still configure for drafts 00-04 and RFC even when > clients with support for the RFC will be available. I guess many > administrators will behave like me ("no need to force an upgrade of my > clients if there is no problem to fix"), so that's why I'll still > advocate for this setting to be the default later. Once again, this is just a *default* configuration value, if an administrator wants to enable support for all drafts, he just have to recompile with specific configure options !!! And as I said before, quite all remote peers I saw supports draft 00 and/or draft 02, so unless someone knows a peers who only supports draft 01 and/or draft 03, there is no real need to include them in any default configuration. But once again, do what you all think is the best as the default config, as, for my own usage, I'll enable what I want by appropriate configure options in a Makefile..... Yvan. |
From: <ma...@ne...> - 2005-01-30 20:12:49
|
VANHULLEBUS Yvan <va...@fr...> wrote: > Once again, this is just a *default* configuration value, if an > administrator wants to enable support for all drafts, he just have to > recompile with specific configure options !!! Sure, but if you change the meaning of --enable-natt from everything to only RFC, you burn some admins that don't expect the change when they update.=20 That means loosing some time for them to discover why some of their client don't interoperate anymore and to discover how to re-enable it. That probably also means loosing our time because some admins will ask on the mailing list why it suddently broke with the new release. And this problem won't change with next releases. Of course you can warn about the problem in the documentation, but do you read the doc when you upgrade? I don't, I prefer getting burned and cursing at the bloody guy that broke backward compatibility :) In my opinion, once things are in a release, they should be considered as carved in the stone. The only exception for me would be security and interoperability issues. And this is why I think we should only remove the things that violate the RFC from --enable-natt. Thing that violate the RFC are drafts 05+, drafts 00-04 and RFC are RFC-compliant. =20 --=20 Emmanuel Dreyfus Publicit=E9 subliminale: achetez ce livre! http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php ma...@ne... |
From: Michal L. <mi...@lo...> - 2005-02-02 01:32:40
|
On Sun, 30 Jan 2005, Emmanuel Dreyfus wrote: > In my opinion, once things are in a release, they should be considered > as carved in the stone. The only exception for me would be security and > interoperability issues. > > And this is why I think we should only remove the things that violate > the RFC from --enable-natt. Thing that violate the RFC are drafts 05+, > drafts 00-04 and RFC are RFC-compliant. I completely agree with Manu. We must support RFC _in_addition_ to currently supported drafts in default config because - otherwise we confuse our users - new racoon should work with old racoon when compiled with the same config options - it doesn't break anything I'm fine with removing drafts 01 and 03 from default config because they are basically the same as 00 and 02. However 02_n should be kept. To make things more complicated, here is Michal's proposition :-) --enable-natt will enable 00, 02 and RFC --enable-natt=00,01,02,03,04,05,06,rfc will enable those specified drafts respectively. IMHO it's cleaner than to have tons of separate --enable-natt-dratf_NN switches. 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: VANHULLEBUS Y. <va...@fr...> - 2005-02-02 08:34:44
|
On Wed, Feb 02, 2005 at 02:32:33AM +0100, Michal Ludvig wrote: > On Sun, 30 Jan 2005, Emmanuel Dreyfus wrote: > > > In my opinion, once things are in a release, they should be considered > > as carved in the stone. The only exception for me would be security and > > interoperability issues. > > > > And this is why I think we should only remove the things that violate > > the RFC from --enable-natt. Thing that violate the RFC are drafts 05+, > > drafts 00-04 and RFC are RFC-compliant. > > I completely agree with Manu. We must support RFC _in_addition_ to > currently supported drafts in default config because > - otherwise we confuse our users > - new racoon should work with old racoon when compiled with the same > config options > - it doesn't break anything As you like. > I'm fine with removing drafts 01 and 03 from default config because they > are basically the same as 00 and 02. However 02_n should be kept. Actually, supoprt for VID_02 and VID_02n both depends on ENABLE_NATT_02. > To make things more complicated, here is Michal's proposition :-) > --enable-natt will enable 00, 02 and RFC That's what I called "hybrid proposition". > --enable-natt=00,01,02,03,04,05,06,rfc will enable those specified drafts > respectively. > > IMHO it's cleaner than to have tons of separate --enable-natt-dratf_NN > switches. I used separate --enable-natt_xx just because I am a configure.ac newbie, and just made some copy/pastes :-) I like the --enable-natt= syntax, but I think it would be better to *always* enable the RFC, no ? Yvan. |
From: <ma...@ne...> - 2005-02-03 00:04:51
|
VANHULLEBUS Yvan <va...@fr...> wrote: > I like the --enable-natt= syntax, but I think it would be better to > *always* enable the RFC, no ? No, you can't do that: NAT-T may infringe a patent in the US, so it's better to have it disabled by default so that nobody gets it by mistake. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz ma...@ne... |
From: VANHULLEBUS Y. <va...@fr...> - 2005-02-03 08:27:53
|
On Thu, Feb 03, 2005 at 01:04:44AM +0100, Emmanuel Dreyfus wrote: > VANHULLEBUS Yvan <va...@fr...> wrote: > > > I like the --enable-natt= syntax, but I think it would be better to > > *always* enable the RFC, no ? > > No, you can't do that: NAT-T may infringe a patent in the US, so it's > better to have it disabled by default so that nobody gets it by mistake. Sorry, that's not what I meant: "but I think it would be better to *always* enable the RFC as soon as --enable-natt is set". So setting --enable-natt=01 would *also* enable the RFC. Yvan. |
From: <ma...@ne...> - 2005-02-03 21:27:46
|
VANHULLEBUS Yvan <va...@fr...> wrote: > Sorry, that's not what I meant: "but I think it would be better to > *always* enable the RFC as soon as --enable-natt is set". Yes, and drafts 00-04... > So setting --enable-natt=01 would *also* enable the RFC. I'd rather understand --enable_natt=01 as only draft 01 and nothing else... -- Emmanuel Dreyfus Le cahier de l'admin BSD 2eme ed. est dans toutes les bonnes librairies http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php ma...@ne... |
From: VANHULLEBUS Y. <va...@fr...> - 2005-02-04 17:34:41
|
On Thu, Feb 03, 2005 at 10:27:43PM +0100, Emmanuel Dreyfus wrote: > VANHULLEBUS Yvan <va...@fr...> wrote: > > > Sorry, that's not what I meant: "but I think it would be better to > > *always* enable the RFC as soon as --enable-natt is set". > > Yes, and drafts 00-04... third try: "but I think it would be better to *always* enable the RFC as soon as --enable-natt is set, even if some drafts are specified with --enable-natt=xx syntax". > > So setting --enable-natt=01 would *also* enable the RFC. > > I'd rather understand --enable_natt=01 as only draft 01 and nothing > else... I don't understand why someone would want to enable some NATT support but disable Draft support... And as I think this would globally be a bad idea, I think it should NOT be possible to do that (and for now, that is NOT possible in the code, RFC support is enabled as soon as ENABLE_NATT is defined), or at least would require something more complex to be done (something like --enable-natt=xx --disable-natt-rfc, for example). Yvan. |
From: <ma...@ne...> - 2005-02-04 21:34:19
|
VANHULLEBUS Yvan <va...@fr...> wrote: > And as I think this would globally be a bad idea, I think it should > NOT be possible to do that=20 Why do you want to prevent ipsec-tools user from producing a particlar setup? Ok, neither you nor me see any interest of building with support for draft 02 without RFC, but - that costs us nothing to let the possibility of doing so =20 - the user can't do it without knowledge of what he is doing - that causes no harm to offer the possibility --=20 Emmanuel Dreyfus Publicit=E9 subliminale: achetez ce livre! http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php ma...@ne... |
From: Michal L. <mi...@lo...> - 2005-02-06 23:16:59
|
Emmanuel Dreyfus wrote: > VANHULLEBUS Yvan <va...@fr...> wrote: > > >>And as I think this would globally be a bad idea, I think it should >>NOT be possible to do that > > > Why do you want to prevent ipsec-tools user from producing a particlar > setup? Ok, neither you nor me see any interest of building with support > for draft 02 without RFC, but > - that costs us nothing to let the possibility of doing so > - the user can't do it without knowledge of what he is doing > - that causes no harm to offer the possibility Right, configure.ac shouldn't try to be more clever than the user. If the user says --enable-natt=00 and doesn't get rfc? OK, his fault. He should have said --enable-natt=00,rfc :-) BTW once you have all the infrastructure with --enable-natt_whatever I'll rewirte it to --enable-natt=wh,at,ev,er for your convenience ;-) OK? Michal |
From: VANHULLEBUS Y. <va...@fr...> - 2005-02-07 08:24:57
|
On Mon, Feb 07, 2005 at 12:16:45PM +1300, Michal Ludvig wrote: > Right, configure.ac shouldn't try to be more clever than the user. If > the user says --enable-natt=00 and doesn't get rfc? OK, his fault. He > should have said --enable-natt=00,rfc :-) As you like... > BTW once you have all the infrastructure with --enable-natt_whatever > I'll rewirte it to --enable-natt=wh,at,ev,er for your convenience ;-) > OK? Quite everything is ready, except a ENABLE_NATT_RFC define. I won't have time to do that this week, but if someone else wants to do it, it's very easy, you just have to search the other ENABLE_NATT_XX defines and do the same.... And don't forget to backport on HEAD... well, backport on branch 0.5, well, you all understand what I meant :-) Yvan. |