[Search] [pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00                                                            
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.


4.1.1.3  NAT

   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.

4.1.1.4  QoS

   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.>>>

4.1.2  Policy

   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.

4.1.3.2  Identity

   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

4.2.1.1  General

   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.>>>

4.2.1.3  NAT

   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.

4.2.1.4  QoS

   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


4.2.2  Policy

   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.>>>


4.2.3.2  Identity

   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.


4.3.1.3  NAT

   The IPsec connection may undergo NAT translation. The traffic within
   the IPsec connection most likely will not be NAT'd.


4.3.1.4  QoS

   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.>>>


4.3.2  Policy

   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).


4.3.3.2  Identity

   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.


4.4.1.3  NAT

   iSCSI connections may be NAT'd. iFCP and FCIP connections cannot be
   NAT'd.


4.4.1.4  QoS

   [Abob01] has no mention of QoS.


4.4.2  Policy

   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.>>>


4.4.3.2  Identity

   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.


8.1.2  Discovery

   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]