<div class="gmail_quote">On Fri, Feb 15, 2013 at 1:46 AM, Navarro, Abel <span dir="ltr"><<a href="mailto:abel@midokura.com" target="_blank">abel@midokura.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Hi, I think you guys are talking about the same concepts. Let me see if I understand correctly:<div><br></div><div>Requirement: be able to connect to Amazon VPN</div><div><br></div><div>We MUST:</div>
<div>- Offer ESP termination</div></div></blockquote><div><br>To clarify, we must terminate ESP (for VPN traffic), but offering ESP termination (for other services) would be a different feature, one that should be able to re-use some of the IPSec VPN work if we get around to it.<br>
What "offering ESP termination" makes me think of is a scenario like this:<br>    * Client has a service that requires cryptographic protection on the public internet, so accepts only ESP traffic<br>    * Client runs multiple servers as guests in a MinoNet cloud to provide the service<br>
    * Because MN offers ESP termination, it decrypts the ESP'd traffic and balances it among the servers<br><br>I don't think it's important to be offering this, but it's what I understand when a product says it offers ESP termination.<br>
<br>I do think it's important to not interfere with a guest terminating ESP traffic for an address in case a client wants to do ESP termination themselves, for some non-VPN thing.<br><br>    -- Jacob<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div>- Offer IKE, for authentication coordination</div><div><br></div><div>We SHOULD:</div><div>- Offer BGP failover on routes over ESP</div><div><br></div>
<div>We MAY:</div><div>- Offer AH</div><div>- Offer other IPsec suite capabilities</div><div><br></div><div><pre style="white-space:pre-wrap;word-wrap:break-word">      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
      "OPTIONAL" in this document are to be interpreted as described in
      RFC 2119.</pre><pre style="white-space:pre-wrap;word-wrap:break-word"><br></pre></div><div>--</div><div>abel</div><div><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">

On Thu, Feb 14, 2013 at 10:52 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">

<div class="gmail_quote"><div>On Thu, Feb 14, 2013 at 1:41 AM, Guillermo Ontañón <span dir="ltr"><<a href="mailto:guillermo@midokura.jp" target="_blank">guillermo@midokura.jp</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div dir="ltr">Hi Jacob,<div><div class="gmail_extra"><br><div class="gmail_quote"><div>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><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><div>Yeah, good point. To be specific, implementing the current proposal would mean:</div><div>



<br></div><div>  * IKE (validation via PSK only, no certificates)</div><div>  * ESP termination.</div><div>  * So called 'route-based' VPNs with BGP. (this is what I call 'dynamic' in my proposal.</div>
<div>  * (maybe) 'policy-based' VPNs (what I call 'static' in my proposal.</div><div><br></div><div>I'll add it to the feature description.</div></div></div></div></div></blockquote></div><div><br>As I understand your proposal, it terminates ESP (specifically, it has the host OS terminate it), but only for VPN traffic.  This seems to fall shy of "ESP termination" sans modifiers.  For that, I'd expect MidoNet to be able to receive ESP traffic for a public address it manages and send its payload to the internal address.  Though with us terminating ESP for the VPN, we should be able to build on that to providing ESP termination for external/internal addresses.<span><font color="#888888"><br>


<br>     -- Jacob<br></font></span></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br>