| Message ID | 1495098956-18012-2-git-send-email-ian.stokes@intel.com |
|---|---|
| State | Changes Requested |
| Headers | show |
Regards _Sugesh > -----Original Message----- > From: ovs-dev-bounces@openvswitch.org [mailto:ovs-dev- > bounces@openvswitch.org] On Behalf Of Ian Stokes > Sent: Thursday, May 18, 2017 10:16 AM > To: dev@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@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 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? 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@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-dev
> > Regards > _Sugesh > > > > -----Original Message----- > > From: ovs-dev-bounces@openvswitch.org [mailto:ovs-dev- > > bounces@openvswitch.org] On Behalf Of Ian Stokes > > Sent: Thursday, May 18, 2017 10:16 AM > > To: dev@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@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@openvswitch.org > > https://mail.openvswitch.org/mailman/listinfo/ovs-dev
On 18 May 2017 at 02:15, Ian Stokes <ian.stokes@intel.com> wrote: > 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@intel.com> Thanks for proposing this. See my comments inline. > --- > 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. > + </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> Is it possible to do seamless rekeying with this design? If I understand correctly, then in your ER model you have 1:1 mapping between Interface rows and SPIs. Seamless rekeying is typically implemented by allowing two key pairs to coexist for short time and then keying daemon shortly wipes out the old keys. This kinda implies that you need to create a new table for IPsec keys opposed to trying to attach it as an attribute to the Interface table. > + > + <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. > + </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. Would it be better to request keys in hex format opposed to alphanumeric, because: 1. that is how ip-xfrm interface works; AND 2. with alphanumeric it may be hard to get key sizes to 128 bits etc > + </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 > -- > 1.7.0.7 > > _______________________________________________ > dev mailing list > dev@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-dev
> On 18 May 2017 at 02:15, Ian Stokes <ian.stokes@intel.com> wrote: > > 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@intel.com> > > Thanks for proposing this. See my comments inline. No problem, thanks for the feedback. I hadn’t spotted these until today and I have since sent out a v2 of the rfc with some very basic code to allow some functional testing of the crypto/authentication aspects of DPDK in OVS. https://mail.openvswitch.org/pipermail/ovs-dev/2017-August/337919.html See comments inline below. > > --- > > 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. > > + </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> > Is it possible to do seamless rekeying with this design? > > If I understand correctly, then in your ER model you have 1:1 mapping > between Interface rows and SPIs. Seamless rekeying is typically > implemented by allowing two key pairs to coexist for short time and then > keying daemon shortly wipes out the old keys. > > This kinda implies that you need to create a new table for IPsec keys > opposed to trying to attach it as an attribute to the Interface table. No, seamless rekeying isn't possible with this design, initially I'm going to target static key setup. Down the line though I would like keying to be handled by a key daemon such as strong swan or open swan. I have to look in to how this could be achieved. There already is a userspace plugin in Open Swan, possibly we could hook into that. That work would be further down the line however than the initial proposal. > > > + > > + <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. > > + </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. > Would it be better to request keys in hex format opposed to alphanumeric, > because: > 1. that is how ip-xfrm interface works; AND 2. with alphanumeric it may be > hard to get key sizes to 128 bits etc > Good idea, I'll take that onboard for the next revision. > > > > + </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 > > -- > > 1.7.0.7 > > > > _______________________________________________ > > dev mailing list > > dev@openvswitch.org > > https://mail.openvswitch.org/mailman/listinfo/ovs-dev
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. + </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. + </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. + </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
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@intel.com> --- vswitchd/vswitch.xml | 222 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 222 insertions(+), 0 deletions(-)