<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-patil-pcp-multihoming-00" ipr="trust200902">
  <front>
    <title abbrev="PCP in Multihoming">Using PCP to control NAT and Firewalls
    in Multihoming</title>

    <author fullname="Prashanth Patil" initials="P." surname="Patil">
      <organization abbrev="Cisco">Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street>Cessna Business Park, Varthur Hobli</street>

          <street>Sarjapur Marthalli Outer Ring Road</street>

          <city>Bangalore</city>

          <region>Karnataka</region>

          <code>560103</code>

          <country>India</country>
        </postal>

        <email>praspati@cisco.com</email>
      </address>
    </author>

    <author fullname="Tirumaleswar Reddy" initials="T." surname="Reddy">
      <organization abbrev="Cisco">Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street>Cessna Business Park, Varthur Hobli</street>

          <street>Sarjapur Marathalli Outer Ring Road</street>

          <city>Bangalore</city>

          <region>Karnataka</region>

          <code>560103</code>

          <country>India</country>
        </postal>

        <email>tireddy@cisco.com</email>
      </address>
    </author>

    <author fullname="Reinaldo Penno" initials="R." surname="Penno">
      <organization abbrev="Cisco">Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street>170 West Tasman Drive</street>

          <city>San Jose</city>

          <region>California</region>

          <code>95134</code>

          <country>USA</country>
        </postal>

        <email>repenno@cisco.com</email>
      </address>
    </author>

    <author fullname="Dan Wing" initials="D." surname="Wing">
      <organization abbrev="Cisco">Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street>170 West Tasman Drive</street>

          <city>San Jose</city>

          <region>California</region>

          <code>95134</code>

          <country>USA</country>
        </postal>

        <email>dwing@cisco.com</email>
      </address>
    </author>

    <date />

    <workgroup>PCP Working Group</workgroup>

    <abstract>
      <t>This note describes how Port Control Protocol (PCP) can be used to
      control NATs and Firewalls in multihoming deployments.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="introduction" title="Introduction">
      <t>A host can use the Port Control Protocol (PCP) to flexibly manage the
      IP address and port mapping information on Network Address Translators
      (NATs) or firewalls, to facilitate communications with remote hosts. In
      a multihomed network, there may be multiple PCP servers providing
      Firewall or prefix translation functions to hosts in the network.</t>

      <t>This document covers PCP related considerations in IPv4 and IPv6
      multihomed networks.</t>
    </section>

    <section title="Problem Statement">
      <t>The main problem of a PCP multihoming situation can be succintly
      described as 'one client, multiple servers'. <xref
      target="I-D.ietf-pcp-base">PCP-base</xref> does not address how a PCP
      Client should behave in a situation when it discovers multiple PCP
      Servers and therefore many questions are open to standardization. For
      example, if multiple PCP Servers are discovered through the same
      interface, should the client send PCP requests be sent to all of them?
      Are there significant differences between a multihoming and
      high-availability scenarios? If yes, how can a PCP Client determine one
      versus the other. These are just a few questions related to the
      problem.</t>

      <t>In this document we make the following simplifying assumption:</t>

      <t><list style="symbols">
          <t>Whenever a PCP Client discovers multiple PCP Servers, it will
          send requests to all of them in parallel as described in <xref
          target="I-D.boucadair-pcp-server-selection"></xref>.</t>

          <t>There is no requirement that multiple PCP Servers have the same
          capabilities.</t>

          <t>PCP Requests to different servers are independent, meaning that
          the result of a PCP request to one server does not influence
          another.</t>

          <t>If PCP Servers provides NAT, it is out of scope how the client
          manages ports across PCP Servers. For example, whether PCP Client
          requires all external ports to be the same or whether there are
          ports available at all.</t>
        </list>In all scenarios below PCP client has a single interface unless
      explicitly noted otherwise.</t>
    </section>

    <section anchor="ipv6_multi" title="IPv6 Multihoming">
      <t>In an IPv6 multihomed network, two or more routers co-located with
      firewalls are present on a single link shared with the host(s). Each
      router is in turn connected to a different service provider network and
      the host in this environment would be offered multiple prefixes and
      advertised multiple DNS/NTP servers. Consider a scenario in which
      firewalls within an IPv6 multihoming environment also implement a PCP
      Server. PCP client learns of the available PCP servers by using DHCP
      <xref target="I-D.ietf-pcp-dhcp"></xref> or any other PCP server
      discovery technique defined in future specifications. The PCP client
      will send PCP requests in parallel to each of the PCP Servers as
      described in <xref
      target="I-D.boucadair-pcp-server-selection"></xref>.</t>

      <t><figure anchor="Figure1" title="IPv6 Multihoming">
          <artwork align="left"><![CDATA[                       ==================
                       |    Internet    |
                       ==================
                          |          |
                          |          | 
                     +----+-+      +-+----+
                     | ISP1 |      | ISP2 |               
                     +----+-+      +-+----+      ISP Network
                          |          |
    .........................................................
                          |          | 
                          |          |        Subscriber Network
                  +-------+---+ +----+------+
                  | rtr1 with | | rtr2 with | 
                  |   FW1     | |    FW2    |
                  +-------+---+ +----+------+
                          |          |
                          |          | 
                          |          |
                   -----+-+-----+------
                          |
                        +-+-----+ 
                        | Hosts | 
                        +-------+]]></artwork>
        </figure></t>
    </section>

    <section anchor="ipv4_multi" title="IPv4 Multihoming">
      <t>In an IPv4 multihomed network, the gateway router is connected to
      different service provider networks. The host is connected to the
      gateway router and is given a private IPv4 address oblivious to the fact
      that there are multiple service providers. The Gateway router will be
      configured with multiple PCP proxy servers, each corresponding to an
      upstream PCP server. Each PCP Server is announced independently since it
      is within a different ISP. PCP client can learn these multiple PCP proxy
      addresses using DHCP or any other PCP server discovery technique. The
      PCP client, by sending PCP requests in parallel to both the PCP proxies,
      will learn the external IP addresses and ports allocated by each of the
      upstream PCP servers. The Gateway router which implements a PCP Proxy
      <xref target="I-D.bpw-pcp-proxy"></xref> , creates local NAT state,
      modifies the PCP request and forwards it to the PCP server. The incoming
      PCP response will be updated by the PCP Proxy and forwarded to the PCP
      client.</t>

      <figure anchor="Figure3"
              title="IPv4 Multihomed environment with Gateway Router performing NAPT">
        <artwork align="left"><![CDATA[
                     ====================
                     |    Internet       |
                     =====================
                        |              |
                        |              | 
                   +----+--------+   +-+------------+
                   | ISP1        |   | ISP2         |
                   | PCP ServerA |   | PCP ServerB  |
                   +----+--------+   +-+------------+ ISP Network  
                        |              |               
                        |              |        
      ..............................................................
                        |              |
                        | Port1        | Port2    Subscriber Network
                        |              |                 
                   +----+-----------------+            
                   |   NAPT & PCP Proxy   |         
                   |       GW Router      |             
                   +----+-----------------+             
                        |                                
                        |    
                        |
                   -----+-+-----+------
                        |
                      +-+-----+ 
                      | Hosts |  (private address space)
                      +-------+]]></artwork>
      </figure>

      <t></t>
    </section>

    <section title="Other Multihoming use cases">
      <section title="IPv6 Network-Managed Firewall ">
        <t>A network-managed Firewall uses the same techniques as the
        premises-based firewall, but the firewall service is delivered using a
        security appliance positioned in the ISP. The requesting router in
        customer premises may obtain the PCP server addresses from the ISP
        delegating router, and then pass that configuration information on to
        the PCP clients through a DHCP server in the requesting router in the
        customer premises. The PCP client can also learn PCP servers using
        other PCP server discovery techniques. Each PCP Server is announced
        independently since it is within a different ISP.</t>

        <figure anchor="Figure2" title="Network-Managed Firewall">
          <artwork align="left"><![CDATA[                       ====================
                       |    Internet       |
                       =====================
                          |              |
                          |              | 
                     +----+------+     +-+---------+
                     |           |     |           | 
                     | ISP1 with |     | ISP2 with |
                     | FW1       |     | FW2       |  
                     +----+------+     +-+---------+ ISP Network  
                          |              |                      
     ............................................................
                          |              |
                          | Port1        | Port2   Subscriber Network
                          |              |                 
                     +----+-----------------+            
                     |      Gateway         |             
                     |       Router         |             
                     +----+-----------------+             
                          |                                
                          |    
                          |
                     -----+-+-----+------
                          |
                        +-+-----+ 
                        | Hosts | 
                        +-------+]]></artwork>
        </figure>

        <t></t>

        <t>When the PCP client sends a PCP request to the PCP server deployed
        in the ISP and the source address of the PCP request is not the one
        that is delegated by the upstream ISP, then that PCP request will be
        dropped at the ISP by its ingress filter rule. Ingress filtering is
        becoming more popular among ISPs to mitigate the damage of
        denial-of-service (DoS) attacks as explained in section 2.1.2 of <xref
        target="RFC5220"></xref>. In IPv6 multihoming the PCP client will
        eventually learn that the PCP server responds to only PCP requests
        with specific source address after few attempts and hence can discard
        sending PCP requests with wrong source address to the PCP server
        provided by the ISP.</t>
      </section>

      <section anchor="PBR" title="IPv4 Policy based Routing">
        <t>Policy based Routing (PBR) with multi-homing is typically used in
        enterprises to route packets from the same source IP address to
        different ISP based on configuration policies and match conditions
        based on source IP address, destination IP address, destination port,
        DSCP value(s), L4 and L7 protocols (e.g., SIP, RTP, RTSP) etc. For
        e.g. a site with Dual WAN connections Gold-ISP, Bronze-ISP and uses
        Gold-ISP for certain traffic only (e.g. Media). In such a environment
        NAT has different NAT pools and would rely on pre-configured PBR
        policy to determine which NAT address pool to use when an IP packet
        comes from an internal host. PCP allows a host to interact with a
        PCP-controlled NAT device and request an external IP and port.
        Therefore a PCP Server that controls the NAT device with PBR and
        receives a PCP request from a PCP client needs to know from which NAT
        pool to allocate an external IP address and port.</t>

        <t>The PCP PEER request would contain the destination IP address,
        destination port and transport protocol of the remote peer that the
        PCP client will be trying to communicate with. The PCP MAP request
        with FILTER option would also contain the destination IP address,
        transport port but the destination port could be all ports. The NAT
        device based on the information present in the PCP request can
        possibly select the NAT pool, create mapping and return the external
        IP address and port in PCP response.</t>

        <t>There is also a possibility that PBR is determined based on other
        information like L7 protocol, DSCP value(s) that is not conveyed by
        default in the PCP PEER or MAP with FILTER option. Further In case of
        PCP MAP request with just the 3-tuple information (internal port,
        protocol and source IP address), the NAT device does not know which
        NAT pool to use. Hence if the information conveyed in PCP request is
        not sufficient to execute the policy then the PCP server will return a
        new error code (PROVIDE_MORE_DATA) in the PCP response to the PCP
        client asking it to provide additional information in subsequent PCP
        requests. The PCP client can then convey more information like
        DESCRIPTION, DSCP_POLICY using the PCP extensions defined in <xref
        target="I-D.boucadair-pcp-extensions"></xref>.</t>
      </section>
    </section>

    <section title="Multiple interfaces and Servers">
      <t>One interesting case for PCP multi-homing is when a end host such as
      a mobile terminal has multiple interfaces concurrently active, for
      example, Wi-Fi and 3G. In this case PCP client would discover different
      PCP Servers over different interfaces. Although multiple interfaces are
      available, an application might choose to use just one based on, for
      example, bandwidth requirements, and therefore would need to send PCP
      requests to just one PCP Server.</t>

      <t>This scenario requires further discussion. TBD</t>
    </section>

    <section anchor="security" title="Security Considerations">
      <t>Security considerations in <xref target="I-D.ietf-pcp-base"></xref>
      apply to this use.</t>
    </section>

    <section anchor="iana" title="IANA Considerations">
      <t>The following PCP result code is to be allocated :
      PROVIDE_MORE_DATA</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include='reference.I-D.ietf-pcp-base'?>

      <?rfc include='reference.I-D.ietf-pcp-dhcp'?>

      <?rfc include='reference.I-D.bpw-pcp-proxy'?>

      <?rfc include='reference.I-D.boucadair-pcp-extensions'?>

      <?rfc include='reference.I-D.boucadair-pcp-server-selection'?>
    </references>

    <references title="Informative References">
      <?rfc include="reference.RFC.5220"?>

      <!---->
    </references>
  </back>
</rfc>
