[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

PCP Working Group                                               P. Patil
Internet-Draft                                                  T. Reddy
Intended status: Standards Track                                R. Penno
Expires: April 14, 2013                                          D. Wing
                                                                   Cisco
                                                        October 11, 2012


         Using PCP to control NAT and Firewalls in Multihoming
                     draft-patil-pcp-multihoming-00

Abstract

   This note describes how Port Control Protocol (PCP) can be used to
   control NATs and Firewalls in multihoming deployments.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on April 14, 2013.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.




Patil, et al.            Expires April 14, 2013                 [Page 1]


Internet-Draft             PCP in Multihoming               October 2012


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  IPv6 Multihoming  . . . . . . . . . . . . . . . . . . . . . . . 4
   4.  IPv4 Multihoming  . . . . . . . . . . . . . . . . . . . . . . . 4
   5.  Other Multihoming use cases . . . . . . . . . . . . . . . . . . 5
     5.1.  IPv6 Network-Managed Firewall . . . . . . . . . . . . . . . 6
     5.2.  IPv4 Policy based Routing . . . . . . . . . . . . . . . . . 7
   6.  Multiple interfaces and Servers . . . . . . . . . . . . . . . . 7
   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 8
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 8
     9.1.  Normative References  . . . . . . . . . . . . . . . . . . . 8
     9.2.  Informative References  . . . . . . . . . . . . . . . . . . 9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 9



































Patil, et al.            Expires April 14, 2013                 [Page 2]


Internet-Draft             PCP in Multihoming               October 2012


1.  Introduction

   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.

   This document covers PCP related considerations in IPv4 and IPv6
   multihomed networks.


2.  Problem Statement

   The main problem of a PCP multihoming situation can be succintly
   described as 'one client, multiple servers'.  PCP-base
   [I-D.ietf-pcp-base] 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.

   In this document we make the following simplifying assumption:

   o  Whenever a PCP Client discovers multiple PCP Servers, it will send
      requests to all of them in parallel as described in
      [I-D.boucadair-pcp-server-selection].

   o  There is no requirement that multiple PCP Servers have the same
      capabilities.

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

   o  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.

   In all scenarios below PCP client has a single interface unless
   explicitly noted otherwise.





Patil, et al.            Expires April 14, 2013                 [Page 3]


Internet-Draft             PCP in Multihoming               October 2012


3.  IPv6 Multihoming

   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 [I-D.ietf-pcp-dhcp] 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
   [I-D.boucadair-pcp-server-selection].

                          ==================
                          |    Internet    |
                          ==================
                             |          |
                             |          |
                        +----+-+      +-+----+
                        | ISP1 |      | ISP2 |
                        +----+-+      +-+----+      ISP Network
                             |          |
       .........................................................
                             |          |
                             |          |        Subscriber Network
                     +-------+---+ +----+------+
                     | rtr1 with | | rtr2 with |
                     |   FW1     | |    FW2    |
                     +-------+---+ +----+------+
                             |          |
                             |          |
                             |          |
                      -----+-+-----+------
                             |
                           +-+-----+
                           | Hosts |
                           +-------+

                        Figure 1: IPv6 Multihoming


4.  IPv4 Multihoming

   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



Patil, et al.            Expires April 14, 2013                 [Page 4]


Internet-Draft             PCP in Multihoming               October 2012


   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 [I-D.bpw-pcp-proxy] ,
   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.

                        ====================
                        |    Internet       |
                        =====================
                           |              |
                           |              |
                      +----+--------+   +-+------------+
                      | ISP1        |   | ISP2         |
                      | PCP ServerA |   | PCP ServerB  |
                      +----+--------+   +-+------------+ ISP Network
                           |              |
                           |              |
         ..............................................................
                           |              |
                           | Port1        | Port2    Subscriber Network
                           |              |
                      +----+-----------------+
                      |   NAPT & PCP Proxy   |
                      |       GW Router      |
                      +----+-----------------+
                           |
                           |
                           |
                      -----+-+-----+------
                           |
                         +-+-----+
                         | Hosts |  (private address space)
                         +-------+

   Figure 2: IPv4 Multihomed environment with Gateway Router performing
                                   NAPT


5.  Other Multihoming use cases






Patil, et al.            Expires April 14, 2013                 [Page 5]


Internet-Draft             PCP in Multihoming               October 2012


5.1.  IPv6 Network-Managed Firewall

   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.
                          ====================
                          |    Internet       |
                          =====================
                             |              |
                             |              |
                        +----+------+     +-+---------+
                        |           |     |           |
                        | ISP1 with |     | ISP2 with |
                        | FW1       |     | FW2       |
                        +----+------+     +-+---------+ ISP Network
                             |              |
        ............................................................
                             |              |
                             | Port1        | Port2   Subscriber Network
                             |              |
                        +----+-----------------+
                        |      Gateway         |
                        |       Router         |
                        +----+-----------------+
                             |
                             |
                             |
                        -----+-+-----+------
                             |
                           +-+-----+
                           | Hosts |
                           +-------+

                    Figure 3: Network-Managed Firewall

   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 [RFC5220].  In
   IPv6 multihoming the PCP client will eventually learn that the PCP



Patil, et al.            Expires April 14, 2013                 [Page 6]


Internet-Draft             PCP in Multihoming               October 2012


   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.

5.2.  IPv4 Policy based Routing

   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.

   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.

   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
   [I-D.boucadair-pcp-extensions].


6.  Multiple interfaces and Servers

   One interesting case for PCP multi-homing is when a end host such as
   a mobile terminal has multiple interfaces concurrently active, for



Patil, et al.            Expires April 14, 2013                 [Page 7]


Internet-Draft             PCP in Multihoming               October 2012


   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.

   This scenario requires further discussion.  TBD


7.  Security Considerations

   Security considerations in [I-D.ietf-pcp-base] apply to this use.


8.  IANA Considerations

   The following PCP result code is to be allocated : PROVIDE_MORE_DATA


9.  References

9.1.  Normative References

   [I-D.boucadair-pcp-extensions]
              Boucadair, M., Penno, R., and D. Wing, "Some Extensions to
              Port Control Protocol (PCP)",
              draft-boucadair-pcp-extensions-03 (work in progress),
              April 2012.

   [I-D.boucadair-pcp-server-selection]
              Boucadair, M., Penno, R., and D. Wing, "PCP Server
              Selection", draft-boucadair-pcp-server-selection-00 (work
              in progress), September 2012.

   [I-D.bpw-pcp-proxy]
              Boucadair, M., Penno, R., Wing, D., and F. Dupont, "Port
              Control Protocol (PCP) Proxy Function",
              draft-bpw-pcp-proxy-02 (work in progress), September 2011.

   [I-D.ietf-pcp-base]
              Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P.
              Selkirk, "Port Control Protocol (PCP)",
              draft-ietf-pcp-base-28 (work in progress), October 2012.

   [I-D.ietf-pcp-dhcp]
              Boucadair, M., Penno, R., and D. Wing, "DHCP Options for
              the Port Control Protocol (PCP)", draft-ietf-pcp-dhcp-05
              (work in progress), September 2012.



Patil, et al.            Expires April 14, 2013                 [Page 8]


Internet-Draft             PCP in Multihoming               October 2012


9.2.  Informative References

   [RFC5220]  Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama,
              "Problem Statement for Default Address Selection in Multi-
              Prefix Environments: Operational Issues of RFC 3484
              Default Rules", RFC 5220, July 2008.


Authors' Addresses

   Prashanth Patil
   Cisco Systems, Inc.
   Cessna Business Park, Varthur Hobli
   Sarjapur Marthalli Outer Ring Road
   Bangalore, Karnataka  560103
   India

   Email: praspati@cisco.com


   Tirumaleswar Reddy
   Cisco Systems, Inc.
   Cessna Business Park, Varthur Hobli
   Sarjapur Marathalli Outer Ring Road
   Bangalore, Karnataka  560103
   India

   Email: tireddy@cisco.com


   Reinaldo Penno
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, California  95134
   USA

   Email: repenno@cisco.com


   Dan Wing
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, California  95134
   USA

   Email: dwing@cisco.com





Patil, et al.            Expires April 14, 2013                 [Page 9]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/