Hello!
I don't read this alias normally, but I was pointed to it by folks. I'm also
using JIVE to read this one instead of my normal e-mail.
Punchin started its life as a test-tool for Solaris IPsec and IKE during the S9
bringup of IKE(v1). Punchin is different than other remote-access solutions
because it doesn't augment IKE to perform user authentication and
internal-address deployment. If one were to put the all-seeing packet sniffer
(with a small amount of client and server observability, too) between a punchin
client and server, you'd see something like this:
* IKE Phase I (self-signed certificates)
* IKE QM for diagnostic ping
* ESP-protected ping
* IKE QM for UDP port 2112 for setup (maybe TCP coming soon)
* ESP-protected UDP port 2112 exchange
- Request
- Challenge (e.g. "Password" or Token-card challenge)
- Response
- Failure or Success(with internal IP address)
(client then rewhacks routing tables and plumbs an ip.tun0, server plumbs
an ip.tunN)
* IKE QM for Tunnel Mode, internal-local==previously-asssigned,
internal-remote==default
* ESP-protected internal traffic.
Once we got NAT-Traversal working and we discovered cisco wasn't going to do an
Sol x86 client, punchin took on a life of its own within Sun. We've also found
bugs in other IPsec implementations while attempting to port punchin to those
platforms.
Punchin's nice because it's just a set of scripts and one binary application
(two if you're using MacOS X) that control the OS's built-in IPsec
functionality. Most "VPN clients" require kernel modules that have varying
levels of stability or rely on undocumented or unstable interfaces. You'll
never get a kernel panic with punchin unless your OS is broken (which is why
punchin is such a nice test tool for Solaris/OpenSolaris).
We haven't open-sourced it mostly because it's not Team IPsec's day jobs. One
idea we've been kicking around is putting the source in /usr/demo ala. the
DTrace or MDB examples. Nothing we do in punchin is encumbered (even though
our IKEv1 is encumbered w.r.t. source only), so it's just a matter of time and
resources, something we're short on with Labelled IPsec and IKEv2 + RFC 430x
coming up.
BTW, our IKEv2 will be open-source, and if you hang out on networking- or
security- discuss we'll have something to say there soon. Also, IKEv2 has the
IKEv1 hacks baked-into the spec, so punchin's functionality could (and probably
should) be subsumed by a decent IKEv2 implementation.
Does that answer everyone's questions?
Dan McD.
This message posted from opensolaris.org
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
