> 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.
> nce 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.

So would this solution be compatible with the existing Cisco solutions that 
many companies have?
 
 
This message posted from opensolaris.org
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Reply via email to