Minimalist Port Control Protocol Proxy
draft-stenberg-homenet-minimalist-pcp-proxy-01

Abstract

This document describes a minimalist PCP proxy function needed within the homenet architecture. It is notably a subset of a general PCP proxy.

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 30, 2015.

Copyright Notice

Copyright (c) 2014 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.

Table of Contents

• 1. Introduction
• 2. Requirements language
• 3. Requirements for the design
• 4. The use case for MPP
• 4.1. State required
• 4.2. Difference from 'general' PCP proxy
• 5. Algorithm
• 5.1. Local epoch reset
• 5.2. Client -> Proxy server port (ANNOUNCE)
• 5.3. Client -> Proxy server port -> Server (MAP/PEER)
• 5.4. Server -> Proxy client port -> Client (MAP/PEER)
• 6. Security Considerations
• 7. IANA Considerations
• 8. References
• 8.1. Normative references
• 8.2. Informative references
• Appendix A. Changelog
• Appendix B. Draft source
• Appendix C. Acknowledgements
• Author's Address

1. Introduction

The (generic) PCP proxy defined in [I-D.ietf-pcp-proxy] seems excessively complex in terms of footprint for home routers, as it requires both PCP server and client implementations glued to each other.

Instead of implementing a full PCP server and client, we define an alternative which requires just simple message forwarding and some state for each PCP server and (recent, reply pending) PCP request. The state required is much less than in the official PCP proxy draft.

A GPLv2-licensed experimental, guaranteedly incomplete, and probably still incorrect sample implementation of MPP is currently under development at https://github.com/fingon/minimalist-pcproxy/ . Comments and/or pull requests are welcome.

2. Requirements language

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

3. Requirements for the design

Homenet architecture document [RFC7368] allows for multi-homing. Therefore multiple PCP servers, one for each CER, MUST be supported. The PCP upstream server choice MUST depend on the source address used by the client.

Given over ninety percent of current home traffic is IPv4, dual-stack PCP SHOULD be supported for the foreseeable future. Proposed homenet prefix assignment algorithm defined in [I-D.ietf-homenet-prefix-assignment] assumes only zero or one upstream IPv4 links, NATted to a single IPv4 prefix. Therefore there is no multi-homing concerns there, but the IPv4 requests MUST be made with the CER that the traffic for the IPv4 prefix is routed to.

The amount stored state SHOULD be minimal.

MPP SHOULD also have as simple as possible implementation for both footprint and correctness validation purposes.

4. The use case for MPP

Each first-hop router in a Homenet runs this algorithm. Each router with upstream connectivity additionally runs a real PCP server, but on either an IP address that is not provided to any clients, or separate port. HNCP [I-D.ietf-homenet-hncp] is used to maintain the information about upstream connections for the running MPP instances, and therefore normal PCP server selection is not needed.

4.1. State required

In addition to the local definition of epoch, for each server, following information is stored and updated as needed:

• Source IP prefix and length to match.
• Remote IP address (and possibly port) of the server to use.
• Remote epoch tracking (prev_server_time, prev_client_time as per PCP standard [RFC6887]).

For each PCP client request that has not been responded to yet, (at least) following information SHOULD be stored:

• Source IP and port number.
• Mapping nonce.
• Flag indicating whether THIRD_PARTY option was added or not by this node.
• [ Server the request was forwarded to - optional ]

The per-client-request structure (and MPP itself) is a potential attack vector, so rate limiting the number of requests, as well as number of total pending client requests, SHOULD be supported.

4.2. Difference from 'general' PCP proxy

The MPP defined here is only a subset of what official PCP proxy draft [I-D.ietf-pcp-proxy] covers. However, it also is MUCH simpler to implement and define. Notable limitations include:

• MPPs may be hard to adapt to real server selection in non-Homenet environments (TBD).

5. Algorithm

Next behavior of MPP is described. MPP MUST have both PCP client and PCP server ports open.

5.1. Local epoch reset

On local epoch reset (when MPP is started, or based on detected epoch reset at one of the servers as defined in Section 5.4), MPP SHOULD send unsolicited multicast ANNOUNCEs as specified in [RFC6887].

5.2. Client -> Proxy server port (ANNOUNCE)

When client sends ANNOUNCE to the proxy's server port on a downstream interface, the proxy should provide a direct response, as specified in [RFC6887].

5.3. Client -> Proxy server port -> Server (MAP/PEER)

On receipt of a PCP request from a client on a downstream interface to the PCP server port, MPP behaves as follows:

• Check if the source IP address and the PCP client IP Address are the same. If a mismatch is detected, the behavior specified in [RFC6887] must be followed. (TBD - third party?)
• Check that for the client's source IP address, there exists a PCP server responsible for it within the local configuration. If not, TBD (error, but which one).
• If the request is rejected, build an error response and send it back to the PCP client. The error status code is set to NOT_AUTHORIZED.
• If the request is accepted, adjust it (e.g., adding a THIRD_PARTY Option if it does not already exist, updating the PCP client IP Address to the address client used when contacting the proxy) and forward it from local client port with the source address matching the IP address in the adjusted request.
• Finally, the proxy should keep track of the request (or at least parts of it, such as client's UDP port number), so that the original port of the client is not lost. As section of 8.1PCP specification [RFC6887] states, client port SHOULD be random and as THIRD_PARTY option contains only the IP address, forwarding of reply is not possibly without keeping track of the client requests.

5.4. Server -> Proxy client port -> Client (MAP/PEER)

On receipt of a PCP response on the PCP client port, MPP behaves as follows:

• Check that source IP matches one of the PCP servers, and that the source port matches PCP server port. If not, silently drop the packet.
• Find matching stored request. After receipt, it can be discarded. If no stored request is found, drop the packet.
• Strip the THIRD_PARTY option, if according to the stored request information one was added.
• Ensure that the per-server epoch is valid per [RFC6887]. If not, reset local epoch.
• Adjust the epoch in the response to local epoch.
• Send the response forward to the client, with source address/port matching the original destination address/port, and the destination address/port matching the stored request's source address/port.

6. Security Considerations

7. IANA Considerations

This document has no actions for IANA.

8. References

8.1. Normative references

8.2. Informative references

Appendix A. Changelog

draft-stenberg-homenet-minimalist-pcp-proxy-01: Cleaned the text somewhat, and added the fact that we DO have to keep track of PCP client port anyway as it is random, and this results in (small) per-active-request state that has to be maintained.

Appendix B. Draft source

As usual, this draft is available at https://github.com/fingon/ietf-drafts/ in source format (with nice Makefile too). Feel free to send comments and/or pull requests if and when you have changes to it!

Appendix C. Acknowledgements

The algorithm text is adapted from draft-ietf-pcp-proxy-04 Section 8. It is unfortunately gone from the more recent iterations.

Author's Address