Internet DRAFT - draft-stenberg-homenet-minimalist-pcp-proxy
draft-stenberg-homenet-minimalist-pcp-proxy
Network Working Group M. Stenberg
Internet-Draft
Intended status: Standards Track October 27, 2014
Expires: April 30, 2015
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.
Stenberg Expires April 30, 2015 [Page 1]
Internet-Draft Minimalist PCP Proxy October 2014
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements language . . . . . . . . . . . . . . . . . . . . 2
3. Requirements for the design . . . . . . . . . . . . . . . . . 3
4. The use case for MPP . . . . . . . . . . . . . . . . . . . . 3
4.1. State required . . . . . . . . . . . . . . . . . . . . . 3
4.2. Difference from 'general' PCP proxy . . . . . . . . . . . 4
5. Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5.1. Local epoch reset . . . . . . . . . . . . . . . . . . . . 4
5.2. Client -> Proxy server port (ANNOUNCE) . . . . . . . . . 4
5.3. Client -> Proxy server port -> Server (MAP/PEER) . . . . 4
5.4. Server -> Proxy client port -> Client (MAP/PEER) . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative references . . . . . . . . . . . . . . . . . . 6
8.2. Informative references . . . . . . . . . . . . . . . . . 6
8.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Appendix A. Changelog . . . . . . . . . . . . . . . . . . . . . 6
Appendix B. Draft source . . . . . . . . . . . . . . . . . . . . 7
Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
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/ [1].
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].
Stenberg Expires April 30, 2015 [Page 2]
Internet-Draft Minimalist PCP Proxy October 2014
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:
o Source IP prefix and length to match.
o Remote IP address (and possibly port) of the server to use.
o 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:
o Source IP and port number.
o Mapping nonce.
Stenberg Expires April 30, 2015 [Page 3]
Internet-Draft Minimalist PCP Proxy October 2014
o Flag indicating whether THIRD_PARTY option was added or not by
this node.
o [ 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:
o 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:
o 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?)
o 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).
Stenberg Expires April 30, 2015 [Page 4]
Internet-Draft Minimalist PCP Proxy October 2014
o 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.
o 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.
o 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:
o 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.
o Find matching stored request. After receipt, it can be discarded.
If no stored request is found, drop the packet.
o Strip the THIRD_PARTY option, if according to the stored request
information one was added.
o Ensure that the per-server epoch is valid per [RFC6887]. If not,
reset local epoch.
o Adjust the epoch in the response to local epoch.
o 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
Stenberg Expires April 30, 2015 [Page 5]
Internet-Draft Minimalist PCP Proxy October 2014
7. IANA Considerations
This document has no actions for IANA.
8. References
8.1. Normative references
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P.
Selkirk, "Port Control Protocol (PCP)", RFC 6887, April
2013.
8.2. Informative references
[RFC7368] Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil,
"IPv6 Home Networking Architecture Principles", RFC 7368,
October 2014.
[I-D.ietf-pcp-proxy]
Perreault, S., Boucadair, M., Penno, R., Wing, D., and S.
Cheshire, "Port Control Protocol (PCP) Proxy Function",
draft-ietf-pcp-proxy-05 (work in progress), February 2014.
[I-D.ietf-homenet-hncp]
Stenberg, M. and S. Barth, "Home Networking Control
Protocol", draft-ietf-homenet-hncp-01 (work in progress),
June 2014.
[I-D.ietf-homenet-prefix-assignment]
Pfister, P., Paterson, B., and J. Arkko, "Prefix and
Address Assignment in a Home Network", draft-ietf-homenet-
prefix-assignment-01 (work in progress), October 2014.
8.3. URIs
[1] https://github.com/fingon/minimalist-pcproxy/
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.
Stenberg Expires April 30, 2015 [Page 6]
Internet-Draft Minimalist PCP Proxy October 2014
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
Markus Stenberg
Helsinki 00930
Finland
Email: markus.stenberg@iki.fi
Stenberg Expires April 30, 2015 [Page 7]
