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]