[MidoNet-dev] Draft proposal: IPsec in midonet
guillermo at midokura.jp
Thu Feb 14 09:41:44 UTC 2013
On Wed, Feb 13, 2013 at 10:44 PM, Jacob Mandelson <jlm at midokura.com> wrote:
> Hi Guillermo,
> > I'm including below my initial discussion about adding IPsec
> > support for midonet.
> I think this needs to emphasize that it's supporting IPSec VPNs only,
> and not any other pieces of the IPSec suite. (If I see "Supports
> IPSec" with no modifier, I expect it to terminate ESP, verify AH, and
> perform IKE.)
Yeah, good point. To be specific, implementing the current proposal would
* IKE (validation via PSK only, no certificates)
* ESP termination.
* So called 'route-based' VPNs with BGP. (this is what I call 'dynamic'
in my proposal.
* (maybe) 'policy-based' VPNs (what I call 'static' in my proposal.
I'll add it to the feature description.
> > - Statically add SA's localnet-0.0.0.0/0. Meaning that anytime the
> > IPsec instance sees a packet coming from one of the known local
> > networks the tuple of that network with 0.0.0.0/0 will match and let
> > the traffic through.
> Will this cause problems for IPSec traffic which isn't part of the VPN?
I think it ought to work because a) only packets with a source in
'localsubnets' would match those policies and b) the virtual router should
only give the ipsec gateway traffic that matches routes negotiated by BGP
through the tunnel. In other words, the IPsec gateway would see these types
* Generated by the BGP daemon with src=link-local-address, going through
* Generated out of the public IP address (IKE, ESP traffic, DNS, ...), it
would never match the SPDB, never encrypted.
* Forwarded traffic that comes from the tunnel or should be put into the
> > - IKE pre-shared key.
> If you have a pre-shared key, why perform IKE?
The PSK is not used for traffic encryption, it is used in IKE to
authenticate both sides, the IKE negotiation then moves on to setting up
and refreshing ESP keys.
> > - IPsec connection parameters: PFS mode, hash function, encryption
> > function. Amazon is very strict on this, requiring exactly:
> > Group-2, SHA-1, AES-128. IMHO that's a correct philosophy,
> > sticking to the common minimum. If midonet is as strict as Amazon
> > the user doesn't need to supply this.
> Could we use being more flexible as a selling point, for those that
> want to use (eg) SHA-2 instead?
I guess that depends on what people ask for. My very personal opinion is
that there's little value in vendors offering a gazillion crypto and hash
algorithms, and that it does clutter configuration and creates opportunity
for mismatches between both sides of the connection. Anyway, adding a new
alg (within those supported by the IKE deamon and the kernel) would just
mean a change in the REST API to allow writing those values.
Thanks for the writeup Guillermo, Jacob
-- Guillermo Ontañón
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the MidoNet-dev