idnits 2.17.1 draft-ietf-ipsec-sps-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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 35) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 9 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** There are 710 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 3226 has weird spacing: '... prot spor...' == Line 3227 has weird spacing: '...sanchez sec...' == Line 3228 has weird spacing: '...sanchez con...' == Line 3236 has weird spacing: '... prot spor...' == Line 3237 has weird spacing: '...sanchez sec...' == (22 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The 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 (November 18, 1998) is 9284 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) == Missing Reference: 'P' is mentioned on line 3184, but not defined == Unused Reference: 'ALX98' is defined on line 2334, but no explicit reference was found in the text == Unused Reference: 'RFC2230' is defined on line 2341, but no explicit reference was found in the text == Unused Reference: 'PKIXP1' is defined on line 2344, but no explicit reference was found in the text == Unused Reference: 'PolMod' is defined on line 2348, but no explicit reference was found in the text == Unused Reference: 'Harkins98' is defined on line 2351, but no explicit reference was found in the text == Unused Reference: 'Piper98' is defined on line 2354, but no explicit reference was found in the text -- Unexpected draft version: The latest known version of draft-ietf-ipsec-arch-sec is -06, but you're referring to -07. -- Possible downref: Non-RFC (?) normative reference: ref. 'KA98b' -- Possible downref: Non-RFC (?) normative reference: ref. 'ALX98' ** Obsolete normative reference: RFC 1305 (Obsoleted by RFC 5905) ** Downref: Normative reference to an Informational RFC: RFC 2230 == Outdated reference: A later version (-11) exists of draft-ietf-pkix-ipki-part1-10 -- Possible downref: Normative reference to a draft: ref. 'PolMod' -- Unexpected draft version: The latest known version of draft-ietf-ipsec-isakmp-oakley is -07, but you're referring to -08. ** Downref: Normative reference to an Historic draft: draft-ietf-ipsec-isakmp-oakley (ref. 'Harkins98') -- Unexpected draft version: The latest known version of draft-ietf-ipsec-ipsec-doi is -09, but you're referring to -10. ** Downref: Normative reference to an Historic draft: draft-ietf-ipsec-ipsec-doi (ref. 'Piper98') == Outdated reference: A later version (-01) exists of draft-ietf-ipsec-spsl-00 -- Possible downref: Normative reference to a draft: ref. 'SPSL' Summary: 15 errors (**), 0 flaws (~~), 18 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group L.A. Sanchez, BBN/GTEI 2 Internet Draft M.N. Condell, BBN/GTEI 3 Expires April, 1999 November 18, 1998 5 Security Policy System 6 8 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and its working groups. Note that other groups may also distribute 13 working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six 16 months and may be updated, replaced, or obsoleted by other 17 documents at any time. It is inappropriate to use Internet- Drafts 18 as reference material or to cite them other than as "work in 19 progress." 21 To view the entire list of current Internet-Drafts, please check 22 the "1id-abstracts.txt" listing contained in the Internet-Drafts 23 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 24 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 25 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US 26 West Coast). 28 Abstract 30 This document describes a distributed system that provides the 31 mechanisms needed for discovering, accessing and processing security 32 policy information of hosts, subnets or networks of a security domain. 33 In this system policy clients and servers exchange information using 34 the Security Policy Protocol. The protocol defines how the policy 35 information is exchanged, processed, and protected by clients and 36 servers. The system accommodates topology changes, hence policy 37 changes, rather easily without the scalability constraints imposed by 38 static reconfiguration of each client. The protocol is extensible and 39 flexible. It allows the exchange of complex policy objects between 40 clients and servers. 42 Table of Contents 44 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 45 1.1 Terms and Technical Definitions. . . . . . . . . . . . . . 3 46 1.1.1 Requirements Terminology . . . . . . . . . . . . . . . 3 47 1.1.2 Technical Definitions. . . . . . . . . . . . . . . . . 3 48 1.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 49 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 50 3. Policy Master File . . . . . . . . . . . . . . . . . . . . . . 8 51 4. Policy Database. . . . . . . . . . . . . . . . . . . . . . . . 9 52 4.1 Local Policy Database. . . . . . . . . . . . . . . . . . . 9 53 4.2 Cache Database . . . . . . . . . . . . . . . . . . . . . . 10 54 4.3 Security Domain Database . . . . . . . . . . . . . . . . . 10 55 5. Security Policy Protocol (SPP) . . . . . . . . . . . . . . . . 11 56 5.1 SPP Message Format . . . . . . . . . . . . . . . . . . . . 12 57 5.2 SPP Payloads . . . . . . . . . . . . . . . . . . . . . . . 14 58 5.2.1 Query Payload. . . . . . . . . . . . . . . . . . . . . 14 59 5.2.2 Record Payload . . . . . . . . . . . . . . . . . . . . 15 60 5.2.3 Signature Payload. . . . . . . . . . . . . . . . . . . 16 61 5.3 SPP Messages . . . . . . . . . . . . . . . . . . . . . . . 17 62 5.3.1 Query Messages . . . . . . . . . . . . . . . . . . . . 17 63 5.3.2 Reply Messages . . . . . . . . . . . . . . . . . . . . 17 64 5.3.3 Policy Messages. . . . . . . . . . . . . . . . . . . . 18 65 5.3.4 Policy Acknowledgment Messages . . . . . . . . . . . . 18 66 5.3.4 Transfer Messages. . . . . . . . . . . . . . . . . . . 18 67 5.3.5 KeepAlive Messages . . . . . . . . . . . . . . . . . . 19 68 6. Policy Attribute Encoding. . . . . . . . . . . . . . . . . . . 19 69 7. Policy Queries . . . . . . . . . . . . . . . . . . . . . . . . 21 70 7.1 Security Gateway Query . . . . . . . . . . . . . . . . . . 21 71 7.2 COMSEC Query . . . . . . . . . . . . . . . . . . . . . . . 21 72 7.3 Certificate Query. . . . . . . . . . . . . . . . . . . . . 22 73 8. Policy Records . . . . . . . . . . . . . . . . . . . . . . . . 24 74 8.1 Security Gateway Record. . . . . . . . . . . . . . . . . . 24 75 8.2 COMSEC Record. . . . . . . . . . . . . . . . . . . . . . . 25 76 8.3 Security Association Record. . . . . . . . . . . . . . . . 26 77 8.4 Policy Server Record . . . . . . . . . . . . . . . . . . . 28 78 8.5 Certificate Record . . . . . . . . . . . . . . . . . . . . 29 79 9. SPP Message Processing . . . . . . . . . . . . . . . . . . . . 30 80 9.1 General Message Processing . . . . . . . . . . . . . . . . 30 81 9.2 Query Message Processing . . . . . . . . . . . . . . . . . 30 82 9.3 Reply Message Processing . . . . . . . . . . . . . . . . . 33 83 9.4 Policy Message Processing. . . . . . . . . . . . . . . . . 35 84 9.5 Policy Acknowledgment Message Processing . . . . . . . . . 37 85 9.6 KeepAlive Message Processing . . . . . . . . . . . . . . . 38 86 10. Policy Decorrelation Process . . . . . . . . . . . . . . . . . 39 87 10.1 Decorrelation Algorithm . . . . . . . . . . . . . . . . . 40 88 11. Policy Resolution Process. . . . . . . . . . . . . . . . . . . 42 89 12. Usage of SPS with IPSec. . . . . . . . . . . . . . . . . . . . 43 90 Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . . . 46 91 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 92 Appendix A. DATA_TYPE Definitions. . . . . . . . . . . . . . . . . 47 93 Appendix B. Decorrelation Example. . . . . . . . . . . . . . . . . 64 94 Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 95 Author Information . . . . . . . . . . . . . . . . . . . . . . . . 69 96 1. Introduction 98 The Security Policy System (SPS) is a distributed database of 99 security policy information. It provides the mechanisms needed for 100 discovering, accessing and processing security policy information of 101 hosts, subnets or networks of a security domain. 102 In SPS, each security domain has a master file that uniquely 103 defines a security domain by its network resources (hosts, subnets, 104 networks) and the policies to access them. Security policies and the 105 entire domain definition is stored in the Master File. 106 These policies reside in a database local to the security 107 domain. The Policy Server provides access to these policies to client 108 applications requesting policy information for a particular host, 109 subnet or network. SPS provides mechanisms to limit the access of 110 policy records to authorized hosts and/or users. SPS also provides 111 procedures to validate the authenticity and integrity of the policy 112 information exchanged between security domains. 113 Policy Clients generate query databases of different security 114 domains using the Security Policy Protocol. SPS provides a standard 115 set of query types for policy information. New query types can be 116 incorporated as needed. Policy Servers reply to these requests after 117 determining the validity of the request. 118 Since security policies could be highly restrictive and 119 relative to the intended communication between a source and 120 destination, it is possible that the replies provided by a Policy 121 Server would differ depending on the identity of the requestor, making 122 caching of the policies a plausible but complicated process. SPS 123 defines an algorithm that makes the caching of security policies a 124 feasible task. 125 SPS defines the format of the security policy records and the 126 encoding of these before transmission. SPS also defines a standard and 127 extensible message format. SPS specifies the message processing 128 required at the Policy Servers and Policy Clients. 130 1.1 Terms and Technical Definitions 132 1.1.1 Requirements Terminology 134 Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and 135 "MAY" that appear in this document are to be interpreted as described 136 in [Bra97]. 138 1.1.2 Technical Definitions 140 Security Gateway 142 A security gateway refers to an intermediate system that 143 implements IPSec protocols. For example, a router or a 144 firewall implementing IPSec is a security gateway. 146 Security Domain 148 A set of communicating entities and resources that share a 149 common security policy enforced at one or more enforcement 150 agents or at an individual host. The definition of security 151 domain applies to networks protected by security gateways as 152 well as to single hosts, since a host may be the enforcer of 153 its own policies. Security domains could exist inside other 154 security domains. 156 Security Association (SA) 158 A simplex "connection" that affords security services to the 159 traffic it carries. Two types of security associations 160 are defined: transport mode and tunnel mode. A transport 161 mode SA is a security association between two hosts. A 162 tunnel mode SA is essentially an SA applied to an IP tunnel. 163 For transit traffic, whenever either end of a security 164 association is a security gateway, the SA MUST be tunnel mode. 166 Security Association Bundle 168 A group of security associations that are used to protect 169 communications that share a common endpoint. For example, 170 all the SAs that a particular host needs to use to 171 communicate with another host, including any SAs that host 172 itself needs with intermediate security gateways. 174 1.2 Requirements 176 The architectural requirements of the Security Policy System are as follows: 178 - Gateway Discovery 180 SPS must be able to determine a set of necessary security gateways 181 through which a message must travel to complete a communication 182 on a single path between two hosts. 184 - Identity Verification 186 SPS must allow hosts to verify the identities of security gateways 187 and other hosts with which they are communicating. It must 188 also be able to verify that a gateway that claims to represent 189 a particular host actually does have the authority to represent 190 that host. 192 - Require no changes to security protocols 194 SPS must not require changes, additions or modifications to 195 security protocols that use it. 197 - Key Management Protocol Independence 199 SPS must be independent of any particular key management protocol. 201 - Minimal Exterior Infrastructure Dependency 203 SPS SHOULD NOT depend upon an exterior infrastructure, 204 although implementations may use an exterior infrastructure. 205 For example, public keys may be distributed using the 206 existing DNS infrastructure. SPS must not 207 prohibit other means for distributing keys. Particular 208 implementations may, however, rely on the DNS for key 209 distribution, though they may not be as robust as 210 implementations that provide several key distribution 211 mechanisms. 213 2. Overview 215 The Security Policy System is a distributed system which 216 provides hosts and security gateways with the policy information 217 required to establish a secure communication end-to-end through 218 possibly multiple security gateways. The Security Policy System 219 provides one or more automated mechanism for hosts to discover primary 220 and secondary security gateways relevant in an end-to-end 221 communication. Using the Security Policy System, hosts can validate 222 the identity of security gateways and verify that the gateways in 223 question are authorized to represent the source or destination host 224 which they claim to represent. 225 SPS is comprised of Policy Servers (PS), Policy Clients (PC), 226 Master Files and SPS Databases. Master Files contain local policies 227 and other particular information about a security domain. Local policy 228 information combined with non-local policies (policies outside the 229 boundaries of the security domain) form the SPS Databases. Policy 230 Servers receive request messages from policy clients and other policy 231 servers, process them, and provide the appropriate policy information 232 to the requestor based on the request and access control rules. The 233 servers also maintain the SPS databases by loading local and non-local 234 policy information received through SPS exchanges. Policy Clients 235 generate requests for policy information and transform the replies 236 into the appropriate format required by the application using 237 SPS. Figure 1.0 depicts the SPS components. 239 Local : 240 / Policies +----------+ : 241 Master / ---> | SPS | : Non-Local 242 File \ Security | Database | <----- Policies 243 \ Domain +----------+ : 244 Information | : 245 | : 246 +----------+ : 247 | Policy | : 248 | Server | : 249 +----------+ : 250 ^ ^ : 251 +---------+ | | /\ 252 | Policy | | | / \ 253 | Clients |<------ SPP -- --->< SG ><--- SPP ---> External 254 +---------+ \ / Policy Servers 255 \/ and Clients 256 Security : 257 Domain : 259 Figure 1 SPS components and interactions 261 Policy Servers and Clients use the Security Policy Protocol 262 (SPP) to exchange policy information. SPP transports policy 263 information from the SPS Database where this information resides to 264 security gateways and hosts. This protocol provides hosts with the 265 policy information needed to establish security associations with 266 security gateways in the communication path to other hosts, without 267 requiring a-priori knowledge of the identities of the security 268 gateways. 269 Suppose Policy ClientA would like to establish an IPSec 270 protected communication with Policy ClientB. Policy ClientA is unaware 271 of the existence of Security GatewayB (SGB). Similarly, Policy 272 ClientB is unaware of the existence of Security Gateway A 273 (SGA). Furthermore, assumme that SGB and SGA both have policies 274 stating that any inbound communication must be authenticated using ESP 275 [KA98b]. Now, if Policy ClientA initiates negotiations for a security 276 association with Policy ClientB it would fail since SGB requires any 277 inbound packets to be authenticated using ESP and Policy ClientA 278 doesn't have a security association with SGB. 279 SPS provides the mechanisms to resolve this problem. Imagine 280 that the network administrators for Security Domain Foo and Foobar 281 prepare a Master File containing the policies of their respective 282 domains. These are the policies enforced by SGA and SGB do not include 283 specific policies of any of the clients members of a security 284 domain. A security domain could be as small as one host acting as its 285 own Policy Client and Server and, enforcing its own policies, or as 286 large as many networks with several Policy Servers and Security 287 Gateways. 288 Both Master Files are first parsed and verified to avoid 289 syntax errors. Policies within the Master Files are decorrelated using 290 the decorrelation process specified in section 10. Policy Server A and 291 B load the policies from their respective security domains into their 292 SPS Databases and listen for policy requests. 294 Security Security 295 Domain Foo Domain Foo 297 +----------+ +----------+ 298 | Policy | | Policy | 299 | ServerA | | ServerB | 300 +----------+ +----------+ 301 ^ ^ ^ ^ 302 +---------+ Q1 | | Q2 /\ /\ Q2 | | Q3 +----------+ 303 | Policy | R1 | | R2 / \ Q2/R2 / \ R2 | | R3 | Policy | 304 | ClientA |<--- -----><------><--- ---->| ClientB | 305 +---------+ \ / \ / +----------+ 306 \/ \/ 308 Figure 2 Example of SPS operation 310 Now suppose that Policy ClientA had a facility enabling it to 311 request policy information to Policy Server A dynamically. The policy 312 request message could be triggered by a message sent from the kernel 313 to a Key Management Protocol. So, Policy ClientA sends a Query (Q1) to 314 Policy ServerA. Policy ServerA looks in its cache for a policy record 315 that matches the query. If it doesn't find one it sends a Query (Q2) 316 containing the same policy request information destined to Policy 317 ClientB. This message includes a signature that validates the 318 authenticity and integrity of the query's content. 319 (Q2) is intercepted by SGB. SGB forwards the message (Q2) to 320 Policy ServerB. Policy serverB first verifies that it can accept 321 queries from Policy ServerA. It then validates the signature in 322 Q2. It searches its database for the appropriate policy information 323 after verifying that it is authoritative over Policy ClientB. 324 Policy ServerB first merges its local policy with the policy 325 information in (Q2) and it then replies (R2) to Policy ServerA. The 326 reply includes the original query information and all policy 327 information needed to allow Policy ClientA to establish a secure 328 communication with Policy ClientB. The merging or policy resolution 329 process helps in determining any policy conflicts and ambiguities. 330 It is possible for Policy ServerB to query Policy ClientB for 331 its policy with respect to this particular communication. Policy 332 ServerB could generate then a third query (Q3). Policy ClientB 333 responds with its policy in (R3). Policy ServerB merges its policy for 334 this communication and the policy in (R3) before replying to Policy 335 ServerA. Policy ServerB also attached additional information to the 336 reply asserting its authority over Policy ClientB. This chain of trust 337 MUST be validated cryptographically. The merged policy returns in (R2) 338 to Policy ServerA where it merges its local policy with the external 339 policy received in (R2) and caches it for later use. 340 A protocol such as SPP accommodates topology changes, hence 341 policy changes, rather easily without the scalability constraints 342 imposed by static reconfiguration of each client. The protocol is 343 extensible and flexible It allows the exchange of complex policy 344 objects between clients and servers. 346 3. Policy Master File 348 In SPS, policy information of a particular security domain is 349 stored in a Master File. SPS does not impose a particular format for 350 the data store in a master file. SPSL [SPSL] defines a vendor 351 independent language that can be used to define policy information for 352 a security domain. Master Files however, must contain the information 353 specified below. The order in which the policy information appears in 354 the Master File is extremely important since most policy enforcers 355 search for the first policy entry that matches the characteristics of 356 a particular packet. Any other applicable policy found after the first 357 match is ignored. 359 Master files require the following information: 361 certificate 363 This information points to one or more certificates to be 364 referenced by the maintainer information. The private key 365 corresponding to the public key found in this certificate is 366 used to sign the information contained in the master 367 file. The public key is used to verify the information's 368 integrity and authenticity. 370 maintainer 372 This information defines the entities authorized to create, 373 delete and modify the policy information in a particular 374 Master File. 376 policy-server 378 This information specifies the identity of the primary 379 and secondary policy servers for a particular security domain. 381 nodes 382 This information identifies a set of interfaces that may have 383 policies attached to them. There must be at least one node in a 384 security domain. 386 gateway 387 This information identifies a set of interfaces associated 388 with a host that enforces the policies of a particular 389 security domain. 391 domain 392 The domain information defines a security domain in terms of 393 the nodes, the security gateways and the policy servers that 394 are part of it. 396 policy 397 An ordered set of policies. These policies cover the domain or 398 domains describe by the preceding information. 400 The Master file contains the list of nodes that are part of the 401 security domain, the list of security gateways protecting the security 402 domain, a list of the policy rules enforced by the security gateways 403 and possibly the policy rules enforced at the nodes. 404 The Master File MUST contain information indicating who is 405 responsible for the security domain and a pointer to a public key that 406 can be used to verify the integrity and authenticity of the 407 information found in the master file. 409 4. Policy Database 411 In SPS, every security domain MUST maintain a database 412 containing the policy information for that domain. Security domains 413 could be as small as one host or as large as several networks. This 414 database, called the SPS Database, is comprised of three logical 415 databases: 1) the Local Policy Database, 2) the Cache Database and, 3) 416 the Security Domain Database. 417 The Local Policy Database contains all the policies for the 418 security domain. It is populated with information coming from the 419 Master File of the security domain. The Cache Database contains local 420 and external policies received from other security domains via SPS 421 exchanges. The policies are merged using the policy resolution process 422 specified in section 11. The Security Domain Database contains a list 423 of all hosts, security gateways, and policy servers that are part of 424 the security domain. 425 Compliant SPS implementations of a policy client and server do 426 not need to implement these three databases separately. However, the 427 information contained in each one of them MUST exist. The Local 428 Database and the Cache Database MUST keep a distinct sets of policies 429 since it is not possible to revert cached policy information into 430 Local Database policy information after the cached items expire. 431 While it is not necessary to standardize the format of the 432 database used, the SPS database MUST contain a minimum set of 433 information. The next three subsections describe each database in 434 terms of its functionality and requirements. 436 4.1 Local Policy Database 438 Every policy client and every policy server MUST keep a 439 database containing its local policy. In the client case, the policy 440 is kept in some pre-configured form and loaded into the database. The 441 database could be the same as the client's Security Policy Database 442 (SPD) as defined in [kent98]. In the server's case the information 443 found in the Local Policy Database applies to all the members of the 444 security domain and therefore it MUST be kept separate from the 445 server's own policy information found in its SPD. 446 The Local Policy Database MUST contain the policies expressed 447 in the Master File for the security domain. Policies are divided into 448 a clause section and an action section. The clause section describes a 449 particular communication while the action clause indicates what should 450 be done with the communication. 451 Each policy entry MUST contained a unique identifier, an 452 expiration time, and a single policy clause followed by each action 453 clause that applies to that policy clause. In terms of the Security 454 Policy Protocol, the clause portion of the policy is encoded in 455 communication security records and the action portion (if IPSec 456 related) is encoded in security association records. 457 Policies in this database MUST be decorrelated as defined in 458 section 10. An algorithm for policy decorrelation is presented in 459 section 10.1. Decorrelated policies allow for efficient reordering and 460 organization of the policies without affecting the enforcement 461 process. Policy decorrelation also facilitates the caching of external 462 policies. 464 4.2 Cache Database 466 In addition to the information stored in the Local Policy 467 Database, every policy client and server MUST keep a cache of merged 468 local and non-local policy data. Non-local policies are policies which 469 do not exist in some pre-configured form in a policy client or 470 server. These policies are learned through SPS exchanges. 471 Non-local policies are merged with Local Database policies 472 using the policy resolution process discussed in section 11. The 473 resultant merged policies MUST be kept logically separate from the 474 local policies. The cached data then can be used to answer subsequent 475 queries for the same policy information. 476 Each policy entry MUST contain a unique identifier, an 477 expiration time, and typically a single policy clause followed by each 478 action clause that applies to that policy clause. A policy entry MAY 479 contain multiple policy clauses each followed by action clauses, if 480 the policy must be enforced at multiple endpoints. Each policy entry 481 MUST also contain any assertion information that could indicate the 482 relationship between the policy server that provide the SPS message 483 and the information in the policy exchange. It SHOULD also include any 484 public keying material (e.g. certificates, etc.) that might be needed 485 to validate the assertions made by policy servers. In terms of the 486 Security Policy Protocol, policy server assertions, and certificates 487 are encoded in policy server and certificates records, respectively. 488 Policy Clients and Servers MUST NOT cache policies 489 indefinitely, since cached policies have a non-local component that 490 may change without warning. Each policy entry MUST contain an 491 expiration time that MUST be considered as the maximum amount of time 492 that this policy MAY be cached. Longer cache expiry times should be 493 associated with policies that are less likely to change, while shorter 494 cache expiry times should be associated with policies that are likely 495 to change. As in the Local Policy Database, policies in the Cache 496 Database MUST be decorrelated as defined in section 10. 498 4.3 Security Domain Database 500 A Policy Server MUST also maintain information that describes 501 the security domain for which it is authoritative. This information 502 includes a list with the identities of each security gateway enforcing 503 policies at the perimeter of the security domain and an entry 504 indicating the identities of the nodes that are members of the 505 security domain. 507 Policy servers use this information to determine that they 508 are authoritative over the host for which they are providing policy 509 information. It also allows policy servers to determine if they 510 may participate in an SPP exchange without violating the chain 511 of trust that the recipient of the information will require to 512 verify the authenticity of the policy. 514 5. Security Policy Protocol (SPP) 516 Policy clients and servers exchange information using the 517 Security Policy Protocol. The protocol defines how the policy 518 information is exchanged, processed, and protected by clients and 519 servers. The protocol also defines what policy information is 520 exchanged and the format used to encode the information. The protocol 521 specifies six different message types used to exchange policy 522 information. An SPP message contains a message header section followed 523 by zero or more SPP payloads, depending on the message type. 524 Figure 3 depicts the format of an SPP message. The header 525 section is present in every message. It contains fields identifying 526 the message, the type of message, the status of the message, the 527 number of queries and/or record payloads, and the host requesting 528 policy information. The header also includes a timestamp field that 529 provides anti-replay protection. Following the header there might be 530 zero or more SPP payloads. Currently, there are three payload types 531 defined in SPP: Query, Record, and Signature payloads. See section 5.2 532 for encoding details. 533 SPP has six distinct message types. Query messages contain a 534 specific request for policy information. Reply messages include policy 535 records that answer specific policy queries. Policy messages include 536 policy information and are utilized for up/downloading security 537 policies to and from a policy server. Policy Acknowledgment messages 538 are utilized to acknowledge corresponding Policy messages but do not 539 themselves contain policy information. Transfer messages, which 540 include policy information, are utilized by policy servers to exchange 541 bulk policy information between servers. Finally, policy servers use 542 keep alive messages to inform security gateways and/or other 543 monitoring devices of the status of the server. 544 SPP messages MUST be authenticated either using IPSec [Kent98] 545 or another security mechanism. SPP provides a basic security mechanism 546 that can be used to provide authentication and integrity to its 547 messages, especially when traversing heterogenous domains and the 548 identity of the policy server authoritative for the destination is 549 unknown. These services are provided using digital signatures. 550 SPP caries signatures in the signature payload. The signature 551 is calculated over the entire SPP message. When this service is used, 552 the entity (host, policy server or security gateway) verifying the 553 signature must have access to the public key that corresponds to the 554 private key used to sign the SPP message. 555 Certificate fetching is out of the scope of SPP. However, SPP 556 provides a simple certificate fetching mechanism for entities that 557 elect to use it as an alternative to other mechanisms. SPP suports 558 several Public Key certificates formats. 560 SPP is modular and extensible. New policy queries and records 561 can be defined and incorporated easily. This document defines a 562 minimum set of queries and policy records required in a policy-based 563 security management system. 565 5.1 SPP Message Format 567 An SPP message follows the format depicted in figure 3. It is 568 comprised of a header and zero or more SPP payloads. This section 569 defines the encoding for the SPP header. Sections 5.2 and 5.3 cover 570 the encoding for the SPP payload and message types, respectively. 572 0 1 2 3 573 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 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----- 575 | MESSAGE ID | | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 577 | MTYPE | MCODE | QCOUNT | RCOUNT | | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 579 | IDENTITY TYPE | RESERVED | | 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 581 | | SPP 582 + TIMESTAMP + Header 583 | | | 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 585 | | | 586 ~ SENDER IDENTITY ~ | 587 | | | 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----- 589 | | SPP 590 + SPP PAYLOADS... |Payloads 591 | 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----- 594 Figure 3: Format of an SPP Message 596 The SPP header includes the following fields: 598 MESSAGE ID 599 A 4 octet field used to match messages and their responses 600 (e.g. queries to replies and policy to policy acknoledgement 601 messages). This value starts at "zero" and MUST be incremented 602 by (01)hex with every new message. 604 MTYPE 605 A 1-octet field indicating the SPP message type. 606 The currently defined values are: 608 Value Message Type 610 00 Value Not Assigned 611 01 SPP-QUERY 612 02 SPP-REPLY 613 03 SPP-POL 614 04 SPP-POL_ACK 615 05 SPP-XFR 616 06 SPP-KEEP_ALIVE 617 07-255 Reserved 619 MCODE 620 A 1-octet field providing information about this message. 621 See section 5.3 for the codes applicable to each message type. 623 Code Action 624 Field Type 626 00 Value Not Assigned 627 01 message accepted 628 02 denied, administratively prohibited 629 03 denied, timestamp failed 630 04 denied, failed signature 631 05 denied, insufficient resources 632 06 denied, malformed message 633 07 denied, unspecified 634 08 partially available 635 09 unavailable 636 10 communication prohibited 637 11-255 reserved 639 QCOUNT 640 A 1 octet field indicating the number of Query payloads included 641 in the message. 643 RCOUNT 644 A 1 octet field indicating the number of Record payloads 645 included in the message. 647 IDENTITY TYPE 649 This 1 octet field indicates the type of indentity found in 650 the Sender Identity field. Valid values are: 652 Value Identity Type 654 00 Value Not Assigned 655 01 IPV4_ADDR 656 02 IPV6_ADDR 657 03 Host DNS Name 658 04-255 Reserved 660 RESERVED 661 A 3 octet field used for field 32-bit boundary alignment and 662 reserved for future use. Set value to all zeros (00)hex. 664 TIMESTAMP 666 This 8-octet field contains a timestamp used to provide 667 limited protection against replay attacks. The timestamp 668 is formatted as specified by the Network Time Protocol 669 [RFC1305]. 671 SENDER IDENTITY 673 A variable length field containing the identity of the sender 674 (host, security gateway or policy server) of the SPP 675 message. The IDENTITY_TYPE field indicates the format of the 676 content in this field. This field does not allow IP address 677 ranges or wildcards. 679 5.2 SPP Payloads 681 5.2.1 Query Payload 683 The Query payload contains fields to express a particular 684 request for policy information. Hosts, security gateways, or policy 685 servers can generate and transmit Query payloads in SPP messages to 686 policy servers. Figure 4 shows the format of the Query payload. 688 0 1 2 3 689 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 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 691 | PCL | PID | RESERVED | 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 | TYPE | LENGTH | 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 | QUERY Data ... 696 +-+-+-+-+-+-+-+- 698 Figure 4: Format of Query Payload 700 The Query Payload fields are defined as follows: 702 PCL 703 A 1 octet field indicating the payload class. Query payloads 704 MUST contain (01)hex in the PCL field. 706 PID 707 A 1 octet field containing the ID number that identifies a 708 particular Query payload within an SPP message. Since one 709 SPP message can contain multiple Query payloads, each one 710 MUST be uniquely identified. This number MUST be unique 711 among the Query payloads within an SPP message. 713 RESERVED 715 A 2 octet field reserved for future use. Set value to all 716 zeros (00)hex. 718 TYPE 719 A 2 octet field that specifies the type of query contained in 720 the QUERY Data fields. The currently defined queries are: 722 Value Query Payload Type 724 00 Value Not Assigned 725 01 Security Gateway Query 726 02 Communication Security Query 727 03 Certificate Query 728 04-65536 Reserved 730 LENGTH 731 A 2 octet field indicating the length in octets of the query 732 data field. 734 QUERY Data 736 A variable length field containing a single policy query. See 737 section 7 for encoding format. 739 5.2.2 Record Payload 741 The Record payload contains fields that assert policy 742 information. Hosts, security gateways, or policy servers can generate 743 and transmit Record payloads in SPP messages. Figure 5 shows the 744 format of the Record payload. 746 0 1 2 3 747 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 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 | PCL | PID | RESERVED | 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 | TYPE | LENGTH | 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 | RECORD Data ... 754 +-+-+-+-+-+-+-+- 756 Figure 5: Format of Record Payload 758 The Record Payload fields are defined as follows: 760 PCL 761 A 1 octet field indicating the payload class. Record payloads 762 MUST contain (02)hex in the PCL field. 764 PID 765 This field is used to match queries to Record payloads. If 766 the record is a reply to a query, then the value for this 767 field MUST match the correspondent Query payload PID. If it 768 is not a reply to a query, the value SHOULD be set to zero. 770 RESERVED 772 A 2 octet field reserved for future use. Set value to all 773 zeros (00)hex. 775 TYPE 776 A 2 octet field that specifies the type of Record. The 777 currently defined records are: 779 Value Record Type 781 00 Value Not Assigned 782 01 Security Gateway Record 783 02 Communication Security Record 784 03 Security Association Record 785 04 Certificate Record 786 05 Policy Server Record 787 06-65536 Reserved 789 LENGTH 790 A 2 octet field indicating the length in octets of the RECORD 791 data field. 793 RECORD Data 795 A variable length field containing a single policy record. See 796 section 8 for encoding format. 798 5.2.3 Signature Payload 800 The Signature Payload contains data generated by the digital 801 signature function (selected by the originator), over the entire SPP 802 message, except for part of the Signature payload. This payload is 803 used to verify the integrity of the data in the SPP message. Figure 6 804 shows the format of the Signature payload. 806 0 1 2 3 807 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 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 809 | PCL | TYPE | LENGTH | 810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 811 | SIGNATURE Data ... 812 +-+-+-+-+-+-+-+- 814 Figure 6: Signature Payload Format 816 The Signature payload fields are defined as follows: 818 PCL 819 A 1 octet field indicating the payload class. Signature payloads 820 MUST contain (03)hex in the PCL field. 822 TYPE 823 A 1 octet field that specifies the signature algorithm 824 employed. The currently defined signature types are: 826 Value Algorithm Type 828 00 Value Not Assigned 829 01 RSA 830 02 DSA 831 03-255 Reserved 833 LENGTH 834 A 2 octet field indicating the length in octets of the 835 SIGNATURE Data field. 837 SIGNATURE Data 839 A variable length field that contains the results from 840 applying the digital signature function to the entire 841 SPP message (including the PCL, TYPE, and LENGTH fields 842 of the Signature payload), except for the Signature Data 843 field of the Signature payload. 845 5.3 SPP Messages 847 5.3.1 Query Message 849 An SPP-QUERY message is comprised of an SPP header, one or 850 more Query payloads, zero or more Record payloads, and a Signature 851 payload, if one is required. Query messages MUST always contain a Query 852 payload. Record payloads may optionally be included to pass policy 853 information along with the query. If the Signature payload is employed 854 it MUST be the last payload in the message. The Query message MTYPE 855 value is (01)hex. The MCODE field must be set to zero (00)hex. 857 5.3.2 Reply Message 859 An SPP-REPLY message is comprised of an SPP header, one or 860 more Query payloads, zero or more Record payloads which answer the 861 corresponding Query payload, and a Signature payload, if one is 862 required. Reply messages MUST contain a Query payload. Reply messages 863 MUST include a Record payload unless the reply contains an error code 864 of values (02-08). If the Signature payload is employed it MUST be the 865 last payload in the message. The MTYPE value for a Reply message is 866 (02)hex. The following MCODE values may be used for Reply messages: 868 Code Action 869 Field Type 871 01 message accepted 872 02 denied, administratively prohibited 873 03 denied, timestamp failed 874 04 denied, failed signature 875 05 denied, insufficient resources 876 06 denied, malformed message 877 07 denied, unspecified 878 08 partially available 879 09 unavailable 880 10 communication prohibited 882 5.3.3 Policy Message 884 An SPP-POL message is comprised of an SPP header, one or more 885 Record payloads, and a Signature payload, if one is required. Policy 886 messages MUST NOT include Query payloads. If the Signature payload is 887 employed it MUST be the last payload in the message. The MTYPE value 888 for a Policy message is (03)hex. The MCODE field must be set to zero 889 (00)hex. 891 5.3.4 Policy Acknowledgement Message 893 An SPP-POL_ACK message is comprised of an SPP header and a 894 Signature payload, if one is required. These messages MUST NOT contain 895 Query or Record payloads. The status of the associated Policy message 896 is expressed within the MCODE field. If the Signature payload is 897 employed it MUST be the only payload in the message. The MTYPE value 898 for a Policy Acknowledgement message is (04)hex. The following MCODE 899 values may be used for Policy Acknowledgement messages: 901 Code Action 902 Field Type 904 01 message accepted 905 02 denied, administratively prohibited 906 03 denied, timestamp failed 907 04 denied, failed signature 908 05 denied, insufficient resources 909 06 denied, malformed message 910 07 denied, unspecified 912 5.3.5 Transfer Message 914 An SPP-XFR message is comprised of an SPP header, one or more 915 Record payloads, and a Signature payload, if one is required. Transfer 916 messages MUST NOT include Query payloads. If the Signature payload is 917 employed it MUST be the last payload in the message. The MTYPE value 918 for a Transfer message is (05)hex. The MCODE field must be set to zero 919 (00)hex. 921 5.3.6 KeepAlive Message 923 An SPP-KEEP_ALIVE message is comprised of an SPP header and a 924 Signature payload, if one is required. These messages MUST NOT contain 925 Query or Record payloads. If the Signature payload is employed it MUST 926 be the only payload in the message. The MTYPE value for a KeepAlive 927 message is (06)hex. The MCODE field must be set to zero (00)hex. 929 6.0 Policy Attribute Encoding 931 Query and Record payloads include several different selector 932 types and SA attributes with their associated values. These data are 933 encoded following a Type/Length/Value (TLV) format to provide 934 flexibility for representing different kinds of data within a 935 payload. Certain Data_Types with values of length equal to 2 octets 936 follow the Type/Value (T/V) format. The first bit of the DATA_TYPE 937 field is used to distinguished between the two formats. A value of (0) 938 indicates a TLV format while a value of (1) indicates TV format. This 939 generic encoding format is depicted in figure 7. 941 X = 0: 943 0 1 2 3 944 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 945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 946 |X| DATA_TYPE | LENGTH | 947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 948 | DATA_VALUE... 949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 951 X = 1: 953 0 1 2 3 954 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 955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 956 |1| DATA_TYPE | DATA_VALUE... 957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 959 Figure 7: Generic Data Attribute Formats 961 The generic data attribute fields are defined as follows: 963 X 964 This bit indicates if the DATA_TYPE follows the TLV(0) or the 965 TV(1) format. 967 DATA_TYPE 969 A 2 octet field indicating the selector type. The currently 970 defined values are: 972 DATA DATA_TYPE X 974 IPV4_ADDR 1 0 975 IPV6_ADDR 2 0 976 SRC_IPV4_ADDR 3 0 977 SRC_IPV4_ADDR_SUBNET 4 0 978 SRC_IPV4_ADDR_RANGE 5 0 979 DST_IPV4_ADDR 6 0 980 DST_IPV4_ADDR_SUBNET 7 0 981 DST_IPV4_ADDR_RANGE 8 0 982 SRC_IPV6_ADDR 9 0 983 SRC_IPV6_ADDR_SUBNET 10 0 984 SRC_IPV6_ADDR_RANGE 11 0 985 DST_IPV6_ADDR 12 0 986 DST_IPV6_ADDR_SUBNET 13 0 987 DST_IPV6_ADDR_RANGE 14 0 988 DIRECTION 15 1 989 USER_NAME 16 0 990 SYSTEM_NAME 17 0 991 XPORT_PROTOCOL 18 0 992 SRC_PORT 19 0 993 SRC_PORT_DYNAMIC 20 0 994 DST_PORT 21 0 995 DST_PORT_DYNAMIC 22 0 996 SEC_LABELS 23 0 997 V6CLASS 24 1 998 V6FLOW 25 0 999 V4TOS 26 1 1000 ACTION 27 1 1001 SRC_PORT_RANGE 28 0 1002 DST_PORT_RANGE 29 0 1004 IPSEC_ACTION 50 0 1005 ISAKMP_ACTION 51 0 1007 RESERVED 30-49, 52-32767 1009 LENGTH 1011 A 2 octet field indicating the length of the selector value in 1012 octets, not including any trailing padding added to the 1013 DATA_VALUE field. The padding length is implicit. 1015 DATA_VALUE 1017 A variable length field containing the value of the selector 1018 specified by DATA_TYPE. If the Selector value is not aligned at 1019 the 4 octet boundary the field MUST be padded on the right with 1020 (00)hex to align on the next 32-bit boundary. 1022 7. Policy Queries 1024 7.1 Security Gateway Query 1026 This basic query provides a dynamic mechanism to determine 1027 which relevant security gateways, both primary and backup, are in the 1028 path to a particular destination address. Since the answer to a 1029 request for information could depend on the identity of the requestor, 1030 the host address of the source of the intended communicaton is 1031 included in the query. Figure 8 shows the format of the Security 1032 Gateway Query. 1034 0 1 2 3 1035 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 1036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1037 | | 1038 ~ SOURCE ADDRESS DATA ~ 1039 | | 1040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1041 | | 1042 ~ DESTINATION ADDRESS DATA ~ 1043 | | 1044 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1046 Figure 8: Security Gateway Query Format 1048 The Security Gateway Query fields are defined as follows: 1050 SOURCE ADDRESS DATA 1052 This variable length field contains a single IP address 1053 (unicast) either in IPv4 or IPv6 format. The encoding 1054 format is specified in section 6. The acceptable DATA_TYPE 1055 values are 3 and 9. 1057 DESTINATION ADDRESS DATA 1059 This variable length field contains a single IP address 1060 (unicast) either in IPv4 or IPv6 format. The encoding 1061 format is specified in section 6. The acceptable DATA_TYPE 1062 values are 6 and 12. 1064 7.2 COMSEC Query 1066 The Communication Security Query (or COMSEC query) provides a 1067 dynamic mechanism for a host or security gateway to inquire if a 1068 communication having a particular set of characteristics is 1069 allowed. The communication is described in terms of source and 1070 destination addresses, protocols, source port, destination port, and 1071 other parameters as defined in section 6. These parameters are known 1072 as selectors in the IPSec context and are primarily the contents of 1073 the IP and TCP headers. Figure 9 shows the format of the COMSEC 1074 Query. 1076 0 1 2 3 1077 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 1078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1079 | | 1080 ~ SOURCE ADDRESS DATA ~ 1081 | | 1082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1083 | | 1084 ~ DESTINATION ADDRESS DATA ~ 1085 | | 1086 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1087 | SELECTOR DATA ... 1088 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1090 Figure 9: COMSEC Query Format 1092 The COMSEC Query fields are defined as follows: 1094 SOURCE ADDRESS DATA 1096 This variable length field contains a single IP address 1097 (unicast) either in IPv4 or IPv6 format. The encoding 1098 format is specified in section 6. The acceptable DATA_TYPE 1099 values are 3 and 9. 1101 DESTINATION ADDRESS DATA 1103 This variable length field contains a single IP address 1104 (unicast) either in IPv4 or IPv6 format. The encoding 1105 format is specified in section 6. The acceptable DATA_TYPE 1106 values are 6 and 12. 1108 SELECTOR DATA 1110 This includes one or more fields following the encoding format 1111 specified in section 6. The acceptable DATA_TYPE values are 1112 15-29, inclusive. 1114 7.3 CERT Query 1116 Mechanisms to dispatch and fetch public-key certificates are 1117 not part of SPP. However, in the absence of external request/dispatch 1118 mechanisms, SPP provides for a certificate request query that allows a 1119 host, security gateway, or server to solicit a certificate. Figure 9 1120 shows the format of the CERT Query. 1122 1 2 3 1123 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 1124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1125 | CERT_TYPE | IDENTITY_TYPE | AUTHORITY_TYPE| RESERVED | 1126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1127 | | 1128 ~ IDENTITY ~ 1129 | | 1130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1131 | | 1132 ~ CERTIFICATE AUTHORITY ~ 1133 | | 1134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1136 Figure 9: Certificate Query Format 1138 The Certificate query fields are defined as follows: 1140 CERT_TYPE 1142 A 1 octet field that contains an encoding of the type of 1143 certificate requested. Acceptable values are listed below: 1145 Certificate Type Value 1147 Value Not Assigned 0 1148 PKCS #7 wrapped X.509 certificate 1 1149 PGP Certificate 2 1150 DNS Signed Key 3 1151 X.509 Certificate - Signature 4 1152 X.509 Certificate - Key Exchange 5 1153 Kerberos Tokens 6 1154 SPKI Certificate 7 1155 RESERVED 8 - 255 1157 IDENTITY_TYPE 1159 This 1 octet field indicates the type of indentity found in 1160 the Identity field. Valid values are listed below: 1162 Value Identity Type 1164 0 Value Not Assigned 1165 1 IPV4_ADDR 1166 2 IPV6_ADDR 1167 3 DNS Name 1168 4 X.500 Distinguished Name 1169 5-255 Reserved 1171 AUTHORITY_TYPE 1173 This 1 octet field indicates the type of authority found in 1174 the Certificate Authority field. Valid values are the same as 1175 IDENTITY_TYPE. 1177 IDENTITY 1179 This variable length field contains the identity of the 1180 principal by which the certificate should be located. The 1181 value MUST be of the type stated in IDENTITY_TYPE. 1183 CERTIFICATE AUTHORITY 1185 A variable length field containing an encoding of an 1186 acceptable certificate authority for the type of certificate 1187 requested. The value MUST be of the type stated in 1188 AUTHORITY_TYPE. 1190 8. Policy Records 1192 8.1 Security Gateway Record 1194 This record contains information that indicates the IP 1195 addresses of the interfaces for the the primary and secondary security 1196 gateways protecting a host or group of hosts. The record contains the 1197 primary and secondary gateways at one point in the path that an IP 1198 datagram originated from the source address listed in the Security 1199 Gateway query will have to traverse to reach the destination address 1200 listed in that query. If the IP datagram must traverse multiple 1201 gateways, a Security Gateway Record must be included for each gateway. 1202 The list of secondary security gateways is optional. Figure 10 shows 1203 the format of the Security Gateway Record. 1205 0 1 2 3 1206 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 1207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1208 | CACHE-EXPIRY | 1209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1210 | FLAGS | RESERVED | 1211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1212 | | 1213 ~ PRIMARY SG ADDRESS ~ 1214 | | 1215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1216 | SECONDARY SG ADDRESSES 1217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1219 Figure 10: Security Gateway Record Format 1221 The Security Gateway Record fields are defined as follows: 1223 CACHE-EXPIRY 1225 A 4 octet field indicating the maximum amount of time, 1226 in seconds, this policy record MAY be cached. 1228 FLAGS 1230 A 2 octet field indicating different options to aid in 1231 interpreting the security gateway data. If not in use, set 1232 value to all zeros (00)hex. Currently, no flag values are 1233 defined so this field MUST be set to (00)hex. 1235 RESERVED 1237 A 2 octet field reserved for future use. If not in use, set 1238 value to all "zeros". 1240 PRIMARY SG ADDRESS 1242 A variable length field containing the IP address of the primary 1243 security gateway for protecting a particular host. This 1244 variable length field contains a single unicast IP 1245 address. The encoding format is specified in section 6. 1246 The acceptable DATA_TYPE values are 1 and 2. 1248 SECONDARY SG ADDRESSES 1250 This variable length field contains the IP addresses of 1251 secondary security gateways protecting a particular host. This 1252 field may contain a list of single unicast IP addresses. The 1253 encoding format is specified in section 6. The acceptable 1254 DATA_TYPE values are 1 and 2. 1256 8.2 COMSEC Record 1258 The COMSEC record indicates if a communication having a 1259 particular set of characteristics is allowed or not. The communication 1260 is described in terms of source and destination addresses, protocols, 1261 source ports, destination ports, and other attributes defined in 1262 section 6. Figure 11 shows the format of the COMSEC Record. 1264 0 1 2 3 1265 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1267 | CACHE-EXPIRY | 1268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1269 | FLAGS | RESERVED | 1270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1271 | | 1272 ~ SOURCE ADDRESS DATA ~ 1273 | | 1274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1275 | | 1276 ~ DESTINATION ADDRESS DATA ~ 1277 | | 1278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1279 | SELECTOR DATA ... 1280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1282 Figure 11: COMSEC Record Format 1284 The COMSEC Record fields are defined as follows: 1286 CACHE-EXPIRY 1288 A 4 octet field indicating the maximum amount of time, 1289 in seconds, this policy record MAY be cached. 1291 FLAGS 1293 A 2 octet field indicating different options to aid in 1294 interpreting the selector data. If not in use, set 1295 value to all zeros (00)hex. Currently, no flag values are 1296 defined so this field MUST be set to (00)hex. 1298 RESERVED 1300 A 2 octet field reserved for future use. If not in use, set 1301 value to all zeros (00)hex. 1303 SOURCE ADDRESS DATA 1305 This variable length field contains a single IP 1306 address (unicast, anycast, broadcast (IPv4 only), or multicast 1307 group), range of addresses (low and high values, inclusive), 1308 address + mask, or a wildcard address. The encoding format is 1309 specified in section 6. The acceptable DATA_TYPE values are 1310 3-5 and 9-11, inclusive. 1312 DESTINATION ADDRESS DATA 1314 This variable length field contains a single IP 1315 address (unicast, anycast, broadcast (IPv4 only), or multicast 1316 group), range of addresses (low and high values, inclusive), 1317 address + mask, or a wildcard address. The encoding format is 1318 specified in section 6. The acceptable DATA_TYPE values are 1319 6-8 and 12-14, inclusive. 1321 SELECTOR DATA 1323 This includes one or more fields following the encoding format 1324 specified in section 6. The acceptable DATA_TYPE values are 1325 15-29, inclusive. 1327 8.3 Security Association Record 1329 Security Association Records contain selectors and security 1330 association attributes (APPLIERS) that characterize a particular 1331 Security Association between the source and destination addresses 1332 listed in the record. This record contains data types as defined in 1333 the section 6. Figure 12 shows the format of the SA Record. 1335 0 1 2 3 1336 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 1337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1338 | CACHE-EXPIRY | 1339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1340 | FLAGS | RESERVED | 1341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1342 | | 1343 ~ SOURCE ADDRESS DATA ~ 1344 | | 1345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1346 | | 1347 ~ DESTINATION ADDRESS DATA ~ 1348 | | 1349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1350 SELECTOR DATA AND APPLIERS... 1351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1353 Figure 12: SA Record Format 1355 The SA record fields are defined as follows: 1357 CACHE-EXPIRY 1359 A 4 octet field indicating the maximum amount of time, 1360 in seconds, this policy record MAY be cached. 1362 FLAGS 1364 A 2 octet field indicating different options to aid in 1365 interpreting the selector data. If not in use, set 1366 value to all zeros (00)hex. Currently, no flag values are 1367 defined so this field MUST be set to (00)hex. 1369 RESERVED 1371 A 2 octet field reserved for future use. If not in use, set 1372 value to all zeros (00)hex. 1374 SOURCE ADDRESS DATA 1376 This variable length field contains a single IP 1377 address (unicast, anycast, broadcast (IPv4 only), or multicast 1378 group), range of addresses (low and high values, inclusive), 1379 address + mask, or a wildcard address. The encoding format is 1380 specified in section 6. The acceptable DATA_TYPE values are 1381 3-5 and 9-11, inclusive. 1383 DESTINATION ADDRESS DATA 1385 This variable length field contains a single IP 1386 address (unicast, anycast, broadcast (IPv4 only), or multicast 1387 group), range of addresses (low and high values, inclusive), 1388 address + mask, or a wildcard address. The encoding format is 1389 specified in section 6. The acceptable DATA_TYPE values are 1390 6-8 and 12-14, inclusive. 1392 SELECTOR DATA AND APPLIERS 1394 This includes one or more fields following the encoding format 1395 specified in section 6. The acceptable DATA_TYPE values are 1396 15-29 and 50-51, inclusive. 1398 8.4 Policy Server Record 1400 The Policy Server record indicates the host, security gateway, 1401 or policy server for which a particular policy server is 1402 authoritative. It represents an assertion, typically made by a policy 1403 server, with repect to a member of a security domain that the server 1404 represents. The record includes the Identity of the policy server and 1405 the identity of a node (host, security gateway, another server, etc.). 1406 Figure 13 shows the format of the Policy Server Record. 1408 0 1 2 3 1409 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 1410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1411 | CACHE-EXPIRY | 1412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1413 | FLAGS | RESERVED | 1414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1415 | | 1416 ~ POLICY SERVER IDENTITY ~ 1417 | | 1418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1419 | | 1420 ~ NODE IDENTITY ~ 1421 | | 1422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1424 Figure 13: Policy Server record format 1426 The Policy Server Record fields are defined as follows: 1428 CACHE-EXPIRY 1430 A 4 octet field indicating the maximum amount of time, 1431 in seconds, this policy record MAY be cached. 1433 FLAGS 1435 A 2 octet field indicating different options to aid in 1436 interpreting the server and node data. If not in use, set 1437 value to all zeros (00)hex. Currently, no flag values are 1438 defined so this field MUST be set to (00)hex. 1440 RESERVED 1442 A 2 octet field reserved for future use. If not in use, set 1443 value to all zeros (00)hex. 1445 POLICY SERVER IDENTITY 1447 This variable length field contains the identity of the 1448 policy server. It may contain an IP address (unicast) 1449 either in IPv4 or IPv6 format. The encoding format is 1450 specified in section 6 The acceptable DATA_TYPE values 1451 are 1 and 2. 1453 NODE IDENTITY 1455 This variable length field contains the identity of a node 1456 for which the policy server is authoritative. It may contain 1457 an IP address (unicast) either in IPv4 or IPv6 format. The 1458 encoding format is specified in section 6 The acceptable 1459 DATA_TYPE values are 1 and 2. 1461 8.5 CERT Record 1463 The CERT record contains one public key certificate. This 1464 record is provided in SPP as an alternate mechanism for certificate 1465 dispatching. Figure 14 shows the format of the CERT Record. 1467 0 1 2 3 1468 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 1469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1470 | CACHE-EXPIRY | 1471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1472 | CERT_TYPE | | 1473 +-+-+-+-+-+-+-+-+ | 1474 ~ CERT_DATA ~ 1475 | | 1476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1478 Figure 14: Certificate Record Format 1480 CACHE-EXPIRY 1482 A 4 octet field indicating the maximum amount of time, 1483 in seconds, this policy record MAY be cached. 1485 CERT_TYPE 1487 This 1 octet field indicates the type of certificate or 1488 certificate-related information contained in the Certificate 1489 Data field. The values for this field are described in 1490 Section 7.3. 1492 CERT_DATA 1494 This variable length field contains the actual encoding of 1495 certificate data. The type of certificate is indicated by the 1496 Certificate Type field. 1498 9. SPP Message Processing 1500 SPP messages use UDP or TCP as their transport protocol. 1501 Messages carried by UDP are restricted to 512 bytes (not counting the 1502 IP or UDP headers). Fragmentation is allowed for messages containing 1503 more than 512 bytes. The SPP-XFR message SHOULD use TCP to transfer 1504 the contents of the SPS Database from a primary to secondary policy 1505 server. SPP uses UDP and TCP ports 501. 1507 9.1 General Message processing 1509 For an SPP-Query or SPP-Pol message, the transmitting entity 1510 MUST do the following: 1512 1. Set a timer and initialize a retry counter. 1513 2. If an SPP-Reply or SPP-Pol_Ack message corresponding to the 1514 appropriate SPP-Query or SPP-Pol message is received within the time 1515 interval, or before the retry counter reaches 0, the transmitting 1516 entity continues normal operation. 1517 3. If an SPP-Reply or SPP-Pol_Ack message corresponding to the 1518 appropriate SPP-Query or SPP-Pol message is not received within the 1519 time interval, and a secondary policy server is available, the 1520 message is sent to the secondary server. If a secondary server 1521 does not exist the message is resent to the primary and the retry 1522 counter is decremented. 1523 4. If the retry counter reaches zero (0) the event should be logged 1524 in the appropriate system audit file. 1525 5. At this point, the transmitting entity will clear state for 1526 this peer and revert to using conventional security mechanisms. 1528 9.2 Query Message (SPP-Query) Processing 1530 When creating a SPP-Query message, the entity (host, security gateway, 1531 or policy server) MUST do the following: 1533 1. Generate the Message ID value. This value starts at "zero" and 1534 MUST be incremented by (01)hex with every new message. 1535 2. Set the value of the MTYPE field to 01 1536 3. Set the MCODE value to (00)hex. 1537 4. Set the QCOUNT and RCOUNT fields. All fields MUST be 1538 set to (00)hex when their corresponding payloads do no exist. 1540 5. Set the flag bits accordingly and set the RESERVED field to (00)hex. 1541 6. Calculate and place the timestamp value used for anti-replay attack 1542 protection. 1543 7. Set the IDENTITY_TYPE and IDENTITY of the Sender of the SPP 1544 message. 1545 8. Construct the SPP data payloads. A Query payload MUST be present 1546 in this message. 1547 9. Local policy information related to the query MAY be included as 1548 Record payloads following the Query payloads. 1549 10. If the Signature payload is required for message integrity and 1550 authentication, calculate a signature over the SPP header, SPP 1551 payloads, the PCL, TYPE, and LENGTH fields of the Signature 1552 payload. If required, the Signature payload MUST be the last 1553 payload in the message. 1555 When a policy server receives an SPP-Query message it MUST do the 1556 following: 1558 1. Check for SPP access control. If enabled, read the IP address in the 1559 Sender's field of the SPP header. 1561 - Verify whether or not the message is allowed. If the message is 1562 not allowed then: 1564 o send an SPP_Reply message with the error code 02 1565 o discard message and log EVENT if configured to do so 1567 - If the message is allowed, continue. 1569 2. Check timestamp field for anti-replay protection. If a replayed 1570 message is detected: 1572 - send an SPP_Reply message with the error code 03 1573 - discard message and log EVENT if configured to do so 1575 3. If the message requires signature validation. 1577 - Fetch certificate or key corresponding to the IP address found 1578 in the sender field of the SPP header. 1580 - If a certificate or key is not available the entity MAY, 1581 depending on configuration: 1583 o choose to abort validation process, send SPP-Reply message 1584 with error code 05, discard the message, and MAY log 1585 the EVENT. 1587 o send an SPP-Query message to the source of the IP address 1588 found in the sender field of the SPP header with a CERT Query 1589 payload. Keep the SPP-Query message until the SPP_Reply 1590 returns. Extract certificate or key, validate it and 1591 proceed. 1593 - Once a validated certificate or key is available then validate 1594 signature. 1596 o If validation fails, send SPP-Reply message with error 1597 code 05, discard the message, and the EVENT MAY be logged. 1599 4. Parse the Query record. Check the Destination Address Data field to 1600 determine if the message received was intended for a node that is a 1601 member of the server's security domain. 1603 5. If the message is for a node that is a member of the server's 1604 security domain then: 1606 - Using src, dst, and any other applicable fields found in the 1607 Query Payload, search the SPS database for an appropriate policy. 1609 o If a policy is found then construct a SPP-Reply message per 1610 section 9.3 with appropriate payloads 1612 o If a policy is not found then construct a SPP-Reply message 1613 per section 9.3 with appropriate payloads and error code. 1615 6. If the message is for a node that is not part of the server's 1616 security domain then: 1618 - Check the Cache database for any relevant policies that apply to 1619 this communication. 1621 o If a policy is found then construct a SPP-Reply message per 1622 section 9.3 with appropriate payloads 1624 o If a policy is not found then continue. 1626 - Check the Local database for any relevant policies that apply to 1627 this communication. 1629 - If a matching policy is found: 1631 o Generate a new SPP-Query message repeating all payloads and 1632 applicable fields. The Sender Address will be the address of 1633 the server. The destination for this message MUST 1634 be the one in the original SPP-Query received. 1636 o Keep state. Upon reception of the corresponding SPP-Reply the 1637 policy server MUST send an SPP-Reply addressed to sender of the 1638 original SPP-Query. 1640 - If a matching policy is not found then: 1642 o The policy server MUST send the SPP-Query message unchanged. 1643 The server MAY validate the authenticity of the message, if 1644 neccessary, before forwarding it. 1646 9.3 Reply Message (SPP-Reply) Processing 1648 When creating a SPP-Reply message, the policy server MUST do the 1649 following: 1651 1. Copy the Message ID value from the corresponding SPP-Query message 1652 into the Message ID field. 1653 2. Set the value of the MTYPE field to 02 1654 3. Set the MCODE value. 1655 4. Set the QCOUNT and RCOUNT fields. All fields MUST be 1656 set to (00)hex when their corresponding payloads do no exist. 1657 5. Set the flag bits accordingly and set the RESERVED field to (0). 1658 6. Calculate and place the timestamp value used for anti-replay attack 1659 protection. 1660 7. Set the IDENTITY_TYPE and IDENTITY of the Sender of the SPP 1661 message. 1662 8. Copy the Query payloads from the SPP-Query message to the 1663 SPP-Reply message. 1664 9. Construct the SPP data payload. Unless there is an error, at 1665 least one record corresponding to each Query payload MUST be 1666 present. 1667 10. A policy server record and a CERT record MUST be added to the 1668 SPP-Reply message if the server is not authoritative for the 1669 source of the query (e.g., the address in the Source Address Data 1670 field of the COMSEC Query payload) and, 1672 1) The policy server is authoritative for the address found in 1673 the Destination Address Data field of the query, or 1674 2) The policy server is authoritative for the host in 1675 the Sender ID of the previous reply, or 1676 3) The policy server is authoritative for the host in the 1677 Sender ID of the query to which this is a reply. 1678 11. If the Signature payload is required for message integrity and 1679 authentication, calculate a signature over the SPP header, SPP 1680 payloads, the PCL, TYPE, and LENGTH fields of the Signature 1681 payload. If present, the Signature payload MUST be the last 1682 payload in the message. 1683 12. The SPP-Reply message is sent to the host that is listed in 1684 the Sender ID field of the SPP-Query to which this is a reply. 1686 When a host or security gateway receives an SPP-Reply message it MUST 1687 do the following: 1689 1. Read the Message ID field. If the value does not match the value 1690 of an outstanding SPP-Query message from a policy server then: 1691 - silently discard the message and the event MAY be logged. 1693 2. If Message ID matches, Check the timestamp field for anti-replay 1694 protection. If a replayed message is detected the message is 1695 silently discarded and the event MAY be logged. 1697 3. Establish if the message requires signature validation by 1698 seraching for a Signature payload: 1699 - if signature validation is required proceed with step 4. 1700 - if signature validation is not required proceed with step 6. 1702 4. Validate the signature on the message. 1704 - Fetch certificate or key corresponding to the IP address found 1705 in the sender field of the SPP header. 1707 - If a certificate or key is not available the entity MAY: 1709 o choose, depending on configuration, to abort validation 1710 process, discard the message and MAY log the EVENT. 1712 o send an SPP-query message to the source of the IP address 1713 found in the sender field of the SPP header with a CERT query 1714 payload. Keep SPP-Reply message until the corresponding 1715 SPP_Reply returns. Extract certificate or key, validate it 1716 and proceed. 1718 5. Once a validated certificate or key is available then validate 1719 signature. 1721 If validation fails: 1722 - the message is silently discarded and the EVENT MAY be logged 1724 If validation succeeds, continue processing. 1726 6. For Policy Servers, validate the chain of trust: 1728 - For each Policy Server record, verify that the Policy Server 1729 is authoritative over the Node. This may be done using 1730 information contained in certificates. 1732 - Use the Policy Server records to Create a chain of hosts from 1733 the destination host to this policy server where two records 1734 are linked if the Node in one is the Policy Server in another. 1736 - If the chain has no breaks, then this policy server MUST be 1737 authoritative over the sender of the reply, otherwise drop 1738 the message and stop processing it. 1740 - If the chain has one break, then the last policy server on 1741 the chain MUST be the sender of the reply, otherwise drop 1742 the message and stop processing it. 1744 - If the chain has two or more breaks, then there is an error 1745 in the chain so drop the message and stop processing it. 1747 - Verify that the Policy Server that is authoritative over the 1748 destination host is authoritative over ALL destination hosts 1749 in the reply. 1751 7. If MCODE value is 2-10: 1753 For hosts or security gateways: 1754 - clear all the state and stop processing 1755 For policy servers: 1756 - create an SPP-Reply message using the same MCODE value. 1758 8. If the reply received correponds to a Cert query and the MCODE is 1759 either (01)hex, (08)hex (accept or partially unavailable) process 1760 message that was held up waiting for the cert. 1762 9. For Policy Servers: 1764 - Search the Local Policy Database for a policy entry that 1765 matches the policy expressed in Query payload. 1767 - Merge the local and non-local policy information using the 1768 policy resolution proccess outlined in section 11. 1770 - If the merge fails send an SPP-Reply message with MCODE 10, 1771 Communication Prohibited 1773 - If the merge succeeds: 1775 o cache policy information. This includes all Query and Record 1776 payloads. 1777 o send an SPP-Reply message with the resulting policy records 1779 10. For hosts or security gateways: 1781 - verify that the information in the Record payload corresponds 1782 to the information in the Query payload. 1783 - extract the records and create a policy entry in the SPD 1784 according to local format. The policy is entered in the SPD ONLY 1785 if local configuration allows. 1787 9.4 Policy Message (SPP-Pol) Processing 1789 When creating a SPP-Pol message, the entity (host, security gateway, or 1790 policy server) MUST do the following: 1792 1. Generate the Message ID value. This value starts at "zero" and 1793 MUST be incremented by (01)hex with every new message. 1794 2. Set the value of the MTYPE field to 03. 1795 3. Set the MCODE value to (00)hex. 1796 4. Set the RCOUNT field. The QCOUNT field MUST be set to (00)hex 1797 since no query payloads exist. 1798 5. Set the flag bits accordingly and set the RESERVED field to (0). 1799 6. Calculate and place the timestamp value used for anti-replay attack 1800 protection. 1801 7. Set the IDENTITY_TYPE and IDENTITY of the Sender of the SPP 1802 message. 1803 8. Construct the SPP data payloads. A Record payload MUST be present 1804 in this message. Query payloads MUST NOT be present. 1806 9. If the Signature payload is required for message integrity and 1807 authentication, calculate a signature over the SPP header, SPP 1808 payloads, the PCL, TYPE, and LENGTH fields of the Signature 1809 payload. If required, the Signature payload MUST be the 1810 last payload in the message. 1812 When a policy server receives an SPP-Pol message it MUST do the 1813 following: 1815 1. Check for SPP access control. If enabled, read the IP address in the 1816 Sender's field of the SPP header. 1818 - Verify whether or not the message is allowed. If the message is 1819 not allowed then: 1821 o send an SPP-Pol_Ack message with the error code 02 1822 o discard message and log EVENT if configured to do so 1824 - If the message is allowed, continue. 1826 2. Check timestamp field for anti-replay protection. If a replayed 1827 message is detected: 1829 - send an SPP_Reply message with the error code 03 1830 - discard message and log EVENT if configured to do so 1832 3. If the message requires signature validation. 1834 - Fetch certificate or key corresponding to the IP address found 1835 in the sender field of the SPP header. 1837 - If a certificate or key is not available the entity MAY, 1838 depending on configuration: 1840 o choose to abort validation process, send SPP-Pol_Ack message 1841 with error code 05, discard the message and MAY log the 1842 EVENT. 1844 o send an SPP-Query message to the source of the IP address 1845 found in the sender field of the SPP header with a CERT Query 1846 payload. Keep SPP-Pol message until the SPP_Reply 1847 returns. Extract certificate or key, validate it and 1848 proceed. 1850 - Once a validated certificate or key is available then validate 1851 signature. 1853 o If validation fails the message is silently discarded and the 1854 EVENT MAY be logged 1856 4. If signature was not required or upon successful validation of a 1857 signature parse the payloads. 1859 5. For hosts and security gateways: 1861 - extract the records and create a policy entry in the cache 1862 database. The policy MAY be entered in the SPD, also, ONLY 1863 if cofiguration allows. 1865 6. For Policy Servers: 1867 - extract the records and create a policy entry in the cache 1868 database. 1870 9.5 Policy Acknowledgement Message (SPP-Pol_Ack) Processing 1872 When creating a SPP-Pol_Ack message, the policy server MUST do the 1873 following: 1875 1. Copy the Message ID value from the corresponding SPP-Pol message 1876 into the Message ID field. 1877 2. Set the value of the MTYPE field to 04 1878 3. Set the MCODE value. 1879 4. Set the QCOUNT and RCOUNT fields. All fields MUST be 1880 set to (00)hex. 1881 5. Set the flag bits accordingly and set the RESERVED field to (0). 1882 6. Calculate and place the timestamp value used for anti-replay attack 1883 protection. 1884 7. Set the IDENTITY_TYPE and IDENTITY of the Sender of the SPP 1885 message. 1886 8. Query or Record payloads MUST NOT be present. 1887 9. If the Signature payload is required for message integrity and 1888 authentication, calculate a signature over the SPP header, the 1889 PCL, TYPE, and LENGTH fields of the Signature payload. 1891 When a host, security gateway or policy server receives an 1892 SPP-Pol_Ack message the entity MUST do the following: 1894 1. Read the Message ID field. If the value does not match the value 1895 of an outstanding SPP-Pol message from a policy server then: 1896 - silently discard the message and the EVENT MAY be logged. 1898 2. If Message ID matches then check the timestamp field for anti-replay 1899 protection. If a replayed message is detected the message is 1900 silently discarded and the EVENT MAY be logged. 1902 3. If the message is original (not replayed) and the message requires 1903 signature validation then: 1905 - Fetch certificate or key corresponding to the IP address found 1906 in the sender field of the SPP header. 1908 - If a certificate or key is not available the entity MAY: 1910 o choose, depending on configuration, to abort validation 1911 process, discard the message and MAY log the EVENT. 1913 o send an SPP-query message to the source of the IP address 1914 found in the sender field of the SPP header with a CERT Query 1915 payload. Keep SPP-Pol_ack message until the SPP_Reply 1916 returns. Extract certificate or key, validate it and 1917 proceed. 1919 4. Once a validated certificate or key is available then validate the 1920 signature. 1921 If validation fails: 1922 - the message is silently discarded and the event MAY be logged 1923 If validation succeeds: 1924 - read the MCODE field and proceed accordingly. If no errors, 1925 clear all the state for this message and proceed. 1927 9.6 KeepAlive Message (SPP-KEEP_ALIVE) Processing 1929 When creating an SPP-Keep_Alive message, the policy server MUST do the 1930 following: 1932 1. Generate the Message ID value. This value starts at "zero" and 1933 MUST be incremented by (01)hex with every new message. 1934 2. Set the value of the MTYPE field to (06)hex. 1935 3. Set the MCODE value to (00)hex. 1936 4. Set the QCOUNT and RCOUNT fields. All fields MUST be 1937 set to (00)hex. 1938 5. Set the flag bits accordingly and set the RESERVED field to (0). 1939 6. Calculate and place the timestamp value used for anti-replay attack 1940 protection. 1941 7. Set the IDENTITY_TYPE and IDENTITY of the Sender of the SPP 1942 message. 1943 8. Query or Record payloads MUST NOT be present. 1944 9. If the Signature payload is required for message integrity and 1945 authentication, calculate a signature over the SPP header, the 1946 PCL, TYPE, and LENGTH fields of the Signature payload. 1948 When a host or security gateway receives an SPP-Keep_Alive message it 1949 MUST do the following: 1951 1. Check for SPP access control. If enabled, read the IP address in the 1952 Sender's field of the SPP header. 1954 - Verify whether or not the message is allowed. If the message is 1955 not allowed then discard message and log EVENT if configured to 1956 do so. 1958 2. Check timestamp field for anti-replay protection. If a replayed 1959 message is detected discard message and log EVENT if configured to 1960 do so. 1962 3. If the message requires signature validation then: 1964 - Fetch certificate or key corresponding to the IP address found 1965 in the sender field of the SPP header. 1967 - If a certificate or key is not available the entity MAY 1968 depending on configuration: 1970 o choose to abort validation process, discard the message and 1971 perhaps logged the event. 1973 o send an SPP-Query message to the source of the IP address 1974 found in the sender field of the SPP header with a CERT Query 1975 payload. Keep SPP-Keep_Alive message until the SPP-Reply 1976 returns. Extract certificate or key, validate it and 1977 proceed. 1979 - Once a validated certificate or key is available then validate 1980 signature. 1982 o If validation fails the message is silently discarded and the 1983 event MAY be logged 1985 4. If signature validation was not required or upon successful 1986 validation of a signature, the EVENT MAY be logged. 1988 10. Policy Decorrelation Process 1990 It is not possible for a Policy Server to use policies as they 1991 are written in the SPS master file, since those policies are likely to 1992 be correlated. Two policies are correlated if there is a non-nil 1993 intersection between the values of each of their selectors. Caching 1994 correlated policies can lead to incorrect policy implementation based 1995 on those cached policies, as the following example shows. 1997 H1 --- SG1 --------- SG2 --- H2 1998 | | \__ H3 1999 | | 2000 PS1 PS2 2002 PS2 contains the following policies in its master file: 2003 src dst proto direction action 2004 1) * H2 * inbound permit 2005 2) * * * inbound deny 2007 These two policies are correlated since all the selectors (src, dst, 2008 proto, and direction) overlap. The following SPP exchanges occur: 2010 1) PS1 requests policy for H3. 2011 2) PS2 returns policy #2 to PS1 which then caches policy #2. 2012 3) PS1 now looks up the policy for H2 and discovers that it already 2013 has a matching policy (policy #2) and uses that. 2015 This is clearly wrong, since policy #2 indicates that the 2016 communication to H2 should be denied, though PS2's policy actually 2017 indicates that it should be allowed. 2019 The solution is to remove the ambiguities that may exist in 2020 the master file. The policies of the master file MUST be decorrelated 2021 before they are entered into the Local Policy Database. That is, the 2022 policies must be rewritten so that for every pair of policies there 2023 exists a selector for which there is a nil intersection between the 2024 values in both of the policies. 2026 The policies in the above example could be decorrelated as follows: 2027 src dst proto direction action 2028 1') * H2 * inbound permit 2029 2') * not H2 * inbound deny 2031 Now the exchange is a bit different: 2032 1) PS1 requests policy for H3. 2033 2) PS2 returns policy #2' to PS1 which then caches policy #2'. 2034 3) PS1 now looks up the policy for H2, doesn't have a matching 2035 policy, so it requests a policy for H2. 2036 4) PS2 returns policy #1' to PS1 which then caches policy #1', 2037 which is the correct policy for H2. 2039 All SPAs and SPRs, therefore, MUST decorrelate their master 2040 files before using those policies for SPP. Once the policies are 2041 decorrelated, there is no longer any ordering requirement on the 2042 policies, since only one policy will match any requested 2043 communication. The next section describes decorrelation in more 2044 detail and presents an algorithm that may be used to implement 2045 decorrelation. 2047 10.1 Decorrelation Algorithm 2049 The basic decorrelation algorithm takes each policy in a 2050 correlated set of policies and divides it up into a set of policies 2051 using a tree structure. Those of the resulting policies that are 2052 decorrelated with the uncorrelated set of policies are then added to 2053 that decorrelated set. 2054 The basic algorithm does not guarantee an optimal set of 2055 decorrelated policies. That is, the policies may be broken up into 2056 smaller sets than is necessary, though they will still provide all the 2057 necessary policy information. Some extensions to the basic algorithm 2058 are described later to improve this and improve the performance of the 2059 algorithm. 2061 C A set of ordered, correlated policies 2062 Ci The ith policy in C. 2063 U The set of uncorrelated policies being built from C 2064 Ui The ith policy in U. 2066 A policy P may be expressed as a mapping of selector values to 2067 actions: 2068 Pi = Si1 x Si2 x ... x Sik -> Ai 2070 1) Put C1 in set U as U1 2072 For each policy Cj (j > 1) in C 2073 2) If Cj is uncorrelated with every policy in U, then add it to U. 2075 3) If Cj is correlated with one or more policies in U, create a tree 2076 rooted at the policy Cj that partitions Cj into a set of uncorrelated 2077 policies. The algorithm starts with a root node where no selectors 2078 have yet been chosen. 2080 A) Choose a selector in Cj, Scjn, that has not yet been chosen when 2081 traversing the tree from the root to this node. If there are no 2082 selectors not yet used, continue to the next unfinished branch 2083 until all branches have been completeded. When the tree is 2084 completed, go to step D. 2086 T is the set of policies in U that are correlated with the policy 2087 to this node. 2089 The policy at this node is the policy formed by the selector values 2090 of each of the branches between the root and this node. Any 2091 selector values that are not yet represented by brances assume 2092 the corresponding selector value in Cj, since the values in Cj 2093 represent the maximum value for each selector. 2095 B) Add a branch to the tree for each value of the selector Scjn that 2096 appears in any of the policies in T. (If the value is a superset 2097 of the value of Scjn in Cj, then use the value in Cj, since that 2098 value represents the universal set.) Also add a branch for the 2099 compliment of the union of all the values of the selector Scjn 2100 in T. When taking the compliment, remember that the universal 2101 set is the value of Scjn in Cj. A branch need not be created 2102 for the nil set. 2104 C) Repeat A and B until the tree is completed. 2106 D) The policy to each leaf now represents a policy that is a subset 2107 of Cj. The policies at the leaves completely partition Cj in 2108 such a way that each policy is either completely overriden by 2109 a policy in U, or is uncorrelated with the policies in U. 2111 Add all the uncorrelated policies at the leaves of the tree to U. 2113 5) Get next Cj and goto 2. 2115 6) When all policies in C have been processed, then U will contain an 2116 uncorrelated version of C. 2118 There are several optimizations that can be made to this algorithm. 2119 A few of them are presented here. 2121 It is possible to optimize, or at least improve, the amount of 2122 branching that occurs by carefully choosing the order of the selectors 2123 used for the next branch. For example, if a selector Scjn can be 2124 chosen so that all the values for that selector in T are equal to or a 2125 superset of the value of Scjn in Cj, then only a single branch need to 2126 be created (since the compliment will be nil). 2127 Branches of the tree do not have to procede with the entire 2128 decorrelation algorithm. For example, if a node represents a policy 2129 that is uncorrelated with all the policies in U, then there is no 2130 reason to continue decorrelating that branch. Also, if a branch is 2131 completely overridden by a policy in U, then there is no reason to 2132 continue decorrelating the branch. 2133 An additional optimization is to check to see if a branch is 2134 overridden by one of the CORRELATED policies in set C that has alread 2135 been decorrelated. That is, if the branch is part of decorrelating 2136 Cj, then check to see if it was overridden by a policy Cm, m < j. 2137 This is a valid check, since all the policies Cm are already expressed 2138 in U. 2139 Along with checking if a policy is already uncorrelated in 2140 step 2, check if Cj is overriden by any policy in U. If it is, skip it 2141 since it is not relevant. A policy x is overriden by another policy y 2142 if every selector in x is equal to or a subset of the corresponding 2143 selector in policy y. Appendix B shows an example of applying the 2144 algorithm to a set of correlated policies. 2146 11. Policy Resolution Process 2148 When a policy server receives a reply (Section 9.3), it merges 2149 its local policy for the communication with any non-local policies 2150 contained in the reply. The merging process creates a new policy that 2151 is the intersection of the local and remote policies. It then uses 2152 the merged policy as its reply to the queryand caches it. The policy 2153 resolution process is as follows: 2155 1. Get local and remote policies for the requested communication. 2157 2. Verify that the remote policy answer the query. This may be 2158 accomplished by intersecting the query with each of the answers 2159 to the query and verify that they have a non-nil intersection. 2161 3. For each pair of endpoints described by the policy: 2163 - Find the intersection of the policies between these endpoints. 2165 o If the intersection is nil, then the policies do not permit 2166 the communication and an error should be returned. It is not 2167 necessary to continue processing other endpoints. 2169 o If the intersection is not nil, then the intersection should 2170 be added to the reply policy. 2172 4. The policy created by the intersections is the policy that should 2173 be cached and used as a reply to the query. 2175 Step 3 requires that the policy server must be able to determine all 2176 the sets of endpoints described by the policy. The endpoint 2177 information comes from two places: the source and destination 2178 addresses in the query (which is possibly more specific than those 2179 fields in the policies) and the location information in the 2180 ipsec_action attribute. 2181 The location information may offer the policy server some 2182 flexibility in how it interprets endpoints for the communication. For 2183 example, if the policy indicates a tunnel must be established with any 2184 host or gateway in the source or destination host's domain, the policy 2185 server can choose the endpoint within the bounds of the policy. This 2186 choice can be made randomly, using a set policy (e.g., always choose 2187 the outermost gateway permitted by the policy), or using additional 2188 information the server may maintain for this purpose. For example, 2189 the server may keep track of previous policy decisions it made and use 2190 those as hints to which security associations may already exist. It 2191 can then try to make decisions that will allow these security 2192 associations to be reused. 2194 12. Usage of SPS with IPSec 2196 This section illustrates how the Security Policy System 2197 operates and interacts with IPSec. It describes, step-by-step, the 2198 process from the inital application call to the establishment of the 2199 necessary security associations. 2201 admin. boundary admin. boundary 2202 ----------------- --------------------------- 2203 | | | admin. boundary| 2204 | | | ---------------| 2205 | Q1 | Q2 | Q3 | || 2206 | H1 ---- SG1 ---- (Internet) --- SG2 ---- | SG3 --- H2 || 2207 | R3 | | R2 | | R1 | | || 2208 | PS1 | | PS2 | PS3 || 2209 | | | ---------------| 2210 ----------------- --------------------------- 2211 ESP Tunnel 2212 |===============================| 2213 ESP Tunnel 2214 |========================================| 2215 ESP Transport 2216 |================================================| 2218 |==| = security association required by policy 2219 ---- = connectivity (or if so labeled, administrative boundary) 2220 Hx = host x 2221 SGx = security gateway x 2222 PSx = policy server x 2223 Qx = query x 2224 Rx = reply x 2226 1. User application attempts to send a message from H1 to H2 2227 (e.g., finger somebody@H2) 2229 2. IPSec on H1 gets the packet and finds a policy for it in the 2230 Security Policy Database (SPD). 2232 3. H1 does not have a security association for the communication and 2233 asks the Key Management Protocol to establish the needed security 2234 association. 2236 4. The policy client in H1 is queried for the policy governing the 2237 communication between H1 and H2. 2239 5. H1's policy client creates an SPP query, Q1, and sends it to PS1, 2240 its configured policy server. 2242 6. PS1 receives the query. Its security domain database indicates that 2243 it is not authoritative over H2 so it checks its cache to see if it 2244 has a cached answer. For this example, it does not, so it creates 2245 a new SPP query, Q2, with the query and sends it to H2. 2247 7. SG2 intercepts Q2 and passes it to PS2. 2249 8. PS2 receives the query. Its security domain database indicates that 2250 it is not authoritative over H2 and PS2 determines it wants to be 2251 involved in the communication. It checks its cache to see if it has 2252 a cached answer. For this example, it does not, so it creates a new 2253 SPP query, Q3, with the query and sends it to H2. 2255 9. SG3 intercepts Q3 and passes it to PS3. 2257 10. PS3 receives the query. It checks its security domain database and 2258 determines that it is authoritative over H2 so it will send a reply. 2259 It checks its cache to see if it has a cached answer. For this 2260 example, it does have one cached from previous information sent to 2261 it by H2. The cached policy indicates ESP transport must be done 2262 with H2 and ESP tunnel must be done with SG3. 2264 11. PS3 creates two messages. One is an SPP reply message, R1, with the 2265 policy indicating the required security associations, a security 2266 server record indicating PS3 is authoritative over H2, and PS3's 2267 certificate in a certificate record. The reply is sent to PS2. 2269 The second message is an SPP policy message to signal SG3 that it 2270 will need a security association with H1. 2272 12. PS2 receives the R1. It verifies that PS3 is authoritative over 2273 H2. It looks up its local policy and resolves it with the policy 2274 in the reply. It caches the resolved policy and creates two messages. 2275 One is the reply to PS1, R2, that contains the resolved policy, PS3's 2276 security server and certificate records and a security server record 2277 that states that PS2 is authoritative over PS3 and PS2's certificate. 2279 The second message is an SPP policy message to signal SG2 that it 2280 will need a security association with H1. 2282 13. PS1 receives the R2. It verifies that PS2 is authoritative over PS3 2283 and PS3 is authoritative over H2, forming a valid chain of trust. 2284 It looks up its local policy and resolves it with the policy in the 2285 reply. It caches the resolved policy and creates R3, a reply to H1. 2286 R3 contains the resolved policy (the security server and certificate 2287 records are no longer needed). 2289 14. The policy client receives the R3 and returns it to the application 2290 that queried for it. The policy indicates that the three security 2291 associations must be established and they must be established in 2292 a particular order. 2294 15. The KMP is given this information and first creates a security 2295 association with PS2 which it can use to set up the security 2296 association with PS3. They both can be used to set up the security 2297 association with H2. 2299 16. Finally, the original message from the application can proceed using 2300 the security associations. 2302 If H2 wanted to get directly involved in the communication, 2303 PS3 would not be authoritative over H2, H2 would be authoritative over 2304 itself. There would then be another pair of messages where PS3 sends 2305 a query to H2 which H2 receives and sends a reply back to PS3 and the 2306 processing continues as outlined above. 2308 Acknowledgments 2310 The authors thank Charles Lynn, Steve Kent and John Zao for their 2311 participation in requirements discussions for the Security Policy 2312 System. Our gratitude to Charlie Lynn, Matt Fredette, Alden Jackson, 2313 Dave Mankins, Marla Shepard and Pam Helinek for the contributions to 2314 this document. We thank Mary Hendrix (INS Corp.) for reviewing this 2315 document. We thank Isidro Castineyra for his contributions to the 2316 early parts of this work. 2318 References 2320 [Bra97] Bradner, S., "Key Words for use in RFCs to indicate 2321 Requirement Levels", RFC2119, March 1997. 2323 [Kent98] S. Kent, R. Atkinson, "Security Architecture for the 2324 Internet Protocol", Internet Draft draft-ietf-ipsec-arch-sec-07, 2325 July 1998. 2327 [KA98b] S. Kent, R. Atkinson, "IP Encapsulating Security 2328 Payload (ESP)", Internet Draft, July 1998. 2330 [isakmp] D. Maughan, M. Schertler, M. Schneider, J. Turner, "Internet 2331 Security Association and Key Management Protocol (ISAKMP)", Internet 2332 Draft draft-ietf-ipsec-isakmp-10, July 3, 1998 2334 [ALX98] A. Vopilov, "The Locating an IPSec Gateway Algorithm", 2335 Working Draft, February 1998. 2337 [RFC1305] Mills, D., "Network Time Protocol (Version 3): 2338 Specification, Implementation and Analysis", RFC 1305, March 2339 1992. 2341 [RFC2230] R. Atkinson, "Key Exchange Delegation Record for the DNS", 2342 RFC 2230, The Internet Society, November 1997 2344 [PKIXP1] R. Housley, W. Ford, W. Polk, D. Solo, "Internet Public 2345 Key Infrastructure: X.509 Certificate and CRL Profile". 2346 Internet Draft draft-ietf-pkix-ipki-part1-10, September 1998. 2348 [PolMod] R. Pereira, P. Bhattacharya, "IPSec Policy Data Model", Internet 2349 Draft draft-ietf-ipsec-policy-model-00, February 1998 2351 [Harkins98] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", 2352 Internet Draft draft-ietf-ipsec-isakmp-oakley-08, June 1998. 2354 [Piper98] D. Piper, "The Internet IP Security Domain of 2355 Interpretation for ISAKMP", Internet Draft 2356 draft-ietf-ipsec-ipsec-doi-10.txt, July 1998 2358 [SPSL] M. Condell, C. Lynn, J. Zao "Security Policy Specification 2359 Language", Internet Draft draft-ietf-ipsec-spsl-00.txt, 2360 November 1998 2362 APPENDIX A 2364 DATA_TYPE Definitions 2366 The encoding of each selector and SA attribute is decribed here. 2367 Attributes generally encode "any" in one of two ways. If using 2368 the TLV format (X = 0) then the length is set to 0 to indicate any. 2369 If the TV format (X = 1) is used, then the value is set to 0; 2371 Lists are generally expressed by setting the length of the value to a 2372 multiple of the length of a single data value. The multiple used is 2373 the number of elements in the list. If the selector or attribute 2374 may express a list, each element is expressed the same as the element 2375 described in DATA_VALUE. 2377 This section describes the values and DATA_VALUE encoding for each 2378 selector and SA attribute. 2380 A.1 IPV4_ADDR 2382 X 0 2383 DATA_TYPE 1 2384 LENGTH 4 if an IP address is present, 2385 0 if no IP address is present. 2386 list Yes 2387 DATA_VALUE 2389 0 1 2 3 2390 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 2391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2392 | ADDRESS | 2393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2395 A.2 IPV6_ADDR 2397 X 0 2398 DATA_TYPE 2 2399 LENGTH 16 if an IP address is present, 2400 0 if no IP address is present. 2401 list Yes 2402 DATA_VALUE 2404 0 1 2 3 2405 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 2406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2407 | | 2408 | | 2409 | ADDRESS | 2410 | | 2411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2412 A.3 SRC_IPV4_ADDR 2414 X 0 2415 DATA_TYPE 3 2416 LENGTH 4 times the number of addresses in the list. 2417 A length of 0 indicates any address. 2418 list Yes 2419 DATA_VALUE 2421 0 1 2 3 2422 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 2423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2424 | SRC ADDRESS | 2425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2427 A.4 SRC_IPV4_ADDR_SUBNET 2429 X 0 2430 DATA_TYPE 4 2431 LENGTH 8 times the number of subnets in the list. 2432 A length of 0 indicates any subnet. 2433 list Yes 2434 DATA_VALUE 2436 0 1 2 3 2437 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 2438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2439 | SUBNET ADDRESS | 2440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2441 | SUBNET MASK | 2442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2444 A.5 SRC_IPV4_ADDR_RANGE 2446 X 0 2447 DATA_TYPE 5 2448 LENGTH 8 times the number of address ranges in the list. 2449 A length of 0 indicates any address. 2450 list Yes 2451 DATA_VALUE 2453 0 1 2 3 2454 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 2455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2456 | LOWER BOUND SRC ADDRESS | 2457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2458 | UPPER BOUND SRC ADDRESS | 2459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2460 A.6 DST_IPV4_ADDR 2462 X 0 2463 DATA_TYPE 6 2464 LENGTH 4 times the number of addresses in the list. 2465 A length of 0 indicates any address. 2466 list Yes 2467 DATA_VALUE 2469 0 1 2 3 2470 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 2471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2472 | DST ADDRESS | 2473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2475 A.7 DST_IPV4_ADDR_SUBNET 2477 X 0 2478 DATA_TYPE 7 2479 LENGTH 8 times the number of subnets in the list. 2480 A length of 0 indicates any subnet. 2481 list Yes 2482 DATA_VALUE 2484 0 1 2 3 2485 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 2486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2487 | SUBNET ADDRESS | 2488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2489 | SUBNET MASK | 2490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2492 A.8 DST_IPV4_ADDR_RANGE 2494 X 0 2495 DATA_TYPE 8 2496 LENGTH 8 times the number of address ranges in the list. 2497 A length of 0 indicates any address. 2498 list Yes 2499 DATA_VALUE 2501 0 1 2 3 2502 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 2503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2504 | LOWER BOUND DST ADDRESS | 2505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2506 | UPPER BOUND DST ADDRESS | 2507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2508 A.9 SRC_IPV6_ADDR 2510 X 0 2511 DATA_TYPE 9 2512 LENGTH 16 times the number of addresses in the list. 2513 A length of 0 indicates any address. 2514 list Yes 2515 DATA_VALUE 2517 0 1 2 3 2518 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 2519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2520 | | 2521 | SRC | 2522 | ADDRESS | 2523 | | 2524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2526 A.10 SRC_IPV6_ADDR_SUBNET 2528 X 0 2529 DATA_TYPE 10 2530 LENGTH 32 times the number of subnets in the list. 2531 A length of 0 indicates any subnet. 2532 list Yes 2533 DATA_VALUE 2535 0 1 2 3 2536 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 2537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2538 | | 2539 | SUBNET | 2540 | ADDRESS | 2541 | | 2542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2543 | | 2544 | SUBNET | 2545 | MASK | 2546 | | 2547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2549 A.11 SRC_IPV6_ADDR_RANGE 2551 X 0 2552 DATA_TYPE 11 2553 LENGTH 32 times the number of address ranges in the list. 2554 A length of 0 indicates any address. 2555 list Yes 2556 DATA_VALUE 2557 0 1 2 3 2558 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 2559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2560 | | 2561 | LOWER BOUND | 2562 | SRC ADDRESS | 2563 | | 2564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2565 | | 2566 | UPPER BOUND | 2567 | SRC ADDRESS | 2568 | | 2569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2571 A.12 DST_IPV6_ADDR 2573 X 0 2574 DATA_TYPE 12 2575 LENGTH 16 times the number of addresses in the list. 2576 A length of 0 indicates any address. 2577 list Yes 2578 DATA_VALUE 2580 0 1 2 3 2581 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 2582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2583 | | 2584 | DST | 2585 | ADDRESS | 2586 | | 2587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2589 A.13 DST_IPV6_ADDR_SUBNET 2591 X 0 2592 DATA_TYPE 13 2593 LENGTH 32 times the number of subnets in the list. 2594 A length of 0 indicates any subnet. 2595 list Yes 2596 DATA_VALUE 2598 0 1 2 3 2599 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 2600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2601 | | 2602 | SUBNET | 2603 | ADDRESS | 2604 | | 2605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2606 | | 2607 | SUBNET | 2608 | MASK | 2609 | | 2610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2611 A.14 DST_IPV6_ADDR_RANGE 2613 X 0 2614 DATA_TYPE 14 2615 LENGTH 32 times the number of address ranges in the list. 2616 A length of 0 indicates any address. 2617 list Yes 2618 DATA_VALUE 2620 0 1 2 3 2621 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 2622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2623 | | 2624 | LOWER BOUND | 2625 | DST ADDRESS | 2626 | | 2627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2628 | | 2629 | UPPER BOUND | 2630 | DST ADDRESS | 2631 | | 2632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2634 A.15 DIRECTION 2636 X 1 2637 DATA_TYPE 15 2638 LENGTH TV attribute, no length 2639 list No 2640 DATA_VALUE 2641 1 2 3 2642 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2644 | DIRECTION | 2645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2647 DIRECTION 2648 In/Outbound 0 2649 Inbound 1 2650 Outbound 2 2652 Direction is with respect to the senders interface. 2654 A.16 USER_NAME 2656 X 0 2657 DATA_TYPE 16 2658 LENGTH 1 plus the length of NAME 2659 A length of 0 indicates any name. 2660 list No 2661 DATA_VALUE 2662 0 1 2 3 2663 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 2664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2665 | NAME_TYPE | NAME ~ 2666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2668 NAME_TYPE 2669 822_EMAIL 0 2670 DIST_NAME 1 2672 NAME 2673 Name of type NAME. 2674 [**** probably should describe in more detail] 2676 A.17 SYSTEM_NAME 2678 X 0 2679 DATA_TYPE 17 2680 LENGTH 1 plus the length of NAME 2681 A length of 0 indicates any name. 2682 list No 2683 DATA_VALUE 2685 0 1 2 3 2686 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 2687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2688 | NAME_TYPE | NAME ~ 2689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2691 NAME_TYPE 2692 DNS_NAME 0 2693 DIST_NAME 1 2694 822_NAME 2 2695 X400_ADDR 3 2696 DIR_NAME 4 2697 EDI_PARTY_NAME 5 2698 URI 6 2699 IPADDR 7 2700 REGID 8 2701 OTHER 255 2703 NAME 2704 Name of type NAME. 2705 [***** probably should describe in more detail] 2707 A.18 XPORT_PROTOCOL 2709 X 0 2710 DATA_TYPE 18 2711 LENGTH 1 plus length of pdata 2712 A length of 0 indicates any address. 2713 list No (see below) 2714 DATA_VALUE 2715 0 1 2 3 2716 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 2717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2718 | PTYPE | PDATA ~ 2719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2721 PTYPE Describes the rest of the data: 2722 ANY 0 2723 OPAQUE 1 2724 LIST 2 2725 RANGE 3 2727 PDATA 2728 Not used if PTYPE is ANY or OPAQUE 2730 LIST 2731 indicates a list whose elements look like the following: 2733 0 2734 0 1 2 3 4 5 6 7 2735 +-+-+-+-+-+-+-+-+ 2736 | PROTOCOL | 2737 +-+-+-+-+-+-+-+-+ 2739 The length of pdata to be used as part of the LENGTH 2740 field is 1 times the number of elements in the list. 2742 RANGE 2743 indicates a range of protocol values whose lower bound 2744 is LOWER, and upper bound is UPPER. 2745 0 1 2746 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 2747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2748 | LOWER | UPPER | 2749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2751 The length of pdata to be used as part of the LENGTH 2752 field is 2. 2754 A.19 SRC_PORT 2756 X 0 2757 DATA_TYPE 19 2758 LENGTH 2 times the number of ports in the list. 2759 A length of 0 indicates any port. 2760 list Yes 2761 DATA_VALUE 2763 0 1 2764 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2766 | PORT | 2767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2768 A.20 SRC_PORT_DYNAMIC 2770 X 0 2771 DATA_TYPE 20 2772 LENGTH 4 plus 2 times the number of ports in the list. 2773 A length of 4 indicates any port. 2774 list See Below 2775 DATA_VALUE 2776 0 1 2 3 2777 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 2778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2779 | DYNAMIC LOWER BOUND | DYNAMIC UPPER BOUND | 2780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2781 | PORT | ... ~ 2782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2784 The use of this attribute indicates that dynamic port allocation 2785 is permitted. Communications that are intitiated with any of the 2786 ports indicated, may then dynamically allocate any of the ports 2787 listed within the LOWER and UPPER BOUNDS, inclusive. 2789 DYNAMIC LOWER BOUND 2790 Lower bound of the range of ports that may be dynamically 2791 allocated. If this and DYNAMIC UPPER BOUND are both 0, 2792 then any port may be dynamically allocated. 2794 DYNAMIC UPPER BOUND 2795 Upper bound of the range of ports that may be dynamically 2796 allocated. If this and DYNAMIC LOWER BOUND are both 0, 2797 then any port may be dynamically allocated. 2799 PORT 2800 Port that the communication must be initiated with. This 2801 may be a list of ports. 2803 A.21 DST_PORT 2805 X 0 2806 DATA_TYPE 21 2807 LENGTH 2 times the number of ports in the list. 2808 A length of 0 indicates any port. 2809 list Yes 2810 DATA_VALUE 2812 0 1 2813 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2815 | PORT | 2816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2817 A.22 DST_PORT_DYNAMIC 2819 X 0 2820 DATA_TYPE 22 2821 LENGTH 4 plus 2 times the number of ports in the list. 2822 A length of 4 indicates any port. 2823 list See Below 2824 DATA_VALUE 2825 0 1 2 3 2826 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 2827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2828 | DYNAMIC LOWER BOUND | DYNAMIC UPPER BOUND | 2829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2830 | PORT | ... ~ 2831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2833 The use of this attribute indicates that dynamic port allocation 2834 is permitted. Communications that are intitiated with any of the 2835 ports indicated, may then dynamically allocate any of the ports 2836 listed within the LOWER and UPPER BOUNDS, inclusive. 2838 DYNAMIC LOWER BOUND 2839 Lower bound of the range of ports that may be dynamically 2840 allocated. If this and DYNAMIC UPPER BOUND are both 0, 2841 then any port may be dynamically allocated. 2843 DYNAMIC UPPER BOUND 2844 Upper bound of the range of ports that may be dynamically 2845 allocated. If this and DYNAMIC LOWER BOUND are both 0, 2846 then any port may be dynamically allocated. 2848 PORT 2849 Port that the communication must be initiated with. This 2850 may be a list of ports. 2852 A.23 SEC_LABELS 2854 X 0 2855 DATA_TYPE 23 2856 LENGTH Variable. 2857 list No 2858 DATA_VALUE 2859 0 1 2 3 2860 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 2861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2862 | SECURITY LABEL ~ 2863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2865 A.24 V6CLASS 2867 X 1 2868 DATA_TYPE 24 2869 LENGTH TV attribute, no length 2870 list No 2871 DATA_VALUE 2872 1 2 3 2873 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2875 | PADDING | CLASS | 2876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2878 PADDING set to 0 2880 CLASS class value 2882 A.25 V6FLOW 2884 X 0 2885 DATA_TYPE 25 2886 LENGTH 4 2887 list No 2888 DATA_VALUE 2889 0 1 2 3 2890 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 2891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2892 | PADDING | FLOW | 2893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2895 PADDING set to 0 2897 FLOW set to flow value 2899 A.26 V4TOS 2901 X 1 2902 DATA_TYPE 26 2903 LENGTH TV attribute, no length 2904 list No 2905 DATA_VALUE 2906 1 2 3 2907 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2909 | PADDING | TOS | 2910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2912 PADDING set to 0 2914 TOS type of service value 2916 A.27 ACTION 2918 X 1 2919 DATA_TYPE 27 2920 LENGTH TV attribute, no length 2921 list No 2922 DATA_VALUE 2923 1 2 3 2924 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2926 | ACTION | 2927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2929 DIRECTION 2930 Deny 0 2931 Permit 1 2933 A.28 SRC_PORT_RANGE 2935 X 0 2936 DATA_TYPE 28 2937 LENGTH 4 times the number of port ranges in the list. 2938 A length of 0 indicates any port. 2939 list Yes 2940 DATA_VALUE 2942 0 1 2 3 2943 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 2944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2945 | PORT LOWER BOUND | PORT UPPER BOUND | 2946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2948 A.29 DST_PORT_RANGE 2950 X 0 2951 DATA_TYPE 29 2952 LENGTH 4 times the number of port ranges in the list. 2953 A length of 0 indicates any port. 2954 list Yes 2955 DATA_VALUE 2957 0 1 2 3 2958 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 2959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2960 | PORT LOWER BOUND | PORT UPPER BOUND | 2961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2963 A.30 IPSEC_ACTION 2965 X 0 2966 DATA_TYPE 50 2967 LENGTH Variable 2968 list Yes 2969 DATA_VALUE 2970 0 1 2 3 2971 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----- 2973 | PFS | ESP | CIPHER_ALG | INTEGRITY_ALG | | 2974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2975 | KEYLENGTH | ROUNDS | | 2976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2977 | GROUP | LIFETIME_TYPE | | 2978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2979 | LIFETIME | Fixed 2980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length 2981 | PFS | AH | INTEGRITY_ALG | RESERVED | | 2982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2983 | GROUP | LIFETIME_TYPE | | 2984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2985 | LIFETIME | | 2986 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2987 | PFS | IPCOMP_ALG | LIFETIME_TYPE | | 2988 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2989 | LIFETIME | | 2990 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----- 2991 | LOC_TYPE | LOC_SRC... 2992 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2993 | LOC_TYPE | LOC_DST... 2994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2995 | LOC_TYPE | LOC_SRC... 2996 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Variable 2997 | LOC_TYPE | LOC_DST... Length 2998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2999 | LOC_TYPE | LOC_SRC... 3000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3001 | LOC_TYPE | LOC_DST... 3002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3004 PFS 3005 FALSE 0 3006 TRUE 1 3008 ESP 3009 NOT_REQUIRED 0 3010 TUNNEL_MODE 1 3011 TRANSP_MODE 2 3013 CIPHER_ALG 3015 NONE 0 3016 ANY 1 3017 RFC1829_IV64 2 3018 DES 3 3019 DES3 4 3020 RC5 5 3021 IDEA 6 3022 CAST 7 3023 BLOWFISH 8 3024 3IDEA 9 3025 RFC1829_IV32 10 3026 RC4 11 3028 KEYLENGTH 3030 The first octet corresponds to the minimum value and the 3031 second octet corresponds to the maximum value. If no range 3032 exist the first octet indicates the keylength. The second 3033 octet contains a value of (00)hex. 3035 ROUNDS 3037 The first octet corresponds to the minimum value and the 3038 second octet corresponds to the maximum value. If no range 3039 exist the first octet indicates the rounds. The second 3040 octet contains a value of (00)hex. 3042 INTEGRITY_ALG 3044 NONE 0 3045 ANY 1 3046 HMAC_MD5 2 3047 HMAC_SHA1 3 3048 HMAC_DES 4 3049 KEYED_MD5 5 3050 HMAC_RIPEM 6 3052 GROUP 3054 MODP (modular exponentiation group) 1 3055 ECP (elliptic curve group over GF[P]) 2 3056 EC2N (elliptic curve group over GF[2^N]) 3 3058 values 4-65000 are reserved to IANA. Values 65001-65535 are for 3059 private use among mutually consenting parties. 3061 LIFETIME_TYPE 3063 This 2 octet field indicates type of lifetime. 3065 seconds 1 3066 kilobytes 2 3068 values 3-65000 are reserved to IANA. Values 65001-65535 are for 3069 private use among mutually consenting parties. 3071 LIFETIME 3073 This 4 octet field indicates the SA lifetime. For a given 3074 "Lifetime_Type" the value of the "Lifetime" attribute 3075 defines the actual length of the SA life-- either a number of 3076 seconds, or a number of kilobytes protected. 3078 LOC_TYPE 3080 This 1 octet field indicates the contents of the LOC_SRC or 3081 LOC_DST field. If this field is 0 then the LOC_SRC or LOC_DST 3082 will be omitted. 3084 0 NONE 3085 1 IPv4 address 3086 2 IPv6 address 3087 3 DNS Name 3088 4 Defaults 3090 LOC_SRC 3092 Variable length field depending on LOC_TYPE. IF LOC_TYPE is (04) 3093 then this field is 1 octet in length an it may only take the 3094 following fields: 3096 1 ANY 3097 2 DEST 3098 3 HOST 3099 4 LOCAL-SG 3100 5 REMOTE-SG 3102 LOC_DST 3104 See LOC_SRC. 3106 AH 3107 NOT_REQUIRED 0 3108 TUNNEL_MODE 1 3109 TRANSP_MODE 2 3111 IPCOMP_ALG 3112 ANY 0 3113 OUI 1 3114 DEFLATE 2 3115 LZS 3 3116 V42BIS 4 3118 RESERVED 3120 This 1 or 2 octet field (see paylaod formats above) is 3121 primarily used for padding purposes. Its value is always 0. 3123 A.31 ISAKMP_ACTION 3125 X 0 3126 DATA_TYPE 51 3127 LENGTH 13 BYTES 3128 list No 3129 DATA_VALUE 3130 0 1 2 3 3131 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 3132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3133 | MODE | CIPHER_ALG | KEYLENGTH | 3134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3135 | HASH_ALG | RESERVED | GROUP | 3136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3137 | LIFETIME_TYPE | RESERVED | 3138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3139 | LIFETIME | 3140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3142 MODE 3144 This octet indicates the IKE mode of operation. 3146 MAIN 0 3147 AGRESSIVE 1 3149 CIPHER_ALG 3151 This octet indicates which cipher should be used for the 3152 ISAKMP phase 1 negotiation. 3154 ANY 0 3155 DES 1 3156 IDEA 2 3157 BLOWFISH 3 3158 RC5 4 3159 DES3 5 3160 CAST 6 3162 KEYLENGTH 3164 The first octet corresponds to the minimum value and the 3165 second octet corresponds to the maximum value. If no range 3166 exist the first octet indicates the keylength. The second 3167 octet contains a value of (00)hex. 3169 HASH_ALG 3171 This octet indicates which algorithm should be used for the 3172 ISAKMP phase 1 negotiation. 3174 ANY 0 3175 MD5 1 3176 SHA1 2 3177 TIGER 3 3178 GROUP 3180 This 2 octet field indicates which group should be used during 3181 the ISAKMP phase 1 or phase 2 negotiation. 3183 MODP (modular exponentiation group) 1 3184 ECP (elliptic curve group over GF[P]) 2 3185 EC2N (elliptic curve group over GF[2^N]) 3 3187 values 4-65000 are reserved to IANA. Values 65001-65535 are for 3188 private use among mutually consenting parties. 3190 LIFETIME_TYPE 3192 This 2 octet field indicates type of lifetime. 3194 seconds 1 3195 kilobytes 2 3197 values 3-65000 are reserved to IANA. Values 65001-65535 are for 3198 private use among mutually consenting parties. 3200 LIFETIME 3202 This 4 octet field indicates the SA lifetime. For a given 3203 "Lifetime_Type" the value of the "Lifetime" attribute defines 3204 the actual length of the SA life-- either a number of seconds, 3205 or a number of kilobytes protected. 3207 RESERVED 3209 This 1 or 2 octet field (see paylaod formats above) is 3210 primarily used for padding purposes. Its value is always 0. 3212 Note: for the variable-size fields (i.e., LOC_SRC and LOC_DST), add 3213 padding until the 4-octet boundary. Since the LEN of the LOC_SRC or 3214 LOC_DST fields is known the receiver can parse the field and then 3215 discard the rest of the bits through the 4-octet boundary. 3217 APPENDIX B 3219 Decorrelation Example. 3221 This appendix demonstrates the decorrelation algorithm on a sample 3222 set of policies. This uses the optimizations presented. 3224 The correlated policy set C: 3226 src dst prot sport dport user sec level 3227 C1 199.93/16 199.100.2/24 TCP * 22 lsanchez sec 3228 C2 199.93/16 199.100.2/24 TCP * * lsanchez conf 3229 C3 199.93/16 199.100.2/24 UDP * * lsanchez * 3230 C4 199.93/16 199.100.2/24 UDP * 52 * * 3231 C5 199.93/16 199.100.2/24 * * * * * 3232 C6 * * * * * * * 3234 B.1 policy C1 3236 src dst prot sport dport user sec level 3237 C1: 199.93/16 199.100.2/24 TCP * 22 lsanchez sec 3239 By step 1, C1 becomes U1: 3241 The current uncorrelated policy set: 3242 U1 199.93/16 199.100.2/24 TCP * 22 lsanchez sec 3244 B.2 policy C2 3246 src dst prot sport dport user sec level 3247 C2: 199.93/16 199.100.2/24 TCP * * lsanchez conf 3249 C2 is uncorrelated with U1 because the security levels do not overlap. 3250 By step 2, C2 is added to U. 3252 The current uncorrelated policy set: 3253 U1 199.93/16 199.100.2/24 TCP * 22 lsanchez sec 3254 U2 199.93/16 199.100.2/24 TCP * * lsanchez conf 3256 B.3 policy C3 3258 src dst prot sport dport user sec level 3259 C3: 199.93/16 199.100.2/24 UDP * * lsanchez * 3261 C3 is uncorrelated with U because it uses UDP while both policies in 3262 U use TCP. By step 2, C3 is added to U. 3264 The current uncorrelated policy set: 3265 U1 199.93/16 199.100.2/24 TCP * 22 lsanchez sec 3266 U2 199.93/16 199.100.2/24 TCP * * lsanchez conf 3267 U3 199.93/16 199.100.2/24 UDP * * lsanchez * 3268 B.4 policy C4 3270 src dst prot sport dport user sec level 3271 C4: 199.93/16 199.100.2/24 UDP * 52 * * 3273 T = U o 3274 nil /| (src) 199.93/16 3275 T = U o 3276 nil /| (dst) 199.100.2/24 3277 T = U o 3278 nil /| (sport) * 3279 T = U o 3280 / \ 3281 ~lsanchez / \ (user) lsanchez 3283 We can end the algorithm here, since 3285 1) the ~lsanchez branch: 3286 199.93/16 199.100.2/24 UDP * 52 ~lsanchez * 3287 is uncorrelated with T since ~lsanchez does not overlap any policies 3288 in T. 3290 2) The lsanchez branch: 3291 199.93/16 199.100.2/24 UDP * 52 lsanchez * 3292 is overriden by the policy U3. 3294 The current uncorrelated policy set: 3295 U1 199.93/16 199.100.2/24 TCP * 22 lsanchez sec 3296 U2 199.93/16 199.100.2/24 TCP * * lsanchez conf 3297 U3 199.93/16 199.100.2/24 UDP * * lsanchez * 3298 U4 199.93/16 199.100.2/24 UDP * 52 ~lsanchez * 3299 B.5 policy C5 3301 src dst prot sport dport user sec level 3302 C5: 199.93/16 199.100.2/24 * * * * * 3304 T = U o 3305 nil /| (src) 199.93/16 3306 T = U o 3307 nil /| (dst) 199.100.2/24 3308 T = U o 3309 nil /| (sport) * 3310 T = U o 3311 _______/|\_______ 3312 ~UDP,~TCP / | \ (prot) UDP 3313 | o T=U3,U4 3314 | TCP |\_________ 3315 | | \ 3316 | | lsanchez | (user) ~lsanchez 3317 T=U1,U2 o o T = U4 3318 / \ (user) / \ 3319 ~lsanchez / \ lsanchez ~52 / \ (dport) 52 3320 | 3321 T=U1,U2 o 3322 _________/|\_________ 3323 ~sec,~conf / | \ (sec label) conf 3324 | sec 3325 | 3326 T = U1 o 3327 / \ 3328 ~22 / \ (dport) 22 3330 We can end the algorithm here since: 3332 1) The branch: 3333 199.93/16 199.100.2/24 ~UDP,~TCP * * * * 3334 is uncorrelated with T = U. 3336 2) The branch: 3337 199.93/16 199.100.2/24 UDP * * lsanchez * 3338 is overridden by U3. 3340 3) The branch: 3341 199.93/16 199.100.2/24 UDP * ~52 ~lsanchez * 3342 is uncorrelated with T = U4. 3344 4) The branch: 3345 199.93/16 199.100.2/24 UDP * 52 ~lsanchez * 3346 is overridden by U4. 3348 5) The branch: 3349 199.93/16 199.100.2/24 TCP * * ~lsanchez * 3350 is uncorrelated with T = U1, U2. 3352 6) The branch: 3353 199.93/16 199.100.2/24 TCP * * lsanchez ~sec,~conf 3354 is uncorrelated with T = U1, U2. 3356 7) The branch: 3357 199.93/16 199.100.2/24 TCP * * lsanchez conf 3358 is overridden by U2. 3360 8) The branch: 3361 199.93/16 199.100.2/24 TCP * ~22 lsanchez sec 3362 is uncorrelated with T = U1. 3364 9) The branch: 3365 199.93/16 199.100.2/24 TCP * 22 lsanchez sec 3366 is overridden by U1. 3368 The current uncorrelated policy set: 3369 U1 199.93/16 199.100.2/24 TCP * 22 lsanchez sec 3370 U2 199.93/16 199.100.2/24 TCP * * lsanchez conf 3371 U3 199.93/16 199.100.2/24 UDP * * lsanchez * 3372 U4 199.93/16 199.100.2/24 UDP * 52 ~lsanchez * 3374 U5 199.93/16 199.100.2/24 ~UDP,~TCP * * * * 3375 U6 199.93/16 199.100.2/24 UDP * ~52 ~lsanchez * 3376 U7 199.93/16 199.100.2/24 TCP * * ~lsanchez * 3377 U8 199.93/16 199.100.2/24 TCP * * lsanchez ~sec,~conf 3378 U9 199.93/16 199.100.2/24 TCP * ~22 lsanchez sec 3380 B.6 policy C6 3382 src dst prot sport dport user sec level 3383 C6: * * * * * * * 3385 T = U o 3386 /| 3387 ~199.93/16 / | (src) 199.93/16 3388 T = U o 3389 /| 3390 ~199.100.2/24 / | (dst) 199.100.2/24 3392 We can end the algorithm here since: 3394 1) The branch: 3395 ~199.93/16 * * * * * * 3396 is uncorrelated with all the policies in T. 3398 2) The branch: 3399 199.93/16 ~199.100.2/24 * * * * * 3400 is uncorrelated with all the policies in T. 3402 3) The branch: 3403 199.93/16 199.100.2/24 * * * * * 3404 is overridden by policy C5. 3406 The uncorrelated version of C: 3407 U1 199.93/16 199.100.2/24 TCP * 22 lsanchez sec 3408 U2 199.93/16 199.100.2/24 TCP * * lsanchez conf 3409 U3 199.93/16 199.100.2/24 UDP * * lsanchez * 3410 U4 199.93/16 199.100.2/24 UDP * 52 ~lsanchez * 3412 U5 199.93/16 199.100.2/24 ~UDP,~TCP * * * * 3413 U6 199.93/16 199.100.2/24 UDP * ~52 ~lsanchez * 3414 U7 199.93/16 199.100.2/24 TCP * * ~lsanchez * 3415 U8 199.93/16 199.100.2/24 TCP * * lsanchez ~sec,~conf 3416 U9 199.93/16 199.100.2/24 TCP * ~22 lsanchez sec 3418 U10 199.93/16 ~199.100.2/24 * * * * * 3419 U11 ~199.93/16 * * * * * * 3420 Disclaimer 3422 The views and specification here are those of the authors and are 3423 not necessarily those of their employers. The authors and their 3424 employers specifically disclaim responsibility for any problems 3425 arising from correct or incorrect implementation or use of this 3426 specification. 3428 Copyright (C) The Internet Society (November 1997). All 3429 Rights Reserved. 3431 This document and translations of it may be copied and furnished 3432 to others, and derivative works that comment on or otherwise 3433 explain it or assist in its implmentation may be prepared, copied, 3434 published and distributed, in whole or in part, without 3435 restriction of any kind, provided that the above copyright notice 3436 and this paragraph are included on all such copies and derivative 3437 works. However, this document itself may not be modified in any 3438 way, such as by removing the copyright notice or references to the 3439 Internet Society or other Internet organizations, except as needed 3440 for the purpose of developing Internet standards in which case the 3441 procedures for copyrights defined in the Internet Standards 3442 process must be followed, or as required to translate it into 3443 languages other than English. The limited permissions granted above 3444 are perpetual and will not be revoked by the Internet Society or 3445 its successors or assigns. 3447 This document and the information contained herein is provided on 3448 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 3449 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 3450 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 3451 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3452 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3454 Author Information 3456 Luis A. Sanchez Matthew N. Condell 3457 BBN Technologies BBN Technologies 3458 GTE Internetworking GTE Internetworking 3459 10 Moulton Street 10 Moulton Street 3460 Cambridge, MA 02140 Cambridge, MA 02140 3461 USA USA 3462 Email: lsanchez@bbn.com Email: mcondell@bbn.com 3463 Telephone: +1 (617) 873-3351 Telephone: +1 (617) 873-6203