| Network Working Group | M. Boucadair |
| Internet-Draft | C. Jacquenet |
| Intended status: Experimental | France Telecom |
| Expires: January 1, 2016 | June 30, 2015 |
Discovering the Capabilities of Flow-Aware Service Functions (a.k.a. Middleboxes): A PCP-based Approach
draft-boucadair-hops-capability-discovery-00
This document specifies a solution to discover the capabilities of a flow-aware service function. The solution relies upon the use of the Port Control Protocol (PCP).
This solution allows for applications to anticipate connectivity failures and to proceed with countermeasures (e.g., create a mapping for incoming connections, discover a mapping lifetime, discover an external IP address, avoid injecting some options in the outgoing packets, etc.). The propsoed approach allows, for example, to discover whether an upstream flow-aware service function is MPTCP-friendly (that is, it does not strip MPTCP signals) or SCTP-compliant, whether it embeds a firewall function, etc. or a combination thereof.
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].
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 January 1, 2016.
Copyright (c) 2015 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.
Advanced service functions (e.g., Performance Enhancement Proxies ([RFC3135]), NATs [RFC3022][RFC6333][RFC6146], firewalls [I-D.ietf-opsawg-firewalls], etc.) are required to achieve various objectives such as IP address sharing, firewalling, to avoid covert channels, to detect and protect against DDoS attacks, etc.
Removing those functions is not an option because they are used to address constraints that are often typical of the current yet protean Internet situation (global IPv4 address depletion comes to mind, but also the plethora of services with different QoS/security/robustness requirements, etc.), and this is even exacerbated by environment-specific designs (e.g., the nature and the number of service functions that need to be invoked at the Gi interface of a mobile infrastructure).
Moreover, these sophisticated service functions are located in the network but also in service platforms, or other structures like Content Delivery Networks. Some of these service functions can be controlled by hosts (e.g., NAT) to avoid connectivity complications ([RFC6269]) while others are hidden to customers.
This document proposes a solution that can be used by hosts to discover the capabilities of flow-aware service functions that are visible to them but it can also be used by an administrator responsible for the management of such (hidden) service functions, e.g., to inform an SFC controller ([I-D.ww-sfc-control-plane]) about the nature and the status of these service functions. Obviously, exposing this information to hosts/applications is deployment-specific.
Customer-facing flow-aware service functions can announce their capabilities to hosts. This information can be used by a host to select a service function instance (e.g., include the external address of that service function in a referral will involve that service function in the communication path). For example, a host that discovers that the Residential Gateway it is connected to does not support Stream Control Transmission Protocol (SCTP, [RFC4960]), won't even try to use SCTP as a transport protocol; TCP/SCTP happy eyeball proposals are useless in such case.
This document extends the base PCP [RFC6887] with a new option, called CAPABILITY (Section 2), to discover the capabilities of one or several service functions typically embedded in middleboxes. Retrieving the capabilities of these middleboxes is meant to facilitate fault management (e.g., provide a hint about why some applications fail, help select the required actions to instruct the middlebox to handle incoming connections, etc.). This option, when received from a PCP server, is used by a host (and the PCP client) to better adapt the traffic it may send according to the perceived network conditions as exposed in the PCP option (including tweaking PCP requests to instruct mappings).
This specification can also be used to help the introduction of new transport protocols. For example, CPE devices managed by a service provider can include this feature. Also, a service provider that Introduces additional service nodes that support new features (e.g., SCTP-aware CGN) in the network can select the set of CPEs that will be serviced by these nodes. It can do so by setting the SCTP bit when sending the capability information to the selected CPEs. Additional sample use cases are discussed in Section 5.
The CAPABILITY option (Code: TBA, Figure 1) is used by a flow-aware service function to explicitly inform a host about the capabilities that pertain to the said flow-aware service function, especially as far as IP forwarding operations are concerned.
One single CAPABILITY option is conveyed in the same PCP message even if several functions are co-located in the same device (e.g., NAT44 and NAT64, NAT44 and port set assignment capability, etc.).
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CAPABILITY | Reserved | Length=16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A| Capability |
+-+ |
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This Option:
Option Name: PCP Capabilities option (CAPABILITY)
Number: TBA (IANA)
Purpose: Retrieve the capabilities of a PCP-controlled device
Valid for Opcodes: ANNOUNCE, MAP, PEER
Length: 16
May appear in: both request and response
Maximum occurrences: 1
Figure 1: Capability option
When set, the A bit indicates the PCP server supports authentication ([I-D.ietf-pcp-authentication]). If this bit is unset, it indicates that plain PCP is supported.
The Capability Field is encoded in 127 bits. Each bit in the Capability bit mask is used to represent a PCP-controlled device capability. Whenever a bit of the Capability Field is set, this means that the corresponding capability is enabled/supported. Several bits can be set simultaneously if several functions are co-located. The default value for each capability bit is '0'. The meaning associated with the following Capability bits is (other values can be added to the list):
The PCP client includes a CAPABILITY option in a MAP or ANNOUNCE request to learn the capabilities of an upstream PCP-controlled device. When conveyed in a PCP request, the Capability field MUST be set to 0. The CAPABILITY option can be inserted in a MAP request that is used to learn the external IP address, as detailed in Section 11.6 of [RFC6887].
The PCP client MUST be prepared to receive multiple CAPABILITY options (e.g., if several PCP servers are deployed and each of them is configured with a distinct set of capabilities). The PCP client MUST associate each received set of capabilities and suffix with the PCP server from which the information was retrieved.
Upon receipt of an unsolicited PCP ANNOUNCE message, the PCP client replaces the former set of capabilities as received from the same PCP server with the new set of capabilities, as indicated in the CAPABILITY option.
Based on the received capabilities, the host/application/PCP client may decide to tune its requests (e.g., Section 5). For example, a PCP client can use the returned information to decide whether all PCP servers need to be contacted in parallel or only a subset of them , or which service function to solicit in order to establish some sessions (e.g., SCTP).
Activating this feature on the PCP server is subject to administrative authorization procedures.
The PCP server that controls a flow-aware service function SHOULD be configured to provide requesting PCP clients with the supported capabilities whose corresponding bit in the CAPABILITY option will therefore be set. When enabled, the CAPABILITY option conveys the set of capabilities supported by the PCP-controlled device.
If the PCP server is configured to honor the CAPABILITY option but has no means to determine the set of capabilities supported by the local device, the PCP server MUST NOT include any CAPABILITY option in its PCP messages.
The PCP server MAY be configured to include a CAPABILITY option in all MAP responses, even if the CAPABILITY option is not listed in the associated request. The PCP server MAY be configured to include a CAPABILITY option in its ANNOUNCE messages.
In the event of any change of the capabilities supported by the PCP-controlled device (e.g., the activation of a new service function), the PCP server SHOULD issue an unsolicited PCP ANNOUNCE message to inform the PCP client about the updated set of capabilities.
Upon receipt of a PCP request from a PCP client that requires the PCP server to proceed with an operation that is beyond its capabilities, the PCP server MAY return an error code together with the CAPABILITY option.
When a new PCP server joins the network, it MAY then send an ANNOUNCE Opcode with its capabilities (i.e., CAPABILITY option).
__________
+-----------+ +-----------------+ / \ +-----------+
| HOST |___|MPTCP-disabled FW|____| Internet |___| Server |
+-----------+ +-----------------+ \__________/ +-----------+
Figure 2: MPTCP Example
______________________
/ \
| |
| +--------+
| | SCTP- |@IP_Ext1
| |disabled|-----+
| | NAT |
+------+ | Network +--------+
| Host |______| |
+------+ | +-------+
| | SCTP- |@IP_Ext2
| |Enabled|-------
| | NAT |
| +-------+
\_________________________/
Figure 3: SCTP Example
PCP
Client __________
+-----------+ +------+ +------+ / \ +-----------+
|Application|___| NPTv6|___| FW |____| Internet |___|Application|
| Client | | | | | | | | Server |
+-----------+ +------+ +------+ \__________/ +-----------+
Figure 4: NPTv6 and Firewall not collocated with PCP server Capability
+-----+
______|NPTv6|___________
/ +-----+ \
| |
| +-----+
+-----------+ +------+ | | PRR |
|Application|___| IPv6 |______| Network +-----+
|PCP Client| | FW | | |
+-----------+ +------+ | +------+
| | NAT64|
+-----------+ +-------+ | | + |
|PCP client |___|A+P NAT|_____| | FW |
+-----------+ +-------+ | +-----+ +------+
\______|NPTv6|___________/
+-----+
Figure 5: Multiple PCP-controlled devices
Below is provided a non-exhaustive list of use cases to illustrate the benefits of the proposed solution:
PCP-related security considerations are discussed in [RFC6887].
An attacker may generate a PCP message with a fake CAPABILITY option to switch off some features that would have been used by a host. Means to authenticate the PCP server SHOULD be supported.
The following PCP option Code is to be allocated in the optional-to-process range (the registry is maintained in http://www.iana.org/assignments/pcp-parameters/pcp-parameters.xml#options):
A sub-registry is required to track the set of capabilities of PCP-controlled devices.
| [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. |