idnits 2.17.1 draft-ietf-ipsec-policy-framework-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard 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. ** There are 17 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 283 has weird spacing: '...trained to th...' == Line 393 has weird spacing: '...ication for s...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 1999) is 9202 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'Ref 1' on line 97 -- Looks like a reference, but probably isn't: 'Ref 8' on line 179 -- Looks like a reference, but probably isn't: 'Ref 11' on line 187 -- Looks like a reference, but probably isn't: 'Ref 12' on line 187 == Unused Reference: '1' is defined on line 410, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 413, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 416, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 419, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 421, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 423, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 426, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 428, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 431, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 433, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 436, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 439, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (ref. '5') (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2401 (ref. '8') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2402 (ref. '9') (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2406 (ref. '10') (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2407 (ref. '11') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2409 (ref. '12') (Obsoleted by RFC 4306) Summary: 14 errors (**), 0 flaws (~~), 15 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPSec Working Group P. Srisuresh 3 INTERNET-DRAFT Lucent Technologies 4 Expire in August, 1999 L.A. Sanchez 5 BBN Technologies 6 February 1999 8 Policy Framework for IP Security 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. Internet-Drafts are 15 working documents of the Internet Engineering Task Force (IETF), 16 its areas, and its working groups. Note that other groups may also 17 distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet- 22 Drafts as reference material or to cite them other than as 23 "work in progress." 25 To view the entire list of current Internet-Drafts, please check 26 the "1id-abstracts.txt" listing contained in the Internet-Drafts 27 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 28 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 29 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 30 (US West Coast). 32 To view the list Internet-Draft Shadow Directories, see 33 http://www.ietf.org/shadow.html. 35 Abstract 37 As policy based networking has become a common place across the 38 Internet with the advent of IPsec, firewalls and other initiatives, 39 it is important for peering end nodes to understand where and why 40 packets enroute are black-holed. End-to-end networking mandates that 41 end nodes be cognizant of the impact policies along various points 42 on the network will have on their packets. The objective of this 43 document is to lay out a framework of policy requirements for end 44 nodes. While the framework is focussed on IPSec based policies, 45 it may be applicable across a wider policy base. 47 1. Introduction and Overview 49 IP packets are subject to a variety of policies enroute by 50 intermediate systems. These systems are in general policy 51 enforcement points. Some of the policies enforced are specific to 52 local administration, and end-nodes do not need to be notified of 53 them. However, there are others that impact packets and traffic 54 flow, which end-nodes need to be aware of. 56 Policy criteria discussed in this document is limited to packet 57 direction and packet contents, including IP and transport headers. 58 Policy actions considered are assumed to be limited to packet 59 transformation and packet flow. In particular, the document does 60 not address application specific policies that are end-to-end 61 transparent. In addition, the document assumes that packets cross 62 administrative boundaries. For a single administrative domain, it 63 may be reasonable to assume a proprietary solution, where a central 64 policy management station could control policies for all the 65 enforcement points within the domain and end-nodes may be able to 66 query such a central management station to find policies enforced 67 within the domain. 69 By default, when no packet based policies are applied, an IP packet 70 is expected to remain unchanged and delivered to the target node, 71 as identified by the destination address in IP header. Typically, 72 end-nodes can identify a possible route taken by packets destined 73 to an address by running "traceroute" for the destination 74 address. Default Packet traversal route is unchanged by the 75 protocol of the packet. Historically, packet traversal has been 76 determined solely by the destination address in the IP 77 header and sometimes by optional extensions (such as source route 78 option) to the header. Packets may be dropped randomly by 79 intermediate nodes due to traffic congestion or other resource 80 constraints, not directly tied to packet specifics. With the advent 81 of packet-filters and security gateways, deviations from this 82 behavior are likely to occur due to the enforcement of specific 83 policies at various nodes during packet traversal. 85 This document will (a) illustrate applications where packet based 86 policies enroute can cause deviations to default traffic processing, 87 and (b) identify requirements for both intermediate and end nodes 88 in understanding policy based routing. The objective of the 89 document is to provide a framework of reference for those 90 contemplating solutions in this area. 92 1.1 Terms and Technical Definitions 94 1.1.1 Requirements Terminology 95 Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" 96 and "MAY" that appear in this document are to be interpreted as 97 described in [Ref 1]. 99 1.1.2 Technical Definitions 101 Security Gateway 103 A security gateway refers to an intermediate system that 104 implements IPSec protocols. For example, a router or a 105 firewall implementing IPSec is a security gateway. 107 Security Domain 109 A set of communicating entities and resources that share a 110 common security policy enforced at one or more enforcement 111 agents or at an individual host. The definition of security 112 domain applies to networks protected by security gateways as 113 well as to single hosts, since a host may be the enforcer of 114 its own policies. Security domains could exist inside other 115 security domains. 117 2. Impact of policies enroute 119 We will consider the following diagram to illustrate some of 120 the undesirable effects of policy enforcement (without knowledge 121 to end-nodes), as packets traverse through such enforcement 122 devices. Specifically we will discuss the impact of firewalls 123 (packet-filters/bastion hosts) and security gateways. In the 124 context of this document a security gateway is an intermidiate 125 system implementing IPSec. 127 An application on Host-A that needed to communicate with Host-B, 128 in a different administrative domain would typically cross a 129 minimum of two policy enforcement devices - one local to the 130 administrative domain and another local to the peer node's 131 administrative domain. The policy enforcement devices enroute could 132 be firewalls, security gateways or a node enforcing some other policy 133 initiative (such as QOS) or a combination of these. Figure 1 below 134 depicts a plausible scenario to illustrate policy enforcement by 135 intermediate systems on end-to-end communications. Figure 1 is meant 136 to be an example and does not cover the various configurations in 137 which administrative domains may be connected to each other. In 138 practice, there may be multiple policy enforcement devices within or 139 outside an administrative domain. However, the diagram does provide 140 the necessary base to address policy specific issues. 142 ________________ 143 ( ) 144 +--+ ( Administrative ) 145 |__|------( Boundary - B ) 146 /____\ ( ) 147 Host-B (________________) 148 | 149 +--------------------+ 150 | Policy-Enforcement | 151 | Device - GW-B | 152 +--------------------+ 153 __________ | 154 ( ) | 155 +-----------------+ ( ) +-----------------+ 156 | Border Router-A |--( Internet )--| Border Router-B | 157 +-----------------+ ( ) +-----------------+ 158 | (__________) 159 | 160 +--------------------+ 161 | Policy-Enforcement | 162 | Device - GW-A | 163 +--------------------+ 164 | 165 ---------------- 166 ( ) 167 +--+ ( Administrative ) 168 |__|------( Boundary - A ) 169 /____\ ( ) 170 Host-A (________________) 172 Figure 1: Policy Enforcement Devices within administrative domains 174 A security gateway operating in tunnel mode may encrypt and/or 175 authenticate a packet and forward it through a tunnel destined to 176 peer security gateway. The peer gateway in turn, de-tunnels the IP 177 packet from the tunnel and reverse-transforms it to extract the 178 original packet. It then forwards it to the destination, as 179 specified in the original packet. [Ref 8] 181 A packet is subject to IPsec tunneling only as it matches the 182 secure packet selection policies for the gateway. The tunnel peers 183 must ensure that only packets that meet the mutually agreed upon 184 policies for the tunnel are transmitted over the tunnel. These 185 packet selection policies may be set manually by the administrators 186 on either end or may be exchanged using Internet key Enchange (IKE) 187 protocol in the ID payload of Quick mode ([Ref 11], [Ref 12]). 189 When a packet is selected for secure tunneling, the routing path of 190 the packet is altered to traverse through the peer gateway node. 191 Note, however, this is not to suggest that IPsec policies alter 192 the routing protocols. 194 Below are some of the pitfalls applications may be subject to as a 195 result of Security Gateway policy enforcement. 197 1. If the peering Security Gateways do not have matching policies, 198 packets could be tunneled by the local Gateway device and 199 yet, dropped by the peering device. 201 The offended Gateway device may optionally issue an ICMP-Reject 202 packet to the packet originator. Typically, if this happens 203 during session establishment period, the end-node may choose not 204 to pursue the application. However, many a times, the gateway 205 nodes do not send a notification, and the applications are left 206 to using timeouts to drop a session. 208 It is important for the end-node to know if a packet is dropped 209 due to enforcement of a policy or due to congestion and random 210 drop. In the former case, it is fruitless to retry. However, if 211 the application were to be aware of the policy that failed the 212 session it could potentially pursue alternate approaches. 214 2. Even as peering gateways have matching policies and the 215 associated SAs, there could be security breaches when the 216 policies have overlap and the order is different on the 217 peering gateways. 219 Ex: In Figure 1, GW-A could have 2 policies, with associated 220 SAs as follows: 221 1. Enforce 3DES for all TCP packets between GW-A and GW-B 222 2. Authenticate HTTP packets between GW-A and GW-B 224 GW-B could have the same policies in reverse, as follows: 225 1. Authenticate HTTP packets between GW-A and GW-B 226 2. Enforce 3DES for all TCP packets between GW-A and GW-B 228 You will notice that GW-A will use 3DES to send HTTP packets, 229 whereas GW-B would simply authenticate the HTTP packets. This 230 could be a potential cause for security breeches. 232 3. Even when the policies on the peering gateway nodes match 233 exactly, there is no guarantee that Packets are secured using 234 the same policy in both directions. Policies at an IPSec Gateway 235 device will determine the route a packet would take on the way 236 out. But, there is no guarantee that the response packet would 237 follow the same route in reverse. In particular, there is no 238 guarantee that the response packet would traverse the same peer 239 gateway device in the return path. This could result in security 240 breaches. e.g., a packet may traverse securely in one direction 241 and the response might come back in the clear in the opposite 242 direction. 244 4. An application comprised of a session bundle may work only 245 partially. For example, A security Gateway cannot create an SA 246 (one or more) to support FTP-only sessions(i.e., FTP control and 247 data sessions), unless your policy is to preserve all of TCP. 248 Here is why. You could have a policy that preserves FTP control 249 session by selecting src or Dest TCP port to be 21. But, the data 250 session parameters set by, say PASV response, will decide the port 251 number used by the ensuing data session. Only the end-nodes know 252 the data session port numbers. Dynamically selected ports in a 253 session cannot not be known to the security gateways, unless they 254 have application specific knowledge to examine the payload, 255 or applications notify them of the sessions specific to 256 themselves. 258 3. Policy requirements 260 In this section, we try to assess the requirements of end nodes 261 with regard to policies that impact the packets originated from or 262 directed to such a node. It is assumed that communication is not 263 limited to a single administrative boundary and could span multiple 264 boundaries. It is hoped that the requirements outlined here will 265 provide a guideline to the various solutions that attempt to address 266 Policy transparency to applications. 268 The solution proposed must not require changes, additions or 269 modifications to the algorithms or the IPsec protocols that use it. 270 The solution may optionally be independent of any particular key 271 management or key exchange protocol. 273 3.1. A flexible, Vendor-independent representation of Policies. 275 As we move to the realm of end-to-end communication, we need to 276 ascertain that end nodes are capable of learning the policies 277 applied to their packets, as they traverse a network, spanning 278 multiple administrative boundaries. Such a policy description must 279 be vendor neutral, so the peering IPsec nodes can understand and 280 enforce the policies on either end (tunnel or transport mode) for 281 a security Association. 283 A Policy must be flexible and should not be constrained to the 284 form of a single rule per SA. A policy should be able to 285 accomodate a variety of rules, allowing for specification of a 286 range of addresses, transport ports, protocols and other 287 paramaters, while also permitting selective exclusion. 289 3.2. Provide a mechanism for policy discovery 291 End nodes must be able to query and find out the policies their 292 packets will be subjected to. A mechanism that can fulfill 293 such a requirement would be beneficial. A protocol may be 294 devised for client nodes to query and discover policies relevant 295 to the application. 297 A traceroute-like facility for identifying the routers enroute 298 and policies applied for secure traversal of a packet would 299 also be useful. The deficiency with the existing traceroute 300 program is that Traceroute is ICMP based and assumes that routing 301 is based purely on the destination IP address. It doesnt take 302 into account policy-based networking. In a policy-based 303 environment, packets could traverse different routes, using 304 different tunnels, based on packet protocol and session 305 characteristics. 307 3.3. Provide a mechanism for Policy Exchange and Query information 309 The principal focus of IKE is to securely exchange session keys 310 dynamically. However, there exists a need for peering security 311 gateway nodes to exchange policies and for end nodes and 312 intermediate nodes alike to make queries of policy specific 313 information. 315 3.4. Provide Policy Negotiation 317 When IPsec peers exchange policy information using IKE. It is 318 mandatory that the peering nodes agree upon the values of a set of 319 selectors for transmitting packets over any security 320 association. Also, there may be several SA proposals within an SA 321 payload allowing hosts to select a mutually agreeable set of 322 parameters to protect the communication. 324 However, it is not reasonable to assume that the peering nodes will 325 have exactly matching policies on either end. Hence, it is a 326 requirement for the peering nodes to carve out intersections of 327 policies exchanged between both parties. Such a methodology would 328 ensure that peering nodes can agree upon a common set of policies, 329 which they could in turn enforce strictly on either end. 331 3.5. Provide Policy resolution 332 In some cases hosts and security gateways may agree upon the set of 333 selectors describing the communication but not on the set of SA 334 parameters required to protect such communication. Consider the case 335 where a host insists on using ESP in transport mode with DES to reach 336 a final destination while its security gateway explicitly prohibits 337 this. 339 The security gateway may have such policy because it does not allow 340 forwarding of encrypted traffic into its domain. In this case it 341 could be possible that the host may want to establish a security 342 association with its gateway and allow its gateway to establish a 343 security association with the intended final destination on behalf 344 of the host. With such policy is available at the security gateway, 345 the host may choose to agree to implement this rather than not 346 communicating at all with the final destination. 348 3.6. Provide Dynamic Policy Updates(Add/Delete) to Enforcement Points. 350 For IPsec, the end nodes should be able to influence policies 351 associated with an IPsec SA dynamically. This is independent of 352 whether the SA was between the peers directly or between 2 gateway 353 nodes in between. An end node should be able to add/delete policies 354 dynamically from an SA. Without this, application specific policies 355 are hard to enforce on an SA. 357 Ex: For an FTP SA, the end nodes ought to be able to (a) add/delete 358 newer policies (describing the parameters of ensuing FTP data 359 sessions) to the existing FTP control session SA, or (b) create 360 newer SAs dynamically confirming to dynamically generated policy 361 parameters. 363 3.7. Provide Policy bundling for SA bundles. 365 A policy bundling mechanism by which a single policy may be 366 associated with multiple SAs is required for SA bundles. 368 Ex: Say, you have 2 policies on GW1: 370 1. Authenticate HTTP packets between GW1 and GW2 371 2. Enforce 3DES for all TCP packets between GW1 and GW3. 373 The above association between policy and security Action may be 374 restated as follows, upon policy Sequencing. The ESP SA may or 375 may not be shared, based on the selector specified in rule 2. 377 1. For HTTP packets - Authenticate between GW1 and GW2 378 - Apply 3DES between GW1 and GW3. 380 2. For non-HTTP, TCP packets 381 - Apply 3DES between GW1 and GW3. 383 So, GW1 is able to apply SA bundles on outgoing HTTP packets. 384 Upon return, the inbound HTTP are subject to detunneling on 385 2 SAs, but a single policy verification. 387 3.8. Provide Error notification to end nodes failing policies. 389 When a packet is dropped at any node across the network due to 390 enforcement of a certain policy, it would be beneficial for the 391 application to know the policy that caused the packets to drop. 393 Standardization of reject notification for such a purpose is 394 desirable. Such a message should not only contain the packet that 395 failed a policy, but also the policy and the ID of the policy 396 enforcement device. 398 4. Security Considerations 400 The document provides a framework for applications to identify the 401 relevant policies in place across the network. Policies must be 402 communicated in a secure way so as not to jeopardize the ability 403 of the application to run. It is also important to ensure that the 404 policies that are communicated statically or dynamically to the 405 Policy Enforcement device are doen so, securely. Not doing so could 406 compromise the security of the entire network. 408 REFERENCES 410 [1] Bradner, S., "Key Words for use in RFCs to indicate 411 Requirement Levels", RFC2119, March 1997. 413 [2] R. Braden, "Requirements for Internet Hosts -- Communication 414 Layers", RFC 1122 416 [3] R. Braden, "Requirements for Internet Hosts -- Application 417 and Support", RFC 1123 419 [4] F. Baker, "Requirements for IP Version 4 Routers", RFC 1812 421 [5] "TRANSMISSION CONTROL PROTOCOL (TCP) SPECIFICATION", RFC 793 423 [6] J. Postel, "INTERNET CONTROL MESSAGE PROTOCOL SPECIFICATION", 424 RFC 792 426 [7] J. Postel, "User Datagram Protocol (UDP)", RFC 768 428 [8] S. Kent, R. Atkinson, "Security Architecture for the Internet 429 Protocol", RFC 2401. 431 [9] S. Kent, R. Atkinson, "IP Authentication Header", RFC 2402 433 [10] S. Kent, R. Atkinson, "IP Encapsulating Security Payload 434 (ESP)", RFC 2406. 436 [11] D. Piper, "The Internet IP Security Domain of Interpretation 437 for ISAKMP", RFC 2407. 439 [12] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", 440 RFC 2409. 442 Authors' Addresses 444 Pyda Srisuresh 445 Lucent technologies 446 4464 Willow Road 447 Pleasanton, CA 94588-8519 448 U.S.A. 450 Voice: (925) 737-2153 451 Fax: (925) 737-2110 452 EMail: suresh@ra.lucent.com 454 Luis A. Sanchez 455 BBN Technologies 456 GTE Internetworking 457 10 Moulton Street 458 Cambridge, MA 02140 460 Voice: (617) 873-3351 461 EMail: lsanchez@bbn.com