Matt, Although I not followed IPsec for a long, it looks the standards still won't help you. (Can't wait to see 'IPsecond' activity started to resolve this and plenty other issues I have got in minds;-) An year ago I wrote some proposal on similar problem, nothing special, but you may wish to review attached message. --Alexei -----Original Message----- From: Matt Field <MFIELD@securenet.com.au> To: 'ipsec@lists.tislabs.com' <ipsec@lists.tislabs.com> Date: 24 èþíÿ 1999 ã. 6:02 Subject: redundancy :Hi, : :Can anyone illustrate if and how ipsec could handle multiple ipsec :gateways to a single network. I have come accross the following :scenario: : :----------------------------------------- Network 1 : | : | D : -------------- : | | : | | : A B : | | : | | : \ / : \ / : \ / : C : | :----------------------------------------- Network 2 : :Network 1 has D which is a Front End Processor (FEP) that performs some :kind of load balancing that may route packets either through ipsec :gateways A or B. C is an ipsec gateway on a remote network. The :problem is, if tunnels are created beween gateways A-C and B-C, then :when C receives a packet from Network 2 for network 1, how does :determine which SA to use since the destination address is behind both :gateways? : :My guess is that this is an implementation detail and outside the scope :of IPSEC but any thoughts on this would be useful. : :regards, : :Matt Field : :
-- BEGIN included message
- To: "IPsec MailList" <ipsec@tis.com>
- Subject: locating IPsec gateway proposal
- From: "Alexei V. Vopilov" <alx@elnet.msk.ru>
- Date: Tue, 3 Feb 1998 20:56:00 +0300
- Sender: owner-ipsec@ex.tis.com
Attached document describes an approach to solve the following problems - discovering IP address and/or Key of IPsec gateway - locating a backup gateway at the runtime if primary gateway fails. - discovering the chain of nested gateways if there is a number of secured borders protecting a remote server. Comments and critics are welcome. regards, --- Alexei V. Vopilov (alx@elnet.msk.ru), +7(095)5367694 Software Architecture&Development Consultant. ---February 3, 1998 Alexei V. Vopilov Alx@elnet.msk.ru The locating an IPsec gateway algorithm <draft-draft-alx-ipsec-gw-loc.txt> Abstract ----------------------------------------- As any sophisticated and fast growing system, Internet employs various technologies to adopt dynamical changing of it infrastructure. This makes possible to keep connectivity at the high level during both usual expansions of Internet and internal rearrangement of yet deployed Internet components. In fact, incorporation of a security in the Internet network layer in most cases successfully breaks achieved connectivity being sacrificed for the safety of information exchange. One scalability problem with IPsec-based communications arises whenever one networking node delegates to other it network security functions. As the result, a client system has to figure out and keep in consistence information about where such trusted intermediate is located presently and which credentials are to use at the same moment. Current DNS and even proposed DNSSEC technologies do not provide required functionality to solve this task reliably. This document propose a number of considerations that, if taken into effect, increase availability of secured resources while keeping the security level intact. Discussion ----------------------------------------- Proposed scheme is based on yet available ISAKAMP specification. It is not required to change existing ISAKMP payloads format for supporting basic functions described herein. However, inventing additional payloads and exchange types for ISAKMP would provide more usability for algorithm. In general, this document suggests methodology that having been implemented in an IPsec implementation solves the following issues. 1. The later binding between an IP address of remote server and such parameters as the address of IPsec gateway and gateway Key. 2. Discovering, during runtime, secured backup path for an IPsec client when secured server resources can be reached via more than one IPsec gateways. 3. Discovering a chain of trusted intermediate gateways whenever network traffic must be protected by a number of nested Security Associations. Core Idea ----------------------------------------- Suppose that a client IPsec system must protect communications to some remote server with known IP address. Assume also that such information as an IPsec gateway address and probably gateway's Public Key is not supplied with local policy or those parameters can be dynamically changed during runtime. Since current standards require a client system to establish ISAKMP SA prior negotiating of any application level SA, let's suggest for client to enter in ISAKMP SA negotiations. Here are first two tricks: 1. A client system tries negotiate ISAKMP SA right with the remote server it needs to get access to. 2. With an ISAKMP SA request a client associate only two selector parameters such as locally generated Cookie and local IP address. Note that if a client system is not sure which of credentials to use for destination, this information is just omitted in ISAKMP SA request. Whenever the reply on ISAKMP SA request is received, client finds appropriate ISAKMP SA context based on locally generated cookie value included in the ISAKMP SA response. That means the address of a responder in the reply might not correspond to the one used for sending the request. The next trick is: 3. Upon successful negotiation of an ISAKMP SA, a client node uses actual address of ISAKMP SA responder as one representing security gateway for originally requested remote server. Note that proposed scheme, when based just on yet developed specifications does not prove the trustiness of discovered information, though there is a number of ways to get that prove based on available technologies. Note as well that since some parameters previously considered as resided in the local policy are now suggested to be 'negotiable', the logic embedded into implementations becomes more sophisticated and must be clearly defined. The issues, subsequent from two above statements, are discussed in the respective sections hereinafter. The trustiness of discovered information ----------------------------------------- In fact, this document proposes to have such parameters of IPsec configuration as Gateway Address and Remote Party Credentials be optionally discovered online. One might argue that a system followed this approach will become compromised due to simple attacks. For example, if A wants to access B, some malicious intermediate router C can conduct a simple attack by claiming that it represents B and forcing A to encrypt network data using wrong keys. The response on this argument is that information itself and authorization to use it for specific purposes are topics from two different discussion domains. Thus, the address of a router on the path between two nodes is an issue of projection of current network load on the underlined topology. The authentication of IP address and Public Key of a router to represent a trusted intermediate for destination nodes is an administrative policy employed in an organization the destination node belongs to. The authorization to use discovered IP address and key for a gateway is an administrative issue used by security policy on the client side. For example, once the IP address and Key have been discovered by an initiator, the latest can use DNSSEC protocol to prove that or, at least, consult with locally resided (and trusted) database. Protocol implementation details ----------------------------------------- This section presents if-else conditions occurring during IPsec gateway address and key discovering process. Note that by implementing described logic not only control flow but also general design of an IPsec implementation gets affected. Initiator requirements ------------------- 1. The following configuration data of an IPsec implementation are maintained separately. - Authenticated database of Network domains and corresponded IPsec gateway addresses. - Authenticated database of Network domains and Public keys representing gateways from particular domain. 2. Local SPD may not include the gateway address and Key ID values for particular policy entry. 3. For some local SPD entry it is possible to have a list of associated gateway addresses and allowed Keys. 4. The only selectors that represent an ISAKMP SA request for initiator are Initiator's COOKIE value and allocated source UDP port. The same COOKIE must not be possible to generate within a period less than timeout set for ISAKMP SA creation attempt. 5. Multiple ISAKMP SAs with the same remote system must be supported. Responder (IPsec gateway) requirements ------------------- 1. It must be possible to intercept UDP packets going through a gateway to a system protected by that gateway. 2. Multiple ISAKMP SAs with the same remote system must be supported. Starting point ------------------- The protocol starts whenever Initiator needs to create ISAKMP SA with known destination address. Initiator performs: ------------------- 1. Generates Cookie and composes ISAKMP SA request. Note that Initiator may follow to any of ISAKMP modes, specifically: - Initiator ID payload might not be supplied with the request - Responder ID payload might not be supplied with the request 2. Allocates a source UDP port, creates UDP socket, bind the socket to local address. 3. Sets retransmission counter and timeout value for a request. 4. Sends UDP request originated from allocated port and destined for ISAKMP daemon port of remote system. 5. Starts to listen on created socket bundled to allocated source port for 'any' destination IP address. Gateway performs ------------------- 1. Upon intercepting client's request, consults with local policy whether information provided in the request is enough to enter in the ISAKMP SA negotiation. 2. If more information is required, gateway forces a client to follow appropriate ISAKMP mode by sending the reply originated from gateway (tunneling) IP address with Initiator Cookie included. At the same time, at least the gateway COOKIE is supplied. Initiator performs ------------------- 1. If the listening socket has returned Cookie other than was originally sent, silently drops incoming packet. This even should be logged as possible attack attempt. 2. If the address of destination system differs from one used in request, checks out whether gateway discovering is allowed for particular destination system. 3. If local policy prohibits secured gateway discovering, silently drops the packet, continues listen until retransmit counter has been expired. This even must be logged as either the fact of an attack or misconfiguration either of two IPsec systems. 4. Otherwise, initiator continues negotiations until both gateway address and authenticated credentials become available. Before making any further decision, initiator performs checking that discovered information is authorized for using for particular remote server. The authorization is made based on local configuration of a client or through DNSSEC request. Upon successful creation of ISAKMP SA, the resulting address of ISAKMP SA serves as tunnel address during further (application SAs) negotiations. Discovering backup path/gateway ----------------------------------------- This section describes advanced technique if a remote server can be reached through multiple gateways. The issues of primary gateway failure and dynamical switching the routing to point on other entry point of a secured border are covered as well. The most sophisticated environment would be described as followed: - A remote server can be reached through more than one gateway - Some/all of gateways employ the same virtual tunneling address been assigned to belong a subnet protected by gateways border. - The routing is established to carry packets through different gateways considering forward and backward data- flow directions. More detailed gateway-discovering algorithm is as followed: 1. Initiator discovers primary gateway. The following information becomes available locally: - Tunneling address GW_IP_1 - Gateway Key GW_KEY_1 Note that at this step the ISAKMP SA_1 is created between a Client and GW_1 2. Suppose that primary gateway becomes broken. That fact can be discovered by means ether of two events: - ISAKMP SA_1 does not respond on 'keep alive' messages sent by a client. This case reflects an environment where there is only one gateway or GW_IP_1 is NOT shared between multiple gateways. - A client has received request on ISAKMP SA from other gateway but with the same IP address as GW_IP_1. This case characterizes an environment where the secured data flow is affected by dynamic routing. Note that Key ID of a new gateway can be different from previously discovered one. 3. In both cases, a client starts discovering of another gateway while retrying the old one. 4. If protocol has succeeded, ISAKMP SA_2 is created and all ISAKMP SA_1 child-SAs are renegotiated. 5. ISAKMP SA_1, if not responded, is removed afterwards. Different forward and backward server paths ----------------------------------------- Sometime, the routing will cause the forward and backward exchanges with a remote server are destined through different IPsec gateways. As the result, a client IPsec implementation will meet with the fact of additional ISAKMP SA requested after establishment of an application-level SA. After second ISAKMP SA is established, the request to create application-level SA for backward traffic will be made possibly employing the same tunneling address but different gateway Key. A client has to handle this situation correctly by encrypting application data going to remote server using firstly discovered Key and decrypting backward traffic with secondly discovered Key. Unfortunately, current ISAKMP protocol cannot resolve this potential conflict explicitly. To date only the order of ISAKMP SAs creation provides a hint for a client IPsec implementation. Routing flip-flop ----------------------------------------- The worse case than previously described will be for unstable routing path that might cause to a number of ISAKMP SAs be created when discovering IPsec gateway. Configurations where different gateways employ the same gateway address will not work since a client IPsec cannot predict the path packets will go through, so the right gateway's Key cannot be set for outgoing data without modification current ISAKMP spec. If tunneling address is not shared by many gateways, routing flip-flop won't be a problem since encapsulated packets will have real (not virtual) gateway address in their outer headers. Discovering a chain of gateways ----------------------------------------- An organization security policy would require that a server be accessible through multiple nested SAs. There can be two polar cases, specifically: - The inner gateway or server itself requires data to be encrypted. A number of outer gateways perform the authentication of a client traversing nested secured borders. - The outer gateway provides data confidentiality for a client. A number of inner gateways perform authentication and authorization of a client to use specific resource of a server. In either case, the chain of nested SAs has to be built up. If addresses and/or Keys need to be discovered, below is possible algorithm. 1. A client follows to scheme of discovering IPsec gateway as described before. 2. First (outer) IPsec gateway, acting on behalf of remote server, establishes ISKAMP SA with that client. 3. Client requests from just found gateway an application level SA targeted to the ISAKMP daemon port of a remote server. 4. Upon successful creation of above SA, client sends ISAKMP SA request that has to traverse through first (outer) gateway. Outer gateway strips encrypted payload and forwards encapsulated ISAKMP SA request destined to remote server. 5. Second gateway intercepts that request and replies to client claiming to be intermediate to be also taken into effect. 6. The outer gateway now gets the fact of ISAKMP SA reply going to a client, but it's source address does not match just created application-level SA. 7. Since there is no support in present ISAKMP draft for signaling on such a case, a workaround is to add extra logic into IPsec gateway implementation. The logic is based on the following facts: - The gateway provides discovering function for a client - Client has been served, i.e. ISAKMP SA in behalf of remote server has been established by the gateway - Local security policy on the gateway allows propagation of next gateway discovering 8. The same algorithm is applied until remote server has been reached. Note that if the server runs IPsec it just responds with it own address in the reply, thus terminating the algorithm. Otherwise, a gateway closest to remote server, knowing that the server is on non secured wire refuses creation of next ISAKMP SA. 9. Client is now aware of all gateways and its order. Thus, it can start negotiating of an application level SAs nested according to just discovered information. Just described approach can be generalized, so it would work for discovering backup path as well as for completing any of mentioned above tasks. Good stuff to put into IPsecond ----------------------------------------- This section introduces areas of further improvements IPsec technology towards it scalability and functionality. Nevertheless, topics discussed below do not prevent implementation of IPsec gateway discovering functions based on only whatever is available (and standardized) to date. Suggested improvements just make possible IPsec implementation less complex and more straightforward. Address, Key and IPsec Trust Domains ------------------------ The IPsec Trust Domain term represents the authenticated knowledge of IPsec related configuration parameters. The knowledge is separated from policy enforcement. Instead, it can be used as a statement in high-level policy abstraction. Although the detailed explanation of the Trust Domain term is of other document scope, some issues are discussed below. Suppose, Security Administrator of a gateway has RSA key that is used to sign the gateway key. The name of gateway key can be just it IP address. Suppose also that Network Administrator has own RSA key that is used to sign the address of gateway and subnet resided behind this gateway. Both administrators public keys are enclosed in certificates signed by some other party. Both certificates have Trust Domains identifiers and constraints. Trust Domain identifiers correspond to the right of signing gateway keys and gateway addresses respectively. The constraints are hosts or/and subnets list. The party used to sign above certificates has it own certificate containing Trust Domain identifier and constraints. The Trust Domain identifier says that that party can sign certificates of above mentioned Trust Domains. The constraints restrict such privileges to some network domain (XYZ.COM). The party certificate is also signed. The chain ends up with well-known Certificate signed by well-known Authority. An IPsec gateway can have all the chain preloaded and send it to a client through ISAKMP payloads, which are to be invented. A client might have a policy statement constructed from Authority Certificate and Trust Domains to be enforced from it. Explicit signaling of gateway discovering ------------------------ This attribute/payload to be added in ISAKMP spec would simplify the following things: 1. To have separate policy on a gateway, stating the client's right to do nested SAs discovering through multiple secured borders. 2. To simplify authorization on backup gateway to restore client application-level SAs somewhere in the middle of yet established network connections (considering recovering due to primary gateway failure) 3. To reduce number of ISAKMP SAs maintained on the gateway and client, if the last one is trying to discover a gateway for yet another remote server from the same subnet. Explicit notification on changed routing path ------------------------ Suppose, all gateways of secured network border employ the same tunneling address for using by outside. That case greatly improves secured connectivity to inside resources. A client system might have number of ISAKMP SAs being created at the same time with different gateways. The question is which one is to be active at present moment. It is possible to use 'keep alive' message for testing current routing path, but there is no notification type to be returned by a gateway indicating that other ISKAMP SA has to be established/activated on the client side. The notification would include client Cookie identifying the 'keep-alive' message occasionally received by a gateway. The best solution is to provide separate authentication for this notification for a client. Explicit signaling on creation of one-way SA ------------------------ Consider the case when secured data are going different ways in different directions through some network border. For a client, it results to two the same application-level SAs are active simultaneously. A client has to understand which SA is to use for encryption and which one for decryption. The order of SAs creation does not always work, especially when routing is switched during SA lifetime. Authenticated connections list ------------------------ In case, when a client is switching on a backup gateway, the yet established connections list has to be moved to that gateway transparently for applications. Most firewalls implement a connection bootstrap checking. If a client won't have all connections to be reestablished, it must convince the backup gateway that all connections were created before the right way. The problem has simple solution if a client can always present these connections as authenticated by previously used gateway. Authentication can be a digital signature or it can be a hash over connection information keyed by some shared secret available on all gateways forming fault tolerant environment in an organization. Security considerations ----------------------------------------- The described methodology pretends to improve scalability of IPsec implementation by online discovering of IPsec gateway address and/or it key. However, without strong authentication it is just a way to death to use the retrieved data. At lease following authentication scheme must be supported. 1. Check out that discovered address belongs to administrative domain the remote server does. 2. Check out that discovered Key does match to the list of locally deployed keys corresponded to administrative domain the remote server belongs to. 3. Alternatively for key, check out that signature on discovered Key corresponds to the Certificate Authority of administrative domain the remote server belongs to. Author address information ----------------------------------------- Alexei V. Vopilov Post : 103498, Zelenograd, building 420, N 149, Moscow, Russia. Phone : +7(095) 5367694. E-mail: alx@elnet.msk.ru or alexei.vopilov@usa.net
-- END included message