idnits 2.17.1 draft-ietf-ipsec-vpn-policy-schema-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-27) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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. == Mismatching filename: the document gives the document name as 'draft-ipsec-vpn-policy-schema-00', but the file name used is 'draft-ietf-ipsec-vpn-policy-schema-00' ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 22 longer pages, the longest (page 0) being 62 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 91 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** The abstract seems to contain references ([7], [9]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 7 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 174: '... entity MUST perform when the corre...' RFC 2119 keyword, line 2090: '...hin those actual specification MUST be...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 472 has weird spacing: '...ecified inter...' == Line 714 has weird spacing: '...he form hhmms...' == Line 856 has weird spacing: '...ifetime in se...' == Line 1185 has weird spacing: '...used to carry...' == Line 1222 has weird spacing: '...related attri...' == (1 more instance...) == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'Bradner97' on line 105 -- Looks like a reference, but probably isn't: 'Piper98' on line 629 == Unused Reference: '5' is defined on line 2109, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-ipsec-arch-sec-01 ** Downref: Normative reference to an Historic draft: draft-ietf-ipsec-isakmp (ref. '2') ** Obsolete normative reference: RFC 2251 (ref. '3') (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) -- No information found for draft-ietf-ipsec-isakmp-oakl - is the name correct? -- Possible downref: Normative reference to a draft: ref. '4' -- No information found for draft-ietf-ipsec-doi - is the name correct? -- Possible downref: Normative reference to a draft: ref. '5' -- No information found for draft-ietf-policy-qosschema - is the name correct? -- Possible downref: Normative reference to a draft: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Normative reference to a draft: ref. '9' Summary: 15 errors (**), 0 flaws (~~), 13 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Editors 3 INTERNET DRAFT Partha Bhattacharya, IBM 4 Rob Adams, Cisco 5 William Dixon, Microsoft 6 Roy Pereira, Timestep 7 Raju Rajan, IBM 9 October 9 1998 10 An LDAP Schema for Configuration and Administration of IPSec based 11 Virtual Private Networks (VPNs) 12 draft-ipsec-vpn-policy-schema-00.txt 14 Status of Memo 16 This document is an Internet-Draft. Internet-Drafts are 17 working documents of the Internet Engineering Task Force 18 (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of 23 six months and may be updated, replaced, or obsoleted by 24 other documents at any time. It is inappropriate to use 25 Internet-Drafts as reference material or to cite them other 26 than as ``work in progress.'' 28 To learn the current status of any Internet-Draft, please 29 check the 30 ``1id-abstracts.txt'' listing contained in the 31 Internet-Drafts Shadow Directories on ftp.ietf.org (US 32 East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West 33 Coast), or munnari.oz.au (Pacific Rim). 35 Abstract 37 This document describes the structure of an LDAP directory 38 schema that enables policy based configuration and 39 administration of IPSec based Virtual private networks 40 within and among Internet domains, intranets, and extranets. 41 The schema extends the base IPSec Policy data model in [9] 42 to include end hosts and security gateways. The schema 43 closely follows and expands on the DEN specification [7]. 45 1. Introduction 47 IPSec [1], [2], [4] is a fairly large and complex protocol requiring 48 participating hosts to negotiate a number of configuration parameters 49 during protocol operation. These parameters typically have security 50 related implications, so that defaults specified in the IPSec 51 documents may not be acceptable to certain end hosts. In such 52 cases, IPSec negotiations would fail and manual intervention would 53 be required. Furthermore, the defaults may lead to redundancies 54 in situations where the end hosts are also performing security 55 operations at a higher layer (e.g. SSL). 57 The situation becomes more complex if security gateways have to be 58 traversed for two end hosts to communicate. Depending on the end 59 host application, a gateway may either deny or permit the connection 60 or require an IPSec tunnel from either the end host or another 61 gateway acting as a IPSec proxy for the end host. For successful 62 communication, the gateways have to be properly configured to 63 establish IPSec tunnels with certain end hosts and gateways. 65 In the light of the above discussion, it is plausible that manual 66 configuration of each IPSec host will become less and less viable 67 as more hosts become IPSec enabled. Directory based policy 68 administration is becoming increasingly popular as a versatile and 69 uniform means of managing network services. LDAP [3] is a widely 70 deployed industry standard for accessing directory information. This 71 document presents an LDAP schema for storing IPSec based policy 72 information in a central directory. The schema describes 74 - the required IP layer security attributes of a connection; i.e. 75 whether the connection should be blocked, permitted in the clear or 76 secured by IPSec, 78 - end to end IPSec security association attributes in case the 79 connection needs to be secured by IPSec, 81 - whether security gateways need to be traversed using IPSec; and if 82 so, then the gateway address and the corresponding IPSec security 83 association attributes, 85 - nested gateway traversal, etc. 87 We allow policies to be specified for groups of hosts by either 88 specifying groups or ranges of addresses or wildcarded domains. 89 Policies can also be specified by specific user ids as required by 90 IPSec. 92 The rest of the document is as follows. Section 2 provides general 93 ideas of representing policy rules through a Policy object, the 94 overview of the LDAP schema and the various object classes and their 95 inter-relationships. The schema described above closely follows the 96 policy class hierarchy described in the DEN document [7]. Sections 97 3-7 details the various objects and their attributes. Section 8 98 concludes with some VPN scenarios and examples. 100 1.1. Specification of Requirements 102 The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", 103 and "MAY" that appear in this document are to be interpreted as 104 described in [Bradner97]. 106 2. Class Hierarchy 108 In this section, we describe the various classes related to Policy 109 definition, their inheritance hierarchy and inter-relationships. 110 They are best understood within the Common Information Model [8] 111 of the Directory Management Task Force or the directory structure 112 proposed by the Directory Enabled Networks (DEN) specification [7]. 114 Top 115 |----Policy 116 | 117 |----PolicyCondition 118 | | 119 | |--IPPolicyCondition 120 | 121 |-----UserIDCondition 122 | 123 |----PolicyValidityPeriod 124 | 125 |----PolicyAction 126 | |----RSVPAction 127 | |----DiffServAction 128 | |----ISAKMPAction 129 | |----IPSecSecurityAction 130 | 131 |----DiffServResourceGroup 132 |----RSVPResourceGroup 133 |----ISAKMPProposal 134 |----IPSecProposal 135 |----IPSecTransform 136 |----IPSecPrivateDiffieHellmanGroup 137 | 138 |----PolicyContainmentAuxClass 140 The schema described here closely follows the policy class hierarchy 141 described in the current DEN document [7]. This document expands on 142 the DEN specification but differs in a few significant details, where 143 it was felt that the specification tended to be unclear or redundant. 145 A structural LDAP object class called Policy is defined as the 146 container for policy rules. An object of this class ``pieces 147 together'' several policy components relating to differentiated 148 services, RSVP and IPSec based VPNs. Only the IPSec related 149 parameters are described here; the RSVP and differentiated services 150 related parameters are described in a related document [6]. 152 A Policy rule is encoded as 154 if then 156 A PolicyCondition class specifies attributes that determine 157 when a policy rule applies. These include validity time related 158 parameters and traffic descriptors such as ranges of IP packet 159 header attributes, MAC addresses etc. The policy validity time 160 is described by reference to a PolicyValidityPeriod object that 161 specifies conditions restricting the validity period of a policy 162 rule. 164 IPPolicyCondition is a subclass of PolicyCondition and describes 165 the conditions based on IP packet header attributes. The reason 166 for subclassing PolicyCondition is to allow extensibility to other 167 networking protocols through sub-classes. Sometimes an IPSec policy 168 needs to be specified by specifiying host or user ids. This is 169 allowed by a reference to a UserIDCondition class that describes a 170 set of ids such as Host FQDN, User FQDN, X.500 name etc. 172 A PolicyAction class specifies a collection of attributes that detail 173 permissions or additional behaviors that the policy enforcement 174 entity MUST perform when the corresponding policy condition is 175 satisfied. The PolicyAction class is subclassed into a number 176 of protocol or service specific actions -- DiffServAction, 177 RSVPAction, ISAKMPAction and IPSecSecurityAction. The QoS related 178 classes: DiffServAction, RSVPAction, DiffServResourceGroup and 179 RSVPResourceGroup are defined in a related document [6]. This 180 document focuses on the IPSec related classes ISAKMPAction and 181 IPSecSecurityAction. 183 The ISAKMPAction class specifies attributes required to perform 184 an ISAKMP/Oakley Phase 1 exchange. These include exchange mode, 185 authentication types, Phase 1 proposals, Phase 1 connection 186 management parameters etc. The proposals are described by references 187 to ISAKMPProposal objects. If Private Diffie Hellman groups are to 188 be used in the proposal then an ISAKMPProposal object must contain 189 references to IPSecPrivateDiffieHellmanGroup objects describing 190 private Diffie Hellman groups. 192 The IPSecSecurityAction class specifies the security action (e.g. 193 permit/deny/secure) for a traffic stream. If the traffic is to be 194 secured by IPSec, then this class specifies attributes required for 195 ISAKMP Phase 2 (or Quick Mode) exchange. These include proxy ids, 196 Phase 2 proposals, and Phase 2 connection management parameters. 197 The Phase 2 proposals are described by references to IPSecProposal 198 objects. An IPSec Proposal consists of logically AND-ed combinations 199 of AH, ESP and IPCOMP protocols. The transform attributes for each 200 protocol are described by references to corresponding IPSecTransform 201 objects. 203 The modular object design is done to promote the sharing of objects 204 such as IPSecTransforms, IPSecProposals and ISAKMPProposals. 206 Finally, given a device identity, it must be possible to find 207 all the policies applicable for that device. The auxiliary class 208 PolicyContainmentAuxClass as defined in the DEN specification [7] is 209 for that purpose. It can be attached to a variety of classes that 210 describe devices. The PolicyContainmentAuxClass itself contains 211 an attribute PoliciesContainedRef describing a list of related 212 policies. Therefore the policies for a given device can be obtained 213 by retrieving all the objects specified by the PoliciesContainedRef 214 attribute in an appropriate class such Device (or any other class to 215 which the PolicyContainmentAuxClass class is attached). 217 3. The class Policy 219 The Policy object class is the container class for the policy rules. 220 It contains a number of entries, each entry encodes a policy rule 221 that specifies the resources and services that are allowed (or 222 denied) to a stream of packets. An overview of the class Policy is 223 presented below, followed by the detailed sytax and semantics of 224 various attributes. 226 NAME Policy 227 TYPE Structural 228 DERIVED FROM Top 229 MUST 230 CommonName, 231 PolicyScope, 232 PolicyConditionRef, 233 PolicyActionRef, 234 PolicyVersion 235 MAY 236 PolicyRulePriority, 237 PolicyKeyword, 238 PolicyType, 239 PolicyName, 240 PolicyEnabled 242 The syntax and semantics of the attributes of the class Policy are as 243 follows: 245 NAME CommonName 246 DESC The common name for objects of this class. Used as relative 247 distinguished name to identify object within a branch of 248 directory tree. 249 SYNTAX IA5String 250 EQUALITY caseExactIA5Match 251 SINGLE-VALUED 253 NAME PolicyScope 254 DESC Lists the services that are controlled through this policy 255 EQUALITY caseExactIA5Match 256 SYNTAX IA5String 257 MULTI-VALUED 258 FORMAT: The currently defined values for this attribute are: 259 DiffServ 260 RSVP 261 IPSec 262 ISAKMP 263 SEMANTICS: This attribute is used by the appropriate directory clients 264 to fetch only those policy rules that are relevant for their 265 functionality. The value DiffServ' means the policy rule 266 specifies DiffServ packet classification and traffic treatment. 267 The value `RSVP' means specifes an RSVP policy 268 decision point. The value `IPSec' means the policy refers 269 to an IPSec action rule. The value `ISAKMP' means the policy 270 refers to an ISAKMP action rule. Note that this is a multi- 271 valued attribute, and the same rule may regulate multiple 272 services for a packet stream. 274 NAME PolicyConditionRef 275 DESC Absolute Distinguished name of LDAP entry of the objectclass 276 PolicyCondition, that identify the packets that the policy rule 277 applies to. 278 EQUALITY distinguishedNameMatch 279 SYNTAX DN 280 SINGLE-VALUED 282 The following reference attributes specify the treatment of packets 283 that match the condition specified in the policy rule. The value 284 of a reference attribute is the distinguished name of an LDAP entry 285 which is an object corresponding to a prespecified class. For 286 instance, if the value of the attribute PolicyActionRef is the 287 distinguished name of an entry in the class RSVPAction, then the 288 policy rule specifies the policy relating to the handling of RSVP 289 signalling messages. 291 NAME PolicyActionRef 292 DESC Absolute Distinguished name(s) of LDAP entry, of the objectclass 293 PolicyAction, that specifies permissions and restrictions 294 that apply to the packets identified by the policy condition 295 EQUALITY distinguishedNameMatch 296 SYNTAX DN 297 MULTI-VALUED 298 SEMANTICS Multiple values are understood as logical AND; that is, all 299 the actions must be performed 300 NAME PolicyVersion 301 DESC The version of the policy schema embodied by this policy. 302 SYNTAX IA5String 303 FORMAT The current draft specifies version ``1.0'' 304 EQUALITY caseExactIA5Match 305 SINGLE-VALUED 306 NAME PolicyKeyword 307 DESC List of keywords that assist in locating this policy 308 SYNTAX IA5String 309 MULTI-VALUED 310 DEFAULT No Keywords 312 NAME PolicyType 313 DESC Describes the types of a policy 314 SYNTAX IA5String 315 MULTI-VALUED 316 FORMAT The following values are allowed: 317 ISAKMPPhase1 318 ISAKMPPhase2 319 IPSecDataLocal 320 IPSecDataRemote 321 RSVPSignalling 322 RSVP-DiffServ 323 DiffServ 325 SEMANTICS ISAKMPPhase1 denotes an ISAKMP Phase 1 policy 326 ISAKMPPhase2 denotes an ISAKMP Phase 2 or Quick Mode policy 327 IPSecDataLocal denotes a policy for securing locally 328 originating data by IPSec. Local means either originating 329 from the same host or from an host for which this host 330 acts as a proxy 331 IPSecDataRemote denotes a policy for securing remotely 332 originating data by IPSec. Remote is the opposite of Local 333 as defined before. 334 RSVPSignalling denotes an RSVP signalling policy 335 RSVP-DiffServ denotes a policy for mapping an RSVP traffic 336 into a DiffServ pipe 337 DiffServ denotes a DiffServ policy 339 DEFAULT Unnamed Type 341 NAME PolicyName 342 DESC A user friendly name of this policy class 343 SYNTAX IA5String 344 SINGLE-VALUED 345 DEFAULT No Name 347 The following attribute defines relationships among multiple related 348 rules within the policy repository. 350 NAME PolicyRulePriority 351 DESC Priority level for this rule. Used to resolve ambiguity in 352 condition matching when the ranges specified in the Policy 353 conditions overlap. Higher values of this attribute imply 354 higher priority of the rule. 355 EQUALITY integerMatch 356 SYNTAX INTEGER 357 DEFAULT The default value is 0 (lowest priority) 358 SINGLE-VALUED 359 SEMANTICS: Whenever a packet matches two rules of different priority, 360 the rule with the higher value of PolicyRulePriority is 361 applied. 363 NAME PolicyEnabled 364 DESC A flag describing whether the policy is currently enabled or 365 disabled 366 SYNTAX IA5String 367 EQUALITY caseExactIA5Match 368 SINGLE-VALUED 369 FORMAT The currently defined values for this attribute are: 370 Enabled 371 Disabled 372 DEFAULT Enabled 374 3.1. PolicyContainmentAuxClass 376 Policy rules may need to be grouped together for a number 377 of different purposes -- organizational, security, ease of 378 administration, or ease of retrieval by a policy decision point. We 379 reproduce the PolicyContainmentAuxClass from the DEN specification 380 [7] that serves the useful purpose of grouping policies together. 381 This auxillary class definition is as follows: 383 NAME PolicyContainmentAuxClass 384 TYPE Auxillary 385 DERIVED FROM Top 386 AUXILIARY CLASS None 387 POSSIBLE SUPERIORS Organization, OrganizationalUnit, Group, 388 GroupOfDevices 389 MUST PoliciesContainedRef 390 MAY 392 The syntax and semantics of its sole attribute are as follows: 394 NAME PoliciesContainedRef 395 DESC Absolute distinguished names of policies grouped together 396 for some (context-dependent) purpose. 397 SYNTAX DN 398 EQUALITY distinguishedNameMatch 399 MULTI-VALUED 401 4. Policy Conditions 403 In this section we define the abstract class PolicyCondition, its 404 subclass IPPolicyCondition, and the class UserIDCondition. These 405 classes list the conditions that must be statisfied by a stream of 406 packets in order for the referring rule to apply to that packet 407 stream. 409 The reason for subclassing PolicyCondition is to allow extensibility 410 to other networking protocols through sub-classes such as 411 ATMPolicyCondition (for instance). 413 NAME PolicyCondition 414 TYPE Abstract 415 DERIVED FROM Top 416 AUXILIARY CLASS None 417 MUST CommonName 418 MAY PolicyConditionName 419 PolicyValidityPeriodRef 421 The detailed syntax and semantics of the attributes is as below: 423 NAME CommonName 424 DESC The common name of the policy condition object. Unique within a 425 limited scope and used to identify the object within the 426 directory tree. 427 SYNTAX IA5String 428 EQUALITY caseExactIA5Match 429 SINGLE-VALUED 431 NAME PolicyConditionName 432 DESC The user friendly name of this entry.The Name related attributes 433 are only for ease of user administration. 434 EQUALITY caseExactIA5Match 435 SYNTAX IA5String 436 SINGLE-VALUED 437 The next attribute is a reference to PolicyValdityPeriod object that 438 identifies the entry that limits the temporal scope of the policy to 439 specified periods of time. 441 NAME PolicyValidityPeriodRef 442 DESC Absolute distinguished name(s) of an PolicyValidityPeriod 443 object that specifies the times that the policy is active. 444 EQUALITY distinguishedNameMatch 445 MULTI-VALUED 446 SYNTAX DN 447 DEFAULT Policy applies at all times 449 4.1. The class IPPolicyCondition 451 The class PolicyCondition is now specialized to deal with IPv4 packet 452 headers in the class IPPolicyCondition. 454 NAME IPPolicyCondition 455 TYPE Structural 456 DERIVED FROM PolicyCondition 457 AUXILIARY CLASSES none 458 MAY Interface, 459 SourceIPAddressRange, 460 DestinationIPAddressRange, 461 SourcePortRange, 462 DestinationPortRange, 463 IPProtocolNumberRange, 464 ReceivedTOSByteCheck 465 HostUserIDRef 466 The first attribute limits the spatial scope of the policy rule by 467 identifying specific router interfaces where the policy is to be 468 applied. 470 NAME Interface 471 DESC An attribute that limits the scope of the policy to packets on 472 specified interface(s) and the direction(s) of traffic on these. 473 EQUALITY caseExactIA5Match 474 SYNTAX IA5String 475 MULTI-VALUED 476 FORMAT Three colon seperated strings. The left-most string is a numeral 477 denoting the type of the specification, followed by the incoming 478 and outgoing interface identifiers. Currently defined type/value 479 formats are 480 1:: 481 2:: 482 The IP addresses are in dotted decimal notation. The interface 483 IDs are integers unique to the host device. 485 The first address string specifies a restriction of the rule 486 to traffic inbound on the interface, and the rightmost string 487 specifies a corresponding restriction of the rule to traffic 488 outbound from that interface. An unspecified interface(s) 489 defaults to all interfaces on the device that this rule 490 applies to. 492 EXAMPLE 1:9.3.1.52:9.2.1.54 (Applies to traffic inbound on 9.3.1.52 493 and outbound on 9.3.1.54) 494 1:9.3.1.32: (Applies to traffic inbound on 9.3.1.52 495 outgoing from any interface) 496 2::3 (Applies to traffic outbound on interface 3 497 arriving on any interface) 498 DEFAULTS Defaults to traffic inbound on all interfaces, outbound on 499 all interfaces. 501 NAME SourceIPAddressRange 502 DESC Source IP addresses to which the policy applies 503 EQUALITY caseExactIA5Match 504 SYNTAX IA5String 505 SINGLE-VALUED 506 FORMAT SourceIPAddressRange is of the following form: three colon (':') 507 separated strings denoting a range of IP addresses. The 508 following formats are currently defined 510 1:: 511 The IP v4 address is in dotted decimal format. The 512 CIDRPrefixLength is the number of unmasked leading bits. 513 A packet matches the condition if the unmasked 514 bits on the packet are identical to the unmasked bits on the 515 condition. 517 2:: 518 IP addresses in dotted decimal format. The second 519 address must be no smaller than the first. The first 520 denotes the start of the range, and the second denotes 521 the end of the range. A packet matches the condition 522 if its source address is no smaller than the first 523 IP address in the condition, and no larger than the 524 second. 526 3 527 Indicates policy applies to locally generated packets. 528 EXAMPLE 1:83.23.23.1:24 529 A packet with source address 83.23.23.5 matches. 530 A packet with source address 83.23.24.1 does not. 531 2:83.23.23.0:83.28.28.0 532 A packet with source address 83.23.23.5 matches. 533 A packet with source address 83.29.24.1 does not. 534 DEFAULT Defaults to the entire address range, i.e., every packet 535 matches the source address range condition. 536 NAME DestinationIPAddressRange 537 DESC Destination IP addresses to which policy applies 538 EQUALITY caseExactIA5Match 539 SYNTAX IA5String 540 SINGLE-VALUED 541 FORMAT Identical to that of SourceIPAddressRange above. 542 The value of ``3''indicates a locally destined packet. 543 DEFAULT Defaults to the entire address range, i.e., every packet 544 matches the destination address range condition. 545 NAME SourcePortRange 546 DESC Source Ports to which policy applies 547 EQUALITY caseExactIA5Match 548 SYNTAX IA5String 549 SINGLE-VALUED 550 FORMAT String consisting of two colon separated positive 551 integers, the second no smaller than the first, or one 552 positive integer. 553 DEFAULT Defaults to the entire port range 0 to 65535, i.e., every 554 packet matches the destination address range condition. 555 EXAMPLE 8000:8080 (ports 8000 to 8080), 556 8000 (only port 8000) 557 NAME DestinationPortRange 558 DESC Destination Ports to which policy applies 559 EQUALITY caseExactIA5Match 560 SYNTAX IA5String 561 SINGLE-VALUED 562 FORMAT String consisting of two colon separated positive 563 integers, the second no smaller than the first, or one 564 positive integer. 565 DEFAULT Defaults to the entire port range 0 to 65535, i.e., every 566 packet matches the source address range condition. 568 NAME IPProtocolNumberRange 569 DESC Protocol numbers to which policy applies 570 EQUALITY integerMatch 571 SYNTAX INTEGER 572 SINGLE-VALUED 573 FORMAT String consisting of two colon separated positive 574 integers, the second no smaller than the first, or one 575 positive integer. 576 DEFAULT Defaults to the entire protocol range 0 to 255, i.e., every 577 packet matches the ip protocol range condition. 578 EXAMPLE 50:51 (protocol 50 to 51), 579 50 (only protocol 50) 581 NAME ReceivedTOSByteCheck 582 DESC A condition attribute used to select traffic based on the 583 contents of the TOS byte of the received packet's IP header 584 EQUALITY caseExactIA5Match 585 SYNTAX IA5String 586 SINGLE-VALUED 587 FORMAT String of the form xxxxxxxx:xxxxxxxx, where each of the 588 x's is either 0 or 1. 589 SEMANTICS Each of the substrings is treated as specifying an 8-bit 590 field. The left substring is termed Mask and the right 591 substring Match. The TOS byte of the received packet's IP 592 header is ANDed with Mask and the result is compared against 593 Match. The combination of Mask and Match allows definition of 594 TOS byte based conditions where certain bits in the TOS byte 595 may be ignored for the purpose of comparison. 596 EXAMPLE An incoming packet with TOS byte 11001010 matches the 597 condition specified by a value of 00111100:00001000 for 598 ReceivedTOSByte. 599 NAME UserIDConditionRef 600 DESC Absolute Distinguished name(s) of LDAP entry or entries, of 601 an UserIDCondition object that identify the user or 602 host whose packets that the policy rule applies to. 603 EQUALITY distinguishedNameMatch 604 SYNTAX DN 605 MULTI-VALUED 607 4.2. The Class UserIDCondition 609 In many scenarios, for instance an end host IPSec, policy needs to 610 be specified for a user or a host ID instead of an IP address. A 611 standard example is a corporate worker connecting from home via an 612 ISP. The policy would be specified by Host FQDN, UserFQDN, X500 DN 613 etc. To accomodate this source and destination ids are required. 615 NAME HostUserID 616 TYPE Structural 617 DERIVED FROM Top 618 AUXILIARY CLASS None 619 MUST CommonName 620 MAY SourceID, 621 DestinationID, 622 NAME SourceID 623 DESC Source Host Identifier 624 SYNTAX IA5String 625 EQUALITY caseExact1A5Match 626 MULTI-VALUED 627 FORMAT Two strings , colon (`:') seperated, the first describing the 628 ID type and the second the ID value. The valid IdTypes and 629 their corresponding values are defined in [Piper98]. These 630 include: 631 Host-FQDN: 632 User-FQDN: 633 X500-DN: 634 X500-GN: 635 Key-Id: 636 DEFAULT Any ID is considered valid. 638 NAME DestinationID 639 DESC Destination Host Identifier 640 SYNTAX IA5String 641 EQUALITY caseExact1A5Match 642 MULTI-VALUED 643 DEFAULT Any ID is considered valid. 644 FORMAT Same as Source ID 646 5. The class PolicyValidityPeriod 648 Objects of this class describe conditions that restrict the validity 649 period of the policy rule. The class definition is as follows: 651 NAME PolicyValidityPeriod 652 TYPE Structural 653 DERIVED FROM Top 654 AUXILIARY CLASSES NONE 655 MUST CommonName 656 MAY PolicyValidityPeriodName, 657 PolicyValidityTime, 658 PolicyValidityMonthMask, 659 PolicyValidityDayOfWeekMask, 660 PolicyValidityTimeOfDayRange 662 The syntax and semantics of various attributes are as given below 664 NAME PolicyValidityPeriodName 665 DESC The user friendly name of this entry. 666 EQUALITY caseExactIA5Match 667 SYNTAX IA5String 668 SINGLE-VALUED 670 NAME PolicyValidityTime 671 DESC When this policy is valid 672 EQUALITY caseExactIA5Match 673 SYNTAX IA5String 674 MULTI-VALUED 675 FORMAT String(s) of the form yyyymmddhhmmss:yyyymmddhhmmss: 676 SEMANTICS The first two substrings must be valid times, 677 (year-month-date-hour-minute- second) the second larger 678 than the first. The last substring is optional and 679 describes the time zone. 680 DEFAULT If the time zone is omitted then the time is local time at 681 the policy decision point. If the attribute itself is absent 682 then the policy is always valid. 683 EXAMPLE 19980121060000:19991231133000:GMT 684 (meaning Policy in effect from 6:00 AM on January 21, 1998 685 to 1:30 PM on December 31, 1999, Greenwich Mean Time). 687 NAME PolicyValidityMonthMask 688 DESC Months during which policy is valid 689 EQUALITY caseExactIA5Match 690 SYNTAX IA5String 691 SINGLE-VALUED 692 FORMAT String denoting a mask of 12 0s and 1s. 693 SEMANTICS 1's corresponding to months in the January to December 694 range when the policy is valid. 695 EXAMPLE 000111111100 (Valid from April until October) 696 DEFAULT 111111111111, i.e., valid always 698 NAME PolicyValidityDayOfWeekMask 699 DESC days during which policy is valid 700 EQUALITY caseExactIA5Match 701 SYNTAX IA5String 702 SINGLE-VALUED 703 FORMAT String representing a mask of 7 0s and 1s. 704 SEMANTICS 1's correspond to days in the Monday to Sunday range 705 when the policy is valid. 706 EXAMPLE 1111100 (Valid weekdays) 707 DEFAULT 1111111, i.e., valid always 709 NAME PolicyValidityTimeOfDayRange 710 DESC Time(s) of day during which policy is valid 711 EQUALITY caseExactIA5Match 712 SYNTAX IA5String 713 MULTI-VALUED 714 FORMAT String(s) of the form hhmmss:hhmmss 715 SEMANTICS Substrings on either side of the colon must be be valid 716 time of day values. If the second string is not larger 717 than the first, then a wrap around midnight is assumed. 718 EXAMPLE 090000:170000 (Policy valid from 9 AM to 5 PM) 719 DEFAULT 000000:235959 720 6. The class PolicyAction 722 While implementing policy within a network device, the 723 PolicyCondition helps identify a substream of packets that 724 are to be granted access to network resources, in a manner that is 725 specified by an instantiation of the class PolicyAction. 727 The class definition is as follows. 729 NAME PolicyAction 730 TYPE Abstract 731 DERIVED FROM Top 732 AUXILIARY CLASSES NONE 733 MUST CommonName 735 The PolicyAction is subclassed into a number of protocol or service 736 specific actions, each of which is described next. 738 6.1. The class ISAKMPAction 740 This class describes the ISAKMP/Oakley action attributes for 741 the traffic flow as described by the linked IPPolicyCondition or 742 AuxIDPolicyCondition object. 744 NAME ISAKMPAction 745 TYPE Structural 746 DERIVED FROM PolicyAction 747 AUXILIARY CLASSES NONE 748 DESC Describes ISAKMP/Oakley Phase 1 actions 749 MUST CommonName, 750 ISAKMPExchangeMode, 751 ISAKMPProposalRef 752 MAY 753 ISAKMPActionName, 754 LocalHostPublicKeyInfo, 755 RemoteHostPublicKeyInfo, 756 MinSecurityAssociationLifetimeSec, 757 MinSecurityAssociationLifetimeKBytes, 758 ISAKMPConnectionLifetimeSec, 759 ISAKMPConnectionKBytes, 760 SecurityAssociationRefreshThreshold, 761 ISAKMPConnectionAutoStartFlag 763 NAME ISAKMPActionName 764 DESC The user friendly name of this entry. 765 EQUALITY caseExactIA5Match 766 SYNTAX IA5String 767 SINGLE-VALUED 768 The ISAKMPExchangeMode attribute denotes the ISAKMP/Oakley key 769 exchange mode: main or aggressive. 771 NAME ISAKMPExchangeMode 772 DESC ISAKMP-Oakley key Exchange mode 773 EQUALITY integerMatch 774 SYNTAX INTEGER 775 SINGLE-VALUED 776 FORMAT The values can be found in [4] 777 DEFAULT The value corresponding to Main mode 779 The ISAKMPProposalRef attribute describes a set of ordered 780 ISAKMP proposals. Since LDAP does not support ordered lists, the 781 ISAKMPProposalRef attribute is defined as a composite string in order 782 to be able to capture the relative ordering of the proposals. 784 NAME ISAKMPProposalRef 785 DESC Ordered list of absolute DNs of ISAKMPProposal objects 786 EQUALITY caseExactIA5Match 787 SYNTAX IA5String 788 MULTI-VALUED 789 FORMAT The format is `pref:ISAKMPProposalDN' where 790 - pref is an integer denoting the relative preference of 791 the proposal. Lower number has higher preference. 792 - ISAKMPProposalDN denotes the distinguishing name (DN) of an 793 ISAKMPProposal object 795 The following two attributes describe information about the 796 repository of public keys for the source and the destination. The 797 information consists of the type of the public key repository (e.g. 798 Secure DNS, Certificate Authority, LDAP-Directory, Inline ISAKMP), 799 the host name of the public key repository, and acceptable public key 800 certificate encodings. 802 These are specified as part of policy so that an IPSec host 803 can perform the proper public key operations during an actula 804 ISAKMP/Oakley exchange. 806 NAME LocalHostPublicKeyInfo 807 DESC Information about local hosts's public key. Required for public 808 key based Authentication in ISAKMP 809 EQUALITY caseIgnoreMatch 810 SYNTAX IA5 String 811 MULTI-VALUED 812 FORMAT: A string of the form `Type : IPName : X500Name: Encoding', where 813 - Type is any one of the following types of Public key CAs: 814 SecureDNS, 815 CA, 816 LDAP-Directory 817 Inline-ISAKMP 819 - IPName is the fully qualified domain name of the allowed 820 certificate authority. It is required for Types `SecureDNS', 821 `CA' and `LDAP-Directory' 822 - X500Name is the X500 DN of the CA (for Types `CA' and 823 `LDAP-Directory') 824 - Encoding is the acceptable certificate when source is using 825 Inline ISAKMP to transfer public keys. The following values 826 are allowed: 827 X.509 828 PKCS 829 DNS-SIG`KEY 830 SPKI 831 Multiple values of the attribute is treated as logical OR. 832 DEFAULT implementation dependent 834 NAME RemoteHostPublicKeyInfo 835 DESC Information about remote hosts's public key. Required for public 836 key based Authentication in ISAKMP 837 EQUALITY integerMatch 838 SYNTAX INTEGER 839 MULTI-VALUED 840 FORMAT same as LocalHostPublicKeyInfo 841 DEFAULT implementation dependent 843 The following two attributes specify minimum ISAKMP security 844 association lifetimes. A received ISAKMP negotiation request with 845 values smaller than this value are rejected. 847 NAME MinSecurityAssociationLifetimeKBytes 848 DESC Minimum Security Association Lifetime in kiloBytes for use in 849 ISAKMP negotiation 850 EQUALITY integerMatch 851 SYNTAX INTEGER 852 SINGLE-VALUED 853 DEFAULT implementation dependent 855 NAME MinSecurityAssociationLifetimeSec 856 DESC Minimum Security Association Lifetime in seconds for use in 857 ISAKMP negotiation 858 EQUALITY integerMatch 859 SYNTAX INTEGER 860 SINGLE-VALUED 861 DEFAULT implementation dependent 863 Often it may be desirable to have a long lived ``ISAKMP connection" 864 between two hosts, implying that the ISAKMP Security Associations 865 must be automatically re-negotiated when the (negotiated) security 866 association lifetime expires. The following two attributes specify 867 these values. 869 NAME ISAKMPConnectionLifetimeKBytes 870 DESC A large Lifetime in kiloBytes during which ISAKMP Security 871 Associations are periodically renegotiated once they expire 872 EQUALITY integerMatch 873 SYNTAX INTEGER 874 SINGLE-VALUED 875 DEFAULT The ISAKMP security associations are re-negotiated forever; that 876 is the lifetime is infinity 878 NAME ISAKMPConnectionLifetimeSec 879 DESC A large Lifetime in seconds during which ISAKMP Security 880 Associations are periodically renegotiated once they expire 881 EQUALITY integerMatch 882 SYNTAX INTEGER 883 SINGLE-VALUED 884 DEFAULT The ISAKMP security associations are renegotiated forever; that 885 is the lifetime is infinity 887 The SecurityAssociationRefreshThreshold attribute denotes a fraction 888 of negotiated ISAKMP security association Lifetime at which the 889 ISAKMP security association must be refreshed. For example, if the 890 SecurityAssociationRefreshThreshold is 0.9 and the negotiated ISAKMP 891 security association lifetime is 100MBytes, then a new security 892 association must be negotiated when 90 MBytes has been transferred. 894 NAME SecurityAssociationRefreshThreshold 895 DESC Fraction of negotiated ISAKMP Security Association Lifetime at 896 which an ISAKMP security association must be refreshed 897 EQUALITY caseIgnoreMatch 898 SYNTAX IA5String 899 SINGLE-VALUED 900 FORMAT a:b where a and b are integers 901 SEMANTICS a:b means a/b 902 DEFAULT implementation dependent 904 The ISAKMPConnectionAutoStart flag denotes whether the ISAKMP 905 association must be negotiated at system initialization. 907 NAME ISAKMPConnectionAutoStartFlag 908 DESC Flag denoting whether the ISAKMP security association must be 909 automatically negotiated at system initialization 910 EQUALITY integerMatch 911 SYNTAX INTEGER 912 SINGLE-VALUED 913 FORMAT 1 (YES), 0 (NO) 914 DEFAULT 0 915 6.2. The class IPSecSecurityAction 917 This class describes the IPSec Security action and related attributes 918 for a traffic flow. 920 NAME IPSecSecurityAction 921 TYPE Structural 922 DERIVED FROM PolicyAction 923 AUXILIARY CLASSES NONE 924 DESC Describes ipsec (Phase 2) security rules 925 MUST 926 CommonName 927 SecurityAction 928 MAY 929 IPSecSecurityActionName, 930 LocalIPSecTunnelEndPoint, 931 RemoteIPSecTunnelEndPoint, 932 LocalProxiedAddressRange, 933 RemoteProxiedAddressRange, 934 LocalProxiedPort, 935 RemoteProxiedPort, 936 ProxiedIPProtocol, 937 ProxiedHostScope, 938 IPSecProposalRef, 939 ISAKMPActionRef, 940 MinSecurityAssociationLifetimeSec, 941 MinSecurityAssociationLifetimeKBytes, 942 IPSecConnectionLifetimeSec, 943 IPSecConnectionLifetimeKBytes, 944 SecurityAssociationRefreshThreshold, 945 IPSecAutoStartFlag 947 The IPSECSecurityActionName is the user friendly name of this object. 949 NAME IPSECSecurityActionName 950 DESC The user friendly name of this entry. 951 EQUALITY caseExactIA5Match 952 SYNTAX IA5String 953 SINGLE-VALUED 955 The SecurityAction attribute states the security action for the flow. 957 NAME SecurityAction 958 DESC Security action for the datagram 959 EQUALITY caseExactStringMatch 960 SYNTAX IA5String 961 SINGLE-VALUED 962 FORMAT The following values are allowed 963 Permit 964 Deny 965 PermitIfInboundIPSec 966 SEMANTICS Deny means that the packet must be dropped. 968 Permit means that the packet must be allowed and further 969 processing depends on the presence of the IPSecProposalRef 970 attribute. If such an attribute is present, then the packet 971 must be secured by IPSec; else the packet is transmitted 972 in the clear. 974 PermitIfInboundIPSec means that if the packet has already 975 received inbound IPSec processing, then it must be processed 976 according to `Permit' rules; else it must be dropped. This 977 is to disallow packets that attempt to bypass inbound 978 IPSec processing. 980 The next two attributes specifies the two end points of the IPSec 981 security association that must carry the traffic. These attributes 982 are relevant if the SecurityAction attribute is `Permit' or 983 `PermitIfInboundIPSec' and there is an IPSecProposalRef attribute 984 implying that the traffic must be secured by IPSec. 986 For some applications, it may not be required to specify these two 987 attributes and the defaults may suffice (see examples in section 8) 989 NAME LocalIPSecTunnelEndPoint 990 DESC Address of the local IPSec host 991 EQUALITY caseIgnoreMatch 992 SYNTAX IA5 String 993 SINGLE-VALUED 994 FORMAT The following formats are supported 995 1: 996 2: 997 DEFAULT Any one of the local interface addresses for the host for 998 which the policy is applicable 1000 NAME RemoteIPSecTunnelEndPoint 1001 DESC A list of potential addresses of the remote IPSec host 1002 EQUALITY caseIgnoreMatch 1003 SYNTAX IA5 String 1004 MULTI-VALUED 1005 FORMAT Same as LocalIPSecTunnelEndPoint 1006 DEFAULT If the packet is a locally destined IPSec Quick Mode packet 1007 then the RemoteIPSecTunnelEndPoint is the source address in 1008 the packet (that matches the policy conditions) 1010 If the packet is a data packet that is to be forwarded after 1011 IPSec processing then the RemoteIPSecTunnelEndPoint is the 1012 destination address in the packet (that matches the policy 1013 conditions) 1014 SEMANTICS If the SecurityAction is Permit and there is an IPSecProposalRef 1015 attribute then, the flow described in the linked PolicyCondition 1016 object must be carried by an IPSec security association 1017 between the two hosts described by the LocalIPSecTunnelEndPoint 1018 and RemoteIPSecTunnelEndPoint attributes. 1020 The LocalIPSecTunnelEndPoint attribute represents a particular 1021 interface for the local host. This is useful for multihomed hosts. 1023 Multiple RemoteIPSecTunnelEndPoints are treated as logical OR. 1025 The following six attributes together define the traffic in the 1026 Identity payload in the IPSec Quick Mode negotiation. 1028 The LocalProxiedAddressRange, ProxiedIPProtocol and LocalProxiedPort 1029 attributes define the traffic for which the LocalIPSecTunnelEndPoint 1030 host acts as a proxy. 1032 The RemoteProxiedAddressRange, ProxiedIPProtocol and 1033 RemoteProxiedPort attributes define the traffic for which the 1034 RemoteIPSecTunnelEndPoint host acts as a proxy. 1036 The ProxiedHostScope attribute describes whether a separate 1037 IPSec Security Association is required for each pair of hosts in 1038 (LocalProxiedAddressRange, RemoteProxiedAddressRange) or only one is 1039 required for that entire range of hosts. 1041 NAME LocalProxiedAddressRange 1042 DESC Local proxied address range for use in ISAKMP Quick Mode payload 1043 EQUALITY caseIgnoreMatch 1044 SYNTAX IA5 String 1045 SINGLE-VALUED 1046 FORMAT identical to SourceIPAddressRange in the IPPolicyCondition class. 1047 DEFAULT The entire address range 1049 NAME RemoteProxiedAddressRange 1050 DESC Remote proxied address range for use ISAKMP Quick Mode Identity 1051 payload 1052 EQUALITY caseIgnoreMatch 1053 SYNTAX IA5 String 1054 SINGLE-VALUED 1055 FORMAT identical to SourceIPAddressRange in the IPPolicyCondition class. 1056 DEFAULT The entire address range 1058 NAME ProxiedProtocol 1059 DESC Proxied protocol for use in ISAKMP Quick Mode payload 1060 EQUALITY caseIgnoreMatch 1061 SYNTAX INTEGER 1062 SINGLE-VALUED 1063 DEFAULT The protocol value in the packet that matches the flow described 1064 in the linked PolicyCondition object 1066 NAME LocalProxiedPort 1067 DESC local proxied port for use in ISAKMP Quick Mode Identity payload 1068 EQUALITY integerMatch 1069 SYNTAX INTEGER 1070 SINGLE-VALUED 1071 DEFAULT The local port number in the packet that matches the flow. 1073 NAME RemoteProxiedPort 1074 DESC remote proxied port for use in ISAKMP Quick Mode Identity payload 1075 EQUALITY integerMatch 1076 SYNTAX INTEGER 1077 SINGLE-VALUED 1078 DEFAULT The remote port number in the packet that matches the flow 1080 NAME ProxiedHostScope 1081 DESC Describes whether IPSec Security Association is one for each pair 1082 of hosts in (LocalProxiedAddressRange,RemoteProxiedAddressRange) or 1083 one for the entire range of hosts. 1084 EQUALITY integerMatch 1085 SYNTAX INTEGER 1086 SINGLE-VALUED 1087 FORMAT The following values are allowed 1088 0x00 1089 0x01 (i.e. Least Significant Bit(LSB) is set) 1090 0x02 (i.e. LSB+1 is set) 1091 0x03 (i.e. both LSB and LSB+1 are set) 1092 SEMANTICS LSB corresponds to local address while LSB+1 corresponds to 1093 Remote address. The semantics for each bit is identical. 1095 If LSB is reset then the entire set of addresses defined by 1096 the LocalProxiedAddressRange attribute must be carried over 1097 one IPSec security association. 1099 If the LSB is set then a distinct IPSec security association 1100 must be used for each host in the range of the 1101 LocalProxiedAddressRange attribute. 1103 Identical logic applies for the LSB+1 bit and the 1104 RemoteProxiedAddressRange attribute 1106 DEFAULT The value 0x00; meaning that only one IPSec tunnel must be 1107 used for the entire set of LocalProxiedAddressRange and 1108 RemoteAddressRange values. 1110 The explicit rules for matching Proxied addresses are as follows: 1112 1. If the packet is a locally destined IPSec Quick Mode packet (i.e. 1113 this host is acting as an IPSec Quick Mode responder), then the 1114 processing is as follows: 1116 The source address in the packet must be contained in the 1117 RemoteTunnelEndPoint values (if specified). 1119 If the LSB in ProxiedHostScope is set, then the IDci presented 1120 must be a single address within the RemoteProxiedAddresssRange 1121 and further, must be equal to the source address in the packet. 1122 Otherwise, the IDci must be entire RemoteProxiedAddressRange. 1124 Similarly, if the LSB+1 bit is set then the IDcr presented 1125 must be a single address within the LocalProxiedAddressRange 1126 and further, must be equal to the destination address in 1127 the packet. Else, the IDcr presented must be the entire 1128 LocalProxiedAddressRange. 1130 2. If the packet is one that is to be forwarded after IPSec 1131 processing, then the processing is to be done as follows. 1133 The source address in the received packet must belong to 1134 LocalProxiedAddressRange and the destination address in the 1135 received packet must belong to the RemoteProxiedAddressRange. 1137 If the LSB in ProxiedHostScope is set, then source address in 1138 the packet must be negotiated as IDci; otherwise the entire 1139 LocalProxiedAddressRange must be negotiated as IDci. 1141 If the LSB+1 bit in ProxiedHostScope is set, then destination 1142 address in the packet must be negotiated as IDcr; otherwise the 1143 entire RemoteProxiedAddressRange must be negotiated as IDcr. 1145 As an example of a situation where two IPSec hosts must not 1146 negotiate the entire range of addresseses specified in the 1147 LocalProxiedAddressRange and RemoteProxiedAddressRange attributes, 1148 consider the remote access by users from a specific IPv4 subnet 1149 say 39.23.x.x. We might wish to say, for instance, that for any 1150 host attempting to do IPSec Quick Mode negotiation from the subnet 1151 39.23.x.x, we require that the IDci presented comprise of the 1152 address of that host alone. We mandate this by specifying that 1153 the RemoteProxiedAddressRange is 39.23.x.x, but also that the 1154 ProxiedHostScope attribute value is 0x02 or 0x03. The meaning of 1155 these ProxiedHostScope values are described next and it implies that 1156 the source address in the received Quick Mode packet must be used 1157 to derive the IDci presented. This approach avoids having multiple 1158 IPSec actions, each containing single LocalProxiedAddressRange or 1159 RemoteProxiedAddressRange values and provides flexibility in defining 1160 the traffic to be protected by an IPSec security association. 1162 The IPSecProposalRef attribute contains a list of IPSec Proposals for 1163 the flow. Since LDAP does not support ordered lists, a composite 1164 string is required to define ordered IPSec proposals. 1166 NAME IPSecProposalRef 1167 DESC Ordered list of absolute DNs of of IPSecProposal objects 1168 EQUALITY caseIgnoreMatch 1169 SYNTAX IA5String 1170 MULTI-VALUED 1171 FORMAT The format is `pref:IPSecProposalDN' where 1172 - pref is an integer denoting the relative preference of this 1173 proposal 1174 - IPSecProposalDN denotes the distinguishing name of an 1175 IPSecProposal object representing this proposal 1177 Sometimes there can be multiple ISAKMPAction objects for the flow, 1178 e.g. if there are multiple ISAKMP security associations between 1179 the two IPSec hosts protecting this flow. In such scenarios, an 1180 ISAKMPActionRef attribute describes the particular ISAKMP security 1181 association that must carry this traffic. 1183 NAME ISAKMPActionRef 1184 DESC Absolute distinguised name of the ISAKMPAction object that 1185 describes the ISAKMP action used to carry the IPSec traffic 1186 EQUALITY distinguishedNameMatch 1187 SYNTAX DN 1188 SINGLE-VALUED 1190 The rest of the attributes are as defined in Section 6.1 but apply to 1191 ISAKMP Quick Mode traffic. 1193 7. Other classes 1195 7.1. The class ISAKMPProposal 1197 This class describes the attributes of an ISAKMP (phase one) 1198 proposal. 1200 NAME ISAKMPProposal 1201 DESC Describes ISAKMP proposal attributes 1202 DERIVED FROM Top 1203 AUXILIARY CLASSES NONE 1204 MUST 1205 CommonName, 1206 ISAKMPAuthenticationMethod, 1207 ISAKMPHashAlgorithm, 1208 ISAKMPCipherAlgorithm, 1209 MAY 1210 ISAKAMPProposalName, 1211 ISAKMPPrfAlgorithm, 1212 ISAKMPCipherKeyLength, 1213 ISAKMPCipherKeyRounds, 1214 DefaultDiffieHellmanGroupId, 1215 PrivateDiffieHellmanGroupRef, 1216 SecurityAssociationLifetimeSec, 1217 SecurityAssociationLifetimeKBytes 1219 The ISAKMPProposalName defines the user friendly name of this entry. 1221 NAME ISAKMPProposalName 1222 DESC The user friendly name of this entry. The Name related attributes are 1223 only for ease of user administration 1224 EQUALITY caseExactIA5Match 1225 SYNTAX IA5String 1226 SINGLE-VALUED 1228 The ISAKMPAuthenticationMethod attribute defines the ISAKMP/Oakley 1229 authentication method. 1231 NAME ISAKMPAuthenticationMethod 1232 DESC Authentication method for key exchange in ISAKMP 1233 EQUALITY integerMatch 1234 SYNTAX INTEGER 1235 SINGLE-VALUED 1236 FORMAT The acceptable values for are given in [4] 1237 DEFAULT Implementation dependent 1239 NAME ISAKMPHashAlgorithm 1240 DESC Hash Algorithms for use in ISAKMP 1241 EQUALITY integerMatch 1242 SYNTAX INTEGER 1243 SINGLE-VALUED 1244 FORMAT The acceptable values for are given in [4] 1245 DEFAULT Implementation dependent 1247 NAME ISAKMPCipherAlgorithm 1248 DESC Cipher Algorithms for use in ISAKMP 1249 EQUALITY integerMatch 1250 SYNTAX INTEGER 1251 SINGLE-VALUED 1252 FORMAT The acceptable values for are given in [4] 1253 DEFAULT Implementation dependent 1255 NAME ISAKMPPRFAlgorithm 1256 DESC PseudoRandom function algorithm for use in ISAKMP 1257 EQUALITY integerMatch 1258 SYNTAX INTEGER 1259 SINGLE-VALUED 1260 FORMAT The acceptable values for are given in [4] 1261 DEFAULT The value corresponding to HMAC 1263 The following two attributes are related to some special ISAKMP 1264 ciphers. 1266 NAME ISAKMPCipherKeyLength 1267 DESC Keylength for use when ISAKMP Cipher algorithms are CAST, RC5 or 1268 Blowfish 1269 EQUALITY integerMatch 1270 SYNTAX INTEGER 1271 SINGLE-VALUED 1272 DEFAULT Not applicable 1274 NAME ISAKMPCipherKeyRounds 1275 DESC Key rounds for use with some ISAKMP Cipher algorithms 1276 EQUALITY integerMatch 1277 SYNTAX INTEGER 1278 SINGLE-VALUED 1279 DEFAULT Not applicable 1281 ISAKMPCipherKeyRounds is not used at present, but may be needed for 1282 some new cipher algorithm. 1284 DefaultDiffieHellmanGroupId attribute specifies the well known Diffie 1285 Hellman group Ids in case these are to be used. If on the other hand 1286 private groups are to be used, then the PrivateDiffieHellmanGroupRef 1287 provides a reference to the PrivateDiffieHellmanGroup object 1288 describing the group attributes. 1290 NAME DefaultDiffieHellmanGroupId 1291 DESC Default Diffie Hellman group ids: 1,2,3,4 defined in [4] 1292 EQUALITY integerMatch 1293 SYNTAX INTEGER 1294 SINGLE-VALUED 1295 DEFAULT Implementation dependent 1297 NAME PrivateDiffieHellmanGroupRef 1298 DESC Absolute DN of an DiffieHellmanGroup object 1299 EQUALITY distinguishedNameMatch 1300 SYNTAX DN 1301 SINGLE-VALUED 1302 DEFAULT Not applicable 1304 The following two attributes specify security association lifetimes. 1306 NAME SecurityAssociationLifetimeKBytes 1307 DESC Security Association Lifetime time in KBytes 1308 EQUALITY integerMatch 1309 SYNTAX INTEGER 1310 SINGLE-VALUED 1311 DEFAULT Implementation dependent 1313 NAME SecurityAssociationLifetimeSec 1314 DESC Security Association Lifetime time in seconds 1315 EQUALITY integerMatch 1316 SYNTAX INTEGER 1317 SINGLE-VALUED 1318 DEFAULT Implementation dependent 1320 7.2. The class IPSecProposal 1322 This class describes an IPSec proposal for ISAKMP/Oakley Quick Mode 1323 negotiation. A proposal consists of combinations of AH, ESP and 1324 IPCOMP protocols. 1326 The transform attributes of the AH protocol are specified by the 1327 AHProtocolTransformRef attribute that refers to an appropriate 1328 IPSecTransform object (described in section 7.3). 1330 Similarly, the ESPProtocolTransformRef attribute specifies 1331 the transforms associated with the ESP protocol and the 1332 IPCOMPProtocolTransformRef attribute specifies the transforms 1333 associated with the IPCOMP protocol. The ESPProtocolTransformRef 1334 and IPCOMPProtocolTransformRef attribute refers to an appropriate 1335 IPSecTransform objects (described in section 7.3). 1337 The attributes AHProtocolTransformRef, ESPProtocolTransformRef 1338 and IPCOMPProtocolTransformRef are all taken as logical ANDs when 1339 presented together. For example, when both an AHProtocolTransformRef 1340 and an ESPProtocolTransformRef are present, then both AH and ESP must 1341 be negotiated together. 1343 The class definition is 1345 NAME IPSecProposal 1346 DESC Describes an IPSEC Proposal 1347 DERIVED FROM Top 1348 MUST 1349 CommonName, 1350 PerfectForwardSecrecy 1351 MAY 1352 IPSecProposalName, 1353 DefaultDiffieHellmanGroupId, 1354 PrivateDiffieHellmanGroupRef, 1355 AHProtocolTransformRef, 1356 ESPProtocolTransformRef, 1357 IPCOMPProtocolTransformRef 1359 The attribute definitions are given below. 1361 NAME ISAKMPProposalName 1362 DESC The user friendly name of this entry. 1363 EQUALITY caseExactIA5Match 1364 SYNTAX IA5String 1365 SINGLE-VALUED 1367 The PerfectForwardSecrecy attribute denotes whether a fresh Diffie 1368 Hellman Exchange is required in IPSec Quick Mode. If this attribute 1369 value is 1 (i.e. fresh Diffie Hellman exchange is required) then 1370 one of the Diffie Hellman attributes DefaultDiffieHellmanGroupId, 1371 PrivateDiffieHellmanGroupRef must be present in each of the referred 1372 IPSecTransform objects. 1374 NAME PerfectForwardSecrecy 1375 DESC Perfect forward secrecy requirement in IPSec Quick Mode 1376 EQUALITY integerMatch 1377 SYNTAX INTEGER 1378 SINGLE-VALUED 1379 FORMAT The following values are defined 1380 1 (Required) 1381 0 (not required) 1383 NAME DefaultDiffieHellmanGroupId 1384 DESC Default Diffie Hellman group ids: 1,2,3,4 defined in [4] 1385 EQUALITY integerMatch 1386 SYNTAX INTEGER 1387 SINGLE-VALUED 1389 NAME PrivateDiffieHellmanGroupRef 1390 DESC Absolute DN of a private DiffieHellmanGroup object 1391 EQUALITY distinguishedNameMatch 1392 SYNTAX DN 1393 SINGLE-VALUED 1395 Note that the following reference object lists are defined as strings 1396 in order to emulate ordered lists which is currently not supported in 1397 LDAP. 1399 NAME AHProtocolTransformRef 1400 DESC Ordered list of absolute distinguished names of IPSecTransform objects 1401 corresponding to AH protocol 1402 EQUALITY caseIgnoreMatch 1403 SYNTAX IA5 String 1404 MULTI-VALUED 1405 FORMAT The format is `pref:IPSecTransformDN' where 1406 - pref is an integer denoting the relative preference of 1407 the transform. Lower number is higher preference. 1408 - IPSecTransformDN denotes the distinguishing name of an 1409 IPSecTransform object corresponding to the AH protocol 1411 NAME ESPProtocolTransformRef 1412 DESC Ordered list of absolute distinguished names of IPSecTransform objects 1413 corresponding to ESP protocol 1414 EQUALITY caseIgnoreMatch 1415 SYNTAX IA5 String 1416 MULTI-VALUED 1417 FORMAT The format is `pref:IPSecTransformDN' where 1418 - pref is an integer denoting the relative preference of 1419 the transform. Lower number is higher preference. 1420 - IPSecTransformDN denotes the distinguishing name of an 1421 IPSecTransform object corresponding to the ESP protocol 1423 NAME IPCOMPProtocolTransformRef 1424 DESC Ordered list of absolute distinguished names of IPSecTransform objects 1425 corresponding to IPCOMP protocol 1426 EQUALITY distinguishedNameMatch 1427 SYNTAX DN 1428 MULTI-VALUED 1429 FORMAT The format is `pref:IPSecTransformDN' where 1430 - pref is an integer denoting the relative preference of the 1431 transform. Lower number is higher preference. 1432 - IPSecTransformDN denotes the distinguishing name of an 1433 IPSecTransform object corresponding to the IPCOMP protocol 1435 7.3. The class IPSecTransform 1437 This class describes the attributes of an IPSec Quick Mode transform. 1439 NAME IPSecTransform 1440 DESC Describes IPSec transform attributes 1441 DERIVED FROM Top 1442 MUST 1443 CommonName 1444 IPSecProtocolId 1445 MAY 1446 IPSecTransformName, 1447 AHIntegrityAlgorithm, 1448 ESPIntegrityAlgorithm, 1449 ESPCipherAlgorithm, 1450 ESPCipherKeyLength, 1451 ESPCipherKeyRounds, 1452 IPCOMPCompressAlgorithm, 1453 IPCOMPVendorCompressAlgorithm, 1454 EncapsulationMode, 1455 SecurityAssociationLifetimeSec, 1456 SecurityAssociationLifetimeKBytes 1458 NAME ISAKMPTransformName 1459 DESC The user friendly name of this entry.The Name related attributes are 1460 only for ease of user administration. 1461 EQUALITY caseExactIA5Match 1462 SYNTAX IA5String 1463 SINGLE-VALUED 1464 The IPSecProtocolId attribute denotes the IPSec protocol (e.g. 1465 AH, ESP, IPCOMP) corresponding to this transform object. For 1466 example, if the transform object denotes an AH`MD5 transform then the 1467 IPSecProtocolId is IPSEC`AH. 1469 NAME IPSecProtocolId 1470 DESC IPSec protocol corresponding to this transform 1471 EQUALITY integerMatch 1472 SYNTAX INTEGER 1473 SINGLE-VALUED 1474 FORMAT The acceptable values are given in [4]. 1476 The AHIntegrityAlgorithm and ESPIntegrityAlgorithm attributes 1477 denote the integrity transform (e.g. MD5, SHA etc.) in AH and ESP 1478 protocols respectively. 1480 NAME AHIntegrityAlgorithm 1481 DESC Integrity Algorithm for use in AH 1482 EQUALITY integerMatch 1483 SYNTAX INTEGER 1484 SINGLE-VALUED 1485 FORMAT The acceptable values are given in [4]. 1486 DEFAULT Not applicable 1488 NAME ESPIntegrityAlgorithm 1489 DESC Integrity Algorithm for use in ESP 1490 EQUALITY integerMatch 1491 SYNTAX INTEGER 1492 SINGLE-VALUED 1493 FORMAT The acceptable values are given in [4]. 1494 DEFAULT Not applicable 1496 The EncapsulationMode describes the Tunnel or transport encapsulation 1497 mode. 1499 NAME EncapsulationMode 1500 DESC Encapsulation Mode: Tunnel or Transport 1501 EQUALITY integerMatch 1502 SYNTAX INTEGER 1503 SINGLE-VALUED 1504 FORMAT The acceptable values for in [4]. 1505 DEFAULT: the integer value corresponding to the Transport Mode 1507 The ESPCipherAlgorithm attribute denotes the integrity transform 1508 (e.g. 3DES, IDEA etc.) in ESP. 1510 NAME ESPCipherAlgorithm 1511 DESC Cipher Algorithms for use in ESP 1512 EQUALITY integerMatch 1513 SYNTAX INTEGER 1514 SINGLE-VALUED 1515 FORMAT The acceptable values are given in [4] 1516 DEFAULT Not applicable 1518 NAME ESPCipherKeyLength 1519 DESC Keylength for use when ESP Cipher algorithms are CAST, RC5 or 1520 Blowfish 1521 EQUALITY integerMatch 1522 SYNTAX INTEGER 1523 SINGLE-VALUED 1524 DEFAULT Not applicable 1526 NAME ESPCipherKeyRounds 1527 DESC Key rounds for use with some ESP Cipher algorithms 1528 EQUALITY integerMatch 1529 SYNTAX INTEGER 1530 SINGLE-VALUED 1531 DEFAULT Not applicable 1533 ESPCipherKeyRounds is not used at present, but may be needed for some 1534 new cipher algorithm. 1536 NAME IPCOMPCompressAlgorithm 1537 DESC Compression Algorithms for use in IPCOMP 1538 EQUALITY integerMatch 1539 SYNTAX INTEGER 1540 SINGLE-VALUED 1541 FORMAT The acceptable values are given in [4] 1542 DEFAULT Implementation dependent 1544 NAME IPCOMPVendorCompressAlgorithm 1545 DESC Vendor specific Compression Algorithms for use in IPCOMP 1546 EQUALITY integerMatch 1547 SYNTAX INTEGER 1548 SINGLE-VALUED 1549 DEFAULT Not applicable 1551 The VendorCompressAlgorithm attribute must be present when 1552 CompressAlgorithm represents OUI. 1554 The following two attributes specify security association lifetimes. 1555 If a proposal consists of multiple protocols such as AH and ESP, then 1556 the lifetime values applies to each protocol as they are negotiated 1557 together. 1559 NAME SecurityAssociationLifetimeKBytes 1560 DESC Security Association Lifetime in KBytes 1561 EQUALITY integerMatch 1562 SYNTAX INTEGER 1563 SINGLE-VALUED 1564 DEFAULT Implementation dependent 1566 NAME SecurityAssociationLifetimeSec 1567 DESC Security Association Lifetime in seconds 1568 EQUALITY integerMatch 1569 SYNTAX INTEGER 1570 SINGLE-VALUED 1571 DEFAULT Implementation dependent 1573 7.4. The class PrivateDiffieHellmanGroup 1575 This class defines a private Diffie Hellman Group. 1577 NAME PrivateDiffieHellmanGroup 1578 DESC Describes a private Diffie Hellman group attributes 1579 DERIVED FROM Top 1580 MUST 1581 CommonName 1582 DHGroupType 1583 MAY 1584 PrivateDHGroupName, 1585 DHPrime, 1586 DHGenerator, 1587 DHGenerator1, 1588 DHGenerator2, 1589 DHCurveA, 1590 DHCurveB, 1591 DHFieldSize, 1592 DHOrder 1594 The attribute definitions are as follows. 1596 NAME DHGroupType 1597 DESC The diffie Hellman group type for a DHGroup object: 1598 EQUALITY integerMatch 1599 SYNTAX INTEGER 1600 SINGLE-VALUED 1601 SEMANTICS The acceptable values are given in [4] 1603 NAME DHFieldSize 1604 DESC GF size for elliptic curve groups 1605 EQUALITY integerMatch 1606 SYNTAX INTEGER 1607 SINGLE-VALUED 1609 NAME DHGenerator 1610 DESC Group Generator 1611 EQUALITY caseIgnoreMatch 1612 SYNTAX IA5 String 1613 SINGLE-VALUED 1615 NAME DHCurveA 1616 DESC Group Curve A for elliptic curve groups 1617 EQUALITY caseIgnoreMatch 1618 SYNTAX IA5 String 1619 SINGLE-VALUED 1621 NAME DHCurveB 1622 DESC Group Curve B for elliptic curve groups 1623 EQUALITY caseIgnoreMatch 1624 SYNTAX IA5 String 1625 SINGLE-VALUED 1627 NAME DHOrder 1628 DESC Group Order for elliptic curve groups 1629 EQUALITY caseIgnoreMatch 1630 SYNTAX IA5 String 1631 SINGLE-VALUED 1633 8. VPN Schema Usage Examples 1635 In this section we describe some usage scenarios for VPNs. The 1636 intent is not to be very complete in specifying all the attributes, 1637 rather to show how the important attributes are to be defined. The 1638 objects are all written in LDIF notation. 1640 8.1. Scenario I: Intranet communication 1642 - - - - - - - - - - - - - - - - - - - - - - - - - - 1643 | | 1644 | | 1645 S1, TCP, any port ---------------------> S2, TCP, port 8000-8080 1646 | | 1647 | Intranet | 1648 - - - - - - - - - - - - - - - - - - - - - - - - - - 1650 The requirements are: 1652 - All hosts on subnet S1 must use IPSec to communicate to hosts on 1653 subnet S2 and (HTTP) ports 8000-8080 1655 - Only hosts on subnet S1 are allowed to initiate connections 1657 - No intermediate gateways are required 1659 8.1.1. ISAKMP rules for each host in S1 and S2 1661 Each host in S1 and S2 needs to have the following rule. 1663 dn: cn=S1-S2-isakmp-rule, o=XYZ, c=US 1664 Objectclass: Policy 1665 PolicyScope: ISAKMP 1666 PolicyType: ISAKMP 1667 PolicyConditionRef: cn=S1-S2-isakmp-traffic,o=XYZ, c=US, 1668 PolicyActionRef: cn=S1-S2-isakmp-action, o=XYZ, c=US 1670 dn: cn=S1-S2-isakmp-traffic, o=XYZ, c=US 1671 Objectclass: IPPolicyCondition 1672 SourceAddressRange: S1 1673 DestinationAddressRange: S2 1674 IPProtocolRange: 17 (i.e. UDP) 1675 SourcePortRange: 500 (i.e. ISAKMP port) 1676 DestinationPortRange: 500 (i.e. ISAKMP port) 1678 dn: cn=S1-S2-isakmp-action, o=XYZ, c=US 1679 Objectclass: ISAKMPAction 1680 ISAKMPProposalRef: cn=S1-S2-isakmp-proposal,o=XYZ, c=US 1682 dn: cn=S1-S2-isakmp-proposal, o=XYZ, c=US 1683 Objectclass: ISAKAMPProposal 1684 ISAKMPHashAlgorithm: 2(i.e. SHA) 1685 ISAKMPAuthenticationMethod: 4 (i.e. RSA encryption) 1686 ISAKMPCipherAlgorithm: 5(i.e. 3DES) 1687 SecurityAssociationLifetimeSec: 3600 1689 Note that there must be no IPPolicyCondition object with S2 as the 1690 source address range and S1 as the destination address range, since 1691 hosts in S2 are not allowed to initiate ISAKMP negotiations. 1693 8.1.2. IPSec Rules for each host in S1 1695 For the sake of illustration suppose that the following two IPSec 1696 proposals need to be negotiated. 1698 - the first (preferred) proposal consists of only ESP protocol with 1699 3DES as cipher and SHA as the integrity algorithm, 1701 - the second proposal consists of both AH and ESP protocols; SHA is 1702 the integrity algorithm for AH while 3DES is the cipher for ESP. 1703 There is no integrity algorithm for ESP in this proposal. 1705 Three IPSec rules are needed for hosts on subnet S1:: 1707 1. one rule for handling data packets from S2 to S1: this states 1708 that such packets must arrive at S1 within an IPSec security 1709 association. Because of this rule, it would not be possible to 1710 send non-IPSec packets from S2 to S1 on src port 8000-8080. 1712 dn: cn=S2-S1-HTTP-rule, o=XYZ, c=US 1713 Objectclass: Policy 1714 PolicyScope: IPSec 1715 PolicyType: IPSecDataRemote 1716 PolicyConditionRef: cn=S2-S1-HTTP-traffic, o=XYZ, c=US 1717 PolicyActionRef: cn=inboundIPSecAction, o=XYZ,c=US 1719 dn: cn=S2-S1-HTTP-traffic, o=XYZ, c=US 1720 Objectclass: IPPolicyCondition 1721 SourceIPAddressRange: S2 1722 DestinationIPAddressRange: S1 1723 SourcePortRange: 8000:8080 1724 IPProtocolRange: 4 (i.e. TCP) 1726 dn: cn= inboundIPSecIPSecAction, o=XYZ, c=US 1727 Objectclass: IPSecSecurityAction 1728 SecurityAction: PermitIfInboundIPSec 1730 2. one rule for data packets from S1 to S2: this states that such 1731 packets must be secured by IPSec processing. 1733 dn: cn= S1-S2-HTTP-rule, o=XYZ, c=US 1734 Objectclass: Policy 1735 PolicyScope: IPSec 1736 PolicyType: IPSecDataLocal 1737 PolicyConditionRef: cn=S1-S2-HTTP-traffic, o=XYZ, c=US 1738 PolicyActionRef: cn=S1-S2-HTTP-IPSec-action, o=XYZ,c=US 1740 dn: cn=S1-S2-HTTP-traffic, o=XYZ, c=US 1741 Objectclass: IPPolicyCondition 1742 SourceIPAddressRange: S1 1743 DestinationIPAddressRange: S2 1744 DestinationPortRange: 8000:8080 1745 IPProtocolRange: 4 (i.e. TCP) 1747 dn: cn= S1-S2-HTTP-IPSec-action, o=XYZ, c=US, 1748 Objectclass: IPSecSecurityAction 1749 SecurityAction: Permit 1750 LocalProxiedAddressRange: S1 1751 RemoteProxiedAddressRange: S2 1752 LocalProxiedPort: 0 1753 RemoteProxiedPort: 8000 : 8080 1754 ProxiedProtocol: 4 1755 ProxiedHostScope: 0x11 1756 IPSecProposalRef: 1: cn= ESPProposal, o=XYZ, c=US, 1757 IPSecProposalRef: 2: cn= AHESPProposal, o=XYZ, c=US 1759 dn: cn=ESPProposal,o=XYZ, c=US 1760 Objectclass: IPSecProposal 1761 ESPProtocolTransformRef: 1: cn= AuthEncryptTransform,o=XYZ, c=US 1763 dn: cn=AHESPProposal, o=XYZ, c=US 1764 Objectclass: IPSecProposal 1765 AHProtocolTransformRef: 1: cn= AuthTransform, o=XYZ, c=US 1766 ESPProtocolTransformRef: 1: cn= EncryptTransform, o=XYZ, c=US 1768 dn: cn= AuthEncryptTransform,o=XYZ, c=US, 1769 Objectclass: IPSecTransform 1770 IPSecProtocolId: 3 (i.e. IPSEC`PROTO`ESP) 1771 ESPCipherAlgorithm: 3 (i.e. 3DES) 1772 ESPIntegrityAlgorithm: 2 (i.e. HMAC-SHA-1) 1773 EncapsulationMode: 2 (i.e. transport) 1774 SecurityAssociationLifetimeSec: 3600 1776 dn: cn= AuthTransform,o=XYZ, c=US 1777 Objectclass: IPSecTransform 1778 IPSecProtocolId: 2 (i.e. IPSEC`PROTO`AH) 1779 AHIntegrityAlgorithm: 2 (i.e. HMAC-SHA-1) 1780 EncapsulationMode: 1 (i.e. tunnel) 1781 SecurityAssociationLifetimeSec: 3600 1783 dn: cn= EncryptTransform, o=XYZ, c=US 1784 Objectclass: IPSecTransform 1785 IPSecProtocolId: 3 (i.e. IPSEC`PROTO`ESP) 1786 ESPCipherAlgorithm: 3 (i.e. 3DES) 1787 EncapsulationMode: 2 (i.e. transport) 1788 SecurityAssociationLifetimeSec: 3600 1790 3. one for IPSec packets from S1 to S2 (that is, packets with 1791 protocol field AH or ESP). This would state whether S1 and S2 can 1792 communicate directly or a gateway has to be traversed. 1794 dn: cn= S1-S2-AHESP-rule, o=XYZ, c=US 1795 Objectclass: Policy 1796 PolicyType: IPSecDataLocal 1797 PolicyConditionRef: cn=S1-S2-AHESP-traffic, o=XYZ, c=US 1798 PolicyActionRef: cn=clearIPSecSecurityAction, o=XYZ, c=US 1800 dn: cn=S1-S2-AHESP-traffic, o=XYZ, c=US, 1801 Objectclass: IPPolicyCondition 1802 SourceIPAddressRange: S1 1803 DestinationIPAddressRange: S2 1804 IPProtocolRange: 50-51 (i.e. AH and ESP) 1806 dn: cn=clearIPSecSecurityAction, o=XYZ, c=US 1807 Objectclass: IPSecSecurityAction 1808 SecurityAction: Permit 1810 8.1.3. IPSec Rules for each host in S2 1812 The situation for hosts in S2 is symmetric to those for S1, except 1813 that a policy is needed for hosts in S2 to respond to ISAKMP Quick 1814 Mode negotiations. Hosts in S1 do not need such a policy since they 1815 only initiate ISAKMP. 1817 Such a policy is needed since the packet header in ISAKMP Quick 1818 Mode is different than in a data packet and we want to make it 1819 straightforward for hosts to match policies. 1821 Hence for hosts in S2, the following IPSec rules are needed: 1823 - Three rules as described in section 8.1.2 with the difference 1824 that source and destination addresses, port numbers etc. must be 1825 reversed. 1827 - An extra rule that enables hosts on S2 to respond to ISAKMP Phase 1828 2 signalling. 1830 dn: cn=S1-S2-isakmp-QuickMode-rule, o=XYZ, c=US 1831 Objectclass: Policy 1832 PolicyScope: IPSec 1833 PolicyType: IPSecPhase2 1834 PolicyConditionRef: cn=S1-S2-isakmp-traffic,o=XYZ, c=US, 1835 PolicyActionRef: cn=S2-HTTP-S1-ipsec-action, o=XYZ, c=US 1837 dn: cn= S2-HTTP-S1-IPSec-action, o=XYZ, c=US, 1838 Objectclass: IPSecSecurityAction 1839 SecurityAction: Permit 1840 LocalProxiedAddressRange: S2 1841 RemoteProxiedAddressRange: S1 1842 LocalProxiedPort: 8000 : 8080 1843 RemoteProxiedPort: 0 1844 ProxiedProtocol: 4 1845 ProxiedHostScope: 0x11 1846 IPSecProposalRef: 1: cn= ESPProposal, o=XYZ, c=US, 1847 IPSecProposalRef: 2: cn= AHESPProposal, o=XYZ, c=US 1849 The IPSecProposal objects are defined in section 8.1.2. 1851 8.2. Scenario II: Remote access to intranet via an ISP 1853 This case differs from the previous in that subnet S2 is behind a 1854 security gateway GW2. The traffic between subnets S1 and S2 on 1855 destination port range 8000-8080 must be sent within an per host 1856 IPSec tunnel between an host on S1 and GW2. 1858 ---------------------------------- 1859 | | 1860 S1,TCP ---Internet--- GW2---Intranet-------->S2,TCP,HTTP ports 1862 <-----------------end-to-end IPSec------------> 1863 <---outer IPSec --->| | 1864 tunnel ---------------------------------- 1866 8.2.1. Rules for each host in S1 1868 Identical to those in section 8.1 since from S2's point of view, 1869 nothing has changed. 1871 8.2.2. Rules for each host in S2 1873 ISAKMP Rules: 1875 An additional rule is required for communication between hosts 1876 on S1 and GW2. Typically the traffic profile described in the 1877 PolicyCondition object for S1-S2 rule will be broad enough to include 1878 the S1 and GW2. If this is not the case then a new rule has to be 1879 added as in section 8.1.1 by replacing the subnet S2 with the gateway 1880 GW2. 1882 IPSec rules: 1884 The difference between this case and the intranet case in section 1885 8.1.2 is that hosts on S1 now have to send S1-S2 traffic via the 1886 gateway GW2. 1888 To accomplish this, simply replace the rule whose DN equals ``cn= 1889 S1-S2-AHESP-rule, o=XYZ, c=US'' in section 8.1.2 by the following two 1890 rules: (Note that objects not defined here are defined earlier in 1891 this section) 1893 1. One rule which states that IPSec packets between S1 and S2 must 1894 be sent within an IPSec tunnel between S1 and GW2. 1896 dn: cn= S1-S2-AHESP-rule, o=XYZ, c=US 1897 Objectclass: Policy 1898 PolicyScope: IPSec 1899 PolicyType: IPSecDataLocal 1900 PolicyConditionRef: cn=S1-S2-AHESP-traffic, o=XYZ, c=US 1901 PolicyActionRef: cn=AHTunnelSecurityAction, o=XYZ, c=US 1902 dn: cn=AHTunnelSecurityAction, o=XYZ, c=US 1903 Objectclass: IPSecSecurityAction 1904 SecurityAction: Permit 1905 RemoteIPSecTunnelEndPoint: GW2 1906 LocalProxiedAddressRange: S1 1907 RemoteProxiedAddressRange: S2 1908 ProxiedProtocol: 0 1909 LocalProxiedPort:0 1910 RemoteProxiedPort:0 1911 ProxiedHostScope: 0x11 1912 IPSecProposalRef: cn=AuthTunnelProposal, o=XYZ, c=US 1914 dn: cn= AuthTunnelProposal,o=XYZ, c=US 1915 Objectclass: IPSecProposal 1916 IPSecTransformRef: 1: cn= AuthTransform, o=XYZ, c=US 1918 2. one rule that states that hosts on S1 and GW2 need not traverse 1919 any intermediate gateways. 1921 dn: cn=S1-GW2-AHESP-rule, o=XYZ, c=US 1922 Objectclass: Policy 1923 PolicyScope: IPSec 1924 PolicyType: IPSecDataLocal 1925 TrafficProfileRef: cn=S1-GW2-AHESP-traffic, o=XYZ, c=US 1926 PolicyActionRefe: cn=clearIPSecSecurityAction, o=XYZ,c=US 1928 dn: cn=S1-GW2-AHESP-traffic, o=XYZ, c=US 1929 Objectclass: PolicyCondition 1930 SourceAddressRange: S1 1931 DestinationAddressRange: GW2 1932 IPProtocolRange: 50:51 1933 8.2.3. Rules for GW2 1935 Only the IPSec rules are described here. The ISAKMP rule between 1936 GW2 and hosts on S1 can be generated easily. Note that objects not 1937 defined here are defined earlier in this section. 1939 1. A rule that states that packets from S1 to S2 on destination 1940 port 8000-8080 must be received inside of an IPSec security 1941 association, and then must be sent out in the clear. 1943 dn: cn= S1-S2-GatewayRemoteAccessRule, o=XYZ, c=US 1944 Objectclass: Policy 1945 PolicyScope: IPSec 1946 PolicyType: IPSecDataRemote 1947 TrafficProfileRef: cn=S1-S2-HTTP-traffic, o=XYZ, c=US 1948 PolicyActionRef: cn=S1-GW2-inbound-SecurityAction, o=XYZ,c=US 1950 Bhattacharya et. al. Expires April 9 1999 [Page xl] 1951 dn: cn=S1-GW2-inbound-SecurityAction, o=XYZ, c=US 1952 Objectclass: IPSecSecurityAction 1953 SecurityAction: PermitIfInboundIPSec 1955 2. A rule that states that packets from S2 to S1 on source port 8000 1956 to 8080 must be secured by ipsec on the outbound path. 1958 dn: cn= S2-S1-GatewayRemoteAccessRule, o=XYZ, c=US 1959 Objectclass: Policy 1960 PolicyScope: IPSec 1961 PolicyType: IPSecDataLocal 1962 TrafficProfileRef: cn=S2-HTTP-S1-traffic, o=XYZ, c=US 1963 PolicyActionRef: cn=GW2-S1-HTTP-SecurityAction, o=XYZ, c=US 1965 dn: cn=GW2-S1-HTTP-SecurityAction, o=XYZ, c=US 1966 Objectclass: IPSecSecurityAction 1967 SecurityAction: Permit 1968 LocalIPSecTunnelEndpoint: GW2 1969 LocalProxiedAddressRange: S2 1970 RemoteProxiedAddressRange: S1 1971 ProxiedProtocol: 0 1972 LocalProxiedPort:0 1973 RemoteProxiedPort:0 1974 ProxiedHostScope: 0x11 1975 ProxiedProtocol: 4(i.e. TCP) 1976 IPSecProposalRef: cn=AHTunnelProposal, o=XYZ, c=US 1978 3. A rule that states that GW2 and hosts on S1 can communicate 1979 directly. 1981 dn: cn=GW2-S1-AHESP-rule, o=XYZ, c=US 1982 Objectclass: Policy 1983 PolicyScope: IPSec 1984 PolicyType: ISAKMPDataLocal 1985 TrafficProfileRef: cn=GW2-S1-EHESP-traffic, o=XYZ, c=US 1986 PolicyActionRef: cn=clearIPSecSecurityAction, o=XYZ, c=US 1988 dn: cn=GW2-S1-AHESP-traffic, o=XYZ, c=US 1989 Objectclass: PolicyCondition 1990 SourceAddressRange: GW2 1991 DestinationAddressRange: S1 1992 IPProtocolRange: 50-51 (i.e. AH and ESP) 1994 4. A rule for GW2 to respond to ISAKMP Quick Mode packets from hosts 1995 in S1. 1997 dn: cn=S1-GW2-isakmp-QuickMode-rule, o=XYZ, c=US 1998 Objectclass: Policy 1999 PolicyScope: IPSec 2000 PolicyType: ISAKMPPhase2 2001 Bhattacharya et. al. Expires April 9 1999 [Page xli] 2002 PolicyConditionRef: cn=S1-GW2-isakmp-traffic,o=XYZ, c=US, 2003 PolicyActionRef: cn=GW2-S1-HTTP-SecurityAction, o=XYZ, c=US 2005 dn: cn=S1-GW2-isakmp-traffic, o=XYZ, c=US 2006 Objectclass: IPPolicyCondition 2007 SourceAddressRange: S1 2008 DestinationAddressRange: GW2 2009 IPProtocolRange: 17 (i.e. UDP) 2010 SourcePortRange: 500 (i.e. ISAKMP port) 2011 DestinationPortRange: 500 (i.e. ISAKMP port) 2013 8.3. Scenario III: Corporate Branch office to Main office 2015 Suppose that hosts on subnets S1 and S2 are not IPSec enabled. 2016 therefore traffic initiated by any host on subnet S1 and destined 2017 to any host subnet S2 and port 80 is to be carried by the security 2018 gateways GW1 and GW2 within an IPSec security association in tunnel 2019 mode as show below. 2021 ---------------- --------------------- 2022 | | | | 2023 Intranet Intranet 2024 S1,TCP,-----------GW1-----Internet---GW2---------->S2,TCP, 2025 Any port <-----IPSec ------> port 8000-8080 2026 AH tunnel 2027 | | | | 2028 --------------- ------------------- 2030 Rules for GW1 are described here since those for GW2 are completely 2031 symmetric except the ISAKMP Quick Mode responder rule. Also, only 2032 IPSec rules are described since ISAKMP rules are straightforward. 2033 Note that objects not defined here are defined earlier in this 2034 section. 2036 1. The first rule for the gateway GW1 concerns packets received from 2037 hosts on subnet S1 destined to hosts on subnet S2 and on port 2038 8000-8080. These packets must be sent to GW2 within ONE IPSec 2039 tunnel. Note the use of the ProxiedHostScope attribute. 2041 dn: cn= S1-S2-BrOffRule, o=XYZ, c=US 2042 Objectclass: Policy 2043 PolicyScope: IPSec 2044 PolicyType: IPSecDataLocal 2045 TrafficProfileRef: cn=S1-S2-HTTP-traffic, o=XYZ, c=US 2046 PolicyActionRef: cn=S1-S2-BrOffSecAction, o=XYZ,c=US 2048 dn: cn=S1-S2-BrOffSecAction, o=XYZ, c=US 2049 Objectclass: IPSecSecurityAction 2050 SecurityAction: Permit 2051 Bhattacharya et. al. Expires April 9 1999 [Page xlii] 2052 LocalIPSecTunnelEndPoint: GW1 2053 RemoteIPSecTunnelEndPoint: GW2 2054 LocalProxiedAddressRange: S1 2055 RemoteProxiedAddressRange: S2 2056 LocalProxiedPort: 0 2057 RemoteProxiedPort: 8000 : 8080 2058 ProxiedProtocol: 4 2059 ProxiedHostScope: 0x00 2060 IPSecProposalRef: cn=AHTunnelProposal, o=XYZ, c=US 2062 2. The second rule states that GW1 and GW2 can communicate directly 2063 without any intermediate gateways. 2065 dn: cn=GW1-GW2-AHESP-rule, o=XYZ, c=US 2066 Objectclass: Policy 2067 PolicyScope: IPSec 2068 PolicyType: IPSecDataLocal 2069 TrafficProfileRef: cn=GW1-GW2-AHESP-traffic, o=XYZ, c=US 2070 PolicyActionRef: cn=clearIPSecSecurityAction, o=XYZ, c=US 2072 dn: cn=GW1-GW2-AHESP-traffic, o=XYZ, c=US 2073 Objectclass: PolicyCondition 2074 SourceIPAddressRange: GW1 2075 DestinationIPAddressRange: GW2 2076 IPProtocolRange: 50-51 (i.e. AH and ESP) 2078 3. The third rule states that packets from S2 to S1 must receive 2079 inbound IPSec processing and then forwarded in the clear. 2081 dn: cn= S2-S1-BrOffRule, o=XYZ, c=US 2082 Objectclass: Policy 2083 PolicyScope: IPSec 2084 PolicyType: PolicyDataRemote 2085 PolicyConditionRef: cn=S2-S1-HTTP-traffic, o=XYZ, c=US 2086 PolicyActionRef: cn=inboundIPSecAction, o=XYZ,c=US 2087 9. Security Considerations 2089 This draft presents a policy model of the IPSec documents. All 2090 security considerations within those actual specification MUST be 2091 considered prior to implementing a policy architecture. 2092 References 2094 [1] R. Atkinson, ``Security Architecture for the Internet Protocol'', 2095 draft-ietf-ipsec-arch-sec-01 2097 Bhattacharya et. al. Expires April 9 1999 [Page xliii] 2099 [2] D. Maughan, M. Schertler, M. Schneider, J. Turner, `` 2100 Internet Security Association and Key Management'', 2101 draft-ietf-ipsec-isakmp-09 2103 [3] M. Wahl, T. Howes, S. Kille, ``Lightweight Directory Access 2104 Protocol (v3)'', RFC 2251 2106 [4] D. Harkins, ``The Internet Key Exchange'', draft-ietf-ipsec-isakmp-oakl* 2107 *ey-06 2109 [5] D. Piper, ``The Internet IP Security Domain Of Interpretation for 2110 ISAKMP'', draft-ietf-ipsec-doi-07 2112 [6] R. Rajan, J-C. Martin, S. Kamat, M. See and R. Chaudhury, 2113 ``Schema for Differentiated Services and Integrated Services in 2114 Networks'', draft-ietf-policy-qosschema-00.txt 2116 [7] S. Judd and J. Strassner, ``Directory Enabled Networks - 2117 Information Model and Base Schema'' - Draft v3.0r5 DEN 2118 Specifications, September 1998 2120 [8] Common Information Model (CIM) Specification, Desktop Management 2121 Task Force, Version 2.0, Mar. 1998. 2123 [9] R. Pereira and P. Bhattacharya, ``IPSec Policy Data Model'', 2124 draft-ietf-ipsec-policy-model-00.txt 2126 Acknowledgments 2128 The IBM authors would like to thank Pau Cheng, Will Fiveash, 2129 Skip Booth and Charlie Kunzinger for many useful discussions and 2130 suggestions. 2132 Contact Address 2134 Partha P Bhattacharya 2135 Phone: (914) 784-7981 2136 Email: partha@watson.ibm.com 2137 IBM T. J. Watson Research Center 2138 Rob Adams 2139 Phone: (425) 558-2285 2140 Email: radams@cisco.com 2141 Cisco Systems 2142 Roy Pereira 2143 Phone: (613) 599-3610 x 4808 2144 Bhattacharya et. al. Expires April 9 1999 [Page xliv] 2146 Email: rpereira@timestep.com 2147 TimeStep Corporation 2149 William Dixon 2150 Phone: (425) 703-8729 2151 Email: wdixon@microsoft.com 2152 Microsoft Corporation 2154 Raju Rajan 2155 Phone: (914) 784-7260 2156 Email: raju@watson.ibm.com 2157 IBM T. J. Watson Research Center 2159 Bhattacharya et. al. Expires April 9 1999 [Page xlv]