PCP Working Group S. Cheshire Internet-Draft Apple Intended status: Standards Track August 28, 2012 Expires: March 1, 2013 PCP Address Invalidation draft-cheshire-pcp-invalidate-00 Abstract Port Control Protocol (PCP) Address Invalidation allows an address allocation agent (e.g. a DHCP Server) to signal to a NAT or firewall that an address that was previously in use is no longer in use, and all state pertaining to it may be discarded. 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 March 1, 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. Cheshire Expires March 1, 2013 [Page 1] Internet-Draft PCP invalidate August 2012 1. Terminology 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 "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119]. 2. Introduction NATs and firewalls create implicit mapping state as a result of seeing outbound traffic from the host. In addition, Port Control Protocol [I-D.ietf-pcp-base] allows a host to explicitly request mappings. All NATs and firewalls have some finite limit on the amount of mapping state they can accomodate, so releasing mapping state when it is no longer required makes those resources available for other clients. When a host leaves the network and its DHCP address lease expires, any mapping state associated with that address is no longer required. In addition, allowing old mapping state to remain after the address is assigned to a new host could potentially expose that new host to unwanted traffic. Therefore, when a DHCP address lease expires or is released, the DHCP server should signal to the NAT or firewall that all mapping state associated with that address should be released. In the case of a typical residential home gateway, the DHCP server is colocated with the NAT or firewall in the same hardware device, and the signal from the DHCP server software component to the NAT or firewall software component can be a simple internal software operation. In the case of an Internet Service Provider, the DHCP server and Large Scale NAT may often be implemented in different devices. In this case it would be useful to have a network protocol to enable the DHCP server to signal Address Invalidation to the Large Scale NAT. This could be done via some proprietary mechanism, or via some SNMP message, but the most natural way to implement this state management message would be via a PCP Opcode. Cheshire Expires March 1, 2013 [Page 2] Internet-Draft PCP invalidate August 2012 3. PCP Address Invalidation When a DHCP address lease expires or is released, and the DHCP server wishes to inform the NAT and/or firewall device(s) of this, it sends the PCP request [I-D.ietf-pcp-base] shown below: Data format for PCP Opcode 3 "INVALIDATE" 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Internal IP Address to Invalidate (128 bits) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: PCP Address Invalidation Request and Response Format When the "Internal IP Address to Invalidate" field is an IPv6 address, the IPv6 address is placed in the field as-is. When the "Internal IP Address to Invalidate" field is an IPv4 address, an IPv4-mapped IPv6 address [RFC4291] is used (::ffff:0: 0/96). This has the first 80 bits set to zero and the next 16 set to one, while its last 32 bits are filled with the IPv4 address. This is unambiguously distinguishable from a native IPv6 address, because an IPv4-mapped IPv6 address [RFC4291] would not be valid for a mapping. The PCP Address Invalidation Request MUST be sent in such a way that its authenticity can be verified by the receiving NAT or firewall. For example, the request could be signed and timestamped to prove that it was generated by an entity authorized to do so (e.g. the DHCP server). Alternatively, the request could be sent over a secure channel, such as TLS, or DTLS, where the identity of the sender is securely verified. In some environments, if the PCP Address Invalidation Request is sent over a private network within a service provider's data centre, with adequate ingress filtering, then merely checking the source IP address of the packet against a whitelist may be adequate. If the request fails such authentication checks, a NOT_AUTHORIZED error MUST be returned. The NAT or firewall replies with a PCP Response containing the same Internal IP Address to Invalidate, and an appropriate response code. If the request was properly authenticated and all existing mapping state (if any) for the specified address was successfully deleted, then a SUCCESS response code (zero) is returned. Otherwise an an Cheshire Expires March 1, 2013 [Page 3] Internet-Draft PCP invalidate August 2012 appropriate non-zero response code is returned. 4. Security Considerations NATs and firewalls MUST verify that PCP Address Invalidation Requests are properly authorized. 5. IANA Considerations IANA is requested to record that PCP Opcode 3 is allocated for "PCP INVALIDATE". 6. 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-26 (work in progress), June 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. Author's Address Stuart Cheshire Apple Inc. 1 Infinite Loop Cupertino, California 95014 USA Phone: +1 408 974 3207 Email: cheshire@apple.com Cheshire Expires March 1, 2013 [Page 4]