[11:56:21] --- LOGGING STARTED
[16:21:15] --- sbrim has joined
[16:26:36] --- FDupont has joined
[16:26:56] --- bruce has joined
[16:31:30] <bruce> doesn't look like anyone is using this.
[16:35:04] --- FDupont has left
[16:35:08] --- behcet.sarikaya has joined
[16:40:13] --- trond has joined
[16:40:31] --- TJ has joined
[16:40:33] <TJ> Wow
[16:40:40] <TJ> I am finally online
[16:40:57] <TJ> unfortunately my jabber server provider decided to shut down their servers this week.
[16:40:59] <TJ> ---
[16:41:15] <TJ> Public home agent service available. See slide for contact details. WG status— End of the road for mip6. Last time we’re meeting as mip6. Light at the end of the road – MEXT Jari A. talking about mext. This is the last meeting – but we said that last time as well. Plan was to get everything done for this meeting but not quite. Charter approved by IESG, Jari did a bit more edits but doesn’t need to go to iesg any more. Need to name who the chairs are, interview the candidates and old chairs this week. If you want to suggest yourself or someone else for this position, please talk to Jari this week.
[16:41:26] <TJ> WG status – a couple of new RFCs published. Bootstrapping has made progress – this was a major item of effort over the last couple of years. Extending the mobility header format is a good thing. Concluded to publish as a mip6 working group document. Maybe this will be part of mext. Most of the documents on the milestones are done. In WG last call, completed, or going through IESG. This is a reasonable time for closing and rechartering as mext. MIP6-NEMO-v4 traversal – all issues have been closed, and latest version of the document is ready for last call so we will go to it immediately. Vijay – AAA goals draft is far from complete. Missing basic things like what’s needed between HA and AAA to enable preshared keys. Assumes that EAP is always used for AAA. A: Currently the document has expired. Gerardo was working on it. Please send comments to the list and we can revise the document.
[16:41:44] <TJ> -- Vijay Devarapalli – document almost ready for approval. Jari A- There are no discusses. Do you know of anything needed? A- No. Jari -OK then I’ll approve it immediately.
[16:41:59] <TJ> Vijay is going over the changes in the document from the last IETF.
[16:42:13] --- sbrim has left
[16:42:13] --- sam-xzq has joined
[16:44:33] --- TJ has left
[16:45:06] --- TJ has joined
[16:46:32] <TJ> Comments?
[16:46:35] --- apetrescu has joined
[16:46:37] <TJ> (none)
[16:46:42] <TJ> ---
[16:48:03] <TJ> Heejin Jang - DHCP Options for Home Information Discovery in MIPv6
[16:48:03] --- TJ has left
[16:48:14] --- TJ has joined
[16:52:32] <TJ> Hesham Soliman - I think it's better to reference 4140bis. It's going through last call now.
[16:54:42] --- bnsmith has joined
[16:55:45] --- uli.m has joined
[16:56:19] <TJ> Next steps - update the draft based on commends from DHC, and move forward with IESG
[16:56:31] <TJ> Raj - Is there a rev6 coming to address DHC comments?
[16:56:37] <TJ> A: I think so.
[16:56:47] <TJ> Raj: So it's not ready to be sent to the IESG until that update.
[16:57:05] <TJ> ---
[16:57:19] --- apetrescu has left
[16:57:33] --- apetrescu has joined
[16:58:15] <TJ> Binding Revocation for IPv6 Mobility
[17:02:10] <TJ> Greg Daley: Can you please comment on how this is safer/better than sending binding refresh requests and replying with a lifetime of 0?
[17:02:32] <TJ> Sri G.: For binding refresh, you can not terminate things with a single message.
[17:02:53] <TJ> Greg: I don't see how that's safe with regard to security associations. Is there an SA that allows us to terminate all bindings?
[17:03:45] <TJ> Vijay: When would use a CoA to remove a MN's binding? The HA decides that a particular HoA needs to be removed. When would you use the CoA?
[17:04:13] <TJ> A: In case of MAC supported multiple care of addresses, or multiple mobile node CoAs, it would be safer to specify the CoA.
[17:04:31] <TJ> Vijay: Why would you selectively remove CoAs? This doesn't make sense
[17:05:30] --- ChanWah.Ng has joined
[17:07:31] --- bruce has left
[17:07:59] <TJ> Hesham Soliman: I can't think of an example where you would revoke one BID but leave the others.
[17:08:12] <TJ> A: If someone has two VoIP sessions, and one has a crappy account, he could revoke one
[17:08:26] <TJ> Hesham: I'm assuming this happens due to lack of resources, a breach, or..?
[17:10:17] <TJ> Raj is making some comments as well.. everyone seems to believe that deprecating one CoA is too fine granularity.
[17:11:04] <TJ> Hesham - it doesn't really do the job you want either. Revoking the BID for a session or flow just causes the MN to go to another CoA.
[17:12:49] <TJ> Kuntal - one example for revoking a single binding. If it's a pre-paid session and the quota expires you tear down the session. Same thing with IMS.
[17:13:19] <TJ> Hesham - I'm not saying you have to remove this; I was asking why. As for prepaid, there are many ways of doing this and MIP is not the best way. AAA or SIP-based are probably better.
[17:14:01] <TJ> Sri - providing generic semantics. If the HA doesn't see the need to terminate a specific binding on an interface, ..
[17:14:26] <TJ> Vijay - IMO, we just need a simple binding revocation based on MN identifier or home address. You can add a lot of stuff and then it becomes useless.
[17:15:31] <TJ> Raj - I tend to agree with that as well. Revocation within the context of MIP6 makes sense if you are taking down an HA for maintenance and want to indicate that, etc. When you start talking about using revocation for pre-paid sessions running out, that's getting into a complex scenario. You don't need to do MIP6 binding revocation signaling for these cases.
[17:16:11] <TJ> Alex P- I support the use of binding refresh requests instead of defining a new message. 2nd comment is technical and I'll send it to the mailing list.
[17:16:37] <TJ> Related to this, 3rd comment - I would like to see a 4th or another status where MN tells HA that it doesn't want the HA to revoke the binding.
[17:18:52] <apetrescu> Kuntal Chowdhury
[17:19:03] <apetrescu> KC: HA going down is lewast important use case
[17:19:14] <apetrescu> KC: often used cases are:...
[17:19:23] <apetrescu> KC: we solved these for v4, look now at v6.
[17:19:27] <apetrescu> Ryuji Wakikawa RW
[17:19:43] <apetrescu> RW: monami6 modifications, we used BID to identify the binding, HA treats the binding as a general MIP binding.
[17:19:52] <apetrescu> RW: not much difference monami6 and ...
[17:20:25] <apetrescu> RW: multiple bindings for same MN, each binding as a normal binding. no reason for so much complicaitons.
[17:20:35] <apetrescu> Raj Patil: regularity of revoking of single flow?
[17:20:37] <apetrescu> RW: yes
[17:20:42] <apetrescu> RP: cuts line after TJ
[17:20:52] <apetrescu> fagan from malo(?) (sounds so)
[17:21:07] <behcet.sarikaya> Fan Zhao
[17:21:07] <apetrescu> f: HA needs to temporarily, catch up to, this issue should be covered in this draft.
[17:21:28] <apetrescu> TJ: re-emphasize, kept symbol, semantics of HoA, forward to CoA.
[17:21:49] <apetrescu> TJ: if your app uses something to keep track of accounting, too much granularity. Maybe add another HoA for another flow?
[17:22:07] <apetrescu> TJ: be simple, you have a binding, revoke packets, no longer receive packets, maybe use another address.
[17:22:24] <apetrescu> (TJ, not sure Igot you right on minutes).
[17:22:42] <TJ> yeah, the basic point is just not to complicate things too much here
[17:23:06] <TJ> especially because there are some big security implications and getting to that detailed level of granularity can get quite complicated.
[17:24:00] <TJ> Question from Gopal - should this WG define a binding revocation feature for MIP6?
[17:24:05] <TJ> 8 hands raised
[17:24:33] <TJ> Question asked again.. should we specify bidning revocation feature for MIP6
[17:24:41] <TJ> about 10 hands raised
[17:24:54] <TJ> Who thinks we should not do anything and base spec is suffcient?
[17:24:57] <TJ> No hands raised.
[17:25:09] <TJ> Should WG adopt this document as solution for binding revocation?
[17:25:12] --- jhlim has joined
[17:25:26] <TJ> Hesham - we should really take into account the discussion about using binding refresh to do this.
[17:25:41] <TJ> (previous question not voted on)
[17:25:53] <apetrescu> JA: ought to be when new charter is sent
[17:25:55] <TJ> Jari - After new charter is sent.. this is a separate item
[17:26:23] <TJ> Raj -Given that binding refresh is an alternate way, let's have a discussion of that on the mailing list and decide whether we'll take Hamid's draft as a baseline.
[17:26:35] <apetrescu> Hamid's? Ahmad's.
[17:26:40] <TJ> Vijay - So binding refresh is only sent by CN, not by the HA.
[17:26:42] <TJ> oops.
[17:26:57] <TJ> Greg - BR is sent by someone you have a binding with.
[17:28:00] <TJ> ---
[17:28:14] <TJ> Suresh Krishnan - Mobile IPv6 Firewall Recommendations
[17:28:54] <TJ> It's not easy to recognize MIP6 traffic. So we tried to classify traffic patterns according to which FW you're targetting (HA, MN, CN's FW)
[17:29:31] <TJ> Filtering on certain MH types are not implementable on today's firewalls
[17:31:14] <TJ> Hesham - comment on Traffic to be allowed slide. Last bullet is a Q of someone who wants to be reachable behind the FW.
[17:31:23] <TJ> It's the same sort of problem for any node.
[17:32:05] <TJ> Recommend that IPsec packets should pass through to HA. If you have a better solution, please let us know.
[17:32:41] <TJ> CoTi/HoT messages from CN to MN through the HA usually gets dropped -- install a special rule.
[17:33:05] <TJ> Comment from ___ - traffic is encrypted using IPsec for BU between MN and HA. There is only _____.
[17:33:16] <TJ> With no encryption.
[17:33:29] <TJ> A: Today, IPsec packets are dropped. We need to let IPsec packets through.
[17:34:03] <TJ> Greg D - Yes, they do. I've been blocking IPsec packets for last 6 months.
[17:34:55] <TJ> Hesham - just for context, some firewalls in enterprise market block IPsec. Not public networks. So it's predominantly an enterprise problem.
[17:35:10] <TJ> A: For MIP6 to work, you let IPsec packets pass. We're not making assumptions about whether they are or not.
[17:36:51] <TJ> Frank Shah? - Your solution is hard to configure on a firewall. Makes the firewall unsafe.
[17:37:10] <behcet.sarikaya> Frank Xia
[17:37:44] <TJ> You should let all IPsec traffic go through the firewall? Not safe.
[17:38:01] <TJ> A: If you are running a service, you need to let the packets through. Just like a VPN service.
[17:40:53] <TJ> Alex - A general comment: MIP6 RO has certain security weakness whereby attacker situation on both paths .. so firewall administrators may reply that opening firewall for RO brings certain security risks, and they are correct.
[17:41:11] <TJ> A: Correct. So some parts of this are required for bidirectional tunneling, and some are required for RO.
[17:43:12] <TJ> -BRB-
[17:43:53] <TJ> Jari A - The future-looking stuff sounds dangerous or funny. Why would we need to do that? Why can't we rely on existing mechanisms for negotiation with firewalls instead of developing something for MIP?
[17:44:19] <TJ> A: Hannes was working on existing mechanisms and adapting them to adapt for MIP, but we don't have consensus with the design team to move forward.
[17:44:20] <TJ> -BRB-
[17:46:33] <TJ> IP tunneling optimization in a mobile environment.
[17:46:38] <TJ> ----
[17:46:50] <TJ> Raj: IPR disclosure on this
[17:50:37] --- ldondeti has joined
[17:50:51] --- vidya has joined
[17:52:08] <vidya> can someone tell me which presentation is currently going on?
[17:52:36] <apetrescu> the one of wassim haddad on header compression
[17:52:43] <apetrescu> presenter is suresh krishnan
[17:52:45] <vidya> ok, thnx
[17:52:47] <behcet.sarikaya> http://tools.ietf.org/html?draft=draft-haddad-mip6-tunneling-optimization-01
[17:53:29] <TJ> OK I'm back
[17:54:08] <TJ> Frank Xia: This can save some radio costs, power,.. but the disadvantage is that this is a state-based.. not only as HA, but CN should have some state information. This information can have some disadvantages.
[17:54:30] <TJ> This can be done in a link layer. The link layer can use some compression technology.
[17:55:06] <TJ> A: We already set up state on the HA and CN. So this just piggybacks on the BU so it's not a burden. And since we know the domain of the compression, we can always do better than generic compression techniques.
[17:55:26] <TJ> Greg D: This is good. The killer application is maintaining your 1500 byte MTU. And it is not possible to do that with ROHC.
[17:56:18] --- jhlim has left: Disconnected
[17:56:20] <TJ> You can then compress what is compressed here with ROHC. This does not work on bi-dir tunneling from HA for all desitinations. You might need add'l addresses to manage that. But you can use the next header option to have an unencrypted/uncompressed next header to identify whether you're applying this technique.
[17:56:51] <TJ> Henrik L.: What does bittorrent have to do with this? No, bluetooth. Ahh, it's bidirectional tunneling. The draft should define what BT means.
[17:57:22] <TJ> Kuntal Chowdhury - MIP6 extension for Configuration Options
[17:57:22] <TJ> --
[17:57:29] <TJ> Kuntal Chowdhury - MIP6 extension for Configuration Options
[17:59:23] --- behcet.sarikaya has left
[18:02:54] <TJ> Frank Xia: This L3 option provides a high-level service. Why use the MN - HA interaction? Just add an option in mobility signaling.
[18:03:14] <TJ> What does a service mean? I don't know.
[18:03:34] <TJ> A: As an example, if you want to discover the address of a specific server/host on your home link, how do you do that if you're on a different network?
[18:06:19] <TJ> Raj - to summarize what Frank is saying, you could get this information through another way other than MIP6
[18:06:46] <TJ> Ryuji - on Applicability slide. When MN boots up at the home link, this mechanism doesn't work, since it's on the home link.
[18:07:19] <TJ> Second comment on proxy MIP stuff, it's better to take up address assignment and binding signaling. This is the functionality of DHCP. You can just ue this for proxy MIP.
[18:07:55] <TJ> a: if the mn connects to an access link, it thinks it's at home, but the AR doesn't get any info about the dhcp servier address, etc. So how does access network give information about home network?
[18:08:50] --- sam-xzq has left: Replaced by new connection
[18:08:52] --- sam-xzq has joined
[18:09:03] <TJ> Greg: We have service location protocol, we have dhcp for host related params. We have media independent information services. We have router discovery to discover host route config.. Why do we need to add another configuration protocols? (Rhetorical). I am loathe to add another protocol we have to secure, get through IESG, etc.
[18:09:19] <TJ> Raj: Should we extend MIP6 to do host configuration? We need to discuss this on the mailing list.
[18:09:45] <TJ> Hesham: I agree with Greg. We can tunnel DHCP requests if we want to. We had the same discussion on MIPv4 about 4 or 5 years ago.
[18:10:11] <TJ> A: If you look at the slides, it is already in MIPv4 wg.
[18:10:27] <TJ> Alex: We have two proposals in NEMO for prefix delegation, MIP and DHCP, and we currentlly prefer DHCP.
[18:10:57] <TJ> (He made another comment I didn't get)
[18:10:59] <TJ> Kent - Diff between MIPv4 and MIPv6. In v6, we have a bootstrapping mechanism. After that, why can't we just use DHCP over that MIP tunnel?
[18:11:26] <TJ> A: It can be used. You have to make AAA attributions., and that is more involved. This is one message.
[18:12:11] <TJ> Jari A - just to clarify the MIPv4 document siuation. Clearly we're not doing anything here until we know what happened with the MIPv4 document. The IESG has approved the charter item, but hasn't seen the document yet. (It's in WG last call in MIPv4 and DHC). We need WG last call and IESG.
[18:12:44] <TJ> Henrik - That's quite correct and I agree. There may be a difference in how dhcp works in v4 and v6, and why it may be more feasible to run dhcp over the link in one case than in the other. So we can't assume that they're the same.
[18:13:05] <TJ> A: This is not about dhcp. This is using the dhcp format to ship that information bcak from the home network.
[18:13:19] <TJ> Henrik : Kent's proposal was to just run dhcp over the link, and that might work.
[18:13:28] --- behcet.sarikaya has joined
[18:13:28] <vidya> don't think that works
[18:13:33] <TJ> ---
[18:13:51] <vidya> the first couple of dhcp messages are sent to
[18:13:58] <vidya> and cannot be mapped to the MIP tunnel
[18:14:07] <TJ> Interfacing between IKEv4/IPsec and...
[18:14:08] <vidya> sorry, unfortunately, I'm not in the room :)
[18:14:21] <TJ> Yah the question was doing it for v6.. might be different.
[18:14:29] <TJ> Going through slides.
[18:15:21] --- apetrescu has left: Replaced by new connection
[18:15:30] --- apetrescu has joined
[18:15:37] <TJ> Proposal: Mobile Security Reference Database. Stores the mobility information which is reachable for IKEv2 and OS kernel.
[18:16:03] <TJ> Indexed by MPI; MIPv6 daemon stores mobility parameters in this DB (especially Coa)
[18:18:38] --- behcet.sarikaya has left
[18:19:22] <TJ> Raj: PFK interface is interesting, and it has been discussed in the past with WG interest. Given that we're rechartering into MEXT, this discussion should be followed up there to see if this might be a milestone or a goal there.
[18:19:43] <TJ> Comment: Currently, most company make proprietary PFK solutions, so we might need this standardized.
[18:19:45] <TJ> ---
[18:19:49] <TJ> Gopal - next steps
[18:20:10] <TJ> WG last call needed on 4 items and 6 drafts to be submitted to the IESG.
[18:20:21] --- ChanWah.Ng has left
[18:20:28] <TJ> (see slide)
[18:21:16] <TJ> Thanks from chairs and ADs for participating in the working group.
[18:21:18] <TJ> (Applause)
[18:21:26] <TJ> Over and out.
[18:21:29] --- TJ has left
[18:24:09] --- uli.m has left
[18:28:38] --- apetrescu has left
[18:38:36] --- vidya has left
[18:43:57] --- ldondeti has left
[18:45:47] --- trond has left: Disconnected
[18:55:52] --- sam-xzq has left
[19:17:29] --- trond has joined
[19:17:40] --- trond has left