Network Working Group                                       Jari Arkko
INTERNET-DRAFT                                                Ericsson
Category: Informational
<draft-arkko-pfkey-reference-00.txt>
July 14, 2000



     PF_KEY Extensions for Reducing Policy Information in Kernel


1.  Status of this Memo

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. Internet-Drafts are working docu-
ments of the Internet Engineering Task Force (IETF),  its  areas,  and
its  working groups.  Note that other groups may also distribute work-
ing documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six  months
and  may  be updated, replaced, or made obsolete 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   may    be    found    at
http://www.ietf.org/ietf/1id-abstracts.txt

The  list  of  Internet-Draft  Shadow  Directories  may  be  found  at
http://www.ietf.org/shadow.html.

The distribution of this memo is unlimited.  It is  filed  as  <draft-
arkko-pfkey-reference-00.txt>,  and   expires January 1, 2001.  Please
send comments to the author or to pf_key@inner.net.

2.  Abstract

PF_KEY is a generic key management API that can be  used  with  IPsec.
This document discusses the extension of the PF_KEY interface in order
to lessen the need to store complicated IPsec policy data  in  kernel-
mode  implementations, and to make it possible for key management dae-
mons reuse traffic pattern information already present in the kernel.

3.  Introduction

PF_KEY [1] is a generic key management API that can be used with,  for
instance,  IPsec  [2].  PF_KEY  is  a  socket  protocol family used by
trusted privileged key management applications to communicate with  an
operating system's kernel-mode implementation of IPsec.

Experience in implementing PF_KEY-based systems  has  uncovered  areas
where  PF_KEY  lacks  functionality  which is needed for IPsec and IKE
[3].  These areas include certain missing algorithms, missing  mechan-
isms to handle IPsec SA bundles, and unnecessary duplication of policy
information in several parts of a system. This document describes  one



J. Arkko                                                      [Page 1]





INTERNET-DRAFT            PF_KEY Extensions              July 14, 2000


possible  way to extend PF_KEY. It is targeted as a starting point for
discussions and does not claim to solve all known PF_KEY problems.

In this document we discuss the extension of the PF_KEY  interface  in
two respects:

        (a)     Enabling kernel mode IPsec implementations to
                know less about IPsec policies, such as what
                algorithms should be used. At the same time
                features previously not supported by PF_KEY - such
                as IPsec SA bundles - can be implemented over
                PF_KEY in a transparent manner.

        (b)     Enabling key management daemon implementations to
                delegate all traffic pattern matching to
                the kernel. Presently, traffic pattern matching
                must be performed both in the kernel for
                outgoing packets and in the key management
                deamon for incoming IKE connection requests.

4.  Overview of Current Operation

Using the existing PF_KEY interface, kernel-mode IPsec implementations
can  request  a key management daemon in user space to create new SAs.
The kernel makes such requests using the ACQUIRE  message  in  PF_KEY,
and  includes  the  exact  list  of allowed algorithms and other IPsec
parameters. Inside the ACQUIRE message, this list is in a data element
called  the  "Proposal extension". In order to construct the list, the
kernel must have a data structure which contains  all  possible  IPsec
policy information.

When the peer in an IPsec connection establishes the  connection,  the
process  works in a different way. A request from the peer is received
by IKE. IKE makes a local decision about what algorithms  and  parame-
ters are suitable for the proposed traffic type, and once the negotia-
tion is complete, informs the kernel.

As IKE handles only symmetric SAs, the same policy information of  (a)
what  are  the  algorithms  and other parameters and (b) which traffic
needs IPsec and with what parameters needs to be stored in two places:
the  kernel  and the key management daemon. This is inconvenient, par-
ticularly if there are several key management daemons.  For  instance,
certain  Voice over IP architectures require the use of both IKE, Ker-
beros, and applications as key management daemons. This means that the
same  information  would  have  to  be  stored not in two, but several
places.

5.  Overview of Modified Operation

The current PF_KEY operation is extended in two ways. First, an alter-
native  for  the  Proposal  extension is provided. The purpose of this
alternative is to make it possible for the kernel  to  just  reference
IPsec  policies instead of actually being able to know their contents.
This is quite beneficial both because the  kernel  or  hardware  IPsec



J. Arkko                                                      [Page 2]





INTERNET-DRAFT            PF_KEY Extensions              July 14, 2000


implementation  can be made simpler and because PF_KEY no longer needs
to suffer about incompatibilities between IKE proposal and PF_KEY pro-
posals.  The  new  alternative extension is called Proposal Reference,
and it can appear anywhere where a Proposal extension can in an inter-
changeable way.

The second extension to PF_KEY operation is to allow the ACQUIRE  mes-
sage  also in the direction from the key management daemon to the ker-
nel.  Since the kernel must store traffic patterns for detecting  e.g.
an incoming packet that should have used IPsec but didn't, this infor-
mation can also be used in other purposes.  Namely,  upon  getting  an
incoming IKE connection request, the key management daemon must make a
decision as to which one of the proposed  SAs  is  suitable,  if  any.
When making this decision it can use the kernel traffic pattern policy
information, therefore making it  unnecessary  to  store  any  of  the
traffic pattern policy information in the key management deamon.  This
is useful, for instance, when there can be several key management dae-
mons.

The Proposal Reference extension  and  the  reverse-direction  ACQUIRE
messsage can also be used together.

6.  Messages



6.1.  ACQUIRE

The SADB_ACQUIRE message is modified to have the following behaviour:

The kernel sends an SADB_ACQUIRE message to registered sockets.

      <base, address(SD), (address(P)), (identity(SD),) (sensitivity,)
       proposal-or-propref>

The proposal-or-propref must be either the  standard  PF_KEY  Proposal
extension,  or  the Proposal Reference extension defined in this docu-
ment.

6.2.  QUERY

The new SADB_X_QUERY message is sent by the key management  deamon  in
order  let the kernel make the decision about a suitable SA. This mes-
sage resembles ACQUIRE, but is initiated by the key management  daemon
and,  from the point of view of the kernel, is not related to the pos-
sibly coming GETSPI, UPDATE, and ADD messages. This message  does  not
create state at the kernel end.

The message behavior of this message is:

Send an SADB_X_QUERY message from a user process to the kernel.

        <base, address(SD), (address(P), (identity(SD),) (sensitivity,)>




J. Arkko                                                      [Page 3]





INTERNET-DRAFT            PF_KEY Extensions              July 14, 2000


The  kernel  returns  the  SADB_X_QUERY  message  to   all   listening
processes.

        <base, address(SD), (address(P)), (identity(SD),) (sensitivity,)
               proposal-or-propref>

The proposal-or-propref must be either the  standard  PF_KEY  Proposal
extension,  or  the Proposal Reference extension defined in this docu-
ment.

7.  Extensions


7.1.  Proposal Reference Extension

Like the Proposal extension, the purpose of Proposal Reference  exten-
sion  is  to  tell  the  key management daemon the proposal for new SA
algorithms and other parameters. It looks like:

           struct sadb_pref {
                   uint16_t sadb_pref_len;
                   uint16_t sadb_pref_exttype;
                   uint32_t sadb_pref_what;
           };
           /* sizeof(struct sadb_pref) == 8 */

The meaning of the fields is as follows:

        sadb_pref_len           This is the length of the extension.

        sadb_pref_exttype       This should be SADB_X_EXT_PREFERENCE.

        sadb_pref_what          This is an opaque identifier that
                                tells the key management daemon what
                                IPsec policy should be applied. These
                                identifiers have been agreed by
                                the kernel and the key management
                                daemon using mechanisms outside PF_KEY.

Note that the referred policy may request the creation of a simple SA,
or  even  a  set  of  SAs  (called an SA bundle). For this reason, key
management deamon MUST ignore the  sadb_msg_satype  field  value  when
interpreting  messages  containing  this  extension.  The  kernel sets
sadb_msg_satype to SADB_TYPE_UNSPEC when initiating  an  ACQUIRE  mes-
sage.

8.  Further work

Further discussions are needed in the following areas:

(1) Backwards compatibility. How do the PF_KEY peers know they can use
the new extensions?

(2) How should the opaque references be represented  in  the  Proposal



J. Arkko                                                      [Page 4]





INTERNET-DRAFT            PF_KEY Extensions              July 14, 2000


Reference  extensions?  Is  an integer a suitable opaque reference, or
would a string be more practical? Perhaps then the kernel traffic pat-
tern  configuration could be done completely indepedently of the other
configuration; filter definitions could say for instance "if  you  see
10.x.x.x to 11.x.x.x, apply psec with policy VPN_1".

(3) If multiple key management daemons are assumed, how  are  proposal
references  used then? Do the daemons all contact a yet another deamon
that holds the mapping from the reference to an actual proposal?

(4) What is the role of future  IETF  security  policy  mechanisms  in
relation  to  PF_KEY,  and do they affect extensions described in this
document?

9.  Acknowledgements

Possible merit for these extensions should go to the many people  with
whom  I've  discussed  about  these  issues,  including members of the
PF_KEY list.

10.  References

[1]  D. McDonald, C. Metz, Phan, B. "PF_KEY Key Management  API,  Ver-
sion  2"  RFC  2367, Sun Microsystems, U.S. Naval Research Laboratory,
July 1998.

[2]  S. Kent, Atkinson, R. "Security  Architecture  for  the  Internet
Protocol" RFC 2401, BBN Corp, @Home Network, November 1998.

[3]  Harkins, D. and Carrel, D.,  "The  Internet  Key  Exchange",  RFC
2409, Cisco Systems, November 1998.

11.  Author's Address

Jari Arkko
Oy LM Ericsson Ab
02420 Jorvas
Finland

Phone: +358 40 5079256 (hand)
       +358 9 2992480 (desk)
EMail: Jari.Arkko@ericsson.com
       (July 1 - August 30, 2000: jari@arkko.com)














J. Arkko                                                      [Page 5]