Internet DRAFT - draft-cheshire-pcp-invalidate
draft-cheshire-pcp-invalidate
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]
