idnits 2.17.1 draft-ietf-ipsec-spp-00.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 == The page length should not exceed 58 lines per page, but there was 9 longer pages, the longest (page 14) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 75 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 4 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 2006 has weird spacing: '...age and the e...' == 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: R Raw policy flag. When this flag is set, policy servers MUST not resolve the policies that they return. == 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 'SHOULD not' in this paragraph: This octet indicates if ESP is to be used and in what mode. NOT REQUIRED means that ESP is not necessary but if used it MUST be negotiated based on the parameters defined below. TUNNEL_MODE or TRANSP_MODE means that ESP MUST be negotiatiated in this mode. ANY_MODE means that ESP MUST be negotited and that any mode (Tunnel or transport) will suffice. NOT ALLOWED means that ESP SHOULD not be negotiated and it MUST not be part of this SA. == 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 'SHOULD 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. == 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: IPCOMP This field indicates if IP Compression is to be used. NOT REQUIRED means that IPCOMP is not necessary but if used it MUST be negotiated based on the parameters defined below. REQUIRED means that IPCOMP MUST be negotiated as part of this SA. NOT ALLOWED means that IPCOMP 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 (July 1, 1999) is 9059 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 2236, but no explicit reference was found in the text == Unused Reference: 'RFC1035' is defined on line 2243, but no explicit reference was found in the text == Unused Reference: 'PKIXP1' is defined on line 2250, but no explicit reference was found in the text == Unused Reference: 'SPSL' is defined on line 2261, 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) ** 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: Non-RFC (?) normative reference: 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: 10 errors (**), 0 flaws (~~), 14 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft L.A. Sanchez, BBN 2 draft-ietf-ipsec-spp-00.txt M.N. Condell, BBN 3 Expires January, 2000 July 1, 1999 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. 28 Abstract 30 This document describes a protocol for discovering, accessing and 31 processing security policy information of hosts, subnets or networks 32 of a security domain. The Security Policy Protocol defines how the 33 policy information is exchanged, processed, and protected by clients 34 and servers. The protocol is extensible and flexible. It allows the 35 exchange of complex policy objects between clients and servers. 37 Table of Contents 39 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 40 1.1 Definitions. . . . . . . . . . . . . . . . . . . . . . . . 4 41 1.2 Policies . . . . . . . . . . . . . . . . . . . . . . . . . 5 43 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 45 3. SPP Message. . . . . . . . . . . . . . . . . . . . . . . . . . 7 46 3.1 SPP Message Format . . . . . . . . . . . . . . . . . . . . 8 47 3.2 SPP Payloads . . . . . . . . . . . . . . . . . . . . . . . 11 48 3.2.1 Query Payload. . . . . . . . . . . . . . . . . . . . . 11 49 3.2.2 Record Payload . . . . . . . . . . . . . . . . . . . . 12 50 3.2.3 Signature Payload. . . . . . . . . . . . . . . . . . . 13 51 3.3 SPP Messages . . . . . . . . . . . . . . . . . . . . . . . 14 52 3.3.1 Query Messages . . . . . . . . . . . . . . . . . . . . 14 53 3.3.2 Reply Messages . . . . . . . . . . . . . . . . . . . . 14 54 3.3.3 Policy Messages. . . . . . . . . . . . . . . . . . . . 15 55 3.3.4 Policy Acknowledgment Messages . . . . . . . . . . . . 15 56 3.3.5 Transfer Messages. . . . . . . . . . . . . . . . . . . 15 57 3.3.6 KeepAlive Messages . . . . . . . . . . . . . . . . . . 15 59 4. Policy Queries . . . . . . . . . . . . . . . . . . . . . . . . 16 60 4.1 Security Gateway Query . . . . . . . . . . . . . . . . . . 16 61 4.2 COMSEC Query . . . . . . . . . . . . . . . . . . . . . . . 16 62 4.3 Certificate Query. . . . . . . . . . . . . . . . . . . . . 17 64 5. Policy Records . . . . . . . . . . . . . . . . . . . . . . . . 19 65 5.1 Security Gateway Record. . . . . . . . . . . . . . . . . . 19 66 5.2 COMSEC Record. . . . . . . . . . . . . . . . . . . . . . . 20 67 5.3 Security Association Record. . . . . . . . . . . . . . . . 22 68 5.4 Policy Server Record . . . . . . . . . . . . . . . . . . . 23 69 5.5 Certificate Record . . . . . . . . . . . . . . . . . . . . 25 71 6. Transfer Records . . . . . . . . . . . . . . . . . . . . . . . 25 73 7. Policy Attribute Encoding. . . . . . . . . . . . . . . . . . . 26 75 8. SPP Message Processing . . . . . . . . . . . . . . . . . . . . 28 76 8.1 General Message Processing . . . . . . . . . . . . . . . . 28 77 8.2 Query Message Processing . . . . . . . . . . . . . . . . . 28 78 8.3 Reply Message Processing . . . . . . . . . . . . . . . . . 32 79 8.4 Policy Message Processing. . . . . . . . . . . . . . . . . 35 80 8.5 Policy Acknowledgment Message Processing . . . . . . . . . 37 81 8.6 Transfer Message Processing. . . . . . . . . . . . . . . . 38 82 8.7 KeepAlive Message Processing . . . . . . . . . . . . . . . 40 84 9. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 41 85 9.1 Message Type . . . . . . . . . . . . . . . . . . . . . . . 41 86 9.2 Message Code . . . . . . . . . . . . . . . . . . . . . . . 41 87 9.3 Identity Type. . . . . . . . . . . . . . . . . . . . . . . 41 88 9.4 Payload Class. . . . . . . . . . . . . . . . . . . . . . . 42 89 9.5 Query Type . . . . . . . . . . . . . . . . . . . . . . . . 42 90 9.6 Record Type. . . . . . . . . . . . . . . . . . . . . . . . 42 91 9.7 Signature Type . . . . . . . . . . . . . . . . . . . . . . 42 92 9.8 Certificate Type . . . . . . . . . . . . . . . . . . . . . 42 93 9.9 Certificate Identity Type. . . . . . . . . . . . . . . . . 42 94 9.10 Attribute Data Type . . . . . . . . . . . . . . . . . . . 43 95 9.11 User Name Type. . . . . . . . . . . . . . . . . . . . . . 43 96 9.12 System Name Type. . . . . . . . . . . . . . . . . . . . . 43 97 9.13 IPsec Action Attribute. . . . . . . . . . . . . . . . . . 43 98 9.14 IKE Action Attribute. . . . . . . . . . . . . . . . . . . 43 100 10. Security Considerations. . . . . . . . . . . . . . . . . . . . 44 102 Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . . . 44 104 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 106 Appendix A. DATA_TYPE Definitions. . . . . . . . . . . . . . . . . 46 108 Appendix B. An SPP Example . . . . . . . . . . . . . . . . . . . . 69 110 Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 112 Author Information . . . . . . . . . . . . . . . . . . . . . . . . 75 113 1. Introduction 115 The IPSec protocols [Kent98] provide a mechanism for securing 116 communications at the IP layer and IKE [Harkins98] can be used to 117 provide keys for IPSec. Currently practice with these protocols 118 maintains an assumption that communicating hosts have some a-priori 119 knowledge of which communications with particular newtwork entities 120 must be secured. While this assumption is valid in some environments 121 (e.g. some VPN environments), it does not support more general IPSec 122 senarios in a scalable manner. 124 In order to allow IPSec to scale in general cases, it is necessary 125 to be able to identify which entities involved in a communication 126 will require IPSec to protect the communication and what their 127 policies are regarding it. 129 The Security Policy Protocol (SPP) defines how the policy information 130 is exchanged, processed, and protected by clients and servers. The 131 protocol also defines what policy information is exchanged and the 132 format used to encode the information. The protocol specifies six 133 different message types used to exchange policy information. An SPP 134 message contains a message header section followed by zero or more SPP 135 payloads, depending on the message type. 137 SPP is part of the Security Policy System architecture [SPS]. This 138 document uses terms and references functionality described in [SPS]. 140 The remainder of this section defines terms and concepts that will 141 be used throughout this document. Section 2 provides and overview 142 of the protocol. The remainder of the document describes the 143 encoding of the protocol and how SPP messages are processed. 145 1.1 Definitions 147 The following terms are used throughout this document, in addition 148 to the terms defined in section [***] of [SPS]. 150 Authoritative 152 Host A is authoritative over host B if host A has the right to 153 represent policy for host B. Host A may assert its relationship 154 to host B using policy server records (section 5.4), but MUST be 155 able to cryptographically prove the assertion. 157 Transitively Authoritative 159 A host is transitively authoritative over another host, A, if it 160 is either authoritative over host A or authoritative over a host, 161 B, which is trasitively athoritative over host A. For example, 162 if host X is authoritative for host Y and host Y is authoritative 163 for host Z, then host X is transitively authoritative for host Z. 165 Chain of Trust 167 A chain of trust is a set of cryptographically-proven authoritative 168 assertions that prove that a policy server is transitively 169 authoritative over the source or destination of a communication. 170 The chain of trust is used to prove that a policy server has 171 a right to be involved in an SPP exchange. See section 10 for 172 more about the chain of trust. 174 Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and 175 "MAY" that appear in this document are to be interpreted as described 176 in [Bra97]. 178 1.2 Policies 180 Defining and storing policies are beyond the scope if this document. 181 However, this section describes SPP's policy requirements and a 182 brief high-level look at its representation. 184 Policy Representation 186 SPP provides both the comsec record (section 5.2) and the Security 187 Association (SA rec) record (section 5.3) to describe policies. The 188 comsec record defines the selectors that describe a communication 189 along with a permit or deny action. The SA rec defines the actions, 190 specifically the IPSec and IKE security associations, necessary for 191 the communication to proceed. A policy transferred by SPP, therefore, 192 MUST consist of one comsec record to describe the selectors of the 193 communication and zero or more SA recs which describe the security 194 associations that are required to complete the communication. 196 Decorrelation 198 Policies exchanged using SPP MUST be decorrelated as described in 199 [SPS]. Two policies are decorrelated if there exists at least one 200 selector in both policies for which their values do not intersect. 201 Decorrelation is necessary to permit policy servers to properly 202 cache policies. 204 2. Overview 206 This section provides an overview of the SPP operation. A more 207 detailed and complex example of SPP operation is available in appendix 208 B. This overview assumes the policy servers have been loaded with 209 policies for their security domains and the policy has been 210 appropriately decorrelated (as specified in [SPS]). 212 Security Security 213 Domain Foo Domain Foo 215 +----------+ +----------+ 216 | Policy | | Policy | 217 | Server A | | Server B | 218 +----------+ +----------+ 219 ^ ^ ^ ^ 220 +---------+ Q1 | | Q2 /\ /\ Q2 | | Q3 +----------+ 221 | Host | R1 | | R2 / \ Q2/R2 / \ R2 | | R3 | Host | 222 | A |<--- -----><------><--- ---->| B | 223 +---------+ \ / \ / +----------+ 224 \/ \/ 226 Figure 1: Overview of SPP operation 228 Host A, wanting to communicate with Host B, invokes its policy client. 229 Host A's client sends a Query (Q1) to its configured local policy 230 server, Policy Server A. Policy Server A looks in its cache for a 231 policy record that matches the query. If it doesn't find one, it sends 232 a Query (Q2) containing the same policy request information to Host B. 233 Q2 is sent to Host B since Policy Server A may not know about the 234 existence of SGB or Policy Server B. This message includes a signature 235 that validates the authenticity and integrity of the query's content. 237 (Q2) is intercepted by SGB. SGB forwards the message (Q2) to Policy 238 Server B. Policy server B verifies that it can accept queries from 239 Policy Server A and validates the signature in Q2. It searches its 240 database for the appropriate policy information after verifying that 241 it is authoritative over Policy Client B. 243 Policy Server B merges its local policy with the policy information in 244 (Q2) and it sends a Reply (R2) to Policy Server A. The reply includes 245 the original query information and all policy information needed to 246 allow Policy Client A to establish a secure communication with Host 247 B. Policy Server B also attaches additional information to the reply 248 asserting its authority over Host B. 250 When Policy Server A receives the reply (R2) from Policy Server A, it 251 validates the signature in R2 and cryptographically verifies that 252 Policy Server B is authoritative over Host B. It then merges is local 253 policy with the policy information in (R2) and sends a Reply (R1) to 254 Host A. Policy Server A caches the merged policy to use when 255 answering future queries. Host A may then use this information to 256 establish necessary security associations with Host B. 258 If, however, Policy Server B is not authoritative over Host B, it 259 would query Host B for its policy with respect to this particular 260 communication. Policy Server B would generate a third query (Q3). Host 261 B would respond with its policy in (R3). Policy Server B merges its 262 policy for this communication and the policy in (R3) before replying 263 to Policy Server A. Policy Server A processes the reply as it did 264 above. 266 SPP accommodates topology changes, hence policy changes, rather easily 267 without the scalability constraints imposed by static reconfiguration 268 of each client. The protocol is extensible and flexible It allows the 269 exchange of complex policy objects between clients and servers. 271 3. SPP Message 273 The SPP header is present in every message. It contains fields 274 identifying the message, the type of message, the status of the 275 message, the number of queries and/or record payloads, and the host 276 requesting policy information. The header also includes a timestamp 277 field that provides anti-replay protection. Following the header there 278 might be zero or more SPP payloads. Currently, there are three payload 279 types defined in SPP: Query, Record, and Signature payloads. See 280 section 3.2 for encoding details. 282 SPP has six distinct message types. Query messages contain a specific 283 request for policy information. Reply messages include policy records 284 that answer specific policy queries. Policy messages include policy 285 information and are utilized for up/downloading security policies to 286 and from a policy server. Policy Acknowledgment messages are utilized 287 to acknowledge corresponding Policy messages but do not themselves 288 contain policy information. Transfer messages, which include policy 289 information, are utilized by policy servers to exchange bulk policy 290 information between servers. Finally, policy servers use keep alive 291 messages to inform security gateways and/or other monitoring devices 292 of the status of the server. 294 SPP messages MUST be authenticated either using IPSec [Kent98] or 295 another security mechanism. SPP provides a basic security mechanism 296 that can be used to provide authentication and integrity to its 297 messages when other security mechanisms are not in use. The SPP 298 authentication is especially useful when traversing heterogenous 299 domains and the identity of the policy server authoritative for the 300 destination is unknown. These services are provided using digital 301 signatures. 303 SPP caries signatures in the signature payload. The signature is 304 calculated over the entire SPP message. When this service is used, the 305 entity (host, policy server, or security gateway) verifying the 306 signature must have access to the public key that corresponds to the 307 private key used to sign the SPP message. 309 Certificate fetching is out of the scope of SPP. However, SPP 310 provides a simple certificate fetching mechanism for entities that 311 elect to use it as an alternative to other mechanisms. SPP suports 312 several Public Key certificates formats. 314 SPP is modular and extensible (See section 9. for IANA 315 considerations). New policy queries and records can be defined and 316 incorporated easily. This document defines a minimum set of queries 317 and policy records required in a policy-based security management 318 system. 320 3.1 SPP Message Format 322 An SPP message follows the format depicted in figure 2. It is 323 comprised of a header and zero or more SPP payloads. This section 324 defines the encoding for the SPP header. Sections 3.2 and 3.3 cover 325 the encoding for the SPP payload and message types, respectively. 327 0 1 2 3 328 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 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----- 330 | MESSAGE ID | | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 332 | MTYPE | MCODE | QCOUNT | RCOUNT | | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 334 | IDENTITY TYPE |R|D|C|I|T| RSVD| RESERVED | | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 336 | | SPP 337 + TIMESTAMP + Header 338 | | | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 340 | | | 341 ~ SENDER IDENTITY ~ | 342 | | | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----- 344 | | SPP 345 + SPP PAYLOADS... |Payloads 346 | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----- 349 Figure 2: Format of an SPP Message 351 The SPP header includes the following fields: 353 MESSAGE ID 354 A 4 octet field used to match messages and their responses 355 (e.g. queries to replies and policy to policy acknowledgement 356 messages). This value starts at "zero" and MUST be incremented 357 by (1) with every new message. 359 MTYPE 360 A 1-octet field indicating the SPP message type. 361 The currently defined values are: 363 Message Type Value 365 Value Not Assigned 0 366 SPP-QUERY 1 367 SPP-REPLY 2 368 SPP-POL 3 369 SPP-POL_ACK 4 370 SPP-XFR 5 371 SPP-KEEP_ALIVE 6 373 values 7-250 are reserved to IANA. Values 251-255 are for 374 private use among mutually consenting parties. 376 MCODE 377 A 1-octet field providing information about this message. 378 All MTYPEs share a common MCODE space, although each message 379 type may not use all the defined message codes. See section 380 3.3 for the codes applicable to each message type. 382 Action Code 383 Type Field 385 Value Not Assigned 0 386 message accepted 1 387 denied, administratively prohibited 2 388 denied, timestamp failed 3 389 denied, failed signature 4 390 denied, insufficient resources 5 391 denied, malformed message 6 392 denied, unspecified 7 393 partially available 8 394 unavailable 9 395 communication prohibited 10 396 partially available, server unreachable 11 398 values 12-250 are reserved to IANA. Values 251-255 are for 399 private use among mutually consenting parties. 401 QCOUNT 402 A 1 octet field indicating the number of Query payloads included 403 in the message. 405 RCOUNT 406 A 1 octet field indicating the number of Record payloads 407 included in the message. 409 IDENTITY TYPE 410 This 1 octet field indicates the type of indentity found in 411 the Sender Identity field. Valid values are: 413 Identity Type Value 415 Value Not Assigned 0 416 IPV4_ADDR 1 417 IPV6_ADDR 2 418 Host DNS Name 3 420 values 4-250 are reserved to IANA. Values 251-255 are for 421 private use among mutually consenting parties. 423 R 424 Raw policy flag. When this flag is set, policy servers 425 MUST not resolve the policies that they return. 427 D 428 Domain flag. Only resolve the policies as far as the last 429 policy server that is transitively authoritative over the 430 host requesting the policy resolution. 432 C 433 Dont cache flag. Don't cache the policies generated by the 434 query. 436 I 437 Ignore cache flag. Ignore any cached policies when processing 438 the query. 440 T 441 No chain-of-trust. A client indicates to its server that it 442 does not need chain-of-trust information. Policy Servers 443 MUST NOT set this flag. Only Policy Clients have the option 444 to set it. 446 RSVD 447 A 4 bit field reserved for future use. 448 Set value to all zeros (0). 450 RESERVED 451 A 2 octet field used for field 32-bit boundary alignment and 452 reserved for future use. Set value to all zeros (0). 454 TIMESTAMP 455 This 8-octet field contains a timestamp used to provide 456 limited protection against replay attacks. The timestamp 457 is formatted as specified by the Network Time Protocol 458 [RFC1305]. 460 SENDER IDENTITY 461 A variable length field containing the identity of the sender 462 (host, security gateway, or policy server) of the SPP 463 message. The IDENTITY_TYPE field indicates the format of the 464 content in this field: 466 Identity Type Sender Identity 468 IPV4_ADDR An IPv4 Address 469 IPV6_ADDR An IPv6 Address 470 Host DNS Name A DNS name encoded as described 471 in [rfc1035] 473 This field does not allow IP address ranges or wildcards. 474 If this field is not aligned at the 4 octet boundary, the 475 field MUST be padded on the right with (00)hex to align on 476 the next 32-bit boundary. 478 3.2 SPP Payloads 480 3.2.1 Query Payload 482 The Query payload contains fields to express a particular request for 483 policy information. Hosts, security gateways, or policy servers can 484 generate and transmit Query payloads in SPP messages to policy 485 servers. Figure 3 shows the format of the Query payload. 487 0 1 2 3 488 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 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 | PCL | PID | RESERVED | 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | TYPE | LENGTH | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | QUERY Data ... 495 +-+-+-+-+-+-+-+- 497 Figure 3: Format of Query Payload 499 The Query Payload fields are defined as follows: 501 PCL 502 A 1 octet field indicating the payload class. Query payloads 503 MUST contain (1) in the PCL field. 505 PID 506 A 1 octet field containing the ID number that identifies a 507 particular Query payload within an SPP message. Since one 508 SPP message can contain multiple Query payloads, each one 509 MUST be uniquely identified. This number MUST be unique 510 among the Query payloads within an SPP message. 512 RESERVED 514 A 2 octet field reserved for future use. Set value to all 515 zeros (0). 517 TYPE 518 A 2 octet field that specifies the type of query contained in 519 the QUERY Data fields. The currently defined queries are: 521 Query Payload Type Value 523 Value Not Assigned 0 524 Security Gateway Query 1 525 Communication Security Query 2 526 Certificate Query 3 528 values 4-65000 are reserved to IANA. Values 65001-65535 are for 529 private use among mutually consenting parties. 531 LENGTH 532 A 2 octet field indicating the length in octets of the query 533 data field. 535 QUERY Data 537 A variable length field containing a single policy query. See 538 section 7 for encoding format. 540 3.2.2 Record Payload 542 The Record payload contains fields that assert policy information. 543 Hosts, security gateways, or policy servers can generate and transmit 544 Record payloads in SPP messages. Figure 4 shows the format of the 545 Record payload. 547 0 1 2 3 548 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 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 | PCL | PID | RESERVED | 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 | TYPE | LENGTH | 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 | RECORD Data ... 555 +-+-+-+-+-+-+-+- 557 Figure 4: Format of Record Payload 559 The Record Payload fields are defined as follows: 561 PCL 562 A 1 octet field indicating the payload class. Record payloads 563 MUST contain (2) in the PCL field. 565 PID 566 This field is used to match queries to Record payloads. If 567 the record is a reply to a query, then the value for this 568 field MUST match the correspondent Query payload PID. If it 569 is not a reply to a query, the value SHOULD be set to zero. 571 RESERVED 573 A 2 octet field reserved for future use. Set value to all 574 zeros (0). 576 TYPE 577 A 2 octet field that specifies the type of Record. The 578 currently defined records are: 580 Record Type Value 582 Value Not Assigned 0 583 Security Gateway Record 1 584 Communication Security Record 2 585 Security Association Record 3 586 Certificate Record 4 587 Policy Server Record 5 588 Transfer Record 6 590 values 7-65000 are reserved to IANA. Values 65001-65535 are for 591 private use among mutually consenting parties. 593 LENGTH 594 A 2 octet field indicating the length in octets of the RECORD 595 data field. 597 RECORD Data 599 A variable length field containing a single policy record. See 600 section 8 for encoding format. 602 3.2.3 Signature Payload 604 The Signature Payload contains data generated by the digital signature 605 function (selected by the originator), over the entire SPP message, 606 except for part of the Signature payload. This payload is used to 607 verify the integrity of the data in the SPP message. Figure 5 shows 608 the format of the Signature payload. 610 0 1 2 3 611 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 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 | PCL | TYPE | LENGTH | 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 | SIGNATURE Data ... 616 +-+-+-+-+-+-+-+- 618 Figure 5: Signature Payload Format 620 The Signature payload fields are defined as follows: 622 PCL 623 A 1 octet field indicating the payload class. Signature payloads 624 MUST contain (3) in the PCL field. 626 TYPE 627 A 1 octet field that specifies the signature algorithm 628 employed. The currently defined signature types are: 630 Algorithm Type Value 632 Value Not Assigned 0 633 RSA 1 634 DSA 2 636 values 3-250 are reserved to IANA. Values 251-255 are for 637 private use among mutually consenting parties. 639 LENGTH 640 A 2 octet field indicating the length in octets of the 641 SIGNATURE Data field. 643 SIGNATURE Data 645 A variable length field that contains the results from 646 applying the digital signature function to the entire 647 SPP message (including the PCL, TYPE, and LENGTH fields 648 of the Signature payload), except for the Signature Data 649 field of the Signature payload. 651 3.3 SPP Messages 653 3.3.1 Query Message 655 An SPP-QUERY message is comprised of an SPP header, one or more Query 656 payloads, zero or more Record payloads, and a Signature payload, if 657 one is required. Query messages MUST always contain a Query 658 payload. Record payloads may optionally be included to pass policy 659 information along with the query. If the Signature payload is employed 660 it MUST be the last payload in the message. The Query message MTYPE 661 value is (1). The MCODE field must be set to zero (0). 663 3.3.2 Reply Message 665 An SPP-REPLY message is comprised of an SPP header, one or more Query 666 payloads, zero or more Record payloads which answer the corresponding 667 Query payload, and a Signature payload, if one is required. Reply 668 messages MUST contain a Query payload. Reply messages MUST include a 669 Record payload unless the reply contains an MCODE of values 2-8. If 670 the Signature payload is employed it MUST be the last payload in the 671 message. The MTYPE value for a Reply message is (2). The following 672 MCODE values may be used for Reply messages: 674 Action Code 675 Type Field 677 Value Not Assigned 0 678 message accepted 1 679 denied, administratively prohibited 2 680 denied, timestamp failed 3 681 denied, failed signature 4 682 denied, insufficient resources 5 683 denied, malformed message 6 684 denied, unspecified 7 685 partially available 8 686 unavailable 9 687 communication prohibited 10 688 partially available, server unreachable 11 690 3.3.3 Policy Message 692 An SPP-POL message is comprised of an SPP header, one or more Record 693 payloads, and a Signature payload, if one is required. Policy messages 694 MUST NOT include Query payloads. If the Signature payload is employed 695 it MUST be the last payload in the message. The MTYPE value for a 696 Policy message is (3). The MCODE field must be set to zero (0). 698 3.3.4 Policy Acknowledgement Message 700 An SPP-POL_ACK message is comprised of an SPP header and a Signature 701 payload, if one is required. These messages MUST NOT contain Query or 702 Record payloads. The status of the associated Policy message is 703 expressed within the MCODE field. If the Signature payload is employed 704 it MUST be the only payload in the message. The MTYPE value for a 705 Policy Acknowledgement message is (4). The following MCODE values may 706 be used for Policy Acknowledgement messages: 708 Action Code 709 Type Field 711 Value Not Assigned 0 712 message accepted 1 713 denied, administratively prohibited 2 714 denied, timestamp failed 3 715 denied, failed signature 4 716 denied, insufficient resources 5 717 denied, malformed message 6 718 denied, unspecified 7 720 3.3.5 Transfer Message 722 An SPP-XFR message is comprised of an SPP header, one or more Record 723 payloads, and a Signature payload, if one is required. Transfer 724 messages MUST NOT include Query payloads. If the Signature payload is 725 employed it MUST be the last payload in the message. The MTYPE value 726 for a Transfer message is (5). The MCODE field must be set to zero 727 (0). 729 3.3.6 KeepAlive Message 731 An SPP-KEEP_ALIVE message is comprised of an SPP header and a 732 Signature payload, if one is required. These messages MUST NOT contain 733 Query or Record payloads. If the Signature payload is employed it MUST 734 be the only payload in the message. The MTYPE value for a KeepAlive 735 message is (6). The MCODE field must be set to zero (0). 737 4. Policy Queries 739 4.1 Security Gateway Query 741 This basic query provides a dynamic mechanism to determine which 742 relevant security gateways, both primary and backup, are in the path 743 to a particular destination address. Since the answer to a request for 744 information could depend on the identity of the requestor, the host 745 address of the source of the intended communicaton is included in the 746 query. Figure 6 shows the format of the Security Gateway Query. 748 0 1 2 3 749 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 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 | | 752 ~ SOURCE ADDRESS DATA ~ 753 | | 754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 755 | | 756 ~ DESTINATION ADDRESS DATA ~ 757 | | 758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 Figure 6: Security Gateway Query Format 762 The Security Gateway Query fields are defined as follows: 764 SOURCE ADDRESS DATA 766 This variable length field contains a single IP address 767 (unicast) either in IPv4 or IPv6 format. The encoding 768 format is specified in section 7. The acceptable DATA_TYPE 769 values are 3 and 9. 771 DESTINATION ADDRESS DATA 773 This variable length field contains a single IP address 774 (unicast) either in IPv4 or IPv6 format. The encoding 775 format is specified in section 7. The acceptable DATA_TYPE 776 values are 6 and 12. 778 4.2 COMSEC Query 780 The Communication Security Query (or COMSEC query) provides a dynamic 781 mechanism for a host or security gateway to inquire if a communication 782 having a particular set of characteristics is allowed. The 783 communication is described in terms of source and destination 784 addresses, protocols, source port, destination port, and other 785 parameters as defined in section 7. These parameters are known as 786 selectors in the IPSec context and are primarily the contents of the 787 IP, TCP, and UDP headers. Figure 7 shows the format of the COMSEC 788 Query. 790 0 1 2 3 791 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 792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 793 | | 794 ~ SOURCE ADDRESS DATA ~ 795 | | 796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 797 | | 798 ~ DESTINATION ADDRESS DATA ~ 799 | | 800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 801 | SELECTOR DATA ... 802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 804 Figure 7: COMSEC Query Format 806 The COMSEC Query fields are defined as follows: 808 SOURCE ADDRESS DATA 810 This variable length field contains a single IP address 811 (unicast) either in IPv4 or IPv6 format. The encoding 812 format is specified in section 7. The acceptable DATA_TYPE 813 values are 3 and 9. 815 DESTINATION ADDRESS DATA 817 This variable length field contains a single IP address 818 (unicast) either in IPv4 or IPv6 format. The encoding 819 format is specified in section 7. The acceptable DATA_TYPE 820 values are 6 and 12. 822 SELECTOR DATA 824 This includes one or more fields following the encoding format 825 specified in section 7. The acceptable DATA_TYPE values are 826 15-29, inclusive. 828 4.3 CERT Query 830 Mechanisms to dispatch and fetch public-key certificates are not part 831 of SPP. However, in the absence of external request/dispatch 832 mechanisms, SPP provides for a certificate request query that allows a 833 host, security gateway, or server to solicit a certificate. Figure 8 834 shows the format of the CERT Query. 836 0 1 2 3 837 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 838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 | CERT_TYPE | IDENTITY_TYPE | AUTHORITY_TYPE| RESERVED | 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 841 | | 842 ~ IDENTITY ~ 843 | | 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 845 | | 846 ~ CERTIFICATE AUTHORITY ~ 847 | | 848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 850 Figure 8: Certificate Query Format 852 The Certificate query fields are defined as follows: 854 CERT_TYPE 856 A 1 octet field that contains an encoding of the type of 857 certificate requested. Acceptable values are listed below: 859 Certificate Type Value 861 Value Not Assigned 0 862 PKCS #7 wrapped X.509 certificate 1 863 PGP Certificate 2 864 DNS Signed Key 3 865 X.509 Certificate - Signature 4 866 X.509 Certificate - Key Exchange 5 867 Kerberos Tokens 6 868 SPKI Certificate 7 870 values 8-250 are reserved to IANA. Values 251-255 are for 871 private use among mutually consenting parties. 873 IDENTITY_TYPE 875 This 1 octet field indicates the type of indentity found in 876 the Identity field. Valid values are listed below: 878 Value Identity Type 880 0 Value Not Assigned 881 1 IPV4_ADDR 882 2 IPV6_ADDR 883 3 DNS Name 884 4 X.500 Distinguished Name 886 values 5-250 are reserved to IANA. Values 251-255 are for 887 private use among mutually consenting parties. 889 AUTHORITY_TYPE 891 This 1 octet field indicates the type of authority found in 892 the Certificate Authority field. Valid values are the same as 893 IDENTITY_TYPE. 895 IDENTITY 897 This variable length field contains the identity of the 898 principal by which the certificate should be located. The 899 value MUST be of the type stated in IDENTITY_TYPE. 901 CERTIFICATE AUTHORITY 903 A variable length field containing an encoding of an 904 acceptable certificate authority for the type of certificate 905 requested. The value MUST be of the type stated in 906 AUTHORITY_TYPE. 908 5. Policy Records 910 5.1 Security Gateway Record 912 This record contains information that indicates the IP addresses of 913 the interfaces for the the primary and secondary security gateways 914 protecting a host or group of hosts. The record contains the primary 915 and secondary gateways at one point in the communication path between 916 the source and destination addresses listed in the Security Gateway 917 query. If the IP datagram must traverse multiple gateways, a Security 918 Gateway Record must be included for each gateway. The list of 919 secondary security gateways is optional. Figure 9 shows the format of 920 the Security Gateway Record. 922 0 1 2 3 923 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 924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 925 | CACHE-EXPIRY | 926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 927 | FLAGS | RESERVED | 928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 929 | | 930 ~ PRIMARY SG ADDRESS ~ 931 | | 932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 933 | SECONDARY SG ADDRESSES 934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 936 Figure 9: Security Gateway Record Format 938 The Security Gateway Record fields are defined as follows: 940 CACHE-EXPIRY 942 A 4 octet field indicating the maximum amount of time, 943 in seconds, this policy record MAY be cached. 945 FLAGS 947 A 2 octet field indicating different options to aid in 948 interpreting the security gateway data. If not in use, set 949 value to all zeros (00)hex. Currently, no flag values are 950 defined so this field MUST be set to (00)hex. 952 RESERVED 954 A 2 octet field reserved for future use. 955 Set value to all zeros (0). 957 PRIMARY SG ADDRESS 959 A variable length field containing the IP address of the primary 960 security gateway for protecting a particular host. This 961 variable length field contains a single unicast IP 962 address. The encoding format is specified in section 7. 963 The acceptable DATA_TYPE values are 1 and 2. 965 SECONDARY SG ADDRESSES 967 This variable length field contains the IP addresses of one or 968 more secondary security gateways protecting a particular host. 969 This field may contain a list of single unicast IP addresses. 970 The encoding format is specified in section 7. The acceptable 971 DATA_TYPE values are 1 and 2. 973 5.2 COMSEC Record 975 The COMSEC record indicates if a communication having a particular set 976 of characteristics is allowed or not. The communication is described 977 in terms of source and destination addresses, protocols, source ports, 978 destination ports, and other attributes defined in section 7. Figure 979 10 shows the format of the COMSEC Record. 981 0 1 2 3 982 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 983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 984 | CACHE-EXPIRY | 985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 986 | FLAGS | RESERVED | 987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 988 | | 989 ~ SOURCE ADDRESS DATA ~ 990 | | 991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 992 | | 993 ~ DESTINATION ADDRESS DATA ~ 994 | | 995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 996 | SELECTOR DATA ... 997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 999 Figure 10: COMSEC Record Format 1001 The COMSEC Record fields are defined as follows: 1003 CACHE-EXPIRY 1005 A 4 octet field indicating the maximum amount of time, 1006 in seconds, this policy record MAY be cached. 1008 FLAGS 1010 A 2 octet field indicating different options to aid in 1011 interpreting the selector data. If not in use, set 1012 value to all zeros (0). Currently, no flag values are 1013 defined so this field MUST be set to zero (0). 1015 RESERVED 1017 A 2 octet field reserved for future use. 1018 Set value to all zeros (0). 1020 SOURCE ADDRESS DATA 1022 This variable length field contains a single IP 1023 address (unicast, anycast, broadcast (IPv4 only), or multicast 1024 group), range of addresses (low and high values, inclusive), 1025 address + mask, or a wildcard address. The encoding format is 1026 specified in section 7. The acceptable DATA_TYPE values are 1027 3-5 and 9-11, inclusive. 1029 DESTINATION ADDRESS DATA 1031 This variable length field contains a single IP 1032 address (unicast, anycast, broadcast (IPv4 only), or multicast 1033 group), range of addresses (low and high values, inclusive), 1034 address + mask, or a wildcard address. The encoding format is 1035 specified in section 7. The acceptable DATA_TYPE values are 1036 6-8 and 12-14, inclusive. 1038 SELECTOR DATA 1040 This includes one or more fields following the encoding format 1041 specified in section 7. The acceptable DATA_TYPE values are 1042 15-29, inclusive. 1044 5.3 Security Association Record 1046 Security Association Records contain selectors and security 1047 association attributes (APPLIERS) that characterize a particular 1048 Security Association between the source and destination addresses 1049 listed in the record. This record contains data types as defined in 1050 the section 7. Figure 11 shows the format of the SA Record. 1052 0 1 2 3 1053 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 1054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1055 | CACHE-EXPIRY | 1056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1057 | FLAGS | RESERVED | 1058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1059 | | 1060 ~ SOURCE ADDRESS DATA ~ 1061 | | 1062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1063 | | 1064 ~ DESTINATION ADDRESS DATA ~ 1065 | | 1066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1067 | SELECTOR DATA AND APPLIERS... 1068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1070 Figure 11: SA Record Format 1072 The SA record fields are defined as follows: 1074 CACHE-EXPIRY 1076 A 4 octet field indicating the maximum amount of time, 1077 in seconds, this policy record MAY be cached. 1079 FLAGS 1081 A 2 octet field indicating different options to aid in 1082 interpreting the selector data. If not in use, set 1083 value to all zeros (0). Currently, no flag values are 1084 defined so this field MUST be set to zero(0). 1086 RESERVED 1088 A 2 octet field reserved for future use. 1089 Set value to all zeros (0). 1091 SOURCE ADDRESS DATA 1093 This variable length field contains a single IP 1094 address (unicast, anycast, broadcast (IPv4 only), or multicast 1095 group), range of addresses (low and high values, inclusive), 1096 address + mask, or a wildcard address. The encoding format is 1097 specified in section 7. The acceptable DATA_TYPE values are 1098 3-5 and 9-11, inclusive. 1100 DESTINATION ADDRESS DATA 1102 This variable length field contains a single IP 1103 address (unicast, anycast, broadcast (IPv4 only), or multicast 1104 group), range of addresses (low and high values, inclusive), 1105 address + mask, or a wildcard address. The encoding format is 1106 specified in section 7. The acceptable DATA_TYPE values are 1107 6-8 and 12-14, inclusive. 1109 SELECTOR DATA AND APPLIERS 1111 This includes one or more fields following the encoding format 1112 specified in section 7. The acceptable DATA_TYPE values are 1113 15-29 and 50-51, inclusive. 1115 5.4 Policy Server Record 1117 The Policy Server record indicates the host, security gateway, or 1118 policy server for which a particular policy server is 1119 authoritative. It represents an assertion, typically made by a policy 1120 server, with repect to a member of a security domain that the server 1121 represents. The record includes the Identity of the policy server and 1122 the identity of a node (host, security gateway, another server, etc.). 1123 Figure 12 shows the format of the Policy Server Record. 1125 0 1 2 3 1126 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 1127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1128 | CACHE-EXPIRY | 1129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1130 | FLAGS | RESERVED | 1131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1132 | | 1133 ~ POLICY SERVER IDENTITY ~ 1134 | | 1135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1136 | | 1137 ~ NODE IDENTITY ~ 1138 | | 1139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1141 Figure 12: Policy Server record format 1143 The Policy Server Record fields are defined as follows: 1145 CACHE-EXPIRY 1147 A 4 octet field indicating the maximum amount of time, 1148 in seconds, this policy record MAY be cached. 1150 FLAGS 1152 A 2 octet field indicating different options to aid in 1153 interpreting the server and node data. If not in use, set 1154 value to all zeros (0). Currently, no flag values are 1155 defined so this field MUST be set to zero (0). 1157 RESERVED 1159 A 2 octet field reserved for future use. 1160 Set value to all zeros (0). 1162 POLICY SERVER IDENTITY 1164 This variable length field contains the identity of the 1165 policy server. It may contain an IP address (unicast) 1166 either in IPv4 or IPv6 format. The encoding format is 1167 specified in section 7. The acceptable DATA_TYPE values 1168 are 1 and 2. 1170 NODE IDENTITY 1172 This variable length field contains the identity of a node 1173 for which the policy server is authoritative. It may contain 1174 an IP address (unicast) either in IPv4 or IPv6 format. The 1175 encoding format is specified in section 7. The acceptable 1176 DATA_TYPE values are 1 and 2. 1178 5.5 CERT Record 1180 The CERT record contains one public key certificate. This record is 1181 provided in SPP as an alternate mechanism for certificate 1182 dispatching. Figure 13 shows the format of the CERT Record. 1184 0 1 2 3 1185 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 1186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1187 | CACHE-EXPIRY | 1188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1189 | CERT_TYPE | | 1190 +-+-+-+-+-+-+-+-+ | 1191 ~ CERT_DATA ~ 1192 | | 1193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1195 Figure 13: Certificate Record Format 1197 CACHE-EXPIRY 1199 A 4 octet field indicating the maximum amount of time, 1200 in seconds, this policy record MAY be cached. 1202 CERT_TYPE 1204 This 1 octet field indicates the type of certificate or 1205 certificate-related information contained in the Certificate 1206 Data field. The values for this field are described in 1207 Section 4.3. 1209 CERT_DATA 1211 This variable length field contains the actual encoding of 1212 certificate data. The type of certificate is indicated by the 1213 Certificate Type field. 1215 6. Transfer Records 1217 This record contains the text of the master file that is used to 1218 configure the primary policy server. 1220 0 1 2 3 1221 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 1222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1223 | | 1224 ~ MASTER FILE TEXT ~ 1225 | | 1226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1228 Figure 14: Security Gateway Record Format 1230 The Transfer Record field is defined as follows: 1232 MASTER FILE TEXT 1234 This variable length field contains the text of the master 1235 file that is used to configure the policy server. 1237 7. Policy Attribute Encoding 1239 Query and Record payloads include several different selector types and 1240 SA attributes with their associated values. These data are encoded 1241 following a Type/Length/Value (TLV) format to provide flexibility for 1242 representing different kinds of data within a payload. Certain 1243 Data_Types with values of length equal to 2 octets follow the 1244 Type/Value (T/V) format. The first bit of the DATA_TYPE field is used 1245 to distinguished between the two formats. A value of (0) indicates a 1246 TLV format while a value of (1) indicates TV format. This generic 1247 encoding format is depicted in figure 15. 1249 X = 0: 1251 0 1 2 3 1252 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 1253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1254 |X| DATA_TYPE | LENGTH | 1255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1256 | DATA_VALUE... 1257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1259 X = 1: 1261 0 1 2 3 1262 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 1263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1264 |1| DATA_TYPE | DATA_VALUE | 1265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1267 Figure 15: Generic Data Attribute Formats 1269 The generic data attribute fields are defined as follows: 1271 X 1272 This bit indicates if the DATA_TYPE follows the TLV(0) or the 1273 TV(1) format. 1275 DATA_TYPE 1277 A 2 octet field indicating the selector type. The currently 1278 defined values are: 1280 DATA DATA_TYPE X 1282 IPV4_ADDR 1 0 1283 IPV6_ADDR 2 0 1284 SRC_IPV4_ADDR 3 0 1285 SRC_IPV4_ADDR_SUBNET 4 0 1286 SRC_IPV4_ADDR_RANGE 5 0 1287 DST_IPV4_ADDR 6 0 1288 DST_IPV4_ADDR_SUBNET 7 0 1289 DST_IPV4_ADDR_RANGE 8 0 1290 SRC_IPV6_ADDR 9 0 1291 SRC_IPV6_ADDR_SUBNET 10 0 1292 SRC_IPV6_ADDR_RANGE 11 0 1293 DST_IPV6_ADDR 12 0 1294 DST_IPV6_ADDR_SUBNET 13 0 1295 DST_IPV6_ADDR_RANGE 14 0 1296 DIRECTION 15 1 1297 USER_NAME 16 0 1298 SYSTEM_NAME 17 0 1299 XPORT_PROTOCOL 18 0 1300 SRC_PORT 19 0 1301 SRC_PORT_DYNAMIC 20 0 1302 DST_PORT 21 0 1303 DST_PORT_DYNAMIC 22 0 1304 SEC_LABELS 23 0 1305 V6CLASS 24 1 1306 V6FLOW 25 0 1307 V4TOS 26 1 1308 ACTION 27 1 1309 SRC_PORT_RANGE 28 0 1310 DST_PORT_RANGE 29 0 1312 IPSEC_ACTION 50 0 1313 ISAKMP_ACTION 51 0 1315 values 30-49 and 52-3200 are reserved to IANA. Values 1316 3200-32767 are for private use among mutually consenting 1317 parties. 1319 LENGTH 1321 A 2 octet field indicating the length of the selector value in 1322 octets, not including any trailing padding added to the 1323 DATA_VALUE field. The padding length is implicit. 1325 DATA_VALUE 1327 A variable length field containing the value of the selector 1328 specified by DATA_TYPE. If the Selector value is not aligned at 1329 the 4 octet boundary the field MUST be padded on the right with 1330 (00)hex to align on the next 32-bit boundary. 1332 8. SPP Message Processing 1334 SPP messages use UDP or TCP as their transport protocol. Messages 1335 carried by UDP are restricted to 512 bytes (not counting the IP or UDP 1336 headers). Fragmentation is allowed for messages containing more than 1337 512 bytes. The SPP-XFR message SHOULD use TCP to transfer the contents 1338 of the SPS Database from a primary to secondary policy server. SPP 1339 uses UDP and TCP ports 501. 1341 8.1 General Message processing 1343 For an SPP-Query or SPP-Pol message, the transmitting entity 1344 MUST do the following: 1346 1. Set a timer and initialize a retry counter. 1348 2. If an SPP-Reply or SPP-Pol_Ack message corresponding to the 1349 appropriate SPP-Query or SPP-Pol message is received within the 1350 time interval, or before the retry counter reaches 0, the 1351 transmitting entity continues normal operation. 1353 3. If an SPP-Reply or SPP-Pol_Ack message corresponding to the 1354 appropriate SPP-Query or SPP-Pol message is not received within 1355 the time interval and a secondary policy server, which has not 1356 been attempted on this value of the retry counter, is available, 1357 the message is sent to the secondary server. If all the 1358 secondary servers fail to respond within the time interval, 1359 decrement the retry counter and resend the message to the 1360 primary server. 1362 4. If the retry counter reaches zero (0) the event MAY be logged 1363 in the appropriate system audit file. 1365 5. Following step 4, processing is more specific: 1367 - For hosts and security gateways: 1369 o the transmitting entity will clear state for this peer and 1370 revert to using conventional security mechanisms. 1372 - For policy servers: 1374 o For SPP-Pol messages, clear state for this peer. 1376 o For SPP-Query messages, clear state for this peer, lookup 1377 policy in the server's SPS database and send an SPP-Reply 1378 message per section 8.3 with the policy and MCODE 11. 1380 8.2 Query Message (SPP-Query) Processing 1382 When creating a SPP-Query message, the entity (host, security gateway, 1383 or policy server) MUST do the following: 1385 1. Generate the Message ID value. This value starts at zero (0) and 1386 MUST be incremented by (1) with every new message. 1388 2. Set the value of the MTYPE field to 1 1390 3. Set the MCODE value to zero (0). 1392 4. Set the QCOUNT and RCOUNT fields. All fields MUST be 1393 set to zero (0) when their corresponding payloads do no exist. 1395 5. Set the flag bits accordingly and set the RESERVED field to 1396 zero (0). 1398 6. Set the IDENTITY_TYPE and IDENTITY of the Sender of the SPP 1399 message. 1401 7. Construct the SPP data payloads. A Query payload MUST be present 1402 in this message. 1404 8. Local policy information related to the query MAY be included as 1405 Record payloads following the Query payloads. 1407 9. A Policy Server record and a Cert Record SHOULD also be included 1408 in the message. A Cert record MUST be included if the query is 1409 a Cert Query to avoid a possible certificate query loop. 1411 10. Calculate and place the timestamp value used for anti-replay 1412 attack protection. 1414 11. If the Signature payload is required for message integrity and 1415 authentication, calculate a signature over the SPP header, SPP 1416 payloads, the PCL, TYPE, and LENGTH fields of the Signature 1417 payload. If required, the Signature payload MUST be the last 1418 payload in the message. 1420 When a policy server receives an SPP-Query message it MUST do the 1421 following: 1423 1. Check for SPP access control. If enabled, read the IP address in 1424 the Sender's field of the SPP header. 1426 - Verify whether or not the message is allowed. If the message 1427 is not allowed then: 1429 o send an SPP-Reply message with the MCODE 2 or 7 1430 o discard message and the event MAY be logged. 1432 - If the message is allowed, continue. 1434 2. Check timestamp field for anti-replay protection. If a replayed 1435 message is detected: 1437 - send an SPP-Reply message with the MCODE 3 or 7 1438 - discard message and the event MAY be logged. 1440 3. If the message requires signature validation. 1442 - If a certificate record is present, the server MUST process 1443 it, however, if the server already has a valid key for the 1444 host or server identified in the certificate, the certificate 1445 MAY be ignored. 1447 - Fetch certificate or key corresponding to the IP address 1448 found in the sender field of the SPP header. 1450 - If a certificate or key is not available the entity MAY, 1451 depending on configuration: 1453 o choose to abort validation process, send SPP-Reply message 1454 with MCODE 5 or 7, discard the message, and MAY log 1455 the event. 1457 o send an SPP-Query message to the source of the IP address 1458 found in the sender field of the SPP header with a CERT 1459 Query payload. Keep the SPP-Query message until the 1460 SPP-Reply returns. Extract certificate or key, validate it 1461 and proceed. 1463 - Once a validated certificate or key is available then validate 1464 signature. 1466 o If validation fails, send SPP-Reply message with MCODE 1467 5 or 7, discard the message, and the event MAY be logged. 1469 4. Parse the Query records. 1471 - If the SPP-Query message only contains cert queries: 1473 o If the Identity field identifies the server or a member of 1474 the server's security domain, send an SPP-Reply message per 1475 section 8.3 with one or more cert records with the 1476 certificates in the certification chain between the 1477 requested Identity and Certificate_Authority and MCODE 1. 1479 o Otherwise, send an SPP-Reply message per section 8.3 with 1480 with MCODE 9 or 7. 1482 - If the SPP-Query message does not only contain cert queries: 1484 o Check the Destination Address Data field to determine if 1485 the message received was intended for a node that is a 1486 member of the server's security domain. 1488 o Continue processing. 1490 5. If the message is for a node that is a member of the server's 1491 security domain or the D bit in the SPP header is set and the 1492 server is the outermost server that is authoritative over the 1493 client or server that sent the message, then: 1495 - Using src, dst, and any other applicable fields found in the 1496 Query Payload, search the SPS database for an appropriate 1497 policy. 1499 o If a policy is found then construct an SPP-Reply message per 1500 section 8.3 with appropriate payloads and MCODE 1. 1502 o If a policy is not found then construct an SPP-Reply message 1503 per section 8.3 with appropriate payloads and MCODE 9 or 7. 1505 6. If the message is for a node that is not part of the server's 1506 security domain then: 1508 - If the I and R bits are not set in the SPP header, check the 1509 Cache database for any relevant policies that apply to this 1510 communication. 1512 o If a policy is found then construct a SPP-Reply message per 1513 section 8.3 with appropriate payloads and MCODE 1. 1515 o If a policy is not found then continue. 1517 - Check the Local database for any relevant policies that apply 1518 to this communication. 1520 - If the server is authoritative for the source address of 1521 the query or a matching policy is found (A matching policy 1522 is defined as a policy that either produces a comsec record 1523 with an action attribute with the value "deny", or a policy 1524 that would produce an SA record with one or more IPSec action 1525 and IKE action attributes. A policy that only produces a 1526 comsec record with an action attribute with the value "permit" 1527 is not considered matching for this step.): 1529 o Generate a new SPP-Query message. The new message MUST use 1530 the same query payload as the old message. If the new 1531 query will include policy from the server, then the policy 1532 used SHOULD be the server's local policy merged with any 1533 policies received with the query message. The Sender Address 1534 will be the address of the server. The destination for this 1535 message MUST be the one in the original SPP-Query received. 1537 o Keep state. Upon reception of the corresponding SPP-Reply 1538 the policy server MUST send an SPP-Reply addressed to sender 1539 of the original SPP-Query. 1541 - If the server is not authoritative for the source address of 1542 the query and a matching policy is not found then: 1544 o The policy server MUST send the SPP-Query message unchanged. 1545 The SPP-Query message MUST use the same source port that was 1546 used to send it to the server so the next server that 1547 processes the query will return it to the correct port. 1548 This SPP-Query message MUST NOT be added to the retry queue 1549 (section 8.1). 1551 8.3 Reply Message (SPP-Reply) Processing 1553 When creating a SPP-Reply message, the policy server MUST do the 1554 following: 1556 1. Copy the Message ID value from the corresponding SPP-Query 1557 message into the Message ID field. 1559 2. Set the value of the MTYPE field to 2 1561 3. Set the MCODE value. 1563 4. Set the QCOUNT and RCOUNT fields. All fields MUST be 1564 set to zero (0) when their corresponding payloads do no exist. 1566 5. Set the flag bits accordingly and set the RESERVED field to (0). 1568 6. Set the IDENTITY_TYPE and IDENTITY of the Sender of the SPP 1569 message. 1571 7. Copy the Query payloads from the SPP-Query message to the 1572 SPP-Reply message. 1574 8. Construct the SPP data payload. Unless there is an error, at 1575 least one record corresponding to each Query payload MUST be 1576 present. 1578 9. A policy server record and a CERT record MUST be added to the 1579 SPP-Reply message if the the query to which this is a reply 1580 did NOT have the T bit set. If the T bit is set, the records 1581 SHOULD NOT be added. 1583 10. Calculate and place the timestamp value used for anti-replay 1584 attack protection. 1586 11. If the Signature payload is required for message integrity and 1587 authentication, calculate a signature over the SPP header, SPP 1588 payloads, the PCL, TYPE, and LENGTH fields of the Signature 1589 payload. If present, the Signature payload MUST be the last 1590 payload in the message. 1592 12. The SPP-Reply message is sent to the host that is listed in 1593 the Sender ID field of the SPP-Query to which this is a reply. 1595 When a host or security gateway receives an SPP-Reply message it MUST 1596 do the following: 1598 1. Read the Message ID field. If the value does not match the value 1599 of an outstanding SPP-Query message from a policy server then: 1600 - silently discard the message and the event MAY be logged. 1602 2. If Message ID matches, Check the timestamp field for anti-replay 1603 protection. If a replayed message is detected the message is 1604 silently discarded and the event MAY be logged. 1606 3. Establish if the message requires signature validation by 1607 searching for a Signature payload: 1608 - if signature validation is required proceed with step 4. 1609 - if signature validation is not required proceed with step 6. 1611 4. Validate the signature on the message. 1613 - If a certificate record is present, the server MUST process 1614 it, however, if the server already has a valid key for the 1615 host or server identified in the certificate, the certificate 1616 MAY be ignored. 1618 - Fetch certificate or key corresponding to the IP address 1619 found in the sender field of the SPP header. 1621 - If a certificate or key is not available the entity MAY: 1623 o choose, depending on configuration, to abort validation 1624 process, discard the message and MAY log the event. 1626 o send an SPP-Query message to the source of the IP address 1627 found in the sender field of the SPP header with a CERT 1628 query payload. Keep SPP-Reply message until the 1629 corresponding SPP-Reply returns. Extract certificate or 1630 key, validate it and proceed. 1632 5. Once a validated certificate or key is available then validate 1633 signature. 1635 If validation fails: 1636 - the message is silently discarded and the event MAY be logged 1638 If validation succeeds, continue processing. 1640 6. For Policy Servers, validate the chain of trust: 1642 - For each Policy Server record, verify that the Policy Server 1643 is authoritative over the Node. This may be done using 1644 information contained in certificates. 1646 - Use the Policy Server records to Create a chain of hosts from 1647 the destination host to this policy server where two records 1648 are linked if the Node in one is the Policy Server in another. 1650 - If the chain has no breaks, then this policy server MUST be 1651 authoritative over the sender of the reply, otherwise drop 1652 the message and stop processing it. 1654 - If the chain has one break, then the last policy server on 1655 the chain MUST be the sender of the reply, otherwise drop 1656 the message and stop processing it. 1658 - If the chain has two or more breaks, then there is an error 1659 in the chain so drop the message and stop processing it. 1661 - Verify that the Policy Server that is authoritative over the 1662 destination host is authoritative over ALL destination hosts 1663 in any comsec records. 1665 7. If MCODE value is 2-7, 9 or 10: 1667 For hosts or security gateways: 1668 - clear all the state and stop processing 1669 For policy servers: 1670 - create an SPP-Reply message using the same MCODE value. 1672 8. If the reply received correponds to a Cert query and the MCODE 1673 is either (1), (8) (accept or partially unavailable) 1674 process message that was held up waiting for the cert. 1676 9. For Policy Servers: 1678 - Search the Local Policy Database for a policy entry that 1679 matches the policy expressed in Query payload. 1681 - If the R bit is not set, merge the local and non-local policy 1682 information using the policy resolution proccess outlined in 1683 section [***] in [SPS]. 1685 - If the R bit is set, include both the policies found in the 1686 Local Policy Database and the policies in the reply to send 1687 in the new reply. 1689 - If the merge fails send an SPP-Reply message with MCODE 10 1690 or 7 and cache the failure. 1692 - If the merge succeeds or the R bit is set: 1694 o If the R and C bits are not set, cache policy information. 1695 This includes all Record payloads. 1696 o send an SPP-Reply message with the resulting policy records 1697 and MCODE 1. 1698 o If the R and D bits are not set and the merge indicated 1699 that policies should be sent to one or more security 1700 gateways, construct a signal for each gateway by creating 1701 an SPP-Pol message with the appropriate policy from the 1702 merge. 1704 10. For hosts or security gateways: 1706 - verify that the information in the Record payload corresponds 1707 to the information in the Query payload. 1708 - extract the records and create a policy entry in the SPD 1709 according to local format. The policy is entered in the SPD 1710 ONLY if local configuration allows. 1712 8.4 Policy Message (SPP-Pol) Processing 1714 When creating a SPP-Pol message, the entity (host, security gateway, or 1715 policy server) MUST do the following: 1717 1. Generate the Message ID value. This value starts at zero (0) and 1718 MUST be incremented by (1) with every new message. 1720 2. Set the value of the MTYPE field to 3. 1722 3. Set the MCODE value to zero (0). 1724 4. Set the RCOUNT field. The QCOUNT field MUST be set to zero (0) 1725 since no query payloads exist. 1727 5. Set the flag bits accordingly and set the RESERVED field to (0). 1729 6. Set the IDENTITY_TYPE and IDENTITY of the Sender of the SPP 1730 message. 1732 7. Construct the SPP data payloads. A Record payload MUST be 1733 present in this message. Query payloads MUST NOT be present. 1735 8. Calculate and place the timestamp value used for anti-replay 1736 attack protection. 1738 9. If the Signature payload is required for message integrity and 1739 authentication, calculate a signature over the SPP header, SPP 1740 payloads, the PCL, TYPE, and LENGTH fields of the Signature 1741 payload. If required, the Signature payload MUST be the 1742 last payload in the message. 1744 When a policy server receives an SPP-Pol message it MUST do the 1745 following: 1747 1. Check for SPP access control. If enabled, read the IP address in 1748 the Sender's field of the SPP header. 1750 - Verify whether or not the message is allowed. If the message 1751 is not allowed then: 1753 o send an SPP-Pol_Ack message with the MCODE 2 or 7 1754 o discard message and the event MAY be logged. 1756 - If the message is allowed, continue. 1758 2. Check timestamp field for anti-replay protection. If a replayed 1759 message is detected: 1761 - send an SPP-Pol_Ack message with the MCODE 3 or 7 1762 - discard message and the event MAY be logged. 1764 3. If the message requires signature validation. 1766 - If a certificate record is present, the server MUST process 1767 it, however, if the server already has a valid key for the 1768 host or server identified in the certificate, the certificate 1769 MAY be ignored. 1771 - Fetch certificate or key corresponding to the IP address 1772 found in the sender field of the SPP header. 1774 - If a certificate or key is not available the entity MAY, 1775 depending on configuration: 1777 o choose to abort validation process, send SPP-Pol_Ack 1778 message with MCODE 5 or 7, discard the message and MAY log 1779 the event. 1781 o send an SPP-Query message to the source of the IP address 1782 found in the sender field of the SPP header with a CERT 1783 Query payload. Keep SPP-Pol message until the SPP-Reply 1784 returns. Extract certificate or key, validate it and 1785 proceed. 1787 - Once a validated certificate or key is available then 1788 validate signature. 1790 o If validation fails the message is silently discarded and 1791 the event MAY be logged 1793 4. If signature was not required or upon successful validation of a 1794 signature parse the payloads. 1796 5. For hosts and security gateways: 1798 - extract the records and create a policy entry in the cache 1799 database. The policy MAY be entered in the SPD, also, ONLY 1800 if configuration allows. 1802 6. For Policy Servers: 1804 - extract the records, find corresponding policies in the 1805 server's SPS database, merge the two sets of policies, and 1806 create a policy entry in the cache database. 1808 7. Send an SPP-Pol_Ack message with MCODE 1. 1810 8.5 Policy Acknowledgement Message (SPP-Pol_Ack) Processing 1812 When creating a SPP-Pol_Ack message, the policy server MUST do the 1813 following: 1815 1. Copy the Message ID value from the corresponding SPP-Pol message 1816 into the Message ID field. 1818 2. Set the value of the MTYPE field to 4 1820 3. Set the MCODE value. 1822 4. Set the QCOUNT and RCOUNT fields. All fields MUST be 1823 set to zero (0). 1825 5. Set the flag bits accordingly and set the RESERVED field to (0). 1827 6. Set the IDENTITY_TYPE and IDENTITY of the Sender of the SPP 1828 message. 1830 7. Query or Record payloads MUST NOT be present. 1832 8. Calculate and place the timestamp value used for anti-replay 1833 attack protection. 1835 9. If the Signature payload is required for message integrity and 1836 authentication, calculate a signature over the SPP header, the 1837 PCL, TYPE, and LENGTH fields of the Signature payload. 1839 When a host, security gateway, or policy server receives an 1840 SPP-Pol_Ack message the entity MUST do the following: 1842 1. Read the Message ID field. If the value does not match the value 1843 of an outstanding SPP-Pol message from a policy server then: 1844 - silently discard the message and the event MAY be logged. 1846 2. If Message ID matches then check the timestamp field for 1847 anti-replay protection. If a replayed message is detected the 1848 message is silently discarded and the event MAY be logged. 1850 3. If the message is original (not replayed) and the message 1851 requires signature validation then: 1853 - If a certificate record is present, the server MUST process 1854 it, however, if the server already has a valid key for the 1855 host or server identified in the certificate, the certificate 1856 MAY be ignored. 1858 - Fetch certificate or key corresponding to the IP address 1859 found in the sender field of the SPP header. 1861 - If a certificate or key is not available the entity MAY: 1863 o choose, depending on configuration, to abort validation 1864 process, discard the message and MAY log the event. 1866 o send an SPP-Query message to the source of the IP address 1867 found in the sender field of the SPP header with a CERT 1868 Query payload. Keep SPP-Pol_ack message until the SPP-Reply 1869 returns. Extract certificate or key, validate it and 1870 proceed. 1872 4. Once a validated certificate or key is available then validate 1873 the signature. 1874 If validation fails: 1875 - the message is silently discarded and the event MAY be logged 1876 If validation succeeds: 1877 - read the MCODE field and proceed accordingly. If no errors, 1878 clear all the state for this message and proceed. 1880 8.6 Transfer Message (SPP-XFER) Processing 1882 When creating an SPP-Xfer message, the policy server MUST do the 1883 following: 1885 1. Generate the Message ID value. This value starts at zero (0) and 1886 MUST be incremented by (1) with every new message. 1888 2. Set the value of the MTYPE field to 5. 1890 3. Set the MCODE value to (0). 1892 4. Set the RCOUNT field. The QCOUNT field MUST be set to zero (0) 1893 since no query payloads exist. 1895 5. Set the flag bits accordingly and set the RESERVED field to 1896 zero (0). 1898 6. Set the IDENTITY_TYPE and IDENTITY of the Sender of the SPP 1899 message. 1901 7. Construct the SPP data payloads. A single Transfer Record MUST 1902 be present in this payload and MUST contain the master file 1903 used to configure this policy server. 1905 8. Calculate and place the timestamp value used for anti-replay 1906 attack protection. 1908 9. If the Signature payload is required for message integrity and 1909 authentication, calculate a signature over the SPP header, SPP 1910 payloads, the PCL, TYPE, and LENGTH fields of the Signature 1911 payload. If required, the Signature payload MUST be the last 1912 payload in the message. 1914 When a security gateway receives an SPP-Xfer message it MUST do the 1915 following: 1917 1. Check for SPP access control. If enabled, read the IP address in 1918 the Sender's field of the SPP header. 1920 - Verify whether or not the message is allowed. If the message 1921 is not allowed then: 1923 o discard message and the event MAY be logged. 1925 - If the message is allowed, continue. 1927 2. Check timestamp field for anti-replay protection. If a replayed 1928 message is detected: 1930 - discard message and the event MAY be logged. 1932 3. If the message requires signature validation. 1934 - If a certificate record is present, the server MUST process 1935 it, however, if the server already has a valid key for the 1936 host or server identified in the certificate, the certificate 1937 MAY be ignored. 1939 - Fetch certificate or key corresponding to the IP address 1940 found in the sender field of the SPP header. 1942 - If a certificate or key is not available the entity MAY, 1943 depending on configuration: 1945 o choose to discard the message, and MAY log the event. 1947 o send an SPP-Query message to the source of the IP address 1948 found in the sender field of the SPP header with a CERT 1949 Query payload. Keep the SPP-Query message until the 1950 SPP-Reply returns. Extract certificate or key, validate it 1951 and proceed. 1953 - Once a validated certificate or key is available then 1954 validate signature. 1956 o discard the message, and the event MAY be logged. 1958 4. If signature was not required or upon successful validation of a 1959 signature parse the payload. 1961 - extract the Transfer Record and save the master file that it 1962 contains. 1964 - Flush the contents of the SPS database, domain database, and 1965 cache. 1967 - Load the new information from the transferred master file into 1968 the databases. 1970 8.7 KeepAlive Message (SPP-KEEP_ALIVE) Processing 1972 When creating an SPP-Keep_Alive message, the policy server MUST do the 1973 following: 1975 1. Generate the Message ID value. This value starts at zero (0) and 1976 MUST be incremented by (1) with every new message. 1978 2. Set the value of the MTYPE field to 6. 1980 3. Set the MCODE value to zero (0). 1982 4. Set the QCOUNT and RCOUNT fields. All fields MUST be 1983 set to zero (0). 1985 5. Set the flag bits accordingly and set the RESERVED field to (0). 1987 6. Set the IDENTITY_TYPE and IDENTITY of the Sender of the SPP 1988 message. 1990 7. Query or Record payloads MUST NOT be present. 1992 8. Calculate and place the timestamp value used for anti-replay 1993 attack protection. 1995 9. If the Signature payload is required for message integrity and 1996 authentication, calculate a signature over the SPP header, the 1997 PCL, TYPE, and LENGTH fields of the Signature payload. 1999 When a host or security gateway receives an SPP-Keep_Alive message it 2000 MUST do the following: 2002 1. Check for SPP access control. If enabled, read the IP address in 2003 the Sender's field of the SPP header. 2005 - Verify whether or not the message is allowed. If the message 2006 is not allowed then discard message and the event MAY be 2007 logged. 2009 2. Check timestamp field for anti-replay protection. If a replayed 2010 message is detected discard message and the event MAY be logged. 2012 3. If the message requires signature validation then: 2014 - If a certificate record is present, the server MUST process 2015 it, however, if the server already has a valid key for the 2016 host or server identified in the certificate, the certificate 2017 MAY be ignored. 2019 - Fetch certificate or key corresponding to the IP address 2020 found in the sender field of the SPP header. 2022 - If a certificate or key is not available the entity MAY 2023 depending on configuration: 2025 o choose to abort validation process, discard the message and 2026 the event MAY be logged. 2028 o send an SPP-Query message to the source of the IP address 2029 found in the sender field of the SPP header with a CERT 2030 Query payload. Keep SPP-Keep_Alive message until the 2031 SPP-Reply returns. Extract certificate or key, validate it 2032 and proceed. 2034 - Once a validated certificate or key is available then 2035 validate signature. 2037 o If validation fails the message is silently discarded and 2038 the event MAY be logged 2040 4. If signature validation was not required or upon successful 2041 validation of a signature, the event MAY be logged. 2043 9. IANA Considerations 2045 This document contains many "magic numbers" to be maintained by the 2046 IANA. This section explains the criteria to be used by the IANA to 2047 assign numbers beyond the ones defined in this document. 2049 9.1 Message Type 2051 The MTYPE field of the SPP Header (section 3.1) defines message 2052 exchange types for SPP. Requests for assignment of new message type 2053 values 7-250 must be accompanied by a reference to a standards-track 2054 or Informational RFC which describes the new message type and how it 2055 should be processed. Values 251-255 are for private use. 2057 9.2 Message Code 2059 The MCODE field of the SPP Header (section 3.1) defines the acceptable 2060 return codes for an SPP message. Requests for assignment of new 2061 message code values 12-250 must be accompanied by a description of the 2062 conditions under which the code is returned. Values 251-255 are for 2063 private use. 2065 9.3 Identity Type 2067 The Identity Type field of the SPP Header (section 3.1) defines the 2068 acceptable formats for identifying the sender of an SPP message. 2069 Requests for assignment of new identity types 4-250 must be 2070 accompanied by a description of the format of the corresponding SENDER 2071 IDENTITY field in the header. Values 251-255 are for private use. 2073 9.4 Payload Class 2075 The first octect of each payload header (section 3.2) defines the type 2076 of payload that follows it. Requests for assignment of new message 2077 type values 4-250 must be accompanied by a reference to a 2078 standards-track or Informational RFC which describes the format of the 2079 payload's header and data. Values 251-255 are for private use. 2081 9.5 Query Type 2083 The query type (section 3.2.1) defines how the payload data will be 2084 interpreted and answered. Requests for assignment of new query type 2085 values 4-65000 must be accompanied by a reference to a standards-track 2086 or Informational RFC which describes the format of the data and how it 2087 should be used. Values 65001-65535 are for private use. 2089 9.6 Record Type 2091 The record type (section 3.2.2) defines how the payload data will be 2092 interpreted. Requests for assignment of new record type values 2093 4-65000 must be accompanied by a reference to a standards-track or 2094 Informational RFC which describes the format of the data and how it 2095 should be used. Values 65001-65535 are for private use. 2097 9.7 Signature Type 2099 The signature type (section 3.2.3) defines the signature algorithm 2100 used to sign the SPP message. Requests for assignment of new 2101 signature type values 3-250 must be accompanied by a reference to a 2102 standards-track or Informational RFC or a reference to published 2103 cryptographic literature which describes this algorithm. Values 2104 251-255 are for private use. 2106 9.8 Certificate Type 2108 The Cert Type field of the Certificate query and record (section 3.1) 2109 defines the type of certificate requested or included in the payload. 2110 Requests for assignment of new certificate types 8-250 must be 2111 accompanied by a description of certificate and its encoding. Values 2112 251-255 are for private use. 2114 9.9 Certificate Identity Type 2116 The Identity Type and Authority Type fields of the certificate query 2117 (section 4.3) define the acceptable formats for identifying the host 2118 and its certificate authority for which a certificate is requested. 2119 Requests for assignment of new certificate identity types 5-250 must 2120 be accompanied by a description of the format of the corresponding 2121 IDENTITY and CERTIFICATE AUTHORITY fields in the payload. Values 2122 251-255 are for private use. 2124 9.10 Attribute Data Type 2126 The Data_Type field of the attribute encoding (section 7) defines the 2127 type of attribute included in the data_value field. Requests for 2128 assignment of new attribute data types 30-49 and 52-3200 must be 2129 accompanied by a description of the X bit indicating if it is in TLV 2130 or TV format, a detailed description of the Data_Value field 2131 corresponding to the attribute type, and in which record and query 2132 data fields the type may be used. Values 3200-32767 are for private 2133 use. 2135 9.11 User Name Type 2137 The Name_Type field of the user name attribute (section A.16) defines 2138 the data in the Name field of the attribute. Requests for assignment 2139 of new user name types 2-250 must be accompanied by a description of 2140 the corresponding Name field. Values 251-255 are for private use. 2142 9.12 System Name Type 2144 The Name_Type field of the system name attribute (section A.17) 2145 defines the data in the Name field of the attribute. Requests for 2146 assignment of new system name types 9-249 must be accompanied by a 2147 description of the corresponding Name field. Values 251-255 are for 2148 private use. 2150 9.13 IPsec Action Attribute 2152 The assigned values of Lifetime_Type, Cipher_Alg, Int_Alg_Esp, 2153 Int_Alg_Ah, and Ipcomp_Alg use the values of their associated fields 2154 in [Piper98] and are updated when the IANA updates their values in 2155 [Piper98]. 2157 The Loc_Type field of the IPSec action attribute (section A.30) 2158 defines the type of location address in the Loc_Src and Loc_Dst 2159 fields. Requests for assignment of new location types 5-250 must be 2160 accompanied by a description of the corresponding Loc_Src and Loc_Dst 2161 field. Values 251-255 are for private use. 2163 The Loc_Src and Loc_Dst fields of the IPSec action attribute (section 2164 A.30) may define a general location type. Requests for assignment of 2165 new general location values 5-250 must be accompanied by a description 2166 of the general location type. Values 251-255 are for private use. 2168 9.14 IKE Action Attribute 2170 The assigned values of Group Description, Group_Type, Auth_Method, 2171 PRF, Lifetime_Type, Cipher_Alg, and Hash_Alg use the values of their 2172 associated fields in [Harkins98] and are updated when the IANA updates 2173 their values in [Harkins98]. 2175 The Mode field of the IKE action attribute (section A.31) defines the 2176 IKE Mode. Requests for assignment of new Modes 3-250 must only be 2177 done when new modes are added to the IKE protocol. Values 251-255 are 2178 for private use. 2180 10. Security Considerations 2182 All SPP messages MUST be authenticated to prove which policy server 2183 sent the message and that it hasn't been modified en-route. The 2184 authentication MAY be provided using the signature payload provided 2185 by SPP or some other mechanism such as IPSec. 2187 However, since the policy data may change during SPP exchanges, the 2188 messages cannot maintain a signature from every policy server that is 2189 involved in the policy exchange. SPP depends on a chain-of-trust for 2190 end-to-end authentication. Messages between policy servers are 2191 authenticated and contain policy server records and certificates which 2192 include proof that the server is authoritative over a set of nodes. 2193 The receiving server can use this information to create a chain of 2194 servers involved in the policy exchange from itself to the server 2195 authoritative over the destination of the query. This chain is used 2196 to prove that only servers that have authorization to be involved in 2197 the communication were involved. 2199 Policy information may be considered sensitive, since examining 2200 policies may expose expoitable weaknesses in the policies. The 2201 distribution of policies may be limited to reduce this risk. Policy 2202 distribution MAY be limited to those nodes that need to know the 2203 information. Limiting distribution any further negates the purpose of 2204 the protocol so is not allowed for proper use of SPP. 2206 Additional protections, such as privacy protection, may be desired 2207 by some domains. This can be achieved by encrypting SPP data. 2208 Encrypting SPP messages is out of scope of this document and may 2209 be discussed elsewhere. 2211 SPP uses timestamps to protect against replay attacks. This requires 2212 that nodes have adequately synchronized time-of-day clocks. It is 2213 necessary to choose an appropriately sized window of time in which 2214 timestamps may be accepted. If the window is too small, valid 2215 messages may be discarded. On the other hand, if the window is too 2216 large it may leave the server open to replay attacks. 2218 Acknowledgments 2220 The authors thank Charles Lynn, Steve Kent and John Zao for their 2221 participation in requirements discussions for the Security Policy 2222 System. Our gratitude to Charlie Lynn, Matt Fredette, Alden Jackson, 2223 Dave Mankins, Marla Shepard and Pam Helinek for the contributions to 2224 this document. We thank Joel Levin and Mary Hendrix (INS Corp.) for 2225 reviewing this document. We thank Isidro Castineyra for his 2226 contributions to the early parts of this work. 2228 References 2230 [Bra97] Bradner, S., "Key Words for use in RFCs to indicate 2231 Requirement Levels", RFC2119, March 1997. 2233 [Kent98] S. Kent, R. Atkinson, "Security Architecture for the 2234 Internet Protocol", RFC 2401, November 1998. 2236 [KA98b] S. Kent, R. Atkinson, "IP Encapsulating Security 2237 Payload (ESP)", RFC 2406, November 1998. 2239 [isakmp] D. Maughan, M. Schertler, M. Schneider, J. Turner, "Internet 2240 Security Association and Key Management Protocol (ISAKMP)", 2241 RFC 2408, November 1998. 2243 [RFC1035] Mockapetris, P., "Domain Names - Implementation and 2244 Specification", RFC 1035, November 1987. 2246 [RFC1305] Mills, D., "Network Time Protocol (Version 3): 2247 Specification, Implementation and Analysis", RFC 1305, March 2248 1992. 2250 [PKIXP1] R. Housley, W. Ford, W. Polk, D. Solo, "Internet Public 2251 Key Infrastructure: X.509 Certificate and CRL Profile". 2252 RFC 2459, January 1999. 2254 [Harkins98] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", 2255 RFC 2409, November 1998. 2257 [Piper98] D. Piper, "The Internet IP Security Domain of 2258 Interpretation for ISAKMP", RFC 2407, November 1998. 2260 [SPS] L. Sanchez, M. Condell "Security Policy System Architecture" 2261 [SPSL] M. Condell, C. Lynn, J. Zao "Security Policy Specification 2262 Language", Internet Draft draft-ietf-ipsp-spsl-00.txt, 2263 July 1999 2265 APPENDIX A 2267 DATA_TYPE Definitions 2269 The encoding of each selector and SA attribute is decribed here. 2270 Each attribute is described using the following set of data: 2272 X The value of the X bit in the attribute encoding. 2273 DATA_TYPE The value of the DATA_TYPE field in the attribute 2274 encoding. 2275 LENGTH The length of the data to use if X = 0. 2276 list 'yes' indicates the attribute may be used as a list 2277 as described below. 2278 DATA_VALUE Encoding of the DATA_VALUE field in the attribute 2279 encoding. 2281 Attributes generally encode "any" in one of two ways. If using 2282 the TLV format (X = 0) then the length is set to 0 to indicate any. 2283 If the TV format (X = 1) is used, then the value is set to 0; 2285 Attributes that may be expressed as lists provide the DATA_VALUE 2286 encoding for one element of the list. Multiple list elements may be 2287 expressed by concatenating multiple list elements. The LENGTH of 2288 attribute is the number of elements present times the length of one 2289 list element. Therefore, when reading an attribute that can be 2290 expressed as a list, the number of list elements may be determined by 2291 dividing the length by the size of a single list element. 2293 The remainder of this appendix describes the values and encoding for 2294 each selector and SA attribute specified in section 7. 2296 A.1 IPV4_ADDR 2298 X 0 2299 DATA_TYPE 1 2300 LENGTH 4 if an IP address is present, 2301 0 if no IP address is present. 2302 list No 2303 DATA_VALUE 2305 0 1 2 3 2306 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 2307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2308 | ADDRESS | 2309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2311 ADDRESS 2313 An IPV4 address 2315 A.2 IPV6_ADDR 2317 X 0 2318 DATA_TYPE 2 2319 LENGTH 16 if an IP address is present, 2320 0 if no IP address is present. 2321 list No 2322 DATA_VALUE 2324 0 1 2 3 2325 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 2326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2327 | | 2328 | | 2329 | ADDRESS | 2330 | | 2331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2333 ADDRESS 2335 An IPV6 address 2337 A.3 SRC_IPV4_ADDR 2339 X 0 2340 DATA_TYPE 3 2341 LENGTH 4 times the number of addresses in the list. 2342 A length of 0 indicates any address. 2343 list Yes 2344 DATA_VALUE 2346 0 1 2 3 2347 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 2348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2349 | SRC ADDRESS | 2350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2352 SRC ADDRESS 2354 An IPV4 address representing the source host of a 2355 communication 2357 A.4 SRC_IPV4_ADDR_SUBNET 2359 X 0 2360 DATA_TYPE 4 2361 LENGTH 8 times the number of subnets in the list. 2362 A length of 0 indicates any subnet. 2363 list Yes 2364 DATA_VALUE 2365 0 1 2 3 2366 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 2367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2368 | SUBNET ADDRESS | 2369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2370 | SUBNET MASK | 2371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2373 SUBNET ADDRESS 2375 An IPV4 address representing the source subnet of a 2376 communication 2378 SUBNET MASK 2380 An IPV4 address representing the source subnet mask of a 2381 communication 2383 A.5 SRC_IPV4_ADDR_RANGE 2385 X 0 2386 DATA_TYPE 5 2387 LENGTH 8 times the number of address ranges in the list. 2388 A length of 0 indicates any address. 2389 list Yes 2390 DATA_VALUE 2392 0 1 2 3 2393 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 2394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2395 | LOWER BOUND SRC ADDRESS | 2396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2397 | UPPER BOUND SRC ADDRESS | 2398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2400 LOWER BOUND SRC ADDRESS 2402 An IPV4 address representing the includsive lower-bound 2403 of a range of source addresses of a communication. 2405 UPPER BOUND SRC ADDRESS 2407 An IPV4 address representing the includsive upper-bound 2408 of a range of source addresses of a communication. 2410 A.6 DST_IPV4_ADDR 2412 X 0 2413 DATA_TYPE 6 2414 LENGTH 4 times the number of addresses in the list. 2415 A length of 0 indicates any address. 2416 list Yes 2417 DATA_VALUE 2418 0 1 2 3 2419 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 2420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2421 | DST ADDRESS | 2422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2424 DST ADDRESS 2426 An IPV4 address representing the destination host of a 2427 communication 2429 A.7 DST_IPV4_ADDR_SUBNET 2431 X 0 2432 DATA_TYPE 7 2433 LENGTH 8 times the number of subnets in the list. 2434 A length of 0 indicates any subnet. 2435 list Yes 2436 DATA_VALUE 2438 0 1 2 3 2439 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 2440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2441 | SUBNET ADDRESS | 2442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2443 | SUBNET MASK | 2444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2446 SUBNET ADDRESS 2448 An IPV4 address representing the destination subnet of a 2449 communication 2451 SUBNET MASK 2453 An IPV4 address representing the destination subnet mask 2454 of a communication 2456 A.8 DST_IPV4_ADDR_RANGE 2458 X 0 2459 DATA_TYPE 8 2460 LENGTH 8 times the number of address ranges in the list. 2461 A length of 0 indicates any address. 2462 list Yes 2463 DATA_VALUE 2465 0 1 2 3 2466 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 2467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2468 | LOWER BOUND DST ADDRESS | 2469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2470 | UPPER BOUND DST ADDRESS | 2471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2472 LOWER BOUND DST ADDRESS 2474 An IPV4 address representing the includsive lower-bound 2475 of a range of destination addresses of a communication. 2477 UPPER BOUND DST ADDRESS 2479 An IPV4 address representing the includsive upper-bound 2480 of a range of destination addresses of a communication. 2482 A.9 SRC_IPV6_ADDR 2484 X 0 2485 DATA_TYPE 9 2486 LENGTH 16 times the number of addresses in the list. 2487 A length of 0 indicates any address. 2488 list Yes 2489 DATA_VALUE 2491 0 1 2 3 2492 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 2493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2494 | | 2495 | SRC | 2496 | ADDRESS | 2497 | | 2498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2500 SRC ADDRESS 2502 An IPV6 address representing the source host of a 2503 communication 2505 A.10 SRC_IPV6_ADDR_SUBNET 2507 X 0 2508 DATA_TYPE 10 2509 LENGTH 32 times the number of subnets in the list. 2510 A length of 0 indicates any subnet. 2511 list Yes 2512 DATA_VALUE 2513 0 1 2 3 2514 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 2515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2516 | | 2517 | SUBNET | 2518 | ADDRESS | 2519 | | 2520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2521 | | 2522 | SUBNET | 2523 | MASK | 2524 | | 2525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2527 SUBNET ADDRESS 2529 An IPV6 address representing the source subnet of a 2530 communication 2532 SUBNET MASK 2534 An IPV6 address representing the source subnet mask of a 2535 communication 2537 A.11 SRC_IPV6_ADDR_RANGE 2539 X 0 2540 DATA_TYPE 11 2541 LENGTH 32 times the number of address ranges in the list. 2542 A length of 0 indicates any address. 2543 list Yes 2544 DATA_VALUE 2546 0 1 2 3 2547 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 2548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2549 | | 2550 | LOWER BOUND | 2551 | SRC ADDRESS | 2552 | | 2553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2554 | | 2555 | UPPER BOUND | 2556 | SRC ADDRESS | 2557 | | 2558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2560 LOWER BOUND SRC ADDRESS 2562 An IPV6 address representing the includsive lower-bound 2563 of a range of source addresses of a communication. 2565 UPPER BOUND SRC ADDRESS 2567 An IPV6 address representing the includsive upper-bound 2568 of a range of source addresses of a communication. 2570 A.12 DST_IPV6_ADDR 2572 X 0 2573 DATA_TYPE 12 2574 LENGTH 16 times the number of addresses in the list. 2575 A length of 0 indicates any address. 2576 list Yes 2577 DATA_VALUE 2579 0 1 2 3 2580 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 2581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2582 | | 2583 | DST | 2584 | ADDRESS | 2585 | | 2586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2588 DST ADDRESS 2590 An IPV6 address representing the destination host of a 2591 communication 2593 A.13 DST_IPV6_ADDR_SUBNET 2595 X 0 2596 DATA_TYPE 13 2597 LENGTH 32 times the number of subnets in the list. 2598 A length of 0 indicates any subnet. 2599 list Yes 2600 DATA_VALUE 2602 0 1 2 3 2603 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 2604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2605 | | 2606 | SUBNET | 2607 | ADDRESS | 2608 | | 2609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2610 | | 2611 | SUBNET | 2612 | MASK | 2613 | | 2614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2615 SUBNET ADDRESS 2617 An IPV6 address representing the destination subnet of a 2618 communication 2620 SUBNET MASK 2622 An IPV6 address representing the destination subnet mask 2623 of a communication 2625 A.14 DST_IPV6_ADDR_RANGE 2627 X 0 2628 DATA_TYPE 14 2629 LENGTH 32 times the number of address ranges in the list. 2630 A length of 0 indicates any address. 2631 list Yes 2632 DATA_VALUE 2634 0 1 2 3 2635 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 2636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2637 | | 2638 | LOWER BOUND | 2639 | DST ADDRESS | 2640 | | 2641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2642 | | 2643 | UPPER BOUND | 2644 | DST ADDRESS | 2645 | | 2646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2648 LOWER BOUND DST ADDRESS 2650 An IPV6 address representing the includsive lower-bound 2651 of a range of destination addresses of a communication. 2653 UPPER BOUND DST ADDRESS 2655 An IPV6 address representing the includsive upper-bound 2656 of a range of destination addresses of a communication. 2658 A.15 DIRECTION 2660 X 1 2661 DATA_TYPE 15 2662 LENGTH TV attribute, no length 2663 list No 2664 DATA_VALUE 2665 1 2 3 2666 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2668 | DIRECTION | 2669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2671 DIRECTION 2672 In/Outbound 0 2673 Inbound 1 2674 Outbound 2 2676 Direction is with respect to the senders interface. 2678 A.16 USER_NAME 2680 X 0 2681 DATA_TYPE 16 2682 LENGTH 1 plus the length of NAME 2683 A length of 0 indicates any name. 2684 list No 2685 DATA_VALUE 2687 0 1 2 3 2688 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 2689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2690 | NAME_TYPE | NAME ~ 2691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2693 NAME_TYPE 2694 822_EMAIL 0 2695 DIST_NAME 1 2697 values 2-250 are reserved to IANA. Values 251-255 are for 2698 private use among mutually consenting parties. 2700 NAME 2701 Name of type NAME. 2702 [**** probably should describe in more detail ****] 2704 A.17 SYSTEM_NAME 2706 X 0 2707 DATA_TYPE 17 2708 LENGTH 1 plus the length of NAME 2709 A length of 0 indicates any name. 2710 list No 2711 DATA_VALUE 2712 0 1 2 3 2713 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 2714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2715 | NAME_TYPE | NAME ~ 2716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2718 NAME_TYPE 2719 DNS_NAME 0 2720 DIST_NAME 1 2721 822_NAME 2 2722 X400_ADDR 3 2723 DIR_NAME 4 2724 EDI_PARTY_NAME 5 2725 URI 6 2726 IPADDR 7 2727 REGID 8 2728 OTHER 250 2730 values 9-249 are reserved to IANA. Values 251-255 are for 2731 private use among mutually consenting parties. 2733 NAME 2734 Name of type NAME. 2735 [***** probably should describe in more detail ****] 2737 A.18 XPORT_PROTOCOL 2739 X 0 2740 DATA_TYPE 18 2741 LENGTH 1 plus length of pdata 2742 A length of 0 indicates any address. 2743 list No (see below) 2744 DATA_VALUE 2746 0 1 2 3 2747 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 2748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2749 | PTYPE | PDATA ~ 2750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2752 PTYPE Describes the rest of the data: 2753 ANY 0 2754 OPAQUE 1 2755 LIST 2 2756 RANGE 3 2758 PDATA 2759 Not used if PTYPE is ANY or OPAQUE. 2761 LIST 2762 indicates a list whose elements look like the following: 2764 0 2765 0 1 2 3 4 5 6 7 2766 +-+-+-+-+-+-+-+-+ 2767 | PROTOCOL | 2768 +-+-+-+-+-+-+-+-+ 2770 The length of pdata to be used as part of the LENGTH 2771 field is 1 times the number of elements in the list. 2773 RANGE 2774 indicates a range of protocol values whose inclusive 2775 lower-bound is LOWER, and inclusive upper-bound is UPPER. 2776 0 1 2777 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 2778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2779 | LOWER | UPPER | 2780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2782 The length of pdata to be used as part of the LENGTH 2783 field is 2. 2785 A.19 SRC_PORT 2787 X 0 2788 DATA_TYPE 19 2789 LENGTH 2 times the number of ports in the list. 2790 A length of 0 indicates any port. 2791 list Yes 2792 DATA_VALUE 2794 0 1 2795 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2797 | PORT | 2798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2800 PORT 2801 Port that the communication must be initiated with. This 2802 may be a list of ports. 2804 A.20 SRC_PORT_DYNAMIC 2806 X 0 2807 DATA_TYPE 20 2808 LENGTH 4 plus 2 times the number of ports in the list. 2809 A length of 4 indicates any port. 2810 list See Below 2811 DATA_VALUE 2812 0 1 2 3 2813 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 2814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2815 | DYNAMIC LOWER BOUND | DYNAMIC UPPER BOUND | 2816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2817 | PORT | ... ~ 2818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2820 The use of this attribute indicates that dynamic port allocation 2821 is permitted. Communications that are intitiated with any of the 2822 ports indicated, may then dynamically allocate any of the ports 2823 listed within the LOWER and UPPER BOUNDS, inclusive. 2825 DYNAMIC LOWER BOUND 2826 Lower bound of the range of ports that may be dynamically 2827 allocated. If this and DYNAMIC UPPER BOUND are both 0, 2828 then any port may be dynamically allocated. 2830 DYNAMIC UPPER BOUND 2831 Upper bound of the range of ports that may be dynamically 2832 allocated. If this and DYNAMIC LOWER BOUND are both 0, 2833 then any port may be dynamically allocated. 2835 PORT 2836 Port that the communication must be initiated with. This 2837 may be a list of ports. 2839 A.21 DST_PORT 2841 X 0 2842 DATA_TYPE 21 2843 LENGTH 2 times the number of ports in the list. 2844 A length of 0 indicates any port. 2845 list Yes 2846 DATA_VALUE 2848 0 1 2849 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2851 | PORT | 2852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2854 PORT 2855 Port that the communication must be initiated with. This 2856 may be a list of ports. 2858 A.22 DST_PORT_DYNAMIC 2860 X 0 2861 DATA_TYPE 22 2862 LENGTH 4 plus 2 times the number of ports in the list. 2863 A length of 4 indicates any port. 2864 list See Below 2865 DATA_VALUE 2866 0 1 2 3 2867 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 2868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2869 | DYNAMIC LOWER BOUND | DYNAMIC UPPER BOUND | 2870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2871 | PORT | ... ~ 2872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2874 The use of this attribute indicates that dynamic port allocation 2875 is permitted. Communications that are intitiated with any of the 2876 ports indicated, may then dynamically allocate any of the ports 2877 listed within the LOWER and UPPER BOUNDS, inclusive. 2879 DYNAMIC LOWER BOUND 2880 Lower bound of the range of ports that may be dynamically 2881 allocated. If this and DYNAMIC UPPER BOUND are both 0, 2882 then any port may be dynamically allocated. 2884 DYNAMIC UPPER BOUND 2885 Upper bound of the range of ports that may be dynamically 2886 allocated. If this and DYNAMIC LOWER BOUND are both 0, 2887 then any port may be dynamically allocated. 2889 PORT 2890 Port that the communication must be initiated with. This 2891 may be a list of ports. 2893 A.23 SEC_LABELS 2895 X 0 2896 DATA_TYPE 23 2897 LENGTH Variable. 2898 list No 2899 DATA_VALUE 2901 0 1 2 3 2902 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 2903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2904 | SECURITY LABEL ~ 2905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2907 SECURITY LABEL 2909 [**** ????? *****] 2911 A.24 V6CLASS 2913 X 1 2914 DATA_TYPE 24 2915 LENGTH TV attribute, no length 2916 list No 2917 DATA_VALUE 2918 1 2 3 2919 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2921 | PADDING | CLASS | 2922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2924 PADDING 2926 set to 0 2928 CLASS 2930 class value 2932 A.25 V6FLOW 2934 X 0 2935 DATA_TYPE 25 2936 LENGTH 4 2937 list No 2938 DATA_VALUE 2939 0 1 2 3 2940 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 2941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2942 | PADDING | FLOW | 2943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2945 PADDING 2947 set to 0 2949 FLOW 2951 set to flow value 2953 A.26 V4TOS 2955 X 1 2956 DATA_TYPE 26 2957 LENGTH TV attribute, no length 2958 list No 2959 DATA_VALUE 2961 1 2 3 2962 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2964 | PADDING | TOS | 2965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2967 PADDING 2969 set to 0 2971 TOS 2973 type of service value 2975 A.27 ACTION 2977 X 1 2978 DATA_TYPE 27 2979 LENGTH TV attribute, no length 2980 list No 2982 DATA_VALUE 2983 1 2 3 2984 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2986 | ACTION | 2987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2989 ACTION 2990 Deny 0 2991 Permit 1 2993 A.28 SRC_PORT_RANGE 2995 X 0 2996 DATA_TYPE 28 2997 LENGTH 4 times the number of port ranges in the list. 2998 A length of 0 indicates any port. 2999 list Yes 3000 DATA_VALUE 3002 0 1 2 3 3003 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 3004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3005 | PORT LOWER BOUND | PORT UPPER BOUND | 3006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3008 PORT LOWER BOUND 3010 Inclusive lower-bound of a range of port numbers that the 3011 communication must be initiated with. 3013 PORT UPPER BOUND 3015 Inclusive upper-bound of a range of port numbers that the 3016 communication must be initiated with. 3018 A.29 DST_PORT_RANGE 3020 X 0 3021 DATA_TYPE 29 3022 LENGTH 4 times the number of port ranges in the list. 3023 A length of 0 indicates any port. 3024 list Yes 3025 DATA_VALUE 3027 0 1 2 3 3028 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 3029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3030 | PORT LOWER BOUND | PORT UPPER BOUND | 3031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3033 PORT LOWER BOUND 3035 Inclusive lower-bound of a range of port numbers that the 3036 communication must be initiated with. 3038 PORT UPPER BOUND 3040 Inclusive upper-bound of a range of port numbers that the 3041 communication must be initiated with. 3043 A.30 IPSEC_ACTION 3045 X 0 3046 DATA_TYPE 50 3047 LENGTH Variable 3048 list Yes 3049 DATA_VALUE 3050 0 1 2 3 3051 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 3052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----- 3053 | ESP | RESERVED | LIFETIME_TYPE | | 3054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3055 | LIFETIME | Fixed 3056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length 3057 | AH | IPCOMP | LIFETIME_TYPE | | 3058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3059 | LIFETIME | | 3060 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----- 3061 | N_OF_CIPHERS | CIPHER_ALG | CIPHER_KEYLENGTH 3062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3063 | ROUNDS | ... 3064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3065 | N_OF_INT_ESP | INT_ALG_ESP | ESP_INT_KEYLENGTH ... 3066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3067 | N_OF_INT_AH | INT_ALG_AH | INT_KEYLENGTH ... 3068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3069 | N_OF_IPCOMP | IPCOMP_ALG ... 3070 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3071 | LOC_TYPE | LOC_SRC... 3072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3073 | LOC_TYPE | LOC_DST... 3074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3075 | LOC_TYPE | LOC_SRC... 3076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3077 | LOC_TYPE | LOC_DST... 3078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3080 ESP 3082 This octet indicates if ESP is to be used and in what 3083 mode. NOT REQUIRED means that ESP is not necessary but if used 3084 it MUST be negotiated based on the parameters defined 3085 below. TUNNEL_MODE or TRANSP_MODE means that ESP MUST be 3086 negotiatiated in this mode. ANY_MODE means that ESP MUST be 3087 negotited and that any mode (Tunnel or transport) will 3088 suffice. NOT ALLOWED means that ESP SHOULD not be negotiated 3089 and it MUST not be part of this SA. 3091 NOT_REQUIRED 0 3092 TUNNEL_MODE 1 3093 TRANSP_MODE 2 3094 TUNNEL_MODE_OPT 3 3095 TRANSP_MODE_OPT 4 3096 ANY_MODE 5 3097 NOT ALLOWED 6 3099 LIFETIME_TYPE 3101 This 2 octet field indicates type of lifetime. 3103 RESERVED 0 3104 SECONDS 1 3105 KILOBYTES 2 3107 These values are assigned in section 4.5 of [Piper98] and 3108 are updated when those assigned values change. 3110 RESERVED 3112 This 1 octet field primarily used for alignment purposes. Its 3113 value is always 0. 3115 LIFETIME 3117 This 4 octet field indicates the SA lifetime. For a given 3118 "Lifetime_Type" the value of the "Lifetime" attribute 3119 defines the actual length of the SA life--either a number of 3120 seconds, or a number of kilobytes protected. 0 is not used. 3122 AH 3123 This octet indicates if AH is to be used and in what mode. NOT 3124 REQUIRED means that AH is not necessary but if used it MUST be 3125 negotiated based on the parameters defined below. TUNNEL_MODE or 3126 TRANSP_MODE means that AH MUST be negotiatiated in this 3127 mode. ANY_MODE means that AH MUST be negotited and that any 3128 mode (Tunnel or transport) will suffice. NOT 3129 ALLOWED means that AH SHOULD not be negotiated and it MUST 3130 not be part of this SA. 3132 NOT_REQUIRED 0 3133 TUNNEL_MODE 1 3134 TRANSP_MODE 2 3135 TUNNEL_MODE_OPT 3 3136 TRANSP_MODE_OPT 4 3137 ANY_MODE 5 3138 NOT ALLOWED 6 3140 IPCOMP 3141 This field indicates if IP Compression is to be used. NOT 3142 REQUIRED means that IPCOMP is not necessary but if used it MUST 3143 be negotiated based on the parameters defined below. REQUIRED 3144 means that IPCOMP MUST be negotiated as part of this SA. NOT 3145 ALLOWED means that IPCOMP MUST not be part of this SA. 3147 NOT_REQUIRED 0 3148 REQUIRED 1 3149 NOT ALLOWED 2 3151 N_OF_CIPHERS 3153 This octet indicates the number of CIPHER_ALG fields in octets 3154 that will follow this field and that could be used during an 3155 IKE phase 2 negotiation. If the value of the ESP 3156 field is (04)hex this field MUST be set to 0. 3158 CIPHER_ALG 3160 This octet indicates which ciphers should be used for the IKE 3161 phase 2 negotiation. If the ANY identifier is used, it MUST be 3162 the only identifier in the list, and its meaning does not 3163 include the NULL cipher. If the value of the N_OF_CIPHERS 3164 field is 0 the CIPHER_ALG, the CIPHER_KEYLENTH and the ROUNDS 3165 fields are ignored. 3167 ANY 0 3168 NULL 1 3169 RFC1829_IV64 2 3170 DES 3 3171 DES3 4 3172 RC5 5 3173 IDEA 6 3174 CAST 7 3175 BLOWFISH 8 3176 3IDEA 9 3177 RFC1829_IV32 10 3178 RC4 11 3180 These values are assigned in section 4.4.4 of [Piper98], with 3181 the exception of 0 being defined as ANY, and are updated when 3182 those assigned values change. 3184 CIPHER_KEYLENGTH 3186 The first octet corresponds to the minimum value and the 3187 second octet corresponds to the maximum value. If no range 3188 exist the first octet indicates the keylength. The second 3189 octet contains a value of (00)hex. 3191 ROUNDS 3193 The first octet corresponds to the minimum value and the 3194 second octet corresponds to the maximum value. If no range 3195 exist the first octet indicates the rounds. The second 3196 octet contains a value of (00)hex. 3198 N_OF_INT_ESP 3200 This octet indicates the number of INTEGRITY_ALG fields in 3201 octets that will follow this field and that could be used 3202 during an IKE phase 1 negotiation. If this field is 0 no 3203 authentication/integrity is used with ESP. 3205 INT_ALG_ESP 3207 This octet indicates which algorithm should be used for the 3208 IKE phase 2 negotiation. If the ANY identifier is used, it 3209 MUST be the only identifier in the list. If the value of the 3210 N_OF_INT_ESP field is 0 this INT_ALG_ESP and ESP_INT_KEYLENGTH 3211 are ignored. 3213 ANY 0 3214 HMAC_MD5 1 3215 HMAC_SHA1 2 3216 DES_MAC 3 3217 KPDK 4 3219 These values are assigned in section 4.5 of [Piper98], with 3220 the exception of 0 being defined as ANY, and are updated when 3221 those assigned values change. 3223 ESP_INT_KEYLENGTH 3225 The first octet corresponds to the minimum value and the 3226 second octet corresponds to the maximum value. If no range 3227 exist the first octet indicates the keylength. The second 3228 octet contains a value of (00)hex. 3230 N_OF_INT_AH 3232 This octet indicates the number of INTEGRITY_ALG fields in 3233 octets that will follow this field and that could be used 3234 during an IKE phase 1 negotiation. If the value of the AH 3235 field is (04)hex this field MUST be set to 0. 3237 INT_ALG_AH 3239 This octet indicates which algorithm should be used for the 3240 IKE phase 2 negotiation. If the value of the N_OF_INT_AH 3241 field is 0 the INT_ALG_AH and the INT_KEYLENGTH fields are 3242 ignored. 3244 ANY 0 3245 HMAC_MD5 1 3246 HMAC_SHA1 2 3247 DES_MAC 3 3248 KPDK 4 3250 These values are assigned in section 4.5 of [Piper98], with 3251 the exception of 0 being defined as ANY, and are updated when 3252 those assigned values change. 3254 INT_ KEYLENGTH 3256 The first octet corresponds to the minimum value and the 3257 second octet corresponds to the maximum value. If no range 3258 exist the first octet indicates the keylength. The second 3259 octet contains a value of (00)hex. 3261 N_OF_IPCOMP 3263 This octet indicates the number of IPCOMP_ALG fields in octets 3264 that will follow this field and that could be used during an 3265 IKE phase 2 negotiation. If the value of the IPCOMP 3266 field is (04)hex this field MUST be set to 0. 3268 IPCOMP_ALG 3270 This octet indicates which algorithm should be used for the 3271 IKE phase 2 negotiation. If the ANY identifier is used, it 3272 MUST be the only identifier in the list. If the value of the 3273 N_OF_IPCOMP field is 0 this field is ignored. 3275 ANY 0 3276 OUI 1 3277 DEFLATE 2 3278 LZS 3 3280 These values are assigned in section 4.4.5 of [Piper98], with 3281 the exception of 0 being defined as ANY, and are updated when 3282 those assigned values change. 3284 LOC_TYPE 3286 This 1 octet field indicates the contents of the LOC_SRC or 3287 LOC_DST field. If this field is 0 then the LOC_SRC or LOC_DST 3288 will be omitted. 3290 NONE 0 3291 IPv4 address 1 3292 IPv6 address 2 3293 DNS Name 3 3294 General 4 3296 values 5-250 are reserved to IANA. Values 251-255 are for 3297 private use among mutually consenting parties. 3299 LOC_SRC 3301 Variable length field depending on LOC_TYPE. 3303 IF LOC_TYPE is (04) then this field is 1 octet in length an it 3304 may only take the following values: 3306 ANY 0 3307 DEST 1 3308 HOST 2 3309 LOCAL-SG 3 3310 REMOTE-SG 4 3312 values 5-250 are reserved to IANA. Values 251-255 are for 3313 private use among mutually consenting parties. 3315 LOC_DST 3317 See LOC_SRC. 3319 A.31 IKE_ACTION 3321 X 0 3322 DATA_TYPE 51 3323 LENGTH Variable 3324 list No 3325 DATA_VALUE 3327 0 1 2 3 3328 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 3329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3330 | MODE | PFS | GROUP DESCRIPTION | 3331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3332 | PRF | LIFETIME_TYPE | 3333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3334 | LIFETIME | 3335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3336 | N_OF_AUTH | AUTH_METHOD ... 3337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3338 | N_OF_CIPHERS | CIPHER_ALG | KEYLENGTH... 3339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3340 | N_OF_HASH | HASH_ALG ... 3341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3343 MODE 3345 This octet indicates the IKE mode of operation. 3347 MAIN 0 3348 AGRESSIVE 1 3349 QUICK 2 3351 values 3-250 are reserved to IANA. Values 251-255 are for 3352 private use among mutually consenting parties. 3354 PFS Indicates if PFS is to be used for the SA negotiation. 3356 FALSE 0 3357 TRUE 1 3359 GROUP DESCRIPTION 3361 This 2 octet field indicates which group should be used during 3362 the ISAKMP phase 1 or phase 2 negotiation. 3364 Not Used 0 3365 default 768-bit MODP group 1 3366 alternate 1024-bit MODP group 2 3367 EC2N group on GP[2^155] 3 3368 EC2N group on GP[2^185] 4 3370 These values are assigned in Appendix A of [Harkins98] 3371 and are updated when those assigned values change. 3373 PRF 3374 There are currently no pseudo-random functions defined. 3376 These values are assigned in Appendix A of [Harkins98] 3377 and are updated when those assigned values change. 3379 LIFETIME_TYPE 3381 This 2 octet field indicates type of lifetime. 3383 seconds 1 3384 kilobytes 2 3386 These values are assigned in Appendix A of [Harkins98] 3387 and are updated when those assigned values change. 3389 LIFETIME 3391 This 4 octet field indicates the SA lifetime. For a given 3392 "Lifetime_Type" the value of the "Lifetime" attribute defines 3393 the actual length of the SA life-- either a number of seconds, 3394 or a number of kilobytes protected. 3396 N_OF_AUTH 3398 This octet indicates the number of AUTH_METHOD fields in octets 3399 that will follow this field and that could be used during an 3400 IKE phase 1 negotiation. 3402 AUTH_METHOD 3404 This octet indicates which authentication methods should be used. 3405 The number of auth_methods that could be used is N_OF_AUTH 3407 pre-shared key 1 3408 DSS signatures 2 3409 RSA signatures 3 3410 Encryption with RSA 4 3411 Revised encryption with RSA 5 3413 These values are assigned in Appendix A of [Harkins98] 3414 and are updated when those assigned values change. 3416 N_OF_CIPHERS 3418 This octet indicates the number of CIPHER_ALG fields in octets 3419 that will follow this field and that could be used during an 3420 IKE phase 1 negotiation. 3422 KEYLENGTH 3424 The first octet corresponds to the minimum value and the 3425 second octet corresponds to the maximum value. If no range 3426 exist the first octet indicates the keylength. The second 3427 octet contains a value of (00)hex. 3429 CIPHER_ALG 3431 This octet indicates which ciphers should be used for the IKE 3432 phase 1 negotiation. For IKE phase 2 negotiations this field is 3433 ignored. The number of ciphers that could be used is 3434 N_OF_CIPHERS 3436 ANY 0 3437 DES 1 3438 IDEA 2 3439 BLOWFISH 3 3440 RC5 4 3441 DES3 5 3442 CAST 6 3444 These values are assigned in Appendix A of [Harkins98], with 3445 the exception of 0 being defined as ANY, and are updated when 3446 those assigned values change. 3448 N_OF_HASH 3450 This octet indicates the number of HASH_ALG fields in octets 3451 that will follow this field and that could be used during an 3452 IKE phase 1 negotiation. 3454 HASH_ALG 3456 This octet indicates which algorithm should be used for the 3457 IKE phase 1 negotiation. For IKE phase 2 negotiations this field 3458 is ignored. 3460 ANY 0 3461 MD5 1 3462 SHA1 2 3463 TIGER 3 3465 These values are assigned in Appendix A of [Harkins98], with 3466 the exception of 0 being defined as ANY, and are updated when 3467 those assigned values change. 3469 APPENDIX B 3471 An SPP Example 3473 This appendix provides a detailed example of SPP in use. This example 3474 expands on the one provided in section [***] of [SPS]. 3476 admin. boundary admin. boundary 3477 ----------------- --------------------------- 3478 | | | admin. boundary| 3479 | | | ---------------| 3480 | Q1 | Q2 | Q3 | || 3481 | H1 ---- SG1 ---- (Internet) --- SG2 ---- | SG3 --- H2 || 3482 | R3 | | R2 | | R1 | | || 3483 | PS1 | | PS2 | PS3 || 3484 | | | ---------------| 3485 ----------------- --------------------------- 3486 ESP Tunnel 3487 |=======================| 3488 ESP Tunnel 3489 |========================================| 3490 ESP Transport 3491 |================================================| 3493 |==| = security association required by policy 3494 ---- = connectivity (or if so labeled, administrative boundary) 3495 Hx = host x 3496 SGx = security gateway x 3497 PSx = policy server x 3498 Qx = query x 3499 Rx = reply x 3501 The following entities have these policies for a communication 3502 between H1 and H2 for UDP port 79: 3504 H1: requires an ESP Transport SA with H2 3505 PS1: requires an ESP Tunnel SA between SG1 and SG2 3506 PS2: requires an ESP Tunnel SA between SG1 and SG2 3507 PS3: requires an ESP Tunnel SA between H1 and SG3 3508 H2: requires an ESP Transport SA with H1 3510 PS1, PS2, PS3 also have policies allowing ESP to pass through 3511 their respective Security Gateways. 3513 1. The policy client at H1 is asked for a policy for a communication: 3514 H1 to H2 using UDP port 79. 3516 2. H1's policy client does not have an answer so it creates an SPP 3517 query, Q1: 3518 SPP Header [Query, Sender H1, qcount 1, rcount 2] 3519 Query Payload [comsec]: 3520 src H1, dst H2, UDP, 79 3521 Record Payload [comsec]: 3522 src H1, dst H2, UDP, 79, permit 3524 Record Payload [SA rec]: 3525 src H1, dst H2, UDP, 79, permit, ESP transport H1->H2 3526 Signature Payload 3527 H1 sends Q1 to PS1, its configured policy server. 3529 3. PS1 receives the query and verifies the signature. Its domain 3530 database indicates that it is not authoritative over H2 so it 3531 checks its cache to see if it has a cached answer. For this 3532 example, it does not, so it creates a new SPP query, Q2, with 3533 the query and records formed by merging the local policy with 3534 the policy from Q1: 3535 SPP Header [Query, Sender PS1, qcount 1, rcount 3] 3536 Query Payload [comsec]: 3537 src H1, dst H2, UDP, 79 3538 Record Payload [comsec]: 3539 src H1, dst H2, UDP, 79, permit 3540 Record Payload [SA rec]: 3541 src SG1, dst SG2, UDP, 79, permit, ESP tunnel SG1->SG2 3542 Record Payload [SA rec]: 3543 src H1, dst H2, UDP, 79, permit, ESP transport H1->H2 3544 Signature Payload 3545 PS1 sends Q2 to H2. 3547 4. SG2 intercepts Q2 and passes it to PS2. 3549 5. PS2 receives the query and verifies the signature. Its domain 3550 database indicates that it is not authoritative over H2 so it 3551 checks its cache to see if it has a cached answer. For this 3552 example, it does not, so it creates a new SPP query, Q3, with 3553 the query and records formed by merging the local policy with 3554 the policy from Q2: 3555 SPP Header [Query, Sender PS1, qcount 1, rcount 3] 3556 Query Payload [comsec]: 3557 src H1, dst H2, UDP, 79 3558 Record Payload [comsec]: 3559 src H1, dst H2, UDP, 79, permit 3560 Record Payload [SA rec]: 3561 src SG1, dst SG2, UDP, 79, permit, ESP tunnel SG1->SG2 3562 Record Payload [SA rec]: 3563 src H1, dst H2, UDP, 79, permit, ESP transport H1->H2 3564 Signature Payload 3565 PS2 sends Q3 to H2. 3567 6. SG3 intercepts Q3 and passes it to PS3. 3569 7. PS3 receives the query and verifies the signature. Its domain 3570 database indicates that it is authoritative over H2 so it 3571 will send a reply. It checks its cache to see if it has a cached 3572 answer. For this example, it does have one cached from previous 3573 information sent to it by H2. PS3 merges the cached policy with 3574 the policy it received from Q3. The merge indicates that a signal 3575 and a reply will be needed. PS3 caches the merged policy. 3577 PS3 creates a reply with the query payload from Q3, the merged 3578 policy and policy server and cert records: 3579 SPP Header [Reply, Sender PS3, qcount 1, rcount 6] 3580 Query Payload [comsec]: 3581 src H1, dst H2, UDP, 79 3582 Record Payload [comsec]: 3583 src H1, dst H2, UDP, 79, permit 3584 Record Payload [SA rec]: 3585 src SG1, dst SG2, UDP, 79, permit, ESP tunnel SG1->SG2 3586 Record Payload [SA rec]: 3587 src H1, dst SG3, UDP, 79, permit, ESP tunnel H1->SG3 3588 Record Payload [SA rec]: 3589 src H1, dst H2, UDP, 79, permit, ESP transport H1->H2 3590 Record Payload [policy server]: 3591 policy server PS3, node H1 3592 Record Payload [cert]: 3593 cert for PS3 3594 Signature Payload 3595 PS3 sends R1 to PS2. 3597 PS3 creates a signal with a comsec record derived from knowing the 3598 traffic that will pass through SG3 and, the part of the merged 3599 policy that terminates at SG3: 3600 SPP Header [Pol, Sender PS3, qcount 0, rcount 2] 3601 Record Payload [comsec]: 3602 src H1, dst H2, ESP, OPAQUE, permit 3603 Record Payload [SA rec]: 3604 src H1, dst SG3, UDP, 79, permit, ESP tunnel H1->SG3 3605 Signature Payload 3606 PS3 sends the signal to SG3. 3608 8. SG3 receives the signal and verifies the signature. SG3 creates 3609 an Ack message to indicate that it has received the policy message: 3610 SPP Header [Pol-Ack, Sender SG3, qcount 0, rcount 0] 3611 Signature Payload 3612 SG3 sends the signal to PS3. 3614 9. PS3 receives the Pol-Ack and verifies the signature. PS3 removes 3615 the corresponding policy message from its retry queue. 3617 10. Meanwhile, PS2 receives the reply R1 and verifies the signature and 3618 the chain-of-trust to verify the policy came from a server 3619 authoritative for H2. It matches an outstanding query message, so it 3620 will send a reply. PS2 merges the policy received in R1 with its 3621 local policy and the policy information it received from Q2. The 3622 merge indicates that a signal and a reply will be needed. PS2 caches 3623 the merged policy. 3625 PS2 creates a reply with the query payload from R1, the merged 3626 policy and policy server and cert records: 3628 SPP Header [Reply, Sender PS2, qcount 1, rcount 8] 3629 Query Payload [comsec]: 3630 src H1, dst H2, UDP, 79 3631 Record Payload [comsec]: 3632 src H1, dst H2, UDP, 79, permit 3633 Record Payload [SA rec]: 3634 src SG1, dst SG2, UDP, 79, permit, ESP tunnel SG1->SG2 3635 Record Payload [SA rec]: 3636 src H1, dst SG3, UDP, 79, permit, ESP tunnel H1->SG3 3637 Record Payload [SA rec]: 3638 src H1, dst H2, UDP, 79, permit, ESP transport H1->H2 3639 Record Payload [policy server]: 3640 policy server PS3, node H1 3641 Record Payload [cert]: 3642 cert for PS3 3643 Record Payload [policy server]: 3644 policy server PS2, node PS3 3645 Record Payload [cert]: 3646 cert for PS2 3647 Signature Payload 3648 PS2 sends R2 to PS1. 3650 PS2 creates a signal with a comsec record derived from knowing the 3651 traffic that will pass through SG2 and, the part of the merged 3652 policy that terminates at SG2: 3653 SPP Header [Pol, Sender PS2, qcount 0, rcount 2] 3654 Record Payload [comsec]: 3655 src H1, dst SG3, ESP, OPAQUE, permit 3656 Record Payload [SA rec]: 3657 src SG1, dst SG2, UDP, 79, permit, ESP tunnel SG1->SG2 3658 Signature Payload 3659 PS2 sends the signal to SG2. 3661 11. SG2 receives the signal and verifies the signature. SG2 creates 3662 an Ack message to indicate that it has received the policy message: 3663 SPP Header [Pol-Ack, Sender SG2, qcount 0, rcount 0] 3664 Signature Payload 3665 SG2 sends the signal to PS2. 3667 12. PS2 receives the Pol-Ack and verifies the signature. PS2 removes 3668 the corresponding policy message from its retry queue. 3670 11. Meanwhile, PS1 receives the reply R2 and verifies the signature and 3671 the chain-of-trust to verify the policy came from a server 3672 authoritative for H2. R2 matches an outstanding query message, so it 3673 will send a reply. PS1 merges the policy received in R2 with its 3674 local policy and the policy information it received from Q1. The 3675 merge indicates that a signal and a reply will be needed. PS1 caches 3676 the merged policy. 3678 PS1 creates a reply with the query payload from R2 and the merged 3679 policy. Policy server and cert records are not necessary since PS1 3680 is authoritative for H1: 3682 SPP Header [Reply, Sender PS1, qcount 1, rcount 3] 3683 Query Payload [comsec]: 3684 src H1, dst H2, UDP, 79 3685 Record Payload [comsec]: 3686 src H1, dst H2, UDP, 79, permit 3687 Record Payload [SA rec]: 3688 src H1, dst SG3, UDP, 79, permit, ESP tunnel H1->SG3 3689 Record Payload [SA rec]: 3690 src H1, dst H2, UDP, 79, permit, ESP transport H1->H2 3691 Signature Payload 3692 PS1 sends R3 to H1. 3694 PS1 creates a signal with a comsec record derived from knowing the 3695 traffic that will pass through SG1 and, the part of the merged 3696 policy that terminates at SG1: 3697 SPP Header [Pol, Sender PS1, qcount 0, rcount 2] 3698 Record Payload [comsec]: 3699 src H1, dst SG3, ESP, OPAQUE, permit 3700 Record Payload [SA rec]: 3701 src SG1, dst SG2, UDP, 79, permit, ESP tunnel SG1->SG2 3702 Signature Payload 3703 PS1 sends the signal to SG1. 3705 12. SG1 receives the signal and verifies the signature. SG1 creates 3706 an Ack message to indicate that it has received the policy message: 3707 SPP Header [Pol-Ack, Sender SG1, qcount 0, rcount 0] 3708 Signature Payload 3709 SG1 sends the signal to PS1. 3711 13. PS1 receives the Pol-Ack and verifies the signature. PS1 removes 3712 the corresponding policy message from its retry queue. 3714 14. Meanwhile, H1 receives the reply R3 and verifies the signature. 3715 The client can now use the policy as it is needed. 3717 Disclaimer 3719 The views and specification here are those of the authors and are 3720 not necessarily those of their employers. The authors and their 3721 employers specifically disclaim responsibility for any problems 3722 arising from correct or incorrect implementation or use of this 3723 specification. 3725 Copyright (C) The Internet Society (May 1999). All 3726 Rights Reserved. 3728 This document and translations of it may be copied and furnished 3729 to others, and derivative works that comment on or otherwise 3730 explain it or assist in its implmentation may be prepared, copied, 3731 published and distributed, in whole or in part, without 3732 restriction of any kind, provided that the above copyright notice 3733 and this paragraph are included on all such copies and derivative 3734 works. However, this document itself may not be modified in any 3735 way, such as by removing the copyright notice or references to the 3736 Internet Society or other Internet organizations, except as needed 3737 for the purpose of developing Internet standards in which case the 3738 procedures for copyrights defined in the Internet Standards 3739 process must be followed, or as required to translate it into 3740 languages other than English. The limited permissions granted above 3741 are perpetual and will not be revoked by the Internet Society or 3742 its successors or assigns. 3744 This document and the information contained herein is provided on 3745 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 3746 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 3747 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 3748 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3749 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3751 Author Information 3753 Luis A. Sanchez Matthew N. Condell 3754 BBN Technologies BBN Technologies 3755 GTE Internetworking GTE Internetworking 3756 10 Moulton Street 10 Moulton Street 3757 Cambridge, MA 02140 Cambridge, MA 02140 3758 USA USA 3759 Email: lsanchez@bbn.com Email: mcondell@bbn.com 3760 Telephone: +1 (617) 873-3351 Telephone: +1 (617) 873-6203