Agenda bashing
Blue sheets and notes takers
Group has a new co-chair: Stefano Faccin

FMIPv6 has received RFC number - this is the first RFC for the WG

draft-kempf-mobopts-handover-key-01
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

draft-yokota-mipshop-3gfh-00.txt
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.

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.

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

Mobile IPv6 (OMIPv6)
http://www.ietf.org/internet-drafts/draft-arkko-mipshop-cga-cba-00.txt
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.

draft-vidya-mipshop-handover-keys-aaa-00.txt

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

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.

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

Requirements:

• 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

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...

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.

Proposed:

• 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.