Internet DRAFT - draft-cuervo-ipsp-arch
draft-cuervo-ipsp-arch
INTERNET-DRAFT Fernando Cuervo
Expires : April 2001 Abdallah Rayhan
Category : Informational Nortel Networks
<draft-cuervo-ipsp-arch-01.txt> 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]
