Network Working Group V. Narayanan Internet-Draft L. Dondeti Intended status: Standards Track QUALCOMM, Inc. Expires: August 29, 2007 February 25, 2007 IP Mobility Protocols - Threat Analysis draft-vidya-ip-mobility-threats-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 August 29, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract IP mobility protocols allow nodes to maintain a somewhat permanent IP address as they change points of attachment to the Internet. There are various levels and types of mobility management available for local and global mobility, and several protocols have been developed to support them. Even though each of the IP mobility management protocols may have its own set of scope and functions, analysis has shown that a generalized threat model is applicable. This document describes a threat model for IP mobility. Narayanan & Dondeti Expires August 29, 2007 [Page 1] Internet-Draft draft-vidya-ip-mobility-threats February 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. IP Mobility Model . . . . . . . . . . . . . . . . . . . . . . 5 4. Asset Classifications for IP Mobility Protocols . . . . . . . 6 5. The Internet Threat Model - A Recap . . . . . . . . . . . . . 7 5.1. Classes of Attacks . . . . . . . . . . . . . . . . . . . . 8 6. Extensions to the Internet Threat Model for Routing . . . . . 8 7. IP Mobility Threat Model . . . . . . . . . . . . . . . . . . . 9 8. Threat and Vulnerability Analysis of IP Mobility Protocols . . 10 8.1. Threats to IP Mobility Providers . . . . . . . . . . . . . 10 8.1.1. Threats to Mobility Agents . . . . . . . . . . . . . . 10 8.1.2. Threats to Mobility Facilitators . . . . . . . . . . . 11 8.2. Threats to IP Mobility Recipients . . . . . . . . . . . . 12 8.3. Threats to non IP Mobility Participants . . . . . . . . . 13 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 12.1. Normative References . . . . . . . . . . . . . . . . . . . 14 12.2. Informative References . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . . . 16 Narayanan & Dondeti Expires August 29, 2007 [Page 2] Internet-Draft draft-vidya-ip-mobility-threats February 2007 1. Introduction The development of any security solution requires an understanding of the threat model. In general, we use the Internet threat model [1] as the basis for security analysis at the IETF. We perform an applicability analysis of the Internet threat model to IP mobility in this document. IP mobility refers to changes in the IP point of attachment of a mobile node. As a consequence of this change, the node may obtain a different (topologically meaningful) address. The result is that a mobile host or network, as it moves, may obtain different topologically meaningful IP addresses that it can use for IP-based communications. Some protocols allow the nodes to maintain the same IP address as they move across different IP points of attachment. IP mobility protocols allow nodes to continue IP communications independent of the current IP point of attachment and to preserve established communication channels across any corresponding IP address changes. Either the mobile node or a proxy communicates the change in IP point of attachment to the node that maintains a binding between the (semi-)permanent address and the transient address. There are various levels and types of mobility management available for local and global mobility and several protocols have been developed to support them. Even though each of the IP mobility management protocols may have its own set of scope and functions, analysis has shown that a generalized threat model is applicable. IP mobility protocols fundamentally handle changes to the IP point of presence by forwarding packets sent to a node's "anchor" address to a "transient" address. These terms are further explained in Section 2. The goal of this document is to aid analysis of the threat models of relevance to IP mobility protocols. Using this threat analysis, the hope is to develop a set of security requirements for such protocols. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2]. In addition, this document uses the following terms for sake of generality: Narayanan & Dondeti Expires August 29, 2007 [Page 3] Internet-Draft draft-vidya-ip-mobility-threats February 2007 IP Mobility IP mobility refers to changes in the IP point of attachment of a node. As a consequence of this change, a node may obtain a different (topologically meaningful) address. The result is that a mobile node or network, as it moves, may obtain different topologically meaningful IP addresses that it can use for IP-based communications. Some protocols allow the nodes to maintain the same IP address as they move across different IP points of attachment. IP Mobility Protocol An IP mobility protocol provides transparency to layers above IP from the changes in the IP addresses resulting from IP mobility. In particular, such protocols allow nodes to continue IP communications independent of the current IP point of attachment and to preserve established communications across any corresponding IP address changes. A key element of an IP mobility protocol is to detect movement and do what is needed to allow communication continuity. Mobility Agent A mobility agent is an entity maintaining state about the location of the mobile nodes. Examples of mobility agents include the Mobile IP Home Agent (HA), the HMIP MAP, the FMIP PAR, NetLMM LMA, MIP6 RO-enabled CN, etc. Mobility Facilitator This refers to an entity other than a mobility agent that may play a role in facilitating the mobility management of the MN. Examples of such mobility facilitators include the NetLMM MAG, MIP4 FA, HMIP AR, etc. Mobility Provider Mobility provider collectively refers to the mobility agent and facilitators. Mobility Recipient The mobility recipient is the entity receiving the IP mobility service. The MN is always the mobility recipient and hence these terms may be used interchangeably. Narayanan & Dondeti Expires August 29, 2007 [Page 4] Internet-Draft draft-vidya-ip-mobility-threats February 2007 Anchor Address This is used to refer to the relatively unchanging IP address of the MN. Examples of anchor addresses are the MIP HoA, HMIP RCoA, FMIP PCoA, NetLMM RHoA, etc. This is usually the address corresponding to which state is maintained in the mobility agent. The permanence and scope of the address may vary depending on the protocol. Transient Address This is used to refer to the relatively frequently changing IP address of the MN. Examples of transient addresses are the MIP CoA, HMIP RCoA, FMIP NCoA, NetLMM PLCoA, etc. This is usually the address that points to the present location of the MN. 3. IP Mobility Model ---------------- | Mobility Agent | ---------------- | | ----------------------------- | | | | | IP Cloud | | | | | ----------------------------- | | | | ----------------------- ----------------------- | Mobility Facilitator 1| ... | Mobility Facilitator n| ----------------------- ----------------------- | | ------ | MN | ------ Figure 1: IP Mobility Architectural Entities There are several classes of IP mobility protocols. In general, IP mobility protocols hide changes in IP address from the layers above Narayanan & Dondeti Expires August 29, 2007 [Page 5] Internet-Draft draft-vidya-ip-mobility-threats February 2007 IP. Different classes of IP mobility protocols achieve this in different ways. One set of protocols use a centralized mobility management entity that maintains a mapping of the anchor and transient addresses and tunnel data to and from the mobile node. The threat analysis in this document applies to this class of protocols. Examples of this class of protocols at the time of this writing include Mobile IP, Hierarchical Mobile IP, Fast Mobile IP, Proxy Mobile IP, MOBIKE and other NetLMM-class of protocols. Other classes of IP mobility protocols such as HIP are out of scope of this analysis. In the class of protocols under consideration, there is a mobility provider that enables and provides the mobility service and a mobility recipient that is the end user of the mobility service. A mobility provider typically consists of some mobility facilitators that enable the service and mobility agent that maintains the state necessary for mobility management. The mobility recipient is always the mobile node. See Figure 1 for an example architecture. IP mobility protocols rely on some signaling exchange to establish the necessary state at the mobility agent. In host-based mobility protocols such as Mobile IP, this signaling is performed by the mobile node itself. In network-based mobility protocols such as NetLMM, this signaling is performed by an entity in the network on behalf of the mobile node. In either case, the mobility agent is one of the entities engaged in the signaling. In a system providing IP mobility services, there are several parties of interest for security analysis purposes. Such parties include: o Parties involved in the mobility service, such as the mobility provider and recipient. Within this category, the mobile node and the mobility agent must function correctly in order for the mobility service to be available. o Parties not involved in the mobility service as such, but, those that may be impacted by the presence of mobility services in the network. Such entities include any node that may be receiving any kind of IP connectivity or services from networks reachable from those providing IP mobility services. 4. Asset Classifications for IP Mobility Protocols For any type of security analysis, it is important to identify the assets to determine what must be protected. Section 3 presents the parties of interest within the scope of IP mobility protocols for the purpose of a security analysis. Those parties of interest, along Narayanan & Dondeti Expires August 29, 2007 [Page 6] Internet-Draft draft-vidya-ip-mobility-threats February 2007 with some other resources, constitute the "assets" for the purpose of threat and vulnerability analysis. This section provides a classification of such assets. Assets may be classified into the following three categories. Critical Assets A critical asset is one whose failure or compromise leads to failed mobility sessions. Examples of critical assets include mobile node, mobility agent, and security infrastructure entities (such as AAA servers or CAs), if any. A security infrastructure entity, when present, may broker the security association between the MN and the mobility agent. Non-Critical Assets A non-critical asset is one whose failure or compromise may cause a temporary disruption to mobility sessions. However, in general, the mobility session can continue despite the failure or compromise of these assets. Examples of non-critical assets include network infrastructure (such as links) and mobility facilitators (such as ARs or even regular routers). Other Assets These are assets that do not fall under either of the two categories above. Examples of such assets include correspondent nodes and other fixed or mobile nodes attaching to the mobility domain. These nodes may or may not use the mobility services, but, use the same resources that are part of the network providing these services. In this analysis, we also consider the threats to any node that is reachable via the mobility provider network due to enabling mobility services in the network. 5. The Internet Threat Model - A Recap Section 3 of [1] describes the Internet threat model. This section provides a brief summary of it as a preface to the application of that model to IP mobility. The Internet threat model is built on two important assumptions: o Assumption 1: Critical Assets are not compromised. More specifically, when a critical asset is compromised, the correctness of the protocol cannot be guaranteed. Also, if a compromised critical asset shuts down a session, nothing can be done about it. Hence, critical assets for a given protocol must Narayanan & Dondeti Expires August 29, 2007 [Page 7] Internet-Draft draft-vidya-ip-mobility-threats February 2007 be protected and we assume they are not compromised for the purposes of threat analysis. o Assumption 2: The attacker has full control of the communication channel. The attacker can read, inject, modify or remove any packets without detection. In the absence of any security encapsulation of packets, this is generally true; we do not assume any security encapsulation in conducting the threat and vulnerability analysis. 5.1. Classes of Attacks Attacks can be classified into four broad categories as follows. o Passive Attacks: A passive attacker only reads, but does not modify, remove or inject any packets. Eavesdropping on data is possible with a passive attack. Also, data collected from a passive attack may later be used to launch an active attack. Passive attackers do not generally need to transmit and thus may be able to conduct the attack without being detected. o Active Attacks: Here, the attacker may modify, remove or inject packets, thereby actively participating in an attack. Active attackers need to transmit data and thus may be detectable via physical observations. o Off-Path Attacks: Here, the attacker is not in the path of the data transmission and is capable of launching an attack from elsewhere in the network. An off-path attack is typically an active attack. o On-Path Attacks: Here, the attacker is present on the path of the data exchanged. On-path attacks are a superset of off-path attacks, since the attacker in this case can do everything that an off-path attacker can do as well as do more due to the virtue of being on-path. The rest of the document analyzes if all of these assumptions and/or attacks are valid for the IP mobility protocols. It also analyzes if there are other assumptions and/or attacks that may be applicable to this class of protocols. 6. Extensions to the Internet Threat Model for Routing Routing protocols extend the Internet threat model in at least two ways, as follows. Narayanan & Dondeti Expires August 29, 2007 [Page 8] Internet-Draft draft-vidya-ip-mobility-threats February 2007 o Routing protocols can typically handle Byzantine failures. Byzantine failures constitute entities selectively lying about routing or other information, while still appearing to function correctly. Such a failure can be the result of mis-configuration or compromise. In a network using a robust routing protocol, two entities can communicate as long as there is at least one non- faulty path between them. Hence, for instance, the compromise of a router leading to false routing information should still allow convergence to an alternate path, when one such path exists. o Upon receiving a routing update, the recipient must be able to verify the authorization of the sender to send the routing update. Without such authorization, nodes may be able to advertise the wrong prefixes and disrupt the routing service. 7. IP Mobility Threat Model In the rest of this document, we apply the Internet threat model to IP mobility. A closer look at the IP mobility model reveals that the threat model is very much analogous to the routing threat model. The mobile node may reach the mobility agent via more than one network attachment point or mobility facilitator. When a mobile node tries to reach its mobility agent via a compromised access router (or some other compromised router along the path), it may fail. However, if it can attach to a different, non-compromised access router that has a path to the same mobility agent, it should be able to obtain mobility service through that access router. If the failure of one access router disrupts the mobility service via any other access router, that is a problem. This effect is sometimes referred to as the domino effect. There is another aspect of mobility that is worth mentioning. Since IP mobility state supplants routing state, it has the potential to impact entities not involved with the mobility service in any way. For instance, the communication between two entities, A and B, may be affected due to the malicious use of an IP mobility protocol by a different entity, C, with a mobility agent, D. This is a concern for all nodes attaching to a network that is reachable from a network that provides mobility services, and thus must be prevented. This threat has similarities to the routing update authorization problem discussed in Section 6. As part of the threat model analysis, it is also important to see what classes of attackers can realize a given attack. Any threat that requires state creation or modification can only be achieved by an active attacker, since it requires more than just observation of Narayanan & Dondeti Expires August 29, 2007 [Page 9] Internet-Draft draft-vidya-ip-mobility-threats February 2007 data exchanged. Typically, on-path attackers are considered to be capable of doing more than off-path attackers, but, this needs to be analyzed within the context of specific threats. It generally provides an attacker more flexibility when an attack can be launched off-path. Differently put, an off-path attack is more likely to happen as it is less of a burden to attacker to launch attacks. Section 8 performs an analysis of the various attacks and the types of attackers that can launch those attacks. 8. Threat and Vulnerability Analysis of IP Mobility Protocols This section analyzes the threats and vulnerabilities to IP mobility participants, as well as non-IP mobility participants due to IP mobility protocols. 8.1. Threats to IP Mobility Providers As already mentioned, the Mobility Provider is the entity providing the IP mobility service and constitutes the mobility agent (such as an HA) and one or more mobility facilitators (such as an AR or FA). The mobility provider is generally interested in ensuring that the service is only provided to authorized entities. It is also in the interest of the mobility provider to ensure that the service is provided as intended. Providing IP mobility service entails the maintenance of state for all mobile nodes served, in order to maintain the mapping of the anchor and transient addresses of those nodes. Hence, the mobility provider, to protect its resources, must ensure that any state is only created by entities served by the provider. 8.1.1. Threats to Mobility Agents Threats to mobility agents fall under two categories: o Creation of state by unauthenticated nodes - this leads to the consumption of resources at the mobility agent. This could further lead to the other attacks on mobility recipients described in Section 8.2. Such attacks hinder the correct operation of IP mobility in the system. Such creation of spurious or incorrect state may further lead to excessive traffic forwarding to be handled by the mobility agent. o Creation of incorrect state by authenticated nodes - as in the case above, this also leads to the other attacks on mobility recipients described in Section 8.2. In addition, this may lead to loops at the mobility agent by causing packets to shuttle infinitely between the routing and mobility stacks of the mobility Narayanan & Dondeti Expires August 29, 2007 [Page 10] Internet-Draft draft-vidya-ip-mobility-threats February 2007 agent. It should be noted that both categories of threats above involve creation of some state at the mobility agent and hence can only be from an active attack. However, these attacks can be launched by an off-path attacker, i.e., the attacker that is attempting to create state at the mobility agent may not be in the path of any legitimate signaling that is going to the mobility agent. In summary, an off-path attacker can create illegal state at a mobility agent to divert traffic thereby deny service to the entity for which the state is created, consume resources at the mobility agent. It is also fairly straightforward for the attacker to repeat this attack several fold and cause significant disruption to the mobility agent's operation. The off-path nature of the attack makes it highly likely, and the low amount of effort required to launch significant damage makes this a high risk event. 8.1.2. Threats to Mobility Facilitators Threats to mobility facilitators also fall into two categories: o Creation of spurious state at the facilitator - Some IP mobility protocols (such as MIP4, for example) require some amount of state to be maintained at the mobility facilitator (e.g., the Foreign Agent). If an attacker is able to create spurious state at the facilitator, it would lead to resource consumption as well as some other attacks described in Section 8.2. Note that it is not feasible to cause redirection of packets by creating incorrect state at the facilitator, since the facilitator does not directly perform the mobility tunneling. However, DoS attacks may be realized from the state created. For instance, it is feasible to cause a facilitator to drop packets meant for a mobile node by creating wrong state at it. Such attacks hinder the correct operation of IP mobility in the system. o Use of the facilitator to disrupt mobility - Since a facilitator may be advertising information necessary for mobility services, it would be feasible to use the facilitator to disrupt the mobility services. For instance, if it is feasible to cause the facilitator to advertise wrong information about a mobility agent, that would result in inappropriate operation of IP mobility in the system. This would result in the facilitator not being able to properly enable the mobility services it intends to. Both categories of threats above also require an active attack, since these are a result of some misinformation being available at the mobility facilitator. Further, these threats can also be realized by Narayanan & Dondeti Expires August 29, 2007 [Page 11] Internet-Draft draft-vidya-ip-mobility-threats February 2007 an off-path attacker. Facilitators are not really critical to enabling mobility, as long as one of them is operational, it is plausible to provide mobility service. In other words, even though the attacker can be off-path, the result of attacking a facilitator is at best intermittent service disruption; thus, attacks on mobility facilitators may be less likely. 8.2. Threats to IP Mobility Recipients The mobile nodes, as recipients of the mobility service, are interested in having undisrupted and correct IP mobility service. In other words, the mobile node must be able to obtain the service as long as it can reach the mobility agent. Also, the mobile node must not be a victim of attacks from other mobile nodes in the network. Threats to mobility recipients can be categorized as follows. o Traffic Redirection: IP mobility protocols create a binding between the anchor and transient addresses of mobile nodes, so that traffic destined for the former can be tunneled to the latter address. If an attacker can create a binding for the anchor address of the MN, the traffic meant for the mobile node ends up being redirected to some other node. This threat to the mobile node can be realized as a result of the attacks to mobility agents described in Section 8.1.1. Note that a binding for an anchor address can only be created when that address belongs to a prefix served by the mobility agent. Hence, such redirection is limited to scope to the prefixes served by the mobility agent. o Distributed Denial of Service: If an attacker can create a binding for its address mapped to the mobile node's transient address, the mobile node ends up being the recipient of spurious traffic and hence a victim to a DDoS attack. The attacker may create several such bindings and can amplify the DDoS attack on the victim. This threat to the mobile node can be realized as a result of the attacks to mobility agents described in Section 8.1.1. It should be noted that the impact of this threat is not unlike an attacker that might send traffic directly to the transient address of the mobile node. However, the important difference is that by causing a DDoS attack due to registering the mobile node's transient address at a mobility agent, the attacker can cause a number of sources to send data to the mobile node. In this case, the attacker needs to put in less effort than the victim. The attacker may subscribe to several high bandwidth flows and direct that traffic to the mobile node. Unlike the redirection attack, the scope of this attack is not limited to the prefixes served by Narayanan & Dondeti Expires August 29, 2007 [Page 12] Internet-Draft draft-vidya-ip-mobility-threats February 2007 the mobility agent and can affect any entity that is reachable via the mobility provider network. o Denial of Service: The MN's mobility service may be disrupted by an attacker. A redirection attack, for example, may lead to DoS. This threat to the mobile node can be realized as a result of the attacks to mobility agents described in Section 8.1.1 or as a result of attacks to mobility facilitators described in Section 8.1.2. Denial of service can also be achieved by an on- path attacker that is capable of dropping or modifying packets sent by the mobile node. o Data Reflection: Incorrect state at the mobility agent or mobility facilitator may cause responses to a request to be sent to a different entity. The effect of this is similar to the DDoS attack described above. Such incorrect state may also cause packets meant for the wrong address to be sent to an entity. This results in a forced redirection, in addition to a DDoS attack on the entity receiving the packets. All of the above attacks can only be realized by causing inappropriate state in the mobility provider. Hence, these can only be caused by active attacks. However, just like all the other threats discussed, these attacks can also be caused by an off-path attacker. None of these require an attacker to capture any data that was actually sent from or to the mobile node. While there are additional DoS attacks feasible by an on-path attacker that drops or modifies packets, the same effect can be realized by an off-path attacker that can create incorrect state at the mobility agent. 8.3. Threats to non IP Mobility Participants As in the case of routing protocols, mobility protocols are also capable of introducing threats to entities that are not parties to the protocol. In particular, all the threats that apply to mobile nodes also apply to any entity that is reachable through the network providing the mobility service. All the threats discussed in Section 8.2 are a result of some inappropriate mobility state in some element of the mobility provider. These are attacks that can affect any entity that uses an IP address for communication that is reachable via the network of the provider. If the mobility agent only serves virtual prefixes for the purposes of IP mobility anchor addresses, then a redirection attack would only be feasible on mobile nodes and not on any fixed nodes or routers. While this may be feasible in some networks and protocols, it is not always feasible. For instance, for scenarios served by FMIP, the prefixes served by an access router are typically physically Narayanan & Dondeti Expires August 29, 2007 [Page 13] Internet-Draft draft-vidya-ip-mobility-threats February 2007 available prefixes that can be reached via a last hop wired or wireless access device. In summary, mobility protocols facilitate DDoS attacks on any entity in the Internet; the potential attacker can be off-path and can launch the attack with a minimal cost. 9. Security Considerations This entire document deals with the threat analysis of IP mobility protocols. There are several security requirements to consider in order to address the threats documented here. Those requirements are presented in a separate draft. 10. IANA Considerations This document has no IANA actions. 11. Acknowledgments 12. References 12.1. Normative References [1] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 12.2. Informative References [3] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. [4] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [5] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, July 2005. [6] Soliman, H., Castelluccia, C., El Malki, K., and L. Bellier, "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC 4140, August 2005. Narayanan & Dondeti Expires August 29, 2007 [Page 14] Internet-Draft draft-vidya-ip-mobility-threats February 2007 [7] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, June 2006. [8] Koodli, R. and C. Perkins, "Mobile IPv4 Fast Handovers", draft-ietf-mip4-fmipv4-03 (work in progress), February 2007. [9] Gundavelli, S., "Proxy Mobile IPv6", draft-sgundave-mip6-proxymip6-01 (work in progress), January 2007. [10] Fogelstroem, E., "Mobile IPv4 Regional Registration", draft-ietf-mip4-reg-tunnel-04 (work in progress), October 2006. [11] Bedekar, A., "A Protocol for Network-based Localized Mobility Management", draft-singh-netlmm-protocol-01 (work in progress), February 2007. [12] Giaretta, G., "The NetLMM Protocol", draft-giaretta-netlmm-dt-protocol-02 (work in progress), October 2006. Authors' Addresses Vidya Narayanan QUALCOMM, Inc. 5775 Morehouse Dr San Diego, CA USA Phone: +1 858-845-2483 Email: vidyan@qualcomm.com Lakshminath Dondeti QUALCOMM, Inc. 5775 Morehouse Dr San Diego, CA USA Phone: +1 858-845-1267 Email: ldondeti@qualcomm.com Narayanan & Dondeti Expires August 29, 2007 [Page 15] Internet-Draft draft-vidya-ip-mobility-threats February 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). Narayanan & Dondeti Expires August 29, 2007 [Page 16]