Minutes MIPSHOP WG at IETF 64

 

Minutes edited by Stefano Faccin

Based on notes by Gerardo Giaretta and Basavaraj Patil

Meeting chaired by Gabriel Montenegro and Stefano Faccin

Slides presented included in the proceedings

 

MONDAY, November 7, 2005

1510-1710 Afternoon Session II

1740-1840 Afternoon Session III

 

1. Agenda Bashing

 

-        Agenda was approved

 

2. Securing MN-MAP communication (Suresh Krishnan)

    draft-haddad-mipshop-hmipv6-security-01

 

- The draft proposes a solution based on CGA, without requiring pre-configuration and reusing existing schemes. It assumes that SEND will be deployed. It indicates that SEND IPRs are going to be released, and tries to take advantage of that

- Assumptions: rfc2462 is used, SEND is deployed, and communication between AR and MAP is secured

- Crypto Based Identifiers (CBIDs): no I-D but paper by Gabriel Montenegro on how to generate a number given 128 bits number and the MN public key, and used to prove ownership of the address

Main points of discussion:

[Vidya]: is the Km known by three entities? Can the AR in the path see the Km?

[Suresh]: no, the AR does not have the private key of the MN to decrypt Km

[Vidya]: isn't the Km encrypted with the Ks and sent to the MN in the LBA?

[Suresh]: No because there is the MN public key is also used

[Hesham]: No additional IPR?

[Suresh]: Correct

[Hesham]: it would be a lot simpler in the operation if the communication is done between MN and MAP.

[Suresh]: right

[Hesham]: did you consider bootstrapping IPsec with the key MN and MAP exchanged? You could negotiate an algorithm in the exchange

[Suresh]: No, we didn't. But it could be possible, and would consider it

[Gabriel]: please, send further comments on the list. Question to WG: Is this WG interested in solving this problem?

[Hesham]: Does not have a technical problem with the I-D. The problem with HMIPv6 has been the fact that a PKI is needed within the scope of the roaming operators. However with this solution, the need for PKI is eliminated.

 

3. A scheme for MN-MAP Security in HMIPv6 (Jianying Zhou)

     draft-qiu-mipshop-mn-map-security-00

 

Solution based on public keys. Security MN-MAP is needed for securing LBU and avoiding redirect attacks. Two modes: authentication mode and authorization mode (only authorized users can use MAP)

Main points of discussion:

[Hesham]: redirect attack is a known attack for MIP6 and HMIP6. It has not been a requirement so far to fix it. We decided to not fix that problem so you don't have to fix it. Also the authenticated MN can perform a redirect attack. So authentication does not fix that problem.

[Hesham]: why do you send HoA in LBU?

[Jianying]: optional, to make the protocol consistent with the next mode of operation that addresses also authorization

[Hesham]: it's not needed and it does not do anything and the MAP cannot verify anything based on the HoA

[Jari]: concerning redirect attacks, in MIP6 you have a business relationship with MN that is stronger. You can go back and send the police or whatever. I'm not sure if we can skip that check here. I think we do need protection for this attack in HMIP

[Gabriel]: I think it is part of problem statement discussion. It's not relevant to this presentation. Perhaps we need to do a problem statement on HMIPv6 security since the problem does not seem clear to everybody 

[Hesham]: I never believed in the police scenario. I'm just trying to say that even an authenticated MN can flood another MN

[Vidya]: agrees with Hesham that redirect attacks can take place also with authenticated BUs.  Does not agree with Hesham that it does not need to be addressed. Suggests continuing discussion on mailing list.

4. Handover Keys using AAA (Vidya Narayanan)

     draft-vidya-mipshop-fast-handover-aaa-01

 

- no a lot of changes from last time in the basic protocol: a couple of open issues that we have solved in the draft but not discussed in the list

- objective: getting a key between MN and AR, assuming thatMN and AAA server share a HMK, and that there is a security association between AR and AAA (via AAA protocol)

- changes from 00

      - moved from UDP to MH to reuse mobility options

      - AR does a CoA validation to bind the CoA to the key

                   - the validation is to verify if anybody else is using that address

 

Main points of discussion:

[James]: you are using ND to find out if a CoA is valid. Don't you need SEND to verify if the CoA is used?

[Vidya]: we do not want to solve all ND issues, but here we want only to ensure that the CoA is not used by anybody else. So we don't need SEND.

[Greg]: we should use optiDAD and not something else

[Vidya]: it's similar to DAD

[Greg]: no use to have a solution similar to DAD

[Vidya]: here the node is on the link and we’re requesting the MN to not reply to the query otherwise there is no way to figure out if there is nobody else using the address

[Gabriel]: we'll discuss that on the mailing list

[Rajeev]: suggests motivating the problem. When MN-AAA with MIPv6 is there a problem? 

[Vidya]: this requirement came from discussion with James. I'm open to suggestions. It's more like: in addition to AAA model the question if we need to do this

 

5. RFC 4068bis (Rajeev Koodli)

    draft-koodli-mipshop-rfc4068bis-00

 

- revision for Proposed Standard

- two publicly available implementations: fmipv6.org and tarzan

- issue tracker: http://www.mip4.org/issues/tracker/mipshop/

- Issues reviewed: 8, 7, 11, 12, 6, 7, 5

- rest of issues will be discussed in the mailing list

Main points of discussion:

[Rajeev]: Issue 6: I would have it in a separate spec and not part of this

[Hesham]: Background: this was chosen because there was a problem in verifying the address. OptiDAD would simplify the spec a lot. Moreover stateful address configuration is not required for IPv6 nodes. It makes more sense to use stateless and solve the address verification issue instead of specifying the usage of a stateful mechanism that may not be supported by hosts.

[Rajeev]: so the issue is: does anybody care to have stateful if the address verification issue is solved?

[James]: I think we should have stateful because some people want it but we do not need to specify how the router gets the address. For example

IKEv2 does not specify anything. Here the complicating issue is that the address is not in a remote network but in a network where the MN is going to. OptiDAD is a good solution for that. For stateful case there is something that should maintain the availability of addresses. I think it's more important to specify properly for the stateless case.

[Alex]: why we need to define a new method to assign addresses?

[Rajeev]: we are not defining a new method. These are existing messages.

To be discussed further on the mailing list

[Hesham]: issue 7: you can do that and this is part of how it works. You can do with global address. There is not requirement in the ND to do it with link local. You can do DAD and unsolicited NA in the same time.

[James]: what happens if the address is duplicate?

[Rajeev]: there is no repair process even if you use optiDAD. That's a reason why we chose to use FBU as encapsulation of FNA

[Hesham]: there is minimal probability. It's more likely that the whole handover process will collapse.

[James]: agree but the probability if someone is attacking is higher

[Hesham]: it's a SEND issue. Just use SEND

 

6. Problem Statement: Media Independent Handover Signaling (Eleanor Hepworth)

    draft-hepworth-mipshop-mih-problem-statement-00

 

- Draft motivated by discussion on MIPSHOP mailing list on MI services, it’s a step backward wrt the other drafts on the topic. Focus is on responsibility of the common protocol aspects between the various MI services

- Wonders what is the role of the IETF in this work.

Main points of discussion:

[Hesham]: I don't understand the problem

[Eleanor]: this is a problem framework

[Hesham]: is correct to say that you presented the framework and the problem is the missing pieces for that solution?

[Eleanor]: yes

[Gabriel]: discussion will be more productive with the next two presentations

[Madjid]: not clear on what 802.21 does. Would have expected to see picture with 802.21 services below IP, not on top of 802.21

[Hesham]: what is the actual issue?

[Stefano]: should wait for next two presentations addressing specifically the 802.21 services

 

7. Some Requirements for a Handover Information Service (Greg Daley)

    draft-faccin-mih-infoserv-01

 

- introduction to 802.21 services with focus on Information Services:

      - associated with passing link layer and network layer information through link layer or network layer protocols

      - information server may or may not be an adjacent network entity

                   - if not adjacent a layer 3 protocol is needed

      - there may be additional mobility services delivered via IP protocols

- handover Information Services

      - assistance in handover planning rather than handover procedure

      - in managed network information about adjacent or neighbor networks that can be used by e.g. FMIPv6

      - it's not real time event information rather for topological information

      - possible different requirements for the delivery of this information and the delivery of event notification that may have real time constraints

- scope of the work

      - needs to be discussed in detail with .21

      - at least 3 tasks: service/server discovery, establishment of security association, transport layer issues (we may look also at information elements but my guess is that most of information elements will come from .21)

Main points of discussion:

[James]: two levels of information that is desired. Low level of information: APs or ARs next to MN. Higher level of information (e.g. prices). These two levels of information may be incompatible. The low level is really needed. For high level there is a lot of problematic business issues. They may not be advertised by network operators. I don't see the high level is useful. I hope .21 will focus the scope on the low level ones.

[Parviz]: in 3G and WiMAX models, layer 2 and layer 3 are strictly tied for handover. Any information you try to centralize on the IP side it has to be tied to your radio access network and some of this information are signaled by the MN. So how do you bring these dependencies?

[Greg]: use scenarios later

[Alper]: is this an output of .21?

[Greg]: no. We would put as an input to .21 as a helper. We need to do our own work and we need to figure out what we want to do

[Alper]: how about the payload?

[Greg]: payload may be involved and will be discussed in the .21

[Alper]: are you saying that payload should be defined by IEEE and is treated as opaque in IETF?

[Greg]: that is something that is worth discussing

[Hesham]: are we getting an official request?

[Greg]: I'm not representing .21

[Hesham]: I have some concerns. IEEE docs are protected by password and it is very difficult to have people participate.

[Greg]: we'll try to make them available

[Hesham]: I also think that .21 should come here and say what they need. It's great to anticipate but there are also other SDOs that may be interested

[Subir]: there may some official liaison with .21 I partially agree with James. I don't think that in case there are no roaming agreements the MN can roam in any network. The assumption is that there is always a roaming agreement. This is one of the motivations for IS. There is discussion in .21 on which information are needed and useful.

[John Loughney]: WG should say which IS are useful. This discussion should go in the problem statement.

[Greg]: agree with your points

[Madjid]: are we defining the scope of .21?

[Greg]: we are trying to understand which scenario is a good starting point for the work

[Madjid]: are trying to do another Seamoby?

[Greg]: no. Most of contents will come from .21. They work on MAC protocol and not on the IP and they do not do security considerations as we do

[Madjid]: I think that IEEE .21 should be focused on L2 issues. And I think that mobility protocols need L2 information. I don't understand how this discussion is related to mipshop since it is dealing with MIPv6

[Stefano]: we'll discuss that during charter discussion later

[Junghoon Jee]: .21 defines discovery. Should we focus on the transport only?

[Greg]: there are IS that are not in local IP subnet and need to be discovered. In this case you cannot discover the server using layer 2 protocols. We need to identify whether this is a problem.

[Junghoon]: what's the role of .21 and mipshop for discovery?

[Greg]: it may be possible for .21 to define in the MAC layer a kind of discovery but my guess is that this may not be always possible

[Junghoon]: .21 considers the case that the discovery is done at layer 2. .21 may define the discovery messages and mipshop should define the transport of these messages.

[Greg]: I would encourage .21 to look at what there is for service discovery and not reinventing. I don't care what the messages are because it does not affect the transport.

[Stefano]: if we want to do discovery over layer 3, IETF has that know-how

[Hesham]: you are asking for a protocol with discovery, reliability, security. You define the carrier and not the information. Why it should be done in mobility WG? The other concern is that it's really hard to define the protocol without understanding the architecture and requirements and we do not have that knowledge.

[Greg]: I can't answer the charter question that would be discussed later. I do agree on the second concern.

[Rajeev]: it's only an interpretation of what .21 might want and not official requirements. It's difficult to have an opinion. One starting point is to see how it is done in other networks (e.g. 3GPP proxy CSCF discovery).

[Eric Njedjou]: I think mipshop is the right place

 

8.  A Problem Statement for Event Services and Command Services for Media Independent Handovers (Greg Daley)

    draft-sreemanthula-es-cs-problem-01

 

- Event services: provides indication of link layer changes; remote ES convey information form one network node to another over IP

- Command Services: command to change state, within a stack but also possible to deliver information between stack elements

- different scenarios: terminal controlled handover and network controlled handover (network makes decisions on network selection in coordination with the terminal; operator oriented model which works with multiple types of technologies)

- caveats: there is a warning from IAB of not passing the events across the network. Draft addresses issues raised

 

Main points of discussion:

 

[Alper]: is this just background or IETF work?

[Greg]: I think most work will be from IS

Not much discussion due to lack of time.

 

9 . Applying Cryptographically Generated Addresses and Credit-Based Authorization to Mobile IPv6 (Jari Arkko)

    draft-arkko-mipshop-cga-cba-02

                     

- RO scheme goal: improving latency and signaling overhead

- based on two techniques: CBA and CGA

- news in version 02: extended Sequence Numbers option not needed; if you run out of the numbers it's easy to setup a new key; splitting the parameters to multiple options and concatenate them

- draft stable

- issue for discussion

      - concurrent CoA test currently done through BU/BA options

                   - cuts the number of messages

                   - makes proactive handover difficult

      - please sends comments

 

Main points of discussion:

[Gabriel]: multihoming and multi-interfaces and multiple CoAs. What about this protocol? Could be simpler?

[Jari]: if we have multi-interface we may not need any optimizations. It could be useful if we discover that we need to much power to keep on the interfaces, but it's an issue to think about.

 

10. FMIPv6 over 3G (Hidetoshi Yokota)

    draft-yokota-mipshop-3gfh-01

 

- implements fast handovers in 3G CDMA, added some extensions and clarification from last meeting

- defines a collection of information available for the target handover as handover assist information

- when MN receives handover indication, it start FMIPv6

- issue in predictive handover: in 3G new AP LLA is not used (pilot channel may be used and the information is bigger); new option-code is defined in the LLA option to convey handover assist information

- other issue: several ways to implement FNA, otherwise it's possible eliminate FNA and to use PPP with IPv6CP option

- reactive mode may be useful but nAR cannot buffer packets: pAR instead of nAR may buffer packets

- some clarification for selective bi-casting: bi-casting can be done at pAR or HA

Main points of discussion:

[James]: we did some work on the low latency in MIP protocol. The problem is that the FBU may be delayed also 300 ms and the MN gets to the new AR before the handover has detected. You cannot solve this problem by bi-casting because the problem is between MN and pAR. I would encourage you to find out if this is still a problem.

[Hidetoshi]: for lossless handover we need buffering

[James]: buffering will not help very much. The problem is with L2 handover and delay in the FBU. This is in predictive mode in CDMA 2K

[Gopal]: the bi-casting is not done to increase the reliability of FBU. It's just an optimization.

[Greg]: (slide 5) If this information needs to be passed to get the handover working, should not be passed to LLA option but in a new option. We need a new type. On next slide: if the PPP peer does not support the new option you have an additional round trip. PPP is not the right place

[Parviz]: 3GPP2 has a layer 2 handoff that requires the PPP session to be anchored to the old AR. A layer 3 fast handover solution would be good for 3GPP2

[Rajeev]: in response to a previous question about FBU, surely the FBU can get lost but you are still receiving packets in the downlink.

 

11. FMIPv6 over over IEEE 802.16e Networks (Heejin Jang)

    draft-jang-mipshop-fh80216e-00

 

- presented 802.16e reference architecture and 802.16e handover overview

- 3 main changes from last presentation: two more primitives are defined, from five to four handover- steps procedure, and described how our proposal could be implemented accordingly to 802.21

 

Main points of discussion:

[Parviz]: architecture that you presented has AR and BS integrated. The AR and BS are not necessarily combined. In WiMAX there are different flavors of the architecture. You need to define a reference architecture before defining triggers. Before defining a protocol we need to stabilize the architecture.

[Junghoon]: in the draft there are two models: there are the combined and the separate models.

[Parviz]: BS is a L2 device and the AR is a L3. You need to separate them

[Alper]: in the context of FMIPv6 it does not matter if AR and BS are co-located. You only need a protocol between AR and BS to deliver triggers and this is discussed by .21

[Parviz]: if you look at the call flow you cannot collapse BS and AR into one logical entity

[Heejin]: they are logically separated but may be co-located in the implementation

[Rajeev]: here she's looking what happens when you change AR. This is not a tentative to solve a WiMAX problem but a .16e application

 

12. Charter discussion

 

- discussion in the mailing list: already reached consensus for some items

- FMIPv6 over foo

      - consensus for YES for informational

      - some people asked with PS but we are going for Informational

- threats and security modeling for discovery and transport for 802.21 IS

      - no much support to go forward with this draft

- Event Services and Command Services (in addition to IS) support

      - consensus for YES

      - some opposition due to lack of clarity in requirements

      - already consensus for IS

- new charter presented

Main points of discussion:

[Parviz]: is .21 related also to FMIPv6 over foo?

[Gabriel]: there may be some interactions

[Parviz]: if there is such a relationship, it may delay the work

[Stefano]: they are decoupled even though there may be interactions

[Junghoon]: discovery in .21?

[Stefano]: the charter does not mention discovery. Specific items for .21 need to be discussed further

[Hesham]: It's difficult to decide which aspects of .21 we need to address. I would like to see the whole picture for .21. I'm just wondering if we need to have a more precise idea on what is done in .21. Isn't it too early?

[Gabriel]: A lot of participants of this WG participate to .21 and will bring info in informal basis. In a formal basis we are still waiting for requirements.

[Hesham]: I'm not against to do that. Not having access to documents is a problem

[Stefano]: That's up to .21 chairs to decide. I'll ask .21 chairs

[Hesham]: if they want cooperation they should give access to drafts

[Subir]: we should establish a better flow so that this WG can understand better .21

[Vidya]: A question on FMIPv6 over foo documents. We are updating FMIP, does it make sense to work on FMIP over foo?

[Gabriel]: We can continue in parallel. They are informational

[Rajeev]: We can get input from foo documents

[Alex]: probably there are too many items in the charter

[Stefano]: continue discussion on mailing list