<div dir="ltr">Hi Jacob,<div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 13, 2013 at 10:44 PM, Jacob Mandelson <span dir="ltr"><<a href="mailto:jlm@midokura.com" target="_blank">jlm@midokura.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Guillermo,<div class="im"><br><br>> I'm including below my initial discussion about adding IPsec<br>> support for midonet.<br>
<br></div>    I think this needs to emphasize that it's supporting IPSec VPNs only,<br>and not any other pieces of the IPSec suite.  (If I see "Supports<br>
IPSec" with no modifier, I expect it to terminate ESP, verify AH, and<br>perform IKE.)</blockquote><div><br></div><div style>Yeah, good point. To be specific, implementing the current proposal would mean:</div><div style>
<br></div><div style>  * IKE (validation via PSK only, no certificates)</div><div style>  * ESP termination.</div><div style>  * So called 'route-based' VPNs with BGP. (this is what I call 'dynamic' in my proposal.</div>
<div style>  * (maybe) 'policy-based' VPNs (what I call 'static' in my proposal.</div><div style><br></div><div style>I'll add it to the feature description.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>>   - Statically add SA's localnet-0.0.0.0/0. Meaning that anytime the<br>>     IPsec instance sees a packet coming from one of the known local<br>
>     networks the tuple of that network with <a href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a> will match and let<br>>     the traffic through.<br><br></div>Will this cause problems for IPSec traffic which isn't part of the VPN?<br>
</blockquote><div><br></div><div style>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 of traffic:</div>
<div style><br></div><div style>  * Generated by the BGP daemon with src=link-local-address, going through the tunnel.</div><div style>  * Generated out of the public IP address (IKE, ESP traffic, DNS, ...), it would never match the SPDB, never encrypted.</div>
<div style>  * Forwarded traffic that comes from the tunnel or should be put into the tunnel. </div><div style><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>>    - IKE pre-shared key.<br><br>If you have a pre-shared key, why perform IKE?</blockquote><div><br></div><div style>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">>     - IPsec connection parameters: PFS mode, hash function, encryption<br>>       function. Amazon is very strict on this, requiring exactly:<br>

>       Group-2, SHA-1, AES-128. IMHO that's a correct philosophy,<br>>       sticking to the common minimum. If midonet is as strict as Amazon<br>>       the user doesn't need to supply this.<br><br></div>
Could we use being more flexible as a selling point, for those that<br>
want to use (eg) SHA-2 instead?<br></blockquote><div><br></div><div style>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.</div>
<div style> </div><div style>Cheers,</div><div style>G</div><div style><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">    Thanks for the writeup Guillermo,       Jacob<br>

</blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">-- Guillermo Ontañón</div>
</div></div></div>