Internet DRAFT - draft-baker-pcp-nptv6-search

draft-baker-pcp-nptv6-search






Network Working Group                                           F. Baker
Internet-Draft                                                   D. Wing
Intended status: Informational                             Cisco Systems
Expires: July 23, 2012                                  January 20, 2012


       Using PCP to Find an External Address in an NPTv6 Network
                    draft-baker-pcp-nptv6-search-00

Abstract

   This note describes an approach to finding the set of External
   Addresses associated with an Internal Address.

Requirements

   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 [RFC2119].

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 July 23, 2012.

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



Baker & Wing              Expires July 23, 2012                 [Page 1]

Internet-Draft     Finding external addresses in NPTv6      January 2012


   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.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Using Multicast PCP . . . . . . . . . . . . . . . . . . . . . . 3
     2.1.  PCP Client: Generating a Request  . . . . . . . . . . . . . 3
     2.2.  PCP Server: Processing a Request  . . . . . . . . . . . . . 4
     2.3.  PCP Client: Processing Responses  . . . . . . . . . . . . . 4
     2.4.  Recovery  . . . . . . . . . . . . . . . . . . . . . . . . . 5
   3.  An implementation approach  . . . . . . . . . . . . . . . . . . 5
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
   5.  Operational Considerations  . . . . . . . . . . . . . . . . . . 5
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 6
   8.  Change Log  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     9.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
     9.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 7




























Baker & Wing              Expires July 23, 2012                 [Page 2]

Internet-Draft     Finding external addresses in NPTv6      January 2012


1.  Introduction

   This note uses terminology defined in [I-D.ietf-pcp-base].

   Section 5 of [RFC6296] points out that there can be issues when an
   application refers a session initiated by a peer to a third party
   application running on the same or a different system; it must
   identify the system the third party application is running on.  This
   is often done by citing an IP address or a DNS name that maps to one
   or more IP addresses.

   In a network that uses Network Address Translation or Network Prefix
   Translation technology, referrals using IP addresses imply that the
   application must be able to identify both the Internal and External
   Addresses of the third party.  Similarly, when a peer system queries
   DNS to find an address (either for the initial access or because a
   referral used a DNS name), DNS must supply it with an address
   appropriate to its domain.  If the two are both in the same network,
   that would be the Internal Address, and otherwise all External
   Addresses.

   This note describes an approach to finding the External Addresses
   associated with an Internal Address.


2.  Using Multicast PCP

   Consider a scenario in which the firewall or other system
   implementing the NPTv6 Translator also implements a Port Control
   Protocol (PCP) [I-D.ietf-pcp-base] Server, and that PCP Server joins
   a multicast group ALL-NPTv6-TRANSLATORS.  A PCP Client could send PCP
   Requests to the multicast group, and get responses from every NPTv6
   Translator in the domain.

2.1.  PCP Client: Generating a Request

   The PCP client sends a MAP Request to that multicast group address,
   with Internal Port=0 and Protocol=0 (which means 'all ports for all
   protocols').  To accommodate packet loss, the request SHOULD be
   transmitted several times with a random jitter between them.  It is
   RECOMMENDED to transmit the MAP Request a total of three times with
   the first retransmission after 5 seconds plus a random value between
   0-2.5 seconds, and again at 10 seconds plus a random value between
   0-5 seconds.







Baker & Wing              Expires July 23, 2012                 [Page 3]

Internet-Draft     Finding external addresses in NPTv6      January 2012


2.2.  PCP Server: Processing a Request

   The PCP server embedded in the NPTv6 device first verifies that the
   PCP message conforms to the requirements of a PCP MAP request as
   described in [I-D.ietf-pcp-base].  Then it checks that the MAP
   request field's Protocol and Internal Port are both zero; if not, a
   MALFORMED_REQUEST error is generated.

   If the MAP request contains the THIRD_PARTY option, it MUST contain
   an IPv6 address, otherwise it results in a MALFORMED_OPTION error.

   Then, depending on the IPv6 prefix of the PCP MAP request (or the
   IPv6 prefix of the THIRD_PARTY option, if present):

   1.  If no translation applies to that IPv6 address (i.e., the address
       is not within a prefix that is translated) the Assigned External
       Address of the MAP response is set to the same as the IP address
       from the IP header of the PCP request (unless THIRD_PARTY was
       used, in which case it is set to the IP address of the
       THIRD_PARTY option).

   2.  If a translation would occur, the external address is returned in
       the Assigned External Address field.

   If the NPTv6 device itself is multihomed (i.e., it contains multiple
   NPTv6 translation functions), a separate MAP Response is sent for
   each NPTv6 instance -- as if they were separate devices.  These MAY
   be sent from the same unicast source address.

   It is RECOMMENDED that the Assigned Lifetime of the MAP response be
   the remaining lifetime of the ISP-assigned address.  In this way, PCP
   clients receive timely updates to the IPv6 address assigned by the
   ISP.

2.3.  PCP Client: Processing Responses

   Each MAP request sent to the multicast group will result in zero,
   one, or more responses (from each NPTv6 listening to that multicast
   group).

   If the network contains multiple NPTv6 instances, multiple MAP
   responses will normally be received.  If multiple responses are
   received, the shortest PCP Assigned Lifetime should be used when
   sending renewal multicast PCP requests.

   Renewals should follow the procedure described in Section 10.2.1 of
   [I-D.ietf-pcp-base].




Baker & Wing              Expires July 23, 2012                 [Page 4]

Internet-Draft     Finding external addresses in NPTv6      January 2012


2.4.  Recovery

   An NPTv6 device may join or leave a network unexpectedly (e.g.,
   device failure, link failure, or link recovery).  To accommodate
   these situations, the NPTv6 devices SHOULD implement PCP Rapid
   Recovery, as described in Section 13 of [I-D.ietf-pcp-base].


3.  An implementation approach

   A practical implementation of the PCP client in this case would be in
   a DNS Server [RFC1034][RFC1035].  Whenever it learns of a mapping
   between a name and an Internal Address (which might happen only at
   startup in a static system, or might happen frequently if Dynamic DNS
   [RFC2136][RFC3007] is used with IPv6 Privacy Addresses [RFC4941]),
   the DNS Server queries ALL-NPTv6-TRANSLATORS for the list of relevant
   addresses to create AAAA Resource Records for.  It may get no
   response (although if there are no such translators one would hope
   for an ICMP Host Unreachable response rather than letting it time
   out), one response, or many.  It always makes a Resource Record for
   the Internal Address; it also makes Resource Records for any External
   Addresses reported.  Such translations come with lifetimes; the DNS
   Server is responsible to re-request as lifetimes expire, and to not
   grant longer Resource Record lifetimes than it has address lifetimes.

   Any system needing to know its own External Addresses or those of
   another party could then obtain them by resolving the relevant DNS
   name, or could follow the same process.


4.  IANA Considerations

   This note requests of the IANA the assignment of a set of multicast
   addresses as described in Section 2.7 of the IP Version 6 Addressing
   Architecture [RFC4291] from the registry [v6mult].  This set of
   addresses is referred to as "ALL-NPTv6-TRANSLATORS".  One address
   should be assigned for each of the following scopes: Link-Local,
   Admin-Local, Site-Local, and Organization-Local.


5.  Operational Considerations

   This document defines a set of multicast addresses in several scopes.
   Operationally, the choice of which scope is appropriate is made by
   the administration.  A reasonable default value in system
   configurations might be Organization-Local (e.g., all NPTv6
   Translators operated by the organization).  However, a large
   organization might well choose Site-Local or Admin-Local, and



Baker & Wing              Expires July 23, 2012                 [Page 5]

Internet-Draft     Finding external addresses in NPTv6      January 2012


   consider that "site" or "administrative" domain to include the set of
   NPTv6 Translators advertising a default route into a specific part of
   its network.


6.  Security Considerations

   The principal security threat in this algorithm is a security threat
   inherent to IP multicast routing and any application that runs on it.
   A rogue system can join a multicast group, meaning it that it sees
   traffic sent to the multicast group that it was presumably not
   intended to see, and may originate responses that are not correct or
   infer information.  Such a rogue system also in effect pulls traffic
   toward it, which may not have been planned for in capacity planning.
   In this scenario, the rogue system has the opportunity to learn the
   addresses of every system that has such a translation, and has the
   capability of adding an incorrect External Address to any list of
   External Addresses.  This presents both privacy and security issues.

   The obvious mitigation is authentication and authorization of
   responses returned; requesters should verify that responses are
   coming from systems that the administration thinks are legitimately
   NPTv6 Translators.  PCP does not define an authentication model, and
   does not define the use of TLS/DTLS or others.  Hence, this likely
   implies the use of IPSec, or at least a list of the addresses of
   authorized NPTv6 translators in the network, with administration-
   specific responses to rogue equipment such as ignoring such responses
   or some form of remediation.  If the multicast routing technology
   supports it, refusing such rogue "joins" would be a good idea.

   In addition, the security considerations in [I-D.ietf-pcp-base] also
   apply to this use.


7.  Acknowledgements

   This note resulted a conversation among the authors, Margaret
   Wasserman, Dave Thaler, and Ron Bonica, and from a separate
   conversation with Keith Moore.


8.  Change Log

   Initial Version:  January 2012


9.  References




Baker & Wing              Expires July 23, 2012                 [Page 6]

Internet-Draft     Finding external addresses in NPTv6      January 2012


9.1.  Normative References

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

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, February 2006.

9.2.  Informative References

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, November 1987.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

   [RFC2136]  Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
              "Dynamic Updates in the Domain Name System (DNS UPDATE)",
              RFC 2136, April 1997.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

   [RFC3007]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
              Update", RFC 3007, November 2000.

   [RFC4941]  Narten, T., Draves, R., and S. Krishnan, "Privacy
              Extensions for Stateless Address Autoconfiguration in
              IPv6", RFC 4941, September 2007.

   [RFC6296]  Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix
              Translation", RFC 6296, June 2011.

   [v6mult]   IANA, "IPv6 Multicast Address Space Registry",
              December 2011, <http://www.iana.org/assignments/
              ipv6-multicast-addresses/ipv6-multicast-addresses.xml>.










Baker & Wing              Expires July 23, 2012                 [Page 7]

Internet-Draft     Finding external addresses in NPTv6      January 2012


Authors' Addresses

   Fred Baker
   Cisco Systems
   Santa Barbara, California  93117
   USA

   Email: fred@cisco.com


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

   Email: dwing@cisco.com


































Baker & Wing              Expires July 23, 2012                 [Page 8]