[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 RFC 5619

Network Working Group                                        S. Yamamoto
Internet-Draft                                               C. Williams
Expires: April 25, 2007                                    KDDI R&D Labs
                                                               F. Parent
                                                              consultant
                                                               H. Yokota
                                                           KDDI R&D Labs
                                                        October 22, 2006


              Softwire Security Analysis and Requirements
              draft-ietf-softwire-security-requirements-01

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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.

   This Internet-Draft will expire on April 25, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document provides the security Guidelines for the Softwire "Hubs
   and Spokes" and "Mesh" solutions.  Together with the discussion of
   the Softwire deployment scenarios, the vulnerability to the security
   attacks is analyzed to provide the security protection mechanism such



Yamamoto, et al.         Expires April 25, 2007                 [Page 1]

Internet-Draft      Softwire security considerations        October 2006


   as authentication, integrity and confidentiality to the softwire
   control and data packets.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Hubs and Spokes Security Guidelines  . . . . . . . . . . . . .  4
     3.1   Deployment Scenarios . . . . . . . . . . . . . . . . . . .  4
     3.2   Trust Relationship . . . . . . . . . . . . . . . . . . . .  6
     3.3   Softwire Security Threat Scenarios . . . . . . . . . . . .  7
       3.3.1   Softwire Blackhole Attacks . . . . . . . . . . . . . .  8
     3.4   Softwire Security Guidelines . . . . . . . . . . . . . . .  9
     3.5   Guidelines for Usage of Security Protection Mechanism  . . 10
       3.5.1   Softwire Security Protocol . . . . . . . . . . . . . . 10
       3.5.2   Authentication . . . . . . . . . . . . . . . . . . . . 11
       3.5.3   Inter-operability guidelines . . . . . . . . . . . . . 12
       3.5.4   IPsec filtering details  . . . . . . . . . . . . . . . 12
       3.5.5   IPsec SPD entries example  . . . . . . . . . . . . . . 12
   4.  Mesh Security Guidelines . . . . . . . . . . . . . . . . . . . 13
     4.1   Deployment Scenario  . . . . . . . . . . . . . . . . . . . 13
     4.2   Trust Relationship . . . . . . . . . . . . . . . . . . . . 14
     4.3   Softwire Security Threat Scenarios . . . . . . . . . . . . 15
       4.3.1   Attacks on the Control Plane . . . . . . . . . . . . . 15
       4.3.2   Attacks on the Data Plane  . . . . . . . . . . . . . . 16
     4.4   Softwire Security Guidelines . . . . . . . . . . . . . . . 16
     4.5   Guidelines for Usage of Security Protection Mechanism  . . 16
       4.5.1   Security Protection Mechanism for Control Plane  . . . 16
       4.5.2   Security Protection Mechanism for Data Plane . . . . . 19
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 20
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
     6.1   Normative References . . . . . . . . . . . . . . . . . . . 20
     6.2   Informative References . . . . . . . . . . . . . . . . . . 21
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23
       Intellectual Property and Copyright Statements . . . . . . . . 24
















Yamamoto, et al.         Expires April 25, 2007                 [Page 2]

Internet-Draft      Softwire security considerations        October 2006


1.  Introduction

   The Softwire Working Group is developing discovery, control and
   encapsulation methods for connecting IPv4 networks across IPv6
   networks and IPv6 networks across IPv4 networks.  Such IP based
   protocols were defined as softwire.  This document provides the
   security Guidelines based on the softwire problem statement by
   analyzing security threat scenarios for the Softwire "Hubs and
   Spokes" and "Mesh" solutions [I-D.softwire-problem-statement].

   The Softwire protocol itself does not implement full security
   protection mechanism in the control plane and data plane and
   vulnerable for potential security attacks.  Thus, the Softwire MUST
   be able to prevent the security threat.  This means that the Softwire
   protocol for control and data planes SHOULD be capable of preventing
   the security threat.  The feature that prevent the security threat
   may or may not be used depending on the Softwire deployment.  This
   document provides the guidelines for the usage of the security
   protection mechanism in terms of the softwire deployment scenarios.

2.  Terminology

   The terminology is based on the softwire problem statement document
   [I-D.softwire-problem-statement].

   AF(i) - Address Family.  IPv4 or IPv6.  Notation used to indicate
   that prefixes, a node or network only deal with a single IP AF.

   AF(i,j) - Notation used to indicate that a node is dual-stack or that
   a network is composed of dual-stack nodes.

   Address Family Border Router (AFBR) -A dual-stack router that
   interconnects two networks that use either the same or different
   address families.  An AFBR forms peering relationships with other
   AFBRs, adjacent core routers and attached CE routers, perform
   softwire discovery and signaling, advertises client ASF(i)
   reachability information and encapsulates/decapsulates customer
   packets in softwire transport headers.

   Customer Edge (CE) - A router located inside AF access island that
   peers with other CE routers within the access island network and with
   one or more upstream AFBRs.

   Customer Premise Equipment (CPE) - An equipment, host or router,
   located at a subscriber's premises and connected with a carrier's
   access network.

   Provider Edge (PE) - A router located at the edge of transit core



Yamamoto, et al.         Expires April 25, 2007                 [Page 3]

Internet-Draft      Softwire security considerations        October 2006


   network that interfaces with CE in access island.

   Softwire Concentrator (SC) - The node terminating the softwire in the
   service provider network.

   Softwire Initiator (SI) - The node initiating the softwire within the
   customer network.

   Softwire Encapsulation Set (SW-Encap) - A softwire encapsulation set
   contains tunnel header parameters, order of preference of the tunnel
   header types and the expected payload types (e.g.  IPv4) carried
   inside the softwire.

   Softwire Next_Hop (SW-NHOP) - This attribute accompanies client AF
   reachability advertisements and is used to reference a softwire on
   the ingress AFBR leading to the specific prefixes.  It contains a
   softwire identifier value and a softwire next_hop IP address denoted
   as <SW ID:SW-NHOP address>.  Its existence in the presence of client
   AF prefixes (in advertisements or entries in a routing table) infers
   the use of softwire to reach that prefix.

3.  Hubs and Spokes Security Guidelines

3.1  Deployment Scenarios

   To provide the security Guidelines, the discussion of the possible
   deployment scenario and the trust relationship in the network is
   important.

   The Softwire initiator always resides in the customer network.  The
   node, in which the softwire initiator resides, can be the CPE access
   device, another dedicated CPE router behind the original CPE access
   device or any kind of host device such as PC, appliance, sensor etc.

   However, the host device may not always have direct access to its
   home carrier network, to which the user has subscribed.  For example,
   the softwire initiator in the laptop PC can access various access
   networks such as Wi-Fi hot-spots, visited office network.  This is
   the nomadic case, which the Softwire SHOULD support., the following
   three use cases should be considered:

   As the softwire deployment models, the following three cases as shown
   in Figure 1 should be considered.  In these cases, the automated
   discovery of the softwire concentrator may be used.  But in this
   document, the information on the softwire concentrator such as the
   DNS name or IP address is assumed to be configured by the user, or by
   the provider of the softwire initiator in advance.




Yamamoto, et al.         Expires April 25, 2007                 [Page 4]

Internet-Draft      Softwire security considerations        October 2006


   Case 1: The softwire initiator connects to the softwire concentrator
   that belongs to the home network service provider via the home access
   provider network.  The IP address of the host may be changed
   periodically due to the home network service provider's policy.

   Case 2: The softwire initiator connects to the softwire concentrator
   that belongs to the home network service provider via the visited
   access network.  This is typical of nomadic access use case.  The
   host does not subscribe to the visited access provider, but this
   provider has some roaming agreement with the home network service
   provider of the host.  The IP address of the host may be changed
   periodically due to the home network service provider's policy.

   Case 3: The softwire initiator connects to the softwire concentrator
   that belongs to the visited network service provider via the visited
   access network.  This is also typical of nomadic access use case.
   The host does not subscribe to the visited network service provider,
   but this provider has some roaming agreement with the home network
   service provider of the host.  If this is the case, the IP address of
   the host is determined by the visited network service provider's
   policy.

   The trust relationship for these three cases will also be different.
   The security consideration must take them into account.  In
   particular, to allow cases 2 and 3, AAA interactions between the home
   network service provider and visited access/service provider should
   be considered.  The details of this scenario are given in Section
   Section 3.2.























Yamamoto, et al.         Expires April 25, 2007                 [Page 5]

Internet-Draft      Softwire security considerations        October 2006


             visited network            visited network
             access provider            service provider
                    +---------------------------------+
             +......|......+    +.....................|......+
             .      v      .    .                     v      .
   +------+  .             .    .  +------+      +--------+  .
   |      |=====================.==|      |      |        |  .
   |  SI  |__.________     .    .  |  SC  |<---->|  AAAp  |  .
   |      |---------- \    .    .  |      |      |        |  .
   +------+  .        \\   .    .  +------+      +--------+  .
             .         \\  .    .                     ^      .
      ^      +..........\\.+    +.....................|......+
      |                  \\                           |
      |                   \\                          |
      |                    \\                         |
      |                     \\                        |
      |      +............+  \\ +.....................|......+
             .            .   \\.                     v      .
   +------+  .            .    \\__+------+      +--------+  .
   |      |  .            .     ---|      |      |        |  .
   |  SI  |=====================.==|  SC  |<---->|  AAAh  |  .
   |      |  .            .     .  |      |      |        |  .
   +------+  .            .     .  +------+      +--------+  .
             .            .     .                            .
             +............+     +............................+
              home network                home network
             access provider            service provider

                      Figure 1: Hubs and Spokes model


3.2  Trust Relationship

   To perform authentication between the SC and the SI, the AAA server
   needs to be involved.  One or more AAA servers should reside in the
   same administrative domain as the SC to authenticate the SI.  When
   the SI is mobile, it may roam from the home ISP network to another,
   e.g. a WIFI hot-spot network.  In such a situation, the SI may not
   always connect to the same SC.  From the SI's viewpoint, the AAA
   server that is in the same administrative domain is called the home
   AAA server and those not in the same administrative domain are called
   visited AAA servers.  The trust relationships between those nodes are
   as follows:

   It can be assumed that the SC and the AAA in the same administrative
   domain share a trust relationship.  When the SC needs to authenticate
   the SI, the SC communicates with the AAA server to request
   authentication and/or to obtain security information.  If the SI



Yamamoto, et al.         Expires April 25, 2007                 [Page 6]

Internet-Draft      Softwire security considerations        October 2006


   roams into a network that is not in the same administrative domain,
   the AAA server (the visited AAA server) communicates with the home
   AAA server that has the SI's security information.  Therefore, the
   communication between the SC and the AAA server must be protected.
   It can be usually assumed that the home and visited AAA servers share
   a trust relationship and the connection between them is protected.

   It can be assumed that the SI and the home AAA server share a trust
   relationship.  The home AAA server provides security information on
   the SI when it is requested by the visited AAA server.  The SI and
   the visited AAA server do not usually have a trust relationship;
   however, if the SI can confirm that the home AAA server is involved
   with the authentication of the SI and the visited AAA server does not
   alter security information from the home AAA server, the visited AAA
   server can be trusted by the SI.  The communication between the SI,
   the home and visited AAA servers must be protected.

   The SI and the SC do not necessarily share a trust relationship
   especially when the SI roams into a different administrative domain.
   When they are mutually authenticated by means of e.g.  AAA servers,
   they can start trusting each other.  Unless authentication is
   successfully performed, the softwire protocol should not be
   initiated.

3.3  Softwire Security Threat Scenarios

   Softwire can be used to connect IPv4 networks across public IPv6
   networks and IPv6 networks across public IPv4 networks.  The control
   and data packets used during the softwire session are vulnerable to
   attack.

   A complete threat analysis of softwire requires examination of the
   protocols used for the softwire setup, the encapsulation method used
   to transport the payload, and other protocols used for configuration
   (e.g., router advertisements, DHCP).

   Threat analysis done for other protocols L2TP using IPsec [RFC3193],
   PANA [RFC4016], NSIS [RFC4081], [I-D.rpsec-routing-threats] are
   applicable here as well and should be used as reference.

   Examples of attacks on softwire include:

   1.  An adversary may try to discover identities by snooping data
       packets.

   2.  An adversary may try to modify packets (both control and data).





Yamamoto, et al.         Expires April 25, 2007                 [Page 7]

Internet-Draft      Softwire security considerations        October 2006


   3.  An adversary may try to hijack the softwire tunnel.

   4.  An adversary can launch denial of service attacks by terminating
       softwire created tunnels.

   5.  An adversary may attempt to disrupt the softwire negotiation in
       order to weaken or remove confidentiality protection.

   6.  An adversary may impersonate the softwire concentrator to
       intercept traffic ("rogue" softwire concentrator).

   7.  If ingress filtering is not in place within the access network, a
       number of DoS attack can happen:

       *  A malicious user can impersonate someone else's IPv4 address
          during the set-up phase and redirect a tunnel to that IP
          address.  A then can, for example, start a high bandwidth
          multimedia flow across that tunnel and saturate its victim's
          uplink.

       *  A malicious user impersonates a large number of IPv4 addresses
          and request tunnel of their behalf.  That would quickly
          saturate the ISP tunnel server infrastructure.

   8.  If ingress filtering is in place in the core ISP backbone but not
       in the access network, the potential victims of the above
       problems will be limited to the ISP's own customers.

   9.  If specific filtering is not in place in the ISP core network,
       another kind of attack can happen.  Customers from another ISP
       could start using its tunneling infrastructure to get free IPv6
       connectivity, transforming effectively the ISP into a IPv6
       transit provider.

   For the Hubs and Spokes model, the SI needs to discover the softwire
   concentrator.  This involves sending solicitations (setup protocol).
   Once the client has discovered the concentrator, the two will enter
   authentication exchange.  Once the access is granted, the client will
   most likely exchange data with other nodes in the Internet.  These
   steps are vulnerable to man-in-the-middle (MITM), denial of service
   (DoS), and service theft attacks, which are discussed in this
   document.  Among them, so called blackhole attacks defined in
   [RFC4593] are discussed in the next section.

3.3.1  Softwire Blackhole Attacks

   A Softwire blackhole attack is a threat by which an internal Attacker
   captures all of the necessary information (including keys if security



Yamamoto, et al.         Expires April 25, 2007                 [Page 8]

Internet-Draft      Softwire security considerations        October 2006


   is present) of a legitimate Softwire node and remove the messages of
   the subgroup of the network.  The attacker may also be able to change
   a legitimate Softwire Control message.  The aim of the internal
   attacker is to Deceive the receiving nodes of Softwire service that
   its Path to the concentrator is different.  In this way the Attacker
   may accumulate traffic to itself but it does Not forward any data
   towards the Softwire Concentrator.  Here the attacker is able to
   divert the traffic to a "black hole" where it is discarded.  The
   attack here is local and the rest of the network may not be
   compromised.

   Countermeasure: In order to overcome the confidentiality problem,
   each node requesting Softwire service can send data encrypted with
   the key that it shares with the concentrator.  Therefore, the
   attacker will not be able to read data packets but will be able to
   drop them.  This problem can be solved by employing an authenticated
   acknowledgment mechanism after the Softwire tunnel is established.

3.4  Softwire Security Guidelines

   Based on the security threat analysis in other sections in this
   document, an enumeration of security requirements are summarized
   below:

   1.  The tunnel set-up protocol MUST not introduce any new
       vulnerability to the network.

   2.  The softwire protocol MUST NOT assume that the discovery process
       is protected.

   3.  The Softwire MUST BE able to mutually authenticate the initiator
       and the concentrator.  The softwire protocol MUST be able to
       establish keys between the initiator and the concentrator to
       protect the Softwire messages.

   4.  The Softwire signaling communication between the client and the
       concentrator MUST BE protected against eavesdropping and spoofing
       attacks.

   5.  The Softwire protocol MUST be able to protect itself against
       replay attacks.

   6.  The Softwire protocol MUST be able to protect the device
       identifier against spoofing when it is exchanged between the
       initiator and the concentrator.

   7.  The Softwire protocol MUST be able to protect disconnect-type and
       revocation-type messages.



Yamamoto, et al.         Expires April 25, 2007                 [Page 9]

Internet-Draft      Softwire security considerations        October 2006


   8.  The Softwire protocol MUST be able to securely bind the
       authenticated session to the device identifier of the client, to
       prevent service theft.

   9.  Softwire security MUST meet the key management requirements of
       the IPsec protocol suite.  IKE SHOULD be supported for
       authentication, security association negotiation, and key
       management


3.5  Guidelines for Usage of Security Protection Mechanism

   The Softwire security requirements state that control and/or data
   plane must be able to provide full payload security when desired
   [I-D.softwire-problem-statement, section 2.11.2].  [RFC3193]
   discusses how L2TP can use IPsec to provide tunnel authentication,
   privacy protection, integrity checking and replay protection.

   [RFC3193] can be applied in the softwire "Hubs and Spokes" model
   context.  New additions to IPsec ([RFC3947],[RFC3948],[RFC4306]) are
   necessary to meet the softwire requirements were published after
   [RFC3193].

   The following sections will discuss [RFC3193] as applied in the
   softwire "Hubs and Spokes" model.

   In softwire, L2TP is used in a voluntary tunneling model only.  The
   Softwire Initiator (SI) acts as a L2TP Access Concentrator (LAC) and
   PPP endpoint.  The L2TP tunnel is always initiated from the SI.

   The scope of the security is on the L2TP tunnel between the SI and
   SC.  If end to end security is required, a security protocol should
   be used in the payload packets (out of scope of this document for
   now).

3.5.1  Softwire Security Protocol

   [RFC3193] section 2.1 defines the security requirement for L2TP.  The
   same requirements are used for the "Hubs and Spokes" softwire model.
   A softwire security compliant implementation MUST implement the
   security protocol requirements as defined in [RFC3193] section 2.1:

   o  IPsec ESP [RFC4303] in transport mode to secure both the L2TP
      control and data packets.

   o  IKE MUST be supported for authentication, security association
      negotiation and key management for IPsec (this is a SHOULD in
      [RFC3193])



Yamamoto, et al.         Expires April 25, 2007                [Page 10]

Internet-Draft      Softwire security considerations        October 2006


   o  Since softwire must support NAT traversal, UDP encapsulation of
      IPsec ESP packets [RFC3948] and negotiation of NAT-traversal in
      IKE [RFC3947] MUST be supported.

   IKEv2 [RFC4306] supports legacy authentication methods that may be
   useful in environments where username and password based
   authentication is already deployed.

3.5.2  Authentication

   The softwire protocol MUST support customer authentication in the
   control plane, in order to authorize access to the service, and
   provide adequate logging of activity.  However, in some
   circumstances, the service provider may decide to turn it off.  For
   example, when the customer is already authenticated by some other
   means, such as closed networks, cellular networks at Layer 2, etc.

   The protocol SHOULD offer mutual authentication in scenarios where
   the SI requires identity proof from the SC.

   In addition, the SC MAY allow non-authenticated connection.  In that
   case, the SC acts as a gateway for anonymous connections.  This
   approach is better than an open relay implementation since ingress
   filtering is performed on established tunnels.  If non-authenticated
   connections are supported by the SC, enabling this function MUST be
   configurable by the SC administrator.

3.5.2.1  PPP authentication

   PPP can provide mutual authentication between the SI and SC using
   CHAP [RFC1994] during the connection establishment phase (Link
   Control Protocol, LCP).  PPP CHAP authentication can be used when the
   SI and SC are on a trusted, non-public IP network.

   Since CHAP does not provide per-packet authentication, integrity, or
   replay protection, PPP CHAP authentication MUST NOT be used
   unprotected on a public IP network.

   Optionally, other authentication methods such as PAP, MS-CHAP EAP MAY
   be supported.

3.5.2.2  L2TPv2 authentication

   L2TPv2 provides an optional CHAP-like [RFC1994] tunnel authentication
   during the control connection establishment [RFC2661, 5.1.1].  The
   same restrictions apply to L2TPv2 authentication and PPP CHAP.





Yamamoto, et al.         Expires April 25, 2007                [Page 11]

Internet-Draft      Softwire security considerations        October 2006


3.5.2.3  IPsec authentication

   Authentication using shared secrets can be used when the number of
   softwire initiators is small.  When the number of SI increases,
   shared secrets becomes difficult to manage.  Public-key digital
   signature or key encryption authentication with certificates is
   preferable [RFC3193, 4.1].

3.5.3  Inter-operability guidelines

   The inter-operability guidelines in [RFC3193] concerning tunnel
   teardown, fragmentation and per-packet security checks must be
   followed.  [Note: nothing specific to softwire.]

3.5.4  IPsec filtering details

   The IPsec filtering details from [RFC3193] section 4 are applicable
   to softwire "Hubs and Spokes" model.

   Although the L2TP specification allows the responder (SC in softwire)
   to use a new IP address when sending the Start-Control-Connection-
   Request-Reply (SCCRP), a softwire concentrator implementation SHOULD
   NOT do this ([RFC3193] section 4).  Note that this feature may be
   needed for "load-balancing" between SCs.

3.5.5  IPsec SPD entries example

   The SPD examples in [RFC3193] appendix A can be applied to softwire
   model.  In that case, the initiator is always the client (SI), and
   responder is the SC.

3.5.5.1  IPv6 over IPv4 Softwire with L2TPv2 example

   In this example, the softwire initiator and concentrator are denoted
   with IPv4 addresses IPv4-SI and IPv4-SC respectively.


                                     Next Layer
         src       dst      Protocol                  Action
        -----     ------    ----------                --------
       IPV4-SI   IPV4-SC      ESP                     BYPASS
       IPV4-SI   IPV4-SC      IKE                     BYPASS
       IPv4-SI   IPV4-SC      UDP, src 1701, dst 1701 PROTECT(ESP,transport)
       IPv4-SC   IPv4-SI      UDP, src   * , dst 1701 PROTECT(ESP,transport)







Yamamoto, et al.         Expires April 25, 2007                [Page 12]

Internet-Draft      Softwire security considerations        October 2006


                                     Next Layer
         src       dst      Protocol                  Action
        -----     ------    ----------                --------
          *      IPV4-SC      ESP                     BYPASS
          *      IPV4-SC      IKE                     BYPASS
          *      IPV4-SC      UDP, src * , dst 1701   PROTECT(ESP,transport)



3.5.5.2  IPv4 over IPv6 Softwire with example

   In this example, the softwire initiator and concentrator are denoted
   with IPv6 addresses IPv6-SI and IPv6-SC respectively.


                                     Next Layer
         src       dst      Protocol                   Action
        -----     ------    ----------                 --------
       IPV6-SI   IPV6-SC      ESP                      BYPASS
       IPV6-SI   IPV6-SC      IKE                      BYPASS
       IPv4-SI   IPV6-SC      UDP, src 1701, dst 1701  PROTECT(ESP,transport)
       IPv4-SC   IPv4-SI      UDP, src * , dst 1701    PROTECT(ESP,transport)



                                     Next Layer
         src       dst      Protocol                 Action
        -----     ------    ----------               --------
          *      IPV6-SC      ESP                    BYPASS
          *      IPV6-SC      IKE                    BYPASS
          *      IPV6-SC      UDP, src * , dst 1701  PROTECT(ESP,transport)



4.  Mesh Security Guidelines

4.1  Deployment Scenario

   In the "Mesh" model, it is required to establish connectivity to
   access network islands of one address family type across a transit
   core of a differing address family type.  To provide reachability
   across the transit core, AFBRs are installed between access network
   island and transit core network.  These AFBRs can peer across
   autonomous systems or perform as Provider Edge routers (PE) within an
   autonomous system.  The AFBRs establish and encapsulate softwires in
   a mesh to the other islands across the transit core network.  The
   transit core network consists of one or more service providers.




Yamamoto, et al.         Expires April 25, 2007                [Page 13]

Internet-Draft      Softwire security considerations        October 2006


   In the softwire "Mesh" solution, point to multi-point connectivity
   among AFBRs is dynamically established by announcing the reachability
   and the encapsulation method using Multiprotocol Extensions for BGP-4
   (MP-BGP)[RFC2858].

   AFBR nodes are Internal BGP speakers and will peer with each other
   (directly or via a route reflector) to exchange SW-encap sets,
   perform softwire signaling, and advertise AF access island
   reachability information and SW-NHOP information.  If such
   information is advertised within an autonomous system, the AFBR node
   receiving them from other AFBRs does not forward them to other AFBR
   nodes.  To exchange the information among AFBRs, the full mesh
   connectivity is required.

   BGP speakers can inject bogus routing information, either by
   masquerading as any other legitimate BGP speaker, or by distributing
   unauthorized routing information as themselves.  The damage due to
   this bogus information is limited rather than eBGP case but cannot be
   ignored.

   AFBRs are PE routers located at the edge of the provider core
   networks.  This is similar architecture of Provider Provisioned PE-
   based VPN.  CE-PE connectivity is established by static way or using
   routing protocol i.e. eBGP.  AFBRs form a peering relationship with
   one or more CE routers located inside the AF access island to AF
   access island reachability information.  Note that the security
   threat on CE-PE is not specific to Softwire Mesh solution.

   As alternative model to make the AFBR a single-stack AF(j) PE node,
   the dual-stack AF(i,j) processing is moved to CE routers located at
   the edge of a customer site and may or may not be provided by the
   core network provider.  This is the dual-stack CE model.  This model
   might evolve inter-CE BGP peering to exchange client AF prefixes/
   next-hops.  The CE-PE connection includes dedicated physical
   circuits, logical circuits (such as Frame Relay and ATM), and shared
   medium access (such as Ethernet-based access).  The CE device has the
   IP connectivity with SP's PE device over the Access connection.

4.2  Trust Relationship

   All the ASBRs in the transit core MUST have a trust relationship or
   an agreement with each other to establish softwires.  Within an
   autonomous system, it is assumed that all the nodes (e.g. the ASBR,
   PE or Route Reflector, if applicable) are trusted with each other so
   that the AFBR can be collocated in the ASBR or PE.  If the transit
   core consists of multiple autonomous systems, intermediate routers
   between ASBRs may not be trusted.




Yamamoto, et al.         Expires April 25, 2007                [Page 14]

Internet-Draft      Softwire security considerations        October 2006


   There MUST be a trust relationship between the PE in the transit core
   and the CE in the corresponding island; however, the link(s) between
   the PE and CE may not be protected.

4.3  Softwire Security Threat Scenarios

   In terms of Softwire mesh solution, the security threats are common
   to those of PPVPN.  [RFC4111] But in this document, the security
   threats on PE-PE are specifically discussed.

   The security attacks on the control plane and the data plane can be
   mounted.  In Mesh Solution, Softwires will be established by using
   MP-BGP.  MP-BGP does not change the security issues inherent in the
   existing BGP.  In terms of the control plane security, the general
   BGP security vulnerabilities are applicable[RFC4272].

4.3.1  Attacks on the Control Plane

   BGP, in and of itself, is subject to the following attacks [RFC4272].

   1.  The routing data carried in BGP is carried in cleartext, so
       eavesdropping is a possible attack against routing data
       confidentiality. (confidentiality violations)

   2.  BGP does not provide for replay protection of its message.
       (replay)

   3.  BGP does not provide protection against insertion of messages.
       However, because BGP uses TCP, when the connection is fully
       established, message insertion by an outsider would require
       accurate sequence number prediction or session-stealing
       attacks.(message insertion)

   4.  BGP does not provide protection against deletion messages.  This
       attack is more difficult against a mature TCP implementation, but
       is not entirely out of question. (message deletion)

   5.  BGP does not provide protection against modification of messages.
       A modification that was syntactically correct and did not change
       the length of the TCP payload would in general not be detectable.
       (message modification)

   6.  6.  BGP does not provide protection against man-in-the-middle
       attacks.  As BGP does not perform peer entity authentication, it
       is vulnerable to a man-in-the-middle attack. (man-in-the-middle)

   7.  While bogus routing data can present a DoS attack on the end
       systems that are trying to transmit data through network and on



Yamamoto, et al.         Expires April 25, 2007                [Page 15]

Internet-Draft      Softwire security considerations        October 2006


       the network infrastructure itself, certain bogus information can
       present a DoS on the BGP routing protocol. (denial-of-service)


4.3.2  Attacks on the Data Plane

   Examples of attacks include:

   1.  An adversary may try to discover confidential information by
       sniffing softwire packets.

   2.  An adversary may try to modify the contents of softwire packets.

   3.  An adversary may try to spoof the softwire packets that do not
       belong there and to insert of copies of once-legitimate packets
       that have been recorded and replayed.

   4.  An adversary can launch Denial-of-Service attack by deleting
       softwire data traffic.  DoS attacks of the resource exhaustion
       type can be mounted against the data plane by spoofing a large
       amount of non-authenticated data into the softwire from the
       outside of the softwire tunnel.

   5.  An adversary may try to sniff softwire packets and to examine
       aspects or meta-aspects of them that may be visible even when the
       packets themselves are encrypted.  An attacker might gain useful
       information based on the amount and timing of traffic, packet
       sizes, sources and destination addresses, etc.


4.4  Softwire Security Guidelines

   Given that security is generally a compromise between expense and
   risk, it is also useful to consider the likelihood of different
   attacks.  There is at least a perceived difference in the likelihood
   of most types of attacks being successfully mounted in different
   deployment.

   The trust model between the access network islands and the transit
   core networks is a key element in determining the applicability of
   encryption for the specific Mesh softwire implementation.

4.5  Guidelines for Usage of Security Protection Mechanism

4.5.1  Security Protection Mechanism for Control Plane

   A BGP has the three fundamental vulnerabilities to the security
   threats [RFC4272].



Yamamoto, et al.         Expires April 25, 2007                [Page 16]

Internet-Draft      Softwire security considerations        October 2006


   1.  BGP has no internal mechanism that provides strong protection of
       the integrity, freshness, and peer authenticity of the message in
       peer-peer BGP communications.

   2.  No mechanism has been specified within BGP to validate the
       authority of a BGP peer to announce NLRI information.

   3.  No mechanism has been specified within BGP to ensure the
       authenticity of the path attributes announced by a BGP peer.

   A BGP implementation MUST support the authentication mechanism
   specified in RFC 2385.  The authentication provided by this mechanism
   could be done on a peer-peer basis.

   The mechanism defined in RFC 2385 is based on a one-way hash function
   (MD5) and use of a secret key.  The key is shared between peer
   routers and is used to generate 16-byte message authentication code
   values that are not readily computed by an attacker who does not have
   access to the key.

   RFC 2385, however, does not specify a means of managing the keys use
   to compute the MAC although RFC3562 provides some Guidelines in the
   key management.

   Key management can be especially onerous for operators.  The number
   of keys required and the maintenance of keys (issue/revoke/renew) has
   had an additive effect as a barrier to deployment.  Thus automated
   means of managing keys, to reduce operational burdens, MUST be
   available in BGP security systems.[I-D.rpsec-bgpsecrec]

   Automated key management will be provided by IKE/IPsec.

4.5.1.1  TCP MD5

   The mandatory-to-support mechanism of TCP MD5 will counter message
   insertion, deletion, and modification, man-in-the-middle and denial
   of service attacks from outsiders.  The use of TCP MD5 does not
   protect against eavesdropping attacks, (but routing data
   confidentiality is not a goal of BGP) The mechanism of TCP MD5 does
   not protect against replay attacks, so the only protection against
   replay is provided by the TCP sequence number processing.  Therefore,
   a replay attack could be mounted against a BGP connection protected
   with TCP MD5 but in very carefully timed circumstances.

   In addition, lack of an automated key distribution protocol
   complicates management and encourages overly long-term use of
   symmetric keys.




Yamamoto, et al.         Expires April 25, 2007                [Page 17]

Internet-Draft      Softwire security considerations        October 2006


4.5.1.2  IPsec

   Use of TCP MD5 counters the message insertion, deletion, and
   modification attacks, as well as man-in-the-middle attacks by
   outsiders.  If routing data confidentiality is desired, the use of
   IPsec ESP could provide that service.  But routing data
   confidentiality is not a goal of BGP.

   IPsec, transport mode is used to protect BGP session between peers.
   If eavesdropping attack against the data plane is identified as a
   threat, ESP can be used to provide confidentiality (encryption),
   integrity and authentication for the BGP session.  Where
   eavesdropping is not a threat, ESP without confidentiality or AH may
   be used.

   To provide replay protection, automated key management system using
   IKE must be used.  IKE main mode can be used using shared secrets for
   authentication when the number of BGP peers is small.  When the
   number of BGP peers is large managing the shared secrets on all peers
   does not scale.  In this scenario, public-key digital signature or
   key encryption authentication in IKE should be used, assuming that
   the peers have the necessary computation available.

4.5.1.3  Secure BGP

   The deeper security issues raised by BGP are not addressed by IPsec
   or any other transmission security mechanism.

   As cryptographic-based mechanism, Both TCP MD5 and IPsec assume that
   the cryptographic algorithms are secure, that secrets used are
   protected from exposure and are chosen well so as not to be
   guessable, that the platforms are securely managed and operated to
   prevent break-ins, etc.

   These mechanisms do not prevent attacks that arise from a router's
   legitimate BGP peers [RFC4272].

   The S-BGP countermeasures use IPsec, Public Key Infrastructure (PKI)
   technology,a nd a new BGP path attribute ("attestations") to ensure
   the authenticity and integrity of BGP communication on a point-to-
   point basis, and to validate BGP routing UPDATE's on a source to
   destination basis[I-D.clynn-s-bgp-protocol].

   To implement the secure BGP, Secure Origin BGP (soBGP) and Pretty
   Secure BGP (psBGP) are also proposed.  The detail comparison was made
   in[Wan05].





Yamamoto, et al.         Expires April 25, 2007                [Page 18]

Internet-Draft      Softwire security considerations        October 2006


4.5.2  Security Protection Mechanism for Data Plane

   The protection mechanisms discussed are intended to describe methods
   by which some security threats can be mitigated.  They are not
   intended as requirements for all softwire implementations.

   The several of the attacks outlined in Section 4.3.2.  In order to
   protect against such threats, the softwire SHOULD provide for replay
   and integrity protection for softwire data packets and MAY protect
   confidentiality of data packets.  Automated key management in the
   softwire mesh solution may be necessary per [RFC4107].

4.5.2.1  Cryptographic Techniques

   IPsec can provide replay protection, integrity and confidentiality of
   IP data packets, which would protect against most threats identified
   in 4.3.2.

   In Softwire Mesh framework solution, IPsec connections can be
   established on selective basis using Tunnel SAFI advertised by AFBRs.
   The softwire mesh framework [wu-softwire-mesh-framework] currently
   supports many tunnel encapsulation type using a "Softwire Mesh
   Encasulation attribute" advertised as a BGP Tunnel SAFI [nalawade-
   softwire-mesh-encap-attribute], [nalawade-kapoor-tunnel-safi].

   To protect the data packets using IPsec, AFBRs must be configured
   with the proper IPsec parameters: ESP (with or without
   confidentiality), transport or tunnel mode, key management (IKE
   phase1 mode and ID), selectors and SPD.

   [nalawade-kapoor-tunnel-safi] describes an IPsec Tunnel Information
   TLV that contains an IKE Identifier.  The SPD and selectors must also
   be defined.  These are directly related to the encapsulation type
   used between the AFBRs (e.g., selectors for L2TP will be different
   from IPv6-over-IPv4 tunnels).

   (to be completed)

4.5.2.2  Access Control Techniques

   Access control techniques include packet-by-packet or packet flow-by
   -packet flow access control by means of filters as well as by means
   of admitting a session for a control/signaling/management protocol
   that is being used to implement softwires.

   It is relatively common for routers to filter data packets.  That is,
   routers can look for particular values in certain fields of the IP or
   higher level (e.g., TCP or UDP) headers.  Packets that match the



Yamamoto, et al.         Expires April 25, 2007                [Page 19]

Internet-Draft      Softwire security considerations        October 2006


   criteria associated with a particular filter may be either discarded
   or given special treatment to prevent an attack or to mitigate the
   effect of a possible future attack.

5.  Security Considerations

   This document is about the IETF's requirement that security be
   considered in the deployment of softwire.  The entire document
   consider the security.

   The several of the attacks outlined in 4.3.2.  In order to protect
   against such threats, the softwire SHOULD provide for replay and
   integrity protection for softwire data packets and MAY protect
   confidentiality of data packets.  Automated key management in the
   softwire mesh solution may be necessary per[RFC4107].

6.  References

6.1  Normative References

   [I-D.softwire-hs-framework-l2tpv2]
              Sorer, B., Pignataro, C., Dos Santos, M., Tremblay, J.,
              and L. Toutain, "Softwire Hub & Spoke Deployment Framework
              with L2TPv2", draft-softwire-hs-framework-l2tpv2 (work in
              progress), August 2006.

   [I-D.softwire-problem-statement]
              Li, X., Durand, A., Ward, D., and S. Dawkins, "Softwire
              Problem Statement",
              draft-ietf-softwire-problem-statement-02 (work in
              progress), May 2006.

   [I-D.v6ops-tunneling-requirements]
              Durand, A. and F. Parent, "Requirements for assisted
              tunneling",
              draft-durand-v6ops-assisted-tunneling-requirements-00
              (work in progress), September 2004.

   [I-D.wu-softwire-mesh-framework]
              Wu, J., Cui, Y., LI, X., Metz, C., and G. Nalawade, "A
              Framework for Softwire Mesh Signaling, Routing and
              Encapsulation across IPv4 and IPv6 Backbone Networks",
              draft-wu-softwire-mesh-framework-00 (work in progress),
              June 2006.

   [RFC1994]  Simpson, W., "PPP Challenge Handshake Authentication
              Protocol (CHAP)", RFC 1994, August 1996.




Yamamoto, et al.         Expires April 25, 2007                [Page 20]

Internet-Draft      Softwire security considerations        October 2006


   [RFC2385]  Heffernan, A., "Protection of BGP Sessions via the TCP MD5
              Signature Option", RFC 2385, August 1998.

   [RFC2409]  Harkins, D. and D. Carrel, "The Internet Key Exchange
              (IKE)", RFC 2409, November 1998.

   [RFC2661]  Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn,
              G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"",
              RFC 2661, August 1999.

   [RFC2858]  Bates, T., Rekhter, Y., Chandra, R., and D. Katz,
              "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000.

   [RFC3365]  Schiller, J., "Strong Security Requirements for Internet
              Engineering Task Force Standard Protocols", BCP 61,
              RFC 3365, August 2002.

   [RFC3947]  Kivinen, T., Swander, B., Huttunen, A., and V. Volpe,
              "Negotiation of NAT-Traversal in the IKE", RFC 3947,
              January 2005.

   [RFC3948]  Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
              Stenberg, "UDP Encapsulation of IPsec ESP Packets",
              RFC 3948, January 2005.

   [RFC4107]  Bellovin, S. and R. Housley, "Guidelines for Cryptographic
              Key Management", BCP 107, RFC 4107, June 2005.

   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)",
              RFC 4303, December 2005.

   [RFC4306]  Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
              RFC 4306, December 2005.

   [RFC4593]  Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to
              Routing Protocols", RFC 4593, October 2006.

6.2  Informative References

   [I-D.bellovin-useipsec]
              Bellovin, S., "Guidelines for Mandating the Use of IPsec",
              draft-bellovin-useipsec-04 (work in progress),
              September 2005.

   [I-D.clynn-s-bgp-protocol]
              Lynn, C. and K. Seo, "Secure BGP (S-BGP)",
              draft-clynn-s-bgp-protocol-01 (work in progress),
              June 2003.



Yamamoto, et al.         Expires April 25, 2007                [Page 21]

Internet-Draft      Softwire security considerations        October 2006


   [I-D.rpsec-bgpsecrec]
              Christian, B. and T. Tauber, "BGP Security Requirements",
              draft-ietf-rpsec-bgpsecrec-06 (work in progress),
              April 2006.

   [I-D.rpsec-routing-threats]
              Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to
              Routing Protocols", draft-ietf-rpsec-routing-threats-07
              (work in progress), October 2005.

   [I-D.white-sobgp-architecture]
              White, R., "Architecture and Deployment Considerations for
              Secure Origin BGP (soBGP)",
              draft-white-sobgp-architecture-02 (work in progress),
              June 2006.

   [RFC3193]  Patel, B., Aboba, B., Dixon, W., Zorn, G., and S. Booth,
              "Securing L2TP using IPsec", RFC 3193, November 2001.

   [RFC3562]  Leech, M., "Key Management Considerations for the TCP MD5
              Signature Option", RFC 3562, July 2003.

   [RFC4016]  Parthasarathy, M., "Protocol for Carrying Authentication
              and Network Access (PANA) Threat Analysis and Security
              Requirements", RFC 4016, March 2005.

   [RFC4081]  Tschofenig, H. and D. Kroeselberg, "Security Threats for
              Next Steps in Signaling (NSIS)", RFC 4081, June 2005.

   [RFC4111]  Fang, L., "Security Framework for Provider-Provisioned
              Virtual Private Networks (PPVPNs)", RFC 4111, July 2005.

   [RFC4272]  Murphy, S., "BGP Security Vulnerabilities Analysis",
              RFC 4272, January 2006.

   [Wan05]    Wan, T., Wan, P., and S. Kranakis, "A Selective
              Introduction to Border Gateway Protocol (BGP) Security
              Issues", URL http://www.scs.carleton.ca/research/
              tech_reports/2005/TR-05-08.pdf, August 2005.












Yamamoto, et al.         Expires April 25, 2007                [Page 22]

Internet-Draft      Softwire security considerations        October 2006


Authors' Addresses

   Shu Yamamoto
   KDDI R&D Labs
   2-1-15 Fujimino-shi
   Saitama,   356-8502
   Japan

   Phone: 81 (49) 278-7311
   Email: shu@kddilabs.jp


   Carl Williams
   KDDI R&D Labs
   Palo Alto, CA  94301
   USA

   Phone: +1.650.279.5903
   Email: carlw@mcsr-labs.org


   Florent Parent
   consultant
   Quebec, QC
   Canada

   Phone: +1 418 265 7357
   Email: Florent.Parent@mac.com


   Hidetoshi Yokota
   KDDI R&D Labs
   2-1-15 Ohara
   Fujimino, Saitama  356-8502
   Japan

   Phone: 81 (49) 278-7894
   Email: yokota@kddilabs.jp













Yamamoto, et al.         Expires April 25, 2007                [Page 23]

Internet-Draft      Softwire security considerations        October 2006


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2006).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Yamamoto, et al.         Expires April 25, 2007                [Page 24]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/