<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" []>
<rfc category="info" ipr="trust200902"
docName="draft-sheffer-autovpn-00">
  <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
  <?rfc toc="yes" ?>
  <?rfc symrefs="yes" ?>
  <?rfc sortrefs="yes"?>
  <?rfc iprnotified="no" ?>
  <?rfc strict="yes" ?>
  <?rfc compact="yes" ?>
  <front>
    <title abbrev="AutoVPN">The AutoVPN Architecture</title>
    <author initials="Y." surname="Sheffer"
    fullname="Yaron Sheffer">
      <organization abbrev="Porticor">Porticor</organization>
      <address>
        <email>yaronf.ietf@gmail.com</email>
      </address>
    </author>
    <author initials="Y." surname="Nir" fullname="Yoav Nir">
      <organization abbrev="Check Point">Check Point Software Technologies Ltd.</organization>
      <address>
        <postal>
          <street>5 Hasolelim st.</street>
          <city>Tel Aviv</city>
          <code>6789735</code>
          <country>Israel</country>
        </postal>
        <email>ynir@checkpoint.com</email>
      </address>
    </author>
    <date year="2014" />
    <abstract>
      <t>This document describes the AutoVPN architecture.  AutoVPN allows IPsec security associations to be set up with no
prior configuration, using the "leap of faith" paradigm.  The
document defines a lightweight protocol for negotiating such
opportunistic encryption either directly between hosts or between
two security gateways on the path.
      </t>
    </abstract>
  </front>
  <middle>
    <!-- ************************************************************************************ -->
    <section title="Introduction">
      <t>In the last few years, there have been several attempts to
      define an opportunistic encryption architecture, where
      network traffic is confidentiality-protected, even in the
      absence of proper authentication of the peers.
      This
      protection is often accompanied by continuity of identity,
      i.e. although the identity may not be authenticated, it is
      verified to remain unchanged between multiple protocol
      sessions, and over long periods (days/weeks). This
      initial protection may be enhanced at a later stage, as peers
      gain stronger trust in each other's identity.
        A term which is often
      used to denote this policy is "leap of faith".
      </t>
      <t>In the IPsec space, these attempts culminated in the BTNS
      (Better Than Nothing Security) working group's
      specifications. The BTNS working group produced a number of
      documents, including <xref target="RFC5386"/> and <xref target="RFC5387"/>.
      In addition, the
      earlier <xref target="RFC4322"/> describes Opportunistic Encryption, as
      implemented in various dialects of Linux (the history of Linux OE is summarized in a long post by Paul Wouters <xref target="oe-history"/>). However these
      specifications focus on the architectural IPsec implications,
      and provide insufficient context to implement the behavior
      described in the current document. "Leap of faith" has never been
      fully specified in the IPsec context, or when specified, assumes mechanisms
      that are still not widely deployed.
      </t>
      <t>Similarly to many security architectures, a well designed
      opportunistic encryption solution requires both a robust
      protocol, and a user interaction component that allows the
      user to understand the exact security guarantees available at
      any time, so that the user may add external inputs about
      trustworthiness of communication peers while staying away
      from the "just press OK" mentality.</t>
      <t>This document describes the
      AutoVPN architecture, an opportunistic encryption extension to the Internet 
      Key Exchange v2 (IKEv2 - <xref target="RFC5996"/>) for IPsec VPN.</t>
      <t>Some of the requirements behind this protocol are:
      <list style="symbols">
        <t>It should be suitable for business-to-business traffic,
        and therefore for deployment on the open Internet.</t>
        <t>It should be robust, efficient and network friendly enough to be
        enabled by default.</t>
        <t>It should be deployable on (existing) security gateways, rather
        than requiring changes to hosts.</t>
	<t>It should also work on hosts that are not protected by gateways, i.e. hosts
	that are themselves IPsec endpoints.</t>
        <t>It should require zero configuration. Some limited level
        of security should be provided by devices which are not
        configured.</t>
        <t>After-the-fact security: the security guarantees can be
        improved at a later time, possibly using out-of-band
        means.</t>
        <t>The protocol should coexist with regular IPsec, with no degradation in security.</t>
        <t>The protocol should provide the best possible security
        given the imperfections of today's Internet. In particular,
        it should not rely on the deployment of DNS Security, anti spoofing
        mechanisms or routing security.</t>
        <t>Small gateways, as well as software VPN clients, are often behind NAT.
        This scenario should be supported.</t>
      </list></t>
    </section>
    <!-- ************************************************************************************ -->
    <section title="Terminology">
    <t>We use the term "initiator" for the gateway through which came the original traffic.
    The gateway may not be the initiator of the new protocol described below. The other
    gateway is the "responder". Note that these terms correspond to the gateways' behavior
    with respect to IKE negotiation.</t>
      <t>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
      <xref target="RFC2119" />.</t>
    </section>
    <!-- ************************************************************************************ -->
    <section title="Architecture and Protocol Overview" anchor="protocol-overview">
      <t>The protocol creates an IPsec tunnel to protect traffic
      which would otherwise be transmitted in the clear. What
      follows is a high level description of the sequence of
      operations.</t>
      <t>We use H1 and H2 to denote two hosts (endpoints), and G1
      and G2 to denote two IPsec gateways, protecting H1 and H2
      respectively. This setup is shown in <xref target="architecture"/> below.
      The solution described here is also applicable when
      one or both hosts is collocated with its respective gateway. Unfortunately it cannot
      be optimized for these cases, since source IP addresses can always be spoofed.
      </t>
           <figure anchor="architecture" title="Deployment Architecture">
            <artwork>
              <![CDATA[
   +--------+   +---------+                  +---------+   +--------+
   |        |   |         |                  |         |   |        |
   |  Host  |   | Gateway |   / -------- \   | Gateway |   |  Host  |
   |   H1   |---|   G1    |---| Internet |---|   G2    |---|   H2   |
   |        |   |         |   \ -------- /   |         |   |        |
   +--------+   +---------+                  +---------+   +--------+]]>
            </artwork>
          </figure>
      <t>
      Initially, only H1 knows of H2's address. The protocol below allows both intervening
      gateways to discover each other, and to gain assurance that each one is on-path of
      the opposite host, i.e. it can see traffic
      addressed to the respective host, and can respond to such traffic.
      </t>
      <t>We assume that both G1 and G2 contain access control functionality,
      as required by the IPsec architecture, and that both allow some clear traffic
      between H1 and H2.</t>
      <t>The message sequence below is motivated to a great extent by the need to cater
      to NAT devices in front of G1, the original initiator. It is assumed that correctly
      implemented NAT devices will perform correct reverse translation of ICMP
      messages. However we cannot assume that they handle correctly ICMP messages
      of an unknown type.
      </t>
      <t>Another major consideration is which side should drive the exchange. We have chosen
      the responder side (G2), since in an Internet where most traffic uses HTTP, the responder
      side knows best which traffic should be protected.</t>
      <t>Lastly, we could have saved one round trip by allowing G2 to spoof H2's address.
      We believe this would have been ill advised.</t>
     <t>
     The flow of messages is depicted in <xref target="message-sequence"/>.
      <list style="symbols">
        <t>H1 creates a network connection to H2, for example by sending a TCP SYN
        packet. H2 replies normally to H1.</t>
        <t>G2 intercepts the reply packet, but lets it pass
        through. The connection proceeds normally, possibly
        including data packets.</t>
        <t>G2 sends a Probe Request message, addressed to H1.</t>
        <t>G1 intercepts the Probe Request, does not forward it,
        and sends a Probe Response, addressed to H2. Note that if H1 is NOT protected
        by a gateway, it will receive the Probe Request message and
        therefore the message should be
        designed to have no effect on innocent receivers.</t>
        <t>G2 intercepts the Probe Response, does not forward it, and
        sends a Probe Complete, addressed to G1.
        </t>
        <t>
        G1 now initiates an IKE_SA_INIT exchange to G2. This message includes payloads that
        can be correlated with the previous messages.</t>
        <t>G1 and G2 negotiate an IPsec SA, potentially for all traffic between
        H1 and H2.</t>
        <t>Both G1 and G2 now move the traffic between H1 and H2
        into the new SA.</t>
      </list></t>
                 <figure anchor="message-sequence" title="Message Sequence">
            <artwork>
              <![CDATA[
 H1                G1                              G2                H2
====              ====                            ====              ====
 ||                ||  Syn                         ||                ||
 ||----------------------------------------------------------------->||
 ||                ||  Ack                         ||                ||
 ||<-----------------------------------------------------------------||
 ||                ||  Unencrypted traffic         ||                ||
 ||<================================================================>||
 ||                ||                              ||                ||
 ||                ||                              ||                ||
 ||                || Probe Request (ICMP)         ||                ||
 ||<- - - - - - - -||<-----------------------------||                ||
 ||                || Probe Response (UDP/4500)    ||                ||
 ||                ||----------------------------->||- - - - - - - ->||
 ||                || Probe Complete (ICMP)        ||                ||
 ||                ||<-----------------------------||                ||
 ||                || IKE Message #1               ||                ||
 ||                ||----------------------------->||                ||
 ||                || IKE Signaling                ||                ||
 ||                ||<============================>||                ||
 ||                || Protected traffic            ||                ||
 ||<==============>||<============================>||<==============>||]]>
            </artwork>
          </figure>
    </section>
    <!-- ************************************************************************************ -->
    <section title="Protocol Exchanges"
    anchor="protocol-exchanges">
    <t>
    AutoVPN consists of a 3-way probing protocol, followed by a slightly extended IKEv2
    exchange.</t>
    <t>
    The normal execution sequence of the protocol is as follows. G2 generates a
    fresh, randomly generated value Nonce-R, and sends to H1:
    </t>
    <t>
        <list style="empty">
        <t>Probe Request: Version, Nonce-R, NAT-Detect</t>
        </list>
    </t>
    <t>
    G1 intercepts the received message and does not forward it to H1. G1 MAY verify that the message
    corresponds to an ongoing connection, using the packet fragment contained in the ICMP
    envelope. G1 generates a fresh, random Nonce-I and sends to H2:
    </t>
    <t>
        <list style="empty">
        <t>Probe Response: Version, Nonce-I, Nonce-R</t>
        </list>
    </t>
    <t>
    where the content of Nonce-R is copied from the request.
    G2 intercepts this message, and does not forward it to H2. G2 MUST verify that Nonce-R
    is valid, and silently ignore the message otherwise. G2 replies with:
    </t>
    <t>
        <list style="empty">
        <t>Probe Complete: Version, Nonce-I, Nonce-R</t>
        </list>
    </t>
    <t>
    G1 MUST check the validity of Nonce-I and Nonce-R. Finally, G1 sends an IKEv2
    IKE_SA_INIT message to G2, containing a copy of the received Nonce-R.
    </t>
    </section>
    <!-- ************************************************************************************ -->
    <section title="Message Format" anchor="format">
    <t>
    The AutoVPN protocol messages consist of
    a sequence of type-length-value (TLV) payloads. The messages are encoded in two
    different base protocols: ICMP and UDP over port 4500.
    </t>
    <t>
    The Probe Request and Probe Complete messages MUST be encoded within ICMP.
    The Probe Response message MUST be encoded within UDP.
    </t>
    <section title="ICMP Encoding">
    <t>
    Each payload is encoded as an ICMP Extension Object, as per <xref target="RFC4884"/>.
    ICMP Error messages contain a copy of (part of) the original packet, and this is used
    to associate the ICMP message with the original clear traffic.
    ICMP header fields are populated as follows:
    <list style="symbols">
    <t>Type is "Parameter Problem".</t>
    <t>Code is the value 1.</t>
    <t>The Checksum field MUST be computed, as per <xref target="RFC0792"/>.</t>
    <t>The new Length field is defined in <xref target="RFC4884"/>.</t>
    </list>
    </t>
    <t>
    In the Extension Object Headers, Class-Num is TBD by IANA, and C-Type is the Type
    value defined for each payload below.
    </t>
    </section>
    <section title="UDP Encoding">
    <t>
    In this encoding, all payloads are simply concatenated following the Preamble. Each payload
    is preceded by a payload header, as defined in <xref target="payloads"/>.
    </t>
    <t>
    The generic Preamble format is described in the next figure.
          <figure anchor="autovpn-preamble" title="AutoVPN Preamble">
            <artwork>
              <![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     IP Header...                                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     UDP Header...                                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     SPI (16 bytes, value TBD by IANA)                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]>
            </artwork>
        </figure>
    </t>
    <t>
    The Probe Response protocol message has 4500 as its destination port.
    The protocol reuses the IKE/IPsec port 4500, however it is neither IKE nor
    IPsec. All three can coexist, and are distinguished using the SPI value.
    The specific SPI value will be allocated out of the "reserved" SPI space.
    </t>
    </section>
    <section anchor="payloads" title="Protocol Payloads">
    <t>
    An AutoVPN payload is encoded as an ICMP Extension Object or within a UDP message.
    When using UDP, the generic payload header is described in the next figure:
          <figure anchor="payload-header" title="Payload Header">
            <artwork>
              <![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Type        |       0       |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            Value...                           |
+...............................................................+
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]>
            </artwork>
        </figure>
        <list style="hanging">
        <t hangText="Type:">
              <vspace blankLines="1"/>One of the payload types listed below.
              <vspace blankLines="1"/></t>
        <t hangText="Length:">
              <vspace blankLines="1"/>The payload length in octets, including
              this header.
              <vspace blankLines="1"/></t>
        </list>
    The following payload types are defined:
    </t>
        <texttable>
        <ttcol align='center'>Name</ttcol>
        <ttcol align='center'>Value</ttcol>
        <ttcol align='left'>Definition</ttcol>
        <c>Unused</c>
        <c>0</c>
        <c></c>
        <c>Version</c>
        <c>1</c>
        <c>Generic information about the current message</c>
        <c>Nonce-I</c>
        <c>2</c>
        <c>Initiator's nonce</c>
        <c>Nonce-R</c>
        <c>3</c>
        <c>Responder's nonce</c>
        <c>NAT-Detect</c>
        <c>4</c>
        <c>NAT detection information</c>
        <c></c>
        <c>4-127</c>
        <c>Reserved to IANA</c>
        <c></c>
        <c>128-255</c>
        <c>Reserved for private use</c>
    </texttable>
    </section>
    <section title="Version Payload">
    <t>This payload is formatted as follows:</t>
          <figure anchor="version-payload" title="Version Payload">
            <artwork>
              <![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Version    | Message Type  |   Reserved    | Vendor ID     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                                                               ~
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
~                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]>
            </artwork>
        </figure>
    <t>The header contains the following fields:</t>
    <t>
    <list style="hanging">
        <t hangText="Version:">
              <vspace blankLines="1"/>MUST be 0x01 for this version of the protocol.
              <vspace blankLines="1"/></t>
        <t hangText="Message Type:">
              <vspace blankLines="1"/>1 for Probe Request, 2 for Probe Response, 3 for Probe Complete.
              Other values are reserved to IANA.
              <vspace blankLines="1"/></t>
        <t hangText="Reserved:">
              <vspace blankLines="1"/>MUST be sent as 0, and ignored by the receiver.
              <vspace blankLines="1"/></t>
        <t hangText="Vendor ID:">
              <vspace blankLines="1"/>This field is optional and of variable length, possibly 0.
              It MAY contain a string uniquely
              identifying the vendor (e.g. "example.com"), or a binary string that is statistically
              unique (e.g. the SHA-1 hash of "we support the XX extension").
              <vspace blankLines="1"/></t>
    </list>
    </t>
    </section>
    <section title="Nonce Payloads">
    <t>
    Nonces are random or unpredictable values that enable the entity that generated them to recognize
    them as valid when it receives them again. Nonces MAY be used to encode state, in order
    to enable stateless implementations of this protocol. The length of each nonce
    (excluding the payload header) MUST be between 8 and 64 octets, inclusive.
    </t>
    <t>
    One possible way to construct the nonce is
    </t>
    <t>
        <list style="empty">
        <t>key-ID || HMAC-SHA256(K, gateway-IP || packet-fragment)</t>
        </list>
    </t>
    <t>
    where K is a secret key known only to the sender, and key-ID
    identifies the key, enabling smooth roll-over of keys. Packet-fragment is the same portion
    of the packet as returned in an ICMP response, i.e. the IP header and the 8 octets
    that follow it.
    </t>
    </section>
    <section title="NAT-Detect Payload">
    <t>This payload consists of a 4-octet obfuscated IPv4 address,
    followed by a 2-octet port number.
    The address is obfuscated by a XOR operation with 0x0F0F0F0F, with the intention of defeating
    over-eager NAT devices which might try to rewrite the packet. The address and port
    are the source address/port of the original (clear) packet,
    as seen by the remote gateway (G2).
    The IP protocol (e.g. UDP or TCP) is inferred from the packet fragment included
    in the ICMP message containing this payload.
    </t>
    </section>
    </section>
    <!-- ************************************************************************************ -->
    <section title="Error Handling and Reliability" anchor="error-handling">
    <t>
    The AutoVPN protocol is UDP and ICMP based, and therefore per-message reliability is
    not guaranteed. Both sides MAY retransmit the ICMP and UDP messages,
    but MUST NOT do so more than
    twice (total of 3 messages). The gateway (G2) that sends the first
    ICMP message MUST NOT retry a particular peer more than once
    every 24 hours.
    </t>
    <t>
    The protocol does not include any error messages. If a peer does not accept a particular
    message for any reason, it MUST silently drop it. For forward compatibility, a receiver SHOULD
    process incoming messages even if they contain
    payloads that it does not understand, and SHOULD ignore these payloads.
    </t>
    </section>
    <!-- ************************************************************************************ -->
    <section title="NAT Considerations">
    <t>The current version of the protocol allows both sides to detect a NAT being
    performed between the gateways. Detection takes place
    during the probing phase. However this scenario raises several issues, which require further
    investigation before a useful solution can be proposed:</t>
    <t>
    <list style="symbols">
    <t>If traffic from a host which is behind NAT (H1) is inserted directly into an IPsec
    tunnel, it will emerge as-is on the other side, and the receiving host might see a
    non-routable <xref target="RFC1918"/> source address.</t>
    <t>The initiating gateway may not have enough information to formulate its IKE Traffic
    Selector payload (TSi).</t>
    </list>
    </t>
    <t>
    A solution that can be considered is for G1 to request a
    Tunnel Inner Address using an IKE Configuration Payload, and to
    perform NAT on traffic originating from H1 so that it appears to
    be sourced from that address. One of the issues with this
    solution is that the initial clear connection will necessarily
    be broken because of the address change.
    </t>
    <t>We note that the protocol can be implemented correctly on a gateway that
    performs the NAT function itself.
    </t>
    </section>
    <!-- ************************************************************************************ -->
    <section title="IKE Protocol Considerations">
    <t>
    The AutoVPN protocol imposes a few requirements on the IKE peers:
    <list style="symbols">
    <t>Both peers MUST use a certificate to authenticate.
    In many cases this is expected to be a self-signed certificate. But see also
    <xref target="cert-rollover"/>.</t>
    <t>The peers MUST NOT negotiate any IPsec protocol, other than ESP in tunnel mode.</t>
    <t>Each peer MUST offer only a single IP address in its negotiated traffic selector.
    This IP address MUST be identical to the one the gateway
    has proven authorization for. This MUST also be validated by the opposite peer. Per
    policy, traffic selectors MAY be even narrower, e.g. referring to specific protocol
    ports.
    </t>
    </list>
    </t>
    <section title="New IKE Payloads">
    <t>
    This protocol defines several new IKE payloads.
    </t>
    <section title="AutoVPN Nonce">
    <t>
    This payload has the payload type TBD by IANA. It MUST only be used in the first
    message of the IKE_SA_INIT exchange. The payload contains an exact copy of
    the Nonce-R AutoVPN payload, without the AutoVPN payload header.
    </t>
    </section>
    <section title="Contact Details">
    <t>
    This payload has the payload type TBD by IANA. It SHOULD be sent by both peers during
    the IKE_AUTH exchange.
    The payload contains a human readable UTF-8 string
    which is designed to assist the person managing the opposite protocol peer in verifying
    the sender's true identity. An example string is:
    <list style="empty">
    <t>
    This gateway is operated by Example Inc. To validate our identity, you may
    wish to obtain our public key's fingerprint from our Web site, at
    https://www.example.com/autovpn. Or you may wish to contact the network administrator at
    1-616-555-1212 to get the fingerprint. Please compare this value with the fingerprint value
    displayed by your gateway.
    </t>
    </list>
    For obvious security reasons, this string MUST be rendered as plain text,
    and in particular MUST NOT be rendered as HTML.
    </t>
    </section>
    </section>
    <section title="AUTOVPN_SHARED_SECRET Notification">
    <t>
    This notification, whose value is TBD by IANA, contains no data. It signifies that
    an AutoVPN shared secret MUST be created by the two IKE peers. See <xref target="cert-rollover"/> for details.
    </t>
    </section>
    </section>
    <!-- ************************************************************************************ -->
    <section title="Security Policy">
    <t>
    This section describes the AutoVPN security policy, and should be viewed as an
    extension of <xref target="RFC4301"/>.
    </t>
        <section title="Certificate States">
        <t>
        AutoVPN defines a state for each peer gateway's certificate.
        A certificate may be in one of the following states (<xref target="certificate-states"/>):
        <list style="symbols">
        <t>Unknown. This may also be a certificate which had been manually removed,
        through a manual operation or for a number of reasons listed below.</t>
        <t>Known but unverified. A DN is associated with a certificate's fingerprint,
        and additional
        information may be available ("contact details").
        When not used, such certificates may be deleted from the table, after some site-specific
        timeout. It is RECOMMENDED that this timeout be larger than 7 days.</t>
        <t>Trusted identity. The administrator can manually mark a certificate as Trusted.
        Alternatively,
        the certificate may have been signed by a trusted third party.</t>
        <t>Untrusted identity. The administrator can manually mark a certificate as Untrusted, if
        he or she manually checks the certificate's fingerprint and detects a mismatch
        against an advertised value. </t>
        <t>Managed. These certificates belong to peers that are part of the same managed VPN. They are
        not further discussed in this document.</t>
        </list>
        </t>
          <figure anchor="certificate-states" title="Certificate States">
            <artwork>
              <![CDATA[
/-----------\                                     /-----------\
|           |       successful IKE exchange       |           |
|           | ==================================> |           |
|  Unknown  |       timeout (when allowed)        |Unverified |
|           | <================================== |           |
|           | ===========                         |           |
\-----------/          || successful exchange     \-----------/
     ||                || (trusted third party)      ||
     ||                ||                            ||
     ||                ||           manual marking   ||
     || configuration  ||        ========================
     ||                ||        ||                    ||
     ||                ||        ||                    ||
     ||                ||        ||                    ||
     \/                ||        \/                    \/
/-----------\          ||    /-----------\       /-----------\
|           |          ||    |           |       |           |
|           |          ====> |           |       |           |
|  Managed  |                |  Trusted  |       | Untrusted |
|           |                |           |       |           |
|           |                |           |       |           |
\-----------/                \-----------/       \-----------/]]>
            </artwork>
        </figure>
        <t>
        If the gateway detects that a peer's certificate has been explicitly revoked,
        it MUST delete this certificate from the table.
        </t>
        <t>
        A PAD entry may exist for certificates in the Unverified, Managed or Trusted states. A PAD
        entry MUST NOT exist for a certificate in the Untrusted state,
        and IKE exchanges with peers presenting such certificates MUST be rejected, regardless of
        who initiated the exchange.
        When a certificate is deleted (whether manually or automatically) or marked as Untrusted,
        the associated PAD entry MUST be deleted.
        </t>
        <t>
        When locating the peer, only the DN should be used. The peer's IP address MUST NOT be
        used, to allow peers to change their address.
        </t>
        </section>
        <section anchor="cert-rollover" title="Certificate Rollover and Permanent Association">
        <t>
        In the absence of a certificate rollover mechanism, it would be impossible to
        distinguish between a legitimate peer presenting a new certificate and a MITM attacker.
        Therefore, AutoVPN gateways MUST support the shared secret mechanism described here.
        </t>
        <t>
        As noted above, the information about a peer's certificate will normally
        time-out and be deleted. However any of the gateways can choose a convenient time to
        "promote" the association between the gateways, by trigerring the creation of
        a shared secret. This secret never expires, other than through
        manual deletion on both peers.
        </t>
        <t>
        The shared secret is associated with the pair of gateway identities, specifically
        with the IDi, IDr payloads exchanged between the gateways. Once a shared secret
        is established, both gateways MUST use it with the associated peer, in preference
        to certificate-based or other forms of authentication.
        A shared secret MAY be initiated for a peer in Unverified or Trusted state.
        On each gateway, the shared secret is associated with the peer gateway's certificate,
        and both MUST NOT be timed out regardless of the certificate's trust state.
        </t>
        <t>
        The initiating gateway, which may be an IKE initiator or responder, MAY send the
        AUTOVPN_SHARED_SECRET notification at any time. The shared secret is the value
        <list style="empty">
        <t>prf+(SK_d, "shared secret for AutoVPN")</t>
        </list>
        where SK_d is the derivation key of the current IKE SA.
        The literal string is represented in ASCII, with no zero terminator.
        </t>
        </section>
        <section title="Certificate Conflicts">
        <t>
        A certificate conflict may be detected during the IKE exchange. This happens
        when an AutoVPN peer presents a certificate whose DN matches the DN of a known AutoVPN
        certificate, but which is different from that certificate.
        In such cases the new peer MUST be rejected, with the notification AUTHENTICATION_FAILED.
        </t>
        <t>
        As a result, barring incorrect configuration, the certificate table can never
        contain multiple certificates with the same DN.
        </t>
        </section>
        <section title="Fallback to Clear">
        <t>
        In some cases it may be desirable to allow fallback to clear traffic
        in cases where an IKE/IPsec
        association cannot be established, even when the peer is known. This is left to local
        policy, and SHOULD be configurable on the gateway. Such configuration MAY take
        the trust level of the peer gateway into account.
        </t>
        <t>
        Moreover, some policies may prefer to send traffic unprotected, even when an IKE SA can
        be established, and then renegotiate an IPsec SA following some manual action. One possible
        way of doing this is using the mechanism described in
        <xref target="RFC6023"/>.
        </t>
        </section>
    </section>
    <!-- ************************************************************************************ -->
	<section title="IANA Considerations" anchor="iana">
		<t>TBD.</t>
	</section>
	<!-- ************************************************************************************ -->
	<section title="Security Considerations" anchor="security">
		<t>TBD.</t>
	</section>
	<!-- ************************************************************************************ -->
	<section title="Acknowledgements">
		<t>A proof of concept implementation of this protocol was created by
			Michael Rogovin at Check Point, and we would like
			to acknowledge his contribution.</t>
	</section>
  </middle>
  <back>
    <references title="Normative References">
    <?rfc include="reference.RFC.0792.xml"?>
    <?rfc include="reference.RFC.1918.xml"?>
    <?rfc include="reference.RFC.2119.xml"?>
    <?rfc include="reference.RFC.4301.xml"?>
    <?rfc include="reference.RFC.5996.xml"?>
    <?rfc include="reference.RFC.4884.xml"?>
    </references>
    <references title="Informative References">
    <?rfc include="reference.RFC.4322.xml"?>
    <?rfc include="reference.RFC.5386.xml"?>
    <?rfc include="reference.RFC.5387.xml"?>
    <?rfc include="reference.RFC.6023.xml"?>
    <?rfc include="reference.RFC.6480.xml"?>
    <reference anchor="oe-history" target="http://nohats.ca/wordpress/blog/2013/09/12/history-and-implementation-status-of-opportunistic-encryption-for-ipsec/"><front><title>History and implementation status of Opportunistic Encryption for IPsec</title>
    <author initials="P. W." surname="Wouters" fullname="Paul Wouters"><organization/></author><date year="2013" month="September"/>
    </front></reference>
   </references>
    <section title="Change Log">
      <section title="-00">
        <t>Initial version.</t>
      </section>
    </section>
    <section title="Implementation Considerations">
        <section title="Address Authorization">
        <t>
        Address authorization SHOULD be maintained separately from peer identity. Timing out
        authorization data (as proposed in <xref target="RFC4322"/>) is risky, since the
        authorization protocol allows a MITM, and also exposes clear traffic. This issue is TBD,
        and for now, authorization will only be removed when a peer is deleted.
        </t>
        <t>
        We should look at alternative ways to prove address ownership. For example, if the gateway G1 can prove its ownership of
        a certain address range, it might send an RPKI <xref target="RFC6480"/> certificate to that effect, plus proof of possession in IKE_AUTH.
        The peer gateway G2 might then decide to allow a wider traffic selector including all of G1's addresses, instead of just H1. 
        </t>
        <t>
        Also TBD are the IPsec policy implications, within the framework of <xref target="RFC4301"/>,
        Sec. 4.4.3.
        </t>
        </section>
        <section title="Multiple Interfaces and Alternative Gateways">
        <t>We might want to support multiple gateway addresses in the probing protocol, so
        we can have high quality connectivity without resorting to "fallback to the clear"
        (i.e. have very long timeouts, measured in days).
        On the other hand, maybe MOBIKE does the work in IKEv2.</t>
        </section>
    </section>
  </back>
</rfc>
