[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
locating IPsec gateway proposal
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