[ovs-dev] [RFC PATCH v1 1/3] vswitch.xml: Detail ipsec user interface.

Stokes, Ian ian.stokes at intel.com
Wed Jul 5 14:04:09 UTC 2017


> 
> Regards
> _Sugesh
> 
> 
> > -----Original Message-----
> > From: ovs-dev-bounces at openvswitch.org [mailto:ovs-dev-
> > bounces at openvswitch.org] On Behalf Of Ian Stokes
> > Sent: Thursday, May 18, 2017 10:16 AM
> > To: dev at openvswitch.org
> > Subject: [ovs-dev] [RFC PATCH v1 1/3] vswitch.xml: Detail ipsec user
> > interface.
> >
> > This commit adds details to the vswitch xml regarding the use of the
> > ipsec interface type. This patch is not intended for upstreaming and
> > simply seeks to solicit feedback on the user interface design of the
> > ipsec port type as described in the vswitch.xml.
> >
> > This modifies the vswitch.xml with a proposed ipsec interface. It also
> > provides details for the proposed interface options such as SPD
> > creation, SA creation and modification, Policy entries for the SPD as
> > well as traffic selctor options for the policy.
> >
> > Signed-off-by: Ian Stokes <ian.stokes at intel.com>
> > ---
> >  vswitchd/vswitch.xml |  222
> > ++++++++++++++++++++++++++++++++++++++++++++++++++
> >  1 files changed, 222 insertions(+), 0 deletions(-)
> >
> > diff --git a/vswitchd/vswitch.xml b/vswitchd/vswitch.xml index
> > bb66cb5..a537911 100644
> > --- a/vswitchd/vswitch.xml
> > +++ b/vswitchd/vswitch.xml
> > @@ -2191,6 +2191,12 @@
> >              A pair of virtual devices that act as a patch cable.
> >            </dd>
> >
> > +          <dt><code>ipsec</code></dt>
> > +          <dd>
> > +            An interface type to provide IPsec RFC4301 functionality
> for
> > +            traffic at the IP layer, initially for IPv4 environments.
> [Sugesh] I am not sure how an ipsec interface works with vxlan tunneling.
> The userspace tunneling send traffic to corresponding phy bridge based on
> tunnel address.
> Now we have one more interface(ipsec) down the tunnel interface?
> Can you please provide a simple diagram with ports and bridges that
> explain how VM to VM ipsec tunnel connection works between two hosts.
> Another point is about the recirculation, does the packet need to
> recirculate again after the encrypt/decrypt?
> 
> 
> > +          </dd>
> > +
> >            <dt><code>null</code></dt>
> >            <dd>An ignored interface. Deprecated and slated for removal
> in
> >            February 2013.</dd>
> > @@ -2510,6 +2516,222 @@
> >        </column>
> >      </group>
> >
> > +    <group title="IPsec">
> > +      <p>
> > +        Only <code>ipsec</code> interfaces support these options.
> > +      </p>
> > +
> > +      <column name="options" key="spd_id" type='{"type": "string"}'>
> > +      <p>
> > +        Must be an identifier for the SPD that is to be used by this
> IPsec
> > +        interface. If no SPD exists with this ID then it will be
> created.
> > +      </p>
> > +      </column>
> > +
> > +      <column name="options" key="sa_id" type='{"type": "string"}'>
> > +      <p>
> > +        An identifier representing the ID of a Security Association.
> > +        If no SA with this ID exists it will be created.
> > +      </p>
> > +      </column>
> > +
> > +      <column name="options" key="sa_spi" type='{"type": "string"}'>
> > +      <p>
> > +        A 32 bit number representing the security policy index for
> > +        the SA.
> > +      </p>
> > +      </column>
> > +
> > +      <column name="options" key="ipsec_mode" type='{"type":
> "string"}'>
> > +      <p>
> > +        The IPsec mode that applies to the SA, one of:
> > +      </p>
> > +        <ul>
> > +          <li>
> > +            <code>transport</code>: Provide protection primarily for
> next
> > +            layer protocols.
> > +          </li>
> > +          <li>
> > +            <code>tunnel</code>: Provide protection to IP layer also
> (applied
> > +            to tunneled IP packets).
> > +          </li>
> > +        </ul>
> > +      <p>
> > +        Initially only support for transport mode will be implemented.
> > +      </p>
> > +      </column>
> > +
> > +      <column name="options" key="sa_protocol" type='{"type":
> "string"}'>
> > +      <p>
> > +        The security protocol used for IPsec, one of the following:
> > +      </p>
> > +        <ul>
> > +          <li>
> > +            <code>ESP</code>: Encapsulating Security Payload.
> > +          </li>
> > +          <li>
> > +            <code>AH</code>: Authentication header
> > +          </li>
> > +        </ul>
> > +      <p>
> > +        Initially only ESP is supported, users can implement
> authentication
> > +        communication only by setting the encryption algorithm to NULL
> for ESP
> > +        but specifying the integrity algorithm. In this way there is no
> need
> > +        to support AH. If this is acceptable to the OVS community then
> this
> > +        option could be removed as it will always be ESP.
> [Sugesh] I think it looks ok to me.
> > +      </p>
> > +      </column>
> > +
> > +      <column name="options" key="crypto_alg" type='{"type":
> "string"}'>
> > +      <p>
> > +        The encryption algorithm used for IPsec, one of the following:
> > +      </p>
> > +        <ul>
> > +          <li>
> > +            <code>NULL</code>: No encryption. Note NULL is required for
> the
> > +            use of ESP with authentication only which is preferred over
> AH
> > +            due to NAT traversal.
> > +          </li>
> > +          <li>
> > +            <code>AES_CBC</code>: AES_CBC is a non-AEAD algorithm.
> > + Note
> > users
> > +            MUST specify an authentication algorithm to check
> integrity.
> > +          </li>
> > +          <li>
> > +            <code>AES_GCM_16</code>: An AEAD algorithm. This allows
> > + the use
> > of
> > +            ESP with a combined mode cipher that handles
> encryption/decryption
> > +            and authentication in a single step. Recommended for
> performance.
> > +          </li>
> > +        </ul>
> > +      </column>
> > +
> > +      <column name="options" key="crypto_key" type='{"type":
> "string"}'>
> > +      <p>
> > +        A crypto key specifies the transformation of plaintext into
> cipher
> > +        text for the encryption algorithm. Alphanumeric user generated
> string.
> > +        IPsec sessions may have very long life time, and carry multiple
> > +        packets, where possible 128-bit or 256-bit keys should be used.
> [Sugesh] I feel this should be a flow item. Is that possible having same
> SA to use Different keys? Does openflow supports ipsec SA or SP
> definitions.

I wouldn't think so, I envisioned the SA as containing the key to be used for particular traffic selector (or flow in this case).

> I remember seeing some of the proposal in Internet. Some of the vendors do
> support Ipsec extension on top of openflow v1.4? Any plan on support
> those?

I wasn't aware of this, can you share info on where you spotted these?

> 
> If yes, these fields can be either flow/value.
> > +      </p>
> > +      </column>
> > +
> > +      <column name="options" key="auth_alg" type='{"type": "string"}'>
> > +      <p>
> > +        Optional. Represents the authentication algorithm to be used
> for
> > +        IPsec. Depending on the encryption algorithm that is chosen a
> user
> > +        may have to specify a separate authentication algorithm.  This
> > +        typically occurs when communications are encrypted with non-
> AEAD
> > +        algorithm which MUST be combined with an authentication
> algorithm.
> > +        Can be one of the following:
> > +      </p>
> > +        <ul>
> > +          <li>
> > +            <code>NULL</code>: No authentication algorithm. Must only
> > + be
> > used
> > +            when the encryption is done with an AEAD algorithm.
> > +          </li>
> > +          <li>
> > +            <code>HMAC_SHA2_256_128</code>: Should be selected when a
> > non AEAD
> > +            algorithm is used for encryption.
> > +          </li>
> > +      </column>
> > +
> > +      <column name="options" key="auth_key" type='{"type": "string"}'>
> > +      <p>
> > +        Required if an auth_alg has been specificed. An authentication
> key
> > +        specifies the transformation of plaintext into cipher text for
> the
> > +        authentication algorithm. An alphanumeric user generated
> string. IPsec
> > +        sessions may have very long life time, and carry multiple
> packets,
> > +        where possible 128-bit or 256-bit keys should be used.
> > +      </p>
> > +      </column>
> > +
> > +      <column name="options" key="policy_priority" type='{"type":
> > "integer"}'>
> > +      <p>
> > +        Represents the policy order for an entry in the SPD.
> > +      </p>
> > +      </column>
> > +
> > +      <column name="options" key="" type='{"type": "string"}'>
> > +      <p>
> > +        A string representing whether the policy is applied to inbound
> or
> > +        outbound traffic. Can be one of the following:
> > +      </p>
> > +        <ul>
> > +          <li>
> > +            <code>inbound</code>
> > +          </li>
> > +          <li>
> > +            <code>outbound</code>
> > +          </li>
> > +      </column>
> > +
> > +      <column name="options" key="policy_action" type='{"type":
> "string"}'>
> > +      <p>
> > +        The policy action to take. Can be one of the following:
> > +      </p>
> > +        <ul>
> > +          <li>
> > +            <code>bypass</code>: IPsec transformation is not applied to
> > +            traffic and traffic continues as normal.
> > +          </li>
> > +          <li>
> > +            <code>discard</code>: Traffic is dropped.
> > +          </li>
> > +          <li>
> > +            <code>protect</code>: An IPsec transformation is applied to
> the
> > +            traffic. Note if action is 'protect' then the policy_sa
> option
> > +            must also be specified.
> > +          </li>
> > +      </column>
> > +
> > +      <column name="options" key="policy_sa" type='{"type": "string"}'>
> > +      <p>
> > +        Required if the action for a policy is protect. The policy_sa
> should
> > +        match an sa_id specified which contains the correct
> transformations.
> > +      </p>
> > +      </column>
> > +
> > +      <column name="options" key="ts_local_ip_range"
> > +              type='{"type": "string"}'>
> > +      <p>
> > +        Optional. This represents the range of local IP addresses for
> the
> > +        traffic selector to examine a packet for. Should be in the form
> of
> > +        <code> start_ip_addr - end_ip_addr </code>
> > +      </p>
> > +      </column>
> > +
> > +      <column name="options" key="ts_remote_ip_range"
> > +              type='{"type": "string"}'>
> > +      <p>
> > +        Optional. This represents the range of remote IP addresses for
> the
> > +        traffic selector to examine a packet for. Should be in the form
> of
> > +       <code> start_ip_addr - end_ip_addr </code>
> > +      </p>
> > +      </column>
> > +
> > +      <column name="options" key="ts_protocol" type='{"type":
> "string"}'>
> > +      <p>
> > +        Optional. This represents the traffic selector next layer
> protocol
> > +        identifier to examine for before taking action.
> > +      </p>
> > +      </column>
> > +
> > +      <column name="options" key="ts_local_port_range"
> > +              type='{"type": "string"}'>
> > +      <p>
> > +        Optional. This represents the range of local port ranges for
> the
> > +        traffic selector to examine a packet for.
> > +      </p>
> > +      </column>
> > +
> > +      <column name="options" key="ts_remote_port_range"
> > +              type='{"type": "string"}'>
> > +      <p>
> > +       This represents the range of remote port range for the traffic
> selector
> > +       to examine a packet for.
> > +      </p>
> > +      </column>
> > +
> > +    </group>
> > +
> >      <group title="MTU">
> >        <p>
> >          The MTU (maximum transmission unit) is the largest amount of
> > data
> [Sugesh] Another monor suggestion is I would like to see, how its looks
> like for the ovs-vsctl command?
> May be its nice to have mention it in the commit message. Not very
> important though.
> 
> 
> > --
> > 1.7.0.7
> >
> > _______________________________________________
> > dev mailing list
> > dev at openvswitch.org
> > https://mail.openvswitch.org/mailman/listinfo/ovs-dev


More information about the dev mailing list