Network Working Group                                        S. Yamamoto
Internet-Draft                                               C. Williams
Expires: September 6, 2007                                KDDI R&D Labs
                                                               F. Parent
                                                              consultant
                                                               H. Yokota
                                                           KDDI R&D Labs
                                                          March 5, 2007


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

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 September 13, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   This document describes 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



Yamamoto, et al.       Expires September 13, 2007               [Page 1]


Internet-Draft      Softwire security considerations          March 2007


   mechanism such 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 . . . . . . . . . . . . . . . . . . .  5
     3.2.  Trust Relationship . . . . . . . . . . . . . . . . . . . .  6
     3.3.  Softwire Security Threat Scenarios . . . . . . . . . . . .  7
     3.4.  Softwire Security Guidelines . . . . . . . . . . . . . . . 10
       3.4.1.  Authentication . . . . . . . . . . . . . . . . . . . . 11
       3.4.2.  Softwire Security Protocol . . . . . . . . . . . . . . 11
     3.5.  Guidelines for Usage of IPsec in Softwire  . . . . . . . . 12
       3.5.1.  Authentication Issues  . . . . . . . . . . . . . . . . 12
       3.5.2.  IPsec Pre-Shared Keys for Authentication . . . . . . . 13
       3.5.3.  Inter-operability guidelines . . . . . . . . . . . . . 13
       3.5.4.  IPsec filtering details  . . . . . . . . . . . . . . . 13
       3.5.5.  IPsec SPD entries example  . . . . . . . . . . . . . . 14
   4.  Mesh Security Guidelines . . . . . . . . . . . . . . . . . . . 15
     4.1.  Deployment Scenario  . . . . . . . . . . . . . . . . . . . 15
     4.2.  Trust Relationship . . . . . . . . . . . . . . . . . . . . 16
     4.3.  Softwire Security Threat Scenarios . . . . . . . . . . . . 17
       4.3.1.  Attacks on the Control Plane . . . . . . . . . . . . . 17
       4.3.2.  Attacks on the Data Plane  . . . . . . . . . . . . . . 18
     4.4.  Applicability of Security Protection Mechanism . . . . . . 18
     4.5.  Guidelines for Usage of Security Protection Mechanism  . . 19
       4.5.1.  Security Protection Mechanism for Control Plane  . . . 19
       4.5.2.  Security Protection Mechanism for Data Plane . . . . . 21
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 21
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
     6.1.  Normative References . . . . . . . . . . . . . . . . . . . 22
     6.2.  Informative References . . . . . . . . . . . . . . . . . . 23
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
   Intellectual Property and Copyright Statements . . . . . . . . . . 26














Yamamoto, et al.       Expires September 13, 2007               [Page 2]


Internet-Draft      Softwire security considerations          March 2007


1.  Introduction

   TThe Softwire Working Group specifies the standardization of
   discovery, control and encapsulation methods for connecting IPv4
   networks across IPv6 networks and IPv6 networks across IPv4 networks.
   The Softwire provides the connectivity to enable global reachability
   of both address families by reusing or extending exisiting
   technology.  The Softwire Working Group is focusing on the two
   scenarios that emerged when discussing the traversal of networks
   composed of differing address families.  This document provides the
   security Guidelines in such two Softwire solution spaces such as
   "Hubs and Spokes" and "Mesh" scenarios Section 3andSection 4described
   in [I-D.ietf-softwire-problem-statement].  The protocols selected for
   Softwire connectivity require the Security consideration on more
   specific deployment scenarios for each solution.

   Layer Two Tunneling Protocol (L2TPv2) selected for "Hubs and Spokes"
   solution MUST use IPsec if the secure communication is
   required[RFC3193].  This document provides the implementation
   guidance (and proper usage) of IPsec as the security protection
   mechanism by considering the various security vulnerabilities in
   "Hubs and Spokes" scenarios.  IKEv2 SHOULD be used in the key
   management protocol for IPsec as the reason of the future proven
   technology as opposed to IKEv1.

   In the "Mesh" solution, Multi-Protocol Border Gateway Protocol (MP-
   BGP) is used as the signaling protocol to establish the Softwire
   connectivities among the access islands with same address families
   across the transit core to exchange the reachability information and
   softwire encapsulation attributes.  As BGP is vulnerable to various
   security attakcs[RFC4272], the adequate security protection mechanism
   MUST be implemented in BGP.  When the networks associated with
   Softwire connectivity include untrusted devices or have possibility
   of connections of those devices, the proper security protection
   mechanism MUST be used for BGP signaling together with filering at
   the Softwire end-point nodes and the secure encapsulation method MUST
   be used for data traffic.  This document provides the implementation
   guidance of IPsec as the security protection mechanism for BGP by
   referencing to the security framework for the Provider-Provisioned
   Virtual Private Networks (PPVPNs) [RFC4111].


2.  Terminology

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

   AF(i) - Address Family.  IPv4 or IPv6.  Notation used to indicate



Yamamoto, et al.       Expires September 13, 2007               [Page 3]


Internet-Draft      Softwire security considerations          March 2007


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






Yamamoto, et al.       Expires September 13, 2007               [Page 4]


Internet-Draft      Softwire security considerations          March 2007


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 (SI) always resides in the customer network.
   The node, in which the SI 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.

   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 (SC) may be used.  But in this
   document, the information on the SC 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.

   Case 1: The SI connects to the SC 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 SI connects to the SC 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 SI connects to the SC 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, the authentication infrastructure



Yamamoto, et al.       Expires September 13, 2007               [Page 5]


Internet-Draft      Softwire security considerations          March 2007


   between the SI and the SC is needed to establish the trust
   relationship.  The softwire problem statement states that the
   softwire solution must be able to be integrated with commonly
   deployed AAA solution.  In these cases, 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.

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



Yamamoto, et al.       Expires September 13, 2007               [Page 6]


Internet-Draft      Softwire security considerations          March 2007


   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
   roams into a network that is not in the same administrative domain,
   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 IPv6 networks across public IPv4
   networks and IPv4 networks across public IPv6 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).

   The softwire solution uses a subset of the Layer2Tunneling Protocol
   (L2TPv2) functionality[RFC2661], [I-D.ietf-softwire-hs-framework-
   l2tpv2].  In the Softwire "Hubs and Spokes" model, L2TPv2 is used in
   a voluntary tunnel model only.  The Softwire Initiator (SI) acts as a



Yamamoto, et al.       Expires September 13, 2007               [Page 7]


Internet-Draft      Softwire security considerations          March 2007


   L2TP Access Concentrator (LAC) and PPP endpoint.  The L2TPv2 tunnel
   is always initiated from the SI.

   Generic threat analysis done for L2TP using IPsec [RFC3193] is
   applicable to Softwire "Hubs and Spokes" deployment.  The threat
   analysis for other protocols such as PANA [RFC4016], NSIS [RFC4081],
   and Routing Protocols [RFC4593] are applicable here as well and
   should be used as reference.

   First, SI resided in the customer network sends Start-Control-
   Connection-Request(SCCRQ) packet to SC for the initiation of
   Softwire.  Optionally, L2TP exchanges Challenge and Response AVPs for
   tunnel mutual authentication in L2TPv2 tunnel creation.  For the CHAP
   authentication key, L2TPv2 protocol does not provide the key
   management facilities.

   Once L2TPv2 process has been completed, the SI and SC optionally
   enter authentication phase after completing PPP Link Control Protocol
   (LCP) negotiation.  PPP authentication supports one way or two way
   CHAP authentication, which can be interworked with AAA.  Other
   authentication PAP authentication, MS-CHAP, and EAP MAY be supported.
   But PPP authentication does not provide per-packet authentication.

   PPP encryption is defined but PPP Encryption Control Protocol (ECP)
   negotiation does not provide for a protected cipher suite
   negotiation.  PPP encryption provides a weak security solution
   [RFC3193].  PPP ECP implementation cannot be expected.  PPP
   authentication also does not provide the scalable key management.

   Once the access is granted to the SI, other protocols start for
   network configuration and the node in the SI side will exchange data
   with other nodes in the network connected through SC.

   These steps are vulnerable to man-in-the-middle (MITM), denial of
   service (DoS), and Service theft attacks, which are caused as the
   consequence of the following adversary actions.

   Adversary attacks on softwire include:

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

   2.  An adversary may try to modify both control and data packets.
       This type of attack involves integrity violations.

   3.  An adversary may try to eavesdrop and collect control messages.
       By replaying these messages, an adversary may successfully hijack
       the L2TP tunnel or the PPP connection inside the tunnel.  An



Yamamoto, et al.       Expires September 13, 2007               [Page 8]


Internet-Draft      Softwire security considerations          March 2007


       adversary might mount MITM, DOS, and theft of service attacks.

   4.  An adversary can flood the Softwire node with bogus signaling
       messages to cause DoS attacks by terminating L2TP tunnels or PPP
       connections.

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

   6.  An adversary may wish to disrupt the PPP LCP authentication
       negotiation.

   In environments where the link is shared without cryptographic
   protections and the weak authentication or one-way authentication is
   used, these security attacks can be mounted on softwire control and
   data packets.

   To access the SC through the public networks, any node can pretend to
   be a SC, if there is no prior trust relationship between SI and SC.
   In this case, an adversary may impersonate the SC to intercept
   traffic ("rogue" softwire concentrator).

   The rogue SC captures all of necessary information (including keys if
   security is present) of a legitimate Softwire node and remove the
   message of the subgroup of the network.  The rogue SC can introduce a
   black hole attack in which the attacker sends out forged routing
   packets and setup a route to some destination via itself and when the
   actual data packets get in they are simply dropped, forming a black
   hole at the SC - where data enters but never leaves.  Another
   possibility is for the attacker to forge routes pointing into an area
   where the destination node is not located.  Everything will be routed
   into this area but nothing will leave.

   The deployment of ingress filtering is able to control the malicious
   users' access.  Without specific ingress filtering checks in the
   decapsulator at SC, it would be possible for an attacker to inject a
   false packet.  This causes DoS attack.  The inner address ingress
   filtering can reject invalid inner source address.  Without inner
   address ingress filtering, another kind of attack can happen.  The
   malicious users from another ISP could start using its tunneling
   infrastructure to get free inner address connectivity, transforming
   effectively the ISP into an inner address transit provider.

   While this does not provide the complete protection in the case an
   address spoofing has been happened.  To protect address spoofing,
   authentication MUST be implemented in the tunnel encapsulation.





Yamamoto, et al.       Expires September 13, 2007               [Page 9]


Internet-Draft      Softwire security considerations          March 2007


3.4.  Softwire Security Guidelines

   Based on the security threat analysis in Section 3.3 in this
   document, Softwire security protocol must support the following
   protections.

   1.  Softwire control messages between the SI and the SC MUST BE
       protected against eavesdropping and spoofing attacks.

   2.  Softwire security protocol MUST be able to protect itself against
       replay attacks.

   3.  Softwire security protocol MUST be able to protect the device
       identifier against the impersonation when it is exchanged between
       the SI and the SC.

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

   5.  Softwire security protocol MUST be able to protect disconnect and
       revocation messages.

   The Softwire security protocol requirement is comparable to RFC3193.
   For Softwire control packets, authentication, integrity and replay
   protection MUST be supported and confidentiality SHOULD be supported.
   For Softwire data packets, authentication, integrity and replay
   protection MUST be supported and confidentiality MAY be supported.

   The Softwire problem statement [I-D.ietf-softwire-problem-statement]
   provides some requirements for "Hubs and Spoke" solution that are
   taken into account in defining the security protection mechanisms.

   1.  control and/or data plane must be able to provide full payload
       security when desired.

   2.  deployed technology must be very strongly considered

   This additional security protection must be separable from the
   Softwire tunneling mechanism.

   Note that 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.  But this is out of scope of
   this document.






Yamamoto, et al.       Expires September 13, 2007              [Page 10]


Internet-Draft      Softwire security considerations          March 2007


3.4.1.  Authentication

   The softwire security protocol MUST support user authentication in
   the control plane, in order to authorize access to the service, and
   provide adequate logging of activity.  The protocol SHOULD offer
   mutual authentication in scenarios where the SI requires identity
   proof from the SC, for example, SI accesses to SC across the public
   network.

   In some circumstances, the service provider may decide to allow non-
   authenticated connection [I-D.softwire-hs-framework-l2tpv2].  For
   example, when the customer is already authenticated by some other
   means, such as closed networks, cellular networks at Layer 2, etc.,
   the service provider may decide to turn it off.  If no authentication
   is conducted on any layer, the SC acts as a gateway for anonymous
   connections.  Running such a service MUST be configurable by the SC
   administrator and the SC SHOULD take some security measures such as
   ingress filtering and adequate logging of activity.  It should be
   noted that anonymous connection service cannot provide the security
   functionalities described in this document (e.g. integrity, replay
   protection and confidentiality).

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

3.4.2.  Softwire Security Protocol

   To meet the above requirements, all softwire security compliant
   implementations MUST implement the following security protocols.

   IPsec ESP[RFC4303]in transport mode for securing softwire control and



Yamamoto, et al.       Expires September 13, 2007              [Page 11]


Internet-Draft      Softwire security considerations          March 2007


   data packets.  Internet Key Exchange (IKE) protocol[RFC3947] MUST be
   supported for authentication, security association negotiation and
   key management for IPsec.  The applicability of different version of
   IKE is discussed in Section 3.5 .

   The softwire security protocol MUST support NAT traversal.  UDP
   encapsulation of IPsec ESP packets[RFC3948] and negotiation of NAT-
   traversal in IKE[RFC3947] MUST be supported when IKEv1 is used.

3.5.  Guidelines for Usage of IPsec in Softwire

   [RFC3193] discusses how L2TP can use IPsec to provide tunnel
   authentication, privacy protection, integrity checking and replay
   protection [RFC4306].  Since it's publication, revision to IPsec
   protocols have been published (IKEv2 [RFC4306], ESP [RFC4303], NAT-
   traversal for IKE [RFC3947] and ESP[RFC3948]).

   Although [RFC3193]can be applied in the softwire "Hubs and Spokes"
   solution.  To meet softwire requirements such as NAT-traversal, NAT-
   traversal for IKE [RFC3947] and ESP[RFC3948] MUST be supported.

   IKEv2 [RFC4306] offers NAT-traversal.  IKEv2 also supports EAP
   authentication with the authentication using shared secrets and
   public key signatures.  IKE is more reliable protocol than IKEv1 and
   the future proof technology.  New implementations SHOULD use IKEv2
   over IKEv1.  There are cases where IKEv1 may be needed, e.g. an
   existing deployment of clients using L2TPv2 with IKEv1.

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

   The following sections will discuss using IPsec to protect L2TPv2 as
   applied in the softwire "Hubs and Spokes" model.  Both IKEv1 (based
   on [RFC3193]) and IKEv2 examples will be given.

3.5.1.  Authentication Issues

   IPsec implementation using IKEv1 only supports machine
   authentication.  There is no way to verify a user identity and to
   segregate the tunnel traffic among users in the multi-user machine
   environment.  When the user identity is required, the extension of
   IKE is required, for example, Xauth is commonly used but not
   standardized.  Whereas, the IKEv2 can support user authentication
   with EAP payload by leveraging existing authentication infrastructure
   and credential database.  This enables the traffic segregation among
   users when user authentication is used by combining the legacy
   authentication.  The user identity asserted within IKEv2 will be



Yamamoto, et al.       Expires September 13, 2007              [Page 12]


Internet-Draft      Softwire security considerations          March 2007


   verified on a per-packet basis.

   If the AAA server is involved to establish a security association
   between the SI and SC, a session key can be derived from the
   authentication between the SI and the AAA server.  Such a scenario
   can be found in [I-D.draft-eronen-ipsec-ikev2-eap-auth-05].
   Successful EAP exchanges within IKEv2 runs between the SI and the AAA
   server create a session key and it is securely transferred to the SC
   from the AAA server.  The trust relationship between the involved
   entities follows Section 3.2 of this document.

3.5.2.  IPsec Pre-Shared Keys for Authentication

   With IPsec, when the identity asserted in IKE is authenticated, the
   resulting derived keys are used to provide per-packet authentication,
   integrity and replay protection.  As a result, the identity verified
   in the IKE is subsequently verified on reception of each packets.
   [RFC3193, 5.1]

   Authentication using pre-shared keys can be used when the number of
   SI and SC is small.  AS the number of SI and SC grow, pre- shared
   keys becomes increasingly difficult to manage.  A softwire security
   protocol must provide a scalable approach to key management.
   Whenever possible, authentication with certificates is preferred.
   ([RFC3193], 4.1).

   If pre-shared keys are used, group pre-shared keys MUST NOT be used
   because of its vulnerability to Man-In-The-Middle attacks ([RFC3193],
   5.1.4).

3.5.3.  Inter-operability guidelines

   The L2TPv2/IPsec inter-operability concerning tunnel teardown,
   fragmentation and per-packet security checks must be followed by
   guidelines given in ([RFC3193] section 3).

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.





Yamamoto, et al.       Expires September 13, 2007              [Page 13]


Internet-Draft      Softwire security considerations          March 2007


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.  Note that the examples are IKEv1 specific.

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.



      src       dst      Protocol                   Action
     -----     ------    --------                   ------
    IPV4-SI   IPV4-SC      ESP  (ports 500,4500)   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)


                          Softwire initiator SPD



      src       dst      Protocol                   Action
     -----     ------    --------                   ------
       *      IPV4-SC      ESP  (ports 500,4500)   BYPASS
       *      IPV4-SC      IKE                     BYPASS
       *      IPV4-SC      UDP, src * , dst 1701   PROTECT(ESP,transport)


                         Softwire concentrator SPD

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.



      src       dst      Protocol                   Action
     -----     ------    --------                   ------
    IPV6-SI   IPV6-SC      ESP  (ports 500,4500)    BYPASS
    IPV6-SI   IPV6-SC      IKE                      BYPASS
    IPv6-SI   IPV6-SC      UDP, src 1701, dst 1701  PROTECT(ESP,transport)
    IPv6-SC   IPv6-SI      UDP, src * , dst 1701    PROTECT(ESP,transport)




Yamamoto, et al.       Expires September 13, 2007              [Page 14]


Internet-Draft      Softwire security considerations          March 2007


                          Softwire initiator SPD



      src       dst      Protocol                   Action
     -----     ------    --------                   ------
       *      IPV6-SC      ESP  (ports 500,4500)  BYPASS
       *      IPV6-SC      IKE                    BYPASS
       *      IPV6-SC      UDP, src * , dst 1701  PROTECT(ESP,transport)


                         Softwire concentrator SPD


4.  Mesh Security Guidelines

4.1.  Deployment Scenario

   In the softwire "Mesh" solution, 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
   perform as Provider Edge routers (PE) within an autonomous system or
   perform peering across autonomous systems.  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.

   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 will
   be established.

   For the connectivity between CE and PE routers, the following two
   cases should be considered.  Note that 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).




Yamamoto, et al.       Expires September 13, 2007              [Page 15]


Internet-Draft      Softwire security considerations          March 2007


   Case 1: When AFBRs are PE routers located at the edge of the provider
   core networks, this is similar architecture of Provider Provisioned
   PE-based VPN.  The connectivity between a CE router in access island
   network and a PE router in transit network is established by static
   way.  The access islands are enterprise networks accommodated through
   PE routers in the provider's transit network.  In this case, the
   access island networks are operated within the provider's autonomous
   system.

   When the access island networks have their own AS number, inter-AS
   model can be applied for the connections among the access island
   networks.  CE routers located inside access islands form a peering
   relationship with AFBRs in the transit network autonomous system to
   exchange AF access island reachability information using eBGP.

   Case 2: As alternative model, a single-stack AF(j) PE node is
   applicable, the AFBR function of the dual-stack AF(i,j) processing is
   moved to CE routers located at the edge of a customer site.  This is
   the dual-stack CE model.  The CE device has the IP connectivity with
   service provider's PE device over the access connection.  The
   customer's access network belongs to provider's autonomous system.
   This model might evolve inter-CE BGP peering to exchange users' AF
   prefixes/next-hops.

   For this managed CE-based model, users in access networks have to
   have a fairly high level of trust that the service provider will
   properly provision and manage the CE devices.

4.2.  Trust Relationship

   In case 1, all AFBR nodes 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 nodes (e.g.
   AFBR, PE or Route Reflector, if applicable) are trusted with each
   other.  If the transit core consists of multiple autonomous systems,
   intermediate routers between AFBRs may not be trusted when back-to-
   back AFBRs are not available.  There MUST be a trust relationship
   between the PE in the transit core and the CE in the corresponding
   island, although the link(s) between the PE and the CE may not be
   protected.

   For the dual-stack CE model in Case 2, CE nodes of iBGP speakers in
   the access island network MUST have the trust relationship with each
   other.  In addition, users in the access island networks and the
   transit core provider MUST have the trust relationship.  The security
   protection mechanism can be applied for CE-to-CE in either a
   provider-provisioned or a user provisioned model.  Note that the
   user-provisioned CE-CE security protection mechanism is outside the



Yamamoto, et al.       Expires September 13, 2007              [Page 16]


Internet-Draft      Softwire security considerations          March 2007


   scope of this document.

4.3.  Softwire Security Threat Scenarios

   The architecture of softwire mesh solution is very similar to that of
   the provider provisioned VPN (PPVPN) [RFC 4111].  The security
   threats considerations on the PPVPN operation are applicable to those
   in the softwire mesh solution.

   The security attacks can be mounted on both the control plane and the
   data plane.  In softwire mesh solution, softwires encapsulation will
   be setup by using MP-BGP.  MP-BGP does not change the security issues
   inherent in 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 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.  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
       the network infrastructure itself, certain bogus information can



Yamamoto, et al.       Expires September 13, 2007              [Page 17]


Internet-Draft      Softwire security considerations          March 2007


       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.  Applicability of Security Protection Mechanism

   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 relationship among users in access networks, transit core
   provider, and other parts of networks described in section 4.2 is a
   key element in determining the applicability of security protection
   mechanism for the specific softwire mesh deployment.

   The Softwire Problem Statement [I-D.ietf-softwire-problem-statement]
   states that the softwire mesh setup mechanism MUST support
   authentication, but the transit core provider may decide to turn it
   off in some circumstances.  If a routing protocol is used to
   advertise the softwire encapsulation, it must also support
   authentication.

   In the data plane, the softwire must support IPsec and a IPsec



Yamamoto, et al.       Expires September 13, 2007              [Page 18]


Internet-Draft      Softwire security considerations          March 2007


   profile must be defined.

   In particular, it determines where encryption should be applied, as
   follows [RFC4111]

   - If the link(s) between the user's site and the provider's PE is not
   trusted, then encryption may be used on the PE-CE link(s).

   - If some part of the transit core network is not trusted, PE-PE path
   may be encrypted.

   The access control technique reduces the exposure to attacks from
   outside the service provider networks.  The access control technique
   includes 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 softwire mesh.

   The access control technique is an important protection against
   security attacks of DoS etc. and a necessary adjunct to cryptographic
   strength in encapsulation.  Packets that match the 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.

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

   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.

   The BGP specification requires that a BGP must support the
   authentication mechanism specified in [RFC2385].  However the
   security mechanism for BGP transport (e.g.  TCP-MD5) is inadequate
   and requires significant operator interaction to maintain a
   respectable level of security.  The current deployments of TCP-MD5
   exhibit serious shortcomings with respect of key management as



Yamamoto, et al.       Expires September 13, 2007              [Page 19]


Internet-Draft      Softwire security considerations          March 2007


   described in [RFC3562]

   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.

   Key management can be especially cumbersome 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], [RFC4107]

4.5.1.1.  IKE/IPsec

   Use of IPsec 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.  If eavesdropping attack is
   identified as a threat, ESP can be used to provide confidentiality
   (encryption), integrity and authentication for the BGP session.

   To provide replay protection, automated key management system using
   IKEv2 must be used.  IKEv2 can be applied 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.2.  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, and a new BGP path attribute ("attestations") to ensure
   the authenticity and integrity of BGP communication on a point-to-



Yamamoto, et al.       Expires September 13, 2007              [Page 20]


Internet-Draft      Softwire security considerations          March 2007


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

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

   The several of the attacks are 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].

   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 solution, IPsec tunnels can be established on
   selective basis using Tunnel SAFI announced by AFBRs.  The softwire
   mesh framework [wu-softwire-mesh-framework] currently supports many
   tunnel encapsulation type using a "Softwire Mesh Encapsulation
   Attribute" announced 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 ( encryption or NULL
   encryption), transport or tunnel mode, key management (IKE SA
   parameters), 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).


5.  Security Considerations

   This document discusses various security threats for the softwire
   control and data packets in "Hubs and Spokes" and "Mesh" time-to-
   market solutions.  With these discussions, the softwire security
   protocol implementations are provided referencing to Softwire Problem



Yamamoto, et al.       Expires September 13, 2007              [Page 21]


Internet-Draft      Softwire security considerations          March 2007


   Statement [I-D.ietf-softwire-problem-statement], Securing L2TP using
   IPsec[RFC3193], Security Framework for PPVPNs [RFC4111], and
   Guidelines for Mandating the Use of IPsec [I-D.bellovin-useipsec].The
   guidelines for the security protocol employment are also given
   considering the specific deployment context.

   Note that this document discusses the softwire tunnel security
   protection and does not address the end-to-end protection.


6.  References

6.1.  Normative References

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

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

   [RFC2385]  Heffernan, A., "Protection of BGP Sessions via the TCP MD5
              Signature Option", RFC 2385, August 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.

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



Yamamoto, et al.       Expires September 13, 2007              [Page 22]


Internet-Draft      Softwire security considerations          March 2007


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

   [I-D.ietf-softwire-hs-framework-l2tpv2]
              Storer, B., "Softwires Hub & Spoke Deployment Framework
              with L2TPv2", draft-ietf-softwire-hs-framework-l2tpv2-03
              (work in progress), February 2007.

   [I-D.rpsec-bgpsecrec]
              Christian, B. and T. Tauber, "BGP Security Requirements",
              draft-ietf-rpsec-bgpsecrec-06 (work in progress),
              April 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.white-sobgp-architecture]
              White, R., "Architecture and Deployment Considerations for
              Secure Origin BGP (soBGP)",
              draft-white-sobgp-architecture-02 (work in progress),
              June 2006.

   [I-D.wu-softwire-mesh-framework]
              Wu, J., "Softwire Mesh Framework",
              draft-wu-softwire-mesh-framework-02 (work in progress),
              March 2007.

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




Yamamoto, et al.       Expires September 13, 2007              [Page 23]


Internet-Draft      Softwire security considerations          March 2007


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


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




Yamamoto, et al.       Expires September 13, 2007              [Page 24]


Internet-Draft      Softwire security considerations          March 2007


   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 September 13, 2007              [Page 25]


Internet-Draft      Softwire security considerations          March 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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.

   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, THE IETF TRUST 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.


Intellectual Property

   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.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Yamamoto, et al.       Expires September 13, 2007              [Page 26]