Network Working Group                                         M. Bagnulo
Internet-Draft                                        Huawei Lab at UC3M
Intended status: Informational                              July 8, 2007
Expires: January 9, 2008


                    Preliminary LISP Threat Analysis
                      draft-bagnulo-lisp-threat-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 January 9, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   This document performs a preliminary threat analysis on the
   Locator/ID Separation Protocol (LISP) as defined in
   draft-farinacci-lisp-01.txt.








Bagnulo                  Expires January 9, 2008                [Page 1]


Internet-Draft      Preliminary LISP Threat Analysis           July 2007


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Application Scenario . . . . . . . . . . . . . . . . . . . . .  3
   3.  Threat analysis  . . . . . . . . . . . . . . . . . . . . . . .  5
     3.1.  Identity hijacking . . . . . . . . . . . . . . . . . . . .  5
       3.1.1.  Attacks using the LISP data packets to create state  .  5
       3.1.2.  Attacks using the Map-Reply message to create state  . 10
     3.2.  DoS attacks  . . . . . . . . . . . . . . . . . . . . . . . 12
       3.2.1.  Flooding a third party . . . . . . . . . . . . . . . . 12
       3.2.2.  Preventing future communications . . . . . . . . . . . 13
       3.2.3.  Interrupt ongoing communication  . . . . . . . . . . . 13
       3.2.4.  DoS attacks against LISP infrastructure  . . . . . . . 13
   4.  Security considerations  . . . . . . . . . . . . . . . . . . . 14
   5.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 14
   6.  Normative References . . . . . . . . . . . . . . . . . . . . . 14
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15
   Intellectual Property and Copyright Statements . . . . . . . . . . 16

































Bagnulo                  Expires January 9, 2008                [Page 2]


Internet-Draft      Preliminary LISP Threat Analysis           July 2007


1.  Introduction

   The Locator/ID Separation Protocol (LISP) is defined in
   draft-farinacci-lisp-01.txt [1].  The goal of this document is to
   identify the different threats in the current LISP protocol in order
   to understand the current level of protection of the LISP protocol
   and identify additional security mechanisms that are needed to
   protect it.

   As in any ID/loc split approach, the critical operation is the
   creation of ID to locator binding state in any device that will use
   it later on.  In the particular case of LISP the critical operation
   is the creation of EID to RLOC mappings in the ITR and the ETR.  Such
   operation is performed in 3 different ways:

   Using the information obtained from a LISP data packet (looking into
   the EID and RLOC information included by the originator of the
   packet)

   Using the information contained in the Map-Reply message

   Using a EID-to-RLOC database

   This document performs threat analysis for the first two cases.  The
   third case, the one of the EID-to-RLOC database, has a different
   trust model, and a specific threat analysis needs to be performed for
   that case.


2.  Application Scenario

   We will consider the following application scenario.



















Bagnulo                  Expires January 9, 2008                [Page 3]


Internet-Draft      Preliminary LISP Threat Analysis           July 2007


   +----+
   | HA |
   +----+
     | EID: P1:IIDA
    -----------------
        |         |     RLOC: P1:IIDLR1, P2:IIDLR2
      +----+    +----+
      |LR1 |    |LR2 |
      +----+    +----+
        |         |
        |         |
     +----+     +----+
     |ISP1|     |ISP2|
     +----+     +----+     +----+
       |           |    +--| HC |  IPC
    +----------------+  |  +----+
    |                |--+
    |    Internet    |     +----+
    |                |-----| AT | IPAT
    +----------------+     +----+
        |
        |
     +----+     +----+
     |LR3 |     | HB |
     +----+     +----+
       |           | EID=IPB RLOC=IPLR3
    --------------------



   LR: LISP Router that behaves as both as the ITR and the ETR

   In the depicted scenario we have two LISP capable sites.  One of the
   sites, depicted on top of the figure, is multihomed to ISP1 and ISP2.
   We assume that we are using LISP1, so one of the routable addresses
   is used as EID, let's say that for host HA P1:IIDA is used as EID.
   In addition, the locators for that host will be the two addresses of
   the exit routers that are playing the role of ITR namely LR1 and LR2,
   so RLOCs are P1:IIDLR1 and P2:IIDLR2.

   (LR stands for LISP router since it plays both the roles of ITR and
   ETR).

   The other LISP capable site is the one depicted in the lower part of
   the figure and it has a single ISP and a single ITR/ETR namely, LR3.
   Host H3 located in this site has IPB as EID and the address of the
   LR3, LPLR3 as RLOC.  Since we are using LISP1, IPB is a routable
   address



Bagnulo                  Expires January 9, 2008                [Page 4]


Internet-Draft      Preliminary LISP Threat Analysis           July 2007


   Hosts HC and AT are other hosts in the Internet, with addresses IPC
   and IPAT respectively.

   HA, HB and HC are victims and AT is the attacker.


3.  Threat analysis

   Full-time off-path attacker assumption

   We will limit the considered attacks to those where the attacker is
   not located along the path used to route packets of the communication
   being attacked during the whole duration of the attack.

   There are then two type of attacks:

   - Off-path attacks the attacker is off-path during the whole duration
   of the attack

   - Time shifted attacks: the attacker is located along path during a
   limited period, but the duration of the attack is significantly
   longer than the period that the attacker is along the path.

3.1.  Identity hijacking

   In the attacks considered in this section the attacker will try to
   hijack the identity of one victim on the eyes of another victim.
   This means that two parties are deceived, one that thinks that is
   communicating with the owner of a given identify, but it is
   communicating with the attacker instead and the party whose identify
   is being stolen.

   As we mentioned earlier, there are two messages an attacker can use
   to create the state required to launch an attack: the LISP data
   packets or the Map-Reply message.  In this section we will first
   present the attacks based on using the LISP data packets and then the
   attacks that use the Map-Reply messages.

3.1.1.  Attacks using the LISP data packets to create state

3.1.1.1.  Attacker initiated communication (Hijacking a client identity)

   In this case, the attacker will initiate a communication with one
   victim pretending to be someone else.

   In the scenario above, the attacker AT will try to initiate a
   communication with HA pretending to be HC.  In order to do that it
   will send a LISP packet with the following parameters:



Bagnulo                  Expires January 9, 2008                [Page 5]


Internet-Draft      Preliminary LISP Threat Analysis           July 2007


   - Destination RLOC (outer header destination address): P1:IIDA

   - Destination EID (Inner header destination address): P1:IIDA

   - Source RLOC (outer header source address): IPAT

   - Source EID (inner header source address): IPC

   The packet will be received by LR1 who will generate the LISP Map-
   Reply message back to IPAT and will store the EID to RLOC mapping
   information for the received data packet.  The EID to RLOC mapping
   information stored at LR1 contains the following information: EID =
   IPC, RLOC=IPAT

   In this case HA will be communicating with the attacker AT but HA
   believes that he is communicating with HC.  HC identity has been
   stolen by AT in the eyes of HA.

   Basically, in this case the packet that triggers all of this is (sent
   from AT toward HA (who's EID is P1:11DA)) looks like:


               DST      SRC
            +---------+------+
            | P1:IIDA | IPAT |<-- RLOC (outer)
            +---------+------+
            | P1:IIDA | IPC  |<-- EID  (inner)
            +---------+------+


   The mapping installed in LR1 is {EID, RLOC} = {IPC, IPAT}, and thus
   HC's identity is hijacked (at least from HA's perspective) by AT
   (since it thinks that IPAT is the RLOC associated with EID HC =
   inaddr(IPC)).  As a result, subsequent packets emitted by HA will
   look like


              DST     SRC
            +-----+---------+
            | IPC | P1:IIDA |
            +-----+---------+


   and LR1 will encap as follows (giving the installed mapping):







Bagnulo                  Expires January 9, 2008                [Page 6]


Internet-Draft      Preliminary LISP Threat Analysis           July 2007


              DST      SRC
            +------+----------+
            | IPAT | P1:IIDR1 |  outer
            +------+----------+
            | IPC  | P1:IIDA  |  innner
            +------+----------+


   and the hijack is complete.

3.1.1.2.  Victim initiated communication (Hijacking a server identity)

   In the previous section, the attacker is hijacking the identity of a
   client, since the attacker is the one that initiates the
   communication.  While this is problematic, a much more ambitious
   attacks would to hijack the identity of a server, i.e. to hijack the
   identity of a server when the victim initiates a communication
   towards the server.

   This is also possible with LISP.  It would work in the following way.

   Suppose that HC is a server that HA uses regularly (e.g. a newspaper
   web site)

   Suppose that AT wants that future communication initiated by HA to HC
   are directed to AT i.e.  AT wants to hijack HC identity for all the
   communications initiated by HA.

   In order to do that, AT performs the following actions.  It first
   needs to install false EID-to-RLOC mapping information in LR1.  In
   order to do that, it sends a data packet containing the following
   information

   - Destination RLOC (outer header destination address): P1:IIDA

   - Destination EID (Inner header destination address): P1:IIDA

   - Source RLOC (outer header source address): IPAT

   - Source EID (inner header source address): IPC

   The data packet could be a UDP packet that will be discarded upon
   reception because there is no process listening in the requested
   port.

   LR1 will store that in order to reach IPC it must tunnel the packets
   to IPAT.




Bagnulo                  Expires January 9, 2008                [Page 7]


Internet-Draft      Preliminary LISP Threat Analysis           July 2007


   However, there is no actual ongoing communication between HA and HC
   at the moment, so the attack has no effect so far.  The attacker must
   then keep the EID to RLOC mapping information alive in LR1 for when
   HA decides to initiate a communication to HC.  The attacker can do
   that by sending periodic data packets with the same information
   detailed before.

   Suppose that at any point in the future, HA decides to initiate a
   communication with HC.  It will send a data packet with destination
   address IPC.  The data packet will be intercepted by LR1 and
   tunnelled to the attacker at IPAT, since this is the mapping
   information available at LR1.

   Note that these attacks affect all future communications started by
   HA and that it affects communication initiated by HA.

3.1.1.3.  Intercepting ongoing communications (becoming a MITM)

   In the two previous sections, we have considered the case where the
   attacker wants to hijack a future communication pretending to be one
   of the involved parties.

   In this section we will consider the case where there is an ongoing
   communication and the attacker wants to hijack the ongoing
   communication.

   Suppose that there is an ongoing communication between HA and HB.  In
   this case, LR1 contains a mapping between EID=IPB and RLOC=IPLR3.
   LR3 contain a mapping between EID= P1:IIDA and RLOC=P1:IIDLR1, P2:
   IIDLR2.

   Suppose now that AT sends two packets, one to LR1 and another to LR3.

   The packet sent to LR1 will contain mapping information of EID=IPB
   and RLOC=IPAT.  The packet sent to LR3 will contain mapping
   information EID=P1:IIDA and RLOC=IPAT.

   (One may think that ingress filtering could help here, but note that
   the attacker is sending packets from the claimed locator, so ingress
   filters won't be of any use to prevent this attack)

   If the new EI-to-RLOC information overrides the previously available
   mapping information (this would depend on how the new mapping
   information is managed, but it seems that in the current version,
   latest information supersedes older information) , the result is that
   LR1 will tunnel packets addressed to HB to the attacker at IPAT and
   LR2 will tunnel packets addressed to HA to the attacker at IPAT.  The
   attacker has now placed himself as a man in the middle in the



Bagnulo                  Expires January 9, 2008                [Page 8]


Internet-Draft      Preliminary LISP Threat Analysis           July 2007


   communication.  It can either modify packets or simply sniff them.

   In this case, packets exchanged in this attack would look like this:
   Suppose HA and HB are communicating.  In this case, LR1 has
   {IPB,IPLR3} and LR3 has {P1:IIDA, {P1:IIDLR1, P2:IIDLR2}} (P1:IIDA
   has 2 possible RLOCs).  Now, the attacker at IPAT sends


               DST      SRC
            +---------+------+
            | P1:IIDA | IPAT |<-- RLOC (outer)
            +---------+------+
            | P1:IIDA | IPB  |<-- EID  (inner)
            +---------+------+

   to HA. the packet is intercepted by LR1, which results in the mapping
   {IPB, IPAT} (so AT has half of the connection).  That is, packets
   from HA -> HB look like


              DST     SRC
            +-----+---------+
            | IPB | P1:IIDA |
            +-----+---------+


   LR1 builds


              DST       SRC
            +------+-----------+
            | IPAT | P1:IIDLR1 |
            +------+-----------+
            | IPB  | P1:IIDA   |
            +------+-----------+


   and packets are delivered to the MITM.

   Going the other way, AT sends


              DST     SRC
            +-----+---------+
            | IPB |  IPAT   |<-- RLOC (outer)
            +-----+---------+
            | IPB | P1:IIDA |<-- EID  (inner)
            +-----+---------+



Bagnulo                  Expires January 9, 2008                [Page 9]


Internet-Draft      Preliminary LISP Threat Analysis           July 2007


   to HB.  The packet is intercepted by LR3, which results in the
   mapping {P1:IIDA, IPAT} (so AT has the other half of the connection),
   so packets sent to P1:IIDA (HA) get delivered to AT (inaddr(IPAT)).

3.1.2.  Attacks using the Map-Reply message to create state

   Map-Reply messages are protected by a nonce, which is copied from the
   LISP data packet that triggered the Map-Reply generation.  Such nonce
   protects from Map-Reply messages generated spontaneously (i.e. not
   generated as a reply to an actual LISP data packet).  While this
   protection prevents a number of attacks, there are still a few
   attacks that are possible, which are presented in this section.

3.1.2.1.  Less-specific prefix attack

   Map-Reply messages are very powerful because they can contain single
   EIDs but also EID prefixes.  Such capability allows any malicious
   party receiving a LISP data packet to reply with a Map-Reply message
   that includes a less specific EID prefix that contains more than its
   own EIDs.  Basically, the problem here is that the return routability
   check only verifies the presence of a single EID and not the whole
   EID prefix.  The attack could be performed in the following way:

   For whatever reason, HB decides to start a communication with AT.  HB
   generates a data packet containing:


              DST    SRC
            +------+-----+
            | IPAT | IPB |
            +------+-----+


   and LR3 will encap as follows:


              DST      SRC
            +------+-------+
            | IPAT | IPLR3 |  outer
            +------+-------+
            | IPAT | IPB   |  innner
            +------+-------+


   In addition, the encapsulated packet will contain a nonce NB.

   AT will receive the packet, will store the state corresponding to HB
   (EID=IPB, RLOC=IPLR3).  In addition, AT can reply with a Map_Reply



Bagnulo                  Expires January 9, 2008               [Page 10]


Internet-Draft      Preliminary LISP Threat Analysis           July 2007


   message.  However, AT can reply with an Map-Reply message that
   contains amore specific prefix that contains other prefixes than its
   own.  In particular, AT can include the 0/0 prefix in the Map-Reply
   message.  The Map-Reply message is validated by the nonce NB the was
   included in the received ISP data packet.  The Map-Reply message that
   AT will send back to LR3 will be:

   - Nonce: NB

   - EID mask-len: 0

   - EID prefix: 0

   - Locator: IPAT

   Upon the reception of such Map-Reply message, LR3 will install the
   EID-to-RLOC mapping which will map the whole EID space to the
   attacker locator IPAT.  All the following packets routed by LR3 will
   be forwarded to the attacker AT.  Note that this not only affects the
   packets generated by HB but to all the packets generated by any host
   behind LR3.  Also note that this is the more extreme case, where the
   whole EID space is hijacked, but it would also be possible to hijack
   parts of the EID space, which would result in less severe attacks,
   but probably more difficult to detect.

3.1.2.2.  Time-shifted attack

   Time-shifted attacks are those where the attacker is located along
   the path during a short period and launches an attack that persists
   in time long after the attacker left the on-path position.  These
   attacks have been considered relevant during the design of other
   protocols for mapping identities and location, such as MIP.  In
   particular, in order to prevent time-shifted attacks in MIPv6 route
   optimization, the MIPv6 specification requires the periodic
   performance of the return routability check.  The lifetime of the
   state created using the validation information obtained using a
   single return routability check is limited to 7 minutes in the MIPv6
   spec.  This implies that the maximum time span that a time-shifted
   attack can be active after the attacker left the on-path position is
   7 minutes.  For additional information about the MIPv6 security
   design, the reader is referred to [2].

   In the case of LISP, an attacker can launch a time-shifted attacks if
   he is able to learn a nonce of a LISP data packet generated by the
   victim.  Once the attacker has obtained the nonce, it can then
   generate a Map-Reply message and hijack any portion of the the EID
   space, thanks to the aforementioned capabilities of EID aggregation
   by the means of less-specific EID prefixes.  The Map-reply message



Bagnulo                  Expires January 9, 2008               [Page 11]


Internet-Draft      Preliminary LISP Threat Analysis           July 2007


   would be accepted by the victim because it contains a valid nonce and
   it will install the ED-to-RLOC mapping.  The state will remain in the
   victim even when the attacker has left the on-path position.  The
   attacker is able to keep the state alive by refreshing the state (is
   likely that LISP provides some means for this since it should be able
   for a genuine host to preserve the state in its peers, even when the
   original path is unreachable)

   The attack is then as follows:

   The attacker is located along a path sniffing packets and looking for
   any LISP data packet generated by the victim.

   Once the attacker finds such a packet, it learns the nonce in the
   LISP header.

   The attacker generated a Map-Reply packet containing the nonce, the
   EID prefix 0/0 and its own locator.

   The attacker sends the Map-Reply which is processed by the victim's
   router which installs the state.

   From this moment, all the outgoing packets of the victim's site are
   forwarded to the locator selected by the attacker.

   The attacker can leave its position and move to its own locator, but
   the attack is still active, since the state is still installed in the
   victim's router.

3.2.  DoS attacks

   In this section, we describe DoS attacks related to LISP.

3.2.1.  Flooding a third party

   In this case, the attacker AT wants to use HA to flood a victim HC.

   In order to do that, AT first initiates a communication with HA and
   starts a download of a heavy flow.  Once that the flow is
   downloading, it redirects the heavy flow towards HC, flooding it.
   This is performed in the following way.

   AT initiates a communication with HA.  In this case, AT uses IPAT as
   EID and IPAT as RLOC.  This mapping information is stored in LR1
   since it is contained in the initial LISP data packet as described
   previously.  AT then starts downloading a heavy flow form HA.  At
   some point then, AT redirects the flow towards HC.  It can do so by
   including IPC as a RLOC for the EID IPAT that is being used in the



Bagnulo                  Expires January 9, 2008               [Page 12]


Internet-Draft      Preliminary LISP Threat Analysis           July 2007


   communication that is downloading the heavy flow.  The IPC RLOC could
   be included since the beginning with a low priority and now simply
   send a LISP Map-Reply message with a higher priority to IPC.  In any
   case the result is that the flow will flood HC.(Note that it is
   expected that AT can include additional locators associated to the
   EID IPAT during the initial period where there is a direct
   communication between AT and HA)

   It should be noted that in some cases, in order to keep the flow
   going, it is necessary that the receiver sends some ACK packets or
   similar.  In this case, it is possible that the attacker can send
   such packets, since EID IPAT in LR1 can contain two valid RLOCs i.e.
   IPAT and IPC.  In this case, if IPC has higher priority that IPAT,
   LR1 will send packets to IPC but will accept packets coming from IPAT
   as valid packets from the EID IPAT.  In this case, the attacker could
   send ACK packets from its own location, and keep the flooding going
   towards IPC.

3.2.2.  Preventing future communications

   This case is similar to the one described in section Victim initiated
   communication (Hijacking a server identity), but only that instead of
   the attackers RLOC, a black hole IP address is included as the RLOC
   for a given EID.  The result is that the traffic addressed to the EID
   is sent to a black hole, resulting in a DoS attacks form
   communications to that EID.

   In addition to that, it is possible to use the Less-specific prefix
   attack to perform a DoS attack.  In this case, a larger number of
   destinations are affected, since it affects a whole prefix.

   Finally, it should be noted that the attacks do not affect the
   traffic generated by a single machine, but to all the traffic routed
   by the affected ITR i.e. to the traffic generated by all the hosts
   behind the ITR.

3.2.3.  Interrupt ongoing communication

   This case is similar to the one described in the section Intercepting
   ongoing communications (becoming a MITM) with the only difference
   that an back hole IP address is included as RLOC for the ongoing
   communication, terminating it.

3.2.4.  DoS attacks against LISP infrastructure

   Another type of DoS attacks that must be considered are the DoS
   attacks against the LISP architecture itself.  LISP infrastructure is
   likely to become a critical part of the network, since EIDs may not



Bagnulo                  Expires January 9, 2008               [Page 13]


Internet-Draft      Preliminary LISP Threat Analysis           July 2007


   be reachable without the LISP service.  This makes the LISP routers a
   preferred target for attackers.

   In particular LISP routers (ITR and ETR) are susceptible to DoS
   attacks.  LISP routers store information about EID-to- RLOC mappings.
   They learn that information from data packets and from ICMP messages.
   An attacker could massively generate either tunnelled data packets so
   that the router cache is overflowed.  The result is that routers will
   not be able to store legitimate EID-to-RLOC mapping information and
   that LISP features will be annulled. (in the case of using non
   routable EIDs, all communication would be annulled if LISP
   functionality is not available)

   Current LISP proposal includes rate-limiting techniques for
   protecting against DoS attacks.  Such technique can be useful to
   prevent LISP routers from crashing under the attack.  However, this
   technique does not prevent the actual effect of the attack, which
   that hosts served by the LISP router under attack will not be able to
   communicate.  This is so, because the LISP router rate limiting
   techniques, will also affect the legitimate request from internal and
   external hosts, making communication hard if not impossible
   (depending on the strength of the actual attack)


4.  Security considerations

   This note outlines security issues of the LISP protocol.


5.  Acknowledgments

   Pekka Nikander and Dave Meyer reviewed this document and provided
   comments.  In addition, Dave Meyer wrote the text containing the
   packet description of attacks described in sections 3.1.1.1 and
   3.1.1.3.  Dino Farinacci provided clarifying comments about how LISP
   works.


6.  Normative References

   [1]  Farinacci, D., Fuller, V., Oran, D., and D. Meyer, "Locator/ID
        Separation Protocol (LISP)", draft-farinacci-lisp-01 (work in
        progress), June 2007.

   [2]  Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E.
        Nordmark, "Mobile IP Version 6 Route Optimization Security
        Design Background", RFC 4225, December 2005.




Bagnulo                  Expires January 9, 2008               [Page 14]


Internet-Draft      Preliminary LISP Threat Analysis           July 2007


Author's Address

   Marcelo Bagnulo
   Huawei Lab at UC3M
   Av. Universidad 30
   Leganes, Madrid  28911
   SPAIN

   Phone: 34 91 6249500
   Email: marcelo@it.uc3m.es
   URI:   http://www.it.uc3m.es








































Bagnulo                  Expires January 9, 2008               [Page 15]


Internet-Draft      Preliminary LISP Threat Analysis           July 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).





Bagnulo                  Expires January 9, 2008               [Page 16]