Internet Draft C. Madson
Document: draft-ietf-ipsec-sonofike-rqts-00.txt Cisco
Expires: September 2002 March 2002
Son-of-IKE Requirements
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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.
Abstract
Various proposals have been made for updating the IKE protocol. This
effort has been known as "Son of IKE (SOI)".
One thing that is missing from the discussion is an evaluation of the
scope of SOI, identifying which problems it should solve. Sections of
this document discuss various scenarios that are considered important
for SOI.
Once this scoping is done, it becomes easier to specify the
requirements of the protocol. This document also discusses protocol,
policy and security requirements for SOI, along with recommendations
for protocol improvement in such areas as modularity, extensibility,
protocol convergence and simplicity, which are important regardless
of the scope of SOI.
Hain Expires - September 2002 [Page 1]
Son-of-IKE Requirements March 2002
Table of Contents
1. Overview.......................................................5
1.1 Changes from Previous Drafts...............................5
2. Conventions Used in This Document..............................6
3. Definitions....................................................6
4. Scenarios: Primary Domains of Usage............................6
4.1 Virtual Private Network Site-to-Site Tunnels...............7
4.1.1 Operational Characteristics..........................7
4.1.1.1 General Description...........................8
4.1.1.2 Dynamic Addressing............................8
4.1.1.3 NAT...........................................9
4.1.1.4 QoS...........................................9
4.1.2 Policy...............................................9
4.1.3 Security-Related Characteristics....................10
4.1.3.1 Authentication...............................10
4.1.3.2 Identity.....................................10
4.1.3.3 Identity Protection..........................10
4.2 Secure Remote Access......................................10
4.2.1 Operational Characteristics.........................11
4.2.1.1 General......................................11
4.2.1.2 Dynamic Addressing...........................12
4.2.1.3 NAT..........................................12
4.2.1.4 QoS..........................................12
4.2.2 Policy..............................................13
4.2.3 Security Characteristics............................13
4.2.3.1 Authentication...............................13
4.2.3.2 Identity.....................................14
4.2.3.3 Identity Protection..........................14
4.3 End-to-End Security.......................................14
4.3.1 Operational Characteristics.........................15
4.3.1.1 General Description..........................15
4.3.1.2 Dynamic Addressing...........................15
4.3.1.3 NAT..........................................15
4.3.1.4 QoS..........................................15
4.3.2 Policy..............................................16
4.3.3 Security Characteristics............................16
4.3.3.1 Authentication...............................16
4.3.3.2 Identity.....................................16
4.3.3.3 Identity Protection..........................16
4.4 IP Storage................................................17
4.4.1 Operational Characteristics.........................17
4.4.1.1 General Description..........................17
4.4.1.2 Dynamic Addressing...........................18
4.4.1.3 NAT..........................................18
4.4.1.4 QoS..........................................18
4.4.2 Policy..............................................18
4.4.3 Security Characteristics............................18
4.4.3.1 Authentication...............................18
Madson Expires - September 2002 [Page 2]
Son-of-IKE Requirements March 2002
4.4.3.2 Identity.....................................19
4.4.3.3 Identity Protection..........................19
4.5 PPVPN/MPLS................................................19
4.5.1 PE-to-PE IPsec......................................19
4.5.2 CE-to-CE IPsec......................................20
5. Other Problem Areas...........................................20
5.1 Mobile IP/Wireless........................................20
5.1.1 Fast Handoff........................................21
5.1.2 Securing Binding Updates............................21
5.2 Multiple and Changing Addresses: IPv6, SCTP and MobileIP (and
NAT?).........................................................22
5.3 Delay-sensitive Applications..............................23
5.4 Other Users of IPsec......................................24
6. General Operational Requirements..............................24
6.1 Scalability...............................................24
6.2 Fast setup................................................25
6.3 One-phase vs. two-phase exchange..........................26
7. Protocol Requirements.........................................27
7.1 Protocol Interaction......................................27
7.2 Identity..................................................27
7.3 Interaction with NAT......................................27
7.4 General Protocol Design Criteria..........................28
7.4.1 Modularity..........................................28
7.4.2 Extensibility.......................................28
7.4.3 Protocol Convergence................................29
7.4.4 Simplicity..........................................30
8. Policy Requirements...........................................30
8.1 Provisioning and Management...............................30
8.1.1 Configuration.......................................30
8.1.2 Discovery...........................................31
8.2 Expanding the set of selectors............................31
8.3 SPD traffic flow descriptors and dynamic policy...........32
8.4 Retaining SAs in face of address changes..................33
8.5 Distribution of authentication information................34
8.6 Authorization.............................................34
8.7 Additional "per-connection" policy........................34
9. Security Requirements.........................................34
9.1 Key Agreement.............................................34
9.2 Key Generation............................................35
9.3 Authentication............................................35
9.4 Resistance to Denial-of-Service Attacks...................36
9.5 Resistance to Replay Attacks..............................37
9.6 Resistance to downgrade attacks...........................37
9.7 Implementation Recommendations............................37
9.8 Use of Negotiation Suites.................................37
9.9 Identity Hiding...........................................38
9.10 Plausible Deniability....................................38
9.11 Protection of Key Management Messages....................39
9.12 Support for PFS..........................................39
Madson Expires - September 2002 [Page 3]
Son-of-IKE Requirements March 2002
10. Security Considerations......................................39
11. Acknowledgements.............................................40
12. References...................................................40
13. Editor's Address.............................................41
Madson Expires - September 2002 [Page 4]
Son-of-IKE Requirements March 2002
1. Overview
While there have been various proposals made over time of how to
"improve" IKE, in order to address issues such as complexity, itÆs
important to decide what are the important characteristics for the
protocol, and then determine what changes need to be made in order to
accomplish this.
Another way of stating this is "what are the characteristics of an
optimal protocol, and what does it take to get there?" It will be
important to prioritize these characteristics, in order to help focus
on making changes in areas that will have the biggest benefit.
We first need to identify the "important" baseline scenarios that
should be accommodated with a redesign of IKE. These scenarios should
drive the definition of detailed requirements in various areas.
However, in many cases the scenarios themselves cannot completely
drive security requirements. There are also some general requirements
that can be considered as requirements related to protocol design,
both of which will be outlined later in the document.
The WG needs to prioritize the sometimes conflicting requirements;
subsequent revisions of this document should reflect this.
The term "Son of IKE" (SOI) will be used to refer to the new
protocol. Where appropriate, "IKE" will be used to refer to the
original protocol. The term "IPsec tunnel" means an instance of an
IPsec "connection", in this context it does not mean "tunnel mode
IPsec".
1.1 Changes from Previous Drafts
The primary differences between this draft and the previous draft
are:
. inclusion of security and policy requirements along with the
protocol requirements
. expanding the scenarios
. restructuring the document to emphasize the scenarios, where
more of the requirements are represented as a result of the
scenarios
. reducing the amount of "philosophical discussion" from the
original draft (which was put there to influence initial WG
thinking).
Madson Expires - September 2002 [Page 5]
Son-of-IKE Requirements March 2002
2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119[1].
3. Definitions
This section defines some terms relative to how they are used within
this document.
1) Dynamic addressing: the network node does not have a fixed
address, and the DNS entry is tied to the address and not the node.
2) Machine-level authentication: refers to some static authentication
scheme, where the authentication material is readily available to
both parties. Machine-level also refers to the fact that the device
is authenticated, and not the user using the device, which is a
function of a higher layer or separate protocol.
3) User-level authentication: refers to the fact that the user of the
device is authenticated. This authentication may be "static" (simple
presenting of user credentials) or "dynamic" (interactive exchange
between user and authentication server/proxy, using legacy
authentication mechanisms).
4. Scenarios: Primary Domains of Usage
It is important for SOI to focus on some number of usage domains, and
make sure that the domains' requirements have been met. The following
sections describe several characteristics of each domain of usage
that are noteworthy:
. Operational Characteristics
o General
o Dynamic addressing
o NAT
o QoS
. Policy
. Security Characteristics
o Authentication
o Identity
o Identity Protection
Madson Expires - September 2002 [Page 6]
Son-of-IKE Requirements March 2002
The scenarios listed here are considered to be the major ones that
should be addressed, although the list is not exhaustive and needs to
be refined by the WG.
For simplicity's sake, this section attempts to describe "idealized"
scenario classes. However, the real world *will* have scenarios which
are hybrids of one or more of the below classes.
The next section will describes some problem areas that are
orthogonal to the main classes; in some scenarios these classes would
be used in conjunction with the above classes, but they are kept
separate to reduce the complexity of the discussion.
A combination of brackets <<< >>> and identing are used to highlight
items that should be considered during protocol design.
4.1 Virtual Private Network Site-to-Site Tunnels
VPN Site-to-Site Tunnels are between two devices acting as Security
Gateways (SGWs). IPsec can either directly encapsulate the IP traffic
that it will secure, or it can secure another tunneling protocol
(e.g. IPinIP) running between the two SGWs, where that tunnel has
already encapsulated the data.
The SGWs may be responsible for securing a wide variety of traffic,
including interactive (Telnet), file transfer and HTTP traffic.
Customers are also increasingly deploying IP-based video conferencing
and VoIP.
This category can be broken down into two sub-categories:
. The VPN itself is in the same general administrative domain as
the transport network.
. The VPN is in a separate administrative domain from the
transport network. This can include a VPN that traverses
transport networks in multiple domains.
In both cases, the VPN itself is in a single administrative domain.
4.1.1 Operational Characteristics
In the first sub-category, the VPN is in the same administrative
domain as the transport network (to be referred to as "single
administrative domain" in this document). One such example may be a
campus network.
Such a network may be a (near) full-mesh.
Madson Expires - September 2002 [Page 7]
Son-of-IKE Requirements March 2002
In the second sub-category, the VPN is in a different administrative
domain from the transport network (to be referred to as "multiple
administrative domains" in this document). One such example may be
one or more SPs interconnecting several locations of an enterprise,
where the enterprise is managing the VPN.
Depending upon its size and organizational topology, the VPN may
operate as a (near) full-mesh, or it may operate with more limited
interconnection (e.g. hub-and-spoke).
4.1.1.1 General Description
The administrator may have requirements to encrypt some or all of the
traffic that crosses the transport network, and may require that
certain traffic be handled or otherwise protected different from
other traffic (e.g. a department-wide video conference may need to be
protected and/or handled in a different manner than normal file
transfer/web traffic between systems in that same department).
While a simple general model has the SGWs simply protecting subnet-
to-subnet traffic, the greater the number of distinctive traffic
classes identified, the greater the number of IPsec tunnels needed
between the SGWs. Even the simple model can result in a lot of IPsec
tunnels in the case where each SGW is fronting multiple non-
contiguous subnets (such as in the case where the SGWs are on the
customer premise boundaries).
<<<This calls out a need for either a two-phased approach for SOI,
or a single-phased approach that is sufficiently fast, where "fast"
represents an optimal combination of "number of messages" and
"computational expenditure". The cost of authentication must also
be factored into the total cost; this will be different for
different mechanisms, which results in a decision of scalability - -
vs- processing overhead. In certain cases, it may be desirable to
amortize the cost of the key management across multiple tunnels.
In the case of a pair of SGWs fronting multiple non-contiguous
subnets, a mechanism that allowed the negotiation of a list of
phase 2 identities will help to alleviate the number of IPsec
tunnels that must be created.>>>
4.1.1.2 Dynamic Addressing
Madson Expires - September 2002 [Page 8]
Son-of-IKE Requirements March 2002
Within a single administrative domain network, the SGWs will almost
always have permanent IP addresses assigned to them.
Within a multiple administrative domain network, there may be a
mixture of SGWs with static and dynamic IP addresses.
Within a single administrative domain network, it is unlikely that
NAT devices will be deployed between the SGWs.
Within a multiple administrative domain network, the IPsec tunnel may
be NAT'd between the SGWs. The traffic inside the IPsec tunnel may
also be NAT'd by one of the SGWs.
In many cases, there will be a need for separate handling of
multimedia vs. standard file transfer/web/login traffic. Depending
upon the characteristics of the traffic, this may call out a need for
fast tunnel establishment ("fast" in this case is expanded to also
mean low delay). Such traffic may also need to be separately
protected (e.g. via stream ciphers instead of block ciphers).
Depending on the location of the SGWs relative to the systems that do
the QoS classification/marking, <<<extensions to the IPsec (now known
as phase 2) parameters are needed in order to negotiate QoS
characteristics for the various tunnels.
QoS increases the probability of multiple tunnels between a pair of
SGWs. Also, negotiation of IPsec tunnels needs to accommodate QoS
information, predominantly in the set of selectors used to identify
the contents of any particular IPsec tunnel.>>>
The peers in this scenario are more likely to be relatively static
(in terms of IP address, number of peers, and rate at which a new
peer will get added or existing peer deleted). The number of peers is
also likely to be lower by orders of magnitude than in the Remote
Access case. Therefore configuring policy pertaining to SOI
(authentication material as well as ciphers) can easily be statically
configured on each peer.
Another issue is policy that should apply to the resulting IPsec
tunnel. In the site-to-site case, since peers are bound to be fairly
static, configuring this IPsec policy (inside IP addresses, firewall
Madson Expires - September 2002 [Page 9]
Son-of-IKE Requirements March 2002
features, QoS features, etc) can be manually configured on both ends,
rather than pushed or pulled in some way.
4.1.3 Security-Related Characteristics
4.1.3.1 Authentication
Machine-level only.
If the SGWs do not have dynamic IP addresses, and there are no NAT
boxes between the SGWs, IP addresses can be sufficient for phase 1
identities, although this is discouraged.
<<<In the case of dynamic IP addresses and/or NAT boxes, IP
addresses cannot be used as phase 1 identifiers. This also means
that the authentication material cannot be chosen based upon the IP
address in the packet.>>>
4.1.3.3 Identity Protection
In a single administrative domain network, while identity protection
is desirable, in many cases it is not a requirement.
<<<In a multiple administrative domain network, identity protection
of both IPsec endpoints is important.>>>
4.2 Secure Remote Access
When the client is outside the protected network that it needs to
access, it will have to interact with a Remote Access Server (RAS) in
order to access that network.
In many cases, this scenario is replacing a remote access scenario
that uses dial-up access to reach a network. The client would dial up
to the RAS and interact with the RAS to perform user-level
authentication (e.g. userid/password, SecureID, etc.). If the
authentication is successful, the RAS would permit access to that
network, and it may also push down configuration information to the
client.
In this scenario, before the IPsec tunnel is constructed between the
client and the RAS, the client must first authenticate itself (most
likely using legacy authentication mechanisms). The IPsec connection
Madson Expires - September 2002 [Page 10]
Son-of-IKE Requirements March 2002
will most likely operate in tunnel mode, and will most likely always
be initiated by the client.
The entity that supplies the RAS typically requires accounting of
connections and resources consumed, in order to do capacity planning.
4.2.1 Operational Characteristics
A RAS server in many cases is a remote access aggregation device,
which is terminating large numbers of IPsec tunnels.
In the case of a reboot of a RAS, the RAS will be forced to rapidly
service a large number of requests to reestablish SOI and IPsec
connections. [While this problem is also true in the Site-to-Site
scenarios, the aggregation densities associated with RAS devices
means that this issue tends to be more prevalent in this scenario.]
<<<This means that the key management mechanism must be able to
rapidly establish both the SOI and IPsec connections, without undue
impact on CPU and memory overhead. ItÆs also desirable for each
exchange to have as few messages as possible, to help alleviate the
burst load on the RAS.>>>
It is more common for a remote access client to initiate a single SOI
connection and create a single IPsec tunnel with the RAS. However, if
there is a need to uniquely handle separate data flows (e.g. video
vs. ftp), a client may need to establish multiple IPsec tunnels with
the RAS. In most cases, any user authentication should apply against
the collection of IPsec tunnels, in other words, the user should not
be forced to re-authenticate with every tunnel setup. [While on the
one hand, this can be viewed as a local issue, in the case of certain
legacy authentication mechanisms, having the client simply store the
value and use it again for the next IPsec tunnel will not work.]
<<<While this does not mandate user authentication to happen within
the SOI exchange, itÆs strongly encouraged that the protocol
directly or indirectly associate a single user authentication
exchange with a group of IPsec tunnels between a client and an
RAS.>>>
In certain scenarios, a single RAS may be supporting traffic for
different VPNs. In this case, the RAS will have a separate identity
per domain. For any given SOI exchange, the RAS will need to select
which identity it will use depending upon the identity supplied by
the client. Basically, the RAS needs the clientÆs identity in order
Madson Expires - September 2002 [Page 11]
Son-of-IKE Requirements March 2002
to decide how to interact with the client (e.g. negotiation
parameters, RAS identity, etc.).
<<<For example, this may mean that SOI will need to allow for the
client to present its identity (or some "blob of bits" that the
server can correctly map to an identity) early in the exchange.>>>
4.2.1.2 Dynamic Addressing
The client will almost always have a dynamic IP address, while the
RAS will have a fixed IP address.
<<<The protocol design (e.g. state management) needs to consider
rapid disconnection/reconnection events, where one client
disconnects and gives up its (outside, or phase 1) IP address, and
the next client grabs that same address.>>>
There may be one or more NAT devices between the client and the RAS.
If an internal address is assigned to the client, there should not be
any need for the RAS to perform NAT translation on the traffic that
is sent to/received from the IPsec tunnel.
While the typical remote access case involves establishing a single
IPsec tunnel between the client and the RAS, over time there will
become a need for multiple IPsec tunnels between the client and the
RAS, for separate handling of multimedia vs. standard file
transfer/web/login traffic. Depending upon the characteristics of the
traffic, this may call out a need for fast tunnel establishment
("fast" in this case is expanded to also mean low delay). Such
traffic may also need to be separately protected (e.g. via stream
ciphers instead of block ciphers).
<<<Extensions to the IPsec (now known as phase 2) parameters are
needed in order to negotiate QoS characteristics for the various
tunnels.
QoS increases the probability of multiple tunnels between a client
and a RAS. Also, negotiation of IPsec tunnels needs to accommodate
QoS information, predominantly in the set of selectors used to
identify the contents of any particular IPsec tunnel.>>>
Madson Expires - September 2002 [Page 12]
Son-of-IKE Requirements March 2002
The remote access scenario generally involves downloading some 'per-
connection' policy from the RAS to the client. In general, this
information is associated with the bootstrapping of the client
connections (set of IPsec tunnels), such as the internal IP address
assigned to the client. There may be information associated with a
single IPsec tunnel out of the set (e.g. information on QoS settings
that the client could use for marking the traffic). Either the push
or pull model of policy distribution may be needed, depending upon
the scenario.
<<<This means that there must be a way of securely pushing down
this policy information before the IPsec tunnel is constructed.>>>
4.2.3 Security Characteristics
4.2.3.1 Authentication
Remote access is one of the major scenarios that isn't solely based
on mutual authentication.
In some scenarios, machine-level authentication in the client-to-
server direction may be sufficient (e.g. the authentication
information supplied by the client is sufficient for the RAS to grant
access to the protected network). In other cases, user-level
authentication is also required. This is primarily supplied via
legacy authentication mechanisms. User-level authentication could
also be done via user credentials that can easily passed in IKE phase
1 (e.g. x.509 user certs).
In the server-to-client direction, the client can use machine-level
authentication to validate that it is communicating with a desired
RAS.
In other scenarios, such as an Internet Kiosk, machine-level
authentication becomes meaningless; user-level authentication is
needed for the client to gain access to the protected network. In
this case, there is no equivalent server-to-client authentication.
Other considerations in terms of user-level authentication:
<<<The mechanism associated with such authentication should
accommodate re-authentication based on the RAS or authentication
server site security policy>>> (e.g. the local policy demands re-
authentication every 8 hours or the connection is torn down). If
out-of-band mechanisms are used for user-level authentication (ala
Madson Expires - September 2002 [Page 13]
Son-of-IKE Requirements March 2002
PIC), then the mechanism must somehow come up with a means of
supporting this requirement.
There should be some means of supporting asymmetric authentication
mechanisms for user-level authentication. Some consideration should
be made as to whether or not to support such mechanisms as one of the
base authentication mechanisms (e.g. what IKE would use for
authentication within phase 1).
A previous section discussed binding of the user-level authentication
with possibly multiple simultaneous IPsec tunnels between the client
and the RAS.
<<<Out-of-band authentication mechanisms must also consider the
location of the authentication server relative to the client and
the RAS. In many scenarios, server tends to be "behind" the RAS
device, in the domain that is being secured by the RAS, which may
be problematic for bootstrapping the user authentication for the
client-to-RAS connection.>>>
The client's SOI identity comes from some authentication information
supplied within the phase 1 exchange. Any identity supplied via out-
of-band user-level authentication may be useful in conjunction with
the connection, but it is not identity information as far as SOI is
concerned.
4.2.3.3 Identity Protection
In the case where the RAS is servicing multiple VPNs, the client may
need to leak all or part of its identity early within the exchange,
in order for the RAS to know how to act to the client (e.g. which
policy and which server identity). Hiding the identity of the RAS may
or may not be required.
4.3 End-to-End Security
[The requirements associated with IP storage are spelled out in
another section.]
What this scenario attempts to describe is the characteristics
associated with the common end-to-end scenarios. The primary
Madson Expires - September 2002 [Page 14]
Son-of-IKE Requirements March 2002
definition of end-to-end here is that the traffic sourced by/destined
to a pair of nodes is secured by those nodes.
This scenario can be subdivided into at least two different
scenarios, the first being the more classical case of "user-to-
services", such as an IPsec connection securing an rlogin session
between two workstations. The other class of scenario is associated
with securing infrastructure traffic, such as a network management
path between the management station and the router, or for router-to-
router control traffic.
4.3.1 Operational Characteristics
4.3.1.1 General Description
An IPsec "connection" is used to secure traffic between the two IP
endpoints for that traffic. The granularity of the connection may be
as fine as an individual socket, or as gross as all traffic between
the two systems. If multiple connections exist, they can have the
same or different protections. The IPsec connection can operate in
either tunnel or transport mode.
4.3.1.2 Dynamic Addressing
End systems may have static or dynamic addresses.
The IPsec connection may undergo NAT translation. The traffic within
the IPsec connection most likely will not be NAT'd.
In the end-to-end model, what is the chance of needing different
tunnels between a pair of end systems to support traffic with
different QoS characteristics? For example, will a given system
service both file transfer and multimedia traffic? If so, there would
be a need for separate IPsec tunnels.
Depending upon the characteristics of the traffic, this may call out
a need for fast tunnel establishment ("fast" in this case is expanded
to also mean low delay). Such traffic may also need to be separately
protected (e.g. via stream ciphers instead of block ciphers).
Madson Expires - September 2002 [Page 15]
Son-of-IKE Requirements March 2002
<<<Extensions to the IPsec (now known as phase 2) parameters are
needed in order to negotiate QoS characteristics for the various
tunnels.
QoS may increase the probability of multiple tunnels between a pair
of end systems. Also, negotiation of IPsec tunnels needs to
accommodate QoS information, predominantly in the set of selectors
used to identify the contents of any particular IPsec tunnel.>>>
In general, the policy is a combination of static configuration and
dynamic policy (e.g. "secure this FTP connection").
4.3.3 Security Characteristics
4.3.3.1 Authentication
In many cases, machine-level authentication is sufficient.
In some cases, such as client-to-server connections, user-level
authentication may also be necessary. User-level authentication via
legacy mechanisms is currently outside the scope of IKE. However, it
may be desirable to have such user authentication happen before IPsec
connections could be established, similar to what happens in the
remote access scenario. User-level authentication could also be done
via user credentials that can easily passed in IKE phase 1 (e.g.
x.509 user certs).
Whether or not there are static IP addresses, in this scenario the
identity is not normally tied to IP address, but to something like an
fqdn or user-at-fqdn identifier.
4.3.3.3 Identity Protection
<<<Hiding the identity of both parties in the exchange is
desirable.>>>
Madson Expires - September 2002 [Page 16]
Son-of-IKE Requirements March 2002
4.4 IP Storage
The IPS working group is addressing the various issues associated
with using storage protocols over IP. The primary protocols in
question are iSCSI, iFCP and FCIP, along with support protocols SLPv2
and iSNS.
[Abob01] does a very thorough job of describing the security
scenarios and requirements for these protocols. While this section
will attempt to highlight some of the key items, the reader is
strongly encouraged to read the document. The documents within the
IPS working group that describe requirements take precedence over
anything described in this document.
4.4.1 Operational Characteristics
4.4.1.1 General Description
iSCSI is a client-server protocol that runs over TCP and is used to
access disk, tape and other devices. iSCSI sessions between a given
Initiator (client) and Target (server) are run over one or more TCP
connections between those entities. A single connection is used for
both control and data, and is secured with its own IPsec tunnel.
iFCP is a gateway-to-gateway protocol, which provides Fibre Channel
fabric services to FC devices over a TCP/IP network. The primary
objective is to allow interconnection and networking of existing FC
devices at wire speeds over an IP network. An iFCP session runs over
a single TCP connection, which is secured with its own IPsec tunnel.
FCIP is a pure FC encapsulation protocol that transports FC frames.
The primary objective is to allow interconnection of FC switches over
TCP/IP networks. An FCIP session runs over one or more TCP
connections, with each connection being secured with its own IPsec
tunnel.
Neither iFCP nor FCIP have any security services. iSCSI has a text-
based authentication login mechanism that can provide mutual
authentication, however, it has no means to support packet-by-packet
security.
iSNS provides for discovery and management of iSCSI and iFCP storage
devices. An iSNS server keeps track of device attributes and monitors
availability and reachability. iSCSI and iFCP clients can use iSNS
for discovery (and possibly management). Connections between iSNS
clients and servers must be secured via IPsec.
Madson Expires - September 2002 [Page 17]
Son-of-IKE Requirements March 2002
SLPv2 provides for a way for iSCSI and FCIP to discover peer entities
and management servers. SLPv2 may also be used to provide information
on peer security configuration. It is strongly encouraged that this
protocol be secured via IPsec.
<<<[Abob01] discusses resource constraints, calling out the size
for both code footprint and data as the most important criteria.>>>
Entities may choose to terminate security associations in order to
save memory, restarting them on an as-needed basis.
4.4.1.2 Dynamic Addressing
iSCSI systems may use static or dynamic addressing. iFCP and FCIP
systems will use static addresses.
iSCSI connections may be NAT'd. iFCP and FCIP connections cannot be
NAT'd.
[Abob01] has no mention of QoS.
Security policy may be statically configured on the devices. The
devices can also choose to use iSNS or SLPv2 for discovery of nodes.
4.4.3 Security Characteristics
4.4.3.1 Authentication
iSCSI has an in-band login authentication mechanism, which provides
mutual authentication. This will provide user authentication, which
can be associated with one or more connections. [Abob01] calls out
using SRP for the specific authentication mechanism.
Neither FCIP nor iFCP have any in-band security, so both protocols
will rely on IKE for authentication. Mutual authentication is
required.
Madson Expires - September 2002 [Page 18]
Son-of-IKE Requirements March 2002
iSNS will use IKE authentication (e.g. machine-level only). Mutual
authentication is required.
SLPv2 will use IKE authentication.
<<<However, the discussion in [Abob01] calls out requirements for
an API, in order to provide a means of pushing authentication
information to the application (e.g. "this peer was authenticated
with this cert"), so the application can decide what types of
transactions are allowed by this peer.>>>
FCIP and iFCP must use IP addresses as identities for IKE
authentication. The other protocols need to use identities other than
IP addresses for authentication.
4.4.3.3 Identity Protection
There is no requirement that the identities used by FCIP and iFCP be
kept confidential. It is recommended that the other protocols use
identity hiding.
4.5 PPVPN/MPLS
A PE (Provider Edge) device can support one or more VPNs. If a PE
supports multiple VPNs, it has internal logic (commonly known as VRF,
or VPN routing and forwarding instance) that maintains data
separation between VPNs. A CE (Customer Edge) device resides in one
or more VPNs. What this means is that two or more PEs supply the
transit network for a collection of CEs representing a customer
network.
There are various proposals in this general space, which will be
outlined below. [Future versions of this draft should flesh out the
scenarios in greater detail.]
4.5.1 PE-to-PE IPsec
[Rose01] proposes a means of using IPsec to secure RFC2547 VPNs. The
outer MPLS label of a VPN packet is replaced with an IPsec
encapsulation, allowing the VPN packets to be carried over non-MPLS
networks (this is to allow traversal over a mixed cloud of both MPLS
Madson Expires - September 2002 [Page 19]
Son-of-IKE Requirements March 2002
and non-MPLS-aware routers, or where the transit network traverses
multiple administrative domains).
[Rose01] introduces the concept of using a new BGP attribute, "IPsec
Extended Community", which will help indicate which traffic flows
need protection. The encapsulation into MPLS and encapsulation by
IPsec is viewed as an atomic operation. However, that may not be
feasible in certain implementations.
<<<it may make sense to expand the set of phase 2 identifiers to
also support an MPLS/VPN identifier (so the entity doing the SPD
check can be separated from the entity doing the encapsulation).>>>
[Decl01] is another proposal for securing RFC2547 VPNs, however, it
makes several special demands on the IPsec processing, including
reserving part of the SPI for signaling special context. [Part of the
stated goal here is to have "IKE negotiate SPI-pools, so that
multiple SPIs point to the same SA".] This will most likely collide
with other mechanisms that systems use to internally subdivide the
SPI space, such as associating a range of SPIs with an instance of a
crypto engine on a system with multiple crypto engines. The SPI
allocation should be a local matter, and there shouldnÆt be any
external meaning applied to the SPI values. [RFC2401 says basically
the same thing.]
4.5.2 CE-to-CE IPsec
In this scenario, the IPsec tunnels are set up between the CE
devices. To a large extent, this scenario is the same as the site-to-
site scenario; the fact that the cloud in between is an MPLS or other
VPN is immaterial.
5. Other Problem Areas
5.1 Mobile IP/Wireless
There are several facets to mobility, some which will be mentioned
here. The issue of handling changing addresses will be discussed in
another section. [A future version of this draft should try to
identify and spell out the primary scenarios in more detail. But no
doubt there are NATs somewhere in the picture ;-).]
The general characteristics here include a desire for a small number
of messages. Short messages are also desirable, but in some scenarios
the # of messages is a much greater issue than the message size.
Madson Expires - September 2002 [Page 20]
Son-of-IKE Requirements March 2002
5.1.1 Fast Handoff
One area where IPsec may be used is in securing the access between
the mobile node and the "wireless" (wireless here simply means "not
wired", as opposed to any particular technology) access node
(sometimes also known as "access router"), in lieu of a mechanism
such as WEP. In some sense, the access node could be considered the
equivalent of an RAS.
The SEAMOBY working group is discussing issues associated with fast
handoff between access nodes, which happens as the mobile node moves
from one access node to another one. Depending upon the networking
characteristics, in certain cases new connections can be established
before existing ones terminate (make-before-break), while in others,
the new connection cannot be done until after the existing ones
terminate (break-before-make). [It is possible for the MN to acquire
a new IP address during the handoff as well, and the handoff has to
somehow also resolve the fact that the IP address of the access node
is also changing.]
One of the pieces to be handed-off would be IPsec context. The
general sentiment is that setting up a new connection from scratch
using either IKE or KINK has the problem of long latency and
excessive signaling during handover [SEAM01]. [SEAM01] proposes a
mechanism for transferring IPsec (but not IKE) state between access
nodes.
However, [SEAM02] claims that there are a lot of additional issues
associated with context transfer, and the scenarios aren't as simple
as claimed by the earlier document. Those authors present an
alternative in [SEAM03].
It isn't clear from any of these documents what is considered an
acceptable (total) delay for fast handoff, <<<but a mechanism that
could rapidly establish connections with new systems could provide
an alternative to the complexities associated with handing over
security state between machines.>>>
5.1.2 Securing Binding Updates
Since this is an issue under active discussion, this section does not
attempt to fully reflect the consensus, if any.
The initial philosophy was that Binding Updates - - notifications from
the mobile node to the correspondent node that the mobile nodeÆs
current address is changing -- would be secured using IPsec. While
Madson Expires - September 2002 [Page 21]
Son-of-IKE Requirements March 2002
that is still a goal, the lack of a universal authentication and
authorization infrastructure makes it a difficult one to achieve
(although it would still be usable in smaller domains).
The bulk of [Thom01] proposes a non-IPsec mechanism to work around
the general problem.
However, [Thom01] does state that even without a ubiquitous PKI, that
at least some of the binding updates (e.g. between the home agent and
the mobile node, which should already have exchanged certificates, or
some such event, before the MN left itÆs home network) must be
secured using IPsec.
Ignoring the PKI issues associated with the above, it is assumed that
the rate of binding update messages sent from a mobile node to its
correspondent nodes is based upon the frequency of new IP address
assignment (rate of movement of the mobile node, topology of the
network that the MN is traveling through, etc.).
Most likely fast setup will be desirable for this scenario.
5.2 Multiple and Changing Addresses: IPv6, SCTP and MobileIP (and NAT?)
This section isnÆt discussing all of the associated requirements of
the above protocols; it is focusing on the idea that there are
multiple protocols which can support more than one address per
endpoint and/or that have addresses that can (sometimes rapidly)
change.
IPv6 allows for multiple addresses per "interface"; the common one
being in terms of scoped addresses: link-local, site-local, and
global (with possibly more than once instance of any particular
type). It is desirable that "connections" survive across renumbering
(although it isn't clear whether that has been codified yet). In
general, the frequency of renumbering should be low.
SCTP allows for multiple IP addresses to be associated with an
endpoint, where these addresses can be added/removed on the fly. The
frequency of updates depends upon where/how SCTP is used.
Mobile IP nodes may have to pick up different IP addresses while the
node is moving (this is supposedly more common as the node enters a
new administrative domain, or if the node is migrating from one media
to another, e.g. 802.11 to cellular). The expectation is that any
connections that the node had with its remote peer (e.g. CN)
Madson Expires - September 2002 [Page 22]
Son-of-IKE Requirements March 2002
shouldn't terminate simply because of the use of a new IP address.
[The connection to an access node is outside the scope of this
section.] The frequency of renumbering is based upon the speed of
travel and the topology of the mobile network(s) that the node is
traveling through.
NAT devices will force an address translation, and if the translation
state in the NAT devices is allowed to age out, the next packet may
force a different translation.
While in (at least) most of these cases, address rollover can be
accommodated by simply setting up new SOI/IPsec connections at the
appropriate time, it does represent an expense. And if the frequency
of change is high enough, the expense may be unacceptable.
Apart from an I-D that discusses how to handle SCTP identifiers
within SOI, and various and sundry NAT-related discussions, there
hasn't been a lot of discussion in the IPsec WG about the general
theme of <<<supporting multiple and/or changing addresses in the
context of a single secure connection.
While it may be too much to expect all of IPsec to handle changing
addresses (e.g. changes to outside addresses), one possibility is
to design SOI in such a way that a phase 1 could survive changes in
addresses, but set up new phase 2 connections when addresses
change. [How one would do this would obviously need further
analysis.] The use of the two-phase approach here could help to
alleviate the expense associated with setting up new connections in
the face of renumbering.
SOI should also accommodate sets of identifiers within a phase 2
exchange. This is needed for supporting SCTP. Also, the negotiation
of a multi-entry phase 2 identifier can help to greatly reduce the
number of IPsec tunnels between systems that need to secure
multiple traffic flows in a similar manner.>>>
5.3 Delay-sensitive Applications
Certain classes of traffic do not tolerate delay very well.
Addressing the delay (or probably more the delay's jitter) associated
with data flowing through an IPsec tunnel is outside the scope of
this document, except to indicate that such delay-sensitive flows may
need their own IPsec tunnels for QoS purposes, even if other IPsec
Madson Expires - September 2002 [Page 23]
Son-of-IKE Requirements March 2002
tunnels exist between the two endpoints. These tunnels may also be
secured differently, for example, using stream ciphers instead of
block ciphers.
There are also applications (e.g. VoIP) that are sensitive to the
delay associated with connection setup, where setting up an IPsec
tunnel is only one part of the total setup.
KINK has a mechanism that attempts to address this issue. The IPsec
WG should consider whether or not the SOI protocol should also
consider this scenario.
The overriding characteristic here would be for the protocol exchange
to run as fast as possible, including performing the necessary
authentication. [KINK also assumes that certain devices find it too
expensive CPU-wise to run DH and RSA and play with certs.]
In the case where the two nodes are running a single application
(such as VoIP), it could be argued that the two-phase exchange is too
expensive. However, if the nodes are running video in conjunction
with voice, the cost of a phase 1 could be amortized over the two (or
more) IPsec tunnels.
5.4 Other Users of IPsec
The above list isnÆt intended to be an exhaustive one regarding every
possible protocol that is considering using IPsec. The intent was to
both call out primary scenarios, and identify other possible
scenarios that have special requirements.
One such example of "another user" is LMP, which is an optical link
management protocol. [Rama01] describes the use of IPsec with LMP,
but does not call out any special requirements. [One might assume
that fast connection establishment would be a criterion for this
protocol.]
6. General Operational Requirements
6.1 Scalability
IPsec will be deployed in end systems, security gateways and RAS
devices.
Madson Expires - September 2002 [Page 24]
Son-of-IKE Requirements March 2002
The number of simultaneous SAs for an end system/client will be quite
a bit smaller than the number of simultaneous SAs that need to be
supported by an intermediate system SGW or RAS.
While a low-end end system may need a lightweight mechanism in order
to save precious memory/CPU/etc. for other functions, larger
intermediate systems also need lightweight mechanism in order to
sustain a reasonable number of connections. In other words, whatever
the cost is for a single connection, that cost needs to be multiplied
by several tens to thousands of times, depending upon the capacity of
the intermediate system.
This especially becomes important in the crash/restart scenario,
where the intermediate system might get hit with a flurry of new
negotiation requests from the remote IPsec peers.
The expense of processing the new negotiation requests includes a
cost based on number of messages and amount of processing. Costs
associated with authentication also need to be accounted for in this
calculation.
At the same time that the system is processing a large number of new
connect requests, it is also receiving traffic/control messages based
on the IKE/IPsec SAs that had been in place prior to the crash. [The
system should not use this traffic as hints to create new SAs, due to
the DoS risk as discussed in a later section.]
Besides the costs associated with connection setup, there are costs
in terms of maintaining the connection. While connection maintenance
has cost, it must be weighed against the cost of "no maintenance".
One such example is the use of a dead peer detection mechanism; while
it isnÆt cost-free, the operational costs associated with black-
holing traffic will outweigh the costs of keeping the connection
"alive".
Costs associated with connection state are also important, whether in
a low-end system with a small footprint or a large intermediate
system supporting many connections. [Abob01] calls out a requirement
for a small code and data footprint; the application may choose to
terminate IPsec tunnels which arenÆt currently active, in order to
save on resources.
6.2 Fast setup
Madson Expires - September 2002 [Page 25]
Son-of-IKE Requirements March 2002
In many cases, fast setup is a desirable, but not critical goal. Its
importance increases in the following scenarios:
. RAS or SGW or other server terminating lots of connections
. SGW crashing and restarting, requiring reestablishment of prior
connections
. Applications which are sensitive to delays in connection setup
. Mobile nodes which frequently move
o A sufficiently fast setup might be an alternative to complex
IPsec context transfer for fast handoff scenarios.
A definition of "fast"in this context means:
. Optimal combination of "number of messages" and "computational
expenditure".
. Low delay where possible. For the scenarios that are delay
sensitive, this means that the cost of the "other pieces" tied
to the exchange, such as validation of authentication
information (e.g. communicating with a PKI or Kerberos server or
whatever), need to be kept in mind.
6.3 One-phase vs. two-phase exchange
SOI will need to negotiate a protected tunnel for its own
communication, as well as the IPSec protected tunnels. These tunnels
may be negotiated simultaneously or sequentially, and the SOI tunnel
may be either short term (for the duration of the IPSec tunnel
negotiation) or long term. The decision on how this is handled
affects:
. Setup time, number of messages, delay
o There is a requirement that a second IPSec tunnel between
two peers be a less costly operation.
. Separate tunnels between IPsec peers for different
traffic flows
. Non-contiguous addresses/subnets
. QoS
. Securing individual UDP sockets between L2TP LAC
and LNS
. Securing individual TCP sockets for IPS sessions
. Flexibility
o Negotiating the IPSec tunnel separately from the SOI tunnel
may allow user authentication to be done under the
protection of the SOI tunnel.
. A long term SOI tunnel may ease sending notify messages, such as
changing ID values, notifications of tunnel teardown, or
keepalives. Without such a long term tunnel, the establishment
of a short term tunnel may need to be very fast, or alternate
mechanisms would need to be proposed.
o Simplicity
Madson Expires - September 2002 [Page 26]
Son-of-IKE Requirements March 2002
o Reducing the number of types of exchanges (e.g.
Phase1/phase2 combined versus a separate phase 2) should be
considered a benefit.
An analysis is needed of what is appropriate to perform under the
protection of a phase 1 exchange, besides rekeying events and
error/notify messages.
However, future additions of new phases to the protocol (ala phase 0,
or phase 1.5, or "first phase 2") should be strongly discouraged.
Shoehorning in new phases is the most difficult (if not impossible)
thing to do cleanly, and it is difficult for any protocol design to
accommodate such events in an extensible manner.
Any issues associated with NAT traversal also need to be considered
in the context of one vs. two phases.
7. Protocol Requirements
7.1 Protocol Interaction
There needs to be an analysis of the types of protocols required in
the SOI framework, and how they interact. For example, in the RAS
scenario three protocols may be required in order to provide a useful
solution: a legacy authentication protocol, a policy push protocol,
and an IPsec negotiation protocol. Defining an order, and possible
interactions between these protocols is necessary. Other scenarios
will have similar predicaments.
7.2 Identity
Identity cannot practically be based off of IP address, due to the
prevalence of NAT devices in the network, and the use of dynamically-
assigned IP addresses.
<more detailed identity discussion to followà>
7.3 Interaction with NAT
At some point in the future, NAT devices may disappear. Until that
point, there is a need for SOI to interact with both IPsec-aware and
non-IPsec aware NAT devices.
Madson Expires - September 2002 [Page 27]
Son-of-IKE Requirements March 2002
Regardless of how addresses and identities, etc., may be handled in
SOI, there is a known issue of NAT devices not handling fragments
very well.
7.4 General Protocol Design Criteria
Describing the scope of SOI is one of the primary goals of this
document. To accomplish the goal, this document needs to (over time):
. Identify key scenarios that need to be accommodated within the
new design.
. Describe what problem spaces SOI will (and won't) try to solve.
No single protocol can solve the worldÆs problems.
. Describe at a high level what needs to be done within the scope
of the SOI protocol and what can be done via out-of-band
mechanisms. [Any such mechanisms need to be defined in the same
timeframe as SOI. Also, SOI must define the core requirements
for the mechanism.]
7.4.1 Modularity
It is also important to encourage the use of functional modularity
within the protocol. Since in some scenarios the answer is to not
mutate SOI to handle that problem set, there is a need for building
blocks for others to use. Such well-defined functional components
(where the definition includes what is required by the component and
what the component will generate/perform) will allow other groups to
pick up these components for their own use (e.g. picking up the
components that meet their needs and use them in conjunction with
components that they develop - - or borrow from elsewhere).
Such functional modularity can also help in terms of understanding
and evaluating the protocol.
7.4.2 Extensibility
Another important protocol design goal is ease of extensibility.
While it is important to maintain control over the scope of SOI, a
protocol that is difficult to extend when necessary is effectively a
dead protocol. SOI must be extensible to a practical degree.
Extensibility has several facets to it:
. Handling of new payloads, field values, exchanges, etc.
o Mechanism to easily add such values.
o Capability to flag these values in such a way that the
receiver can understand how to process unrecognized values.
Madson Expires - September 2002 [Page 28]
Son-of-IKE Requirements March 2002
o New values must be evaluated relative to ones currently
existing. If the new values impact other parts of the
existing protocol, this must be documented.
. Mechanism for specifying variants that are very close to the
base SOI protocol (e.g. what is currently provided via the
ISAKMP DOI). Other active DOIs include
o Group Domain of Interpretation (from MSEC)
o MAPSEC DOI
. Full hashing of SOI packets, in order to protect new values.
. Analyze current fields to decide appropriate behavior for
handling unrecognized values. SOI must spell out the behaviors.
7.4.3 Protocol Convergence
Another important criteria for protocol design is the area of
protocol convergence. It is important for a protocol to behave in a
predictable manner, even in the face of retransmissions, lost
packets, receipt of invalid packets or payloads, loss of
communication between peers, the administrator reinitializing one or
more security connections on one machine, etc.
It is especially important that once an exchange starts, that the two
SOI peers have a very similar view of the state of the connection
between them. It is also important for the behaviors to be well
understood, so that the implementers can make sure that they have
implemented the protocol correctly.
These needs can be addressed by various means:
. Reasonably complete documentation of the protocol state machine
o Analyze error conditions and document such analysis and
document behaviors
o Base protocol must specify all pieces needed to ensure
convergence
. Detecting and handling loss of communication with IKE peer
. Fully spelled-out definition of rekeying behaviors (including
error analysis)
. "Guaranteed" notify/delete messages (this assumes continued
communication between peers).
. Documenting errors, especially if it results in a state change
to the peer. Especially if it involves sending an error message
to the peer. Documenting what the peer needs to do upon receipt
of the error message.
. Negotiation matching rules must be spelled out.
. New (extension) specifications must perform and document
analysis, including impact on existing protocol behaviors.
When meditating on analyzing protocol convergence, it is recommended
that [Spen01] be read. This document does a good job of describing
Madson Expires - September 2002 [Page 29]
Son-of-IKE Requirements March 2002
some of the protocol issues associated with IKEv1; some of these
items are still pertinent for SOI.
An important scenario to be addressed in the analysis: state
management needs to consider rapid disconnection/reconnection events,
where one client disconnects and gives up its (outside, or phase 1)
IP address, and the next client grabs that same address.
7.4.4 Simplicity
Protocol simplicity is another goal. Besides getting rid of
unnecessary fields/exchanges, etc., and keeping in mind the other
protocol design goals above, simplicity can be addressed by other
facets:
. Ease of accomplishing a particular function (simple negotiation
model as is seen in IKE may make it hard to successfully
negotiate with a peer - - if successful connectivity is a goal --
without a fair amount of a-priori knowledge, because of the
sheer number of possible combinations of what needs to be
negotiated).
o This can be alleviated by having fewer negotiable
pieces/attributes
o This can also be alleviated by creating and using so-called
"negotiation suites", which represent well-known groupings
of settings
o This can also be alleviated by modifying the negotiation
model to be something other than a "take it or leave it"
proposition.
8. Policy Requirements
8.1 Provisioning and Management
8.1.1 Configuration
In general, provisioning is viewed as æædefining a topology,
generating a configuration, and distributing it to the network
devicesÆÆ, and then æægenerating and distributing configuration
updatesÆÆ. In the case of IPsec, this information includes security
policy (criteria it will use to decide whether or not to communicate
with a remote peer, and how that communication will be
protected/authenticated/etc.).
In order to support this in a heterogeneous environment, there is a
need for:
Madson Expires - September 2002 [Page 30]
Son-of-IKE Requirements March 2002
. A common distribution mechanism (which also addresses
interacting with systems which have dynamically-assigned
addresses).
. A common representation model for configuration entities
(understood by the devices performing the provisioning) and data
(understood by the provisioned devices)
. The model must also address the issues associated with changing
addressing and dynamic policy instantiation associated with an
application (for example, itÆs hard to secure an H.323
connection when it isnÆt possible to a-priori know the socket).
These mechanisms are completely outside the scope of SOI. However,
the distribution mechanism and representation model should be
relatively lightweight in order to make it useful for smaller
deployments.
To some people provisioning also represents dynamic mechanisms such
as discovery. One such example is in the Provider-Provisioned VPN
(PPVPN) space, which is working on dynamic mechanisms for discovery
of VPN peers and signaling of which peers support which traffic. Two
alternative proposals take slightly different approaches:
. Using BGP extensions to communicate both peers and traffic flows
supported. [Rose01] and [Decl01].
. Using DNS for discovering the VPN peers, and using signaling (as
yet unspecified) between the peers to determine which peer
supports what traffic [Luci01].
Mechanisms like the above are also outside the scope of SOI, but the
IPSP WG should survey mechanisms that are being considered within
other WGs while it considers the issue of policy discovery. [While it
would be very beneficial for IPSP to develop a standardized discovery
mechanism, such a mechanism wouldnÆt be required to be used in every
scenario, for example, IPS has special mechanisms [Abob01] tailored
for itÆs environment which should be used as appropriate.]
8.2 Expanding the set of selectors
This section and the next one talk about the traffic flow descriptors
(e.g. phase 2 IDs).
To a large extent, the SPD is a form of a packet classifier.
Unfortunately, what is negotiated via an IKE phase 2 exchange is a
single instance of a traffic filter entry.
Madson Expires - September 2002 [Page 31]
Son-of-IKE Requirements March 2002
This has multiple issues associated with it, but the biggest one is
scaling. Even if there is a desire to secure multiple non-contiguous
traffic flow descriptors between the same two IPsec endpoints using
the same security characteristics, it is not possible to bind these
all together; individual SAs must be negotiated for each flow
descriptor. A pair of SGWs that are supporting a large number of
traffic flows between them are forced to negotiate independent SAs.
[While in certain cases separate SAs are desirable, there is no
alternative with the current mechanisms.]
The next section discusses a couple of alternative proposals for this
issue.
Adding to the list of possible selectors is also desirable.
One such example is to include some QoS designators (e.g. Diff-Serve
Code Point, etc.), so that separate IPsec tunnels could be created
for separate QoS "levels".
Another example is VPN tags. The PPVPN section had a discussion of
using IPsec to encapsulate VPN-tagged packets so they could traverse
a mixed cloud. [Rose01] talked about the VPN tagging and IPsec
encapsulation as almost an atomic operation, but that won't be
practical in certain deployments. Adding filtering on a VPN tag
allows has two advantages: separation of tagging and IPsec, and
requiring only a single SA bundle to be associated with the tag,
instead of either separate SAs - - one per classical phase 2 ID filter,
or attempting to negotiate and bind the various flows together with a
single SA.
8.3 SPD traffic flow descriptors and dynamic policy
There has also been a strong desire with some applications such as
SCTP [Bell01], to support lists of traffic filters, where entries
could be added to/removed from the list on the fly. In this model,
the SA bundle instance may over time support different traffic flows.
[SCTP also talks about changing phase 1 identifiers; that point will
be covered in a later section.] This allows for a model where
traffic flows that (should) have the same fate to share the same SA.
Besides SCTP, there are other protocols that dynamically discover
what needs to be secured via the protocol exchange itself. [RFC3193]
discusses such a mechanism for L2TP, which requires the creation of
new IPsec SAs in the case of "port floating". [Of course, in the case
of address floating, both a new IKE and IPsec SA will probably be
Madson Expires - September 2002 [Page 32]
Son-of-IKE Requirements March 2002
required, but thatÆs because the client is now talking to a different
device.]
Forcing each protocol that has "floating port" requirements to come
up with their own mechanism to get around the fundamental constraint
results in a lot of unnecessary complexity.
[Sris01] introduces a general mechanism for constructing traffic
filter lists, which also allows for individual filters to be
added/removed from the list.
Negative entries might also be useful in that they might help to
reduce the size of the list (e.g. "secure everything between subnet A
and subnet B except <foo>"). However, they would add to the
complexity and should be approached with caution.
Regardless of the mechanism used, there needs to be a determination
of how to handle the case of "the responder is willing to accept only
a subset of the initiatorÆs list".
8.4 Retaining SAs in face of address changes
There are various scenarios where one end node may have its address
change during operation. The most obvious one is MobileIP, where the
rate of address change can be frequent. Another scenario is IPv6,
where a node may have its global address renumbered at any time (at
least thatÆs the philosophy).
In the classical scenario, this tends to result in a rekeying of IKE
and IPsec SAs between the mobile node and the systems it communicates
with, even if nothing else has changed. Even worse, this renumbering
can happen in the midst of a rekey, causing even more confusion.
When the rate of address change is frequent enough, this rekey
overhead can quickly become very expensive.
While NAT can be considered another scenario in this class, it has
the problem that the address change (NAT translation) goes on without
the knowledge of the system that has its address translated.
[Ignoring NAT discovery mechanisms being discussed for IKE.] Still,
it would be highly desirable for any solution to address this as
well.
One possible idea has two (main) parts (meant for illustrative
purposes only; no analysis has been done on this, not warranted for
merchantability, etc., etc.):
Madson Expires - September 2002 [Page 33]
Son-of-IKE Requirements March 2002
. SOI state management must keep connection state based on phase 1
identities, regardless of the IP addresses in use.
. When a change to an IP address has been detected, it must be
communicated to IPsec and/or SOI where appropriate. SOI as
appropriate will notify the peer of the change.
8.5 Distribution of authentication information
Another piece of the provisioning puzzle is making authentication
information available in a scalable manner. [This was in a note
somewhere, but I donÆt recall what the main point was supposed to be
here.]
8.6 Authorization
<text to be supplied laterà>
8.7 Additional "per-connection" policy
This is more typical in the remote access scenarios, where the client
needs additional information either during connection establishment
or after it completes.
This information can be grouped into two classes:
. Applying to all IPsec tunnels for that connection
o Inside address (assigned by RAS so it wonÆt have to NAT the
traffic coming out of the tunnel).
o Location of DHCP, etc. servers
. Applying to specific IPsec tunnels for that connection:
o QoS settings
o Other?
While there are various proposals, such as using MODECFG or DHCP to
communicate this information, neither one of them is necessarily
flexible enough. In order to subdivide the problem, the above
mechanisms should be use to get the minimal initial information (e.g.
inside address), and IPSP should consider another mechanism to
communicate the other information from the server to the client.
9. Security Requirements
9.1 Key Agreement
Madson Expires - September 2002 [Page 34]
Son-of-IKE Requirements March 2002
The fundamental premise of IKE was that it used Diffie-Hellman for
key agreement, combined with a variant of the Station-to-Station
protocol (by ???) for preventing man-in-the-middle attacks against
the key agreement mechanism. This key, or "shared secret", would
then be used in generating keying material to secure the IKE phase 1
and IPsec tunnels.
The pluses of such a mechanism are that itÆs well understood and
evaluated. The minus is that it is computationally expensive, making
it an important issue in terms of defending against Denial of Service
attacks. In some scenarios, it is also considered to be too expensive
in general - - such a philosophy has resulted in the specification of
KINK.
Still, the current sentiment is that this represents the best
mechanism for key agreement.
9.2 Key Generation
The base protocol spec must spell out the core key generation
requirements, including discussing such issues as "key strength", and
requirements for the amount of entropy associated with various
inputs. It should spell out in great detail the various issues
associated with key expansion. The core requirements, along with the
algorithm-specific requirements (e.g. a specification of an instance
of a PRF), should be sufficient for someone unfamiliar with the
protocols to perform an evaluation.
9.3 Authentication
IKE allows for various authentication mechanisms. However, their
specifications are incomplete (such as the one associated with the
use of X.509 certificates). Another complaint has been that the
specification is biased towards X.509 w/PKI and discourages the
development/deployment/use of other mechanisms.
The core draft should spell out the requirements for authentication
as it affects SOI, such as how the authentication values do/donÆt
fold into the key generation process.
The core draft should also document one least common denominator
authentication mechanism (the current sentiment is to use RSA key
pairs and distribute the public key to the peer systems via an out-
of-band mechanism). This core mechanism must be fully specified,
including discussing distribution/verification of the authenticator
value, how this value is used in the exchange, authentication
validation rules, and other protocol support needed for this
mechanism.
Madson Expires - September 2002 [Page 35]
Son-of-IKE Requirements March 2002
Each other mechanism is in a separate draft, and must include a full
specification of the protocol and handling requirements. For example,
"if you want to do X.509 certificates, you must support these
payloads, you must support these encoding formats, you must send
these payloads at this point in the exchange, you must send
certificate chains that look like this, you must be able to support
certificate path discovery (or not), you must feed this blob into
SKEYID generation this way, you must enforce certificate lifetimes
and crls, the lifetime of a phase 1 SA cannot exceed the lifetime of
the certificate that is used to authenticate the exchange (or notà),
etcà.". [This previous list is an illustration, not a statement of
requirements.]. The document should also spell out if the particular
authentication mechanism implies a particular trust model.
Ideally, the set of possible mechanisms should not be constrained to
the ones that can fit into the number of messages within the normal
SOI exchange.
Over time, there has also been confusion with respect to user-vs-
machine authentication via IKE. Over time, it seems that the general
consensus has been that IKE provides machine authentication; part of
it has to do with the wide variety of user authentication mechanisms,
and whether or not they could be accommodated within IKE phase 1. If
this model holds, there may be a need for user authentication as a
part of SOI (and not just in the remote access scenario). At a
minimum, the base draft should specify that SOI supplies machine-
level authentication.
Another area of consideration involves asymmetric authentication. For
example, in a remote access scenario it might be desirable to have
the server authenticate to the client using a certificate, while the
client might authenticate to the server using a legacy authentication
mechanism.
9.4 Resistance to Denial-of-Service Attacks
While it is difficult to design a protocol that is completely secure
from DoS attacks against it (even ignoring the attack that simply
floods the media preventing the system from sending/receiving
traffic), there are certain things that should be done to alleviate
the vulnerability for DoS attacks.
As a rule, the primary tenants of DoS resistance involve making the
attacker do a certain amount of work before the system under attack
has to do any real work. The system under attack should not be forced
Madson Expires - September 2002 [Page 36]
Son-of-IKE Requirements March 2002
to keep much state, or to perform much processing, until it
determines that the peer system is alive and can sustain a protocol
exchange.
There are various mechanisms proposed to address these issues; these
include:
. Stateless cookies: requested by the responder, this forces the
requestor to sustain an exchange (the equivalent in IKE would be
that the attacker would have to do more than simply spewing out
a whole bunch of MM1 packets).
o Should this be mandatory (a part of every exchange) or
optional (on demand of the responder)?
. No reliance on unauthenticated messages that would force a
change in state. [Kryw01] discusses the scenario of relying on
unauthenticated notify messages, such as "invalid spi", to
decide to tear down existing SAs and force establishment of new
ones.
9.5 Resistance to Replay Attacks
The protocol must be resistant against replay attacks, without
requiring that the node keep large amounts of state (which can be
expensive both memory and processing-wise).
IKE had various proposals for addressing the issue (mostly centered
around message IDs), which may or may not be appropriate for SOI.
9.6 Resistance to downgrade attacks
The protocol must resist against an attacker trying to downgrade the
security of the exchange. IKE addressed this through including the
proposals within the data that was hashed.
9.7 Implementation Recommendations
[for lack of a better term]. There are certain design tradeoffs that
can be made in an implementation, commonly to improve performance
and/or to "improve" certain "behaviors". Some of these tradeoffs
actually have security implications. While it is difficult to guess
what any possible implementer might do, one of the outputs of a
security analysis should be a list of the possible implications, and
a set of implementation recommendations.
9.8 Use of Negotiation Suites
Madson Expires - September 2002 [Page 37]
Son-of-IKE Requirements March 2002
This has been an idea that periodically floats to the surface. The
general idea is that there are too many parameters (attributes) for
negotiation. The number of various combinations is huge. Also, since
anything can match with anything else, it is hard for folks to
evaluate the security properties. [In fact, the original suggestion
of suites came from the cryptographic community, in order to make the
feat of analysis feasible.]
While reducing the number of negotiable attributes can help a great
deal here, the idea of negotiation suites can still be helpful in
addressing the analysis issue.
However, in its security requirements discussion, IPS [Abob01] is
requiring that every single security mechanism must be able to be
"turned off" independently. Such an operational requirement would be
a counter-argument to the use of suites.
9.9 Identity Hiding
In general, identity hiding of both peers is considered desirable. In
practice, there may be scenarios where this isn't feasible.
According to [Kauf01], "whoever admits identity second can be
protected from active attacker". If the responder reveals his
identity first, he can be vulnerable to what is known as a "polling
attack", where the attacker is trolling for systems that will reveal
their identities. However, if the initiator reveals his identity
first, he can be vulnerable to being "tricked" into leaking his
identity to a party that it otherwise would have no intention of
doing so.
Also, in certain scenarios, such as where a RAS supplied by a service
provider is fronting several VPNs, it is necessary for the client to
provide some sort of identifying information early enough in the
exchange in order for the RAS to know which identity and which policy
to use when interacting with that client. In many cases, this
information does not need to be the client identity, but it should be
something that the responder can use to select itÆs own
identity/policy to use when communicating with the client.
At a minimum, the protocol needs to protect against passive attackers
when identity hiding is necessary.
9.10 Plausible Deniability
[Kauf01] discusses this concept, where the data was never signed, but
a third party may be able to prove that the conversation took place
Madson Expires - September 2002 [Page 38]
Son-of-IKE Requirements March 2002
between the two parties. [How much of this is solved via identity
hiding?]
9.11 Protection of Key Management Messages
IKE had partial authentication protection for key management
messages, in that it only hashed certain fields. The primary problem
in the base protocol was that the Commit bit was not protected, which
an attacker could exploit. The more serious problem is that there was
no means of securing any new payloads/fields, regardless of their
security criticality. While hashing fewer fields could be considered
ææfasterÆÆ, the gain in hash speed was offset by the processing
complexity.
SOI MUST protect all fields in all messages via the hash.
9.12 Support for PFS
There has been this long-running sentiment that PFS is a requirement
for security protocols. Certain proposals in the IETF's Security Area
in the past have been shot down because they didnÆt have this
characteristic.
The classical definition of PFS in the IETF is that both peers
generate new D-H pairs and calculate a new shared secret. In IKE,
there exists PFS for phase 1 (each new IKE exchange expects a new
shared secret) and optionally for phase 2 (where each new phase 2
could also calculate a new shared secret to be combined with the
phase 1 shared secret).
One of the recent items for consideration in front of the working
group is whether or not this definition of PFS could be changed for
SOI. At the time being, this seems to have appeal, but no strong
consensus.
10. Security Considerations
This document describes both requirements and other design
considerations that should be taken into account for developing a
follow-on protocol to IKE. The primary goal of the considerations is
to provide guidance for a protocol that is more easily understood/
evaluated in terms of security properties and behaviors.
Madson Expires - September 2002 [Page 39]
Son-of-IKE Requirements March 2002
11. Acknowledgements
Thanks to the various members of the IPsec WG whose comments over a
long period of time have contributed to the thinking that resulted in
this document. Thanks also to Brian Weis, Jan Vilhuber and Scott
Fluhrer for the various discussions and making many helpful
suggestions.
12. References
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997
[Abob01] Aboba, et. al, "Securing IP Block Storage Protocols", draft-
ietf-ips-security-09.txt, work in progress.
[Bell01] Bellovin, et. al, "On the use of SCTP with IPsec", draft-
ietf-ipsec-sctp-03.txt, work in progress.
[Decl01] De Clercq, et. al, "BGP/IPsec VPN", draft-declercq-bgp-
ipsec-vpn-01.txt, work in progress.
[Kauf01] Kaufman, Charlie, "Engineering Trade-offs in Authentication
Protocols", slides from IETF-53 presentation.
[Kryw01] Krywaniuk, A. "Security Properties of the IPsec Protocol
Suite", draft-ietf-ipsec-properties-01.txt, work in progress
[Luci01] Luciani, et. al, "Using DNS for VPN Discovery", draft-
luciani-ppvpn-vpn-discovery-01.txt
[Rama01] Ramamoorthi and Zinin, "LMP Security Mechanism", draft-
sankar-lmp-sec-00.txt, work in progress.
[Rose01] Rosen, et. al, "Use of PE-PE IPsec in RFC2547 VPNs", draft-
ietf-ppvpn-ipsec-2547-01.txt, work in progress.
[SEAM01] Hamer and Kosinski, "IPSec Context Transfer", draft-hk-
seamoby-ct-ipsec-00.txt, work in progress.
[SEAM02] Gopal, Krishnamurthi and Sengodan, "Issues in IPSec Context
Transfer", draft-gopal-seamoby-ipsecctxt-issues-00.txt, work in
progress.
[SEAM03] Gopal, et. al, "IPsec Context Transfer", draft-gopal-
seamoby-ipsec-relocate-00.txt, work in progress
Madson Expires - September 2002 [Page 40]
Son-of-IKE Requirements March 2002
[Spen01] Spencer and Redelmeier, "IKE Implementation Issues", draft-
spencer-ipsec-ike-implementation-01.txt, work in progress
[Sris01] Srisuresh and Vilhuber, "Policy Extensions to IKE", draft-
srisuresh-ike-policy-extensions-00.txt, work in progress.
[Thom01] Thomas, M., "Binding Updates Security", draft-thomas-
mobileip-bu-sec-00.txt, work in progress
13. Editor's Address
Cheryl Madson
<cmadson@cisco.com>
Cisco Systems, Inc.
The IPsec working group can be contacted through the chairs:
Barbara Fraser
<byfraser@cisco.com>
Cisco Systems, Inc.
Ted T'so
<tytso@mit.edu>
Massachusetts Institute of Technology
Madson Expires - September 2002 [Page 41]
