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

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 November 08, 2014.

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. References
• 6.1. Normative references
• 6.2. Informative references
• Appendix A. Draft source
• Appendix B. Acknowledgements
• Author's Address

1. Introduction

This is mostly discussion fodder; I _personally_ find current PCP proxy defined in [I-D.ietf-pcp-proxy] overcomplex for Homenet needs. So I'm defining Minimalist PCP Proxy (MPP) here instead.

A GPLv2-licensed experimental 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

In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [RFC2119].

3. Requirements for the design

Homenet architecture defined in [I-D.ietf-homenet-arch] allows for multihoming -> multiple PCP servers MUST be supported. Notably, the PCP server choice MUST depend on the source address used by the client.

IPv4 is not yet gone -> dual-stack PCP SHOULD be supported. Proposed homenet prefix assignment algorithm defined in [I-D.pfister-homenet-prefix-assignment] assumes only zero or one upstream IPv4 links, NATted to a single IPv4 prefix.

The amount stored state SHOULD be minimal.

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

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 an IP address that is not provided to any clients (TBD or just some weird port#? We're among consenting routers here after all..). [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 of the server.match.
• Remote epoch tracking (prev_server_time, prev_client_time as per [RFC6887]).

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:

• This scheme cannot be used on PCP proxy nodes that actually perform NAT. In case of firewalling, or forwarding, it should work. This is because original destination address client used to contact the local proxy is reused, to store it for later forwarding the response back to the client. If NAT occurs, this is not possible.
• MPPs cannot be cascaded.
• 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)

Just provide a direct response (given internal interface + local IP), as specified in [RFC6887]. Otherwise, ignore.

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

On receipt of a PCP request on an internal interface on 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.
• 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 THIRD_PARTY is already set, consider the request rejected.
• 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, updating the PCP client IP Address to the adddress 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.

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.
• Check that THIRD_PARTY option is present, and store it for future use. If it is not present, or not in a locally connected prefix, silently drop the packet.
• 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 request forward to the client, with source address matching the original destination address, the destination address matching the address within the removed THIRD_PARTY option, and from the local server port to the remote client port.

6. References

6.1. Normative references

6.2. Informative references

Appendix A. 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 B. 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