idnits 2.17.1 draft-ietf-ipsp-spp-01.txt: 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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 681 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 2032 has weird spacing: '...age and the e...' == Line 3719 has weird spacing: '...P field below...' == Line 4172 has weird spacing: '... src dst ...' == Line 4173 has weird spacing: '...inbound per...' == Line 4196 has weird spacing: '... src dst ...' == (28 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: AH This octet indicates if AH is to be used and in what mode. NOT REQUIRED means that AH is not necessary but if used it MUST be negotiated based on the parameters defined below. TUNNEL_MODE or TRANSP_MODE means that AH MUST be negotiatiated in this mode. ANY_MODE means that AH MUST be negotited and that any mode (Tunnel or transport) will suffice. NOT ALLOWED means that AH SHOULD NOT be negotiated and it MUST not be part of this SA. -- 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 (January 29, 2002) is 8120 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'KA98b' is defined on line 2513, but no explicit reference was found in the text == Unused Reference: 'RFC1035' is defined on line 2520, but no explicit reference was found in the text == Unused Reference: 'SPSL' is defined on line 2545, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2401 (ref. 'Kent98') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2406 (ref. 'KA98b') (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 1305 (Obsoleted by RFC 5905) == Outdated reference: A later version (-04) exists of draft-reichmeyer-polterm-terminology-00 -- Possible downref: Normative reference to a draft: ref. 'RGSC00' ** Obsolete normative reference: RFC 2459 (ref. 'PKIXP1') (Obsoleted by RFC 3280) ** Obsolete normative reference: RFC 2409 (ref. 'Harkins98') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2407 (ref. 'Piper98') (Obsoleted by RFC 4306) -- Possible downref: Normative reference to a draft: ref. 'SPS' == Outdated reference: A later version (-04) exists of draft-ietf-ipsp-spsl-00 -- Possible downref: Normative reference to a draft: ref. 'SPSL' Summary: 9 errors (**), 0 flaws (~~), 15 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft L.A. Sanchez, Megisto 2 draft-ietf-ipsp-spp-01.txt M.N. Condell, BBN 3 Expires July, 2002 January 29, 2002 5 Security Policy Protocol 7 Status of this Memo 9 This document is an Internet-Draft and is in full conformance 10 with all provisions of Section 10 of RFC2026. 12 Internet-Drafts are working documents of the Internet Engineering 13 Task Force (IETF), its areas, and its working groups. Note that 14 other groups may also distribute working documents as 15 Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other 19 documents at any time. It is inappropriate to use Internet- 20 Drafts as reference material or to cite them other than as 21 "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 This document describes a protocol for discovering, accessing and 32 processing security policy information of hosts, subnets or networks 33 of a security domain. The Security Policy Protocol defines how the 34 policy information is exchanged, processed, and protected by clients 35 and servers. The protocol is extensible and flexible. It allows the 36 exchange of complex policy objects between clients and servers. 38 Table of Contents 40 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 41 1.1 Definitions. . . . . . . . . . . . . . . . . . . . . . . . 4 42 1.2 Policies . . . . . . . . . . . . . . . . . . . . . . . . . 4 44 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 46 3. SPP Message. . . . . . . . . . . . . . . . . . . . . . . . . . 6 47 3.1 SPP Message Format . . . . . . . . . . . . . . . . . . . . 7 48 3.2 SPP Payloads . . . . . . . . . . . . . . . . . . . . . . . 11 49 3.2.1 Query Payload. . . . . . . . . . . . . . . . . . . . . 11 50 3.2.2 Record Payload . . . . . . . . . . . . . . . . . . . . 12 51 3.2.3 Signature Payload. . . . . . . . . . . . . . . . . . . 13 52 3.3 SPP Messages . . . . . . . . . . . . . . . . . . . . . . . 14 53 3.3.1 Query Messages . . . . . . . . . . . . . . . . . . . . 14 54 3.3.2 Reply Messages . . . . . . . . . . . . . . . . . . . . 14 55 3.3.3 Policy Messages. . . . . . . . . . . . . . . . . . . . 15 56 3.3.4 Policy Acknowledgment Messages . . . . . . . . . . . . 15 57 3.3.5 Transfer Messages. . . . . . . . . . . . . . . . . . . 15 58 3.3.6 KeepAlive Messages . . . . . . . . . . . . . . . . . . 16 60 4. Policy Queries . . . . . . . . . . . . . . . . . . . . . . . . 16 61 4.1 Security Gateway Query . . . . . . . . . . . . . . . . . . 16 62 4.2 COMSEC Query . . . . . . . . . . . . . . . . . . . . . . . 17 63 4.3 Certificate Query. . . . . . . . . . . . . . . . . . . . . 18 65 5. Policy Records . . . . . . . . . . . . . . . . . . . . . . . . 19 66 5.1 Security Gateway Record. . . . . . . . . . . . . . . . . . 19 67 5.2 COMSEC Record. . . . . . . . . . . . . . . . . . . . . . . 21 68 5.3 Security Association Record. . . . . . . . . . . . . . . . 22 69 5.4 Policy Server Record . . . . . . . . . . . . . . . . . . . 23 70 5.5 Certificate Record . . . . . . . . . . . . . . . . . . . . 25 72 6. Transfer Records . . . . . . . . . . . . . . . . . . . . . . . 25 74 7. Policy Attribute Encoding. . . . . . . . . . . . . . . . . . . 26 76 8. SPP Message Processing . . . . . . . . . . . . . . . . . . . . 28 77 8.1 General Message Processing . . . . . . . . . . . . . . . . 28 78 8.2 Query Message Processing . . . . . . . . . . . . . . . . . 29 79 8.3 Reply Message Processing . . . . . . . . . . . . . . . . . 32 80 8.4 Policy Message Processing. . . . . . . . . . . . . . . . . 35 81 8.5 Policy Acknowledgment Message Processing . . . . . . . . . 37 82 8.6 Transfer Message Processing. . . . . . . . . . . . . . . . 38 83 8.7 KeepAlive Message Processing . . . . . . . . . . . . . . . 40 85 9. Policy Resolution . . . . . . . . . . . . . . . . . . . . . . . 41 86 9.1 Expansion of step 4. . . . . . . . . . . . . . . . . . . . 42 88 10. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 46 89 10.1 Message Type. . . . . . . . . . . . . . . . . . . . . . . 46 90 10.2 Message Code. . . . . . . . . . . . . . . . . . . . . . . 46 91 10.3 Identity Type . . . . . . . . . . . . . . . . . . . . . . 46 92 10.4 Payload Class . . . . . . . . . . . . . . . . . . . . . . 47 93 10.5 Query Type. . . . . . . . . . . . . . . . . . . . . . . . 47 94 10.6 Record Type . . . . . . . . . . . . . . . . . . . . . . . 47 95 10.7 Signature Type. . . . . . . . . . . . . . . . . . . . . . 47 96 10.8 Certificate Type. . . . . . . . . . . . . . . . . . . . . 47 97 10.9 Certificate Identity Type . . . . . . . . . . . . . . . . 47 98 10.10 Attribute Data Type. . . . . . . . . . . . . . . . . . . 48 99 10.11 User Name Type . . . . . . . . . . . . . . . . . . . . . 48 100 10.12 System Name Type . . . . . . . . . . . . . . . . . . . . 48 101 10.13 IPsec Action Attribute . . . . . . . . . . . . . . . . . 48 102 10.14 IKE Action Attribute . . . . . . . . . . . . . . . . . . 48 104 11. Security Considerations. . . . . . . . . . . . . . . . . . . . 49 106 Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . . . 50 108 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 110 Appendix A. DATA_TYPE Definitions. . . . . . . . . . . . . . . . . 51 112 Appendix B. An SPP Example . . . . . . . . . . . . . . . . . . . . 78 114 Appendix C. Decorrelation. . . . . . . . . . . . . . . . . . . . . 83 116 Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 118 Author Information . . . . . . . . . . . . . . . . . . . . . . . . 92 120 1. Introduction 122 The IPsec protocols [Kent98] provide a mechanism for securing 123 communications at the IP layer and IKE [Harkins98] can be used to 124 provide keys for IPsec. Currently practice with these protocols 125 maintains an assumption that communicating hosts have some a-priori 126 knowledge of which communications with particular newtwork entities 127 must be secured. While this assumption is valid in some environments 128 (e.g. some VPN environments), it does not support more general IPsec 129 senarios in a scalable manner. 131 In order to allow IPsec to scale in general cases, it is necessary 132 to be able to identify which entities involved in a communication 133 will require IPsec to protect the communication and what their 134 policies are regarding it. 136 The Security Policy Protocol (SPP) defines how the policy information 137 is exchanged, processed, and protected by clients and servers. The 138 protocol also defines what policy information is exchanged and the 139 format used to encode the information. The protocol specifies six 140 different message types used to exchange policy information. An SPP 141 message contains a message header section followed by zero or more SPP 142 payloads, depending on the message type. 144 SPP is part of the Security Policy System architecture [SPS]. This 145 document uses terms and references functionality described in [SPS]. 147 The remainder of this section defines terms and concepts that will 148 be used throughout this document. Section 2 provides and overview 149 of the protocol. The remainder of the document describes the 150 encoding of the protocol and how SPP messages are processed. 152 1.1 Definitions 154 The following terms are used throughout this document, in addition to 155 the terms defined in [SPS] and defined for general policy terminology 156 [RGSC00]. 158 Authoritative 160 Host A is authoritative over host B if host A has the right to 161 represent policy for host B. Host A may assert its relationship 162 to host B using policy server records (section 5.4), but MUST be 163 able to cryptographically prove the assertion. 165 Transitively Authoritative 167 A host is transitively authoritative over another host, A, if it 168 is either authoritative over host A or authoritative over a host, 169 B, which is trasitively athoritative over host A. For example, 170 if host X is authoritative for host Y and host Y is authoritative 171 for host Z, then host X is transitively authoritative for host Z. 173 Chain of Trust 175 A chain of trust is a set of cryptographically-proven authoritative 176 assertions that prove that a policy server is transitively 177 authoritative over the source or destination of a communication. 178 The chain of trust is used to prove that a policy server has 179 a right to be involved in an SPP exchange. See section 10 for 180 more about the chain of trust. 182 Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and 183 "MAY" that appear in this document are to be interpreted as described 184 in [Bra97]. 186 1.2 Policies 188 Defining and storing policies are beyond the scope if this document. 189 However, this section describes SPP's policy requirements and a 190 brief high-level look at its representation. 192 Policy Representation 194 SPP provides both the comsec record (section 5.2) and the Security 195 Association (SA rec) record (section 5.3) to describe policies. The 196 comsec record defines the selectors that describe a communication 197 along with a permit or deny action. The SA rec defines the actions, 198 specifically the IPsec and IKE security associations, necessary for 199 the communication to proceed. A policy transferred by SPP, therefore, 200 MUST consist of one comsec record to describe the selectors of the 201 communication and zero or more SA recs which describe the security 202 associations that are required to complete the communication. 204 Decorrelation 206 Policies exchanged using SPP MUST be decorrelated as described in 207 Appendix C. Two policies are decorrelated if there exists at least 208 one selector in both policies for which their values do not intersect. 209 Decorrelation is necessary to permit policy servers to properly cache 210 policies. 212 2. Overview 214 This section provides an overview of the SPP operation. A more 215 detailed and complex example of SPP operation is available in appendix 216 B. This overview assumes the policy servers have been loaded with 217 policies for their security domains and the policy has been 218 appropriately decorrelated. 220 Security Security 221 Domain Foo Domain Foo 223 +----------+ +----------+ 224 | Policy | | Policy | 225 | Server A | | Server B | 226 +----------+ +----------+ 227 ^ ^ ^ ^ 228 +---------+ Q1 | | Q2 /\ /\ Q2 | | Q3 +----------+ 229 | Host | R1 | | R2 / \ Q2/R2 / \ R2 | | R3 | Host | 230 | A |<--- -----><------><--- ---->| B | 231 +---------+ \ / \ / +----------+ 232 \/ \/ 234 Figure 1: Overview of SPP operation 236 Host A, wanting to communicate with Host B, invokes its policy client. 237 Host A's client sends a Query (Q1) to its configured local policy 238 server, Policy Server A. Policy Server A looks in its cache for a 239 policy record that matches the query. If it doesn't find one, it sends 240 a Query (Q2) containing the same policy request information to Host B. 241 Q2 is sent to Host B since Policy Server A may not know about the 242 existence of SGB or Policy Server B. This message includes a signature 243 that validates the authenticity and integrity of the query's content. 245 (Q2) is intercepted by SGB. SGB forwards the message (Q2) to Policy 246 Server B. Policy server B verifies that it can accept queries from 247 Policy Server A and validates the signature in Q2. It searches its 248 database for the appropriate policy information after verifying that 249 it is authoritative over Policy Client B. 251 Policy Server B merges its local policy with the policy information in 252 (Q2) and it sends a Reply (R2) to Policy Server A. The reply includes 253 the original query information and all policy information needed to 254 allow Policy Client A to establish a secure communication with Host 255 B. Policy Server B also attaches additional information to the reply 256 asserting its authority over Host B. 258 When Policy Server A receives the reply (R2) from Policy Server A, it 259 validates the signature in R2 and cryptographically verifies that 260 Policy Server B is authoritative over Host B. It then merges is local 261 policy with the policy information in (R2) and sends a Reply (R1) to 262 Host A. Policy Server A caches the merged policy to use when 263 answering future queries. Host A may then use this information to 264 establish necessary security associations with Host B. 266 If, however, Policy Server B is not authoritative over Host B, it 267 would query Host B for its policy with respect to this particular 268 communication. Policy Server B would generate a third query (Q3). Host 269 B would respond with its policy in (R3). Policy Server B merges its 270 policy for this communication and the policy in (R3) before replying 271 to Policy Server A. Policy Server A processes the reply as it did 272 above. 274 SPP accommodates topology changes, hence policy changes, rather easily 275 without the scalability constraints imposed by static reconfiguration 276 of each client. The protocol is extensible and flexible It allows the 277 exchange of complex policy objects between clients and servers. 279 3. SPP Message 281 The SPP header is present in every message. It contains fields 282 identifying the message, the type of message, the status of the 283 message, the number of queries and/or record payloads, and the host 284 requesting policy information. The header also includes a timestamp 285 field that provides anti-replay protection. Following the header there 286 might be zero or more SPP payloads. Currently, there are three payload 287 types defined in SPP: Query, Record, and Signature payloads. See 288 section 3.2 for encoding details. 290 SPP has six distinct message types. Query messages contain a specific 291 request for policy information. Reply messages include policy records 292 that answer specific policy queries. Policy messages include policy 293 information and are utilized for up/downloading security policies to 294 and from a policy server. Policy Acknowledgment messages are utilized 295 to acknowledge corresponding Policy messages but do not themselves 296 contain policy information. Transfer messages, which include policy 297 information, are utilized by policy servers to exchange bulk policy 298 information between servers. Finally, policy servers use keep alive 299 messages to inform security gateways and/or other monitoring devices 300 of the status of the server. 302 SPP messages MUST be authenticated either using IPsec [Kent98] or 303 another security mechanism. SPP provides a basic security mechanism 304 that can be used to provide authentication and integrity to its 305 messages when other security mechanisms are not in use. The SPP 306 authentication is especially useful when traversing heterogenous 307 domains and the identity of the policy server authoritative for the 308 destination is unknown. These services are provided using digital 309 signatures. 311 SPP caries signatures in the signature payload. The signature is 312 calculated over the entire SPP message. When this service is used, the 313 entity (host, policy server, or security gateway) verifying the 314 signature must have access to the public key that corresponds to the 315 private key used to sign the SPP message. 317 Certificate fetching is out of the scope of SPP. However, SPP 318 provides a simple certificate fetching mechanism for entities that 319 elect to use it as an alternative to other mechanisms. SPP suports 320 several Public Key certificates formats. 322 SPP is modular and extensible (see section 10 for IANA 323 considerations). New policy queries and records can be defined and 324 incorporated easily. This document defines a minimum set of queries 325 and policy records required in a policy-based security management 326 system. 328 3.1 SPP Message Format 330 An SPP message follows the format depicted in figure 2. It is 331 comprised of a header and zero or more SPP payloads. This section 332 defines the encoding for the SPP header. Sections 3.2 and 3.3 cover 333 the encoding for the SPP payload and message types, respectively. 335 0 1 2 3 336 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----- 338 | VERSION | MTYPE | MCODE | RESERVED | | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 340 | MESSAGE ID | | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 342 | QCOUNT | RCOUNT | IDENTITY TYPE |R|D|C|I|T| RSVD| | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 344 | | SPP 345 + TIMESTAMP + Header 346 | | | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 348 | | | 349 ~ SENDER IDENTITY ~ | 350 | | | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----- 352 | | SPP 353 ~ SPP PAYLOADS... ~ Pay- 354 | | loads 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----- 357 Figure 2: Format of an SPP Message 359 The SPP header includes the following fields: 361 VERSION 362 A 1-octect field containing the version of the Security 363 Policy Protocol. This document describes version 1 of 364 the protocol. 366 MTYPE 367 A 1-octet field indicating the SPP message type. 368 The currently defined values are: 370 Message Type Value 372 Value Not Assigned 0 373 SPP-QUERY 1 374 SPP-REPLY 2 375 SPP-POL 3 376 SPP-POL_ACK 4 377 SPP-XFR 5 378 SPP-KEEP_ALIVE 6 380 values 7-250 are reserved to IANA. Values 251-255 are for 381 private use among mutually consenting parties. 383 MCODE 384 A 1-octet field providing information about this message. 385 All MTYPEs share a common MCODE space, although each message 386 type may not use all the defined message codes. See section 387 3.3 for the codes applicable to each message type. 389 Action Code 390 Type Field 392 Value Not Assigned 0 393 message accepted 1 394 denied, administratively prohibited 2 395 denied, timestamp failed 3 396 denied, failed signature 4 397 denied, insufficient resources 5 398 denied, malformed message 6 399 denied, unspecified 7 400 partially available 8 401 unavailable 9 402 communication prohibited 10 403 partially available, server unreachable 11 405 values 12-250 are reserved to IANA. Values 251-255 are for 406 private use among mutually consenting parties. 408 RESERVED 409 A one octet field reserved for future use. Set value to all 410 zeros (0). 412 MESSAGE ID 413 A 4 octet field used to match messages and their responses 414 (e.g. queries to replies and policy to policy acknowledgement 415 messages). This value starts at "zero" and MUST be incremented 416 by (1) with every new message. 418 QCOUNT 419 A 1 octet field indicating the number of Query payloads 420 included in the message. 422 RCOUNT 423 A 1 octet field indicating the number of Record payloads 424 included in the message. 426 IDENTITY TYPE 427 This 1 octet field indicates the type of indentity found in 428 the Sender Identity field. Valid values are: 430 Identity Type Value 432 Value Not Assigned 0 433 IPV4_ADDR 1 434 IPV6_ADDR 2 435 Host DNS Name 3 437 values 4-250 are reserved to IANA. Values 251-255 are for 438 private use among mutually consenting parties. 440 R 441 Raw policy flag. When this flag is set, policy servers 442 MUST NOT resolve the policies that they return. 444 D 445 Domain flag. Only resolve the policies as far as the last 446 policy server that is transitively authoritative over the 447 host requesting the policy resolution. 449 C 450 Dont cache flag. Don't cache the policies generated by the 451 query. 453 I 454 Ignore cache flag. Ignore any cached policies when processing 455 the query. 457 T 458 No chain-of-trust. A client indicates to its server that it 459 does not need chain-of-trust information. Policy Servers 460 MUST NOT set this flag. Only Policy Clients have the option 461 to set it. 463 RSVD 464 A 4 bit field reserved for future use. 465 Set value to all zeros (0). 467 TIMESTAMP 468 This 8-octet field contains a timestamp used to provide 469 limited protection against replay attacks. The timestamp 470 is formatted as specified by the Network Time Protocol 471 [RFC1305]. 473 SENDER IDENTITY 474 A variable length field containing the identity of the sender 475 (host, security gateway, or policy server) of the SPP 476 message. The IDENTITY_TYPE field indicates the format of the 477 content in this field: 479 Identity Type Sender Identity 481 IPV4_ADDR An IPv4 Address 482 IPV6_ADDR An IPv6 Address 483 Host DNS Name A DNS name encoded as described 484 in [rfc1035] 486 This field does not allow IP address ranges or wildcards. 487 If this field is not aligned at the 4 octet boundary, the 488 field MUST be padded on the right with (00)hex to align on 489 the next 32-bit boundary. 491 3.2 SPP Payloads 493 3.2.1 Query Payload 495 The Query payload contains fields to express a particular request for 496 policy information. Hosts, security gateways, or policy servers can 497 generate and transmit Query payloads in SPP messages to policy 498 servers. Figure 3 shows the format of the Query payload. 500 0 1 2 3 501 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | PCL | PID | RESERVED | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 | TYPE | LENGTH | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 | QUERY Data ... 508 +-+-+-+-+-+-+-+- 510 Figure 3: Format of Query Payload 512 The Query Payload fields are defined as follows: 514 PCL 515 A 1 octet field indicating the payload class. Query payloads 516 MUST contain (1) in the PCL field. 518 PID 519 A 1 octet field containing the ID number that identifies a 520 particular Query payload within an SPP message. Since one 521 SPP message can contain multiple Query payloads, each one 522 MUST be uniquely identified. This number MUST be unique 523 among the Query payloads within an SPP message. 525 RESERVED 527 A 2 octet field reserved for future use. Set value to all 528 zeros (0). 530 TYPE 531 A 2 octet field that specifies the type of query contained in 532 the QUERY Data fields. The currently defined queries are: 534 Query Payload Type Value 536 Value Not Assigned 0 537 Security Gateway Query 1 538 Communication Security Query 2 539 Certificate Query 3 541 values 4-65000 are reserved to IANA. Values 65001-65535 are for 542 private use among mutually consenting parties. 544 LENGTH 545 A 2 octet field indicating the length in octets of the query 546 data field. 548 QUERY Data 550 A variable length field containing a single policy query. See 551 section 7 for encoding format. 553 3.2.2 Record Payload 555 The Record payload contains fields that assert policy information. 556 Hosts, security gateways, or policy servers can generate and transmit 557 Record payloads in SPP messages. Figure 4 shows the format of the 558 Record payload. 560 0 1 2 3 561 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 | PCL | PID | RESERVED | 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 | TYPE | LENGTH | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 | RECORD Data ... 568 +-+-+-+-+-+-+-+- 570 Figure 4: Format of Record Payload 572 The Record Payload fields are defined as follows: 574 PCL 575 A 1 octet field indicating the payload class. Record payloads 576 MUST contain (2) in the PCL field. 578 PID 579 This field is used to match queries to Record payloads. If 580 the record is a reply to a query, then the value for this 581 field MUST match the correspondent Query payload PID. If it 582 is not a reply to a query, the value SHOULD be set to zero. 584 RESERVED 586 A 2 octet field reserved for future use. Set value to all 587 zeros (0). 589 TYPE 590 A 2 octet field that specifies the type of Record. The 591 currently defined records are: 593 Record Type Value 595 Value Not Assigned 0 596 Security Gateway Record 1 597 Communication Security Record 2 598 Security Association Record 3 599 Certificate Record 4 600 Policy Server Record 5 601 Transfer Record 6 603 values 7-65000 are reserved to IANA. Values 65001-65535 are for 604 private use among mutually consenting parties. 606 LENGTH 607 A 2 octet field indicating the length in octets of the RECORD 608 data field. 610 RECORD Data 612 A variable length field containing a single policy record. See 613 section 8 for encoding format. 615 3.2.3 Signature Payload 617 The Signature Payload contains data generated by the digital signature 618 function (selected by the originator), over the entire SPP message, 619 except for part of the Signature payload. This payload is used to 620 verify the integrity of the data in the SPP message. Figure 5 shows 621 the format of the Signature payload. 623 0 1 2 3 624 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 | PCL | TYPE | LENGTH | 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 | SIGNATURE Data ... 629 +-+-+-+-+-+-+-+- 631 Figure 5: Signature Payload Format 633 The Signature payload fields are defined as follows: 635 PCL 636 A 1 octet field indicating the payload class. Signature 637 payloads MUST contain (3) in the PCL field. 639 TYPE 640 A 1 octet field that specifies the signature algorithm 641 employed. The currently defined signature types are: 643 Algorithm Type Value 645 Value Not Assigned 0 646 RSA 1 647 DSA 2 649 values 3-250 are reserved to IANA. Values 251-255 are for 650 private use among mutually consenting parties. 652 LENGTH 653 A 2 octet field indicating the length in octets of the 654 SIGNATURE Data field. 656 SIGNATURE Data 658 A variable length field that contains the results from 659 applying the digital signature function to the entire 660 SPP message (including the PCL, TYPE, and LENGTH fields 661 of the Signature payload), except for the Signature Data 662 field of the Signature payload. 664 3.3 SPP Messages 666 3.3.1 Query Message 668 An SPP-QUERY message is comprised of an SPP header, one or more Query 669 payloads, zero or more Record payloads, and a Signature payload, if 670 one is required. Query messages MUST always contain a Query 671 payload. Record payloads may optionally be included to pass policy 672 information along with the query. If the Signature payload is employed 673 it MUST be the last payload in the message. The Query message MTYPE 674 value is (1). The MCODE field must be set to zero (0). 676 3.3.2 Reply Message 678 An SPP-REPLY message is comprised of an SPP header, one or more Query 679 payloads, zero or more Record payloads which answer the corresponding 680 Query payload, and a Signature payload, if one is required. Reply 681 messages MUST contain a Query payload. Reply messages MUST include a 682 Record payload unless the reply contains an MCODE of values 2-8. If 683 the Signature payload is employed it MUST be the last payload in the 684 message. The MTYPE value for a Reply message is (2). The following 685 MCODE values may be used for Reply messages: 687 Action Code 688 Type Field 690 Value Not Assigned 0 691 message accepted 1 692 denied, administratively prohibited 2 693 denied, timestamp failed 3 694 denied, failed signature 4 695 denied, insufficient resources 5 696 denied, malformed message 6 697 denied, unspecified 7 698 partially available 8 699 unavailable 9 700 communication prohibited 10 701 partially available, server unreachable 11 703 3.3.3 Policy Message 705 An SPP-POL message is comprised of an SPP header, one or more Record 706 payloads, and a Signature payload, if one is required. Policy messages 707 MUST NOT include Query payloads. If the Signature payload is employed 708 it MUST be the last payload in the message. The MTYPE value for a 709 Policy message is (3). The MCODE field must be set to zero (0). 711 3.3.4 Policy Acknowledgement Message 713 An SPP-POL_ACK message is comprised of an SPP header and a Signature 714 payload, if one is required. These messages MUST NOT contain Query or 715 Record payloads. The status of the associated Policy message is 716 expressed within the MCODE field. If the Signature payload is employed 717 it MUST be the only payload in the message. The MTYPE value for a 718 Policy Acknowledgement message is (4). The following MCODE values may 719 be used for Policy Acknowledgement messages: 721 Action Code 722 Type Field 724 Value Not Assigned 0 725 message accepted 1 726 denied, administratively prohibited 2 727 denied, timestamp failed 3 728 denied, failed signature 4 729 denied, insufficient resources 5 730 denied, malformed message 6 731 denied, unspecified 7 733 3.3.5 Transfer Message 735 An SPP-XFR message is comprised of an SPP header, one or more Record 736 payloads, and a Signature payload, if one is required. Transfer 737 messages MUST NOT include Query payloads. If the Signature payload is 738 employed it MUST be the last payload in the message. The MTYPE value 739 for a Transfer message is (5). The MCODE field must be set to zero 740 (0). 742 3.3.6 KeepAlive Message 744 An SPP-KEEP_ALIVE message is comprised of an SPP header and a 745 Signature payload, if one is required. These messages MUST NOT contain 746 Query or Record payloads. If the Signature payload is employed it MUST 747 be the only payload in the message. The MTYPE value for a KeepAlive 748 message is (6). The MCODE field must be set to zero (0). 750 4. Policy Queries 752 4.1 Security Gateway Query 754 This basic query provides a dynamic mechanism to determine which 755 relevant security gateways, both primary and backup, are in the path 756 to a particular destination address. Since the answer to a request for 757 information could depend on the identity of the requestor, the host 758 address of the source of the intended communicaton is included in the 759 query. Figure 6 shows the format of the Security Gateway Query. 761 0 1 2 3 762 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 | | 765 ~ SOURCE ADDRESS DATA ~ 766 | | 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 | | 769 ~ DESTINATION ADDRESS DATA ~ 770 | | 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 773 Figure 6: Security Gateway Query Format 775 The Security Gateway Query fields are defined as follows: 777 SOURCE ADDRESS DATA 779 This variable length field contains a single IP address 780 (unicast) either in IPv4 or IPv6 format. The encoding 781 format is specified in section 7. The acceptable DATA_TYPE 782 values are 3 and 9. 784 DESTINATION ADDRESS DATA 786 This variable length field contains a single IP address 787 (unicast) either in IPv4 or IPv6 format. The encoding 788 format is specified in section 7. The acceptable DATA_TYPE 789 values are 6 and 12. 791 4.2 COMSEC Query 793 The Communication Security Query (or COMSEC query) provides a dynamic 794 mechanism for a host or security gateway to inquire if a communication 795 having a particular set of characteristics is allowed. The 796 communication is described in terms of source and destination 797 addresses, protocols, source port, destination port, and other 798 parameters as defined in section 7. These parameters are known as 799 selectors in the IPsec context and are primarily the contents of the 800 IP, TCP, and UDP headers. Figure 7 shows the format of the COMSEC 801 Query. 803 0 1 2 3 804 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 806 | | 807 ~ SOURCE ADDRESS DATA ~ 808 | | 809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 810 | | 811 ~ DESTINATION ADDRESS DATA ~ 812 | | 813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 814 | SELECTOR DATA ... 815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 Figure 7: COMSEC Query Format 819 The COMSEC Query fields are defined as follows: 821 SOURCE ADDRESS DATA 823 This variable length field contains a single IP address 824 (unicast) either in IPv4 or IPv6 format. The encoding 825 format is specified in section 7. The acceptable DATA_TYPE 826 values are 3 and 9. 828 DESTINATION ADDRESS DATA 830 This variable length field contains a single IP address 831 (unicast) either in IPv4 or IPv6 format. The encoding 832 format is specified in section 7. The acceptable DATA_TYPE 833 values are 6 and 12. 835 SELECTOR DATA 837 This includes one or more fields following the encoding format 838 specified in section 7. The acceptable DATA_TYPE values are 839 15-29, inclusive. 841 4.3 CERT Query 843 Mechanisms to dispatch and fetch public-key certificates are not part 844 of SPP. However, in the absence of external request/dispatch 845 mechanisms, SPP provides for a certificate request query that allows a 846 host, security gateway, or server to solicit a certificate. Figure 8 847 shows the format of the CERT Query. 849 0 1 2 3 850 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 852 | CERT_TYPE | IDENTITY_TYPE | AUTHORITY_TYPE| RESERVED | 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 854 | | 855 ~ IDENTITY ~ 856 | | 857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 858 | | 859 ~ CERTIFICATE AUTHORITY ~ 860 | | 861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 863 Figure 8: Certificate Query Format 865 The Certificate query fields are defined as follows: 867 CERT_TYPE 869 A 1 octet field that contains an encoding of the type of 870 certificate requested. Acceptable values are listed below: 872 Certificate Type Value 874 Value Not Assigned 0 875 PKCS #7 wrapped X.509 certificate 1 876 PGP Certificate 2 877 DNS Signed Key 3 878 X.509 Certificate - Signature 4 879 X.509 Certificate - Key Exchange 5 880 Kerberos Tokens 6 881 SPKI Certificate 7 883 values 8-250 are reserved to IANA. Values 251-255 are for 884 private use among mutually consenting parties. 886 IDENTITY_TYPE 888 This 1 octet field indicates the type of indentity found in 889 the Identity field. Valid values are listed below: 891 Value Identity Type 893 0 Value Not Assigned 894 1 IPV4_ADDR 895 2 IPV6_ADDR 896 3 DNS Name 897 4 X.500 Distinguished Name 899 values 5-250 are reserved to IANA. Values 251-255 are for 900 private use among mutually consenting parties. 902 AUTHORITY_TYPE 904 This 1 octet field indicates the type of authority found in 905 the Certificate Authority field. Valid values are the same as 906 IDENTITY_TYPE. 908 IDENTITY 910 This variable length field contains the identity of the 911 principal by which the certificate should be located. The 912 value MUST be of the type stated in IDENTITY_TYPE. 914 CERTIFICATE AUTHORITY 916 A variable length field containing an encoding of an 917 acceptable certificate authority for the type of certificate 918 requested. The value MUST be of the type stated in 919 AUTHORITY_TYPE. 921 5. Policy Records 923 5.1 Security Gateway Record 925 This record contains information that indicates the IP addresses of 926 the interfaces for the the primary and secondary security gateways 927 protecting a host or group of hosts. The record contains the primary 928 and secondary gateways at one point in the communication path between 929 the source and destination addresses listed in the Security Gateway 930 query. If the IP datagram must traverse multiple gateways, a Security 931 Gateway Record must be included for each gateway. The list of 932 secondary security gateways is optional. Figure 9 shows the format of 933 the Security Gateway Record. 935 0 1 2 3 936 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 938 | CACHE-EXPIRY | 939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 940 | FLAGS | RESERVED | 941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 942 | | 943 ~ PRIMARY SG ADDRESS ~ 944 | | 945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 946 | SECONDARY SG ADDRESSES 947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 949 Figure 9: Security Gateway Record Format 951 The Security Gateway Record fields are defined as follows: 953 CACHE-EXPIRY 955 A 4 octet field indicating the maximum amount of time, 956 in seconds, this policy record MAY be cached. 958 FLAGS 960 A 2 octet field indicating different options to aid in 961 interpreting the security gateway data. If not in use, set 962 value to all zeros (00)hex. Currently, no flag values are 963 defined so this field MUST be set to (00)hex. 965 RESERVED 967 A 2 octet field reserved for future use. 968 Set value to all zeros (0). 970 PRIMARY SG ADDRESS 972 A variable length field containing the IP address of the primary 973 security gateway for protecting a particular host. This 974 variable length field contains a single unicast IP 975 address. The encoding format is specified in section 7. 976 The acceptable DATA_TYPE values are 1 and 2. 978 SECONDARY SG ADDRESSES 980 This variable length field contains the IP addresses of one or 981 more secondary security gateways protecting a particular host. 982 This field may contain a list of single unicast IP addresses. 983 The encoding format is specified in section 7. The acceptable 984 DATA_TYPE values are 1 and 2. 986 5.2 COMSEC Record 988 The COMSEC record indicates if a communication having a particular set 989 of characteristics is allowed or not. The communication is described 990 in terms of source and destination addresses, protocols, source ports, 991 destination ports, and other attributes defined in section 7. Figure 992 10 shows the format of the COMSEC Record. 994 0 1 2 3 995 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 996 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 997 | CACHE-EXPIRY | 998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 999 | FLAGS | RESERVED | 1000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1001 | | 1002 ~ SOURCE ADDRESS DATA ~ 1003 | | 1004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1005 | | 1006 ~ DESTINATION ADDRESS DATA ~ 1007 | | 1008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1009 | SELECTOR DATA ... 1010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1012 Figure 10: COMSEC Record Format 1014 The COMSEC Record fields are defined as follows: 1016 CACHE-EXPIRY 1018 A 4 octet field indicating the maximum amount of time, 1019 in seconds, this policy record MAY be cached. 1021 FLAGS 1023 A 2 octet field indicating different options to aid in 1024 interpreting the selector data. If not in use, set 1025 value to all zeros (0). Currently, no flag values are 1026 defined so this field MUST be set to zero (0). 1028 RESERVED 1030 A 2 octet field reserved for future use. 1031 Set value to all zeros (0). 1033 SOURCE ADDRESS DATA 1035 This variable length field contains a single IP 1036 address (unicast, anycast, broadcast (IPv4 only), or multicast 1037 group), range of addresses (low and high values, inclusive), 1038 address + mask, or a wildcard address. The encoding format is 1039 specified in section 7. The acceptable DATA_TYPE values are 1040 3-5 and 9-11, inclusive. 1042 DESTINATION ADDRESS DATA 1044 This variable length field contains a single IP 1045 address (unicast, anycast, broadcast (IPv4 only), or multicast 1046 group), range of addresses (low and high values, inclusive), 1047 address + mask, or a wildcard address. The encoding format is 1048 specified in section 7. The acceptable DATA_TYPE values are 1049 6-8 and 12-14, inclusive. 1051 SELECTOR DATA 1053 This includes one or more fields following the encoding format 1054 specified in section 7. The acceptable DATA_TYPE values are 1055 15-29, inclusive. 1057 5.3 Security Association Record 1059 Security Association Records contain selectors and security 1060 association attributes (appliers) that characterize a particular 1061 Security Association between the source and destination addresses 1062 listed in the record. This record contains data types as defined in 1063 the section 7. Figure 11 shows the format of the SA Record. 1065 0 1 2 3 1066 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1068 | CACHE-EXPIRY | 1069 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1070 | FLAGS | RESERVED | 1071 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1072 | | 1073 ~ SOURCE ADDRESS DATA ~ 1074 | | 1075 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1076 | | 1077 ~ DESTINATION ADDRESS DATA ~ 1078 | | 1079 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1080 | SELECTOR DATA AND APPLIERS... 1081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1083 Figure 11: SA Record Format 1085 The SA record fields are defined as follows: 1087 CACHE-EXPIRY 1089 A 4 octet field indicating the maximum amount of time, 1090 in seconds, this policy record MAY be cached. 1092 FLAGS 1094 A 2 octet field indicating different options to aid in 1095 interpreting the selector data. If not in use, set 1096 value to all zeros (0). Currently, no flag values are 1097 defined so this field MUST be set to zero(0). 1099 RESERVED 1101 A 2 octet field reserved for future use. 1102 Set value to all zeros (0). 1104 SOURCE ADDRESS DATA 1106 This variable length field contains a single IP 1107 address (unicast, anycast, broadcast (IPv4 only), or multicast 1108 group), range of addresses (low and high values, inclusive), 1109 address + mask, or a wildcard address. The encoding format is 1110 specified in section 7. The acceptable DATA_TYPE values are 1111 3-5 and 9-11, inclusive. 1113 DESTINATION ADDRESS DATA 1115 This variable length field contains a single IP 1116 address (unicast, anycast, broadcast (IPv4 only), or multicast 1117 group), range of addresses (low and high values, inclusive), 1118 address + mask, or a wildcard address. The encoding format is 1119 specified in section 7. The acceptable DATA_TYPE values are 1120 6-8 and 12-14, inclusive. 1122 SELECTOR DATA AND APPLIERS 1124 This includes one or more fields following the encoding format 1125 specified in section 7. The acceptable DATA_TYPE values are 1126 15-29 and 50-51, inclusive. 1128 5.4 Policy Server Record 1130 The Policy Server record indicates the host, security gateway, or 1131 policy server for which a particular policy server is 1132 authoritative. It represents an assertion, typically made by a policy 1133 server, with repect to a member of a security domain that the server 1134 represents. The record includes the Identity of the policy server and 1135 the identity of a node (host, security gateway, another server, etc.). 1136 Figure 12 shows the format of the Policy Server Record. 1138 0 1 2 3 1139 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1141 | CACHE-EXPIRY | 1142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1143 | FLAGS | RESERVED | 1144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1145 | | 1146 ~ POLICY SERVER IDENTITY ~ 1147 | | 1148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1149 | | 1150 ~ NODE IDENTITY ~ 1151 | | 1152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1154 Figure 12: Policy Server record format 1156 The Policy Server Record fields are defined as follows: 1158 CACHE-EXPIRY 1160 A 4 octet field indicating the maximum amount of time, 1161 in seconds, this policy record MAY be cached. 1163 FLAGS 1165 A 2 octet field indicating different options to aid in 1166 interpreting the server and node data. If not in use, set 1167 value to all zeros (0). Currently, no flag values are 1168 defined so this field MUST be set to zero (0). 1170 RESERVED 1172 A 2 octet field reserved for future use. 1173 Set value to all zeros (0). 1175 POLICY SERVER IDENTITY 1177 This variable length field contains the identity of the 1178 policy server. It may contain an IP address (unicast) 1179 either in IPv4 or IPv6 format. The encoding format is 1180 specified in section 7. The acceptable DATA_TYPE values 1181 are 1 and 2. 1183 NODE IDENTITY 1185 This variable length field contains the identity of a node 1186 for which the policy server is authoritative. It may contain 1187 an IP address (unicast) either in IPv4 or IPv6 format. The 1188 encoding format is specified in section 7. The acceptable 1189 DATA_TYPE values are 1 and 2. 1191 5.5 CERT Record 1193 The CERT record contains one public key certificate. This record is 1194 provided in SPP as an alternate mechanism for certificate 1195 dispatching. Figure 13 shows the format of the CERT Record. 1197 0 1 2 3 1198 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1200 | CACHE-EXPIRY | 1201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1202 | CERT_TYPE | | 1203 +-+-+-+-+-+-+-+-+ | 1204 ~ CERT_DATA ~ 1205 | | 1206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1208 Figure 13: Certificate Record Format 1210 CACHE-EXPIRY 1212 A 4 octet field indicating the maximum amount of time, 1213 in seconds, this policy record MAY be cached. 1215 CERT_TYPE 1217 This 1 octet field indicates the type of certificate or 1218 certificate-related information contained in the Certificate 1219 Data field. The values for this field are described in 1220 Section 4.3. 1222 CERT_DATA 1224 This variable length field contains the actual encoding of 1225 certificate data. The type of certificate is indicated by the 1226 Certificate Type field. 1228 6. Transfer Records 1230 This record contains the text of the master file that is used to 1231 configure the primary policy server. 1233 0 1 2 3 1234 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1236 | | 1237 ~ MASTER FILE TEXT ~ 1238 | | 1239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1241 Figure 14: Security Gateway Record Format 1243 The Transfer Record field is defined as follows: 1245 MASTER FILE TEXT 1247 This variable length field contains the text of the master 1248 file that is used to configure the policy server. 1250 7. Policy Attribute Encoding 1252 Query and Record payloads include several different selector types and 1253 SA attributes with their associated values. These data are encoded 1254 following a Type/Length/Value (TLV) format to provide flexibility for 1255 representing different kinds of data within a payload. Certain 1256 Data_Types with values of length equal to 2 octets follow the 1257 Type/Value (T/V) format. The first bit of the DATA_TYPE field is used 1258 to distinguished between the two formats. A value of (0) indicates a 1259 TLV format while a value of (1) indicates TV format. This generic 1260 encoding format is depicted in figure 15. 1262 X = 0: 1264 0 1 2 3 1265 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1267 |X| DATA_TYPE | LENGTH | 1268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1269 | DATA_VALUE... 1270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1272 X = 1: 1274 0 1 2 3 1275 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1277 |1| DATA_TYPE | DATA_VALUE | 1278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1280 Figure 15: Generic Data Attribute Formats 1282 The generic data attribute fields are defined as follows: 1284 X 1285 This bit indicates if the DATA_TYPE follows the TLV(0) or the 1286 TV(1) format. 1288 DATA_TYPE 1290 A 2 octet field indicating the selector type. The currently 1291 defined values are: 1293 DATA DATA_TYPE X 1295 IPV4_ADDR 1 0 1296 IPV6_ADDR 2 0 1297 SRC_IPV4_ADDR 3 0 1298 SRC_IPV4_ADDR_SUBNET 4 0 1299 SRC_IPV4_ADDR_RANGE 5 0 1300 DST_IPV4_ADDR 6 0 1301 DST_IPV4_ADDR_SUBNET 7 0 1302 DST_IPV4_ADDR_RANGE 8 0 1303 SRC_IPV6_ADDR 9 0 1304 SRC_IPV6_ADDR_SUBNET 10 0 1305 SRC_IPV6_ADDR_RANGE 11 0 1306 DST_IPV6_ADDR 12 0 1307 DST_IPV6_ADDR_SUBNET 13 0 1308 DST_IPV6_ADDR_RANGE 14 0 1309 DIRECTION 15 1 1310 USER_NAME 16 0 1311 SYSTEM_NAME 17 0 1312 XPORT_PROTOCOL 18 0 1313 SRC_PORT 19 0 1314 SRC_PORT_DYNAMIC 20 0 1315 DST_PORT 21 0 1316 DST_PORT_DYNAMIC 22 0 1317 SEC_LABELS 23 0 1318 V6CLASS 24 1 1319 V6FLOW 25 0 1320 V4TOS 26 1 1321 ACTION 27 1 1322 SRC_PORT_RANGE 28 0 1323 DST_PORT_RANGE 29 0 1325 IPSEC_ACTION 50 0 1326 ISAKMP_ACTION 51 0 1328 values 30-49 and 52-3200 are reserved to IANA. Values 1329 3200-32767 are for private use among mutually consenting 1330 parties. 1332 LENGTH 1334 A 2 octet field indicating the length of the selector value in 1335 octets, not including any trailing padding added to the 1336 DATA_VALUE field. The padding length is implicit. 1338 DATA_VALUE 1340 A variable length field containing the value of the selector 1341 specified by DATA_TYPE. If the Selector value is not aligned at 1342 the 4 octet boundary the field MUST be padded on the right with 1343 (00)hex to align on the next 32-bit boundary. 1345 8. SPP Message Processing 1347 SPP messages use UDP or TCP as their transport protocol. Messages 1348 carried by UDP are restricted to 512 bytes (not counting the IP or UDP 1349 headers). Fragmentation is allowed for messages containing more than 1350 512 bytes. The SPP-XFR message SHOULD use TCP to transfer the contents 1351 of the SPS Database from a primary to secondary policy server. A port 1352 number has not yet been assigned for use with SPP. For now SPP 1353 uses private UDP and TCP ports 55555. 1355 8.1 General Message processing 1357 For an SPP-Query or SPP-Pol message, the transmitting entity 1358 MUST do the following: 1360 1. Set a timer and initialize a retry counter. 1362 2. If an SPP-Reply or SPP-Pol_Ack message corresponding to the 1363 appropriate SPP-Query or SPP-Pol message is received within the 1364 time interval, or before the retry counter reaches 0, the 1365 transmitting entity continues normal operation. 1367 3. If an SPP-Reply or SPP-Pol_Ack message corresponding to the 1368 appropriate SPP-Query or SPP-Pol message is not received within 1369 the time interval and a secondary policy server, which has not 1370 been attempted on this value of the retry counter, is available, 1371 the message is sent to the secondary server. If all the 1372 secondary servers fail to respond within the time interval, 1373 decrement the retry counter and resend the message to the 1374 primary server. 1376 4. If the retry counter reaches zero (0) the event MAY be logged 1377 in the appropriate system audit file. 1379 5. Following step 4, processing is more specific: 1381 - For hosts and security gateways: 1383 o the transmitting entity will clear state for this peer and 1384 revert to using conventional security mechanisms. 1386 - For policy servers: 1388 o For SPP-Pol messages, clear state for this peer. 1390 o For SPP-Query messages, clear state for this peer, lookup 1391 policy in the server's SPS database and send an SPP-Reply 1392 message per section 8.3 with the policy and MCODE 11. 1394 8.2 Query Message (SPP-Query) Processing 1396 When creating a SPP-Query message, the entity (host, security gateway, 1397 or policy server) MUST do the following: 1399 1. Generate the Message ID value. This value starts at zero (0) and 1400 MUST be incremented by (1) with every new message. 1402 2. Set the value of the MTYPE field to 1 1404 3. Set the MCODE value to zero (0). 1406 4. Set the QCOUNT and RCOUNT fields. All fields MUST be 1407 set to zero (0) when their corresponding payloads do no exist. 1409 5. Set the flag bits accordingly and set the RESERVED field to 1410 zero (0). 1412 6. Set the IDENTITY_TYPE and IDENTITY of the Sender of the SPP 1413 message. 1415 7. Construct the SPP data payloads. A Query payload MUST be present 1416 in this message. 1418 8. Local policy information related to the query MAY be included as 1419 Record payloads following the Query payloads. 1421 9. A Policy Server record and a Cert Record SHOULD also be included 1422 in the message. A Cert record MUST be included if the query is 1423 a Cert Query to avoid a possible certificate query loop. 1425 10. Calculate and place the timestamp value used for anti-replay 1426 attack protection. 1428 11. If the Signature payload is required for message integrity and 1429 authentication, calculate a signature over the SPP header, SPP 1430 payloads, the PCL, TYPE, and LENGTH fields of the Signature 1431 payload. If required, the Signature payload MUST be the last 1432 payload in the message. 1434 When a policy server receives an SPP-Query message it MUST do the 1435 following: 1437 1. Check for SPP access control. If enabled, read the IP address in 1438 the Sender's field of the SPP header. 1440 - Verify whether or not the message is allowed. If the message 1441 is not allowed then: 1443 o send an SPP-Reply message with the MCODE 2 or 7 1444 o discard message and the event MAY be logged. 1446 - If the message is allowed, continue. 1448 2. Check timestamp field for anti-replay protection. If a replayed 1449 message is detected: 1451 - send an SPP-Reply message with the MCODE 3 or 7 1452 - discard message and the event MAY be logged. 1454 3. If the message requires signature validation. 1456 - If a certificate record is present, the server MUST process 1457 it, however, if the server already has a valid key for the 1458 host or server identified in the certificate, the certificate 1459 MAY be ignored. 1461 - Fetch certificate or key corresponding to the IP address 1462 found in the sender field of the SPP header. 1464 - If a certificate or key is not available the entity MAY, 1465 depending on configuration: 1467 o choose to abort validation process, send SPP-Reply message 1468 with MCODE 5 or 7, discard the message, and MAY log 1469 the event. 1471 o send an SPP-Query message to the source of the IP address 1472 found in the sender field of the SPP header with a CERT 1473 Query payload. Keep the SPP-Query message until the 1474 SPP-Reply returns. Extract certificate or key, validate it 1475 and proceed. 1477 - Once a validated certificate or key is available then validate 1478 signature. 1480 o If validation fails, send SPP-Reply message with MCODE 1481 5 or 7, discard the message, and the event MAY be logged. 1483 4. Parse the Query records. 1485 - If the SPP-Query message only contains cert queries: 1487 o If the Identity field identifies the server or a member of 1488 the server's security domain, send an SPP-Reply message per 1489 section 8.3 with one or more cert records with the 1490 certificates in the certification chain between the 1491 requested Identity and Certificate_Authority and MCODE 1. 1493 o Otherwise, send an SPP-Reply message per section 8.3 with 1494 with MCODE 9 or 7. 1496 - If the SPP-Query message does not only contain cert queries: 1498 o Check the Destination Address Data field to determine if 1499 the message received was intended for a node that is a 1500 member of the server's security domain. 1502 o Continue processing. 1504 5. If the message is for a node that is a member of the server's 1505 security domain or the D bit in the SPP header is set and the 1506 server is the outermost server that is authoritative over the 1507 client or server that sent the message, then: 1509 - Using src, dst, and any other applicable fields found in the 1510 Query Payload, search the SPS database for an appropriate 1511 policy. 1513 o If a policy is found then construct an SPP-Reply message per 1514 section 8.3 with appropriate payloads and MCODE 1. 1516 o If a policy is not found then construct an SPP-Reply message 1517 per section 8.3 with appropriate payloads and MCODE 9 or 7. 1519 6. If the message is for a node that is not part of the server's 1520 security domain then: 1522 - If the I and R bits are not set in the SPP header, check the 1523 Cache database for any relevant policies that apply to this 1524 communication. 1526 o If a policy is found then construct a SPP-Reply message per 1527 section 8.3 with appropriate payloads and MCODE 1. 1529 o If a policy is not found then continue. 1531 - Check the Local database for any relevant policies that apply 1532 to this communication. 1534 - If the server is authoritative for the source address of 1535 the query or a matching policy is found (A matching policy 1536 is defined as a policy that either produces a comsec record 1537 with an action attribute with the value "deny", or a policy 1538 that would produce an SA record with one or more IPsec action 1539 and IKE action attributes. A policy that only produces a 1540 comsec record with an action attribute with the value "permit" 1541 is not considered matching for this step.): 1543 o Generate a new SPP-Query message. The new message MUST use 1544 the same query payload as the old message. If the new 1545 query will include policy from the server, then the policy 1546 used SHOULD be the server's local policy merged with any 1547 policies received with the query message. The Sender Address 1548 will be the address of the server. The destination for this 1549 message MUST be the one in the original SPP-Query received. 1551 o Keep state. Upon reception of the corresponding SPP-Reply 1552 the policy server MUST send an SPP-Reply addressed to sender 1553 of the original SPP-Query. 1555 - If the server is not authoritative for the source address of 1556 the query and a matching policy is not found then: 1558 o The policy server MUST send the SPP-Query message unchanged. 1559 The SPP-Query message MUST use the same source port that was 1560 used to send it to the server so the next server that 1561 processes the query will return it to the correct port. 1562 This SPP-Query message MUST NOT be added to the retry queue 1563 (section 8.1). 1565 8.3 Reply Message (SPP-Reply) Processing 1567 When creating a SPP-Reply message, the policy server MUST do the 1568 following: 1570 1. Copy the Message ID value from the corresponding SPP-Query 1571 message into the Message ID field. 1573 2. Set the value of the MTYPE field to 2 1575 3. Set the MCODE value. 1577 4. Set the QCOUNT and RCOUNT fields. All fields MUST be 1578 set to zero (0) when their corresponding payloads do no exist. 1580 5. Set the flag bits accordingly and set the RESERVED field to (0). 1582 6. Set the IDENTITY_TYPE and IDENTITY of the Sender of the SPP 1583 message. 1585 7. Copy the Query payloads from the SPP-Query message to the 1586 SPP-Reply message. 1588 8. Construct the SPP data payload. Unless there is an error, at 1589 least one record corresponding to each Query payload MUST be 1590 present. 1592 9. A policy server record and a CERT record MUST be added to the 1593 SPP-Reply message if the the query to which this is a reply 1594 did NOT have the T bit set. If the T bit is set, the records 1595 SHOULD NOT be added. 1597 10. Calculate and place the timestamp value used for anti-replay 1598 attack protection. 1600 11. If the Signature payload is required for message integrity and 1601 authentication, calculate a signature over the SPP header, SPP 1602 payloads, the PCL, TYPE, and LENGTH fields of the Signature 1603 payload. If present, the Signature payload MUST be the last 1604 payload in the message. 1606 12. The SPP-Reply message is sent to the host that is listed in 1607 the Sender ID field of the SPP-Query to which this is a reply. 1609 When a host or security gateway receives an SPP-Reply message it MUST 1610 do the following: 1612 1. Read the Message ID field. If the value does not match the value 1613 of an outstanding SPP-Query message from a policy server then: 1614 - silently discard the message and the event MAY be logged. 1616 2. If Message ID matches, Check the timestamp field for anti-replay 1617 protection. If a replayed message is detected the message is 1618 silently discarded and the event MAY be logged. 1620 3. Establish if the message requires signature validation by 1621 searching for a Signature payload: 1622 - if signature validation is required proceed with step 4. 1623 - if signature validation is not required proceed with step 6. 1625 4. Validate the signature on the message. 1627 - If a certificate record is present, the server MUST process 1628 it, however, if the server already has a valid key for the 1629 host or server identified in the certificate, the certificate 1630 MAY be ignored. 1632 - Fetch certificate or key corresponding to the IP address 1633 found in the sender field of the SPP header. 1635 - If a certificate or key is not available the entity MAY: 1637 o choose, depending on configuration, to abort validation 1638 process, discard the message and MAY log the event. 1640 o send an SPP-Query message to the source of the IP address 1641 found in the sender field of the SPP header with a CERT 1642 query payload. Keep SPP-Reply message until the 1643 corresponding SPP-Reply returns. Extract certificate or 1644 key, validate it and proceed. 1646 5. Once a validated certificate or key is available then validate 1647 signature. 1649 If validation fails: 1650 - the message is silently discarded and the event MAY be logged 1652 If validation succeeds, continue processing. 1654 6. For Policy Servers, validate the chain of trust. 1656 A valid chain proves that policy has only been applied by 1657 servers authorized to control policy over either the source or 1658 destination host of the requested policy. The "chain" 1659 represents the hierarchy of policy servers authoritative over 1660 the source of the communication and the heirarchy over the 1661 destination. The chain may have a single "break" between the 1662 two policy servers that represent the top of the two 1663 heirarchies. It is formed by the information in the Policy 1664 Server records and must be cryptographically proven that the 1665 relationships described in those records are true. 1667 - For each Policy Server record, verify that the Policy Server 1668 is authoritative over the Node. This MUST be verified 1669 cryptographically which MAY be accomplished using X.509 1670 certificates [PKIXP1]. See section 11 for more details. 1672 - Use the Policy Server records to Create a chain of hosts from 1673 the destination host to this policy server where two records 1674 are linked if the Node in one is the Policy Server in another. 1676 - If the chain has no breaks, then this policy server MUST be 1677 authoritative over the sender of the reply, otherwise drop 1678 the message and stop processing it. 1680 - If the chain has one break, then the last policy server on 1681 the chain MUST be the sender of the reply, otherwise drop 1682 the message and stop processing it. 1684 - If the chain has two or more breaks, then there is an error 1685 in the chain so drop the message and stop processing it. 1687 - Verify that the Policy Server that is authoritative over the 1688 destination host is authoritative over ALL destination hosts 1689 in any comsec records. 1691 7. If MCODE value is 2-7, 9 or 10: 1693 For hosts or security gateways: 1694 - clear all the state and stop processing 1695 For policy servers: 1696 - create an SPP-Reply message using the same MCODE value. 1698 8. If the reply received correponds to a Cert query and the MCODE 1699 is either (1) or (8) (accept or partially unavailable), 1700 process message that was held up waiting for the cert. 1702 9. For Policy Servers: 1704 - Search the Local Policy Database for a policy entry that 1705 matches the policy expressed in Query payload. 1707 - If the R bit is not set, merge the local and non-local policy 1708 information using the policy resolution proccess outlined in 1709 section 9. 1711 - If the R bit is set, include both the policies found in the 1712 Local Policy Database and the policies in the reply to send 1713 in the new reply. 1715 - If the merge fails send an SPP-Reply message with MCODE 10 1716 or 7 and cache the failure. 1718 - If the merge succeeds or the R bit is set: 1720 o If the R and C bits are not set, cache policy information. 1721 This includes all Record payloads. 1722 o send an SPP-Reply message with the resulting policy records 1723 and MCODE 1. 1724 o If the R and D bits are not set and the merge indicated 1725 that policies should be sent to one or more security 1726 gateways, construct a signal for each gateway by creating 1727 an SPP-Pol message with the appropriate policy from the 1728 merge. 1730 10. For hosts or security gateways: 1732 - verify that the information in the Record payload corresponds 1733 to the information in the Query payload. 1734 - extract the records and create a policy entry in the SPD 1735 according to local format. The policy is entered in the SPD 1736 ONLY if local configuration allows. 1738 8.4 Policy Message (SPP-Pol) Processing 1740 When creating a SPP-Pol message, the entity (host, security gateway, or 1741 policy server) MUST do the following: 1743 1. Generate the Message ID value. This value starts at zero (0) and 1744 MUST be incremented by (1) with every new message. 1746 2. Set the value of the MTYPE field to 3. 1748 3. Set the MCODE value to zero (0). 1750 4. Set the RCOUNT field. The QCOUNT field MUST be set to zero (0) 1751 since no query payloads exist. 1753 5. Set the flag bits accordingly and set the RESERVED field to (0). 1755 6. Set the IDENTITY_TYPE and IDENTITY of the Sender of the SPP 1756 message. 1758 7. Construct the SPP data payloads. A Record payload MUST be 1759 present in this message. Query payloads MUST NOT be present. 1761 8. Calculate and place the timestamp value used for anti-replay 1762 attack protection. 1764 9. If the Signature payload is required for message integrity and 1765 authentication, calculate a signature over the SPP header, SPP 1766 payloads, the PCL, TYPE, and LENGTH fields of the Signature 1767 payload. If required, the Signature payload MUST be the 1768 last payload in the message. 1770 When a policy server receives an SPP-Pol message it MUST do the 1771 following: 1773 1. Check for SPP access control. If enabled, read the IP address in 1774 the Sender's field of the SPP header. 1776 - Verify whether or not the message is allowed. If the message 1777 is not allowed then: 1779 o send an SPP-Pol_Ack message with the MCODE 2 or 7 1780 o discard message and the event MAY be logged. 1782 - If the message is allowed, continue. 1784 2. Check timestamp field for anti-replay protection. If a replayed 1785 message is detected: 1787 - send an SPP-Pol_Ack message with the MCODE 3 or 7 1788 - discard message and the event MAY be logged. 1790 3. If the message requires signature validation: 1792 - If a certificate record is present, the server MUST process 1793 it, however, if the server already has a valid key for the 1794 host or server identified in the certificate, the certificate 1795 MAY be ignored. 1797 - Fetch certificate or key corresponding to the IP address 1798 found in the sender field of the SPP header. 1800 - If a certificate or key is not available the entity MAY, 1801 depending on configuration: 1803 o choose to abort validation process, send SPP-Pol_Ack 1804 message with MCODE 5 or 7, discard the message and MAY log 1805 the event. 1807 o send an SPP-Query message to the source of the IP address 1808 found in the sender field of the SPP header with a CERT 1809 Query payload. Keep SPP-Pol message until the SPP-Reply 1810 returns. Extract certificate or key, validate it and 1811 proceed. 1813 - Once a validated certificate or key is available then 1814 validate signature. 1816 o If validation fails the message is silently discarded and 1817 the event MAY be logged 1819 4. If signature was not required or upon successful validation of a 1820 signature parse the payloads. 1822 5. For hosts and security gateways: 1824 - extract the records and create a policy entry in the cache 1825 database. The policy MAY also be entered in the SPD, ONLY 1826 if configuration allows. 1828 6. For Policy Servers: 1830 - extract the records, find corresponding policies in the 1831 server's SPS database, merge the two sets of policies, and 1832 create a policy entry in the cache database. 1834 7. Send an SPP-Pol_Ack message with MCODE 1. 1836 8.5 Policy Acknowledgement Message (SPP-Pol_Ack) Processing 1838 When creating a SPP-Pol_Ack message, the policy server MUST do the 1839 following: 1841 1. Copy the Message ID value from the corresponding SPP-Pol message 1842 into the Message ID field. 1844 2. Set the value of the MTYPE field to 4 1846 3. Set the MCODE value. 1848 4. Set the QCOUNT and RCOUNT fields. All fields MUST be 1849 set to zero (0). 1851 5. Set the flag bits accordingly and set the RESERVED field to (0). 1853 6. Set the IDENTITY_TYPE and IDENTITY of the Sender of the SPP 1854 message. 1856 7. Query or Record payloads MUST NOT be present. 1858 8. Calculate and place the timestamp value used for anti-replay 1859 attack protection. 1861 9. If the Signature payload is required for message integrity and 1862 authentication, calculate a signature over the SPP header, the 1863 PCL, TYPE, and LENGTH fields of the Signature payload. 1865 When a host, security gateway, or policy server receives an 1866 SPP-Pol_Ack message the entity MUST do the following: 1868 1. Read the Message ID field. If the value does not match the value 1869 of an outstanding SPP-Pol message from a policy server then: 1870 - silently discard the message and the event MAY be logged. 1872 2. If Message ID matches then check the timestamp field for 1873 anti-replay protection. If a replayed message is detected the 1874 message is silently discarded and the event MAY be logged. 1876 3. If the message is original (not replayed) and the message 1877 requires signature validation then: 1879 - If a certificate record is present, the server MUST process 1880 it, however, if the server already has a valid key for the 1881 host or server identified in the certificate, the certificate 1882 MAY be ignored. 1884 - Fetch certificate or key corresponding to the IP address 1885 found in the sender field of the SPP header. 1887 - If a certificate or key is not available the entity MAY: 1889 o choose, depending on configuration, to abort validation 1890 process, discard the message and MAY log the event. 1892 o send an SPP-Query message to the source of the IP address 1893 found in the sender field of the SPP header with a CERT 1894 Query payload. Keep SPP-Pol_ack message until the SPP-Reply 1895 returns. Extract certificate or key, validate it and 1896 proceed. 1898 4. Once a validated certificate or key is available then validate 1899 the signature. 1900 If validation fails: 1901 - the message is silently discarded and the event MAY be logged 1902 If validation succeeds: 1903 - read the MCODE field and proceed accordingly. If no errors, 1904 clear all the state for this message and proceed. 1906 8.6 Transfer Message (SPP-XFER) Processing 1908 When creating an SPP-Xfer message, the policy server MUST do the 1909 following: 1911 1. Generate the Message ID value. This value starts at zero (0) and 1912 MUST be incremented by (1) with every new message. 1914 2. Set the value of the MTYPE field to 5. 1916 3. Set the MCODE value to (0). 1918 4. Set the RCOUNT field. The QCOUNT field MUST be set to zero (0) 1919 since no query payloads exist. 1921 5. Set the flag bits accordingly and set the RESERVED field to 1922 zero (0). 1924 6. Set the IDENTITY_TYPE and IDENTITY of the Sender of the SPP 1925 message. 1927 7. Construct the SPP data payloads. A single Transfer Record MUST 1928 be present in this payload and MUST contain the master file 1929 used to configure this policy server. 1931 8. Calculate and place the timestamp value used for anti-replay 1932 attack protection. 1934 9. If the Signature payload is required for message integrity and 1935 authentication, calculate a signature over the SPP header, SPP 1936 payloads, the PCL, TYPE, and LENGTH fields of the Signature 1937 payload. If required, the Signature payload MUST be the last 1938 payload in the message. 1940 When a security gateway receives an SPP-Xfer message it MUST do the 1941 following: 1943 1. Check for SPP access control. If enabled, read the IP address in 1944 the Sender's field of the SPP header. 1946 - Verify whether or not the message is allowed. If the message 1947 is not allowed then: 1949 o discard message and the event MAY be logged. 1951 - If the message is allowed, continue. 1953 2. Check timestamp field for anti-replay protection. If a replayed 1954 message is detected: 1956 - discard message and the event MAY be logged. 1958 3. If the message requires signature validation: 1960 - If a certificate record is present, the server MUST process 1961 it, however, if the server already has a valid key for the 1962 host or server identified in the certificate, the certificate 1963 MAY be ignored. 1965 - Fetch certificate or key corresponding to the IP address 1966 found in the sender field of the SPP header. 1968 - If a certificate or key is not available the entity MAY, 1969 depending on configuration: 1971 o choose to discard the message, and MAY log the event. 1973 o send an SPP-Query message to the source of the IP address 1974 found in the sender field of the SPP header with a CERT 1975 Query payload. Keep the SPP-Query message until the 1976 SPP-Reply returns. Extract certificate or key, validate it 1977 and proceed. 1979 - Once a validated certificate or key is available then 1980 validate signature. 1982 o discard the message, and the event MAY be logged. 1984 4. If signature was not required or upon successful validation of a 1985 signature parse the payload. 1987 - extract the Transfer Record and save the master file that it 1988 contains. 1990 - Flush the contents of the SPS database, domain database, and 1991 cache. 1993 - Load the new information from the transferred master file into 1994 the databases. 1996 8.7 KeepAlive Message (SPP-KEEP_ALIVE) Processing 1998 When creating an SPP-Keep_Alive message, the policy server MUST do the 1999 following: 2001 1. Generate the Message ID value. This value starts at zero (0) and 2002 MUST be incremented by (1) with every new message. 2004 2. Set the value of the MTYPE field to 6. 2006 3. Set the MCODE value to zero (0). 2008 4. Set the QCOUNT and RCOUNT fields. All fields MUST be 2009 set to zero (0). 2011 5. Set the flag bits accordingly and set the RESERVED field to (0). 2013 6. Set the IDENTITY_TYPE and IDENTITY of the Sender of the SPP 2014 message. 2016 7. Query or Record payloads MUST NOT be present. 2018 8. Calculate and place the timestamp value used for anti-replay 2019 attack protection. 2021 9. If the Signature payload is required for message integrity and 2022 authentication, calculate a signature over the SPP header, the 2023 PCL, TYPE, and LENGTH fields of the Signature payload. 2025 When a host or security gateway receives an SPP-Keep_Alive message it 2026 MUST do the following: 2028 1. Check for SPP access control. If enabled, read the IP address in 2029 the Sender's field of the SPP header. 2031 - Verify whether or not the message is allowed. If the message 2032 is not allowed then discard message and the event MAY be 2033 logged. 2035 2. Check timestamp field for anti-replay protection. If a replayed 2036 message is detected discard message and the event MAY be logged. 2038 3. If the message requires signature validation then: 2040 - If a certificate record is present, the server MUST process 2041 it, however, if the server already has a valid key for the 2042 host or server identified in the certificate, the certificate 2043 MAY be ignored. 2045 - Fetch certificate or key corresponding to the IP address 2046 found in the sender field of the SPP header. 2048 - If a certificate or key is not available the entity MAY 2049 depending on configuration: 2051 o choose to abort validation process, discard the message and 2052 the event MAY be logged. 2054 o send an SPP-Query message to the source of the IP address 2055 found in the sender field of the SPP header with a CERT 2056 Query payload. Keep SPP-Keep_Alive message until the 2057 SPP-Reply returns. Extract certificate or key, validate it 2058 and proceed. 2060 - Once a validated certificate or key is available then 2061 validate signature. 2063 o If validation fails the message is silently discarded and 2064 the event MAY be logged 2066 4. If signature validation was not required or upon successful 2067 validation of a signature, the event MAY be logged. 2069 9. Policy Resolution 2071 When a policy server receives a reply, it must merge its local 2072 policy for the communication with any non-local policies contained in 2073 the reply. The merging process creates a new policy that is the 2074 intersection of the local and remote policies. It then uses the 2075 merged policy as its reply to the query and caches it. The policy 2076 resolution process is as follows. 2078 A message (set of policies) consists of one comsec record and zero or 2079 more SA recs that apply to the communication in the comsec record. 2081 1. Get local and remote policies for the requested communication. 2083 2. Verify that the remote policy answer the query. This may be 2084 accomplished by intersecting the query with the comsec record 2085 int the answer and verify that they have a non-nil intersection. 2087 3. Merge the local and remote comsec records. If they don't merge 2088 return error. If they do put merged comsec record in answer. 2090 4. Merge the two sets of policies (SA recs). The merge must: 2092 - Find the intersection of the policies between matching endpoints. 2094 o If the intersection is nil, then the policies do not permit 2095 the communication and an error should be returned. It is not 2096 necessary to continue processing other endpoints. 2098 o If the intersection is not nil, then the intersection should 2099 be added to the reply policy. 2101 - Take into account ipsec action locations when determining the 2102 endpoints to intersect. 2104 - preserve the ordering of the policies so that the SA recs are 2105 generated in the correct order. 2107 5. The policy created by the intersections is the policy that should 2108 be cached and used as a reply to the query. 2110 Step 4 requires that the policy server must be able to determine all 2111 the sets of endpoints described by the policy. The endpoint 2112 information comes from two places: the source and destination 2113 addresses in the query (which is possibly more specific than those 2114 fields in the policies) and the location information in the 2115 ipsec_action attribute. Section 9.1 describes a method of processing 2116 this step in more detail. 2118 The location information may offer the policy server some 2119 flexibility in how it interprets endpoints for the communication. For 2120 example, if the policy indicates a tunnel must be established with any 2121 host or gateway in the source or destination host's domain, the policy 2122 server can choose the endpoint within the bounds of the policy. This 2123 choice can be made randomly, using a set policy (e.g., always choose 2124 the outermost gateway permitted by the policy), or using additional 2125 information the server may maintain for this purpose. For example, 2126 the server may keep track of previous policy decisions it made and use 2127 those as hints to which security associations may already exist. It 2128 can then try to make decisions that will allow these security 2129 associations to be reused. 2131 9.1 Expansion of step 4 2133 This section describes a method of merging two sets of policies. It 2134 describes which policies should be merged together and how to maintain 2135 the appropriate order of the policies. It does not describe the 2136 merging of individual policies which involves taking the intersecting 2137 the selectors and appliers. Other methods to implement the merge may 2138 be used. 2140 Start with two sets of ordered policies. One set is the remote set 2141 of policies that has been received through an SPP exchange. The other 2142 is a local set of policies that was found in a local policy database. 2144 1) Attempt to merge any records that may be merged and interleave 2145 messages to preserve ordering: 2147 for each SA rec in remote message: 2149 Check remote src, dst, location src, and location dst 2150 endpoints against SA recs in local message, in order. Check 2151 against the following rules which are grouped into three 2152 priorities. The high priority is for those policies that 2153 match and should be merged. The low priority is for those 2154 policies that don't merge, but care must be taken to insure 2155 that they are ordered correctly. The final group is policies 2156 that do not match in any way. 2158 Attempt to match each of the unprocessed local SA recs to the 2159 remote SA rec. Find the SA rec (or SA recs, there might be more 2160 than one applicable match) to find the highest priority match. 2162 If the highest priority match is a low priority match, compare 2163 it to the remaining remote SA recs. If there is a remote SA 2164 rec to which it has a high priority match, take the local SA 2165 rec and goto step 3. 2167 Otherwise, process the romote SA rec against each of the highest 2168 matching local SA recs as specified by their priority. 2170 High Priority Matches: 2172 o if both the remote src and dst match the local src and dst 2173 and either 2175 the remote location src and dst and the local location 2176 src and dst match 2178 or 2180 the local or remote location src and dst are set to 2181 zero and the other location src and dst match the src 2182 and dst 2184 - take each unprocessed SA rec in the local message 2185 before this matching one and goto 3. 2187 - merge the two SA recs and goto 3. 2189 o if (remote src and dst match the local location src and dst 2190 and the remote location src and dst either match the remote 2191 src and dst or are zero) or (local src and dst match the 2192 remote location src and dst and the local location src and 2193 dst either match the local src and dst or are zero), then: 2195 - take each unprocessed SA rec in the local message 2196 before this one and goto 3. 2198 - Take the SA rec with the location endpoints that matched 2199 the other src and dst and send it to step 3, but return 2200 the results here for further processing. 2202 - merge the other SA rec with the SA rec resulting from 2203 3 that has the same src and dst. Take this merged SA 2204 rec and goto 3. If the sa rec that was sent to step 2205 3 above was the local sa rec, send the remaining SA 2206 recs that resulted from 3 to step 3, otherwise send 2207 them to step 2. 2209 Low Priority Matches: 2211 o If both the remote src and dst match the local src and dst 2212 but the remote location src and dst and the local location 2213 src and dst do not match, then they do not merge. 2215 - take each unprocessed SA rec in the local message 2216 before this one and goto 3. 2218 - On a query, order the local SA rec before the remote SA 2219 rec. On a reply, order the remote SA rec before the local 2220 SA rec. Maintaining query/reply order, take the local 2221 SA rec to step 3 and the remote SA rec to step 2. 2223 o if the remote src and local src match, but the dsts do not, 2224 or the remote dst and local dst match and the srcs do not, 2225 then: 2227 - take each unprocessed SA rec in the local message 2228 before this one and goto 3. 2230 - On a query, order the local SA rec before the remote SA 2231 rec. On a reply, order the remote SA rec before the local 2232 SA rec. Maintaining query/reply order, take the local 2233 SA rec to step 3 and the remote SA rec to step 2. 2235 No Matches: 2237 o if no endpoints match, then goto 2. 2239 If there are any SA recs remaining in the local message, take each 2240 of them to step 3. 2242 2) Verify local policies for non end-to-end SA recs. This involves 2243 finding policies that are being merged which involve intermediate 2244 enforcement points and check the local policy for the intermediate 2245 points. 2247 The SA rec is directly from the remote message so the 2248 communication must be verified: 2250 A) Check the src and dst and the location src and dst. 2251 If a pair is the same as the communication endpoints, 2252 zero, or is ambiguous, do not continue processing it. 2253 Continue processing any that do not fit these conditions. 2254 If neither pair continues processing, goto 3. 2256 o look in the local database for a policy that matches 2257 the communication described by these endpoints. 2259 o check the comsec record to verify that it is 2260 permitted. (If not deny entire communication). 2262 o For each SA rec from the local policy, except a matching 2263 SA rec, goto 3. 2265 o If there is a matching SA rec, merge it with the remote 2266 SA rec and goto 3. Else take the remote SA rec and 2267 goto 3. 2269 3) Process location fields to resolve any ambiguities that they may 2270 describe and define any new SAs that the location fields may 2271 specify. 2273 If the loc fields are empty, then goto 4. 2275 - If the location fields and local decision making over any 2276 ambiguities indicate that a host or GW controlled by this PS 2277 should be a LOC DST, then replace the LOC DST with the gateway's 2278 ipaddress or DNS name. 2280 - If the location fields and local decision making over any 2281 ambiguities indicate that a host or GW controlled by this PS 2282 should be a LOC SRC, then replace the LOC SRC with the gateway's 2283 ipaddress or DNS name. 2285 - If both the location src and location dst fields are specific 2286 hosts or gateways (i.e. not ambiguous) and not the same as the 2287 src and dst fields, create a new SA rec to reflect the policy 2288 between the location src and dst. 2290 o create the new SA rec. 2292 - Take the original SA rec and any that have been added by this 2293 process and goto 4. 2295 4) Create a reply message and signals to enforcement points as needed. 2297 If this is a query: 2298 Add the SA rec to the answer. 2300 If this is a reply: 2302 If SA rec dst is for GW controlled by this PS: 2303 - If no signal message exists for this GW, yet, create one 2304 with a comsec record formed from the information in the 2305 previous SA rec (in the order that has been established). 2306 - Add the SA rec to the signal for this GW. 2307 - Add SA rec to answer. 2309 If SA rec src is for GW controlled by this PS: 2310 - If no signal message exists for this GW, yet, create one 2311 with a comsec record formed from the information in the 2312 previous SA rec (in the order that has been established). 2313 - Add the SA rec to the signal for this GW. 2315 If neither endpoint is for GW controlled by this PS: 2316 - Add SA rec to answer. 2318 10. IANA Considerations 2320 This document contains many "magic numbers" to be maintained by the 2321 IANA. This section explains the criteria to be used by the IANA to 2322 assign numbers beyond the ones defined in this document. 2324 10.1 Message Type 2326 The MTYPE field of the SPP Header (section 3.1) defines message 2327 exchange types for SPP. Requests for assignment of new message type 2328 values 7-250 must be accompanied by a reference to a standards-track 2329 or Informational RFC which describes the new message type and how it 2330 should be processed. Values 251-255 are for private use. 2332 10.2 Message Code 2334 The MCODE field of the SPP Header (section 3.1) defines the acceptable 2335 return codes for an SPP message. Requests for assignment of new 2336 message code values 12-250 must be accompanied by a description of the 2337 conditions under which the code is returned. Values 251-255 are for 2338 private use. 2340 10.3 Identity Type 2342 The Identity Type field of the SPP Header (section 3.1) defines the 2343 acceptable formats for identifying the sender of an SPP message. 2344 Requests for assignment of new identity types 4-250 must be 2345 accompanied by a description of the format of the corresponding SENDER 2346 IDENTITY field in the header. Values 251-255 are for private use. 2348 10.4 Payload Class 2350 The first octect of each payload header (section 3.2) defines the type 2351 of payload that follows it. Requests for assignment of new message 2352 type values 4-250 must be accompanied by a reference to a 2353 standards-track or Informational RFC which describes the format of the 2354 payload's header and data. Values 251-255 are for private use. 2356 10.5 Query Type 2358 The query type (section 3.2.1) defines how the payload data will be 2359 interpreted and answered. Requests for assignment of new query type 2360 values 4-65000 must be accompanied by a reference to a standards-track 2361 or Informational RFC which describes the format of the data and how it 2362 should be used. Values 65001-65535 are for private use. 2364 10.6 Record Type 2366 The record type (section 3.2.2) defines how the payload data will be 2367 interpreted. Requests for assignment of new record type values 2368 4-65000 must be accompanied by a reference to a standards-track or 2369 Informational RFC which describes the format of the data and how it 2370 should be used. Values 65001-65535 are for private use. 2372 10.7 Signature Type 2374 The signature type (section 3.2.3) defines the signature algorithm 2375 used to sign the SPP message. Requests for assignment of new 2376 signature type values 3-250 must be accompanied by a reference to a 2377 standards-track or Informational RFC or a reference to published 2378 cryptographic literature which describes this algorithm. Values 2379 251-255 are for private use. 2381 10.8 Certificate Type 2383 The Cert Type field of the Certificate query and record (section 3.1) 2384 defines the type of certificate requested or included in the payload. 2385 Requests for assignment of new certificate types 8-250 must be 2386 accompanied by a description of certificate and its encoding. Values 2387 251-255 are for private use. 2389 10.9 Certificate Identity Type 2391 The Identity Type and Authority Type fields of the certificate query 2392 (section 4.3) define the acceptable formats for identifying the host 2393 and its certificate authority for which a certificate is requested. 2394 Requests for assignment of new certificate identity types 5-250 must 2395 be accompanied by a description of the format of the corresponding 2396 IDENTITY and CERTIFICATE AUTHORITY fields in the payload. Values 2397 251-255 are for private use. 2399 10.10 Attribute Data Type 2401 The Data_Type field of the attribute encoding (section 7) defines the 2402 type of attribute included in the data_value field. Requests for 2403 assignment of new attribute data types 30-49 and 52-3200 must be 2404 accompanied by a description of the X bit indicating if it is in TLV 2405 or TV format, a detailed description of the Data_Value field 2406 corresponding to the attribute type, and in which record and query 2407 data fields the type may be used. Values 3200-32767 are for private 2408 use. 2410 10.11 User Name Type 2412 The Name_Type field of the user name attribute (section A.16) defines 2413 the data in the Name field of the attribute. Requests for assignment 2414 of new user name types 2-250 must be accompanied by a description of 2415 the corresponding Name field. Values 251-255 are for private use. 2417 10.12 System Name Type 2419 The Name_Type field of the system name attribute (section A.17) 2420 defines the data in the Name field of the attribute. Requests for 2421 assignment of new system name types 9-249 must be accompanied by a 2422 description of the corresponding Name field. Values 251-255 are for 2423 private use. 2425 10.13 IPsec Action Attribute 2427 The assigned values of Lifetime_Type, Cipher_Alg, Int_Alg_Esp, 2428 Int_Alg_Ah, and Ipcomp_Alg use the values of their associated fields 2429 in [Piper98] and are updated when the IANA updates their values in 2430 [Piper98]. 2432 The Loc_Type field of the IPsec action attribute (section A.30) 2433 defines the type of location address in the Loc_Src and Loc_Dst 2434 fields. Requests for assignment of new location types 5-250 must be 2435 accompanied by a description of the corresponding Loc_Src and Loc_Dst 2436 field. Values 251-255 are for private use. 2438 The Loc_Src and Loc_Dst fields of the IPsec action attribute (section 2439 A.30) may define a general location type. Requests for assignment of 2440 new general location values 5-250 must be accompanied by a description 2441 of the general location type. Values 251-255 are for private use. 2443 10.14 IKE Action Attribute 2445 The assigned values of Group Description, Group_Type, Auth_Method, 2446 PRF, Lifetime_Type, Cipher_Alg, and Hash_Alg use the values of their 2447 associated fields in [Harkins98] and are updated when the IANA updates 2448 their values in [Harkins98]. 2450 The Mode field of the IKE action attribute (section A.31) defines the 2451 IKE Mode. Requests for assignment of new Modes 3-250 must only be 2452 done when new modes are added to the IKE protocol. Values 251-255 are 2453 for private use. 2455 11. Security Considerations 2457 All SPP messages MUST be authenticated to prove which policy server 2458 sent the message and that it hasn't been modified en-route. The 2459 authentication MAY be provided using the signature payload provided 2460 by SPP or some other mechanism such as IPsec. 2462 However, since the policy data may change during SPP exchanges, the 2463 messages cannot maintain a signature from every policy server that is 2464 involved in the policy exchange. SPP depends on a chain-of-trust for 2465 end-to-end authentication. Messages between policy servers are 2466 authenticated and contain policy server records, which claim 2467 authorization over a node, and certificates, which include signed 2468 proof that the server is authoritative the node. The receiving server 2469 can use this information to create a chain of servers involved in the 2470 policy exchange from itself to the server authoritative over the 2471 destination of the query. This chain of authorized servers is used to 2472 prove that only servers that have authorization to be involved in the 2473 communication were involved. Section 8.3 for details on how the chain 2474 is created and verified. 2476 Policy information may be considered sensitive, since examining 2477 policies may expose expoitable weaknesses in the policies. The 2478 distribution of policies may be limited to reduce this risk. Policy 2479 distribution MAY be limited to those nodes that need to know the 2480 information. Limiting distribution any further negates the purpose of 2481 the protocol so is not allowed for proper use of SPP. 2483 Additional protections, such as privacy protection, may be desired 2484 by some domains. This can be achieved by encrypting SPP data. 2485 Encrypting SPP messages is out of scope of this document and may 2486 be discussed elsewhere. 2488 SPP uses timestamps to protect against replay attacks. This requires 2489 that nodes have adequately synchronized time-of-day clocks. It is 2490 necessary to choose an appropriately sized window of time in which 2491 timestamps may be accepted. If the window is too small, valid 2492 messages may be discarded. On the other hand, if the window is too 2493 large it may leave the server open to replay attacks. 2495 Acknowledgments 2497 The authors thank Charles Lynn, Steve Kent and John Zao for their 2498 participation in requirements discussions for the Security Policy 2499 System. Our gratitude to Charlie Lynn, Matt Fredette, Alden Jackson, 2500 Dave Mankins, Marla Shepard and Pam Helinek for the contributions to 2501 this document. We thank Joel Levin and Mary Hendrix (INS Corp.) for 2502 reviewing this document. We thank Isidro Castineyra for his 2503 contributions to the early parts of this work. 2505 References 2507 [Bra97] Bradner, S., "Key Words for use in RFCs to indicate 2508 Requirement Levels", RFC2119, March 1997. 2510 [Kent98] S. Kent, R. Atkinson, "Security Architecture for the 2511 Internet Protocol", RFC 2401, November 1998. 2513 [KA98b] S. Kent, R. Atkinson, "IP Encapsulating Security 2514 Payload (ESP)", RFC 2406, November 1998. 2516 [isakmp] D. Maughan, M. Schertler, M. Schneider, J. Turner, "Internet 2517 Security Association and Key Management Protocol (ISAKMP)", 2518 RFC 2408, November 1998. 2520 [RFC1035] Mockapetris, P., "Domain Names - Implementation and 2521 Specification", RFC 1035, November 1987. 2523 [RFC1305] Mills, D., "Network Time Protocol (Version 3): 2524 Specification, Implementation and Analysis", RFC 1305, March 2525 1992. 2527 [RGSC00] F. Reichmeyer , D. Grossman, J. Strassner, M. Condell, 2528 "A Common Terminology for Policy Management" Internet Draft 2529 draft-reichmeyer-polterm-terminology-00.txt, March 2000. 2531 [PKIXP1] R. Housley, W. Ford, W. Polk, D. Solo, "Internet Public 2532 Key Infrastructure: X.509 Certificate and CRL Profile". 2533 RFC 2459, January 1999. 2535 [Harkins98] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", 2536 RFC 2409, November 1998. 2538 [Piper98] D. Piper, "The Internet IP Security Domain of 2539 Interpretation for ISAKMP", RFC 2407, November 1998. 2541 [SPS] M. Richardson, A. Keromytis, L. Sanchez, "IPsec Policy 2542 Discovery Protocol Requirements", Internet Draft, 2543 draft-richardson-ipsp-requirements-00.txt, October 1999. 2545 [SPSL] M. Condell, C. Lynn, J. Zao "Security Policy Specification 2546 Language", Internet Draft draft-ietf-ipsp-spsl-00.txt, 2547 March 2000 2549 APPENDIX A 2551 DATA_TYPE Definitions 2553 The encoding of each selector and SA attribute is decribed here. 2554 Each attribute is described using the following set of data: 2556 X The value of the X bit in the attribute encoding. 2557 DATA_TYPE The value of the DATA_TYPE field in the attribute 2558 encoding. 2559 LENGTH The length of the data to use if X = 0. 2560 list 'yes' indicates the attribute may be used as a list 2561 as described below. 2562 DATA_VALUE Encoding of the DATA_VALUE field in the attribute 2563 encoding. 2565 Attributes generally encode "any" in one of two ways. If using 2566 the TLV format (X = 0) then the length is set to 0 to indicate any. 2567 If the TV format (X = 1) is used, then the value is set to 0; 2569 Attributes that may be expressed as lists provide the DATA_VALUE 2570 encoding for one element of the list. Multiple list elements may be 2571 expressed by concatenating multiple list elements. The LENGTH of 2572 attribute is the number of elements present times the length of one 2573 list element. Therefore, when reading an attribute that can be 2574 expressed as a list, the number of list elements may be determined by 2575 dividing the length by the size of a single list element. 2577 The remainder of this appendix describes the values and encoding for 2578 each selector and SA attribute specified in section 7. 2580 A.1 IPV4_ADDR 2582 X 0 2583 DATA_TYPE 1 2584 LENGTH 4 if an IP address is present, 2585 0 if no IP address is present. 2586 list No 2587 DATA_VALUE 2589 0 1 2 3 2590 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2592 | ADDRESS | 2593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2595 ADDRESS 2597 An IPV4 address 2598 A.2 IPV6_ADDR 2600 X 0 2601 DATA_TYPE 2 2602 LENGTH 16 if an IP address is present, 2603 0 if no IP address is present. 2604 list No 2605 DATA_VALUE 2607 0 1 2 3 2608 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2610 | | 2611 | | 2612 | ADDRESS | 2613 | | 2614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2616 ADDRESS 2618 An IPV6 address 2620 A.3 SRC_IPV4_ADDR 2622 X 0 2623 DATA_TYPE 3 2624 LENGTH 4 times the number of addresses in the list. 2625 A length of 0 indicates any address. 2626 list Yes 2627 DATA_VALUE 2629 0 1 2 3 2630 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2632 | SRC ADDRESS | 2633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2635 SRC ADDRESS 2637 An IPV4 address representing the source host of a 2638 communication 2640 A.4 SRC_IPV4_ADDR_SUBNET 2642 X 0 2643 DATA_TYPE 4 2644 LENGTH 8 times the number of subnets in the list. 2645 A length of 0 indicates any subnet. 2646 list Yes 2647 DATA_VALUE 2648 0 1 2 3 2649 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2651 | SUBNET ADDRESS | 2652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2653 | SUBNET MASK | 2654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2656 SUBNET ADDRESS 2658 An IPV4 address representing the source subnet of a 2659 communication 2661 SUBNET MASK 2663 An IPV4 address representing the source subnet mask of a 2664 communication 2666 A.5 SRC_IPV4_ADDR_RANGE 2668 X 0 2669 DATA_TYPE 5 2670 LENGTH 8 times the number of address ranges in the list. 2671 A length of 0 indicates any address. 2672 list Yes 2673 DATA_VALUE 2675 0 1 2 3 2676 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2678 | LOWER BOUND SRC ADDRESS | 2679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2680 | UPPER BOUND SRC ADDRESS | 2681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2683 LOWER BOUND SRC ADDRESS 2685 An IPV4 address representing the includsive lower-bound 2686 of a range of source addresses of a communication. 2688 UPPER BOUND SRC ADDRESS 2690 An IPV4 address representing the includsive upper-bound 2691 of a range of source addresses of a communication. 2693 A.6 DST_IPV4_ADDR 2695 X 0 2696 DATA_TYPE 6 2697 LENGTH 4 times the number of addresses in the list. 2698 A length of 0 indicates any address. 2699 list Yes 2700 DATA_VALUE 2701 0 1 2 3 2702 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2704 | DST ADDRESS | 2705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2707 DST ADDRESS 2709 An IPV4 address representing the destination host of a 2710 communication 2712 A.7 DST_IPV4_ADDR_SUBNET 2714 X 0 2715 DATA_TYPE 7 2716 LENGTH 8 times the number of subnets in the list. 2717 A length of 0 indicates any subnet. 2718 list Yes 2719 DATA_VALUE 2721 0 1 2 3 2722 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2724 | SUBNET ADDRESS | 2725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2726 | SUBNET MASK | 2727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2729 SUBNET ADDRESS 2731 An IPV4 address representing the destination subnet of a 2732 communication 2734 SUBNET MASK 2736 An IPV4 address representing the destination subnet mask 2737 of a communication 2739 A.8 DST_IPV4_ADDR_RANGE 2741 X 0 2742 DATA_TYPE 8 2743 LENGTH 8 times the number of address ranges in the list. 2744 A length of 0 indicates any address. 2745 list Yes 2746 DATA_VALUE 2748 0 1 2 3 2749 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2751 | LOWER BOUND DST ADDRESS | 2752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2753 | UPPER BOUND DST ADDRESS | 2754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2755 LOWER BOUND DST ADDRESS 2757 An IPV4 address representing the includsive lower-bound 2758 of a range of destination addresses of a communication. 2760 UPPER BOUND DST ADDRESS 2762 An IPV4 address representing the includsive upper-bound 2763 of a range of destination addresses of a communication. 2765 A.9 SRC_IPV6_ADDR 2767 X 0 2768 DATA_TYPE 9 2769 LENGTH 16 times the number of addresses in the list. 2770 A length of 0 indicates any address. 2771 list Yes 2772 DATA_VALUE 2774 0 1 2 3 2775 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2777 | | 2778 | SRC | 2779 | ADDRESS | 2780 | | 2781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2783 SRC ADDRESS 2785 An IPV6 address representing the source host of a 2786 communication 2788 A.10 SRC_IPV6_ADDR_SUBNET 2790 X 0 2791 DATA_TYPE 10 2792 LENGTH 32 times the number of subnets in the list. 2793 A length of 0 indicates any subnet. 2794 list Yes 2795 DATA_VALUE 2796 0 1 2 3 2797 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2799 | | 2800 | SUBNET | 2801 | ADDRESS | 2802 | | 2803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2804 | | 2805 | SUBNET | 2806 | MASK | 2807 | | 2808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2810 SUBNET ADDRESS 2812 An IPV6 address representing the source subnet of a 2813 communication 2815 SUBNET MASK 2817 An IPV6 address representing the source subnet mask of a 2818 communication 2820 A.11 SRC_IPV6_ADDR_RANGE 2822 X 0 2823 DATA_TYPE 11 2824 LENGTH 32 times the number of address ranges in the list. 2825 A length of 0 indicates any address. 2826 list Yes 2827 DATA_VALUE 2829 0 1 2 3 2830 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2832 | | 2833 | LOWER BOUND | 2834 | SRC ADDRESS | 2835 | | 2836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2837 | | 2838 | UPPER BOUND | 2839 | SRC ADDRESS | 2840 | | 2841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2843 LOWER BOUND SRC ADDRESS 2845 An IPV6 address representing the includsive lower-bound 2846 of a range of source addresses of a communication. 2848 UPPER BOUND SRC ADDRESS 2850 An IPV6 address representing the includsive upper-bound 2851 of a range of source addresses of a communication. 2853 A.12 DST_IPV6_ADDR 2855 X 0 2856 DATA_TYPE 12 2857 LENGTH 16 times the number of addresses in the list. 2858 A length of 0 indicates any address. 2859 list Yes 2860 DATA_VALUE 2862 0 1 2 3 2863 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2865 | | 2866 | DST | 2867 | ADDRESS | 2868 | | 2869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2871 DST ADDRESS 2873 An IPV6 address representing the destination host of a 2874 communication 2876 A.13 DST_IPV6_ADDR_SUBNET 2878 X 0 2879 DATA_TYPE 13 2880 LENGTH 32 times the number of subnets in the list. 2881 A length of 0 indicates any subnet. 2882 list Yes 2883 DATA_VALUE 2885 0 1 2 3 2886 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2888 | | 2889 | SUBNET | 2890 | ADDRESS | 2891 | | 2892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2893 | | 2894 | SUBNET | 2895 | MASK | 2896 | | 2897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2898 SUBNET ADDRESS 2900 An IPV6 address representing the destination subnet of a 2901 communication 2903 SUBNET MASK 2905 An IPV6 address representing the destination subnet mask 2906 of a communication 2908 A.14 DST_IPV6_ADDR_RANGE 2910 X 0 2911 DATA_TYPE 14 2912 LENGTH 32 times the number of address ranges in the list. 2913 A length of 0 indicates any address. 2914 list Yes 2915 DATA_VALUE 2917 0 1 2 3 2918 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2920 | | 2921 | LOWER BOUND | 2922 | DST ADDRESS | 2923 | | 2924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2925 | | 2926 | UPPER BOUND | 2927 | DST ADDRESS | 2928 | | 2929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2931 LOWER BOUND DST ADDRESS 2933 An IPV6 address representing the includsive lower-bound 2934 of a range of destination addresses of a communication. 2936 UPPER BOUND DST ADDRESS 2938 An IPV6 address representing the includsive upper-bound 2939 of a range of destination addresses of a communication. 2941 A.15 DIRECTION 2943 X 1 2944 DATA_TYPE 15 2945 LENGTH TV attribute, no length 2946 list No 2947 DATA_VALUE 2948 1 2 3 2949 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2951 | DIRECTION | 2952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2954 DIRECTION 2955 In/Outbound 0 2956 Inbound 1 2957 Outbound 2 2959 Direction is with respect to the senders interface. 2961 A.16 USER_NAME 2963 X 0 2964 DATA_TYPE 16 2965 LENGTH 1 plus the length of NAME 2966 A length of 0 indicates any name. 2967 list No 2968 DATA_VALUE 2970 0 1 2 3 2971 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2973 | NAME_TYPE | NAME ~ 2974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2976 NAME_TYPE 2977 822_EMAIL 0 2978 DIST_NAME 1 2980 values 2-250 are reserved to IANA. Values 251-255 are for 2981 private use among mutually consenting parties. 2983 NAME 2984 Name of type NAME_TYPE: 2986 NAME_TYPE Description of NAME 2988 822_EMAIL A fully-qualified user name string 2989 (e.g. "jdoe@example.com") as defined in 2990 RFC 822. The string must not contain 2991 any terminators 2993 DIST_NAME A fully-qualified distinguished name string 2994 (e.g. "CN=John Doe, O=Example, Inc, C=US ") 2995 as defined in RFC 1779. The string must not 2996 contain any terminators 2998 A.17 SYSTEM_NAME 3000 X 0 3001 DATA_TYPE 17 3002 LENGTH 1 plus the length of NAME 3003 A length of 0 indicates any name. 3004 list No 3005 DATA_VALUE 3007 0 1 2 3 3008 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3010 | NAME_TYPE | NAME ~ 3011 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3013 NAME_TYPE 3014 DNS_NAME 0 3015 DIST_NAME 1 3016 822_NAME 2 3017 X400_ADDR 3 3018 DIR_NAME 4 3019 EDI_PARTY_NAME 5 3020 URI 6 3021 IPADDR 7 3022 REGID 8 3023 OTHER 250 3025 values 9-249 are reserved to IANA. Values 251-255 are for 3026 private use among mutually consenting parties. 3028 NAME 3029 Name of type NAME_TYPE. Strings must not contain any 3030 terminators. 3032 NAME_TYPE Description of NAME 3034 DNS_NAME A DNS name string (e.g. "host.example.com") 3035 as defined in RFC 1034. 3037 DIST_NAME A fully-qualified distinguished name string 3038 (e.g. "CN=John Doe, O=Example Inc, C=US ") 3039 as defined in RFC 1779. 3041 822_EMAIL A fully-qualified user name string 3042 (e.g. "jdoe@example.com") as defined in 3043 RFC 822. 3045 X400_ADDR A textual representation of an X.400 OR 3046 address string 3047 (e.g. "/CN=John Doe/O=Example Inc/C=US/") 3048 as defined in RFC 2156. 3050 DIR_NAME A relative distinguished name string 3051 (e.g. "OU=Engineering + CN=John Doe, 3052 O=Example Inc, C=US ") as defined in RFC 1779. 3054 EDI_PARTY_NAME An electronic data interchange name string. 3056 URI A uniform resource identifier string 3057 (e.g. "ftp://ftp.example.com/pub/doc.html") 3058 as defined in RFC 2396. 3060 IPADDR A 32-bit or 128-bit IP address. Note that 3061 this is NOT the string representation of 3062 the IP address. 3064 REGID A registered ID is represented by a string 3065 representation of the dotted integer 3066 representation of an object ID (OID) 3067 (e.g. "4.5.8.2.1"). 3069 OTHER This is an object identifier followed by 3070 object specific information. The OID is 3071 represented as above, however, its end is 3072 indicated by a colon ":" which is followed 3073 by the object specified information. 3074 (e.g. "4.5.8.2.1:" 98 "jdoe") 3076 A.18 XPORT_PROTOCOL 3078 X 0 3079 DATA_TYPE 18 3080 LENGTH 1 plus length of pdata 3081 A length of 0 indicates any address. 3082 list No (see below) 3083 DATA_VALUE 3085 0 1 2 3 3086 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3087 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3088 | PTYPE | PDATA ~ 3089 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3091 PTYPE Describes the rest of the data: 3092 ANY 0 3093 OPAQUE 1 3094 LIST 2 3095 RANGE 3 3097 PDATA 3098 Not used if PTYPE is ANY or OPAQUE. 3100 LIST 3101 indicates a list whose elements look like the following: 3103 0 3104 0 1 2 3 4 5 6 7 3105 +-+-+-+-+-+-+-+-+ 3106 | PROTOCOL | 3107 +-+-+-+-+-+-+-+-+ 3109 The length of pdata to be used as part of the LENGTH 3110 field is 1 times the number of elements in the list. 3112 RANGE 3113 indicates a range of protocol values whose inclusive 3114 lower-bound is LOWER, and inclusive upper-bound is UPPER. 3115 0 1 3116 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 3117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3118 | LOWER | UPPER | 3119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3121 The length of pdata to be used as part of the LENGTH 3122 field is 2. 3124 A.19 SRC_PORT 3126 X 0 3127 DATA_TYPE 19 3128 LENGTH 2 times the number of ports in the list. 3129 A length of 0 indicates any port. 3130 list Yes 3131 DATA_VALUE 3133 0 1 3134 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3136 | PORT | 3137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3139 PORT 3140 Port that the communication must be initiated with. This 3141 may be a list of ports. 3143 A.20 SRC_PORT_DYNAMIC 3145 X 0 3146 DATA_TYPE 20 3147 LENGTH 4 plus 2 times the number of ports in the list. 3148 A length of 4 indicates any port. 3149 list See Below 3150 DATA_VALUE 3151 0 1 2 3 3152 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3154 | DYNAMIC LOWER BOUND | DYNAMIC UPPER BOUND | 3155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3156 | PORT | ... ~ 3157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3159 The use of this attribute indicates that dynamic port allocation 3160 is permitted. Communications that are intitiated with any of the 3161 ports indicated, may then dynamically allocate any of the ports 3162 listed within the LOWER and UPPER BOUNDS, inclusive. 3164 DYNAMIC LOWER BOUND 3165 Lower bound of the range of ports that may be dynamically 3166 allocated. If this and DYNAMIC UPPER BOUND are both 0, 3167 then any port may be dynamically allocated. 3169 DYNAMIC UPPER BOUND 3170 Upper bound of the range of ports that may be dynamically 3171 allocated. If this and DYNAMIC LOWER BOUND are both 0, 3172 then any port may be dynamically allocated. 3174 PORT 3175 Port that the communication must be initiated with. This 3176 may be a list of ports. 3178 A.21 DST_PORT 3180 X 0 3181 DATA_TYPE 21 3182 LENGTH 2 times the number of ports in the list. 3183 A length of 0 indicates any port. 3184 list Yes 3185 DATA_VALUE 3187 0 1 3188 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3190 | PORT | 3191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3193 PORT 3194 Port that the communication must be initiated with. This 3195 may be a list of ports. 3197 A.22 DST_PORT_DYNAMIC 3199 X 0 3200 DATA_TYPE 22 3201 LENGTH 4 plus 2 times the number of ports in the list. 3202 A length of 4 indicates any port. 3203 list See Below 3204 DATA_VALUE 3205 0 1 2 3 3206 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3208 | DYNAMIC LOWER BOUND | DYNAMIC UPPER BOUND | 3209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3210 | PORT | ... ~ 3211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3213 The use of this attribute indicates that dynamic port allocation 3214 is permitted. Communications that are intitiated with any of the 3215 ports indicated, may then dynamically allocate any of the ports 3216 listed within the LOWER and UPPER BOUNDS, inclusive. 3218 DYNAMIC LOWER BOUND 3219 Lower bound of the range of ports that may be dynamically 3220 allocated. If this and DYNAMIC UPPER BOUND are both 0, 3221 then any port may be dynamically allocated. 3223 DYNAMIC UPPER BOUND 3224 Upper bound of the range of ports that may be dynamically 3225 allocated. If this and DYNAMIC LOWER BOUND are both 0, 3226 then any port may be dynamically allocated. 3228 PORT 3229 Port that the communication must be initiated with. This 3230 may be a list of ports. 3232 A.23 SEC_LABELS 3234 X 0 3235 DATA_TYPE 23 3236 LENGTH Variable. 3237 list No 3238 DATA_VALUE 3240 0 1 2 3 3241 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3243 | SECURITY LABEL ~ 3244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3246 SECURITY LABEL 3248 Bit representation of the security label for the IP 3249 security option field. 3251 A.24 V6CLASS 3253 X 1 3254 DATA_TYPE 24 3255 LENGTH TV attribute, no length 3256 list No 3257 DATA_VALUE 3258 1 2 3 3259 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3261 | PADDING | CLASS | 3262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3264 PADDING 3266 set to 0 3268 CLASS 3270 class value 3272 A.25 V6FLOW 3274 X 0 3275 DATA_TYPE 25 3276 LENGTH 4 3277 list No 3278 DATA_VALUE 3279 0 1 2 3 3280 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3282 | PADDING | FLOW | 3283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3285 PADDING 3287 set to 0 3289 FLOW 3291 set to flow value 3293 A.26 V4TOS 3295 X 1 3296 DATA_TYPE 26 3297 LENGTH TV attribute, no length 3298 list No 3299 DATA_VALUE 3301 1 2 3 3302 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3304 | PADDING | TOS | 3305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3307 PADDING 3309 set to 0 3310 TOS 3312 type of service value 3314 A.27 ACTION 3316 X 1 3317 DATA_TYPE 27 3318 LENGTH TV attribute, no length 3319 list No 3321 DATA_VALUE 3322 1 2 3 3323 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3325 | ACTION | 3326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3328 ACTION 3329 Deny 0 3330 Permit 1 3332 A.28 SRC_PORT_RANGE 3334 X 0 3335 DATA_TYPE 28 3336 LENGTH 4 times the number of port ranges in the list. 3337 A length of 0 indicates any port. 3338 list Yes 3339 DATA_VALUE 3341 0 1 2 3 3342 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3344 | PORT LOWER BOUND | PORT UPPER BOUND | 3345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3347 PORT LOWER BOUND 3349 Inclusive lower-bound of a range of port numbers that the 3350 communication must be initiated with. 3352 PORT UPPER BOUND 3354 Inclusive upper-bound of a range of port numbers that the 3355 communication must be initiated with. 3357 A.29 DST_PORT_RANGE 3359 X 0 3360 DATA_TYPE 29 3361 LENGTH 4 times the number of port ranges in the list. 3362 A length of 0 indicates any port. 3363 list Yes 3364 DATA_VALUE 3366 0 1 2 3 3367 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3369 | PORT LOWER BOUND | PORT UPPER BOUND | 3370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3372 PORT LOWER BOUND 3374 Inclusive lower-bound of a range of port numbers that the 3375 communication must be initiated with. 3377 PORT UPPER BOUND 3379 Inclusive upper-bound of a range of port numbers that the 3380 communication must be initiated with. 3382 A.30 IPSEC_ACTION 3384 X 0 3385 DATA_TYPE 50 3386 LENGTH Variable 3387 list Yes 3388 DATA_VALUE 3389 0 1 2 3 3390 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----- 3392 | ESP | RESERVED | LIFETIME_TYPE | | 3393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3394 | LIFETIME | Fixed 3395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length 3396 | AH | IPCOMP | LIFETIME_TYPE | | 3397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3398 | LIFETIME | | 3399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----- 3400 | N_OF_CIPHERS | CIPHER_ALG | CIPHER_KEYLENGTH 3401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3402 | ROUNDS | ... 3403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3404 | N_OF_INT_ESP | INT_ALG_ESP | ESP_INT_KEYLENGTH ... 3405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3406 | N_OF_INT_AH | INT_ALG_AH | INT_KEYLENGTH ... 3407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3408 | N_OF_IPCOMP | IPCOMP_ALG ... 3409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3410 | N_OF_LOCATIONS|E|P| LOC_TYPE | LOCATION... 3411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3413 ESP 3415 This octet indicates if ESP is to be used and in what 3416 mode. NOT REQUIRED means that ESP is not necessary but if used 3417 it MUST be negotiated based on the parameters defined 3418 below. TUNNEL_MODE or TRANSP_MODE means that ESP MUST be 3419 negotiatiated in this mode. ANY_MODE means that ESP MUST be 3420 negotited and that any mode (Tunnel or transport) will 3421 suffice. NOT ALLOWED means that ESP SHOULD NOT be negotiated 3422 and it MUST NOT be part of this SA. 3424 NOT_REQUIRED 0 3425 TUNNEL_MODE 1 3426 TRANSP_MODE 2 3427 TUNNEL_MODE_OPT 3 3428 TRANSP_MODE_OPT 4 3429 ANY_MODE 5 3430 NOT ALLOWED 6 3432 LIFETIME_TYPE 3434 This 2 octet field indicates type of lifetime. 3436 RESERVED 0 3437 SECONDS 1 3438 KILOBYTES 2 3440 These values are assigned in section 4.5 of [Piper98] and 3441 are updated when those assigned values change. 3443 RESERVED 3445 This 1 octet field primarily used for alignment purposes. Its 3446 value is always 0. 3448 LIFETIME 3450 This 4 octet field indicates the SA lifetime. For a given 3451 "Lifetime_Type" the value of the "Lifetime" attribute 3452 defines the actual length of the SA life--either a number of 3453 seconds, or a number of kilobytes protected. 0 is not used. 3455 AH 3456 This octet indicates if AH is to be used and in what mode. NOT 3457 REQUIRED means that AH is not necessary but if used it MUST be 3458 negotiated based on the parameters defined below. TUNNEL_MODE or 3459 TRANSP_MODE means that AH MUST be negotiatiated in this 3460 mode. ANY_MODE means that AH MUST be negotited and that any 3461 mode (Tunnel or transport) will suffice. NOT 3462 ALLOWED means that AH SHOULD NOT be negotiated and it MUST 3463 not be part of this SA. 3465 NOT_REQUIRED 0 3466 TUNNEL_MODE 1 3467 TRANSP_MODE 2 3468 TUNNEL_MODE_OPT 3 3469 TRANSP_MODE_OPT 4 3470 ANY_MODE 5 3471 NOT ALLOWED 6 3473 IPCOMP 3474 This field indicates if IP Compression is to be used. NOT 3475 REQUIRED means that IPCOMP is not necessary but if used it MUST 3476 be negotiated based on the parameters defined below. REQUIRED 3477 means that IPCOMP MUST be negotiated as part of this SA. NOT 3478 ALLOWED means that IPCOMP MUST NOT be part of this SA. 3480 NOT_REQUIRED 0 3481 REQUIRED 1 3482 NOT ALLOWED 2 3484 N_OF_CIPHERS 3486 This octet indicates the number of CIPHER_ALG fields in octets 3487 that will follow this field and that could be used during an 3488 IKE phase 2 negotiation. If the value of the ESP 3489 field is (04)hex this field MUST be set to 0. 3491 CIPHER_ALG 3493 This octet indicates which ciphers should be used for the IKE 3494 phase 2 negotiation. If the ANY identifier is used, it MUST be 3495 the only identifier in the list, and its meaning does not 3496 include the NULL cipher. If the value of the N_OF_CIPHERS 3497 field is 0 the CIPHER_ALG, the CIPHER_KEYLENTH and the ROUNDS 3498 fields are ignored. 3500 ANY 0 3501 NULL 1 3502 RFC1829_IV64 2 3503 DES 3 3504 DES3 4 3505 RC5 5 3506 IDEA 6 3507 CAST 7 3508 BLOWFISH 8 3509 3IDEA 9 3510 RFC1829_IV32 10 3511 RC4 11 3513 These values are assigned in section 4.4.4 of [Piper98], with 3514 the exception of 0 being defined as ANY, and are updated when 3515 those assigned values change. 3517 CIPHER_KEYLENGTH 3519 The first octet corresponds to the minimum value and the 3520 second octet corresponds to the maximum value. If no range 3521 exist the first octet indicates the keylength. The second 3522 octet contains a value of (00)hex. 3524 ROUNDS 3526 The first octet corresponds to the minimum value and the 3527 second octet corresponds to the maximum value. If no range 3528 exist the first octet indicates the rounds. The second 3529 octet contains a value of (00)hex. 3531 N_OF_INT_ESP 3533 This octet indicates the number of INTEGRITY_ALG fields in 3534 octets that will follow this field and that could be used 3535 during an IKE phase 1 negotiation. If this field is 0 no 3536 authentication/integrity is used with ESP. 3538 INT_ALG_ESP 3540 This octet indicates which algorithm should be used for the 3541 IKE phase 2 negotiation. If the ANY identifier is used, it 3542 MUST be the only identifier in the list. If the value of the 3543 N_OF_INT_ESP field is 0 this INT_ALG_ESP and ESP_INT_KEYLENGTH 3544 are ignored. 3546 ANY 0 3547 HMAC_MD5 1 3548 HMAC_SHA1 2 3549 DES_MAC 3 3550 KPDK 4 3552 These values are assigned in section 4.5 of [Piper98], with 3553 the exception of 0 being defined as ANY, and are updated when 3554 those assigned values change. 3556 ESP_INT_KEYLENGTH 3558 The first octet corresponds to the minimum value and the 3559 second octet corresponds to the maximum value. If no range 3560 exist the first octet indicates the keylength. The second 3561 octet contains a value of (00)hex. 3563 N_OF_INT_AH 3565 This octet indicates the number of INTEGRITY_ALG fields in 3566 octets that will follow this field and that could be used 3567 during an IKE phase 1 negotiation. If the value of the AH 3568 field is (04)hex this field MUST be set to 0. 3570 INT_ALG_AH 3572 This octet indicates which algorithm should be used for the 3573 IKE phase 2 negotiation. If the value of the N_OF_INT_AH 3574 field is 0 the INT_ALG_AH and the INT_KEYLENGTH fields are 3575 ignored. 3577 ANY 0 3578 HMAC_MD5 1 3579 HMAC_SHA1 2 3580 DES_MAC 3 3581 KPDK 4 3583 These values are assigned in section 4.5 of [Piper98], with 3584 the exception of 0 being defined as ANY, and are updated when 3585 those assigned values change. 3587 INT_ KEYLENGTH 3589 The first octet corresponds to the minimum value and the 3590 second octet corresponds to the maximum value. If no range 3591 exist the first octet indicates the keylength. The second 3592 octet contains a value of (00)hex. 3594 N_OF_IPCOMP 3596 This octet indicates the number of IPCOMP_ALG fields in octets 3597 that will follow this field and that could be used during an 3598 IKE phase 2 negotiation. If the value of the IPCOMP 3599 field is (04)hex this field MUST be set to 0. 3601 IPCOMP_ALG 3603 This octet indicates which algorithm should be used for the 3604 IKE phase 2 negotiation. If the ANY identifier is used, it 3605 MUST be the only identifier in the list. If the value of the 3606 N_OF_IPCOMP field is 0 this field is ignored. 3608 ANY 0 3609 OUI 1 3610 DEFLATE 2 3611 LZS 3 3613 These values are assigned in section 4.4.5 of [Piper98], with 3614 the exception of 0 being defined as ANY, and are updated when 3615 those assigned values change. 3617 N_OF_LOCATIONS 3619 This octet indicates the number of E/P/LOC_TYPE fields 3620 that will follow this field. 3622 E 3624 This bit indicates whether this location represents a 3625 source or destination location. E = 0 indicates a source 3626 location and E = 1 indications a destination location. 3628 P 3629 This bit indicates whether the location is for the AH or ESP 3630 SA. P = 0 indicates the location is for the AH SA while 3631 P = 1 indicates the location is for the ESP SA. 3633 LOC_TYPE 3635 This 6-bit field indicates the contents of the LOCATION 3636 field. If this field is 0 then the LOCATION will be omitted. 3638 NONE 0 3639 IPv4 address 1 3640 IPv6 address 2 3641 DNS Name 3 3642 General 4 3644 values 5-250 are reserved to IANA. Values 251-255 are for 3645 private use among mutually consenting parties. 3647 LOCATION 3649 Variable length field depending on LOC_TYPE. 3651 IF LOC_TYPE is (04) then this field is 1 octet in length an it 3652 may only take the following values: 3654 ANY 0 3655 DEST 1 3656 HOST 2 3657 LOCAL-SG 3 3658 REMOTE-SG 4 3660 values 5-250 are reserved to IANA. Values 251-255 are for 3661 private use among mutually consenting parties. 3663 If multiple locations are indicated that specify the same end-point 3664 for the same SA (i.e. E and P bits are the same), it indicates that 3665 they are possible alternatives for the end-point. 3667 A.31 IKE_ACTION 3669 X 0 3670 DATA_TYPE 51 3671 LENGTH Variable 3672 list No 3673 DATA_VALUE 3675 0 1 2 3 3676 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3678 | MODE |P|GR| RESERVED | FIELD SIZE | 3679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3680 | PRF | LIFETIME_TYPE | 3681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3682 | LIFETIME | 3683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3684 | N_OF_AUTH | AUTH_METHOD ... 3685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3686 | N_OF_CIPHERS | CIPHER_ALG | KEYLENGTH... 3687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3688 | N_OF_HASH | HASH_ALG ... 3689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3690 | GROUP... 3691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3692 MODE 3694 This octet indicates the IKE mode of operation. 3696 MAIN 0 3697 AGRESSIVE 1 3698 QUICK 2 3700 values 3-250 are reserved to IANA. Values 251-255 are for 3701 private use among mutually consenting parties. 3703 P 3705 Indicates if PFS is to be used for the SA negotiation. 3707 FALSE 0 3708 TRUE 1 3710 GR 3712 Indicates if a group description or group type fields are 3713 included in this IKE action. 3715 NO GROUP 0 3716 GROUP_DESCRIPTION 1 3717 GROUP_TYPE 2 3719 See the GROUP field below for more information. 3721 RESERVED 3723 Reserved for future use. Set to zero. 3725 FIELD SIZE 3727 The field size, in bits, of a Diffie-Hellman Group 3729 PRF 3730 There are currently no pseudo-random functions defined. 3732 These values are assigned in Appendix A of [Harkins98] 3733 and are updated when those assigned values change. 3735 LIFETIME_TYPE 3737 This 2 octet field indicates type of lifetime. 3739 seconds 1 3740 kilobytes 2 3742 These values are assigned in Appendix A of [Harkins98] 3743 and are updated when those assigned values change. 3745 LIFETIME 3747 This 4 octet field indicates the SA lifetime. For a given 3748 "Lifetime_Type" the value of the "Lifetime" attribute defines 3749 the actual length of the SA life-- either a number of seconds, 3750 or a number of kilobytes protected. 3752 N_OF_AUTH 3754 This octet indicates the number of AUTH_METHOD fields in octets 3755 that will follow this field and that could be used during an 3756 IKE phase 1 negotiation. 3758 AUTH_METHOD 3760 This octet indicates which authentication methods should be 3761 used. The number of auth_methods that could be used is N_OF_AUTH 3763 pre-shared key 1 3764 DSS signatures 2 3765 RSA signatures 3 3766 Encryption with RSA 4 3767 Revised encryption with RSA 5 3769 These values are assigned in Appendix A of [Harkins98] 3770 and are updated when those assigned values change. 3772 N_OF_CIPHERS 3774 This octet indicates the number of CIPHER_ALG fields in octets 3775 that will follow this field and that could be used during an 3776 IKE phase 1 negotiation. 3778 KEYLENGTH 3780 The first octet corresponds to the minimum value and the 3781 second octet corresponds to the maximum value. If no range 3782 exist the first octet indicates the keylength. The second 3783 octet contains a value of (00)hex. 3785 CIPHER_ALG 3787 This octet indicates which ciphers should be used for the IKE 3788 phase 1 negotiation. For IKE phase 2 negotiations this field is 3789 ignored. The number of ciphers that could be used is 3790 N_OF_CIPHERS 3792 ANY 0 3793 DES 1 3794 IDEA 2 3795 BLOWFISH 3 3796 RC5 4 3797 DES3 5 3798 CAST 6 3799 These values are assigned in Appendix A of [Harkins98], with 3800 the exception of 0 being defined as ANY, and are updated when 3801 those assigned values change. 3803 N_OF_HASH 3805 This octet indicates the number of HASH_ALG fields in octets 3806 that will follow this field and that could be used during an 3807 IKE phase 1 negotiation. 3809 HASH_ALG 3811 This octet indicates which algorithm should be used for the 3812 IKE phase 1 negotiation. For IKE phase 2 negotiations this 3813 field is ignored. 3815 ANY 0 3816 MD5 1 3817 SHA1 2 3818 TIGER 3 3820 These values are assigned in Appendix A of [Harkins98], with 3821 the exception of 0 being defined as ANY, and are updated when 3822 those assigned values change. 3824 GROUP 3826 This field describes the group to be used during ISAKMP 3827 negotiation. It is only present if GR is 1 or 2. If GR 3828 is 1 it takes the form of the GROUP_DESCRIPTION field below. 3829 If it is 2, it takes the form of the GROUP_DEFINITION field 3830 below. 3832 GROUP DESCRIPTION 3834 1 2 3 3835 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3837 | ACTION | 3838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3840 This 2 octet field indicates which group should be used during 3841 the ISAKMP phase 1 or phase 2 negotiation. 3843 Not Used 0 3844 default 768-bit MODP group 1 3845 alternate 1024-bit MODP group 2 3846 EC2N group on GP[2^155] 3 3847 EC2N group on GP[2^185] 4 3849 These values are assigned in Appendix A of [Harkins98] 3850 and are updated when those assigned values change. 3852 GROUP DEFINITION 3854 0 1 2 3 3855 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3857 | GROUP TYPE | RESERVED | 3858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3859 | PRIME LENGTH | PRIME 3860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3861 | GENERATOR 1 LENGTH | GENERATOR 1 3862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3863 | GENERATOR 2 LENGTH | GENERATOR 2 3864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3865 | CURVE A LENGTH | CURVE A 3866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3867 | CURVE B LENGTH | CURVE B 3868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3869 | GROUP LENGTH | GROUP 3870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3872 GROUP TYPE 3874 This 2 octet field indicates which group type should be used 3875 during the ISAKMP phase 1 or phase 2 negotiation. 3877 Not Used 0 3878 MODP 1 3879 ECP 2 3880 EC2N 3 3882 These values are assigned in Appendix A of [Harkins98] 3883 and are updated when those assigned values change. 3885 RESERVED 3887 Reserved for future use. Set to zero. 3889 PRIME LENGTH 3890 GENERATOR 1 LENGTH 3891 GENERATOR 2 LENGTH 3892 CURVE A LENGTH 3893 CURVE B LENGTH 3894 GROUP LENGTH 3896 Length of their respective fields in bytes. If their 3897 respective field does not exist, the length is set to zero. 3899 PRIME 3900 GENERATOR 1 3901 GENERATOR 2 3902 CURVE A 3903 CURVE B 3904 GROUP 3905 The group prime/irreducible polynomial, group generator one, 3906 group generator two, group curve A, group curve B, and group 3907 order, respectively. These are defined in [Harkins98]. 3909 APPENDIX B 3911 An SPP Example 3913 This appendix provides a detailed example of SPP in use. 3915 admin. boundary admin. boundary 3916 ----------------- --------------------------- 3917 | | | admin. boundary| 3918 | | | ---------------| 3919 | Q1 | Q2 | Q3 | || 3920 | H1 ---- SG1 ---- (Internet) --- SG2 ---- | SG3 --- H2 || 3921 | R3 | | R2 | | R1 | | || 3922 | PS1 | | PS2 | PS3 || 3923 | | | ---------------| 3924 ----------------- --------------------------- 3925 ESP Tunnel 3926 |=======================| 3927 ESP Tunnel 3928 |========================================| 3929 ESP Transport 3930 |================================================| 3932 |==| = security association required by policy 3933 ---- = connectivity (or if so labeled, administrative boundary) 3934 Hx = host x 3935 SGx = security gateway x 3936 PSx = policy server x 3937 Qx = query x 3938 Rx = reply x 3940 The following entities have these policies for a communication 3941 between H1 and H2 for UDP port 79: 3943 H1: requires an ESP Transport SA with H2 3944 PS1: requires an ESP Tunnel SA between SG1 and SG2 3945 PS2: requires an ESP Tunnel SA between SG1 and SG2 3946 PS3: requires an ESP Tunnel SA between H1 and SG3 3947 H2: requires an ESP Transport SA with H1 3949 PS1, PS2, PS3 also have policies allowing ESP to pass through 3950 their respective Security Gateways. 3952 1. The policy client at H1 is asked for a policy for a communication: 3953 H1 to H2 using UDP port 79. 3955 2. H1's policy client does not have an answer so it creates an SPP 3956 query, Q1: 3957 SPP Header [Query, Sender H1, qcount 1, rcount 2] 3958 Query Payload [comsec]: 3959 src H1, dst H2, UDP, 79 3960 Record Payload [comsec]: 3961 src H1, dst H2, UDP, 79, permit 3962 Record Payload [SA rec]: 3963 src H1, dst H2, UDP, 79, permit, ESP transport H1->H2 3964 Signature Payload 3965 H1 sends Q1 to PS1, its configured policy server. 3967 3. PS1 receives the query and verifies the signature. Its domain 3968 database indicates that it is not authoritative over H2 so it 3969 checks its cache to see if it has a cached answer. For this 3970 example, it does not, so it creates a new SPP query, Q2, with 3971 the query and records formed by merging the local policy with 3972 the policy from Q1: 3973 SPP Header [Query, Sender PS1, qcount 1, rcount 3] 3974 Query Payload [comsec]: 3975 src H1, dst H2, UDP, 79 3976 Record Payload [comsec]: 3977 src H1, dst H2, UDP, 79, permit 3978 Record Payload [SA rec]: 3979 src SG1, dst SG2, UDP, 79, permit, ESP tunnel SG1->SG2 3980 Record Payload [SA rec]: 3981 src H1, dst H2, UDP, 79, permit, ESP transport H1->H2 3982 Signature Payload 3983 PS1 sends Q2 to H2. 3985 4. SG2 intercepts Q2 and passes it to PS2. 3987 5. PS2 receives the query and verifies the signature. Its domain 3988 database indicates that it is not authoritative over H2 so it 3989 checks its cache to see if it has a cached answer. For this 3990 example, it does not, so it creates a new SPP query, Q3, with 3991 the query and records formed by merging the local policy with 3992 the policy from Q2: 3993 SPP Header [Query, Sender PS1, qcount 1, rcount 3] 3994 Query Payload [comsec]: 3995 src H1, dst H2, UDP, 79 3996 Record Payload [comsec]: 3997 src H1, dst H2, UDP, 79, permit 3998 Record Payload [SA rec]: 3999 src SG1, dst SG2, UDP, 79, permit, ESP tunnel SG1->SG2 4000 Record Payload [SA rec]: 4001 src H1, dst H2, UDP, 79, permit, ESP transport H1->H2 4002 Signature Payload 4003 PS2 sends Q3 to H2. 4005 6. SG3 intercepts Q3 and passes it to PS3. 4007 7. PS3 receives the query and verifies the signature. Its domain 4008 database indicates that it is authoritative over H2 so it 4009 will send a reply. It checks its cache to see if it has a cached 4010 answer. For this example, it does have one cached from previous 4011 information sent to it by H2. PS3 merges the cached policy with 4012 the policy it received from Q3. The merge indicates that a signal 4013 and a reply will be needed. PS3 caches the merged policy. 4015 PS3 creates a reply with the query payload from Q3, the merged 4016 policy and policy server and cert records: 4017 SPP Header [Reply, Sender PS3, qcount 1, rcount 6] 4018 Query Payload [comsec]: 4019 src H1, dst H2, UDP, 79 4020 Record Payload [comsec]: 4021 src H1, dst H2, UDP, 79, permit 4022 Record Payload [SA rec]: 4023 src SG1, dst SG2, UDP, 79, permit, ESP tunnel SG1->SG2 4024 Record Payload [SA rec]: 4025 src H1, dst SG3, UDP, 79, permit, ESP tunnel H1->SG3 4026 Record Payload [SA rec]: 4027 src H1, dst H2, UDP, 79, permit, ESP transport H1->H2 4028 Record Payload [policy server]: 4029 policy server PS3, node H2 4030 Record Payload [cert]: 4031 cert for PS3 4032 Signature Payload 4033 PS3 sends R1 to PS2. 4035 PS3 creates a signal with a comsec record derived from knowing the 4036 traffic that will pass through SG3 and, the part of the merged 4037 policy that terminates at SG3: 4038 SPP Header [Pol, Sender PS3, qcount 0, rcount 2] 4039 Record Payload [comsec]: 4040 src H1, dst H2, ESP, OPAQUE, permit 4041 Record Payload [SA rec]: 4042 src H1, dst SG3, UDP, 79, permit, ESP tunnel H1->SG3 4043 Signature Payload 4044 PS3 sends the signal to SG3. 4046 8. SG3 receives the signal and verifies the signature. SG3 creates 4047 an Ack message to indicate that it has received the policy message: 4048 SPP Header [Pol-Ack, Sender SG3, qcount 0, rcount 0] 4049 Signature Payload 4050 SG3 sends the signal to PS3. 4052 9. PS3 receives the Pol-Ack and verifies the signature. PS3 removes 4053 the corresponding policy message from its retry queue. 4055 10. Meanwhile, PS2 receives the reply R1 and verifies the signature and 4056 the chain-of-trust to verify the policy came from a server 4057 authoritative for H2. It matches an outstanding query message, so it 4058 will send a reply. PS2 merges the policy received in R1 with its 4059 local policy and the policy information it received from Q2. The 4060 merge indicates that a signal and a reply will be needed. PS2 4061 caches the merged policy. 4063 PS2 creates a reply with the query payload from R1, the merged 4064 policy and policy server and cert records: 4066 SPP Header [Reply, Sender PS2, qcount 1, rcount 8] 4067 Query Payload [comsec]: 4068 src H1, dst H2, UDP, 79 4069 Record Payload [comsec]: 4070 src H1, dst H2, UDP, 79, permit 4071 Record Payload [SA rec]: 4072 src SG1, dst SG2, UDP, 79, permit, ESP tunnel SG1->SG2 4073 Record Payload [SA rec]: 4074 src H1, dst SG3, UDP, 79, permit, ESP tunnel H1->SG3 4075 Record Payload [SA rec]: 4076 src H1, dst H2, UDP, 79, permit, ESP transport H1->H2 4077 Record Payload [policy server]: 4078 policy server PS3, node H2 4079 Record Payload [cert]: 4080 cert for PS3 4081 Record Payload [policy server]: 4082 policy server PS2, node PS3 4083 Record Payload [cert]: 4084 cert for PS2 4085 Signature Payload 4086 PS2 sends R2 to PS1. 4088 PS2 creates a signal with a comsec record derived from knowing the 4089 traffic that will pass through SG2 and, the part of the merged 4090 policy that terminates at SG2: 4091 SPP Header [Pol, Sender PS2, qcount 0, rcount 2] 4092 Record Payload [comsec]: 4093 src H1, dst SG3, ESP, OPAQUE, permit 4094 Record Payload [SA rec]: 4095 src SG1, dst SG2, UDP, 79, permit, ESP tunnel SG1->SG2 4096 Signature Payload 4097 PS2 sends the signal to SG2. 4099 11. SG2 receives the signal and verifies the signature. SG2 creates 4100 an Ack message to indicate that it has received the policy message: 4101 SPP Header [Pol-Ack, Sender SG2, qcount 0, rcount 0] 4102 Signature Payload 4103 SG2 sends the signal to PS2. 4105 12. PS2 receives the Pol-Ack and verifies the signature. PS2 removes 4106 the corresponding policy message from its retry queue. 4108 11. Meanwhile, PS1 receives the reply R2 and verifies the signature and 4109 the chain-of-trust to verify the policy came from a server 4110 authoritative for H2. R2 matches an outstanding query message, so it 4111 will send a reply. PS1 merges the policy received in R2 with its 4112 local policy and the policy information it received from Q1. The 4113 merge indicates that a signal and a reply will be needed. PS1 4114 caches the merged policy. 4116 PS1 creates a reply with the query payload from R2 and the merged 4117 policy. Policy server and cert records are not necessary since PS1 4118 is authoritative for H1: 4120 SPP Header [Reply, Sender PS1, qcount 1, rcount 3] 4121 Query Payload [comsec]: 4122 src H1, dst H2, UDP, 79 4123 Record Payload [comsec]: 4124 src H1, dst H2, UDP, 79, permit 4125 Record Payload [SA rec]: 4126 src H1, dst SG3, UDP, 79, permit, ESP tunnel H1->SG3 4127 Record Payload [SA rec]: 4128 src H1, dst H2, UDP, 79, permit, ESP transport H1->H2 4129 Signature Payload 4130 PS1 sends R3 to H1. 4132 PS1 creates a signal with a comsec record derived from knowing the 4133 traffic that will pass through SG1 and, the part of the merged 4134 policy that terminates at SG1: 4135 SPP Header [Pol, Sender PS1, qcount 0, rcount 2] 4136 Record Payload [comsec]: 4137 src H1, dst SG3, ESP, OPAQUE, permit 4138 Record Payload [SA rec]: 4139 src SG1, dst SG2, UDP, 79, permit, ESP tunnel SG1->SG2 4140 Signature Payload 4141 PS1 sends the signal to SG1. 4143 12. SG1 receives the signal and verifies the signature. SG1 creates 4144 an Ack message to indicate that it has received the policy message: 4145 SPP Header [Pol-Ack, Sender SG1, qcount 0, rcount 0] 4146 Signature Payload 4147 SG1 sends the signal to PS1. 4149 13. PS1 receives the Pol-Ack and verifies the signature. PS1 removes 4150 the corresponding policy message from its retry queue. 4152 14. Meanwhile, H1 receives the reply R3 and verifies the signature. 4153 The client can now use the policy as it is needed. 4155 Appendix C 4157 Decorrelation 4159 It is not possible for a Policy Server to use policies as they are 4160 written in the SPS master file, since those policies are likely to be 4161 correlated. Two policies are correlated if there is a non-nil 4162 intersection between the values of each of their selectors. Caching 4163 correlated policies can lead to incorrect policy implementation based 4164 on those cached policies, as the following example shows. 4166 H1 --- SG1 --------- SG2 --- H2 4167 | | \__ H3 4168 | | 4169 PS1 PS2 4171 PS2 contains the following policies in its master file: 4172 src dst proto direction action 4173 1) * H2 * inbound permit 4174 2) * * * inbound deny 4176 These two policies are correlated since all the selectors (src, dst, 4177 proto, and direction) overlap. The following SPP exchanges occur: 4179 1) PS1 requests policy for H3. 4180 2) PS2 returns policy #2 to PS1 which then caches policy #2. 4181 3) PS1 now looks up the policy for H2 and discovers that it already 4182 has a matching policy (policy #2) and uses that. 4184 This is clearly wrong, since policy #2 indicates that the 4185 communication to H2 should be denied, though PS2's policy actually 4186 indicates that it should be allowed. 4188 The solution is to remove the ambiguities that may exist in 4189 the master file. The policies of the master file MUST be decorrelated 4190 before they are entered into the Local Policy Database. That is, the 4191 policies must be rewritten so that for every pair of policies there 4192 exists a selector for which there is a nil intersection between the 4193 values in both of the policies. 4195 The policies in the above example could be decorrelated as follows: 4196 src dst proto direction action 4197 1') * H2 * inbound permit 4198 2') * not H2 * inbound deny 4200 Now the exchange is a bit different: 4201 1) PS1 requests policy for H3. 4202 2) PS2 returns policy #2' to PS1 which then caches policy #2'. 4203 3) PS1 now looks up the policy for H2, doesn't have a matching 4204 policy, so it requests a policy for H2. 4205 4) PS2 returns policy #1' to PS1 which then caches policy #1', 4206 which is the correct policy for H2. 4208 All SPAs and SPRs, therefore, MUST decorrelate their master 4209 files before using those policies for SPP. Once the policies are 4210 decorrelated, there is no longer any ordering requirement on the 4211 policies, since only one policy will match any requested 4212 communication. The next section describes decorrelation in more 4213 detail and presents an algorithm that may be used to implement 4214 decorrelation. 4216 C.1 Decorrelation Algorithm 4218 The basic decorrelation algorithm takes each policy in a correlated 4219 set of policies and divides it up into a set of policies using a tree 4220 structure. Those of the resulting policies that are decorrelated with 4221 the decorrelated set of policies are then added to that decorrelated 4222 set. 4224 The basic algorithm does not guarantee an optimal set of decorrelated 4225 policies. That is, the policies may be broken up into smaller sets 4226 than is necessary, though they will still provide all the necessary 4227 policy information. Some extensions to the basic algorithm are 4228 described later to improve this and improve the performance of the 4229 algorithm. 4231 C A set of ordered, correlated policies 4232 Ci The ith policy in C. 4233 U The set of decorrelated policies being built from C 4234 Ui The ith policy in U. 4236 A policy P may be expressed as a mapping of selector values to 4237 actions: 4238 Pi = Si1 x Si2 x ... x Sik -> Ai 4240 1) Put C1 in set U as U1 4242 For each policy Cj (j > 1) in C 4244 2) If Cj is decorrelated with every policy in U, then add it to U. 4246 3) If Cj is correlated with one or more policies in U, create a tree 4247 rooted at the policy Cj that partitions Cj into a set of decorrelated 4248 policies. The algorithm starts with a root node where no selectors 4249 have yet been chosen. 4251 A) Choose a selector in Cj, Scjn, that has not yet been chosen when 4252 traversing the tree from the root to this node. If there are no 4253 selectors not yet used, continue to the next unfinished branch 4254 until all branches have been completed. When the tree is 4255 completed, go to step D. 4257 T is the set of policies in U that are correlated with the policy 4258 to this node. 4260 The policy at this node is the policy formed by the selector 4261 values of each of the branches between the root and this node. 4262 Any selector values that are not yet represented by branches 4263 assume the corresponding selector value in Cj, since the values 4264 in Cj represent the maximum value for each selector. 4266 B) Add a branch to the tree for each value of the selector Scjn that 4267 appears in any of the policies in T. (If the value is a superset 4268 of the value of Scjn in Cj, then use the value in Cj, since that 4269 value represents the universal set.) Also add a branch for the 4270 compliment of the union of all the values of the selector Scjn 4271 in T. When taking the compliment, remember that the universal 4272 set is the value of Scjn in Cj. A branch need not be created 4273 for the nil set. 4275 C) Repeat A and B until the tree is completed. 4277 D) The policy to each leaf now represents a policy that is a subset 4278 of Cj. The policies at the leaves completely partition Cj in 4279 such a way that each policy is either completely overridden by 4280 a policy in U, or is decorrelated with the policies in U. 4282 Add all the decorrelated policies at the leaves of the tree to U. 4284 5) Get next Cj and goto 2. 4286 6) When all policies in C have been processed, then U will contain an 4287 decorrelated version of C. 4289 There are several optimizations that can be made to this algorithm. 4290 A few of them are presented here. 4292 It is possible to optimize, or at least improve, the amount of 4293 branching that occurs by carefully choosing the order of the selectors 4294 used for the next branch. For example, if a selector Scjn can be 4295 chosen so that all the values for that selector in T are equal to or a 4296 superset of the value of Scjn in Cj, then only a single branch need to 4297 be created (since the compliment will be nil). 4299 Branches of the tree do not have to proceed with the entire 4300 decorrelation algorithm. For example, if a node represents a policy 4301 that is decorrelated with all the policies in U, then there is no 4302 reason to continue decorrelating that branch. Also, if a branch is 4303 completely overridden by a policy in U, then there is no reason to 4304 continue decorrelating the branch. 4306 An additional optimization is to check to see if a branch is 4307 overridden by one of the CORRELATED policies in set C that has already 4308 been decorrelated. That is, if the branch is part of decorrelating 4309 Cj, then check to see if it was overridden by a policy Cm, m < j. 4310 This is a valid check, since all the policies Cm are already expressed 4311 in U. 4313 Along with checking if a policy is already decorrelated in step 2, 4314 check if Cj is overridden by any policy in U. If it is, skip it since 4315 it is not relevant. A policy x is overridden by another policy y if 4316 every selector in x is equal to or a subset of the corresponding 4317 selector in policy y. Appendix A shows an example of applying the 4318 algorithm to a set of correlated policies. 4320 C.2 Decorrelation Example 4322 This appendix section demonstrates the decorrelation algorithm and the 4323 optimizations presented on a sample set of policies. We start with 4324 the following set of correlated policies, set C: 4326 src dst prot sport dport user sec level 4327 C1 199.93/16 199.100.2/24 TCP * 22 lsanchez sec 4328 C2 199.93/16 199.100.2/24 TCP * * lsanchez conf 4329 C3 199.93/16 199.100.2/24 UDP * * lsanchez * 4330 C4 199.93/16 199.100.2/24 UDP * 52 * * 4331 C5 199.93/16 199.100.2/24 * * * * * 4332 C6 * * * * * * * 4334 C.2.1 policy C1 4336 We start with policy C1: 4338 src dst prot sport dport user sec level 4339 C1: 199.93/16 199.100.2/24 TCP * 22 lsanchez sec 4341 By step 1 of the algorithm, C1 is put directly into set U as policy 4342 U1. 4344 The current decorrelated policy set U is: 4345 U1 199.93/16 199.100.2/24 TCP * 22 lsanchez sec 4347 C.2.2 policy C2 4349 Next, we look at policy C2: 4351 src dst prot sport dport user sec level 4352 C2: 199.93/16 199.100.2/24 TCP * * lsanchez conf 4354 C2 is decorrelated with the policies already in U (U1) because the 4355 security levels do not overlap. By step 2, C2 is added to U as U2. 4357 The current decorrelated policy set U is: 4358 U1 199.93/16 199.100.2/24 TCP * 22 lsanchez sec 4359 U2 199.93/16 199.100.2/24 TCP * * lsanchez conf 4361 C.2.3 policy C3 4363 Next, we look at policy C3: 4365 src dst prot sport dport user sec level 4366 C3: 199.93/16 199.100.2/24 UDP * * lsanchez * 4367 C3 is decorrelated with the policies already in U (U1 and U2) because 4368 it uses UDP while both policies in U use TCP. By step 2, C3 is added 4369 to U as U3. 4371 The current decorrelated policy set U is: 4372 U1 199.93/16 199.100.2/24 TCP * 22 lsanchez sec 4373 U2 199.93/16 199.100.2/24 TCP * * lsanchez conf 4374 U3 199.93/16 199.100.2/24 UDP * * lsanchez * 4376 C.2.4 policy C4 4378 Next, we look at policy C4: 4380 src dst prot sport dport user sec level 4381 C4: 199.93/16 199.100.2/24 UDP * 52 * * 4383 T = {U3} o 4384 / \ 4385 ~lsanchez / \ (user) lsanchez 4387 Policy C4 is correlated with policy U3 in U, so T = {U3}. First we 4388 choose to decorrelate the user selector. The policy in T as the value 4389 "lsanchez" for this selector, so we create a branch for "lsanchez" and 4390 its compliment. 4392 The lsanchez branch: 4393 199.93/16 199.100.2/24 UDP * 52 lsanchez * 4394 is overriden by the policy U3. 4396 The compliment branch: 4397 199.93/16 199.100.2/24 UDP * 52 ~lsanchez * 4398 is decorrelated with T since ~lsanchez does not overlap any policies 4399 in T. Since this branch is decorrelated, it is added to set U. 4401 The current decorrelated policy set U is: 4402 U1 199.93/16 199.100.2/24 TCP * 22 lsanchez sec 4403 U2 199.93/16 199.100.2/24 TCP * * lsanchez conf 4404 U3 199.93/16 199.100.2/24 UDP * * lsanchez * 4405 U4 199.93/16 199.100.2/24 UDP * 52 ~lsanchez * 4407 C.2.5 policy C5 4409 Next, we look at policy C5: 4411 src dst prot sport dport user sec level 4412 C5: 199.93/16 199.100.2/24 * * * * * 4413 T = U o 4414 _______/|\_______ 4415 ~UDP,~TCP / | \ (prot) UDP 4416 | o T=U3,U4 4417 | TCP |\_________ 4418 | | \ 4419 | | lsanchez | (user) ~lsanchez 4420 T=U1,U2 o o T = U4 4421 / \ (user) / \ 4422 ~lsanchez / \ lsanchez ~52 / \ (dport) 52 4423 | 4424 T=U1,U2 o 4425 _________/|\_________ 4426 ~sec,~conf / | \ (sec label) conf 4427 | sec 4428 | 4429 T = U1 o 4430 / \ 4431 ~22 / \ (dport) 22 4433 Policy C5 is correlated with all the policies currently in U, so 4434 T = U. First we choose to decorrelate the protocol selector. The 4435 policies in $T$ have the values ``UDP'' and ``TCP'' for this selector, 4436 so we create a branch for each of them and a branch for the complement 4437 of their union. 4439 We can stop processing the complement branch: 4440 199.93/16 199.100.2/24 ~UDP,~TCP * * * * 4441 since it is decorrelated with T. This policy will be added to 4442 the decorrelated set. 4444 The "UDP" and "TCP" branches still require more processing since they 4445 are both still correlated with policies in U. We will start by 4446 processing the "UDP" branch. The policy through this branch is 4447 correlated with policies U3 and U4, so T = {U3, U4}. We choose to 4448 decorrelate on the user selector. The policies in T have "lsanchez" 4449 and "~lsanchez" as their values for this selector so we create 4450 branches for "lsanchez" and "~lsanchez." The compliment branch is 4451 redundant to these branches. 4453 We can stop processing the "lsanchez" branch: 4454 199.93/16 199.100.2/24 UDP * * lsanchez * 4455 since it is overridden by policy U3. 4457 The "~lsanchez" branch, however, requires more processing since it is 4458 correlated with policy U4 (T = {U4}). We choose to decorrelate on the 4459 dport selector. The policy in T has "52" as its value for this 4460 selector so we create a "52" branch and a branch for its compliment 4461 "~52". 4463 We can stop processing the complement branch: 4464 199.93/16 199.100.2/24 UDP * ~52 ~lsanchez * 4465 since it is decorrelated with T. This policy will be added to 4466 the decorrelated set. 4468 We can also stop processing the "52" branch: 4469 199.93/16 199.100.2/24 UDP * 52 ~lsanchez * 4470 since it is overridden by U4. 4472 Now we need to go back and process the "TCP" branch. The policy 4473 through this branch is correlated with policies U1 and U2, so T = {U1, 4474 U2}. We choose to decorrelate on the user selector. The policies in 4475 T have "lsanchez" as their values for this selector so we create 4476 branches for "lsanchez" and its compliment, "~lsanchez." 4478 We can stop processing the complement branch: 4479 199.93/16 199.100.2/24 TCP * * ~lsanchez * 4480 since it is decorrelated with T. This policy will be added to 4481 the decorrelated set. 4483 The "~lsanchez" branch, however, requires more processing since it is 4484 correlated with both policies in T. We choose to decorrelate on the 4485 sec label selector. The policies in T have "sec" and "conf" as their 4486 values for this selector so we create branches "sec", "conf", and the 4487 complement of their union, "~sec,~conf" 4489 We can stop processing the complement branch: 4490 199.93/16 199.100.2/24 TCP * * lsanchez ~sec,~conf 4491 since it is decorrelated with T. This policy will be added to 4492 the decorrelated set. 4494 We can stop processing the "conf" branch: 4495 199.93/16 199.100.2/24 TCP * * lsanchez conf 4496 since it is overridden by policy U2. 4498 The "sec" branch, however, requires more processing since it is 4499 correlated with policy U1 (T = U1). We choose to decorrelate on the 4500 dport selector. The policy in T has "22" as its value for this 4501 selector so we create a "22" branch and a "~22" branch for its 4502 compliment. 4504 We can stop processing the complement branch: 4505 199.93/16 199.100.2/24 TCP * ~22 lsanchez sec 4506 since it is decorrelated with T. This policy will be added to 4507 the decorrelated set. 4509 We can stop processing the "22" branch: 4510 199.93/16 199.100.2/24 TCP * 22 lsanchez sec 4511 since it is overridden by policy U1. 4513 The decorrelated policy set after decorrelating C5 is: 4514 U1 199.93/16 199.100.2/24 TCP * 22 lsanchez sec 4515 U2 199.93/16 199.100.2/24 TCP * * lsanchez conf 4516 U3 199.93/16 199.100.2/24 UDP * * lsanchez * 4517 U4 199.93/16 199.100.2/24 UDP * 52 ~lsanchez * 4519 U5 199.93/16 199.100.2/24 ~UDP,~TCP * * * * 4520 U6 199.93/16 199.100.2/24 UDP * ~52 ~lsanchez * 4521 U7 199.93/16 199.100.2/24 TCP * * ~lsanchez * 4522 U8 199.93/16 199.100.2/24 TCP * * lsanchez ~sec,~conf 4523 U9 199.93/16 199.100.2/24 TCP * ~22 lsanchez sec 4525 C.2.6 policy C6 4527 Finally, we look at policy C6: 4529 src dst prot sport dport user sec level 4530 C6: * * * * * * * 4532 T = U o 4533 /| 4534 ~199.93/16 / | (src) 199.93/16 4535 T = U o 4536 /| 4537 ~199.100.2/24 / | (dst) 199.100.2/24 4539 Policy C6 is correlated with all the policies currently in U, so 4540 T = U. First we choose to decorrelate the src selector. The 4541 policies in $T$ have the value "199.93/16" for this selector, 4542 so we create a branch for "199.93/16" and one for its compliment, 4543 "~199.93/16". 4545 We can stop processing the complement branch: 4546 ~199.93/16 * * * * * * 4547 since it is decorrelated with all the policies in T. This policy will 4548 be added to the decorrelated set. 4550 The "199.93/16" branch, however, requires more processing since it is 4551 correlated with all the policies in T. We choose to decorrelate on the 4552 dst selector. The policies in T have "199.100.2/24" as their value 4553 for this selector so we create a "199.100.2/24" branch and a 4554 "~199.100.2/24" branch for its compliment. 4556 We can stop processing the complement branch: 4557 199.93/16 ~199.100.2/24 * * * * * 4558 since it is decorrelated with all the policies in T. This policy will 4559 be added to the decorrelated set. 4561 We can stop processing the "199.100.2/24" branch: 4562 199.93/16 199.100.2/24 * * * * * 4563 since it is overridden by policy C5. 4565 The full decorrelated version of C is: 4566 U1 199.93/16 199.100.2/24 TCP * 22 lsanchez sec 4567 U2 199.93/16 199.100.2/24 TCP * * lsanchez conf 4568 U3 199.93/16 199.100.2/24 UDP * * lsanchez * 4569 U4 199.93/16 199.100.2/24 UDP * 52 ~lsanchez * 4571 U5 199.93/16 199.100.2/24 ~UDP,~TCP * * * * 4572 U6 199.93/16 199.100.2/24 UDP * ~52 ~lsanchez * 4573 U7 199.93/16 199.100.2/24 TCP * * ~lsanchez * 4574 U8 199.93/16 199.100.2/24 TCP * * lsanchez ~sec,~conf 4575 U9 199.93/16 199.100.2/24 TCP * ~22 lsanchez sec 4577 U10 199.93/16 ~199.100.2/24 * * * * * 4578 U11 ~199.93/16 * * * * * * 4579 Disclaimer 4581 The views and specification here are those of the authors and are 4582 not necessarily those of their employers. The authors and their 4583 employers specifically disclaim responsibility for any problems 4584 arising from correct or incorrect implementation or use of this 4585 specification. 4587 Copyright (C) The Internet Society (2000). All 4588 Rights Reserved. 4590 This document and translations of it may be copied and furnished 4591 to others, and derivative works that comment on or otherwise 4592 explain it or assist in its implementation may be prepared, copied, 4593 published and distributed, in whole or in part, without 4594 restriction of any kind, provided that the above copyright notice 4595 and this paragraph are included on all such copies and derivative 4596 works. However, this document itself may not be modified in any 4597 way, such as by removing the copyright notice or references to the 4598 Internet Society or other Internet organizations, except as needed 4599 for the purpose of developing Internet standards in which case the 4600 procedures for copyrights defined in the Internet Standards 4601 process must be followed, or as required to translate it into 4602 languages other than English. The limited permissions granted above 4603 are perpetual and will not be revoked by the Internet Society or 4604 its successors or assigns. 4606 This document and the information contained herein is provided on 4607 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 4608 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 4609 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 4610 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 4611 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 4613 Author Information 4615 Luis A. Sanchez Matthew N. Condell 4616 Megisto Systems BBN Technologies 4617 10 Moulton Street 4618 Cambridge, MA 02138 4619 USA USA 4620 Email: lsanchez@megisto.com Email: mcondell@bbn.com 4621 Telephone: Telephone: +1 (617) 873-6203