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

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

Network Working Group                                        S. Yamamoto
Internet-Draft                                               C. Williams
Expires: December 21, 2006                                 KDDI R&D Labs
                                                               F. Parent
                                                  Independent Consultant
                                                               H. Yokota
                                                           KDDI R&D Labs
                                                           June 19, 2006


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

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 December 21, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document discusses the security requirements of softwire.
   Authentication, integrity, confidentiality and replay protection of
   the softwire control and data packets are discussed.  Both hub and
   spokes and mesh solutions are discussed.



Yamamoto, et al.        Expires December 21, 2006               [Page 1]

Internet-Draft      Softwire security considerations           June 2006


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Softwire Model . . . . . . . . . . . . . . . . . . . . . . . .  3
     3.1   Hub and Spokes . . . . . . . . . . . . . . . . . . . . . .  3
     3.2   Mesh . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Trust Relationship . . . . . . . . . . . . . . . . . . . . . .  6
   5.  Softwire Security Threat Scenarios . . . . . . . . . . . . . .  6
   6.  Softwire Security Requirements . . . . . . . . . . . . . . . .  8
   7.  Guideline for IPSec usage  . . . . . . . . . . . . . . . . . .  9
     7.1   Softwire Security Protocol . . . . . . . . . . . . . . . .  9
     7.2   Authentication . . . . . . . . . . . . . . . . . . . . . . 10
       7.2.1   PPP authentication . . . . . . . . . . . . . . . . . . 10
       7.2.2   L2TPv2 authentication  . . . . . . . . . . . . . . . . 10
       7.2.3   IPsec authentication . . . . . . . . . . . . . . . . . 10
     7.3   Inter-operability guidelines . . . . . . . . . . . . . . . 11
     7.4   IPsec filtering details  . . . . . . . . . . . . . . . . . 11
     7.5   IPsec SPD entries example  . . . . . . . . . . . . . . . . 11
       7.5.1   IPv6 over IPv4 Softwire with L2TPv2 example  . . . . . 11
       7.5.2   IPv4 over IPv6 Softwire with example . . . . . . . . . 11
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     9.1   Normative References . . . . . . . . . . . . . . . . . . . 11
     9.2   Informative References . . . . . . . . . . . . . . . . . . 12
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12
       Intellectual Property and Copyright Statements . . . . . . . . 14
























Yamamoto, et al.        Expires December 21, 2006               [Page 2]

Internet-Draft      Softwire security considerations           June 2006


1.  Introduction

   The Softwire Working Group is developing methods for 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 discusses the
   security requirements based on the softwire problem statement by
   analyzing security threat scenarios for both "Hubs and Spokes" and
   "Mesh" [I-D.softwire-problem-statement].

   As softwire protocol, L2TP was adopted by the Softwire Working Group.
   But L2TP does not define tunnel protection mechanism and vulnerable
   for potential security attacks.  Thus, the use of IPsec was discussed
   to provide for tunnel authentication, confidentiality, integrity
   checking and replay protection.[RFC 3193] However the usage of IPsec
   is not always straightforward.  This document provides the guidelines
   for IPsec usage in terms of the softwire network scenarios.

2.  Terminology

   The terminology is based on the softwire problem statement document
   [I-D.softwire-problem-statement].  The following terms are essential
   for this document.

   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.


3.  Softwire Model

3.1  Hub and Spokes

   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.

   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 attach to various access networks such
   as Wi-Fi hot-spots, visited office network.  Therefore, as shown in
   Figure 1, the following three use cases should be considered:

   Case 1: The softwire initiator connects to the softwire concentrator
   that belongs to the home network service provider via the home



Yamamoto, et al.        Expires December 21, 2006               [Page 3]

Internet-Draft      Softwire security considerations           June 2006


   network access provider.  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
   network access provider.  This is typical of nomadic access use case.
   The host does not subscribe to the visited network 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
   network access provider.  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 network access/service provider
   should be considered.  The details of this scenario are given in
   Section Section 4.
























Yamamoto, et al.        Expires December 21, 2006               [Page 4]

Internet-Draft      Softwire security considerations           June 2006


             visited network            visited network
             access provider            service provider
                    +---------------------------------+
                    |                                 |
             +......v......+    +.....................|......+
             .             .    .                     v      .
   +------+  .  (case 3)   .    .  +------+      +--------+  .
   |      |=====================.==|      |      |        |  .
   |  SI  |__.________     .    .  |  SC  |<---->|  AAAv  |  .
   |      |---------- \    .    .  |      |      |        |  .
   +------+  .        \\   .    .  +------+      +--------+  .
             .         \\  .    .                     ^      .
      ^      +..........\\.+    +.....................|......+
      |                  \\                           |
      |          (case 2) \\                          |
      |                    \\                         |
      |                     \\                        |
      |      +............+  \\ +.....................|......+
             .            .   \\.                     v      .
   +------+  .            .    \\__+------+      +--------+  .
   |      |  . (case 1)   .     ---|      |      |        |  .
   |  SI  |=====================.==|  SC  |<---->|  AAAh  |  .
   |      |  .            .     .  |      |      |        |  .
   +------+  .            .     .  +------+      +--------+  .
             .            .     .                            .
             +............+     +............................+
              home network                home network
             access provider            service provider

          Figure 1: Softwire hub and spokes authentication model


3.2  Mesh

   The softwire initiator and concentrator model is no more applied to
   the Mesh softwire.  The Address Family Boundary Routers (AFBRs) are
   advertising route (reachability information?) for relatively large
   network islands.  The individual fine-grained authentication is not
   necessary.

   Although the softwire for mesh must support authentication, it may be
   deactivated in some circumstances.  This means that the
   authentication is done between AFBRs.  However, if a routing protocol
   is used to advertise the softwire encapsulation, it must activate
   authentication.

   In the data plane, the security mechanism must be supported.




Yamamoto, et al.        Expires December 21, 2006               [Page 5]

Internet-Draft      Softwire security considerations           June 2006


4.  Trust Relationship

   To perform authentication between the SC and the SI, the AAA servers
   need 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 network service/access
   provider network to another (Cases 2 and 3 in Figure 1).  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:

   The SC and the AAA server in the same administrative domain must
   share a trust relationship, which can be done statically or
   dynamically by the network operator.  When the SC needs to
   authenticate the SI, the SC communicates with the AAA server to
   request authentication and/or to obtain security information.
   Therefore, the communication between the SC and the AAA server must
   be protected.  If the SI roams into a network that is not in the same
   administrative domain, the visited AAA server (AAAv in Figure 1)
   needs to communicate with the home AAA server (AAAh in Figure 1) that
   has the SI's security information.  The home and visited AAA servers,
   therefore, must share a trust relationship and the connection between
   them must also be 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 continued
   any further.

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



Yamamoto, et al.        Expires December 21, 2006               [Page 6]

Internet-Draft      Softwire security considerations           June 2006


   attack.

   A complete threat analysis of softwire requires examination of the
   protocols used for the 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).

   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



Yamamoto, et al.        Expires December 21, 2006               [Page 7]

Internet-Draft      Softwire security considerations           June 2006


       could start using its tunneling infrastructure to get free IPv6
       connectivity, transforming effectively the ISP into a IPv6
       transit provider.

   It is important to consider the differences between the hub and
   spokes and the mesh solutions with respect to security
   considerations.

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

   For Mesh model, security threat is not serious because in most cases,
   softwire is applied among the trusted domains through AFBRs.  When
   the softwire is used inside a provider network, "roaming" issues will
   not be raised.

6.  Softwire Security Requirements

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

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

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

   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.

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

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

   The Softwire protocol MUST BE able to protect the device identifier
   against spoofing when it is exchanged between the initiator and the



Yamamoto, et al.        Expires December 21, 2006               [Page 8]

Internet-Draft      Softwire security considerations           June 2006


   concentrator.

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

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

   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

7.  Guideline for IPSec usage

   Note: this section only covers the h&s softwire model.  The mesh
   scenario will be covered at a later stage.

   The Softwire security requirements state that control and data plane
   must be able to provide payload security when desired [softwire-
   problem-statement, section 2.11].  [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 h&s model context.  New
   additions to IPsec ([RFC3948],[RFC3947],[RFC4306]) are necessary to
   meet the softwire requirements were published after [RFC3193].

   The following sections will discuss [RFC3193] as applied in the
   softwire hub&spoke model.

   In softwire, L2TP is used in a voluntary tunneling model only.  The
   Softwire Initiator (SI) acts as a 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).

7.1  Softwire Security Protocol

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





Yamamoto, et al.        Expires December 21, 2006               [Page 9]

Internet-Draft      Softwire security considerations           June 2006


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

   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.


7.2  Authentication

   Softwire requirements for authentication vary from no-authentication
   to mutual authentication between the SI and SC [I-D.softwire-problem-
   statement, section 2.11].  The no-authentication mode SHOULD NOT be
   used on public IP networks.

7.2.1  PPP authentication

   PPP can provide mutual authentication between the SI and SC using
   CHAP [RFC1994] during the connection establishment phase (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 on a
   public IP network.

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

7.2.3  IPsec authentication

      pre-shared key, certificates, and (for IKEv2) an EAP exchange

      identity (IP address, DNS name, and X.500 distinguished name)

      Main mode vs. aggressive mode

      IPsec authentication vs. PPP/L2TPv2 authentication: keep both?
      [RFC3193, 5.1], user vs. machine authentication.




Yamamoto, et al.        Expires December 21, 2006              [Page 10]

Internet-Draft      Softwire security considerations           June 2006


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

7.4  IPsec filtering details

   The IPsec filtering details from [RFC3193] section 4 are applicable
   to softwire h&s model.

   Although the L2TP specification allows the responder (SC in softwire)
   to use a new IP address when sending the SCCRP, a softwire
   concentrator implementation SHOULD NOT do this ([RFC3193] section 4).
   (NOTE: this point should be discussed on the mailing list.  This
   feature may be needed for "load-balancing" between SC) [Mote: To be
   completed]

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

7.5.1  IPv6 over IPv4 Softwire with L2TPv2 example

   (To be completed)

7.5.2  IPv4 over IPv6 Softwire with example

   (To be completed)

8.  Security Considerations

   This document discusses security issues that should be considered in
   the deployment of softwire.  The requirements in Section 6, however,
   are not fully discussed yet with respect to security in service
   discovery, scaling, routing and multicast.

9.  References

9.1  Normative References

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



Yamamoto, et al.        Expires December 21, 2006              [Page 11]

Internet-Draft      Softwire security considerations           June 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.

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

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

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


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












Yamamoto, et al.        Expires December 21, 2006              [Page 12]

Internet-Draft      Softwire security considerations           June 2006


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

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


   Florent Parent
   Independent 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 December 21, 2006              [Page 13]

Internet-Draft      Softwire security considerations           June 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 December 21, 2006              [Page 14]


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