swIPe

-----BEGIN PGP SIGNED MESSAGE-----

Has anything been happening with swIPe lately?  I seem to remember reading
a couple of months ago that the protocol was being revised (simplified?) 
and that a new RFC was going to be released soon.  What's the status of 
the project now?

==
Alex Strasheim | finger astrashe@nyx.cs.du.edu
alex@omaha.com | for my PGP 2.6.1. public key

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBLuUFUREpP7+baaPtAQGKGQP/UN7bJfYOHIEdgV9uDnJLbJ00q4J/opLW
KpDxF+yl4Nhld70YkMQ/xJ9CeGh0mrCNLz/O8nD4KLrJ87RnH2T1fMV6vdegEvxF
CnDEOyRCSEa3kB3c1mkP5rtvW9PJF6GiqDkbaA86wa2usBkuv63mZjPc4EVLiZwY
+0xew1PgMQs=
=oHAW
-----END PGP SIGNATURE-----

Alex Strasheim says:
> Has anything been happening with swIPe lately?  I seem to remember reading
> a couple of months ago that the protocol was being revised (simplified?) 
> and that a new RFC was going to be released soon.  What's the status of 
> the project now?

Asking this *during* the IETF meeting is bad timing. Ask the question
again in a week...

.pm

>-----BEGIN PGP SIGNED MESSAGE-----
>
>Has anything been happening with swIPe lately?  I seem to remember reading
>a couple of months ago that the protocol was being revised (simplified?) 
>and that a new RFC was going to be released soon.  What's the status of 
>the project now?
>
>==
>Alex Strasheim | finger astrashe@nyx.cs.du.edu
>alex@omaha.com | for my PGP 2.6.1. public key
>
>-----BEGIN PGP SIGNATURE-----
>Version: 2.6.2
>
>iQCVAwUBLuUFUREpP7+baaPtAQGKGQP/UN7bJfYOHIEdgV9uDnJLbJ00q4J/opLW
>KpDxF+yl4Nhld70YkMQ/xJ9CeGh0mrCNLz/O8nD4KLrJ87RnH2T1fMV6vdegEvxF
>CnDEOyRCSEa3kB3c1mkP5rtvW9PJF6GiqDkbaA86wa2usBkuv63mZjPc4EVLiZwY
>+0xew1PgMQs=
>=oHAW
>-----END PGP SIGNATURE-----

Well, if by swIPe you mean the standards-track IP security protocol,
quite a bit.  I'm not going to the next IETF meeting (perry?, phil?)
but I understand that swIPe and friends have mutated into something
that is very close to becoming an RFC.  Key management is another
story, with no general agreement as to what the requirements even are.
My own feeling is that more experience is needed with network-layer
security in general before the problems and tradeoffs of key managment
in heterogeneous networks will emerge with any clarity.

If you mean swIPe, the protocol described in Ioannidis and Blaze's
draft RFC of last December, not much.  There's an implementation
floating around (I think on the ucb ftp server), but I don't know
of anyone who's actively deploying it outside of closed systems.

Now would is a very good time to play with this stuff, particularly with
an eye toward understanding what the key management requirements are.
Right now the future internet cryptographic security architecture is wide
open, but that window is starting to close.

-matt

Matt Blaze says:
> Well, if by swIPe you mean the standards-track IP security protocol,
> quite a bit.  I'm not going to the next IETF meeting (perry?, phil?)
> but I understand that swIPe and friends have mutated into something
> that is very close to becoming an RFC.

True.

> Key management is another story, with no general agreement as to
> what the requirements even are.

Less true; there are multiple proposals, but none of them meet my
internal standards on what is needed :-)

> My own feeling is that more experience is needed with network-layer
> security in general before the problems and tradeoffs of key managment
> in heterogeneous networks will emerge with any clarity.

I would partially agree. We do have some actual real world experience
with one key management and authentication system -- Kerberos. Its not
sufficient, but it does provide a lot of interesting lessons. In
particular, it has a distinct advantage over most the the currently
proposed key management systems in the IETF: it is actually possible
to write secure applications with Kerberos. (This is not as bad as it
sounds; there are still ways to use the proposed key management
systems (for setting up encrypted tunnels as an example) but these
uses are more limited.)

> If you mean swIPe, the protocol described in Ioannidis and Blaze's
> draft RFC of last December, not much.  There's an implementation
> floating around (I think on the ucb ftp server), but I don't know
> of anyone who's actively deploying it outside of closed systems.

Actually, swIPe the implementation has been ported to three systems
(largely berkeley clones) and is being actively sold as part of the
TIS firewall product. However, its future with its current packet
format is obviously limited. swIPe the packet format is quite dead,
but swIPe the implementation will probably be hacked to support the
IPSP protocol, whatever it ends up being in the end.

> Now would is a very good time to play with this stuff, particularly with
> an eye toward understanding what the key management requirements are.
> Right now the future internet cryptographic security architecture is wide
> open, but that window is starting to close.

Quite true.

Perry