idnits 2.17.1 draft-arkko-pfkey-reference-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == The page length should not exceed 58 lines per page, but there was 5 longer pages, the longest (page 2) being 66 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 5 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 69 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 199: '...anagement deamon MUST ignore the sadb...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 14 has weird spacing: '...), its areas...' == Line 15 has weird spacing: '...its working g...' == Line 19 has weird spacing: '...and may be u...' == Line 20 has weird spacing: '...iate to use ...' == Line 23 has weird spacing: '...The list o...' == (64 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 14, 2000) is 8686 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2401 (ref. '2') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2409 (ref. '3') (Obsoleted by RFC 4306) Summary: 13 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Jari Arkko 3 INTERNET-DRAFT Ericsson 4 Category: Informational 5 6 July 14, 2000 8 PF_KEY Extensions for Reducing Policy Information in Kernel 10 1. Status of this Memo 12 This document is an Internet-Draft and is in full conformance with all 13 provisions of Section 10 of RFC2026. Internet-Drafts are working docu- 14 ments of the Internet Engineering Task Force (IETF), its areas, and 15 its working groups. Note that other groups may also distribute work- 16 ing documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or made obsolete by other documents at 20 any time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as work in progress. 23 The list of current Internet-Drafts may be found at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories may be found at 27 http://www.ietf.org/shadow.html. 29 The distribution of this memo is unlimited. It is filed as , and expires January 1, 2001. Please 31 send comments to the author or to pf_key@inner.net. 33 2. Abstract 35 PF_KEY is a generic key management API that can be used with IPsec. 36 This document discusses the extension of the PF_KEY interface in order 37 to lessen the need to store complicated IPsec policy data in kernel- 38 mode implementations, and to make it possible for key management dae- 39 mons reuse traffic pattern information already present in the kernel. 41 3. Introduction 43 PF_KEY [1] is a generic key management API that can be used with, for 44 instance, IPsec [2]. PF_KEY is a socket protocol family used by 45 trusted privileged key management applications to communicate with an 46 operating system's kernel-mode implementation of IPsec. 48 Experience in implementing PF_KEY-based systems has uncovered areas 49 where PF_KEY lacks functionality which is needed for IPsec and IKE 50 [3]. These areas include certain missing algorithms, missing mechan- 51 isms to handle IPsec SA bundles, and unnecessary duplication of policy 52 information in several parts of a system. This document describes one 53 possible way to extend PF_KEY. It is targeted as a starting point for 54 discussions and does not claim to solve all known PF_KEY problems. 56 In this document we discuss the extension of the PF_KEY interface in 57 two respects: 59 (a) Enabling kernel mode IPsec implementations to 60 know less about IPsec policies, such as what 61 algorithms should be used. At the same time 62 features previously not supported by PF_KEY - such 63 as IPsec SA bundles - can be implemented over 64 PF_KEY in a transparent manner. 66 (b) Enabling key management daemon implementations to 67 delegate all traffic pattern matching to 68 the kernel. Presently, traffic pattern matching 69 must be performed both in the kernel for 70 outgoing packets and in the key management 71 deamon for incoming IKE connection requests. 73 4. Overview of Current Operation 75 Using the existing PF_KEY interface, kernel-mode IPsec implementations 76 can request a key management daemon in user space to create new SAs. 77 The kernel makes such requests using the ACQUIRE message in PF_KEY, 78 and includes the exact list of allowed algorithms and other IPsec 79 parameters. Inside the ACQUIRE message, this list is in a data element 80 called the "Proposal extension". In order to construct the list, the 81 kernel must have a data structure which contains all possible IPsec 82 policy information. 84 When the peer in an IPsec connection establishes the connection, the 85 process works in a different way. A request from the peer is received 86 by IKE. IKE makes a local decision about what algorithms and parame- 87 ters are suitable for the proposed traffic type, and once the negotia- 88 tion is complete, informs the kernel. 90 As IKE handles only symmetric SAs, the same policy information of (a) 91 what are the algorithms and other parameters and (b) which traffic 92 needs IPsec and with what parameters needs to be stored in two places: 93 the kernel and the key management daemon. This is inconvenient, par- 94 ticularly if there are several key management daemons. For instance, 95 certain Voice over IP architectures require the use of both IKE, Ker- 96 beros, and applications as key management daemons. This means that the 97 same information would have to be stored not in two, but several 98 places. 100 5. Overview of Modified Operation 102 The current PF_KEY operation is extended in two ways. First, an alter- 103 native for the Proposal extension is provided. The purpose of this 104 alternative is to make it possible for the kernel to just reference 105 IPsec policies instead of actually being able to know their contents. 106 This is quite beneficial both because the kernel or hardware IPsec 107 implementation can be made simpler and because PF_KEY no longer needs 108 to suffer about incompatibilities between IKE proposal and PF_KEY pro- 109 posals. The new alternative extension is called Proposal Reference, 110 and it can appear anywhere where a Proposal extension can in an inter- 111 changeable way. 113 The second extension to PF_KEY operation is to allow the ACQUIRE mes- 114 sage also in the direction from the key management daemon to the ker- 115 nel. Since the kernel must store traffic patterns for detecting e.g. 116 an incoming packet that should have used IPsec but didn't, this infor- 117 mation can also be used in other purposes. Namely, upon getting an 118 incoming IKE connection request, the key management daemon must make a 119 decision as to which one of the proposed SAs is suitable, if any. 120 When making this decision it can use the kernel traffic pattern policy 121 information, therefore making it unnecessary to store any of the 122 traffic pattern policy information in the key management deamon. This 123 is useful, for instance, when there can be several key management dae- 124 mons. 126 The Proposal Reference extension and the reverse-direction ACQUIRE 127 messsage can also be used together. 129 6. Messages 131 6.1. ACQUIRE 133 The SADB_ACQUIRE message is modified to have the following behaviour: 135 The kernel sends an SADB_ACQUIRE message to registered sockets. 137 140 The proposal-or-propref must be either the standard PF_KEY Proposal 141 extension, or the Proposal Reference extension defined in this docu- 142 ment. 144 6.2. QUERY 146 The new SADB_X_QUERY message is sent by the key management deamon in 147 order let the kernel make the decision about a suitable SA. This mes- 148 sage resembles ACQUIRE, but is initiated by the key management daemon 149 and, from the point of view of the kernel, is not related to the pos- 150 sibly coming GETSPI, UPDATE, and ADD messages. This message does not 151 create state at the kernel end. 153 The message behavior of this message is: 155 Send an SADB_X_QUERY message from a user process to the kernel. 157 159 The kernel returns the SADB_X_QUERY message to all listening 160 processes. 162 165 The proposal-or-propref must be either the standard PF_KEY Proposal 166 extension, or the Proposal Reference extension defined in this docu- 167 ment. 169 7. Extensions 171 7.1. Proposal Reference Extension 173 Like the Proposal extension, the purpose of Proposal Reference exten- 174 sion is to tell the key management daemon the proposal for new SA 175 algorithms and other parameters. It looks like: 177 struct sadb_pref { 178 uint16_t sadb_pref_len; 179 uint16_t sadb_pref_exttype; 180 uint32_t sadb_pref_what; 181 }; 182 /* sizeof(struct sadb_pref) == 8 */ 184 The meaning of the fields is as follows: 186 sadb_pref_len This is the length of the extension. 188 sadb_pref_exttype This should be SADB_X_EXT_PREFERENCE. 190 sadb_pref_what This is an opaque identifier that 191 tells the key management daemon what 192 IPsec policy should be applied. These 193 identifiers have been agreed by 194 the kernel and the key management 195 daemon using mechanisms outside PF_KEY. 197 Note that the referred policy may request the creation of a simple SA, 198 or even a set of SAs (called an SA bundle). For this reason, key 199 management deamon MUST ignore the sadb_msg_satype field value when 200 interpreting messages containing this extension. The kernel sets 201 sadb_msg_satype to SADB_TYPE_UNSPEC when initiating an ACQUIRE mes- 202 sage. 204 8. Further work 206 Further discussions are needed in the following areas: 208 (1) Backwards compatibility. How do the PF_KEY peers know they can use 209 the new extensions? 211 (2) How should the opaque references be represented in the Proposal 212 Reference extensions? Is an integer a suitable opaque reference, or 213 would a string be more practical? Perhaps then the kernel traffic pat- 214 tern configuration could be done completely indepedently of the other 215 configuration; filter definitions could say for instance "if you see 216 10.x.x.x to 11.x.x.x, apply psec with policy VPN_1". 218 (3) If multiple key management daemons are assumed, how are proposal 219 references used then? Do the daemons all contact a yet another deamon 220 that holds the mapping from the reference to an actual proposal? 222 (4) What is the role of future IETF security policy mechanisms in 223 relation to PF_KEY, and do they affect extensions described in this 224 document? 226 9. Acknowledgements 228 Possible merit for these extensions should go to the many people with 229 whom I've discussed about these issues, including members of the 230 PF_KEY list. 232 10. References 234 [1] D. McDonald, C. Metz, Phan, B. "PF_KEY Key Management API, Ver- 235 sion 2" RFC 2367, Sun Microsystems, U.S. Naval Research Laboratory, 236 July 1998. 238 [2] S. Kent, Atkinson, R. "Security Architecture for the Internet 239 Protocol" RFC 2401, BBN Corp, @Home Network, November 1998. 241 [3] Harkins, D. and Carrel, D., "The Internet Key Exchange", RFC 242 2409, Cisco Systems, November 1998. 244 11. Author's Address 246 Jari Arkko 247 Oy LM Ericsson Ab 248 02420 Jorvas 249 Finland 251 Phone: +358 40 5079256 (hand) 252 +358 9 2992480 (desk) 253 EMail: Jari.Arkko@ericsson.com 254 (July 1 - August 30, 2000: jari@arkko.com)