2.3.16 MIPv6 Signaling and Handoff Optimization (mipshop)

NOTE: This charter is a snapshot of the 63rd IETF Meeting in Paris, France. It may now be out-of-date.

Last Modified: 2005-07-02


Gabriel Montenegro <gabriel_montenegro_2000@yahoo.com>

Internet Area Director(s):

Mark Townsley <townsley@cisco.com>
Margaret Wasserman <margaret@thingmagic.com>

Internet Area Advisor:

Margaret Wasserman <margaret@thingmagic.com>

Mailing Lists:

General Discussion: mipshop@ietf.org
To Subscribe: mipshop-request@ietf.org
In Body: subscribe
Archive: http://www.ietf.org/mail-archive/web/mipshop/index.html

Description of Working Group:

Mobile IPv6 specifies routing support to permit IP hosts using IPv6 to
move between IP subnetworks while maintaining session continuity.
Mobile IPv6 supports transparency above the IP layer, including
maintenance of active TCP connections and UDP port bindings.

To accomplish this, the mobile node notifies its home agent (and
potentially also its correspondent nodes) of the current binding
between its home address and its care of address. This binding allows a
mobile node to maintain connectivity with the Internet as it moves
between subnets.

Depending on what steps a mobile node must perform on a new subnet, the
lag between when the mobile node has layer 2 connectivity and when it
begins sending and receiving packets on the new link may be
substantial. A mobile node must first detect at layer 3 that its point
of attachment has changed, then it must perform configuration on the
new link, including router discovery and configuring a new care of
address. After that, the mobile node must perform binding updates with
the home address and any correspondent nodes. Since many layer 2
mobility technologies require that the mobile node drop its link
connectivity to the old subnet when moving, any packets between the
correspondent node and the mobile node sent or in-flight during this
time arrive at the old care of address, where they are dropped. Such
packet loss may have significant adverse effects.

The Mobile IP Working group had previously been developing two
technologies to address the issues of signaling overhead and handoff
latency/packet loss:

  - Hierarchical Mobile IPv6 mobility management (HMIPv6)

      HMIPv6 deals with reducing the amount and latency of signaling
      between a MN, its Home Agent and one or more correspondents by
      introducing the Mobility Anchor Point (MAP) (a special node
      located in the network visited by the mobile node). The MAP acts
      somewhat like a local home agent for the visiting mobile node by
      limiting the amount of signaling required outside the MAP's

  - Fast Handovers for Mobile IPv6 (FMIPv6)

      FMIPv6 reduces packet loss by providing fast IP connectivity as
      soon as a new link is established. It does so by fixing up the
      routing during link configuration and binding update, so that
      packets delivered to the old care of address are forwarded to the
      new. In addition, FMIPv6 provides support for preconfiguration of
      link information (such as the subnet prefix) in the new subnet
      while the mobile node is still attached to the old subnet. This
      reduces the amount of preconfiguration time in the new subnet.

These two technologies can be used separately or together to reduce or
eliminate signaling overhead and packet loss due to handoff delays in
Mobile IPv6.

Scope of MIPSHOP:

The MIPSHOP Working Group will complete the FMIPv6 and HMIPv6 work
begun in the Mobile IP Working Group. Specifically, the WG will:

1) Complete the specification of HMIPv6 protocol.

2) Complete the specification of FMIPv6 protocol.

Because work (ongoing or originating) in other working groups may
suggest changes or alternative designs for HMIPv6 and FMIPv6, these
specifications will be advanced as Experimental RFCs until more
experience is obtained with IP mobility in IPv6.

3) Complete work on a set of requirements for "Localized Mobility
  Management (LMM)", whereby a Mobile Node is able to continue
  receiving packets in a new subnet before the corresponding changes
  in either the Home Agent or Correspondent Node binding. It is the
  intention that the requirements be consistent with the FMIPv6 and
  HMIPv6 protocols; in the event that there are inconsistencies, they
  will be documented.

4) Complete work on the applicability of FMIPv6 in the specific case
  of 802.11 networks for advancement as Informational RFC.

There are security issues that arise because of the highly dynamic
nature of the security relationships between, say, a mobile node and
its mobility anchor points, or between a mobile node and its access
routers in a fast handover scenario. The working group is not required
to provide solutions to all these issues before publishing its
experimental and informational protocols. The working group will
document the security requirements and the shortcomings of the
solutions in the corresponding protocol specifications. This will
provide valuable feedback to other groups or subsequent efforts.

Goals and Milestones:

Done  Working Group Last Call on draft-ietf-mipshop-hmip-xx.txt
Done  Working Group Last Call on draft-ietf-mipshop-lmm-requirements-XX.txt
Done  Working Group Last Call on draft-ietf-mipshop-fmipv6-xx.txt
Done  Discuss Last Call comments and security analyses at IETF 58
Done  Submit draft draft-ietf-mipshop-lmm-requirements-XX.txt to IESG for consideration of publication as Informational
Done  Submit draft-ietf-mipshop-fmipv6-xx.txt to IESG for consideration of publication as Experimental
Done  Submit draft-ietf-mipshop-hmip-xx.txt to IESG for consideration of publication as Experimental
Done  Working Group Last Call on draft-ietf-mipshop-80211fh-xx.txt for Informational
Done  Submit draft-ietf-mipshop-80211fh-xx.txt to IESG for consideration of publication as Informational


  • draft-ietf-mipshop-hmipv6-04.txt
  • draft-ietf-mipshop-80211fh-04.txt

    Request For Comments:

    RFC4068 E Fast Handovers for Mobile IPv6

    Current Meeting Report

    Mipshop Meeting

    IETF 63, Paris, August 2, 2005

    Meeting Minutes: Christian Vogt, TJ Kniveton (merged by Stefano Faccin)

    Tuesday, August 2, 2005
    0900 - 1000 Morning Session I

    1.Preliminaries -- Gabriel Montenegro
    Agenda bashing
    Blue sheets and notes takers
    Group has a new co-chair: Stefano Faccin
    2. Document Status -- Gabriel Montenegro
    FMIPv6 has received RFC number - this is the first RFC for the WG
    3. FMIPv6 MN-AR security: SeND-based Handover keys
    James Kempf

    James on SeND keys for MN-AR
    • usage: for FMIP, for context transfer
    • use send CGA RSA PK to encrypt a handover (ho) key,
    • how a ho key is used depends on ho protocol
    • name of key is the addr
    4. Mobile IPv6 Fast Handovers for 3G CDMA Networks
    Hidetoshi Yokota

    MIPv6 to be used in 3G network. Need seamless handovers, therefore fast handovers. Typically, MNs will be multi-homed and use different interfaces. This allows for smoother handovers. Bicasting during handover.

    Christian: Bicasting might confuse protocols at upper layers, like TCP...

    A: There was a draft in Mobileip working group using the eifel algorithm to cope with packet duplicates and out-of-ordering.

    Rajeev: Planning to build experimental testbed?

    Yokota: Yes.

    Q: How bad is a handover without FMIP6? Right now, we can do it at layer 2, but standard MIP6 won't be efficient enough.

    Q: Seems that you need additional messages...

    Rajeev: When you use FMIP6, you can skip some messages, namely the ones shaded blue in the presentation.

    Q: How about layer-3 information in layer-2 messages? Is this possible?

    A: Yes.

    Q: Would it help?

    A: We can skip some layer-3 messages.

    Q: The trigger seems to always come from the BS. Is this always the case?

    Yokota: If the MN loses connection, MN can trigger handover as a fall-back.

    5. Mobile IPv6 Fast Handovers over IEEE 802.16e Networks
    draft-jang-mipshop-fh80216e-00.txt Heejin Jang

    IEEE 802.16e handover process consists of preparation and execution (2 steps). For the purpose of FMIP6, we extend this to four steps: new-access-router discovery, handover preparation, handover execution, and handover completion.

    Charlie Perkins: Assume a handover is successful, but there are no packets buffered. Since you don't use NACKs, how does the MN know that the handover was successful?

    Rajeev: There should be an FBACK in the successful case.

    Suresh: What kind of delay would you have, e.g., with EAPoL?

    Alper: There are other optimizations. You can authorize several base stations at once to reduce the delay.

    Tuesday, August 2, 2005
    1030 - 1230 Morning Session II

    6. Hesham Soliman: HMIPv6 MN-MAP Security
    No draft yet. Hesham to lead discussion on alternatives and issues.
    Current scheme relies on IPsec between the MN and MAP, but RCoA is not reserved to the MN, and there is no binding between address and MN.

    The current IPsec solution works.

    Issues raised: shared keys are not an option; certificates not easily deployable on the host (due to no standard way of managing certificates) and do not work with AAA.

    Alex Petrescu: How about certificates on the AR?

    James Kempf: Security protocols with host-based certificates have not been successful. Cable networks use them, but in general it is a problem. EAPTTLS with server-side certificates are more widely used and deployable. Another reason, as discussed in netlmm - if you get a virus or spyware on host, virus could distribute address of MAP.

    Which model: authentication only, or both authentication/authorization? Current draft considers both.

    When using certificates: Authentication only => Certificates are only used for setting up a key. This is sufficient everywhere where mobility is a default service.

    Authentication/Authorization => different. This is needed if mobility is an add-on service (roaming scenario?)

    When using AAA: It is transparent to the MAP whether the MN roams or not because authoentication and authorization are entirely handled by AAA infrastructure.

    CGAs could be used in the authentication-only model, but they are not that useful in the authentication/authorization model.

    Suggestion: Keep current IPsec as default. Add other mechansims, as we know what the problem and scenario are.

    Greg Dailey: Wondering why you would not use IKEv1 in agressive mode with preshared keys.

    Francis Dupont: You should just refer to the PKI for the certificate version.

    Gerardo: As of now, IKEv2 and EAP could also be used. This is what we had done in MIP6 bootstrapping. Certificates is one option, IKEv2 and EAP is another one.

    James: Only minor difference with dynamic HA deployment. So current HMIPv6 to PS not wise.

    AA: What do you mean by keep the current mechanism?

    Certificates? EAP support is not there in the draft.

    Hesham: When this draft came out, there was no IKEv2.

    James: w/ regard to 3rd bulletpoint: We see a minor difference b/t this and dynamic home agent assignment (in bootstrapping draft). I don't support moving this to PS. We'll never deploy w/ dynamic home agent assignment

    Vijay Devarapalli: This is similar to assigning HA on visited link. Security for that is hard. Not possible to have cert for each MN, for each MAP. So I agree w/ James.

    Hesham: There is aggregate trust b/t domains. So it's not for each MAP.

    Vijay: You can't authorize MAP in visited domain.

    Hesham: This is chain of trust -- CA in visited domain trusts CA in home domain

    Vijay: We don't have something like this today

    A: yes we do, PKI

    Hesham: Point James made - if we have dynamic home agent mechanism we don't need this. But we don't have one today.

    Vijay: When you do local HA assignment in visited link, you have to set up security, so that solution would be applicable here

    James: We've discussed this, and it's not entirely as easy as you've made it.

    Shinta Sugimoto: You mentioned a scheme for MAP to verify uniqueness of rcoa of MN. in draft, it mentions that that will be used, but when MN is away,...

    Hesham: it's internal -- you check BCache, and if one already exists, you don't use it. It's just a way of checking for duplicates.

    Sugimoto: It should be done in initial BReg.

    Basavaraj Patil - On last slide, how to proceed - in order to keep complexity of MN minimal, we should use same mechanisms for base. on 2nd draft for ..... (talking way too fast to transcribe) stick to that, and don't worry about adding new security mechanisms

    7. Applying Cryptographically Generated Addresses and Credit-Based Authorization to Optimize
    Mobile IPv6 (OMIPv6)
    Jari, Wassim and Christian

    Goals for improving RO: Make authentication faster, but still infrastructure-less. Avoid delays of CoA tests by doing them concurrently. Incorporate ML discussion and reviews.

    Main ingredients: CGA, credit-based authorization for concurrent coa tests. During initial handshake, normal return routability, and info is bootstrapped for subsequent optimization (still on initial exchange slide)

    Peers have established BCE with 24 hr lifetime, extended sequence #, semi-permanent security assn (all valid for 24 hours) on "How Subsequent Exchanges Look Like" slide

    Alexandru petrescu: There were only 2 messages before, and now there are 4. Why would this be quicker?

    A: You have 6

    Alex: Well during initial exchange yes. But now in subsequent excahges you have 4

    A: You have 4 here instead of 6 in MIP. But you can use new CoA already after 2 messages, but it is unverified at that time.

    On slide "Where Credit-Based Auth comes into play" (describing how credit-based authorization works). Can use address up to a certain data volume, before it is verified.

    Last slide: Have re-written credit-based auth to make it more clear.

    Vijay: I don't understand why you need extended sequence #s

    A: Key used for computing Binding Auth data option can be used for longer time, up to 24 hours. Seq nos increasing during that time, and they might roll over.

    Charlie: That's a new coa every 2 seconds. Might suggest a different value.

    Vijay: 2nd question: if BC on CN expires, then you need to do initial handshake to HA again. Every time you do a fresh registration w/ CN again, you do 4 message handshake to HA. With CN, might not have extended communication. So you end up doing handshake w/HA each time. Some of the advantage is lost.

    A: When you are still w/in 24 hours, CN still has shared key, so you will do an optimized "handover" (re-registration)

    James: This looks really good. 2 questions. Technical: If CN doesn't understand this algorithm, it can fallback to return routability. So how do you prevent bidding-down attacks?

    A: in that case, CN would say it can do auth, but ...

    James: A lot of IPR on CGA, and IPR release for SEND doesn't apply to this. So WG and chairs need to decide on this. Ericsson has released it, but MS hasn't, so they need to release on this.

    BB: Bidding down can happen, but it's not really an attack.

    Hesham: On a high level, I like the idea. But how do you earn credit in real implementation?

    A: By sending data to CN.

    Hesham: No matter the content?

    A: IP traffic. You want to prevent CN to send more data to unverified address, to avoid amplification attacks.

    Hesham: Earning credit doesn't mean you are "[?]"

    Francis: Size of ? is 550. So you need a way to have larger options. So we have to fix this problem somewhere.

    A: So option space is insufficient?

    Gabriel: Please send that to the ML.

    8. FMIPv6 MN-AR security: AAA-based Keys

    Vidya Narayanan:

    Same problem statement as James's presentation with SEND, but we're trying to solve it using AAA

    Concept is handover master key shared between MN and AAA server

    Rajeev: I see it's an optimization and you can do it, but why?

    A: Useful when MN is rapidly between subnets

    Rajeev: What timespace are we looking at? 1-3 seconds? We should understand that part better.

    A: It really comes down to how the IP network is deployed. Example: MN is driving down a street and at every 4-way intersection, there are APs on different subnets. Something like this will help when you are changing subnets frequently. We couldn't come up with a reason why we shouldn't do this.

    Rajeev: It's good to have, but maybe better to have the base thing well specified

    Rajeev: You have AAA MN nonce. Have you thought about MN generating nonce so it can challenge network?

    A: It was there, but we removed it. Question: what value is it adding to have nonce from MN side? If we need to add it in, we can.

    Rajeev: In AKA system, you have mutual authentication.

    CC: Pre-authentication information. I agree it can help obtaining ? ,. there are 2 layers, using 802.11i,... Which are you using?

    A: Protocol for deriving network key not relating to network access at this point. Not pre-auth as defined in 11i. 1st message from MN to AR1, it can send an HO request to AR2 while it's attached to AR1.

    Hesham: Comment on what Rajeev was saying. There are some measured results where you end up with handover every 3 seconds (Gabriel: let's discuss this offline).

    Hesham: Next slide ("Salient Points") - have you considered using Context Transfer? It's not as beautiful security-wise, but you can have one handover key

    A: This has been beaten to death, and it's not considered secure enough. This is really a single round trip with every AR, and it's not in the critical path. You only need HO key when you're about to send FBU to old AR.

    Hesham: Depends on what requirements are on performance of HO. ..

    Continuing with slides. "Mailing List Discussions"

    James K: I agree it is more complex. Problem is you're asking that AR have security assn, and be aware of access server. In roaming, only NAS has this security assn. But the AR and AAA server have to know about eachother. This is extending AAA infra in a way that's not currently deployed. So unless NAS is colocated with AS, you have to upgrade the infra and deployment to establish that relationship. So I'm not sure how much leverage you get from AAA with this scheme.

    A: Leverage is that you don't have to share any other key with AAA server than what you already have for EAP.

    James: In terms of managing network and setting it up, that's a minor thing. If we could do this without AR having to know about foreign AAA server, it would be good. With enterprise, it would work fine. But for roaming situation it would be harder.

    A: Today with roaming, AAA-L acts as a proxy.

    Hesham: So you have AAAH, AAAL. I think you're making it more difficult for yourself than it is. If you're generating a key, and you transport it in RADIUS, I don't understand what the problem is

    A: Between AAA server and AR? That's exactly what we're doing

    James: ends up on NAS and not the router.

    Hesham: You authenticate, profile comes down, and you attach that

    A: Tying this protocol closely to network access.

    James: Sounds like you haven't read the draft. I was trying to figure out a way to derive the key from AAA

    Gabirel: continue on ML

    9. Neighborhood Information Elements Discovery (NED)
    draft-kempf-mobopts-nhood-discovery-00.txt Rajeev Koodli

    NED provides a generic protocol for carrying information elements of interest to IEEE 802.21. E.g., FMIP, CARD, IEEE 802.21 are information services, but are not harmonized. Protocols serve different purpose, yet share NED in common, but use differnet message formats.

    Need NED query-reply in a transport-independent way.

    Ajoy Singh: Are you re-inventing CARD?

    Rajeev: You resolve L2 identifier to something more useful for L3. No service attributes.

    Ajoy: We could have extended FMIP or CARD to do this. When CARD was designed, we wanted to provide this mapping, and get info from network. Request and response are the same as CARD. It was designed to get info about access network. 802.21 also defining this protocol.

    Stefano: Let's talk about 21 later.

    A: Transport is client-prtocol specific. CARD uses ICMP.

    Rajeev: Card uses ICMP; we want transport indepency.

    Ajoy: You can use ICMP, but you can use others.

    James: I responded to you on ML and gave you 5 reasons why CARD is unsuitable. I was WG chair, and I still think it was unsuitable.

    If information element is described in XML format, do you think it should be combined into? In this protocol?

    A: Message structure followed by TLV. Each option has its own data part. You can define your own structure in the data part.

    Suresh: Why did you want to model this after EAP? You're limiting yourself to 255 octets of data.

    A: Good point. We wanted the multiple protocols listed to use it. So we have to live with that limitation.

    James: It was an architectural sense. We wanted people to use it in different ways as mentioned.

    10. Media-Independent Hanover Services and Interoperabilty
    No draft

    Ajay Rajkumar, 802.21 WG Chair

    Brief background of what 802.21 is doing: handover enablers between 802.3/11/15/16 or 802.xx and 3GPP/3GPP2 or btw. 802.11 ESS. Focus on:
    • Adaptation to new link at L2
    • Address continuity at L3
    • Application continuity
    • transport requirements
    • protocol requirements
    Hesham: Started talking about protocols and architectures. What was the discussion that lead to making this on a lower-layer protocol instead of upper layer? If it was independent, shouldn't it be independent of link layer? Carried inside MAC layer?

    A: No, this is for the L3. Separate L2 requirements to discuss in another forum

    Alex P: You are developing an L3 protocol?

    A: These are specifically for L3 and above. So transport would be L3. And protocol would be carried in L3

    Q: Why is this presented here?

    Ajay: This is of benefit for layer 3 and the transport will be layer 3. Messages can carry layer-2 information, but that would only be static information, not dynamic like for instance signal strength.

    Hesham: Can you carry L2 information in L3?

    A: Yes, it could carry L2 infomation which is static, that is from information server

    11. Examples of Information Services
    Some Requirements for a Media Independent Handover Information Service - draft-faccin-mih-infoserv-00.txt

    Greg Daley

    Example Scenarios for Information Services. These are personal ideas, that might help people visualize things. Once pictures have come up, we can take questions. This is not the 802.21 group's view, but my own view.

    Q: When you say IS server, what do you mean?

    A: This is not a single cell or IP subnet. Enterprise domain or service provider.

    Q: (on "Example IS entities") So you have 3 components. One in mobile, one in access network. ...?

    A: This is not any single access network. So it may not be on one single hop, IPv4 subnet, or IPv6 link. So may be forwarding from mobile into access network. Could be on access router, access point, server in the network.

    Alex: could you be more specific on relationship between this example and work within this WG? For example, would FMIP be applicable here? Media-independent is like saying IP.

    A: an implementation on a host, with multiple interfaces and maybe multiple media. Media independent b/t upper and lower layer protocols. Maybe useful to have media-independent information elements for 802.16,802.11,802.15, cellular. That can be transported in case of event services or info services in L2 frames. But you may not want to deploy like that, but transport information services in IP-like

    Q: Do you restrict that client can not contact server directly?

    A: may not know server.

    On last slide, need to figure out how to discover where information server is, and establish security assn with server which allows transport to occur. May be NED, XML, ...

    Q: do you have to add SRP record for DNS?

    A: We need to check that it's valid and secure.

    Suresh: Circular dependency. If it's L3, we might end up with reactive handover, and we need discovery phase in the 1st hop.

    A: Implicit assumption is that there is an existing connection, in the same way you get a proxy rtr adv. You need an IP channel w/ existing network. This is not a realtime service.

    Q: if 1st hop NMI does not have information, then how is it retrieved?

    A: with redirection, you have to re-establish sec assn. If you have an SA, the other guy may be able to get it for you.

    Hesham: Followup on Alex's question. Since this is abstract, what does it have to do with us? Are we defining subset of this relevant to mobility?

    A: It is particular to mobility. It's supposed to support ip mobility, i.e. in DNA there may be add'l info that L2 passed up. It's here because it has info in common with CARD, FMIP, which are under assessment here.

    Hesham: So can we call it mobility information service?

    A: Maybe we need mobility independent blah blah blah...

    12. Rajeev Koodli: FMIPv6 bis (no slides)
    We got an RFC # (applause). Those who still have references to -03, please update to RFC 4068. Moving forward, issue tracker for bis version. FMIP6 is currently experimental. Everything we have so far is experimental or informational.

    IEEE 802.21 could provide a trigger for a fast handover.
    13. Gabriel: Discussion of Charter Items
    • OMIPv6 + CBA
    • HMIPv6 security and revision
    • Information Elements discovery and IEEE 802.21
    • FMIPv6 security and revision
      • SeND-based keys
      • AAA-based keys
      • protocol revision
    • Informational documents?
    Ajoy: Can we have comment on how CARD does not solve problem? CARD could also do NED

    James: Please write a draft to convince us.

    Stefano Faccin: Let's define requirements first, and then analyze what is available, including CARD

    James: Are you going to write up a charter and post it to the list?

    A: Yes. Most important things are deliverables.

    Gabriel: Thanks to all presenters. Please send presentations to chairs.


    MIPSHOP WG Agenda
    HMIPv6 MN-MAP security
    Applying Cryptographically Generated Addresses and Credit-Based Authorization to Optimize Mobile IPv6
    FMIPv6 MN-AR security: AAA-based Keys
    Media-Indeendent Hanover Services and Interoperabilty
    Examples of Information Services