idnits 2.17.1 draft-ietf-ipsec-policy-schema-00.txt: -(560): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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. == There are 8 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack 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. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- 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: 'Action' on line 237 == Unused Reference: '1' is defined on line 552, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 556, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 560, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 563, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. '1' == Outdated reference: A later version (-16) exists of draft-ietf-policy-core-schema-02 -- Possible downref: Normative reference to a draft: ref. '3' -- Possible downref: Normative reference to a draft: ref. '4' Summary: 5 errors (**), 0 flaws (~~), 7 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Jamie Jason 2 INTERNET DRAFT Michael Jeronimo 3 24 March 1999 Intel Corporation 5 IPsec Policy Schema 6 draft-ietf-ipsec-policy-schema-00.txt 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet- Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months and may be updated, replaced, or obsoleted by other documents 18 at any time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as "work in progress." 21 The list of current Internet-Drafts can be accessed at 22 http://www.ietf.org/ietf/1id-abstracts.txt 24 The list of Internet-Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html. 27 Abstract 29 This document presents an object-oriented model of IPsec policy in 30 order to facilitate agreement about the content and semantics of 31 IPsec policy and to enable derivations of task-specific 32 representations of IPsec policy such as storage schema, distribution 33 representations, and policy specification languages. 35 Table of Contents 37 Status of this Memo................................................1 38 Abstract...........................................................1 39 Table of Contents..................................................2 40 1. Introduction....................................................3 41 2. Overview of the classes.........................................3 42 2.1 Endpoint.......................................................3 43 2.2 Protocol.......................................................4 44 2.3 Condition......................................................4 45 2.4 Action.........................................................4 46 2.5 Rule...........................................................4 47 2.6 Policy.........................................................4 48 3. Class Hierarchy.................................................5 49 4. Class Diagram...................................................5 50 5. Class Definitions...............................................7 51 5.1 Unique Objects.................................................7 52 5.2 Endpoints......................................................7 53 5.3 Protocols......................................................9 54 5.4 Conditions.....................................................9 55 5.5 IKE Actions...................................................10 56 5.6 IPsec Actions.................................................10 57 5.7 Rules.........................................................11 58 5.8 Policies......................................................11 59 6. Security Considerations........................................12 60 7. Intellectual Property..........................................12 61 8. Acknowledgments................................................12 62 9. References.....................................................12 63 10. Disclaimer....................................................13 64 11. Authors' Address..............................................13 66 1. Introduction 68 IPsec policy may assume a variety of forms as it travels from 69 storage to distribution point to decision point. At each step, it 70 may be represented in a way convenient for the current task. For 71 example, the policy could exist as an LDAP schema in a directory, or 72 as an on-the-wire representation over a transport protocol, or in a 73 text-based policy specification language suitable for editing by an 74 administrator. Each of these task-specific representations should 75 be derived from a canonical representation that exactly specifies 76 the content and semantics of IPsec policy. The purpose of this 77 document is to abstract IPsec policy into a task-independent 78 representation. The document is organized as follows: 80 o Section 2 provides an informal description of the classes defined 81 in the IPsec policy schema to give a framework for understanding 82 subsequent sections. 84 o Section 3 lists the IPsec policy schema class hierarchy, 85 displaying the derived-from relationships contained in the schema. 87 o Section 4 presents a detailed class diagram for the IPsec policy 88 schema. This view shows the static relationship between the 89 various classes in the schema. 91 o Section 5 informally describes the semantics of each of the 92 classes in the policy schema. 94 2. Overview of the classes 96 The IPsec policy schema is a model for IPsec policy that provides 97 the structure to express when IPsec is to be applied and what 98 specific IPsec settings are to be used. This section will give an 99 informal description for each of the classes in the IPsec policy 100 schema and describe their relationships. 102 When modeling IPsec policy, it is appropriate to answer the 103 following questions: 105 o WHO is sending/receiving the traffic? 106 o WHAT are they sending/receiving? 107 o WHEN should traffic be protected? 108 o HOW should the traffic be treated? 110 2.1 Endpoint 112 An Endpoint is meant to model a single communication endpoint - in 113 other words, a sender or receiver of IP traffic. An endpoint should 114 not be confused with a single host - while a single host is a type 115 of endpoint, an endpoint is not necessarily a single host. An 116 endpoint is an abstraction upon which concrete specializations are 117 derived. The endpoint answers the first question above - who is 118 sending/receiving data. 120 2.2 Protocol 122 A Protocol is a specification that characterizes the type of 123 traffic. As with the endpoint, a protocol is an abstraction upon 124 which are derived concrete specializations that specify protocol and 125 possibly ports. The Protocol class is used to separate out the 126 communication protocol that an endpoint is using from the endpoint 127 itself. The protocol answers the second question above - what is 128 being sent/received. 130 2.3 Condition 132 A condition element is a condition type (endpoints and protocols are 133 examples of condition types) along with its associated value. 135 A condition is defined as a predicate that is evaluated against the 136 information provided to determine if there is a match (in other 137 words, a true evaluation). The predicate is a logical expression of 138 one or more condition elements, combined using binary logical 139 operators (AND, OR), and possibly grouped using precedence operators 140 (parentheses). Any part of a condition can be further modified 141 using a unary negation (NOT) operator. The condition answers the 142 third question - when should traffic be protected. 144 2.4 Action 146 An Action is a group of Network Service-specific settings (in our 147 example, IPsec) that are to be enforced when its related Condition 148 evaluates to true. The Action answers the fourth question - how 149 should the traffic be treated. 151 2.5 Rule 153 A Rule is an ordered sequence Conditions, ideally mutually 154 exclusive, paired with a set of Actions. The Conditions are 155 evaluated in order until either the sequence is exhausted or a 156 condition evaluates to TRUE. If a condition evaluates to TRUE, then 157 the corresponding Actions are performed. 159 2.6 Policy 161 A policy is an ordered sequence of rules defined to achieve a 162 specific purpose � for example, one policy might be appropriate for 163 a server while another policy contains rules more appropriate for a 164 client. 166 3. Class Hierarchy 168 The following illustrates the class hierarchy for the IPsec policy 169 classes. 171 Top 172 | 173 +---Policy 174 +---Rule 175 +---Condition 176 +---ConditionElement 177 | | 178 | +---EndPoint 179 | | | 180 | | +---IPv4 181 | | +---IPv4Range 182 | | +---IPv4Subnet 183 | | +---IPv6 184 | | +---IPv6Range 185 | | +---IPv6Subnet 186 | | +---FQDN 187 | | +---EndpointGroup 188 | +---Protocol 189 | | 190 | +---GenericProtocol 191 | +---TCPProtocol 192 | +---UDPProtocol 193 | +---ProtocolGroup 194 +---Action 195 | | 196 | +---IKEAction 197 | +---IPsecAction 198 | | 199 | +---IPsecTransportAction 200 | +---IPsecTunnelAction 201 +---IKEProposal 202 +---IPsecProposal 204 4. Class Diagram 206 The following is a high-level representation of policy. A Unified 207 Modeling Language (UML) class diagram is used to represent the 208 objects. 210 In the following class diagram: 212 o Each box represent class with the class name provided. 213 o Class names in brackets ([]) denotes a virtual class. 214 o A line terminated by a "o" represents aggregation. For example, 215 a Policy contains 1 to n rules and a Rule may be contained in 0 216 to n policies. In aggregation, the class being aggregated has a 217 lifetime that is independent of the class that contains it. 219 o A line terminated by an asterisk (*) represents composition. For 220 example, a Condition contains 1 to n Condition Elements and a 221 Condition Element is contained in one and only one Condition. 222 Composition differs from aggregation in that a contained object 223 only exists as long as the containing object. 224 o A line terminated by a arrow (^, <, or >), denotes inheritance, 225 with the arrow pointing to the parent class. 227 +-----------+ 228 | | 229 | Policy | 230 | | 231 +-----+-----+ 232 o 0..n 233 | 234 | 1..n 235 +-----------+ +-----+-----+ +-----------+ 236 | |1..n | |0..n | | 237 | Condition +----o| Rule |o----| [Action] | 238 | | 1..1| | 1..n| | 239 +-----+-----+ +-----------+ +-----------+ 240 * 1..1 ^ 241 | | 242 | 1..n +-------------+ 243 +-----+-----+ +-----+-----+ +-----+-----+ 244 |[Condition | | | | | 245 | Element] | | IKE | | [IPsec |<--+ 246 +-----------+ | Action | | Action] | | 247 ^ +-----------+ +-----------+ | 248 | * 1..1 * 1..1 | 249 +------+------+ | | | 250 | | | 1..n | 1..n | 251 +-----+-----+ +-----+-----+ +-----+-----+ +-----+-----+ | 252 | | | | | | | | | 253 |[Endpoint] | |[Protocol] | | IPsec | | IPsec | | 254 | | | | | Proposal | | Proposal | | 255 +-----------+ +-----------+ +-----------+ +-----------+ | 256 | 2 | 257 | | 258 | +-------------+ 259 | | | 260 | +-----+-----+ +-----+-----+ 261 | | IPsec | | IPsec | 262 | | Transport | | Tunnel | 263 | | Action | | Action | 264 | +-----------+ +-----+-----+ 265 | | 1..1 266 | | 267 +----------------------------------------------------+ 269 5. Class Definitions 271 5.1 Unique Objects 273 Something that is not conveyed in the preceeding class diagram is 274 the notion of a unique object. A unique object is an object that is 275 used as a building block in the policy system. Unique objects can 276 exist independently of all other objects. Each unique object has 277 associated with it a universally unique identifier (UUID). This 278 UUID lives with the object for the existence of the object. In 279 addition to a UUID, a unique object also has associated with it a 280 more user-friendly display name. The following objects are unique 281 objects in our system: 283 o Policies 284 o Rules 285 o Conditions 286 o Actions (IKE, IPSEC Transport, and IPSEC Tunnel) 287 o Endpoint Groups (described later) 288 o Protocol Groups (described later) 290 5.2 Endpoints 292 An Endpoint identifies a sender or receiver of IP traffic. An 293 endpoint condition element can be specialized to be one of the 294 following types: 296 o IPv4 Address 297 o IPv4 Address Range 298 o IPv4 Subnet/Mask 299 o IPv6 Address 300 o IPv6 Address Range 301 o IPv6 Subnet/Mask 302 o Fully Qualified Domain Name (FQDN) 303 o Endpoint Group 305 The following is the class diagram for an endpoint. 307 +---------------------+ 308 * 1..1 1..n| 309 +-----+-----+ +-----+-----+ +-----------+ 310 | | | | | | 311 | Endpoint +-------->+ [Endpoint]|<--------+ FQDN | 312 | Group | | | | | 313 +-----------+ +-----------+ +-----------+ 314 ^ 315 +-----------+ | +-----------+ 316 | | | | | 317 | IPv4 +---------------+---------------+ IPv6 | 318 | Address | | | Address | 319 +-----------+ | +-----------+ 320 | 321 | 323 +-----------+ | +-----------+ 324 | IPv4 | | | Ipv6 | 325 | Address +---------------+---------------+ Address | 326 | Range | | | Range | 327 +-----------+ | +-----------+ 328 | 329 +-----------+ | +-----------+ 330 | IPv4 | | | Ipv6 | 331 | Subnet/ +---------------+---------------+ Subnet/ | 332 | Mask | | Mask | 333 +-----------+ +-----------+ 335 The only endpoint specialization that may require explanation is the 336 endpoint group. An endpoint group is a named, ordered sequence of 337 (possibly) heterogeneous endpoints. Endpoint groups are used to 338 group together endpoints which are to be treated the same. For 339 example, there may exist an endpoint group named "Marketing" that 340 contains the FQDNs of the systems in the Marketing department. 342 Since an endpoint group is a unique object, a condition only 343 contains a reference to it. This makes it possible to have the same 344 endpoint group appear in multiple conditions without duplication of 345 the entire group. More importantly, changes to an endpoint group 346 are automatically reflected in the condition(s) in which it is 347 referenced. For example, say that a new machine in the Marketing 348 department is added to the network. By adding the system to the 349 "Marketing" endpoint group, the system will be provided the same 350 IPsec services as the other Marketing systems. 352 Note that in the above class diagram an endpoint group not only 353 contains endpoint objects, but also derives from an endpoint (in 354 Design Pattern nomenclature, this is a Composite pattern). The net 355 result is that an endpoint group may contain one or more endpoint 356 groups. The only restriction is that circular references are not 357 allowed - for example, an endpoint group may not contain a reference 358 to itself or by following its endpoint group references recursively 359 may not find a reference to itself. 361 5.3 Protocols 363 A protocol object is used to specify the information about what two 364 communicating host are "saying" to each other. This information 365 includes the IP protocol and in the case of UDP or TCP, the source 366 and destination port ranges. The following is a class diagram for a 367 protocol. 369 +-----------+ 370 1..n| [Protocol]| 371 +---------------+ | 372 | +-----------+ 373 1..1* ^ 374 +-----------+ | +-----------+ 375 | Protocol +---------------+---------------+ UDP | 376 | Group | | | Protocol | 377 +-----------+ | +-----------+ 378 | 379 +-----------+ | +-----------+ 380 | Generic +---------------+---------------+ TCP | 381 | Protocol | | Protocol | 382 +-----------+ +-----------+ 384 It would be simple enough to have only one class that covers all 385 protocols, however a non-UDP/TCP protocol does not need the port 386 fields. As with endpoints, there is a named, ordered sequence of 387 protocols - protocol groups. 389 Since a protocol group is a unique object, it exhibits the same 390 properties as an endpoint group. For example, assume there is a 391 protocol group named "Essential Services". If it is later 392 determined that another protocol needs to be added to "Essential 393 Services", this can be done by modifying the "Essential Services" 394 protocol group instead of modifying all conditions which reference 395 the protocol group. 397 A protocol group, like an endpoint group, is restricted by the 398 "circular reference" limitation. 400 5.4 Conditions 402 In the case of IPSEC, we chose to simplify the condition to contain 403 the following three components: 405 o a source endpoint group, SourceGroup 406 o a destination endpoint group, DestinationGroup 407 o a protocol group, ProtocolGroup 409 The condition would be specified as: 411 IF (SourceGroup AND DestinationGroup AND ProtocolGroup) 413 In English, the condition could be phrased as: 415 "When communicating from SourceGroup to DestinationGroup using 416 ProtocolGroup" 418 It is also important to note that even though this was designed in 419 the context of IPsec, the Condition is actually domain-independent. 420 That is, the same Condition used to specify an IPsec Action could 421 also be used for other domains such as Bandwidth and Access. 422 However, this should not be taken to mean that Conditions may only 423 contain domain-independent Condition Elements. If appropriate, a 424 Condition may contain domain-dependent Condition Elements. For 425 example, if we cared about CPU utilization and wanted to restrict a 426 host to using 3-DES for only 5 active streams, a Condition Element 427 that states this could be used. 428 While we restricted ourselves to the traditional 5-tuple, there is 429 nothing that restricts the use of other condition elements (for 430 example, time-of-day). 432 5.5 IKE Actions 434 An IKE Action contains the information necessary to perform the IKE 435 Phase 1 negotiation: 437 o the IKE mode (main or aggressive) 438 o the SA kilobyte lifetime 439 o the SA seconds lifetime 440 o the credential type expected/provided (for example, preshared 441 key) 442 o if the credential type is preshared key, the preshared key 443 o an ordered sequence of IKE proposals 445 Each IKE proposal contains the following information: 447 o an ordered sequence of authentication methods 448 o an ordered sequence of encryption algorithms 449 o an ordered sequence of hash algorithms 450 o a Diffie-Hellman group 452 5.6 IPsec Actions 454 An IPsecAction is an abstract class that contains settings that are 455 common to both transport and tunnel actions: 457 o whether or not to employ IPsec replay detection 458 o the SA kilobyte lifetime 459 o the SA seconds lifetime 460 o the Diffie-Hellman group 461 o an ordered list of IPsec proposals 462 An IPsecTransportAction does not further specialize the IPsecAction. 463 The IPsecTunnelAction adds the following: 465 o the local gateway - an IPv4/6 or FQDN endpoint 466 o the remote gateway - an IPv4/6 or FQDN endpoint 468 Each IPsec proposal contains the following information: 470 o an ordered sequence of AH authentication algorithms 471 o an ordered sequence of ESP encryption algorithms 472 o an ordered sequence of ESP authentication algorithms 474 Although not in the policy class diagram, there are also two more 475 IPsec transport actions: 477 o IPsecPermitAction - allows traffic to be sent/received in the 478 clear 479 o IPsecDenyAction - causes traffic that matches the parameters to 480 be dropped 482 5.7 Rules 484 As stated earlier, a rule is an ordered sequence of Conditions 485 paired with a set of Actions: 487 IF (Condition OR Condition ...) THEN (Action AND Action ...) 489 For simplification, our system restricts a rule to being a 490 condition/action pair. This unfortunately does sometimes require 491 duplication (of which we tried to avoid at all cost). For example, 492 assume host S is talking to host D and it is desirable to not only 493 have end-to-end security, but also to use an encrypted tunnel 494 between the two sites. In our model, two rules will need to be 495 specified - one for transport mode and one for tunnel mode (we will 496 discuss later the evaluation process to make sure that tunnel mode 497 rules are acted upon first). 499 A rule is a unique object in the system and as such, may appear in 500 more than one policy. Updates to a rule are automatically reflected 501 in the affected policies. 503 5.8 Policies 504 In our system, a policy is a named, ordered sequence of rules. The 505 ordering of the rules within a policy is beyond the scope of this 506 draft. The rules in the policy are evaluated sequentially until 507 either one of the rules evaluates to true or the sequence is 508 exhausted. On a host, there may be several policies, however, at 509 any given time only one policy may be tagged as the active policy 510 (in other words, the one that is consulted when a decision is to be 511 made). 513 6. Security Considerations 515 This document describes a schema for IPsec policy. It does not 516 detail security requirements for storage or delivery of this schema. 517 Storage and delivery security requirements should be detailed in a 518 comprehensive policy architecture. 520 7. Intellectual Property 522 The IETF takes no position regarding the validity or scope of any 523 intellectual property or other rights that might be claimed to 524 pertain to the implementation or use of the technology described in 525 this document or the extent to which any license under such rights 526 might or might not be available; neither does it represent that it 527 has made any effort to identify any such rights. Information on the 528 IETF's procedures with respect to rights in standards-track and 529 standards-related documentation can be found in BCP-11. 531 Copies of claims of rights made available for publication and any 532 assurances of licenses to be made available, or the result of an 533 attempt made to obtain a general license or permission for the use 534 of such proprietary rights by implementers or users of this 535 specification can be obtained from the IETF Secretariat. 537 The IETF invites any interested party to bring to its attention any 538 copyrights, patents or patent applications, or other proprietary 539 rights which may cover technology that may be required to practice 540 this standard. Please address the information to the IETF Executive 541 Director. 543 8. Acknowledgments 545 The authors would like to thank Baiju Patel, Ganesh Krishnan, and 546 Ylian Saint-Hilaire for their discussions and contributions to this 547 policy model. We would also like to thank Allison Angus for her 548 efforts in user-interface design and usability feedback. 550 9. References 552 [1] J. Strassner and E. Ellesson, �Terminology for describing 553 network policy and services�, draft-strassner-policy-terms-01.txt, 554 February 1999. 556 [2] J. Strassner, E. Ellesson, B. Moore, �Policy Framework Core 557 Information Model�, draft-ietf-policy-core-schema-02.txt, February 558 1999. 560 [3] R. Pereira, P. Bhattacharya, �IPsec Policy Data Model�, draft- 561 ietf-ipsec-policy-model-00.txt, February 1998. 563 [4] P. Bhattacharya, R. Adams, W. Dixon, R. Pereira, R. Rajan, �An 564 LDAP Schema for Configuration and Administration of IPsec based 565 Virtual Private Networks (VPNs)�, draft-ietf-ipsec-vpn-policy- 566 schema-00.txt, October 1998. 568 10. Disclaimer 570 The views and specification herein are those of the authors and are 571 not necessarily those of their employer. The authors and their 572 employer specifically disclaim responsibility for any problems 573 arising from correct or incorrect implementation or use of this 574 specification. 576 11. Authors' Address 578 Jamie Jason 579 Intel Corporation 580 MS JF3-206 581 2111 NE 25th Ave. 582 Hillsboro, OR 97124 583 Phone: +1-503-264-9531 584 Fax: +1-503-264-9428 585 E-Mail: Jamie.Jason@intel.com 587 Michael Jeronimo 588 Intel Corporation 589 MS JF3-206 590 2111 NE 25th Ave. 591 Hillsboro, OR 97124 592 Phone: +1-503-264-5970 593 Fax: +1-503-264-9428 594 E-Mail: Michael.Jeronimo@intel.com