Opened 13 years ago

Closed 13 years ago

Last modified 12 years ago

#46 closed defect (fixed)

Editorial Changes in REQ draft by Gab Montenegro

Reported by: kempf@… Owned by: kempf@…
Priority: minor Milestone:
Component: nohost-req Severity:
Keywords: REQ draft Cc: netlmm@…

Description

  1. Kempf, Editor

Internet Draft K. Leung Document: draft-ietf-netlmm-nohost-req-00.txt P. Roberts

  1. Nishida
  1. Giaretta
    1. Liebsch

too many authors

Expires: August, 2006 Feburary, 2006

February (sp)

...

Abstract

In draft-kempf-netlmm-nohost-ps, the problems with using global IP mobility

Use the title of the draft instead.

...

1.0 Introduction

In draft-kempf-netlmm-nohost-ps [1], the basic problems that occur when a

use title of the draft.

global mobility protocol is used for managing local mobility are described, and two basic approaches to localized mobility management - the host-based approach that is used by most IETF protocols and the WLAN switch approach -

bad name for the "other" approach. should rename using a constrasting property instead.

are examined. The conclusion from the problem statement document is that neither approach has a complete solution to the problem. While the WLAN switch approach is most convenient for network operators and users because it requires no mobile node support, the proprietary nature limits

no support required? false. perhaps no support at L3, but plenty at L2 and in terms of security for this to work.

interoperability and the restriction to a single wireless link type and wired backhaul link type restricts scalablity. The IETF host-based protocols require host software stack changes that may not be compatible with all global mobility protocols, and also require specialized and complex security transactions with the network that may limit deployability.

L2 security transactions are highly complex and specialized as well. ...

1.1 Terminology

Mobility terminology in this draft follows that in RFC 3753 [2] and in [2]. In addition, the following terms are used here:

Node

A node can be either an end host or router that is served by the localized mobility management domain. Such a node may perform global mobility management (e.g. NEMO [3] or MIPv6[5]). In this case, the IP address obtained by the node from the localized mobility management domain is the care-of address.

Host-Based Approach

This seems to be one of the 2 basic approaches mentioned above. Which is the other basic approach, the one called "wlan switch" approach above? The naming above should be consistent with that in this section.

...

2.1 Handover Performance Improvement (Requirement #1)

Handover packet loss occurs because there is usually latency between when the wireless link handover starts and when the IP link handover completes. During this time the mobile node is unreachable at its former topological location on the old IP link where correspondents are sending packets and to which the routing system is routing them. Such misrouted packets are dropped. This aspect of handover performance optimization has been the subject of an enormous amount of work, both in other SDOs, to reduce the latency of wireless link handover, and in the IETF and elsewhere, to reduce

s/and

the latency in IP link handover. Many solutions to this problem have been proposed at the wireless link layer and at the IP layer. One aspect of this requirement for localized mobility management is that the processing delay for changing the routing after handover must be minimal, in order to avoid excessive packet loss. Ideally, if network-side link layer support is available for handling movement detection, the routing update should complete within the time required for wireless link handover.

Note that a related problem occurs when traffic packets are not routed through a global mobility anchor such as a Mobile IP home agent. Route optimized Mobile IPv6 [5] and HIP [6] are examples. A loss of connectivity can occur when both sides of the IP conversation are mobile and they both hand over at the same time. The two sides must use a global mobility anchor point, like a home agent or rendezvous server, to re-establish the connection, but there may be substantial packet loss until the problem is discovered. Another aspect of this requirement is that the solution must ensure that connectivity is not lost when both ends are mobile and move at the same time.

This paragraph is not really relevant. Suggest eliding it.

In both cases, the loss of accurate routing caused the connection to experience an interruption which may cause service degradation for real time traffic such as voice

2.2 Reduction in Handover-related Signaling Volume (Requirement #2)

Considering Mobile IPv6 as the global mobility protocol (other mobility protocols require about the same or somewhat less), if a mobile node is required to reconfigure on every move between IP links, the following set of signaling messages must be done:

1) Movement detection using DNA [7] or possibly a link specific protocol, 2) Any link layer or IP layer AAA signaling, such as 802.1x [8] or PANA [9].

Pana? Who's actually using it? Seems forced as an example.

The mobile node may also or instead have to obtain a router certificate using SEND [10], if the certificate is not already cached,

3) Router discovery which may be part of movement detection, 4) If stateless address autoconfiguration is used, address configuration and

Duplicate Address Detection (unless optimistic Duplicate Address Detection [11] is used). If stateful address configuration is used, then DHCP is used for address configuration,

Up to here, these steps are fine and apply without any global mobility management. DNA is much more relevant to the problem at hand than global mobility management.

5) Binding Update to the home agent, 6) If route optimization is in effect, return routability to establish the

binding key,

Kempf, et. al. Expires July 2006 [Page 4]

Internet Draft LMM Requirements and Gap Analysis Feburary, 2006

7) Binding Update to correspondent nodes for route optimization.

Elide these last steps, as they are not relevant.

Note that Steps 1-2 will always be necessary, even for intra-link mobility, and Step 3 will be necessary even if the mobile node's care-of address can remain the same when it moves to a new access router.

This is a lot of signaling just to get up on a new IP link. Furthermore, in some cases, the mobile node may need to engage in "heartbeat signaling" to keep the connection with the correspondent or global mobility anchor fresh, for example, return routability in Mobile IPv6 must be done at a maximum every 7 minutes even if the mobile node is standing still. The requirement is that handover signaling volume from the localized mobility management protocol should be no more than what is needed to securely redirect a mobile node's traffic within the localized mobility management domain.

This last sentence seems like a self-fulfilling prophesy: "the work to do X should be no more than the work to get X done."

2.3 Location privacy (Requirement #3)

This seems like a side-effect more than a requirement.

Location privacy in the context of IP mobility refers to hiding the geographic location of mobile users. Although general location privacy issues have been discussed in [13], the location privacy referred to here focuses on the IP layer and involves the basic property of the IP address that may change due to the mobility. The location information should not be revealed to nor deduced by the correspondent node without the authorization of the mobile node's owner. Since the localized mobility management protocol is responsible for the mobile node's mobility within the local mobility management

domain, it should conceal geographical movement of the mobile node.

s/should conceal/also conceals/

The threats to location privacy come in a variety of forms. Perhaps least likely is a man in the middle attack in which traffic between a correspondent and the mobile node is intercepted and the mobile node's location is deduced from that, since man in the middle attacks in the Internet tend to be fairly rare.

s/since man in the middle attacks in the Internet tend to be fairly rare.

More likely are attacks in which the correspondent is the attacker or the correspondent or even mobile node

OLD: attacker or the correspondent or even mobile node

NEW: attacker, or either the correspondent or the mobile node

itself are relaying information on the care-of address change to someone.

s/on/about/ s/someone./someone else./

The owner of the correspondent or mobile node might not even be aware of the problem if an attacker has installed spyware or some other kind of exploit on the mobile node and the malware is relaying the change in care-of address to an attacker.

by this time all bets are off, really.

Note that the location privacy referred to here is different from the location privacy discussed in [15][16][17]. The location privacy discussed in these drafts primarily concerns modifications to the Mobile IPv6 protocol to eliminate places where an eavesdropper could track the mobile node's movement by correlating home address and care of address.

The requirement is that the location information should not be revealed to nor deduced by the correspondent node without the authorization of the mobile node's owner as long as the mobile node remains within the localized mobility management domain. Since the localized mobility management protocol is responsible for the mobile node mobility within the localized mobility management domain, it should conceal the geographical movement of the mobile node.

last sentence is repeated, delete.

Kempf, et. al. Expires July 2006 [Page 5]

Internet Draft LMM Requirements and Gap Analysis Feburary, 2006

2.4 Efficient Use of Wireless Resources (Requirement #4)

Advances in wireless PHY and MAC technology continue to increase the

PHY and MAC: define the first time you use them.

bandwidth available from limited wireless spectrum, but even with technology increases, wireless spectrum remains a limited resource. Unlike wired network links, wireless links are constrained in the number of bits/Hertz by their coding technology and use of physical spectrum, which is fixed by the PHY. It is not possible to lay an extra cable if the link becomes increasingly congested as is the case with wired links.

there's cost there as well, perhaps more. it is very costly to lay down more cable, pay the contractor, etc.

Some existing localized mobility management solutions increase packet size over the wireless link by adding tunneling or other per packet overhead. While header compression technology can remove header overhead, header

s/header overhead, header/overhead, it/

compression does not come without cost. Requiring header compression on the

s/compression

wireless access points increases the cost and complexity of the access points, and increases the amount of processing required for traffic across the wireless link. Since the access points tend to be a critical bottleneck in wireless access networks for real time traffic (especially on the downlink), reducing the amount of per-packet processing is important. While

don't think this is very significant after all the processing already going on just to process the PHY signals. what is costly in terms of time is establishing the necessary compressor/decompressor context.

header compression probably cannot be completely eliminated, especially for real time media traffic, simplifying compression to reduce processing cost is an important requirement.

The requirement is that the localized mobility management protocol should not introduce any new signaling or increase existing signaling over the air.

2.5 Reduction of Signaling Overhead in the Network (Requirement #5)

While bandwidth and router processing resources are typically not as constrained in the wired network, wired networks tend to have higher bandwidth and router processing constraints than the backbone. These

OLD:

While bandwidth and router processing resources are typically not as constrained in the wired network, wired networks tend to have higher bandwidth and router processing constraints than the backbone.

NEW:

Wireless networks tend to have higher bandwidth and router processing constraints than the wired backbone.

constraints are a function of the cost of laying fiber or wiring to the wireless access points in a widely dispersed geographic area. Therefore, any solutions for localized mobility management should minimize signaling within the wired network as well.

2.6 No Extra Security Between Mobile Node and Network (Requirement #6)

...

In summary, ruling out mobile node involvement in local mobility management simplifies security by removing the need for service-specific credentials to authenticate and authorize the mobile node for localized mobility management

not sure this is true. if the nw is implicitly carrying out LMM on the MN's behalf, it means that all MNs are treated equally: they all get LMM treatment.

Under this assumption, even if MNs were actively involved in LMM, one could also decide to treat them all the same and grant them all LMM treatment. The complication comes about when one decides to treat some MNs differently than others, then specific authorization schemes for LMM must be designed, regardless of who initiates the LMM process.

in the network and by limiting the possibility of DoS attacks on network infrastructural elements. The requirement is that support for localized mobility management should not require additional security between the mobile node and the network.

"additional" as compared to what?

2.7 Support for Heterogeneous Wireless Link Technologies (Requirement #7)

...

In addition, an edge mobility solution should provide support for multiple wireless link technologies within the network in separate subnets. It is not required that the localized mobility management solution support handover from one wireless link technology to another without change in IP address. The reason is because a change in network interface typically requires that the hardware interface associated with one wireless link technology be brought up and configured, and this process typically requires that the IP stack for the new interface card be configured on the mobile node from the driver up. Requiring that the mobile node IP stack circumvent this process to keep the IP address constant would be a major change in the way the IP stack software is implemented.

Delete the above paragraph. Giving a given IP address to an interface is not a major issue. The real issue is the expected support on the nwtwork side.

The requirement is that the localized mobility management protocol should not use any wireless link specific information for basic routing management, though it may be used for other purposes, such as identifying a mobile node.

2.8 Support for Unmodified Mobile Nodes (Requirement #8)

In the wireless LAN switching market, no modification of the software on the mobile node is required to achieve "IP mobility" (which means localized mobility management). Being able to accommodate unmodified mobile nodes

s/"IP mobility" (which means localized mobility management)/localized mobility management/

enables a service provider to offer service to as many customers as possible, the only constraint being that the customer is authorized for

s/is/be/

network access.

Kempf, et. al. Expires July 2006 [Page 7]

Internet Draft LMM Requirements and Gap Analysis Feburary, 2006

Another advantage of minimizing mobile node software for localized mobility management is that multiple global mobility management protocols can be supported with a localized mobility management solution that does not have mobile node involvement.

Seems irrelevant, this is another level.

While Mobile IPv6 is clearly the global mobility management protocol of primary interest going forward, there are a variety of global mobility management protocols that might also need support, including proprietary protocols needing support for backward compatibility reasons. Within IETF, both HIP and Mobike are likely to need support in

"within IETF"? this appears to be a deployment discussion, but the IETF is an SDO. perhaps "within the internet"?

addition to Mobile IPv6, and Mobile IPv4 support may also be necessary.

Note that this requirement does NOT mean that the mobile node has no software at all associated with mobility or wireless. The mobile node must have some kind of global mobility protocol if it is to move from one domain of edge mobility support to another, although no global mobility protocol is

not true, nomadism is the most common mode of operation today.

required if the mobile node only moves within the coverage area of the localized mobility management protocol. Also, every wireless link protocol requires handover support on the mobile node in the physical and MAC layers, typically in the wireless interface driver. Information passed from the MAC layer to the IP layer on the mobile nodenode may be necessary to trigger IP signaling for IP link handover. Such movement detection support at the IP level may be required in order to determine whether the mobile node's default router is still reachable after the move to a new access point has occurred at the MAC layer. Whether or not such support is required depends on whether the MAC layer can completely hide link movement from the IP layer. For a wireless link protocol such as the 3G protocols, the mobile node and network undergo an extensive negotiation at the MAC layer prior to handover, so it may be possible to trigger routing update without any IP protocol involvement. However, for a wireless link protocol such as IEEE 802.11 in which there is no network involvement in handover, IP layer

there is nw involvement, right? 11i, 11r, 11k etc have nw components.

movement detection signaling from the mobile node may be required to trigger routing update.

s/routing/a routing/

The requirement is that the localized mobility management solution should be able to support any mobile node that walks up to the link and has a wireless

s/salks up to the/joins the/ s/and has/and that has/

...

3.1 Mobile IPv6 with Local Home Agent

One option is to deploy Mobile IPv6 with a locally assigned home agent in the local network. This solution requires the mobile node to somehow be assigned a home agent in the local network when it boots up. This home agent is used instead of the home agent in the home network. The advantage of this option is that the no special solution is required for edge mobility - the mobile node reuses the global mobility management protocol for that purpose

  • if the mobile node is using Mobile IPv6. One disadvantage is that Mobile IP has no provision for handover between home agents. Although such handover should be infrequent, it could be quite lengthy and complex.

Why is this a disadvantage? Wasn't this specifically excluded (section 2.0 in the prob statement).

This brings up another point: there is a need to clearly specify the non-requirements in this draft.

...

3.2 Hierarchical Mobile IPv6 (HMIPv6)

HMIPv6 [20] provides the most complete localized mobility management solution available today as an Internet RFC. In HMIPv6, a localized mobility

please don't create more confusion: HMIPv6 is an experimental RFC, although the above reads as if it were proposed standard.

...

Requirement #5 FMIPv6 generates extra signaling overhead between previous

s/previous the/the previous/

...

Requirement #6 In addition to the analysis for Mobile IPv6 with local home agent in Section 3.1, FMIPv6 requires the mobile node and the previous access router to share a security association in order to secure FBU/FBA exchange. So far, only a SEND-based solution has been proposed and this

this is not true (as is noted below, btw), please reword.

requires the mobile node to use autoconfigured Cryptographically Generated

Addresses

(CGAs)[21]. This precludes stateful address allocation using DHCP, which might be a necessary deployment in certain circumstances. Another solution based on AAA is under study but it could require extra signaling overhead over the air and in the wired network and it could raise performance issues.

same is true of the send based approach (adds PK operations to encrypt the HO key and decrypt using public key).

...

[27] Threat analysis draft, TBD

Hmmm... non-existent reference for a WG LC-ed document? Please fix.

Change History (3)

comment:1 Changed 13 years ago by kempf@…

  • Status changed from new to assigned

comment:2 Changed 13 years ago by kempf@…

  • Resolution set to fixed
  • Status changed from assigned to closed

I did the best I could with these, but some of these comments are pretty value-judgement laden and I am not sure if I captured the commenter's intend. It would have been much easier if some suggested text could have been included along with the comment so that I could be more sure of matching the intent.

comment:3 Changed 12 years ago by anonymous

  • Milestone milestone2 deleted

Milestone milestone2 deleted

Note: See TracTickets for help on using tickets.