Network Working Group M. Paddon, Ed. Internet-Draft P. Hawkes Expires: June 13, 2006 Qualcomm Inc. December 10, 2005 Packet Filter Configuration Protocol draft-paddon-pfcp-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. This document may not be modified, and derivative works of it may not be created, except to publish it as an RFC and to translate it into languages other than English. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 13, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract The Packet Filter Configuration Protocol (PFCP) is a client-server protocol which provides a mechanism for trusted clients to dynamically request updates to a packet filtering policy managed by a server. Typically, a server is either a packet filter or an entity which controls one or more packet filters. Since clients may specify Paddon & Hawkes Expires June 13, 2006 [Page 1] Internet-Draft Packet Filter Configuration Protocol December 2005 permitted flows as and when they are required, packet filters configured via PFCP may operate an extremely restrictive default policy. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Message Specification Notation . . . . . . . . . . . . . . . . 6 3.1. Basic Syntax . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Integers . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. Enumerations . . . . . . . . . . . . . . . . . . . . . . . 6 3.4. Fields . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.5. Vectors . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.6. Selections . . . . . . . . . . . . . . . . . . . . . . . . 8 3.7. Aggregates . . . . . . . . . . . . . . . . . . . . . . . . 9 3.8. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Packet Filtering Model . . . . . . . . . . . . . . . . . . . . 10 4.1. Pinholes . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2. Pinholes Sets . . . . . . . . . . . . . . . . . . . . . . 11 4.3. Algorithm . . . . . . . . . . . . . . . . . . . . . . . . 11 5. Security Model . . . . . . . . . . . . . . . . . . . . . . . . 12 6. Protocol Definition . . . . . . . . . . . . . . . . . . . . . 13 6.1. Client Requests . . . . . . . . . . . . . . . . . . . . . 13 6.1.1. Hello Request . . . . . . . . . . . . . . . . . . . . 14 6.1.2. Create Request . . . . . . . . . . . . . . . . . . . . 14 6.1.3. List Request . . . . . . . . . . . . . . . . . . . . . 15 6.1.4. Get Request . . . . . . . . . . . . . . . . . . . . . 15 6.1.5. Destroy Request . . . . . . . . . . . . . . . . . . . 15 6.1.6. Cleanup Request . . . . . . . . . . . . . . . . . . . 15 6.1.7. Goodbye Request . . . . . . . . . . . . . . . . . . . 16 6.1.8. Pinhole Specification . . . . . . . . . . . . . . . . 16 6.1.9. Constraint Specification . . . . . . . . . . . . . . . 16 6.2. Server Responses . . . . . . . . . . . . . . . . . . . . . 18 6.2.1. Hello Response . . . . . . . . . . . . . . . . . . . . 19 6.2.2. Create Response . . . . . . . . . . . . . . . . . . . 19 6.2.3. List Response . . . . . . . . . . . . . . . . . . . . 19 6.2.4. Get Response . . . . . . . . . . . . . . . . . . . . . 20 6.2.5. Destroy Response . . . . . . . . . . . . . . . . . . . 20 6.2.6. Cleanup Response . . . . . . . . . . . . . . . . . . . 20 7. Stream Transport of PFCP . . . . . . . . . . . . . . . . . . . 21 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 9. Informative References . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 Intellectual Property and Copyright Statements . . . . . . . . . . 24 Paddon & Hawkes Expires June 13, 2006 [Page 2] Internet-Draft Packet Filter Configuration Protocol December 2005 1. Introduction The use of packet filters to enforce ingress and egress policy at network borders is widespread. Such filtering is often performed either by general purpose routers or by specialized devices such as firewalls, topologically placed so as to intercept all packets traversing the border. Since, in general, networks may have multiple borders, they may need to deploy multiple packet filtering devices, each with it's own distinct policy. Good packet filtering policy involves striking a balance between being permissive enough to support legitimate traffic and restrictive enough to minimize malicious traffic. In networks with predictable packet flows, it may be possible to define a static policy that strikes this balance. In the general case, however, it is more secure to block most or all traffic by default, and to allow trusted entities to authorize specific flows as required. This document specifies the Packet Filter Configuration Protocol (PFCP). PFCP is a client-server protocol which provides a mechanism for clients to dynamically update a packet filtering policy managed by a server. Each node within a network is generally aware of which flows it is prepared to engage in. For a typical node, these flows are completely described by the classes of packet that its network stack is prepared to generate or respond to, plus the classes of packet that application sockets are prepared to generate or respond to. A node which acts as a PFCP client may therefore request packet filtering policy to be updated to permit these flows, usually in an entirely automated fashion. Furthermore, a node may modify its requests to permit only a subset of these possible flows, in order to express a more restrictive security policy. This is often possible when the node, or its applications, have access to additional knowledge about the purpose of the flow. A PFCP client, however, need not be a peer node in the protected network. In general, any trusted entity which needs to manipulate packet filtering policy may act as a client. For instance, a trusted entity which makes policy requests on behalf of a node is known as a PFCP proxy. Such proxies might be used to support nodes which may not be PFCP aware. Proxies may generate policy update requests by any mechanism; typical examples might be from stored profiles, or by observing packets transmitted and received by the proxied node. Another class of PFCP client is any entity which modifies policy based on observation of the network as a whole. For instance, an instrusion detection system may use PFCP to respond to potential threats. Paddon & Hawkes Expires June 13, 2006 [Page 3] Internet-Draft Packet Filter Configuration Protocol December 2005 Servers are typically packet filters, or entities which control one or more packet filters. When a server controls multiple filters, it is effectively providing a unified view and a single point of service for policy management to clients. Such servers may, in turn, use PFCP to control the actual filters (thereby acting as PFCP clients), or they may use some other mechanism. Paddon & Hawkes Expires June 13, 2006 [Page 4] Internet-Draft Packet Filter Configuration Protocol December 2005 2. Terminology This section provides general definitions of selected key terms used in this document. Some of these terms are more precisely defined in later sections. Blackhole: a pinhole which specifies unacceptable packets. Flow: a sequence of semantically associated packets, for example all packets associated with a TCP session or UDP exchange. Flows may be simplex or duplex. Flow state: a state record maintained by a packet filter in order to identify packets belonging to an established flow. Packet filter a device which intercepts packets, and which only forwards those packets which satisfy its filtering policy. Pinhole: a specification of constraints on a packet. Stateful filtering: the use of flow states by a packet filter to forward packets belonging to an existing flow. Whitehole: a pinhole which specifies acceptable packets. 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 [5]. Paddon & Hawkes Expires June 13, 2006 [Page 5] Internet-Draft Packet Filter Configuration Protocol December 2005 3. Message Specification Notation This document describes the external representation of various messages. In order to specify these external formats in a precise and convenient way, the following semi-formal notational conventions are used. 3.1. Basic Syntax Literal numbers are expressed as decimal values, unless they are prefixed by "0x" in which case they are expressed as hexadecimal values. The notation "x^y" is used to denote x to the y'th power. Identifiers are alphanumeric sequence of characters, beginning with an alphabetic character. In this context, an underscore character is considered alphabetic. Whitespace is used to separate syntactic tokens, and is optional where its absence does not create ambiguity. Any non-empty sequence of whitespace characters is treated identically to a single space character. Comments are introduced with "/*" and terminated with "*/", and are treated as whitespace. 3.2. Integers An unsigned integer is a type which represents a contiguous sequence of bits, interpreted as a most-significant-bit first, 2's complement encoding of an unsigned integer value. An unsigned integer is denoted with the following syntax: unsigned where "n" is the length of the unsigned integer in bits. Such a type can hold integer values in the range 0 to 2^n-1 inclusive. For example, an octet sized unsigned integer type is denoted by: unsigned<8> 3.3. Enumerations An enumeration is an unsigned integer type which may only assume one of a specified set of values. An enumeration is declared with the following syntax: enum {id_0(v_0), id_1(v_1), ..., id_k(v_k)} name; where "n" is the length of the field in bits, "id_0" through "id_k" Paddon & Hawkes Expires June 13, 2006 [Page 6] Internet-Draft Packet Filter Configuration Protocol December 2005 are identifiers for all permitted values, "v_0" through "v_k" are the literal values with each identifiers, and "name" is the identifier assigned to this enumeration. Within an enumeration, each "id_0" through "id_k" must be a unique identifier and each and "v_0" through "v_k" must be a unique literal value. Each literal value must fall within the range 0 through 2^n-1 inclusive. For example, the two bit enumerator called "color", with three valid values, is declared by: enum<2> {red(0), green(1), blue(2)} color; 3.4. Fields A field is declared with the following syntax: type name; where "type" specifies the field's type, and "name" is the identifier assigned to the field. For example, the field "mycolor" of type "color" is declared by: color mycolor; Several declarations, one after the other, specify a contiguous sequence of fields. For example a sequence of two colors is declared by: color foreground; color background; 3.5. Vectors A vector is a field consisting of a sequence of values, all of the same type. A fixed length vector is declared with the following syntax: type name[n]; where "type" is the field type, "n" is the literal number of members and "name" is the identifier assigned to the vector. More generally, vectors may be variable length. A vector with as few as "p" members and as many as "q" members is declared with the following syntax: type name[p..q]; Paddon & Hawkes Expires June 13, 2006 [Page 7] Internet-Draft Packet Filter Configuration Protocol December 2005 The actual length of such a vector in a given message is usually specified in an accompanying field. The i-th member of vector "v" is referred to as "v[i]", with the first member always being at index zero. For example, a vector called "mycolors", of between 0 and 10 members, is declared by: color mycolors[0..10]; 3.6. Selections A selection is a choice of fields based on the value of a control field. The control field is usually contained elsewhere in the message, or in a previous message. A selection is declared with the following syntax: select (control){ case v_0: d_0 case v_1: d_1 ... case v_k: d_k default: d_default }; where "control" is the identifier of the control field, "v_0" through "v_k" are possible control field values and "f_0" through "f_k" are sequences of zero or more field declarations. The control field values "v_0" through "v_k" may be literal values or identifiers of enumerated values (if the control field is an enumeration). The default clause is optional, and declares fields when the control field is unmatched. If there is no match and no default clause, no fields are selected. For example, a selection controlled by "mycolors" is declared by: color mycolor; select (mycolor){ case red: unsigned<8> r; case blue: unsigned<8> g; case green: unsigned<8> b; }; Depending on the value of the "mycolor" field in each message instance, the message will contain exactly one "r", "g" or "b" field. Paddon & Hawkes Expires June 13, 2006 [Page 8] Internet-Draft Packet Filter Configuration Protocol December 2005 3.7. Aggregates An aggregate is a type which encapsulates zero or more fields, and is declared with the following syntax: struct {f} name; where "f" is a seqence of zero or more field declarations, and "name" is the identifier assigned to the aggregate. For example, an aggregate "twocolors" is declared by: struct {color foreground; color background;} twocolors; 3.8. Messages Messages are specified by declaring aggregates. A message may be regarded as a sequence of fields, whose order is defined by the order of declaration (when a field itself is an aggregate, all of its members are regarded as preceding the next field). Each field is ultimately resolvable to a sequence of bits, therefore, a message may itself be regarded as a sequence of bits. When a message is packed into a sequence of octets, the n'th bit of the message is stored as in bit (n mod 8) of byte (n div 8), where all bits and bytes are counted from zero. If (n mod 8) is non-zero, the trailing bits in the last octet should be set to zero. Paddon & Hawkes Expires June 13, 2006 [Page 9] Internet-Draft Packet Filter Configuration Protocol December 2005 4. Packet Filtering Model PFCP presents a standardized packet filtering model to clients. This permits clients to interoperate with a network's packet filters effectively regardless of the underlying topology or filtering technology. PFCP servers are responsible for mapping client requests into a configuration suitable for their underlying technology. The PFCP filtering model is based on the concept of a packet classifier called a "pinhole". A pinhole is a specification of constraints that any given packet will either satisfy or fail to satisfy. Each packet that enters the filter is first matched against a set of pinholes, called "whiteholes", that selects for permitted traffic (non-matching packets are discarded). Surviving packets are then matched against a set of "blackholes", that selects for forbidden traffic (matching packets are discarded). The filtering policy is specified by creating and destroying these whiteholes and blackholes. Whiteholes may be marked as "stateful". If a packet matches any stateful whitehole, and that packet subsequently survives the blackholes, then a flow state is created. This state is used to "short-circuit" the processing of all other packets belonging to the flow; the packets are immediately forwarded without being subjected to whiteholes and blackholes. Flow states are managed automatically by the underlying filtering technology. Pinholes are independent of each other, and the semantics of a pinhole set is identical regardless of the order in which its elements were created. This property permits implementations to build highly scalable classifiers, that can dynamically updated in an efficient fashion. 4.1. Pinholes A pinhole is a specification of constraints on a packet. Packets that satisfy these constraints are said to match that pinhole. More formally, a pinhole is defined as a list of one or more constraint vectors, of the form: where field identifies a packet field, and minimum-value and maximum- value specify the inclusive range of acceptable integral values that the field may take. A packet that satisfies all the constraint vectors in a given pinhole is said to match that pinhole. In all Paddon & Hawkes Expires June 13, 2006 [Page 10] Internet-Draft Packet Filter Configuration Protocol December 2005 other cases, it does not match. In order to satisfy a constraint vector, a packet must contain the field specified by the vector. If the minimum and maximum values for a given field are equal, then the constraint vector will only match that specific value. If the minimum and maximum values cover a field's range, then the vector matches any value that the field may take. 4.2. Pinholes Sets A group of pinholes is known as a pinhole set. A packet is said to match a pinhole set if, and only if, it matches at least one pinhole in the set. An intuitive geometric interpretation is that of a barrier punctured by holes of varying shapes and sizes; only packets that pass through a hole survive the matching process. The order in which pinholes are defined has no effect on matching semantics. 4.3. Algorithm Each packet entering a filter is subjected to the following processing steps: 1. If the packet matches a flow state, then forward the packet and exit. 2. If the packet doesn't match the whitehole set, then discard the packet and exit. 3. If the packet matches the blackhole set, then discard the packet and exit. 4. If the packet matches any stateful whitehole, then create a new flow state. 5. Forward the packet. Paddon & Hawkes Expires June 13, 2006 [Page 11] Internet-Draft Packet Filter Configuration Protocol December 2005 5. Security Model PFCP presents a simple user based security model to clients. Each PFCP session is associated with exactly one user identifier during session initiation. The user identifier is used to assign ownership to pinholes: o Pinholes created during a session are owned by that session's user. o A user may only view or manipulate pinholes which they own. Note that pinholes survive any given PFCP session. Servers may honor or refuse pinhole creation requests, thereby determining what capabilities a user should possess. For instance, a server may prevent a user from creating pinholes that affect addresses assigned to others. The definition and management of such policies falls outside the scope of PFCP. Servers must authenticate clients before associating them with a user. Client authentication falls outside the scope of PFCP. Paddon & Hawkes Expires June 13, 2006 [Page 12] Internet-Draft Packet Filter Configuration Protocol December 2005 6. Protocol Definition PFCP is a client-server session oriented protocol, with a simple request-response structure. It assumes the presence of a transport layer which provides reliable in-order delivery of messages between client and server. A PFCP session consists of exactly one hello request, zero or more operational requests, and is terminated by a goodbye request. A server returns exactly one response to each request, except the goodbye which always succeeds and receives no response. A client may "pipeline" requests, by sending multiple request messages without waiting for a server response. The server must always send responses in the same order as the requests were received. Both the client and the server may terminate the underlying transport at any time. When this occurs, clients must assume that any unacknowledged request is in an indeterminate state: it may or may not have been processed. 6.1. Client Requests A client request consists of a request type, followed by a request specific body (if applicable). enum<8> { HELLO_REQUEST (0), CREATE_REQUEST (1), LIST_REQUEST (2), GET_REQUEST (3), DESTROY_REQUEST (4), CLEANUP_REQUEST (5), GOODBYE_REQUEST (6) } RequestType; struct { RequestType request_type; select (request_type){ case HELLO_REQUEST: HelloRequest; case CREATE_REQUEST: CreateRequest; case LIST_REQUEST: ListRequest; case GET_REQUEST: GetRequest; case DESTROY_REQUEST: DestroyRequest; case CLEANUP_REQUEST: CleanupRequest; case GOODBYE_REQUEST: GoodbyeRequest; }; Paddon & Hawkes Expires June 13, 2006 [Page 13] Internet-Draft Packet Filter Configuration Protocol December 2005 } Request; Requests may be sent in any order, unless otherwise noted. 6.1.1. Hello Request A client must send a hello request as the first request of every session. A hello request specifies the PFCP version and the user identifier to be used for the duration of the session. struct { unsigned<4> major; /* major protocol number */ unsigned<4> minor; /* minor protocol number */ unsigned<16> user_length; /* octets of user id */ unsigned<8> user[0..2^16-1]; /* user identifier */ } ProtocolRequest; A user identifier is a sequence of octets that used by the server to assign a user to the new session. If the user identifier is specified as zero length, then the server will automatically assign the session to a user (if possible). Otherwise, the server will assign the requested user to the session (if permitted). A client must send a hello request as the first request of every session, and may continue to transmit hello requests until one succeeds. A client must not send any other request until the server responds successfully to a hello request. A client must not send hello requests after this point. Any request (other than a hello) received by a server before a successful hello response must be treated as a protocol error. Any hello request received by a server after a successful hello response must be treated as a protocol error. 6.1.2. Create Request A create request is used to create pinholes. Up to 2^16-1 pinholes may be specified. struct { unsigned<16> pinhole_count; /* number of pinholes */ Pinhole pinholes[0..2^16-1]; /* pinhole definitions */ } CreateRequest; Each create request is an atomic operation. If it succeeds, then all the requested pinholes will have been created. If it fails, then it is guaranteed that none of the requested pinholes were created. Paddon & Hawkes Expires June 13, 2006 [Page 14] Internet-Draft Packet Filter Configuration Protocol December 2005 On success, each new pinhole is assigned a distinct (relative to the user) pinhole identifier (PID). PIDs retain their meaning between sessions. 6.1.3. List Request A list request is used to retrieve the current set of PIDs assigned to the user. struct { } ListRequest; 6.1.4. Get Request A get request is used to retrieve the definition of pinholes. Up to 2^16-1 pinhole identifiers may be specified in each request. struct { unsigned<16> pid_count; /* number of pinholes */ unsigned<64> pids[0..2^16-1]; /* pinhole identifiers */ } GetRequest; A get request is not an atomic operation. It will return the details of as many pinholes as possible. 6.1.5. Destroy Request A destroy request is used to destroy arbitrary pinholes. Up to 2^16-1 pinhole identifiers may be specified in each request. struct { unsigned<16> pid_count; /* number of pinholes */ unsigned<64> pids[0..2^16-1]; /* pinhole identifiers */ } DestroyRequest; Each destroy request is an atomic operation. If it succeeds, then all the identified pinholes will have been destroyed. If it fails, then it is guaranteed that none of the identified pinholes were destroyed. Once a pinhole is destroyed, its PID may be reassigned. 6.1.6. Cleanup Request A cleanup request is used to destroy all pinholes associated with the session's user. struct { } CleanupRequest; Paddon & Hawkes Expires June 13, 2006 [Page 15] Internet-Draft Packet Filter Configuration Protocol December 2005 6.1.7. Goodbye Request A goodbye request is used to terminate a session. There is no response to a goodbye request, and the request always succeeds. struct { } GoodbyeRequest; 6.1.8. Pinhole Specification A pinhole specification consists of a pinhole type and a set of constraints. enum<2> { WHITEHOLE (0), /* a whitehole */ WHITEHOLE_STATEFUL (1), /* a stateful whitehole */ BLACKHOLE (2) /* a blackhole */ } PinholeType; struct { PinholeType pinhole_type; unsigned<6> constraint_count; Constraint constraint[0..63]; } Pinhole; A pinhole containing more than one constraint specifying the same header field is illegal. Such pinholes must not be transmitted If such a pinhole is received, the entire enclosing request must be treated as badly formed. 6.1.9. Constraint Specification A constraint specification consists of a header field identifier and an associated range of values. enum<8> { IP_VERSION (0), /* IP version number */ IP_PROTOCOL (1), /* next level protocol number */ IP4_DSCP (16), /* IPv4 differentiated services */ IP4_SRC_ADDR (17), /* IPv4 source address */ IP4_DST_ADDR (18), /* IPv4 destination address */ IP6_CLASS (32), /* IPv6 traffic class */ IP6_FLOW (33), /* IPv6 flow label */ IP6_SRC_ADDR (34), /* IPv6 source address */ IP6_DST_ADDR (35), /* IPv6 destination address */ ICMP4_TYPE (48), /* ICMPv4 message type */ ICMP4_CODE (49), /* ICMPv4 message code */ ICMP6_TYPE (64), /* ICMPv6 message type */ Paddon & Hawkes Expires June 13, 2006 [Page 16] Internet-Draft Packet Filter Configuration Protocol December 2005 ICMP6_CODE (65), /* ICMPv6 message code */ UDP_SRC_PORT (80), /* UDP datagram source port */ UDP_DST_PORT (81), /* UDP datagram destination port */ TCP_SRC_PORT (96), /* TCP segment source port */ TCP_DST_PORT (97) /* TCP segment destination port */ } HeaderField; struct { HeaderField header_field; select (header_field){ case IP_VERSION: Range8 ip_version_range; case IP_PROTOCOL: Range8 ip_protocol_range; case IP4_DSCP: Range8 ip4_dscp_range; case IP4_SRC_ADDR: Range32 ip4_src_addr_range; case IP4_DST_ADDR: Range32 ip4_dst_addr_range; case IP6_CLASS: Range8 ip6_class_range; case IP6_FLOW: Range32 ip6_flow_range; case IP6_SRC_ADDR: Range128 ip6_src_addr_range; case IP6_DST_ADDR: Range128 ip6_dst_addr_range; case ICMP4_TYPE: Range8 icmp4_type_range; case ICMP4_CODE: Range8 icmp4_code_range; case ICMP6_TYPE: Range8 icmp6_type_range; case ICMP6_CODE: Range8 icmp6_code_range; case UDP_SRC_PORT: Range16 udp_src_port_range; case UDP_DST_PORT: Range16 udp_dst_port_range; case TCP_SRC_PORT: Range16 tcp_src_port_range; case TCP_DST_PORT: Range16 tcp_dst_port_range; }; } Constraint; struct { unsigned<8> minimum; unsigned<8> maximum; } Range8; struct { unsigned<16> minimum; unsigned<16> maximum; } Range16; struct { unsigned<32> minimum; unsigned<32> maximum; } Range32; struct { unsigned<128> minimum; unsigned<128> maximum; Paddon & Hawkes Expires June 13, 2006 [Page 17] Internet-Draft Packet Filter Configuration Protocol December 2005 } Range128; 6.2. Server Responses A server response consists of a generic response header, followed by a request specific body (if applicable). enum<2> { REQUEST_OK (0), /* request succeeded */ REQUEST_DEFERRED (1), /* resubmit request later */ BAD_REQUEST (2), /* badly formed request */ PROTOCOL_ERROR (3), /* unexpected request */ REQUEST_DENIED (4) /* request not performed */ } ResponseCode; struct { ResponseCode response_code; unsigned<6> backoff; select (request_type){ case HELLO_REQUEST: HelloResponse; case CREATE_REQUEST: CreateResponse; case LIST_REQUEST: ListResponse; case GET_REQUEST: GetResponse; case DESTROY_REQUEST: DestroyResponse; case CLEANUP_REQUEST: CleanupResponse; }; } Response; The defined response codes have the following meanings: REQUEST_OK: the request succeeded. Returned after a successfully completed request. REQUEST_DEFERRED: the request was deferred. Returned whenever a server cannot fulfil a request due to temporary resource shortages. The request may be resubmitted again by the client. In this case, the backoff field contains a server specified hint that the client should wait approximately 2^backoff seconds before trying again. BSD_REQUEST: the request was badly formed. Returned whenever a server cannot correctly parse a request message. PROTOCOL_ERROR: the request was unexpected. Returned whenever a server receives as request that is not permitted at this point in the session. Paddon & Hawkes Expires June 13, 2006 [Page 18] Internet-Draft Packet Filter Configuration Protocol December 2005 REQUEST_DENIED: the request was denied. Returned whenever a server does not fulfil a request due to access control violations. The request must not be resubmitted again by the client. 6.2.1. Hello Response A well formed hello request should never be denied. The response body is alway empty. struct { } HelloResponse; 6.2.2. Create Response If the create request was successful, a list of pinhole identifiers is returned. There is exactly one identifier returned for each pinhole requested, in the same order as in the request. If the request is denied, a list of indices is returned. Each index identifies a denied pinhole specification in the original request (the first specification is offset 0). struct { select (response_type){ case REQUEST_OK: /* list of pinhole identifiers */ unsigned<16> pid_count; unsigned<64> pids[0..2^16-1]; case REQUEST_DENIED: /* list of denied request indices */ unsigned<16> index_count; unsigned<16> indices[0..2^16-1]; }; } CreateResponse; 6.2.3. List Response A well formed list request should never be denied. On success, a list of pinhole identifiers is returned. struct { /* list of defined pinhole identifiers */ unsigned<64> pid_count unsigned<64> pids[0..2^64-1]; } ListResponse; Paddon & Hawkes Expires June 13, 2006 [Page 19] Internet-Draft Packet Filter Configuration Protocol December 2005 6.2.4. Get Response A well formed get request should never be denied. On success, a list of indices and a list of pinhole specifications is returned. Each index identifies an undefined pinhole identifier in the original request (the first identifier is offset 0). Each pinhole specification returned is associated with each successfully retrieved pinhole identifier, in turn. struct { select (response_type){ case REQUEST_OK: /* list of denied request indices */ unsigned<16> index_count; unsigned<16> indices[0..2^16-1]; /* list of pinholes */ unsigned<16> pinhole_count; Pinhole pinholes[0..2^16-1]; }; } GetResponse; 6.2.5. Destroy Response If the destroy request is denied, a list of indices is returned. Each index identifies an undefined pinhole identifier in the original request (the first identifier is offset 0). struct { select (response_type){ case REQUEST_DENIED: /* list of denied request indices */ unsigned<16> index_count; unsigned<16> indices[0..2^16-1]; }; } DestroyResponse; 6.2.6. Cleanup Response A well formed cleanup request should never be denied. The response body is alway empty. struct { } CleanupResponse; Paddon & Hawkes Expires June 13, 2006 [Page 20] Internet-Draft Packet Filter Configuration Protocol December 2005 7. Stream Transport of PFCP PFCP presumes a message oriented transport. In cases where PFCP is to be carried over a stream oriented transport, a framing mechanism is desirable to preserve record boundaries. Over a stream oriented transport, each PFCP message should be preceded by the following frame header: struct { /* length, in octets, of the following frame */ unsigned<64> frame_octets; } FrameHeader; The frame header defines the length, in octets, of the following frame. It does not include the length of the frame header. Implementations must not generate frames that exceed 2^64-1 octets in length. Paddon & Hawkes Expires June 13, 2006 [Page 21] Internet-Draft Packet Filter Configuration Protocol December 2005 8. Security Considerations PFCP is inherently security sensitive. Attackers who can actively pose as legitimate users or modify legitimate users' requests can subvert the operation of a packet filter. Attackers who can passively intercept PFCP traffic may discover exploitable pinholes that they might not otherwise find. Therefore, the authenticity and integrity of PFCP sessions is an absolute requirement, and privacy is highly desirable. Protocols such as TLS provide authenticity, integrity and privacy, and should be considered as suitable transports for PFCP. PFCP has a strong requirement for client authentication. A PFCP server must be able to authenticate a client sufficiently to either assign or authorize user credentials to each session. 9. Informative References [1] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [2] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [3] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981. [4] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [6] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [7] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [8] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 2463, December 1998. [9] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. Paddon & Hawkes Expires June 13, 2006 [Page 22] Internet-Draft Packet Filter Configuration Protocol December 2005 Authors' Addresses Michael Paddon (editor) Qualcomm Inc. Level 3, 230 Victoria Road Gladesville, NSW 2111 Australia Phone: +61 2 9817 4188 Email: mwp@qualcomm.com Philip Hawkes Qualcomm Inc. Level 3, 230 Victoria Road Gladesville, NSW 2111 Australia Phone: +61 2 9817 4188 Email: phawkes@qualcomm.com Paddon & Hawkes Expires June 13, 2006 [Page 23] Internet-Draft Packet Filter Configuration Protocol December 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Paddon & Hawkes Expires June 13, 2006 [Page 24]