[ovs-dev] [PATCH v4 9/9] Documentation: OVN RBAC and IPsec tutorial

Ben Pfaff blp at ovn.org
Thu Aug 2 18:32:49 UTC 2018


Thanks for the comments.  Can you integrate my suggestions and your
comments for v5?

Thanks,

Ben.

On Wed, Aug 01, 2018 at 05:28:02PM -0700, Qiuyu Xiao wrote:
> Thanks Ben! I made a few comments below. Other than that, all looks pretty good!
> 
> -Qiuyu
> 
> On Wed, Aug 1, 2018 at 10:03 AM, Ben Pfaff <blp at ovn.org> wrote:
> > On Tue, Jul 31, 2018 at 02:08:54PM -0700, Qiuyu Xiao wrote:
> >> This patch adds step-by-step guide for configuring OVN Role-Based Access
> >> Control and IPsec.
> >>
> >> Signed-off-by: Qiuyu Xiao <qiuyu.xiao.qyx at gmail.com>
> >
> > You wrote a lot of documentation, and it's really good!  Thank you.
> >
> > I spent some time working to make it even better.  I'm appending an
> > incremental that I'd suggest folding in.  Does it make sense to you?
> >
> > Thanks,
> >
> > Ben.
> >
> > --8<--------------------------cut here-------------------------->8--
> >
> > diff --git a/Documentation/howto/ipsec.rst b/Documentation/howto/ipsec.rst
> > index 17dead5010cf..32e55b5acd0d 100644
> > --- a/Documentation/howto/ipsec.rst
> > +++ b/Documentation/howto/ipsec.rst
> > @@ -48,7 +48,10 @@ OVS IPsec aims to provide a simple interface for user to add encryption on OVS
> >  tunnels. It supports GRE, GENEVE, VXLAN, and STT tunnel. The IPsec
> >  configuration is done by setting options of the tunnel interface and
> >  other_config of Open_vSwitch. You can choose different authentication methods
> > -and fowarding modes based on your system requirement.
> > +and forwarding modes based on your requirements.
> > +
> > +OVS does not currently provide any support for IPsec encryption for traffic not
> > +encapsulated in a tunnel.
> >
> >  Configuration
> >  -------------
> > @@ -59,7 +62,7 @@ Authentication Methods
> >  Hosts of the IPsec tunnel need to authenticate each other to build a secure
> >  channel. There are three authentication methods:
> >
> > -1) You can use pre-shared key (PSK) to do authentication. In both hosts, set
> > +1) You can use a pre-shared key (PSK) to do authentication. In both hosts, set
> >     the same PSK value. This PSK is like your password. You should never reveal
> >     it to untrusted parties. This method is easier to use but less secure than
> >     the certificate-based methods::
> > @@ -72,9 +75,9 @@ channel. There are three authentication methods:
> >
> >     .. note::
> >
> > -      The local_ip field is required for the IPsec tunnel.
> > +      The ``local_ip`` field is required for the IPsec tunnel.
> >
> > -2) You can use self-signed certificate to do authentication. In each host,
> > +2) You can use a self-signed certificate to do authentication. In each host,
> >     generate a certificate and the paired private key. Copy the certificate of
> >     the remote host to the local host and configure the OVS as following::
> >
> > @@ -98,6 +101,10 @@ channel. There are three authentication methods:
> >        follow the tutorial in :doc:`/tutorials/ipsec` and use ovs-pki(8) to
> >        generate compatible certificate and key.
> >
> > +      (Before OVS version 2.10.90, ovs-pki(8) did not generate x.509 v3
> > +      certificates, so if your existing PKI was generated by an older version,
> > +      it is not suitable for this purpose.)
> > +
> >  3) You can also use CA-signed certificate to do authentication. First, you need
> >     to create a CA certificate and sign each host certificate with the CA key
> >     (please see :doc:`/tutorials/ipsec`). Copy the CA certificate to each
> > @@ -133,8 +140,8 @@ actually taking affect to encrypt packets. To offset the risk of unencrypted
> >  packets leaking out during this period, you can choose a more secure forwarding
> >  mode.  There are three forwarding modes:
> >
> > -1) The default mode allows unencrypted packets being sent out before IPsec
> > -   taking effect::
> > +1) The default mode allows unencrypted packets to be sent before IPsec
> > +   completes negotiation::
> >
> >       $ ovs-vsctl add-port br0 ipsec_gre0 -- \
> >                    set interface ipsec_gre0 type=gre \
> > @@ -146,7 +153,7 @@ mode.  There are three forwarding modes:
> >     and/or if there is firewall that can drop the plain packets that
> >     occasionally leak the tunnel unencrypted on OVSDB (re)configuration events.
> >
> > -2) The ipsec_skb_mark mode filters unencrypted packets by using skb mark of
> > +2) The ipsec_skb_mark mode drops unencrypted packets by using skb_mark of
> >     tunnel packets::
> >
> >       $ ovs-vsctl set Open_vSwitch . other_config:ipsec_skb_mark=0/1
> > @@ -156,15 +163,15 @@ mode.  There are three forwarding modes:
> >                                      options:remote_ip=2.2.2.2 \
> >                                      options:psk=swordfish
> >
> > -   OVS IPsec filters unencrypted packets which carry the same skb mark as
> > +   OVS IPsec drops unencrypted packets which carry the same skb_mark as
> >     `ipsec_skb_mark`. By setting the ipsec_skb_mark as 0/1, OVS IPsec prevents
> > -   all unencrypted tunnel packets leaving the host since the default skb mark
> > +   all unencrypted tunnel packets leaving the host since the default skb_mark
> >     value for tunnel packets are 0. This affects all OVS tunnels including those
> >     without IPsec being set up. You can install OpenFlow rules to whitelist
> > -   those non-IPsec tunnels by setting the skb mark of the tunnel traffic as
> > +   those non-IPsec tunnels by setting the skb_mark of the tunnel traffic as
> >     non-zero value.
> >
> > -3) Setting `ipsec_skb_mark` as 1/1 only filters tunnel packets with skb mark
> > +3) Setting `ipsec_skb_mark` as 1/1 only drops tunnel packets with skb_mark
> >     value being 1::
> >
> >       $ ovs-vsctl set Open_vSwitch . other_config:ipsec_skb_mark=1/1
> > @@ -174,9 +181,9 @@ mode.  There are three forwarding modes:
> >                                      options:remote_ip=2.2.2.2 \
> >                                      options:psk=swordfish
> >
> > -   Opposite to 2), this mode doesn't filter unencrypted tunnel packets by
> > -   default. To filter unencrypted IPsec tunnel traffic, you need to explicitly
> > -   set skb mark to a non-zero value for those tunnel traffic by installing
> > +   Opposite to 2), this mode passes through unencrypted tunnel packets by
> > +   default. To drop unencrypted IPsec tunnel traffic, you need to explicitly
> > +   set skb_mark to a non-zero value for those tunnel traffic by installing
> >     OpenFlow rules.
> >
> >  Bug Reporting
> > @@ -185,9 +192,9 @@ Bug Reporting
> >  If you think you may have found a bug with security implications, like
> >
> >  1) IPsec protected tunnel accepted packets that came unencrypted; OR
> > -2) IPsec protected tunnel allowed packets to leave unencrypted;
> > +2) IPsec protected tunnel allowed packets to leave unencrypted
> >
> > -Then report such bugs according to :doc:`/internals/security`.
> > +then please report such bugs according to :doc:`/internals/security`.
> >
> > -If bug does not have security implications, then report it according to
> > +If the bug does not have security implications, then report it according to
> >  instructions in :doc:`/internals/bugs`.
> > diff --git a/Documentation/index.rst b/Documentation/index.rst
> > index 06602f7289ee..bab5ba1f1a98 100644
> > --- a/Documentation/index.rst
> > +++ b/Documentation/index.rst
> > @@ -65,7 +65,8 @@ vSwitch? Start here.
> >    :doc:`tutorials/ovs-advanced` |
> >    :doc:`tutorials/ovn-sandbox` |
> >    :doc:`tutorials/ovn-openstack` |
> > -  :doc:`tutorials/ovs-conntrack`
> > +  :doc:`tutorials/ovs-conntrack` |
> > +  :doc:`tutorials/ipsec`
> >
> >  Deeper Dive
> >  -----------
> > diff --git a/Documentation/tutorials/ipsec.rst b/Documentation/tutorials/ipsec.rst
> > index d25fcb0f717f..e78766705598 100644
> > --- a/Documentation/tutorials/ipsec.rst
> > +++ b/Documentation/tutorials/ipsec.rst
> > @@ -99,18 +99,24 @@ Configuring IPsec tunnel
> >  Suppose you want to build IPsec tunnel between two hosts. `host_1`'s external
> >  IP is `ip_1`. `host_2`'s external IP is `ip_2`.
> >
> > +0. Set up some variables to make life easier.  On both hosts, set ``ip_1`` and
> > +   ``ip_2`` variables, e.g.::
> > +
> > +     $ ip_1=192.0.0.1
> > +     $ ip_2=192.0.0.2
> > +
> >  1. Set up OVS bridges in both hosts.
> >
> >     In `host_1`::
> >
> >         $ ovs-vsctl add-br br-ipsec
> > -       $ ip addr add 192.0.0.1/24 dev br-ipsec
> > +       $ ip addr $ip_1 dev br-ipsec
> 
> Needs to be $ ip addr add $ip_1/24 dev br-ipsec. Otherwise, the route
> information won't be automatic added.
> 
> >         $ ip link set br-ipsec up
> >
> >     In `host_2`::
> >
> >         $ ovs-vsctl add-br br-ipsec
> > -       $ ip addr add 192.0.0.2/24 dev br-ipsec
> > +       $ ip addr add $ip_2 dev br-ipsec
> 
> Needs to be $ ip addr add $ip_2/24 dev br-ipsec. Otherwise, the route
> information won't be automatic added.
> 
> >         $ ip link set br-ipsec up
> >
> >  2. Set up IPsec tunnel.
> > @@ -118,31 +124,31 @@ IP is `ip_1`. `host_2`'s external IP is `ip_2`.
> >     There are three authentication methods. You can choose one to set up your
> >     IPsec tunnel.
> >
> > -   a) Using pre-shared key
> > +   a) Using pre-shared key:
> >
> >        In `host_1`::
> >
> >            $ ovs-vsctl add-port br-ipsec tun -- \
> >                        set interface tun type=gre \
> > -                                    options:local_ip=ip_1 \
> > -                                    options:remote_ip=ip_2 \
> > +                                    options:local_ip=$ip_1 \
> > +                                    options:remote_ip=$ip_2 \
> 
> The predefined $ip_1 is 192.0.0.1. But here I intended to use ip_1 to
> represent the external IP address which can be pinged by other hosts.
> In other words, 192.0.0.1 is the inner IP and ip_1 is the outer IP.
> Maybe we can use another variable to represent ip_1 and ip_2.
> 
> >                                      options:psk=swordfish
> >
> >        In `host_2`::
> >
> >            $ ovs-vsctl add-port br-ipsec tun -- \
> >                        set interface tun type=gre \
> > -                                    options:local_ip=ip_2 \
> > -                                    options:remote_ip=ip_1 \
> > +                                    options:local_ip=$ip_2 \
> > +                                    options:remote_ip=$ip_1 \
> >                                      options:psk=swordfish
> >
> >        .. note::
> >
> >          Pre-shared key (PSK) based authentication is easy to set up but less
> >          secure compared with other authentication methods. You should use it
> > -        cautiously in production system.
> > +        cautiously in production systems.
> >
> > -   b) Using self-signed certificate
> > +   b) Using self-signed certificate:
> >
> >        Generate self-signed certificate in both `host_1` and `host_2`. Then copy
> >        the certificate of `host_1` to `host_2` and the certificate of `host_2`
> > @@ -152,13 +158,13 @@ IP is `ip_1`. `host_2`'s external IP is `ip_2`.
> >
> >            $ ovs-pki req -u host_1
> >            $ ovs-pki self-sign host_1
> > -          $ scp host_1-cert.pem host_2 at ip_2:/path/to/host_1-cert.pem
> > +          $ scp host_1-cert.pem $ip_2:/etc/keys/host_1-cert.pem
> >
> >        In `host_2`::
> >
> >            $ ovs-pki req -u host_2
> >            $ ovs-pki self-sign host_2
> > -          $ scp host_2-cert.pem host_1 at ip_1:/path/to/host_2-cert.pem
> > +          $ scp host_2-cert.pem $ip_1:/etc/keys/host_2-cert.pem
> >
> >        .. note::
> >
> > @@ -166,36 +172,37 @@ IP is `ip_1`. `host_2`'s external IP is `ip_2`.
> >          to /etc/ipsec.d/certs/ and private key to /etc/ipsec.d/private/ so that
> >          StrongSwan has permission to access those files.
> >
> > -      Configure IPsec tunnel to use self-signed certificate.
> > +      Configure IPsec tunnel to use self-signed certificates.
> >
> >        In `host_1`::
> >
> >            $ ovs-vsctl set Open_vSwitch . \
> > -                     other_config:certificate=/path/to/host_1-cert.pem \
> > -                     other_config:private_key=/path/to/host_1-privkey.pem
> > +                     other_config:certificate=/etc/keys/host_1-cert.pem \
> > +                     other_config:private_key=/etc/keys/host_1-privkey.pem
> >            $ ovs-vsctl add-port br-ipsec tun -- \
> >                        set interface tun type=gre \
> > -                             options:local_ip=ip_1 \
> > -                             options:remote_ip=ip_2 \
> > -                             options:remote_cert=/path/to/host_2-cert.pem
> > +                             options:local_ip=$ip_1 \
> > +                             options:remote_ip=$ip_2 \
> > +                             options:remote_cert=/etc/keys/host_2-cert.pem
> >
> >        In `host_2`::
> >
> >            $ ovs-vsctl set Open_vSwitch . \
> > -                     other_config:certificate=/path/to/host_2-cert.pem \
> > -                     other_config:private_key=/path/to/host_2-privkey.pem
> > +                     other_config:certificate=/etc/keys/host_2-cert.pem \
> > +                     other_config:private_key=/etc/keys/host_2-privkey.pem
> >            $ ovs-vsctl add-port br-ipsec tun -- \
> >                        set interface tun type=gre \
> > -                             options:local_ip=ip_2 \
> > -                             options:remote_ip=ip_1 \
> > -                             options:remote_cert=/path/to/host_1-cert.pem
> > +                             options:local_ip=$ip_2 \
> > +                             options:remote_ip=$ip_1 \
> > +                             options:remote_cert=/etc/keys/host_1-cert.pem
> >
> >        .. note::
> >
> > -        The security of the private key is very critical. Don't copy the
> > -        private key to unsafe place.
> > +        The confidentiality of the private key is very critical.  Don't copy it
> > +        to places where it might be compromised.  (The certificate need not be
> > +        kept confidential.)
> >
> > -   c) Using CA-signed certificate
> > +   c) Using CA-signed certificate:
> >
> >        First you need to establish a public key infrastructure (PKI). Suppose
> >        you choose `host_1` to host PKI.
> > @@ -214,7 +221,7 @@ IP is `ip_1`. `host_2`'s external IP is `ip_2`.
> >        In `host_2`::
> >
> >            $ ovs-pki req -u host_2
> > -          $ scp host_2-req.pem host_1 at ip_1:/path/to/host_2-req.pem
> > +          $ scp host_2-req.pem $ip_1:/etc/keys/host_2-req.pem
> >
> >        Sign the certificate requests with the CA key. Copy `host_2`'s signed
> >        certificate and the CA certificate to `host_2`.
> > @@ -223,9 +230,9 @@ IP is `ip_1`. `host_2`'s external IP is `ip_2`.
> >
> >            $ ovs-pki sign host_1 switch
> >            $ ovs-pki sign host_2 switch
> > -          $ scp host_2-cert.pem host_2 at ip_2:/path/to/host_2-cert.pem
> > +          $ scp host_2-cert.pem $ip_2:/etc/keys/host_2-cert.pem
> >            $ scp /var/lib/openvswitch/pki/switchca/cacert.pem \
> > -                    host_2 at ip_2:/path/to/cacert.pem
> > +                    $ip_2:/etc/keys/cacert.pem
> >
> >        .. note::
> >
> > @@ -239,40 +246,42 @@ IP is `ip_1`. `host_2`'s external IP is `ip_2`.
> >        In `host_1`::
> >
> >            $ ovs-vsctl set Open_vSwitch . \
> > -                  other_config:certificate=/path/to/host_1-cert.pem \
> > -                  other_config:private_key=/path/to/host_1-privkey.pem \
> > -                  other_config:ca_cert=/path/to/cacert.pem
> > +                  other_config:certificate=/etc/keys/host_1-cert.pem \
> > +                  other_config:private_key=/etc/keys/host_1-privkey.pem \
> > +                  other_config:ca_cert=/etc/keys/cacert.pem
> >            $ ovs-vsctl add-port br-ipsec tun -- \
> >                     set interface tun type=gre \
> > -                                 options:local_ip=ip_1 \
> > -                                 options:remote_ip=ip_2 \
> > +                                 options:local_ip=$ip_1 \
> > +                                 options:remote_ip=$ip_2 \
> >                                   options:remote_name=host_2
> >
> >        In `host_2`::
> >
> >            $ ovs-vsctl set Open_vSwitch . \
> > -                  other_config:certificate=/path/to/host_2-cert.pem \
> > -                  other_config:private_key=/path/to/host_2-privkey.pem \
> > -                  other_config:ca_cert=/path/to/cacert.pem
> > +                  other_config:certificate=/etc/keys/host_2-cert.pem \
> > +                  other_config:private_key=/etc/keys/host_2-privkey.pem \
> > +                  other_config:ca_cert=/etc/keys/cacert.pem
> >            $ ovs-vsctl add-port br-ipsec tun -- \
> >                     set interface tun type=gre \
> > -                                 options:local_ip=ip_2 \
> > -                                 options:remote_ip=ip_1 \
> > +                                 options:local_ip=$ip_2 \
> > +                                 options:remote_ip=$ip_1 \
> >                                   options:remote_name=host_1
> >
> >        .. note::
> >
> > -        remote_name is the common name (CN) of the signed-certificate. It
> > -        should be set correctly so that only certificate with the expected CN
> > -        can be authenticated.
> > +        remote_name is the common name (CN) of the signed-certificate.  It must
> > +        match the name given as the argument to the ``ovs-pki sign command``.
> > +        It ensures that only certificate with the expected CN can be
> > +        authenticated; otherwise, any certificate signed by the CA would be
> > +        accepted.
> >
> >  3. Test IPsec tunnel.
> >
> >     Now you should have an IPsec GRE tunnel running between two hosts. To verify
> >     it, in `host_1`::
> >
> > -       $ ping 192.0.0.2 &
> > -       $ tcpdump -ni any net ip_2
> > +       $ ping $ip_2 &
> > +       $ tcpdump -ni any net $ip_2
> >
> >     You should be able to see that ESP packets are being sent from `host_1` to
> >     `host_2`.
> > @@ -280,7 +289,7 @@ IP is `ip_1`. `host_2`'s external IP is `ip_2`.
> >  Troubleshooting
> >  ---------------
> >
> > -Use following ovs-apptcl command to get ovs-monitor-ipsec internal
> > +Use following ovs-appctl command to get ovs-monitor-ipsec internal
> >  representation of tunnel configuration::
> >
> >      $ ovs-appctl -t ovs-monitor-ipsec tunnels/show
> > diff --git a/vswitchd/vswitch.xml b/vswitchd/vswitch.xml
> > index df96f30d1146..3caef4f79539 100644
> > --- a/vswitchd/vswitch.xml
> > +++ b/vswitchd/vswitch.xml
> > @@ -770,57 +770,32 @@
> >
> >      <group title="IPsec">
> >        <p>
> > -        The global configuration of IPsec tunnels is set in the
> > -        <code>other_config</code> column of the <code>Open_vSwitch</code>
> > -        table. The individual IPsec tunnel configuration is set in the
> > -        <code>options</code> column of the <code>Interface</code> table.
> > +        These settings control the global configuration of IPsec tunnels.  The
> > +        <code>options</code> column of the <code>Interface</code> table
> > +        configures IPsec for individual tunnels.
> >        </p>
> >        <p>
> > -        <code>ipsec_skb_mark</code> is set to choose forwarding mode which
> > -        prevents unencrypted packets being sent out since there is delay
> > -        between the user setting up IPsec tunnel and the IPsec tunnel actually
> > -        taking affect to encrypt packets.
> > -      </p>
> > -      <p>
> > -        There are three authentication modes:
> > +        OVS IPsec supports the following three forms of authentication.
> > +        Currently, all IPsec tunnels must use the same form:
> >        </p>
> >        <ol>
> >          <li>
> > -          Pre-shared key mode: <code>private_key</code>,
> > -          <code>certificate</code>, and <code>ca_cert</code> must not be set.
> > -          <code>psk</code> in the <code>options</code> column of the
> > -          <code>Interface</code> table should be set as the preshared key.
> > +          Pre-shared keys: Omit the global settings.  On each tunnel, set <ref
> > +          column="options" key="psk"/>.
> >          </li>
> >          <li>
> > -          Self-signed certificate mode: <code>private_key</code> and
> > -          <code>certificate</code> must be set. <code>remote_cert</code> in the
> > -          <code>options</code> column of the <code>Interface</code> table must
> > -          be set. The remote certificate can be self-signed.
> > +          Self-signed certificates: Set the <code>private_key</code> and
> > +          <code>certificate</code> global settings.  On each tunnel, set <ref
> > +          column="options" key="remote_cert"/>.  The remote certificate can be
> > +          self-signed.
> >          </li>
> >          <li>
> > -          CA-signed certificate mode: <code>private_key</code>,
> > -          <code>certificate</code>, and <code>ca_cert</code> must be set.
> > -          <code>remote_name</code> in the <code>options</code> column of the
> > -          <code>Interface</code> table must be set as the common name (CN) of
> > -          the remote certificate. The remote certificate must be signed by the
> > -          CA.
> > +          CA-signed certificates: Set all of the global settings.  On each
> > +          tunnel, set <ref column="options" key="remote_name"/> to the common
> > +          name (CN) of the remote certificate. The remote certificate must be
> > +          signed by the CA.
> >          </li>
> >        </ol>
> > -      <column name="other_config" key="ipsec_skb_mark"
> > -              type='{"type": "string"}'>
> > -          <p>
> > -            Setting ipsec_skb_mark as 1/1 blocks unecrypted packets with skb
> > -            mark setting as 1. Besides, the OpenFlow rule with set SKB mark
> > -            action specified in OVSDB needs to be installed in Open_vSwitch
> > -            table before the first packet was able to leave the OVS tunnel.
> > -          </p>
> > -          <p>
> > -            Setting ipsec_skb_mark as 0/1 blocks unecrypted packets without skb
> > -            mark. As a result, IPsec assumes that all packets coming from
> > -            tunnels should be encrypted unless OpenFlow actions explicitly
> > -            set skb mark to a non-zero value.
> > -          </p>
> > -      </column>
> >        <column name="other_config" key="private_key"
> >                type='{"type": "string"}'>
> >            <p>
> > @@ -845,6 +820,60 @@
> >              that a remote switch of the IPsec tunnel is trustworthy.
> >            </p>
> >        </column>
> > +
> > +      <group title="Plaintext Tunnel Policy">
> > +        <p>
> > +          After an IPsec tunnel is configured, it takes a few round trips to
> > +          negotiate details of the encryption with the remote host.  In the
> > +          meantime, packets sent by the local host over the tunnel can be
> > +          transmitted in plaintext.  This setting controls the behavior in this
> > +          situation.
> > +        </p>
> > +        <column name="other_config" key="ipsec_skb_mark"
> > +                type='{"type": "string"}'>
> > +          <p>
> > +            This setting takes the form
> > +            <code><var>value</var>/<var>mask</var></code>.  If it is specified,
> > +            then the <code>skb_mark</code> field in every outgoing tunneled
> > +            packet sent in plaintext is compared against it and, if it matches,
> > +            the packet is dropped.  This is a global setting that is applied to
> > +            every tunneled packet, regardless of whether IPsec encryption is
> > +            enabled for the tunnel, the type of tunnel, or whether OVS is
> > +            involved.
> > +          </p>
> > +
> > +          <p>
> > +            Example policies:
> > +          </p>
> > +
> > +          <dl>
> > +            <dt><code>1/1</code></dt>
> > +            <dd>
> > +              Drop all unencrypted tunneled packets in which the
> > +              least-significant bit of <code>skb_mark</code> is 1.  This would
> > +              be a useful policy given an OpenFlow flow table that sets
> > +              <code>skb_mark</code> to 1 for traffic that should be encrypted.
> > +              The default <code>skb_mark</code> is 0, so this would not affect
> > +              other traffic.
> > +            </dd>
> > +
> > +            <dt><code>0/1</code></dt>
> > +            <dd>
> > +              Drop all unencrypted tunneled packets in which the
> > +              least-significant bit of <code>skb_mark</code> is 0.  This would
> > +              be a useful policy if no unencrypted tunneled traffic should exit
> > +              the system without being specially whitelisted by setting
> > +              <code>skb_mark</code> to 1.
> > +            </dd>
> > +
> > +            <dt>(empty)</dt>
> > +            <dd>
> > +              If this setting is empty or unset, then all unencrypted tunneled
> > +              packets are transmitted in the usual way.
> > +            </dd>
> > +          </dl>
> > +        </column>
> > +      </group>
> >      </group>
> >
> >      <group title="Common Columns">
> > @@ -2475,9 +2504,9 @@
> >
> >        <column name="options" key="local_ip">
> >          <p>
> > -          Optional (except for IPsec tunnels).  The tunnel destination IP that
> > -          received packets must match.  Default is to match all addresses.  If
> > -          specified, may be one of:
> > +          Normally optional; required for IPsec tunnels.  The tunnel
> > +          destination IP that received packets must match.  Default is to match
> > +          all addresses.  If specified, may be one of:
> >          </p>
> >
> >          <ul>
> > @@ -2753,28 +2782,30 @@
> >
> >        <group title="Tunnel Options: IPsec">
> >          <p>
> > -          <code>gre</code>, <code>geneve</code>, <code>vxlan</code>, and
> > -          <code>stt</code> interfaces support these options.
> > +          Setting any of these options enables IPsec support for a given
> > +          tunnel.  <code>gre</code>, <code>geneve</code>, <code>vxlan</code>,
> > +          and <code>stt</code> interfaces support these options.  See the
> > +          <code>IPsec</code> section in the <ref table="Open_vSwitch"/> table
> > +          for a description of each mode.
> >          </p>
> >          <column name="options" key="psk" type='{"type": "string"}'>
> >            <p>
> > -            The preshared secret to negotiate tunnel in PSK mode. This value
> > -            must match on both tunnel ends and must be unset when
> > -            <code>remote_cert</code> or <code>remote_name</code>is set.
> > +            In PSK mode only, the preshared secret to negotiate tunnel. This
> > +            value must match on both tunnel ends.
> >            </p>
> >          </column>
> >          <column name="options" key="remote_cert" type='{"type": "string"}'>
> >            <p>
> > -            Name of a PEM file containing a certificate of the remote switch.
> > -            The certificate must be x.509 version 3 and with the string in
> > -            common name (CN) also set in the subject alternative name (SAN). It
> > -            must be unset when <code>psk</code> is set.
> > +            In self-signed certificate mode only, name of a PEM file
> > +            containing a certificate of the remote switch.  The certificate
> > +            must be x.509 version 3 and with the string in common name (CN)
> > +            also set in the subject alternative name (SAN).
> >            </p>
> >          </column>
> >          <column name="options" key="remote_name" type='{"type": "string"}'>
> >            <p>
> > -            Common name (CN) of the remote certificate. It must be unset when
> > -            <code>psk</code> is set.
> > +            In CA-signed certificate mode only, common name (CN) of the remote
> > +            certificate.
> >            </p>
> >          </column>
> >        </group>


More information about the dev mailing list