On Sun, Jul 30, 2006 at 01:42:48PM -0400, der Mouse wrote: > >> I know there are those here who believe that IPsec is the wrong > >> strategy for application security. For these protocols, that ship > >> has sailed: we have approved proposed standards that use IPsec. > >> This predates my involvement in the IESG. Now we must provide > >> usable security based on these existing decisions. > > Now first, I want to be clear that I have no opinion on whether IPsec > actually *is* a wrong strategy for application security; I do not know > enough to consider myself competent to hold an opinion on that. > > But it does seem to me that there *always* needs to be a mechanism for > backing out of past mistakes, if they prove to be mistakes - and this > appears to be saying that there is none here. There always is such a mechanism: specify a new version of the thing that had a mistake in it and implement it, then deploy it. The worst case is you need flag days. Usually we find ways to avoid flag days, because flag days are really, really inconvenient, to the point of being utterly impractical. Now, in the case of applications that rely on IPsec and which do so in poor ways, there will likely be ways to fix them that do not require flag days. Specifically the work of the BTNS WG, namely, the work on IPsec APIs, should provide an upgrade path for such applications that does not involve flag days. > Surely *that* needs to be fixed first? Or am I wrong, and the IETF > considers itself unable to rectify past mistakes? "First"? Before... what, figuring out how to use IPsec in softwires? I think the applications that Sam was talking about (e.g., iSCSI, I think) and softwires are sufficiently different that fixing those applications should have no impact on the softwares w/ IPsec work, thus there'd be no benefit to fixing those applications first. Nico --
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.