INTERNET-DRAFT Fernando Cuervo Expires : April 2001 Abdallah Rayhan Category : Informational Nortel Networks November 2000 Architecture for IPSec Policy Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This document proposes an architecture for IPSec policy. The proposed architecture extends the one described in the policy framework draft [PFRFC]. The architecture addresses the mechanisms required to facilitate the dynamic exchange of policy between end administrative domains and across a number of intermediate domains imposing restrictive policies. The proposed architecture does not assume a Cuervo & Rayhan [Page 1] Internet Draft Architecture for IPSEC Policy November 2000 pre-established policy relationship among the administrative domains. This exchange requires the introduction of a policy signaling protocol and a gateway discovery protocol. The issues discussed here cover the mechanisms for discovering gateways, resolving policy conflicts among policy servers and the confidentiality requirements of policy signaling. Table of Contents 1. Introduction...............................................2 2. Requirement Terminology....................................3 3. Definitions................................................3 4. Motivation.................................................4 5. Security Policy Requirements...............................4 6. Architecture. .........................................5 6.1 Protocols Architecture....................................6 6.1.1 Policy Signaling: Basic Model ..........................6 6.1.2 Policy Signaling: Chain Model..........................10 6.1.3 Gateway Discovery Protocol.............................12 7 References.................................................15 8.Authors' Addresses.........................................16 1 Introduction IPSec provides authentication and encryption to make IP communications secure. End-to-end IP flows must pass through several networks (e.g., access providers, enterprise networks, carrier networks, telephone network, etc.). A major problem towards such operation is the policy relationship (including but not limited to security) among administrative domains. A pre- established policy relationship may not always exist across the internet, service provider networks or even intranet domains due to corporate policy, or the dynamic nature of the enforced policies, or the complexity of creating it a priori. Assuming that the proper policies are installed in all security gateways in the communications path, the end result will be a set of properly nested IPSec tunnels around the end-to-end communication with proper selectors and attributes. These policies specify how to manage nesting and conflicting tunnels (e.g., ESP or AH) across multiple domains and nodes, access policies (e.g., filters and IPSec selectors), and security association (SA) attributes (e.g., proposals and transforms). It is important to note that the scope of these policies is to facilitate wider deployment of policy based networking in IP networks. IKE functionality is not duplicated; the policy based infrastructure facilitates interoperability between network domains by setting Cuervo & Rayhan [Page 2] Internet Draft Architecture for IPSEC Policy November 2000 the proper conditions to create security associations using IKE. This document describes an architecture for IPSec policy. The proposed architecture extends the one described in the policy framework draft [PFRFC]. The IPSec policy architecture presents the mechanisms required to facilitate the dynamic exchange of policies between end administrative domains and across a number of intermediate domains that impose restrictive policies. The proposed architecture does not assume a pre-established policy relationship between administrative domains. The architecture proposes protocols and processes for discovering gateways, exchanging policy, resolving policy conflicts among policy servers, and the confidentiality requirements of the policy exchanged between servers and gateways. The motivation of the proposed architecture is presented in Section 4. The types of policy to be addressed by the proposed protocols are described in Section 5. The overall architecture and requirements are described in Section 6. 2 Requirement Terminology The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC 2119 [KEYW]. 3 Definitions - Security Gateway: is the entity that enforces policy. It is referred to as policy gateway as well. - Policy Server: is the entity used to carry out policy decisions for the security gateways. - Gateway Discovery: is a mechanism to identify the gateways that participate in the enforcement of end-to-end set of policies (e.g., IPSec) on a particular set of flows. - Policy Signaling: is a mechanism which servers use to exchange policy with other servers. - Policy Resolution: is a process that determines the policy to be enforced. The resolution process occurs in policy server. The resolution process uses path information acquired during the Cuervo & Rayhan [Page 3] Internet Draft Architecture for IPSEC Policy November 2000 discovery phase and policies obtained through the policy signaling mechanism. 4 Motivation IPSec provides data and source authentication and confidentiality using AH and/or ESP protocols. The set up of a SA between two end- points is accomplished using IKE. However, IKE does not address management of tunneling policies, nested tunnels or configuration of security and SA attributes across multiple administrative domains. This situation arises when intermediate domains impose policy constraints on the traffic passing through their security gateways. A pre-established policy relationship may not always exist. In practice, it will become increasingly difficult to install policies for all users and communication services in all potential gateways because of the dynamics of, just to name a few, user mobility, personalization of communications, churn in the policies that define user treatments or administrative arrangements between network administrations. When the security requirements of a flow are changed dynamically, the mechanisms that determine the proper set up of nested AH and ESP tunnels are required to avoid conflicts across multiple domains and nodes. This draft proposes two mechanisms -- gateway discovery protocol and policy signaling protocol. Gateway discovery is a mechanism to identify gateways that participate in policy enforcement and tunneling policies. Policy signaling is a mechanism in which the policy servers exchange policy information (i.e., access and SA policies) amongst themselves to achieve a consistent set of policies to enforce on the policy gateways. A key attribute of the proposed architecture is the separation of gateway discovery from policy exchange. This enables servers to maintain confidentiality of the exchanged policies when required. Additionally, this approach also provides the flexibility and extensibility since the discovery and signaling protocols can evolve independently of each other to facilitate the creation and support of new network services. 5 Security Policy Requirements In this section, we categorize the types of security policies to be supported. Security policy can be described as follows: Cuervo & Rayhan [Page 4] Internet Draft Architecture for IPSEC Policy November 2000 1- Access Policies: Traffic traveling through gateways can be identified by examining the headers of their IP packets and inspecting the payloads for a particular application patterns such as TCP connections. The rules governing such policies are usually referred to as filtering rules and IPSec selectors when IPSec is considered. 2- SA Policies: We will use the term SA policies to describe security attributes of IPSec security associations [DOIRFC] 3- Tunneling Policies: Tunneling policies describe the possible applications of IPSec tunnels between the end-points of an IP flow and the gateways along the communications path. Tunneling Policies identify tunneling endpoints, based on authentication, privacy and network services requirements along the communications path. This includes the IPSec modes (transport and tunnel) as well as IPSec protocols (ESP [ESPRFC] and AH [AHRFC]). 6 Architecture The functional decomposition of the IPSP architecture extends the one depicted in the policy framework [PFRFC], see Figure 1. The main components of this architecture are policy repository, policy server and security gateway. The policy repository should store persistent information, which the server could use to make policy- related decisions. The organization and requirements of policy repository and data models are outside the scope of this draft. While these issues are important for the wide deployment of policy based networks, it should be addressed by other working groups. +------+ +------+ / Policy \ / Policy \ /Repository\ /Repository\ +------------+ +------------+ ^ ^ | LDAP LDAP | | | v v +--------+ +--------+ | Policy | Policy | Policy | | Server | <---------------> | Server | +--------+ Signaling +--------+ ^ ^ | COPS-Pr COPS-PR | | | v v +---------+ +---------+ | Security| Gateway | Security| | Gateway | <---------------> | Gateway | +---------+ Discovery +---------+ Figure 1: IPSP Architecture The policy server (extended policy decision point) is responsible for making policy decisions using the policy resolution process. The policy server supports the following interfaces: a gateway interface to distribute policies, a server interface to signal policies and an LDAP interface to a policy repository. We propose the COPS-PR for security policy distribution between the gateways and servers. The security gateway (extended policy enforcement point) enforces the policy decisions made by the Cuervo & Rayhan [Page 5] Internet Draft Architecture for IPSEC Policy November 2000 policy server. The security policies supported are described in Section 5. It must also support three interfaces to enable communications between servers and gateways. The gateway-server interface (the COPS-PR interface) should support provisioning of policies as well as requesting policy decisions between the gateway and the server. The gateway-gateway interface implements the gateway discovery mechanism. The third interface is IKE/IPSec [IKERFC, DOIRFC] to realize the security associations between gateways. 6.1 Protocols Architecture The exchange of policy occurs at two levels. The first one is in the discovery protocol. The second one is in the signaling protocol. The resolution process is triggered at both levels to validate the consistency of the exchanged policies with the administrative requirements such as tunneling and access policies. The discovery protocol may perform three functions: identification of the gateways along the path of communication between two end users, transport of tunneling policies across administrative domains and establishment of confidentiality requirements and mechanisms for the signaling protocol. The policy signaling protocol carries out the policy exchange among the two end domains as well as any intermediate domains with policy constraints to enforce. The policies exchanged are the access policies, SA policies as well as tunneling policies. The resolution process is used to resolve conflicts in those policies as well. The policy signaling may require secure exchange of policy. The security requirement of exchanged policies can be accomplished by either an end-to-end ESP tunnel and/or partial encryption of exchanged policies. 6.1.1 Policy Signaling: Basic Model Using the signaling protocol, it should be possible to resolve the policies discussed in Section 5. This includes tunnel management, access policies and SA policies. The signaling protocol can be carried out in two modes, direct mode or proxy mode -- see Figures 2.a and 2.b. The proxy mode does not assume a pre-established relationship between the servers. The same goes for gateways. However, the discovery protocol is used to discover the gateway interface and, in this case, it is used instead of the server's. This is useful for the Internet case. In the direct mode, the interface of the server could be known in advance and servers can talk to each Cuervo & Rayhan [Page 6] Internet Draft Architecture for IPSEC Policy November 2000 other directly. This is useful for the intranet case. Either way, other than the interface no assumptions are made about a pre- established relationship between the respective domains. The proxy mode should help when the identity of the server is to be concealed for security considerations or when a pre-established relationship is not available a priori. During this process, the initiator server exchanges its policy with a peer server administrating the policies of the destination domain. +---------------+ +---------------+ | Policy Server | | Policy Server | +---------------+ +---------------+ ^ ^ | TCP TCP | | | v v +------------+------+ +------+-------------+ | Security |Server| Policy |Server| Security | | Gateway |Proxy | <--------------> |Proxy | Gateway | | +------+ Signaling +------+ | +-------------------+ +--------------------+ Figure 2.a: Functional decomposition of IPSP architecture: proxy mode +---------------+ Policy Signaling +---------------+ | Policy Server | <------------------> | Policy Server | +---------------+ +---------------+ Figure 2.b: Functional decomposition of IPSP architecture: direct mode In this model, the initiator domain (server or gateway) is the one that drives the signaling. It starts by the initiator domain sending a signaling request destined towards the destination domain (server or gateway). The request is based on the information gathered during the discovery protocol and carries proposals of the policy to be exchanged. Similarly, the reply carries the response of the destination server or gateway. There are several issues in this model that needs to be addressed such as request and reply mechanisms, policy contents, values and conditions, processing of exchanged policy, message format, and enforced actions. These details are left to the specification draft of the signaling protocol. Confidentiality of exchanged messages can be provided using two means. The first one is provides total privacy in which ESP tunnels are utilized between the two ends of communication (Figure Cuervo & Rayhan [Page 7] Internet Draft Architecture for IPSEC Policy November 2000 3(a)). This should ensure the authenticity and privacy of the exchanged policies in the policy signaling protocol between the two servers. When it is not required, this step can be skipped. However, when it is required this step occurs before the signaling protocol being initiated. Hence, it is a must to support and optional to use depending on the policies provisioned on the involved administrative domains. The second one is achieved through encrypting only parts of the message (Figure 3(b)). The former provides the confidentiality for the communication link between the two domains, while the latter ensures the confidentiality of the exchanged policy among multiple domains. This is useful for the chain model of signaling where designated segments are encrypted using for example the private key of the initiator and the public key of the receiver or shared secret if possible. This should allow the receiver to decrypt the part it is supposed to read while keeping the rest of the segments encrypted. The two mechanisms are independent and can be used simultaneously or separately. The discovery protocol should realization of both mechanisms. The protocol stack of the signaling protocol is depicted in Figure 4. +----------+ +----------+ | | -.-.-.-.-.-.-.-.-.-.-.-.- | | | Server-A | <-----------------------> | Server-B | | | -.-.-.-.-.-.-.-.-.-.-.-.- | | +----------+ +----------+ <-----> : policy signaling protocol -.-.-.- : ESP tunnel (a) Link Confidentiality Signaling Header, Segment-A-Header (Segment-Encrypted), Segment-C-Header (Segment-Encrypted), Segment-C-Header (Segment-Encrypted) ... (b) Segment encryption Figure 3: Confidentiality options for the policy signaling protocol +------------+ | Policy | | Signaling | +------------| | TCP | Cuervo & Rayhan [Page 8] Internet Draft Architecture for IPSEC Policy November 2000 | UDP +------+ | |IPSEC | +-----+------+ | IP | +------------+ Server Figure 4: Policy signaling protocol stack It is assumed that this model, for example, occurs between two border gateways and does not address the issue when one or more intermediate content inspection, or otherwise, gateways fall in the path between the two ends of communication with the following exception. A gateway can delegate another one to initiate signaling when there is a trust relationship between the two. For example, a border gateway, having one or more nested domains each of which having its own gateway, can initiate the signaling protocol on behave of the nested gateways. This scenario occurs possibly when the outer and inner domains are administrated by the same corporation. Otherwise, the chain model should be used. +--------------------------+ | | | +-------------+ | +-------------+ | | +----+ +----+ Policy +----+ | | | Domain-B |GW-B| |GW-A| <----------> |GW-C| Domain-C | | | +----+ +----+ Signaling +----+ | | +-------------+ | +-------------+ | | +--------------------------+ Figure 5: Nested domains and the policy signaling protocol When policies are exchanged among the servers, the resolution process takes place. The process occurs at each server participating in the signaling protocol. Each server should be able to resolve the conflicts between the acquired policies and its own. The output would be either accepting the proposed policies, modifying them to accommodate administrative requirements or rejecting them due to compliance failure. Such conflicts could occur, for example, in endpoints of ESP tunnels as depicted in Figure6. The detail of this mechanism will be described in the specification draft of this resolution process. SG1 SG2 SG3 SG4 ESP tunnel Cuervo & Rayhan [Page 9] Internet Draft Architecture for IPSEC Policy November 2000 <===============================> ESP tunnel <===============================> Figure 6: Conflicts of ESP tunnels 6.1.2 Policy Signaling: Chain Model In this model, policy signaling is performed in a distributed manner. The concepts of direct and proxy modes apply here as well. The processing in this model is based on policies obtained from the discovery protocol for all the gateways that have policies to enforce on the traffic. Hence, the discovery protocol should precede the chain model. The discovery protocol will be discussed in Section 6.1.3. However, it is suffice to say that the data collected includes the following: tunneling policies, certificates and public keys, confidentiality profiles and the interfaces of the gateways. The tunneling policies will address the conflicts in ESP and AH tunnels among the gateways participating in the signaling protocol. The confidentiality profiles will address the tunneling profiles as well as the segment encryption concepts shown in Figure 3(b). Certificates and public keys are used for the authentication of gateways and towards encryption of exchanged messages. The interfaces are used to identify entities involved in the signaling protocol. Once this information is sorted out by a gateway in the path of traffic, the chain model is carried out. The mechanisms of this model are as follows. The initiator domain (server or gateway) issues a signaling request message towards the destination. The message consists of several requests with each one designated to one of the gateways discovered in the discovery protocol. The contents of each request can be encrypted ensure privacy of exchanged policies between the initiator and each receiver. Once a message processed by a particular domain, new request(s) can be piggybacked to the next domains in line towards the destination domain. Once the message reaches the destination domain, the requests designated to it are processed and reply(s) are formed for each one of those requests. The reply message is sent towards the initiator of the original message. Similar to the original message, when the reply message is received by an intermediate gateway, it gets processed accordingly and the reply(s) are piggybacked when necessary. Replies are piggybacked in accordance with the original requests. Following this mechanism, each gateway will be able to express its signaling request to other gateways in the path and receive replies accordingly while maintaining the confidentiality of requests and replies. Cuervo & Rayhan [Page 10] Internet Draft Architecture for IPSEC Policy November 2000 For example, the discovery protocol shows four gateways in the path of communication as depicted in Figure 7. Assuming that every security gateway is issuing a request to every other one, we will have the following scenario. SG1 issues requests to SG2, SG3 and SG4. SG2 issues requests to SG3 and SG4. SG3 issues a request to SG4. The content of each request -- (Segment)* --is encrypted giving that the necessary keys and encryption details are available through the discovery protocol. When the request message reaches SG2, SG2 processes the request and piggybacks its requests to the gateways ahead accordingly; this information is available from the discovery protocol. Next, SG3 process the requests designated to it from SG1 and SG2 and piggybacks its own to SG4. Finally, SG4 gets to process all the requests made from SG1, SG2, and SG3. In the reply message, SG4 generates replies to every request it received. Next, SG3 processes the reply it received from SG4 and generates replies to the requests it received from SG2 and SG1. Finally, SG1 will receive replies to all the requests it generated. Using this approach, it is possible for each gateway to exchange policy with peer gateways in a secure and scalable fashion. In the case where SG2 is a border gateway and authoritative over SG1, SG2 would process SG1 requests and communicate with peer gateways in SG1's behalf resulting in reduced number of segments. SG1 SG2 SG3 SG4 ---------------> Request MSG Req SG1->SG2:(Segment)* Req SG1->SG3:(Segment)* Req SG1->SG4:(Segment)* ---------------> Request MSG Req SG1->SG3:(Segment)* Req SG1->SG4:(Segment)* Req SG2->SG3:(Segment)* Req SG2->SG4:(Segment)* ---------------> Request MSG Req SG1->SG4:(Segment)* Req SG2->SG4:(Segment)* Req SG3->SG4:(Segment)* <--------------- Reply MSG Rep SG4-SG3:(Segment)* Rep SG4-SG2:(Segment)* Cuervo & Rayhan [Page 11] Internet Draft Architecture for IPSEC Policy November 2000 Rep SG4-SG1:(Segment)* <--------------- Reply MSG Rep SG4-SG2:(Segment)* Rep SG4-SG1:(Segment)* Rep SG3-SG2:(Segment)* Rep SG3-SG1:(Segment)* <--------------- Reply MSG Rep SG4-SG1:(Segment)* Rep SG3-SG1:(Segment)* Rep SG2-SG1:(Segment)* Figure 7: Chain model of the policy signaling protocol This model has a number of unresolved issues such as maintaining the integrity of modified messages. For example, when SG2 consumes the request from SG1 then adds its own requests to SG3 and SG4, how can SG3 and SG4 verify the integrity of the received request message. Another issue of concern is the fail over mechanism. When SG2 does not satisfy the request made by SG1, how does the fail over mechanism proceeds. Similarly, issues arise when there is a conflict of policies between SG3 and SG4. For example, SG3 restricts SG4 from terminating ESP tunnels. In this case, based on the requests SG3 receives from SG1 and SG2 it can make a request to SG4 stating its own policy. In the reply from SG4 to SG3, SG3 would get know if SG4 makes concessions or not. The end result would to satisfy or deny the request. It is expected that these issues would be resolved in the final specifications of the signaling protocol. The concepts of the resolution process discussed in the basic model of the signaling protocol apply here as well. Details are to be given in the draft discussing the resolution process Note that the dynamics of this approach are still under development. 6.1.3 Gateway Discovery Protocol The discovery protocol provides a mechanism to identify tunneling endpoints of IPSec in addition to managing tunneling policies across multiple domains. Furthermore, it provides a mechanism to establish the confidentiality requirements of the resolution protocol. This information is passed then to the servers initiating the policy signaling protocol. The identities exchanged can be of the gateways if the proxy mode is assumed, or of the servers if possible. The discovery protocol shall serve the two Cuervo & Rayhan [Page 12] Internet Draft Architecture for IPSEC Policy November 2000 models of resolution -- basic and chain. +-------------------+ +--------------------+ | Security | Discovery | Security | | Gateway | <--------------> | Gateway | +-------------------+ Protocol +--------------------+ Figure 8: Discovery protocol +-----------+ | Discovery | +-----------+ | UDP | +-----------+ | IP | +-----------+ Gateway Figure 9: Discovery Protocols Stack It is important to identify the peer identity (gateway or server) with which the signaling protocol would be carry out with. This can be accomplished with the tunneling endpoint discovery. It is possible that for the traffic flowing between two domains to encounter intermediate administrative domains manifested through border gateways enforcing some sort of restrictive policies. This will have an effect on the type of policies exchanged and the nesting of tunnels for the discovery and the signaling protocols. It should be possible using the discovery protocol to manage the tunneling policies across multiple domains by identifying the gateways towards the destination. This should help avoiding conflicts of ESP and AH tunnels -- see Figure 6. Confidentiality for signaling is a must to support and optional to use. Therefore, the discovery protocol must facilitate managing confidentiality for the policy signaling protocol. To accomplish this task, certificates, public keys and security profiles need to be exchanged. The security profiles will facilitate the interoperability of encryption algorithms and parameters for the two models of resolution. The mechanism of the discovery protocol is similar to the chain model of signaling. The initiator gateway issues a discovery message towards the destination. The message carries a request Cuervo & Rayhan [Page 13] Internet Draft Architecture for IPSEC Policy November 2000 defining the tunneling policy, credentials and confidentiality requirements. As the message gets intercepted by the next gateway in the path, it either replies to it, piggybacks a new request to the message, let it pass through, or block it and issue a request of its own. The reply is issued if gateway is a border gateway to a domain and detects policy violation. A new request is piggybacked if it is to complement the initial request. In this case, it should be possible to show the relationship between the two requests. The message is let through if there is no policy to be enforced at that particular gateway. A request is blocked and a new request is issued in the case of border gateway controlling access and policy management for all nested domains. Intermediate gateways follow suit if necessary. Once the message reaches the destination, a reply is issued to the received request(s) then sent towards the initiator of the original request message. As the reply message travels, intermediate gateways can add their replies to the requests they received earlier in the request message. The requests and replies should depend on the policy requirements of intermediate domains and on who is authoritative over what. For example, the network architecture depicted in Figure 10 is assumed. To illustrate the concepts, only tunneling policies are shown in this example. We also have the following assumptions. SG1 requires an AH tunnel with a peer gateway or host. SG2 requires to be the endpoint of all ESP tunnels and allows AH tunnels to pass through. SG3 has a similar policy to SG2. SG4 request at least to be the endpoint of AH tunnels. SG1 detects traffic from H1 to H2. A discovery request is sent towards H2 with AH requirement. SG2 detects the discovery request and decides to piggyback its own request for an ESP tunnel. SG3 detects the message and piggybacks its request which complements SG2's request. Finally, SG4 gets to process the request message and sends the reply message towards the initiator, SG1 in this case. Figure 11 shows the details of this example. ESP tunnel SG2==============SG3 AH tunnel SG1================================================SG4 H1 H2 Requirements: SG1 requires AH tunnel with peer gateways SG2 requires ESP tunnel with peer gateways and the endpoint for all ESP tunnels. SG3 requires ESP tunnel with peer gateways and the endpoint for all ESP tunnels. SG4 requires AH tunnel with peer gateways Cuervo & Rayhan [Page 14] Internet Draft Architecture for IPSEC Policy November 2000 Figure 10: Example of network configuration H1 SG1 SG2 SG3 SG4 H2 ---------------> Request MSG Req-1 SG1->H2:AH ---------------> Request MSG Req-1 SG1->H2:AH Req-2 SG2->H2:ESP ---------------> Request MSG Req-1 SG1->H2:AH Req-2 SG2->H2:ESP Req-3,Ref-2 SG3->SG2:ESP <--------------- Reply MSG Req-1 SG1->H2 Rep-1 SG1->SG4 Req-2 SG2->H2:ESP Req-3,Ref-2 SG3->SG2:ESP <--------------- Reply MSG Req-1 SG1->H2 Rep-1 SG1->SG4 Req-2 SG2->H2:ESP Rep-2 SG3->SG2:ESP <--------------- Reply MSG Req-1 SG1->H2:AH Rep-1 SG1->SG2:AH Figure 11: Example of the discovery protocol There are a number of unresolved issues still to be resolved such as maintaining the integrity of modified messages, confidentiality requirements, discovery compliance requirements, and conditions of when to initiate and terminate the protocol. These issues are to be detailed in the specification draft of the discovery protocol. Note that the dynamics of this approach are still under development. 7 References: Cuervo & Rayhan [Page 15] Internet Draft Architecture for IPSEC Policy November 2000 [PFRFC] M. Stevens, H. Mahon, J. Strassner, G. Waters, A. Westeriner, "Policy Framework", Internet Draft, work in progress. [ISARFC] D. Maughan, M. Schertler, M. Schmeider, and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998. [KEYW] S. Bradner, "Key Words for use in RFCs to Indicate Requirements Levels", BCP 14, RFC 2119, March 1997. [IKERFC] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409 November 1998. [ESPRFC] S. Kent, R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [AHRFC] S. Kent, R. Atkinson, "IP Authentication Header ", RFC 2402, November 1998. [DOIRFC] D. Piper, "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998. 14 Author's Addresses Fernando Cuervo Nortel Networks P.O. Box 3511 Stn C Ottawa, ON, Canada K1Y 4H7 Phone: (613) 763-9611 eMail: cuervo@nortelnetworks.com Abdallah Rayhan Nortel Networks P.O. Box 3511 Stn C Ottawa, ON, Canada K1Y 4H7 Phone: (613) 763-9611 eMail: arayhan@nortelnetworks.com Cuervo & Rayhan [Page 16] Internet Draft Architecture for IPSEC Policy November 2000 Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Cuervo & Rayhan [Page 17]