[16:03:22] --- ks has joined
[16:03:32] --- ks has left
[16:05:09] --- TJ has joined
[16:05:59] --- ks has joined
[16:06:14] --- ks has left
[16:06:48] <TJ> Agenda bashing done
[16:06:59] <TJ> Working Group Status (documents)
[16:07:21] <TJ> Vidya N. - how can we have a last call on FMIPv6 before we know what the security solution is?
[16:08:11] <TJ> draft-kempf-mipshop-handover-key-00 -- waiting for mob dir review
[16:08:47] <TJ> No consensus yet on HMIPv6 security.
[16:09:11] <TJ> Alper Y. - on previous slide, was there a mob dir review on Vidya's AD?
[16:09:15] <TJ> Not yet.
[16:09:42] <TJ> James K. did a review as individual, and then as Mob Dir.
[16:10:00] <TJ> James - I don't think this needs another review. This is ready for working group adoption and review.
[16:10:20] <TJ> Alper - There are a couple of other proposals for this problem space. Shouldn't we evaluate them all at once and make a decision?
[16:11:01] <TJ> Vijay - If there are significant issues for what's on the table, or alternates provide significant improvement, they can be considered.
[16:11:24] <TJ> Alper - Why should it be significant improvements? There are other alternatives that should be looked at.
[16:12:00] --- petrescu7 has joined
[16:12:04] --- ryuji.wakikawa@gmail.com has joined
[16:12:12] <TJ> Vijay - The WG has spent a lot of time working on this. It is up to the authors of the alternate solutions to convince the WG.
[16:12:12] --- ks has joined
[16:12:36] <TJ> James - I have been working on this document for 3 years. We should go forward with what we have, and once these are finished, we can look at the others.
[16:13:59] <TJ> Vidya - If we continue process and exhaust the solution space before we pick something, it's not possible. The SEND-based solution has been around a long time, and AAA 1 1/2 to 2 years. New proposals shouldn't be related to existing documents
[16:14:52] <TJ> Alper - Is this needed in such a rush? Why can't we evaluate all the solutions?
[16:15:30] <TJ> Jari A. - Let's look at the presentations, and if we get new information, perhaps the decision on whether we adopt these can change.
[16:17:19] <TJ> HMIPv6 security hasn't made any progress yet.
[16:17:38] <TJ> Drafts on FMIPv6 over different networks - CDMA & 802.16
[16:17:52] --- jasso1 has joined
[16:18:17] <TJ> 3g CDMA document is being brought closer to 3GPP2 specs
[16:18:38] <TJ> 802.16e doc is postponed for now to wait for ? to make more progress
[16:19:06] <petrescu7> slides at https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=67 search 'mipshop' find 'Applying CGA/CBA to MIPv6', 'FMIPv6 for 3G CDMA Networks', 'FMIPv6 extension for Multicast Handover', 'HMIP and FMIP SA', 'Handover Key Hierarchy for HMIPv6', 'Mobility Independent Services: Problem Statement', 'Mobile and Wireless Neighborhood Discovery using DHCP', 'Transmort of MIH Messages over IP', 'Authenticating FMIPv6 Handovers'.
[16:19:13] <petrescu7> wait for 16ng to make progress.
[16:19:23] <petrescu7> 16ng is a WG
[16:19:29] <TJ> Media Independent Handoff doc - should have had a problem statement <missed comments here>
[16:19:42] <TJ> <from Stefano>
[16:19:53] <TJ> ---
[16:20:06] <TJ> draft-ietf-mipshop-cga-cba document status update
[16:20:27] <TJ> presented by Wassim Haddad
[16:21:41] <TJ> Problem with minimum RSA key length of 384.. It might be possible to use integer factoring to break the private key at 384 bits.
[16:21:56] <TJ> Three options for solving this.
[16:22:12] <petrescu7> Hesham Soliman approaching
[16:22:21] <TJ> Hesham - Do you have a preference? I think the third one makes sense.
[16:22:34] <TJ> A: The first and the third make sense.
[16:22:52] <petrescu7> Zhen Cheo
[16:22:54] <TJ> Hesham - What if the CN doesn't agree with minimum and rejects it? I'm fine with 1st and3rd
[16:23:05] <TJ> ? - Minimum RSA can be ???
[16:23:12] <TJ> 704
[16:23:14] <petrescu7> 704
[16:23:35] <TJ> Depends on the application. Minimum ??? we can avoid this problem.
[16:23:46] <TJ> Name - Tsin from Peking University
[16:24:00] <petrescu7> Tsin is Zhen
[16:24:01] <TJ> Hwi-ten - Comment on solution three. ??? may not be enough
[16:24:06] <petrescu7> Cheryl Madson?
[16:24:34] --- behcet has joined
[16:24:49] <TJ> Jari A. - Option 3 would be the right way forward. Perhaps we could combine with option 1. But I don't know if that's really needed. These are keys only used for address ownership, not banking.
[16:25:08] <TJ> ---
[16:25:32] <petrescu7> Zhen Cho presenting going to
[16:26:04] <petrescu7> Ah it's Cao!
[16:26:33] <TJ> Integrating Identity-Based Crypto with CGA in MIPv6
[16:27:10] <TJ> RFC 3972 Section 7.4 cautions about using CGA for purposes other than SEND.
[16:29:57] <TJ> Going over attacks to CGA.
[16:31:03] <TJ> Hesham - Could you explain auto-configure attack?
[16:31:35] <petrescu7> Zhen: CGA verifyiers
[16:31:54] <TJ> Jari - Attacker makes his own keypair and address. That's possible, but what's the harm in that?
[16:32:20] <TJ> A: Address ownership is not a problem, but we can't verify that it's trusted
[16:32:27] <petrescu7> Zhen: we have a test like this
[16:33:12] <TJ> Vidya - I don't understand how the term attack applies. CGAs don't provide authentication. You wouldn't use CGAs in a network that requires authentication.
[16:33:23] --- sbotzko has joined
[16:33:33] --- florent.parent@gmail.com has joined
[16:33:38] <petrescu7> Zhen: MN-CN scenario
[16:33:53] <TJ> On to slide about Address ownership problem
[16:34:32] <TJ> Now explaining IBC
[16:34:52] <TJ> (This seems to be pointing out a problem which CGA does not portend to solve)
[16:35:31] <TJ> Vidya - Why is there a need to add authentication to CGA? It does what it was designed for.
[16:35:38] <petrescu7> Zhen: think without auth how do you say that the endpoint is trusted
[16:36:06] <petrescu7> Zhen: cga has a veryified, we have to do public key crypoto, strong case
[16:36:12] <petrescu7> Zhen: if the key is auth
[16:36:27] <petrescu7> Zhen: if merge zuth key into CGA then use CGA to solve both auth and address ownership
[16:37:56] <petrescu7> Zhen: yes, correct
[16:38:04] <TJ> Kaja from Microsoft - Are you proposing that CGA be enhanced, so you're not solving an existing problem with CGAs, but you're proposing an enhancement so that it can be used for authentication
[16:38:12] <TJ> Vidya - How is that different than certificates?
[16:38:27] <TJ> Kaja -We haven't heard the description of the solution yet.
[16:39:21] <petrescu7> Zhen: cga now is using auth, address, auth method messages
[16:39:36] <petrescu7> Zhen: when CGA is used w e should consider more than CGA initicorespondator
[16:40:28] <petrescu7> Hesham: what app?
[16:40:41] <petrescu7> Zhen: app is a problem, whether we can provide auth in cga is a question
[16:40:45] <petrescu7> Hesham: not a problem.
[16:40:54] <petrescu7> Hesham: if you don't ok.
[16:41:01] <petrescu7> Hesham: saving memory on device?
[16:41:06] <petrescu7> Hesham: is this the right WG?
[16:41:12] <petrescu7> Hesham: stuff for mobility enhancements
[16:41:19] <petrescu7> Hesham: informational ?
[16:41:21] <petrescu7> TJ kniveton
[16:41:34] <petrescu7> TJ: what is proposing? let him explain.
[16:41:59] --- sbotzko has left: Replaced by new connection
[16:43:11] <TJ> Zheng is explaining the "what is IBC-CGA" slide, and now on the Comparison slide.
[16:43:39] <petrescu7> Zhen: Deng Hui?
[16:44:02] <TJ> Zhen is the presenter
[16:44:08] <petrescu7> Deng is questioner
[16:44:23] <petrescu7> Deng: how about fast mip doing similar things?
[16:44:30] <petrescu7> Zhen: yes, we can adopt.
[16:45:15] <TJ> James K. - We've done research on identity-based cryptography in our labs, and our conclusion was that there are 2 fundamental problems: you can't use this in an open world without infra support (same as for PKI or AAA), so we didn't see advantage for something new
[16:45:40] <TJ> 2nd issue: algorithms out there are 1-2 orders of magnitude slower than RSA because of tape-pairing(?) which is expensive
[16:45:54] <TJ> So putting this technology in this level of the system might not be right.
[16:45:54] --- sbotzko has joined
[16:46:00] <petrescu7> Zhen: for 1st q, if we encaparacing, we can also trust hall right?
[16:46:16] <TJ> James - There are other ways to do that, other than in the address.
[16:46:25] --- maeno has joined
[16:46:46] <petrescu7> Zhen: 2nd q, current to ipv6 in this state, crypto such as ecc nsi in our lab we have done new code cbk, public and security from a factor matchings
[16:46:56] <petrescu7> Zhen: only key is generated in factor.
[16:47:08] <petrescu7> Zhen: so the security already depends comparably not to ipv6 itself?
[16:47:27] <petrescu7> Zhen: you mean pairing? or compairing?
[16:47:29] --- maeno has left
[16:47:31] <petrescu7> Zhen: we rely on ECC
[16:47:38] <petrescu7> Zhen: depends on ECC signature
[16:48:12] <petrescu7> Zhen: you mean pairing is something on online?
[16:48:19] <petrescu7> Zhen: our algos now don't depend
[16:48:24] <petrescu7> Zhen: we don't use tape pairing
[16:48:38] <TJ> (out of time - discussion to mailing list)
[16:48:41] <TJ> ---
[16:48:50] <TJ> Fast Handovers for 3G CDMA
[16:49:31] <TJ> Hidetoshi Yokota - KDDI
[16:50:34] <sbotzko> tape-pairing is "tate pairing"
[16:51:15] <petrescu7> aha
[16:51:49] <TJ> Going through slides.. currently on network-controlled FHO
[16:52:58] --- maeno has joined
[16:53:02] --- kakima has joined
[16:55:26] --- behcet has left
[16:56:53] <TJ> Hesham - This is not fast handover
[16:57:04] <TJ> A: Can you wait? there are 5 messages defined in 3GPP2
[16:57:55] <TJ> Hesham - This is just a handover scheme that you think is fast.
[16:58:47] <petrescu7> it's _immediate_ fast handover
[16:58:51] <TJ> Vijay D. - I encouraged us to see how 3GPP2 is doing fast handovers. I wasn't expecting to see the HRDP call flow on a slide. We're not going to standardize what's being done in 3GPP2.
[17:02:07] --- behcet has joined
[17:02:14] <petrescu7> GEorge Tsirtsis: nAR sends proxy BU to ..., then why MN does it too.
[17:05:23] --- maeno has left: Computer went to sleep
[17:07:07] <petrescu7> Vidya Narayanan VN
[17:07:50] <TJ> sorry, gotta go.. Alex can take over all notes
[17:07:57] --- TJ has left
[17:08:25] <petrescu7> Vijay Devarapalli
[17:08:35] <petrescu7> VD: in charter we have apply fmipv6 to 3gpp
[17:08:52] <petrescu7> VD: options: not doing anything (let 3gpp do)
[17:08:59] --- kakima has left
[17:09:10] <petrescu7> VD: design a solution for them
[17:09:14] <petrescu7> Vidya N
[17:09:23] <petrescu7> VN: best get out of these reqs from SDOs
[17:09:33] <petrescu7> VN: get a list of reqs, then while doing 4068bis
[17:09:49] <petrescu7> VN: try meet as many reqs as we can
[17:10:00] <petrescu7> VN: write a doc BCP: here's how to apply 4068bis to 3gpp
[17:10:18] <petrescu7> VN: don't think that define new messages that exclusively pp2 will be using makes sense in ietf
[17:10:24] <petrescu7> presenter H
[17:10:33] <petrescu7> H: possible, but, want to listen fo comments
[17:10:37] <petrescu7> Hesham Soliman
[17:10:49] <petrescu7> HS: intention of fast ho was to be adopted. But please use it.
[17:11:01] <petrescu7> HS: if you find needs to updated, good time to say that now.
[17:11:26] <petrescu7> HS: for what you've desribed we can even have an informational document. Unless you need drastic rework.
[17:11:31] <petrescu7> HS: doesn't need that.
[17:11:34] <petrescu7> presenter H:
[17:11:40] <petrescu7> H: how much should I tweak.
[17:11:45] <petrescu7> HS: don't be rigid about it.
[17:12:00] <petrescu7> HS: if you can input towards existing work, then do it now.
[17:12:05] <petrescu7> H: so no new messages
[17:12:13] <petrescu7> VD: different extensions to options is fine too.
[17:12:24] <petrescu7> VN: work is useful, provides us feedback.
[17:12:29] <petrescu7> VN: step back put these as reqs.
[17:12:45] <petrescu7> VN: then it's possible to get community feedback on whether or not 4068 satisfies reqs.
[17:12:52] <petrescu7> VN: can go into general protocols.
[17:13:06] <petrescu7> VN: rather than saying here's how we propose to extend the protocols.
[17:13:15] <petrescu7> VN: important talk about first step - what's needed.
[17:13:42] <petrescu7> Suresh Krishnan
[17:13:51] <petrescu7> slide: authenticating binding updates in fmipv6
[17:14:18] <petrescu7> slide: Motivatio
[17:14:31] <petrescu7> slide: What's new in this version?
[17:15:02] <petrescu7> slide: First Steps
[17:15:32] <petrescu7> slide: Proposed Solution
[17:16:51] <petrescu7> putting up a picture in a hurry
[17:17:15] <petrescu7> slide: picture of 4 boxes pAR nAR MN and new position of MN
[17:17:56] <petrescu7> James Kempf approaching
[17:18:06] <petrescu7> JK: is there some problem doing SeND with every AR
[17:18:11] <petrescu7> SK: computationally expensive
[17:18:19] <petrescu7> SK: boroowed form draft-kempf
[17:18:32] <petrescu7> JA: proposal for secure AR to MN nd that doesn';t use SeND?
[17:18:37] <petrescu7> SK: first process uses SeND
[17:18:46] <petrescu7> it's not JA it's JK
[17:19:02] <petrescu7> Alper Yegin talking w/o microphone
[17:19:13] <petrescu7> that was n ot Alper Yegin but Wassim Haddad
[17:19:19] <petrescu7> JK: SeND is between MN and AR
[17:19:26] <petrescu7> SK: if not that then smth else
[17:19:32] <petrescu7> JK was that
[17:19:39] <petrescu7> Lacksminath Dondetti
[17:19:47] <petrescu7> LD: you could it wrong in a 1000 different ways
[17:19:56] <petrescu7> LD: there are more issues more fundamntemal than that
[17:20:10] <petrescu7> LD: the AR, the key
[17:20:14] <petrescu7> Wassim: it's not the key
[17:20:19] <petrescu7> LD: the hashing is bieng computed
[17:20:23] <petrescu7> SK: on the mobile
[17:20:32] <petrescu7> SK: he doesn't know yet the undisclosed value
[17:20:44] <petrescu7> SK: H1, h2, h3 to h20... I disclose h20... so the AR doesn't know.
[17:20:56] <petrescu7> LD: each new one would not.
[17:21:08] <petrescu7> LD: would that value be of any use,knowing PAR used a ...
[17:21:26] <petrescu7> LD: hashing has h1, h2, h3... ar1 knows h3, h3 can be derived from h2
[17:21:34] <petrescu7> SK: no, secure FBU from PAR
[17:21:44] <petrescu7> SK: disclosed value is hn, undisclosed is hn-1
[17:21:50] <petrescu7> SK: par knows hn.
[17:22:01] <petrescu7> SK: I create an ncoa...
[17:22:13] <petrescu7> SK: par is the only guy knowing the one-way hashing.
[17:22:18] <petrescu7> LD: other suggestion
[17:22:43] <petrescu7> LD: same key used to derivy the hashing as well as an address, you use the same key in two differnt ways: disclose secret part of MAC already
[17:22:52] <petrescu7> SK: that's why hb run number calculator
[17:23:02] <petrescu7> LD: could still mess it up
[17:23:31] <petrescu7> Frank Xia
[17:23:41] <petrescu7> slide: FMIPv6 Extensions for Multicast Handovers
[17:23:55] <petrescu7> slide: Problem Statement -1
[17:24:31] <petrescu7> slide: Problem Statement - 2
[17:25:03] <petrescu7> slide: Problem Statement - 3
[17:25:47] <petrescu7> slide: Proposed Solution
[17:27:25] <petrescu7> George Tsirtsis
[17:27:37] <petrescu7> GT: Hi includers a mc group the mobile joined?
[17:27:40] <petrescu7> FX: yes
[17:27:52] <petrescu7> GT: new AR would join these groups?
[17:28:06] <petrescu7> FX: yes, some different scenarios... use this info to join mc
[17:28:17] <petrescu7> slide: Mailing List Discussions - 1
[17:28:51] <petrescu7> slide: Mailing List Discussions - 2
[17:28:59] <petrescu7> slide: Next Steps
[17:29:14] <petrescu7> VD: this is new work being proposed in WG
[17:29:22] <petrescu7> VD: mipshop charter already has items
[17:29:54] <petrescu7> GT: initial reaction is that this proposal takes one piece of state and moves it around using AR-AR messages, a bunch state should be moved around - why not QoS , security state
[17:29:59] <petrescu7> GT: a lot of state
[17:30:13] <petrescu7> GT: not sure AR-AR message is the best way to do this
[17:30:21] <petrescu7> FX: also include other info
[17:30:31] <petrescu7> GT: the fmip signalling may not be the best
[17:30:37] <petrescu7> AR-AR is HI-HAck
[17:30:42] <petrescu7> Behcet Sarikaya
[17:30:51] <petrescu7> BS: VD is asking about the problem statement - should we work on it
[17:31:09] <petrescu7> VN: not a compelling problem: fmip provides way to forward all packets, include mc.
[17:31:18] <petrescu7> VN: we prevent mc join at new AR?
[17:31:38] <petrescu7> FX: yes, in ... there is pAR deliver all traffic to nAR not only
[17:32:55] <petrescu7> FX: there is some multicast i
[17:33:02] <petrescu7> VD: concentrating on problem
[17:33:19] <petrescu7> GT: if you want to avoid joins on new link then talk about Context Transfer
[17:33:35] <petrescu7> GT: if talk about temporarily moving multicast traffic over the fmip tunnel
[17:33:54] <petrescu7> GT: buffering mc from one to the other
[17:33:59] <petrescu7> GT: a separate discussion
[17:34:18] <petrescu7> VD: assumption there is a net where fmipv6 is being used., multicast sessions. How do we handle this?
[17:34:25] <petrescu7> MAdjid Nakhjiri
[17:34:38] <petrescu7> MN: I agree... (agree gt better CT than hi/hacks).
[17:35:12] <petrescu7> VN: can we split into two problems: forwarding muclticast packets (fast session handoffs)., can we avoid having to rejoin at new ar.
[17:35:35] <petrescu7> VN: former can be handled by minor mofdis to 4068 bis, but the latter ... ct for mobility protocols?
[17:36:06] <petrescu7> GT: test issue, I can comment about buffering moving multicast traffic, look at it a bit more, mc is not reliable, streaming, what you gain by moving it around...
[17:36:23] <petrescu7> VN: look into is not that another interface? it's not specific to fmip either
[17:36:30] <petrescu7> Hesham Soliman
[17:36:34] <petrescu7> slide: objectives
[17:36:39] <petrescu7> rfc4140
[17:37:11] <petrescu7> slide: Issues raised against RFC 4140
[17:39:39] <petrescu7> slide: Issue 1: Expand Security to include allow for cases where the MN is not configured with a certificate
[17:39:43] --- alfredprasad has joined
[17:39:55] --- jasso1 has left
[17:40:27] --- sbotzko has left
[17:40:52] <petrescu7> slide: Tightening up the spec language
[17:42:04] <petrescu7> slide: Issue 3: Integration of the AR in the signalling path to allow for triggering AR funcitons like CT
[17:42:44] <petrescu7> slide:Adding the AR to the signaling path
[17:43:23] <petrescu7> Vijay Devarapalli approaching
[17:43:53] <petrescu7> VD: two comments
[17:44:02] <petrescu7> VD: BU is ESP encrypted, not visible to the AR
[17:44:09] <petrescu7> HS: which part of the packet is used to alert
[17:44:13] <petrescu7> VD: in the MH?
[17:44:18] <petrescu7> HS: no, dst opt?
[17:44:22] <petrescu7> HS: hop by hop
[17:44:31] <petrescu7> HS: you could do source routing with alert in dst options.
[17:44:44] <petrescu7> HS: we need to discuss how to make it secure
[17:45:02] <petrescu7> VN: what info is the AR exchanging?
[17:45:10] <petrescu7> VN: why BU is not endedntoend?
[17:45:15] <petrescu7> HS: it is, but just alerting.
[17:45:24] <petrescu7> HS: BU as trigger for Context Transfer
[17:45:31] <petrescu7> HS: BU would include additional information
[17:45:48] <petrescu7> VN: mobile could actually include more info in the packet, for the benefit of the AR
[17:45:57] --- rjaksa has joined
[17:46:01] <petrescu7> Jari Arkko
[17:46:09] <petrescu7> JA: why not sending a packet to the AR?
[17:46:12] <petrescu7> JA: why many things with same
[17:46:25] <petrescu7> HS: you could send a packet of course
[17:46:29] <petrescu7> HS: fast handovers
[17:46:37] <petrescu7> JA: micro-optimization
[17:46:54] <petrescu7> HS: depends, on principle we agree we can send two packets. Link-layer, depends how much to send.
[17:46:58] <petrescu7> HS: I agree two packets.
[17:47:07] <petrescu7> JA: focus your efforts on something that has impact
[17:47:14] <petrescu7> JS: not as every voice packet would carry bu
[17:47:18] <petrescu7> JA was that
[17:47:23] <petrescu7> JA: header compression.
[17:47:39] <petrescu7> HS: very difficult to header compress because you don't have a context.
[17:47:48] <petrescu7> HS: don't typically send stuff to AR
[17:47:54] <petrescu7> VN: mostly agree with Jari
[17:47:59] <petrescu7> VN: not sure this opt is needed
[17:48:19] <petrescu7> VN: if you send two packets, link-layer can carry two
[17:48:36] <petrescu7> VN: go about a lot of funcitonality.
[17:48:40] <petrescu7> HS: handover issue event
[17:48:48] <petrescu7> HS: not including new functionality
[17:49:01] <petrescu7> VN: you would be doing, define a payload, mobile is a loowed to send to AR
[17:49:07] <petrescu7> Marco Liebsch
[17:49:16] <petrescu7> ML: cleaner to keep CT independent of the location of the BU
[17:49:27] <petrescu7> ML: bad compromise independent of LBU
[17:49:38] <petrescu7> HS: no, you can source route, don't process the BU.
[17:49:56] <petrescu7> HS: keep independent could be a... specify a new message, CT
[17:49:58] <petrescu7> HS: I agree
[17:50:05] <petrescu7> GT: ;could do with multiple messages
[17:50:19] <petrescu7> GT: not a micro-optimization, people do netlmm because similar reasons
[17:50:29] <petrescu7> GT: micro-optimizaiton is netlmm
[17:50:57] <petrescu7> VD: move to last agenda item on today's sessions
[17:51:02] <petrescu7> session
[17:51:46] <petrescu7> VD: tomorrow's meeting - we'll start with Alper, then most time Media Independent handovers, and then next steps about fmip move forward
[17:51:50] <petrescu7> Hui Deng presenting
[17:51:56] <petrescu7> slide: Handover ...
[17:52:00] <petrescu7> slide: Problem statement
[17:54:45] --- alfredprasad has left: Replaced by new connection
[17:54:46] --- alfredprasad has joined
[17:55:14] --- alfredprasad has left
[17:55:52] --- ryuji.wakikawa@gmail.com has left
[17:56:17] --- rjaksa has left
[17:56:29] --- ks has left
[17:59:32] --- behcet has left
[18:01:52] --- florent.parent@gmail.com has left
[18:14:03] --- petrescu7 has left
[18:25:07] --- behcet has joined
[18:26:47] --- behcet has left