One document matched: draft-arkko-pfkey-reference-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-23 03:06:19 |