Internet DRAFT - draft-paddon-pfcp
draft-paddon-pfcp
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<n>
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<n> {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:
<field, minimum-value, maximum-value>
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]