[09:26:55] --- TJ has joined
[09:27:36] --- momose has joined
[09:32:36] --- rune has joined
[09:33:11] --- gr8k@jabber.org has joined
[09:34:11] --- tskj has joined
[09:34:38] --- jeroen has joined
[09:34:50] --- FDupont has joined
[09:35:03] --- bernt1999 has joined
[09:35:33] --- aibo7 has joined
[09:35:34] --- fp has joined
[09:36:08] <TJ> (Looking for scribes)
[09:36:24] <TJ> ---
[09:36:25] --- aibo7 has left
[09:36:28] <TJ> Working Group Documents
[09:36:42] <TJ> =Basavaraj Patil=
[09:36:53] --- shamus has joined
[09:36:58] <TJ> High-quality MIB has been produced. Thanks to authors. on RFC editors' queue
[09:37:48] <TJ> MIP6 auth protocol , with a couple of discusses ongoing
[09:37:56] <TJ> please take a look at ID tracker for details
[09:38:06] <TJ> chairs have provided response to ADs
[09:38:26] <TJ> separate ID detailing this
[09:39:13] <TJ> Pre-configured keys - simple doc, IESG reviewed with a couple of discusses
[09:39:52] <TJ> Charlie: I didn't see a need for new revision until after blackout period. I'll get a new revision after next week.
[09:40:44] <TJ> IESG evaluating firewalls document (informational) and advance API
[09:41:43] <TJ> "Other WG IDs" slide
[09:42:00] --- mo7sen has joined
[09:42:08] <TJ> Using IPsec b/t Mobile and CN draft - by Francis Dupont
[09:42:21] --- wej has joined
[09:42:25] --- bdeniaud@jabber.org has joined
[09:42:26] --- wej has left: Lost connection
[09:42:44] <TJ> *F Dupont: Please help us to improve routing language
[09:42:55] --- dthaler has joined
[09:43:05] <TJ> AAA-HA interface doc on hold until bootstrap completed
[09:44:03] --- weiliang has joined
[09:44:08] <TJ> Dual Stack MN doc - created a design team to address MN as well as Mobile Routers attaching to a v4 access network. Also expand the scope of the problem to deal w/ carrying v4 traffic. That's on the agenda for today.
[09:44:09] <FDupont> s/routing// (self-demontration :-)
[09:44:31] --- howard218 has joined
[09:44:39] <TJ> TAHI Test Suite - some updates to conformance test. Thanks to Hiroshi for this update.
[09:45:00] <TJ> ---
[09:45:07] <TJ> Bootstrapping in Split Scenarios
[09:45:16] <TJ> =Gerardo Giaretta= who leads the design team
[09:46:18] --- weiliang has left
[09:46:29] <TJ> "Scope of the DT" slide
[09:46:46] <TJ> Design team is not closed, but studying integrated scenario
[09:46:52] <TJ> "Main Design Guideline"
[09:47:40] <TJ> "terminology"
[09:48:30] <TJ> "Split Scenario"
[09:50:26] <TJ> "... (cont'd)
[09:51:09] <TJ> *Hesham Soliman: In Roaming scenario, the HA is assigned by local network?
[09:51:44] <TJ> A: Yes, can be assigned by local network. We defined a solution based on DNS. So we don't have a mechanism to assign the HA by signaling. If the MN uses an HA for the MSP, we'll have a DNS query using the FQDN
[09:51:56] --- howard218 has left: Replaced by new connection
[09:51:58] <TJ> *Hesham: Do I look up my home network FQDN or visited network?
[09:52:03] <TJ> A: Visited.
[09:52:03] --- howard218 has joined
[09:52:40] <TJ> If MSA is home provider but does not have HA and you have a roaming agreement with another provider, the other provider offers the HA
[09:52:49] <TJ> *Hesham: So enterprise is running AAA server?
[09:52:50] <TJ> A: yes
[09:53:07] <TJ> *Hesham: Isn't that highly unusual? What is the purpose of this HA?
[09:53:32] <TJ> A: Two entities can be separated. This is also stated in the problem statement. If the operator can not offer mobility svc, can rely on another operator
[09:53:38] <TJ> *Hesham: It's not just the roaming case.
[09:53:45] <TJ> A: In that case the HA is provided by the MSP
[09:54:41] --- nm has joined
[09:54:54] <TJ> (more discussion on this b/t chairs and Hesham)
[09:55:36] --- weiliang has joined
[09:55:52] --- nm has left: Disconnected
[09:56:01] --- Goldrake has joined
[09:56:14] <TJ> A: MSP is application svc provider. MSA is home agent (?) you can be in home or another network.
[09:56:27] <TJ> Hesham: So can I take this yellow box out and connect it to that yellow box?
[09:56:53] <TJ> Because ASP might not have a AAA server
[09:57:10] --- weiliang has left
[09:57:20] --- nm has joined
[09:58:00] <TJ> *Xing-Li (?): In case MSP and MSA are separated, what kind of authorization?
[09:58:20] <TJ> A: MSA authorizes the service. We can talk about this later in solution. You raised this in the ML
[09:58:43] <TJ> X-L: In (a) scenario, you can do home agent and address assignment, and in (b) you can't.
[09:59:06] <TJ> Can we call it authenticate, not authorize? Because authorize means it has to assign HA and address.
[09:59:31] <TJ> James Kempf: Why do you think HA has to be assigned?
[09:59:43] <TJ> For what technical reason do you need to do it?
[10:00:30] <TJ> A: There must be a roaming agreement between the 2 providers. If the user is authenticated & authorized from MSA, does not mean MSP authorized.
[10:00:41] <TJ> X-L: But MSP could use different HA
[10:01:15] <TJ> Henning: Existing AAA, gives an address from local part and authorization from home network
[10:01:24] <TJ> Hesham: Local network assigns address
[10:01:37] <TJ> Basavaraj: Let's look at solution, and maybe that will answer your questions
[10:02:15] <TJ> Hesham: Just feedback for the scenario. B is redundant; we went through it this morning. I don't think we need a separate solution.
[10:02:21] <TJ> "Solution components" slide
[10:03:58] <TJ> "HA Address Discovery (cont'd)" slide
[10:04:09] --- bonninjm@jabber.org has joined
[10:04:26] <TJ> "IPsec SAs setup" slide
[10:05:19] --- nm has left: Replaced by new connection
[10:05:20] --- nm has joined
[10:05:22] --- nm has left
[10:05:32] <TJ> "Home Address Assignment" slide
[10:06:26] <TJ> "... (cont'd)"
[10:06:26] <TJ> "... (cont'd)"
[10:06:59] <TJ> Francis D.: 2 things not good. Configuration stuff in IKEv2 is separate from DHCP. You should not use it to validate an address. But you should use it to update the DNS.
[10:07:17] <TJ> So I believe you have the wrong assumption about what the services offered by configuration stuff in IKEv2
[10:07:26] <TJ> B.Patil: Why is this bad?
[10:07:55] <TJ> Francis: You should consider that you have a lightweight DHCP service, exactly the same kind of things - no validation, but DNS update.
[10:08:06] <TJ> (we are on "Home address assignment (cont'd)")
[10:08:24] <TJ> Francis: This is a good idea, but it is not in the service of configuration under IKEv2
[10:08:30] <TJ> A: This is why we defined a new attribute.
[10:09:10] <TJ> With that address, the MN runs a CREATE_CHILD_SA exchange. Only the child SA is related to the autoconfigured HomeAddr.
[10:09:32] <TJ> Francis: Same issue about DHCPv6. you can't use it to validate registered addresses. It was rejected by DHCPv6 wg.
[10:10:10] <TJ> Erik Nordmark: So you're proposing to do this to set up temporary privacy. So can you do this at any time during communication? If you want to replace every day/hour... or are you assuming this happens once?
[10:10:42] --- jschoenwae@jabber.org has joined
[10:10:49] <TJ> A: We assume every time the MN goes to bootstrap. If you autoconfig another address, you have another configuration payload exchange (IKE auth exchange) i.e. when you do rekeying under IKEv2. Not once, but depending on lifetime of IKEv2 SA
[10:11:08] <TJ> Alexandru Petrescu: Back to "HA Address Discovery" slide.
[10:11:22] <TJ> So home network prefix is required to be preconfigured on MN. So what's wrong with that?
[10:11:25] <TJ> It's very easy
[10:12:02] <TJ> A: There are scenarios where it's OK, if home net is preconfigured on MN. But first you have a renumbering problem, and also DHAAD does not allow operator to load balance HA assignment to HA on a different subnet.
[10:12:17] <TJ> Alex: What's wrong with using anycast on the same subnet?
[10:12:29] <TJ> A: A more deployable solution is if the MN has nothing preconfigured
[10:12:36] <TJ> But you can still use it.
[10:12:37] <FDupont> s/validate registered/validate\/register/
[10:13:14] --- Goldrake has left
[10:13:44] <TJ> Vijay D: So MN sends DHAAD request and DNS request. If it has home prefix configured ..
[10:14:04] <TJ> Alex: if you do DNS lookup to home.com, your DNS lookup is not secure either
[10:14:34] <TJ> Two parts in DHAAD. Somehow need to secure anycast address.
[10:14:49] <TJ> Hesham: One advantage of this is that you can return AAAA and A record, which can be used for transition cases.
[10:15:07] <TJ> Alex: It requires the home network prefix preconfigured.
[10:15:14] <TJ> Hesham: You can load balance
[10:15:25] <TJ> Alex: can be done with anycast
[10:15:42] <TJ> James K: What protocol do you use to get collection of HAs assigned to anycast address, securely?
[10:15:45] <TJ> Alex: Nothing.
[10:15:51] <TJ> James: exactly
[10:15:59] --- andrewdmcgregor@psg.com has joined
[10:16:04] --- Goldrake has joined
[10:16:10] <TJ> Back to "Home Address Assignment (cont'd)" slide
[10:16:33] <TJ> [I think this is the 2nd such slide, starting with "during ike_auth exchange.."
[10:16:36] <TJ> ]
[10:16:54] <TJ> "Authentication and Authorization with MSA" slide
[10:17:13] --- abaire has joined
[10:17:45] <TJ> Trafiti Kulus?: We've worked on a document to map these requirements to ?
[10:18:37] <TJ> "Home Address registration in the DNS" slide
[10:19:21] --- Goldrake has left
[10:19:27] --- Goldrake has joined
[10:19:44] <TJ> Erik N: I don't think things are that black&white. There's a use case similar to DHCP today, where the DHCP interacts with DNS. But suppose terminal room uses Mobile IP, and I want to register my laptop under Erik.Example.Com -- you shouldn't prevent me from doing that.
[10:20:00] <TJ> A: Agree; in the draft it's optional.
[10:20:13] <TJ> "HA registration in the DNS (cont'd)"
[10:20:22] --- WH has joined
[10:20:51] <TJ> Hui-tan?: In dynamic home agent assignment in the integrated scenario?
[10:21:11] <TJ> A: Yes, we're doing that but it's not covered by this protocol
[10:21:44] <TJ> Through DNS, you can do dynamic home agent discovery.
[10:22:10] <TJ> H-T?: There's a long term advantage for dynamic home agent assignment.
[10:22:54] <TJ> AA:How does this support home agent assignment by the rest of the network? If you use DNS, does the query get resolved by dns server in the home network?
[10:23:08] <TJ> A: If you use FQDN on MSP, ...
[10:23:26] --- bonninjm@jabber.org has left: Logged out
[10:23:27] <TJ> AA: Does home network control whether mobile will assign the home network, or the visited network?
[10:24:06] <TJ> A: In the split scenario, we don't consider home agent assignment in the visited link. Because mobility service and access service are separated by definition.
[10:24:43] <TJ> There is no local assignment because the MSP can not be the ASSP(?)
[10:24:57] <TJ> AA: Notion that mobile can put home.com or visited.com ...
[10:25:11] <TJ> A: Visited.com is not the FQDN of access provider. It's the domainname of the MSP
[10:25:48] <TJ> In case they are the same, it is the integrated scenario which will be in a document in a few months.
[10:26:00] <TJ> Samita Chakrabarti: From the slides, it's not clear if AAA is a requirement for this solution
[10:26:10] <TJ> A: It's not a requirement in the sense that AAA and certificates can be used.
[10:26:17] <TJ> (either one)
[10:26:27] <TJ> AA= Wing Lau
[10:26:55] <TJ> Francis: Q about DNS update. Draft is not clear whether you're referring to AAAA or PTR
[10:27:16] <TJ> A: Direct update is made by the entity that belongs to the FQDN. If the HA is in MSP, or AAA server if...
[10:27:33] <TJ> Francis: It's very easy with dynamic update to replace ...... by security
[10:27:41] <TJ> ---
[10:27:58] <TJ> Updates on MIP6-IKEv2 document
[10:28:04] <TJ> =Vijay Devarapalli=
[10:28:12] <TJ> "Status"
[10:28:24] <TJ> New -02 version with a lot of changes
[10:28:32] <TJ> two issues remaining, want to discuss today
[10:28:38] <TJ> "Changes in version 02"
[10:28:49] --- Goldrake has left
[10:29:02] <TJ> More self-contained, so that RFC3776 is not as heavily referenced
[10:29:44] <TJ> SA and PKI updates
[10:30:21] --- tskj has left
[10:30:49] <TJ> "Major issues - IPsec selector Granularity"
[10:32:40] <TJ> So issue is, what kind of requirements should we have for this spec? Should we use a MUST or leave it to implementations?
[10:33:46] <TJ> Francis: There are two reason we should not have a MUST. There is no reason to have a MUST, because it works without new selectors. Also, to avoid usual problem to get protocols in fragments, many implementations of IPsec only allow selecting on addresses. So you can't assume that protocol selectors are available everywhere.
[10:34:00] <TJ> SHOULD is good because there is no reason not to use new selectors, but MUST is too high.
[10:34:28] <TJ> Put MUST for 3 common selectors, and SHOULD for new selectors
[10:36:01] <TJ> Hesham:Per-Interface became problem once we stopped using home address option. Right?
[10:36:08] <TJ> A: You could have home address option in any message
[10:36:31] <TJ> on the BU and on the HOTI message if you want. So rfc3775 did this (per interface SPDs)
[10:37:03] <TJ> Hesham: It's probably not that big of a deal with ICMP, right? Because not many other non-MIP specific ICMP messages
[10:37:32] <TJ> Jari Arkko: Clarifying Q: Why is this really a problem? Since you're using IKEv2, it requires 2401bis. Doesn't that already have the MUSTs and so forth?
[10:37:48] <TJ> A: 2441bis only has a very few selectors mandated, and most are optional.
[10:38:28] <TJ> Jari A: If this is an issue and you want to support a combination of old and new styles, this doesn't need to be in this document. You can fallback to 3776 alltogether. New doesn't have to contain everything that the old one did. We can make this simpler.
[10:38:38] <TJ> "Major Issues - Packet formats"
[10:39:43] <TJ> There's an option for doing tunneling for everything. Just use one IPsec SA. Advantage is that you have fewer SPD entries, and you can have location privacy. Disadvantage is more packet overhead.
[10:39:44] --- andrewdmcgregor@psg.com has left: Disconnected
[10:40:09] <TJ> Francis D: MPD messages are supposed to be on-link. So if you use __ to get bad TTL, it's not useful, marginal problem.
[10:40:24] <TJ> Alex: I believe they are useful. I implemented them. (The MPD stuff)
[10:40:32] <TJ> Hesham: So what's the issue here?
[10:40:35] <TJ> A: on next slide.
[10:40:49] <TJ> "Major issues - pkt formats" [2nd slide]
[10:41:36] <TJ> So do you want me to write up this tunnel mode in detail? There is a draft-koodli- location privacy draft
[10:42:06] <TJ> Hesham: On previous slide, 3rd bullet.. If it were transport mode with tunnel interface option, we would have always known based on src address
[10:42:17] <TJ> A: We need tunnel mode for HOTI and COTI.
[10:42:26] <TJ> Hesham: But SA would be transport mode for whole tunneled packet
[10:42:31] --- laurent.vreck has joined
[10:42:44] <TJ> A: Packet going to CN. Then inside you have a ... [lost me]
[10:42:59] <TJ> Issue is, move everything to tunnel mode?
[10:43:02] --- jschoenwae@jabber.org has left
[10:43:14] <TJ> Hesham: I thought you were trying to get away from per-interface
[10:43:43] <TJ> B.Patil: Send some text to the list describing this proposal
[10:44:22] --- henrik has joined
[10:45:11] <TJ> Francis: My problem with __ is that it's explicitly forbidden by 3775 for good reasons. You should describe the case where the selector is ___ because.. but it's not a reason to suggest to use it.I agree if you use location privacy, which is the main argument to do that, and you want to forget mobility and use IKE or MOBIKE, then..
[10:45:16] <TJ> ---
[10:45:28] <TJ> v4 Traversal for IPv6 Mobility Protocols
[10:45:33] <TJ> =Vijay Devarapalli=
[10:45:45] <TJ> There was not enough time to write a draft on this, so we have a status update
[10:45:56] <TJ> the design team has discussed a lot of scenarios and defined what we want to address.
[10:46:04] <TJ> "Background"
[10:46:10] <TJ> [skipped]
[10:46:14] <TJ> "Scenario 1"
[10:46:22] <TJ> This is the basic background, where discussion started.
[10:46:22] --- howard218 has left: Disconnected
[10:46:48] <TJ> "Scenario 2"
[10:46:54] --- Tsubasa has joined
[10:47:19] --- henrik has left
[10:47:55] <TJ> "Scenario 3"
[10:48:35] <TJ> When MN is MIPv6 and it also wants to set up IPv4. Most mobile nodes are dual stack. Running MIPv6 and MIPv4 has many disadvantages. So use the same tunnel for IPv4 sessions.
[10:49:07] <TJ> These 3 scenarios will be addressed for sure. Then we have a 4th scenario that was prominent
[10:49:12] <TJ> "The 4th Scenario"
[10:49:26] <TJ> We decided not to address this, then it came up on the ML and was discussed extensively.
[10:49:37] <TJ> The HA is not reachable on IPv4 at all, and is on an IPv6 cloud.
[10:49:56] --- Tsubasa has left
[10:50:00] <TJ> This is like a regular transition scenario, where you have a v4 cloud where the MN is, and the HA is on a v6-only cloud
[10:50:19] <TJ> There's nothing MIP specific or NEMO specific in this cloud; we just use regular transition scenarios.
[10:50:26] <TJ> We plan to address NAT traversal
[10:50:30] <TJ> "NAT Traversal" slide
[10:50:48] <TJ> "Solution Requirements"
[10:51:07] --- rune has left: Replaced by new connection
[10:51:11] <TJ> Francis: I have a basic Q. Do you want full mobility with RO etc, or only re-addressing?
[10:51:13] --- rune has joined
[10:51:21] <TJ> One side is moving, other side is fixed?
[10:51:40] <TJ> It should be easy to add readdressing feature
[10:51:52] <TJ> A: We haven't come to that yet. If MN tunnels through HA, it can do RO
[10:52:37] <TJ> B.Patil: Scope of design team in this effort is restricted to limited set of scenarios which comprise requirements only for most immediate deployments. Just basic MIPv6 connectivity is good enough. Not having RO is something you can live with
[10:52:41] <TJ> Vijay: It can still be done.
[10:52:55] <TJ> Francis: Goal is not just to get solutions, but to select good solutions.
[10:53:48] <TJ> Alex P: I think the next-to-last requirement (use MN HomeAddr) should say "continuous IPv4 sessions". Req to have fixed IPv4 address? So this is done with MIPv4 right?
[10:54:00] <TJ> A: Read hesham's draft which talks about using MIPv4 and MIPv6 at the same time.
[10:54:20] --- abaire has left: Replaced by new connection
[10:54:59] --- abaire has joined
[10:54:59] <TJ> Joel Singh?: Have you looked at the possibility of using TEREDO?
[10:55:08] --- bdeniaud@jabber.org has left: Logged out
[10:55:12] <TJ> A: Yes, document talks about this, take a look at it.
[10:55:13] <TJ> ---
[10:55:20] <TJ> =Hesham Soliman=
[10:55:32] <TJ> Mobility in a Dual Stack Internet
[10:55:47] <TJ> Vijay gave me a lot of credit; it's actually co-authored.
[10:56:01] <TJ> This problem statement was presented in Seoul.. took us a while to republish as a WG item
[10:56:11] <TJ> "The problem" slide
[10:56:48] <TJ> Use of MIPv4 and MIPv6 simultaneously adds signaling and doesn't allow MNs to be reachable on both IPv6 and IPv4 HoAs all the time.
[10:57:53] <TJ> Alex: I understand the problem. You have a mobile, you're on a v6 network, why allow v4 traffic running over it?
[10:58:06] <TJ> B.Patil: If you want to run a v4 network, it's running over a v6 network
[10:58:31] <TJ> Alex: Isn't this going over what was initially discussed in MIP6 and NEMO? Isn't it more than the initial discussion?
[10:58:57] --- dthaler has left
[10:59:01] <TJ> A: This was discussed before any of the NEMO/MIP. But it is a valid scenario.
[10:59:11] <TJ> "Problem" slide
[10:59:13] --- laurent.vreck has left: Disconnected
[10:59:27] <TJ> "Solution Strategy" slide
[10:59:56] <TJ> Dave Thaler: Is the problem lack of efficiency or lack of connectivity?
[11:00:07] <TJ> You should be able to reach the HA using a transition fix
[11:01:09] --- bdeniaud@jabber.org has joined
[11:01:12] <TJ> A: Both. Efficiency if you are dual-stacked. If you are not, it becomes a connectivity issue. You could solve it using transition scenarios. But with mobility, you have to change tunnel endpoints
[11:01:21] <TJ> D Thaler: Problem is optimization, not connectivity
[11:01:56] <TJ> G. Tsitris: Problem is from network operator's perspective. If you want to provide mobility services, ..
[11:02:05] <TJ> D Thaler: Which type of network operator?
[11:02:53] <TJ> George T: have IPv4 network today, want to deploy IPv6 ASAP. Today, you need to do MIPv4, MIPv6, FHO optimizations,.. doesn't work in practice. Yes, this is an optimization, but it provides one mobility solution.
[11:02:54] --- abaire has left: Déconnecté
[11:02:58] <TJ> (more discussion of this)
[11:03:20] --- abaire has joined
[11:03:25] <TJ> Greg Daley: Do we have any well-described IPv4 over IPv6 tunneling mechanisms?
[11:03:33] <TJ> Alex: RFC 2473
[11:03:37] <TJ> (GRE)
[11:03:57] <TJ> Greg D: I believe that there is GRE (grrr)
[11:04:09] <TJ> "Solution Strategy" slide
[11:04:26] --- syi has joined
[11:05:04] <TJ> "MIPv6 Solution Framework" slide
[11:05:26] <TJ> Moving forward, it would be good to have 2 components of this: NAT detection and traversal,
[11:05:38] <TJ> -Having keepalives is not efficient for cellular hosts
[11:06:32] <TJ> "Next steps for draft"
[11:07:11] <TJ> Hannes T: NAT detection and traversal.. document in IPv6 working group describes
[11:07:36] --- dthaler has joined
[11:07:40] <TJ> Alex: Binding IPv4 address to IPv6 address and vice-versa.. isn't this what 6to4 does?
[11:08:07] <TJ> A: Yes, without anycast solution which is questionable by a lot of people, you only have 1-way connectivity
[11:08:15] <TJ> George: Does it even work when you are working?
[11:08:30] <TJ> B.Patil: further discussion on ML
[11:08:34] --- dthaler has left: Disconnected
[11:08:39] <TJ> 7 minute break
[11:09:11] --- gr8k@jabber.org has left: Logged out
[11:09:34] --- bdeniaud@jabber.org has left: Logged out
[11:10:04] --- weiliang has joined
[11:14:17] --- dthaler has joined
[11:14:18] --- dthaler has left: Disconnected
[11:14:34] --- dthaler has joined
[11:14:38] --- dthaler has left
[11:14:47] --- weiliang has left
[11:19:29] --- syi has left
[11:20:35] --- rune has left
[11:20:42] --- rune has joined
[11:21:40] <TJ> Still 1 agenda item left from session 1
[11:21:43] <TJ> ---
[11:21:52] <TJ> IP Addres Location Privacy and IP Mobility
[11:22:01] <TJ> =Rajeev Koodli= (chair of MOBOPTS WG)
[11:22:15] <TJ> "Background"
[11:22:19] --- bernt1999 has left
[11:22:46] --- aibo7 has joined
[11:23:23] <TJ> Revised the draft with input from research group
[11:23:30] <TJ> "Background (MIP6)"
[11:23:45] <TJ> IP addres location privacy -- 2 kinds defined: home address, care-of address.
[11:24:08] <TJ> location privacy - much more narrowly scoped than privacy in general.
[11:24:57] <TJ> HoA visible in all packets the mobile uses, in visited or home link.
[11:25:14] <TJ> So that indicates to someone on that link that a topologically inconsistent address is being used -- an indication of roaming
[11:25:27] <TJ> CoA is visible in all packets sent from the visited network
[11:25:44] --- faw has joined
[11:25:54] <TJ> Francis D: Not true - not visible if you cipher everything by ESP. You can see home address as a result of binding update
[11:26:03] <TJ> A: Agreed. That's how you can protect it.
[11:26:15] <TJ> If you don't use it, the HoA is visible. There are means of masking it.
[11:26:19] <TJ> "The Roaming Problem" slide
[11:26:44] --- jeroen has left
[11:27:00] <TJ> There is device roaming and user roaming. CoA reveals device and possibly user roaming.
[11:27:15] <TJ> to correspondent.
[11:27:36] --- WH has left: Disconnected
[11:27:55] <TJ> So how can we give an option to not reveal CoA to unknown CNs
[11:28:00] --- abaire has left: Disconnected
[11:29:04] <TJ> Profiling of other fields - does it directly compromise location or reveal that someone has roamed? If you see a BU, you know someone is roaming. But whether it compromises a user's identity is not clear
[11:29:38] <TJ> Once location privacy is compromised, it could lead to more targeted profiling.
[11:30:23] <TJ> "Issues to address" slide
[11:31:30] <TJ> "ML input"
[11:31:36] <TJ> Quote from Wassim H.
[11:33:01] <TJ> You can trace a sequence number, but if you can't figure out the HoA you are still OK.. this is a profiling issue.
[11:33:32] <TJ> B.Patil: Next steps - we spun this work off to IRTF, and now they have produced the problem statement of loc. privacy as related to mobility.
[11:34:04] <TJ> Plan to discuss this, make it informational, and publish. We should discuss relevance of privacy on the ML. How important is it to enabling deployments? Does this need to be solved at this time?
[11:34:31] <TJ> Erik Nordmark: Shameless plug for ALIEN BOF tomorrow, for people interested in this area.
[11:35:15] <TJ> ---
[11:35:25] <TJ> Home Agent Reliability and Load Balancing
[11:35:56] <TJ> B.Patil: Charter says we will address topic of HA reliability. Relevance of this is not immediately clear, but several drafts address reliability.
[11:36:41] <TJ> Presentation: HA initiated bootstrap for MIP6
[11:37:08] <TJ> =Qin Li=
[11:37:12] <TJ> "Motivation"
[11:38:41] <TJ> "Related Solution"
[11:39:30] <TJ> "Protocol Operation"
[11:40:24] <TJ> "Scenario of our solution could be used 1) reliability"
[11:40:26] --- abaire has joined
[11:41:00] <TJ> "... 2) Home Agent assignment"
[11:42:15] <TJ> James K: I take it that you're planning on doing this w/o a HA address on the MN? Or does the MN already know the HA address?
[11:42:47] <TJ> A: Maybe bootstrap is misleading. HA-initiated IKE procedure is better. HA assignment is decided before this procedure by load balancing, AAA decision, .
[11:43:19] --- gr8k@jabber.org has joined
[11:43:20] <TJ> James: I read through your draft, and the problem I saw was if MN doesn't know address beforehand, it has to initiate IKE with any address that's coming in. The SPD should specifically say the address or identify the node.
[11:44:02] <TJ> If you want to somehow statically configure the HA address, you're not doing dynamic bootstrapping. Why doesn't MN just initiate the IKE transaction. I don't see how you can do this unless MN is prepared to initiate IKE with any unknown source.
[11:44:23] <TJ> A: Mobility Header type would be the SPD selector. Every MIPv6 signal (BU, BAck) should be protected by IPsec.
[11:44:58] <TJ> James: Also, if the HA is doing a lot of these, it's going to be a big load on the HA. I don't know if that's an issue but it might be. I'll post to the list.
[11:45:55] <TJ> Gerardo G.: I think this is not related to the bootstrapping problem, but reliability problem. It can also be solved with the HA switching draft. So I don't see a need for HA initiated bootstrapping. Also, I read the draft, and during the IKEv2 exchange, the HA sends a configuration payload with an unsolicited configuration reply message.
[11:46:00] <TJ> A: I think we can do it in other ways.
[11:46:26] --- nm has joined
[11:46:57] <TJ> Vidya Narayanan: I had a similar comment to James - it concerns me to allow any source address to request an IKEv2 session with a MN. If the HAs can detect failures quicker than the MN, there's a tradeoff there. But the draft should address security concerns. Perhaps there's another way to solve this by quicker notification of the MN that the exchange has failed.
[11:47:08] <TJ> A: Thank you for 1st suggestion, and I'm not quite sure about the 2nd suggestion.
[11:48:02] <TJ> Hui-deng: That problem is found from reliability, but solution is HA bootstrap.
[11:48:08] <TJ> ---
[11:48:29] <TJ> Reliability and Load Balance among multiple Home Agents
[11:48:35] <TJ> =Hui Deng=
[11:48:44] <TJ> "Problem"
[11:48:48] <TJ> "Motivation - 1"
[11:49:28] <TJ> "Deployment Scenario"
[11:49:31] <TJ> "New VRRP..."
[11:49:36] <TJ> "Partial Recovery"
[11:50:19] <TJ> "Full Recovery"
[11:50:33] <TJ> "Work Item?"
[11:50:48] <TJ> B.patil: We'll take up a discussion on this at the end
[11:50:54] <TJ> ---
[11:51:15] <TJ> HA Reliability using the HAHA Protocol
[11:51:21] <TJ> =Vijay Devarapalli=
[11:51:25] <TJ> (Not going into details)
[11:51:34] <TJ> "HAHA protocol"
[11:52:02] --- bonninjm@jabber.org has joined
[11:52:23] <TJ> This was designed based on Conexion by Boeing's problem, where the HAs are on different continents.
[11:52:28] <TJ> But it can be used for HA reliability too.
[11:52:43] <TJ> Draft has been around for a while. Rewritten completely, splitting into 3 drafts.
[11:52:54] <TJ> ---
[11:53:30] <TJ> MN-HA Signaling for HA Unavailability
[11:53:34] <TJ> =James Kempf=
[11:53:39] <TJ> "Why?"
[11:54:01] <TJ> "Current drafts"
[11:54:44] <TJ> "New Messages"
[11:55:31] <TJ> "Example"
[11:55:41] <TJ> "Future"
[11:56:04] <TJ> I personally believe this is important for bootstrapping and reliability. Operators have to be able to tell MNs if they're doing maintenance and such.
[11:56:15] <TJ> Hesham: This draft is not for the case where the HA crashes, right?
[11:56:29] <TJ> A: Well if it crashes w/o warning, there's nothing to do. This is for controlled shutdown.
[11:56:40] <TJ> Hesham: So this couldn't be sent from another IP address?
[11:56:46] <TJ> A: Well it has to be protected by SA
[11:57:03] <TJ> Hesham: But backup router, with copy of state? Because otherwise it's very limited, and MIP has a problem
[11:57:28] <TJ> Vijay: It can be used along with HA reliability mechanism. If another HA can detect, then it would need to setup SA
[11:58:10] <TJ> Erik N: 2 different things here - multiple HAs available, and the ability to switch. Those might happen in different points in time. If it dies and the MN knows there's another one,.. But some of this starts looking a lot like multihoming
[11:58:22] <TJ> A: Assumption is that MN has done bootstrapping and has a bunch of addresses already
[11:59:37] <TJ> Alex P: I'm generally positive for a new mechanism for HA to send a message to MN. on "Example" slide, not only HA addresses. What happens with RFC3041, renumbering? HA need to update MN at its own will, not waiting to be interrogated
[11:59:49] <TJ> A: we could put other things in there. We couldn't think of what else would be useful.
[12:00:20] <TJ> Alex: 2nd point- HA-HA, the window after switching HA. A session on a MN at the same home address would continue.
[12:00:47] <TJ> A: I don't know about HA-HA. Once you are told that your HA is going down, you have to rebootstrap, get a new address, and go from scratch. There are some optimizations possible, i.e. if it's on the same subnet.
[12:00:55] <TJ> Starting simple seems like the right way to go.
[12:01:52] <TJ> Francis: comment about VRRP. To re-distribute ESP processing is very hard. You can have multiple parallel IPsec SAs.
[12:02:04] <TJ> Chairs cutting the discussion there.
[12:02:40] <TJ> Gopal: Several ways to achieve reliability. You can use 2 HAs and let the vendor handle redundancy. You don't necessarily need a protocol between 2 HAs to achieve reliability/redundancy
[12:03:30] <TJ> 2 HAs in geographically different locations. When one goes down, the other has to pick up the session. There seems to be an undertone of a 4th scenario, when HA goes down/ is going down, MN can recover and get another HoA.
[12:04:13] <TJ> Want to get a sense of what the WG thinks about how important this WG standardizing a protocol b/t 2 HAs for an immediately deployable situation. Should we be working on it in the next 6 months?
[12:04:18] <TJ> Alex: on the same subnet, yes.
[12:04:30] <TJ> B.Patil: you can do that without a protocol solution.
[12:05:18] <TJ> Kent Leung: I would favor postponing this. A lot of vendors have their own reliability infra for inter-process communication or VRRP based. Geographically land-based is supported as well. The real issue is interoperability between different vendors.
[12:05:52] <TJ> If you have mult. vendors providing redundancy for HA service, this is needed. So key question is how operators deploy their networks. Service is typically one vendor per region.
[12:06:12] <TJ> So for now, there are probably enough other things to work on.
[12:06:49] <TJ> Vijay D: The # of protocol drafts out there should give you an indication of the amount of interest for this. You can always do a proprietary solution.
[12:06:59] <TJ> Gopal: I know the # of drafts, I'm just trying to find a reason for working on it.
[12:07:15] <TJ> Vijay: To have a protocol for HA reliability before the vendors all do their own protocol
[12:07:34] <TJ> B.Patil: Is HA reliability a feature that you think is absolutely essential to enable MIPv6 deployment?
[12:07:40] <TJ> Vijay: Yes, that is obvious
[12:08:05] <TJ> Ryuji: If you look at router redundancy, IETF already has VRRP. If everybody just buys a Cisco HA, that's fine. But that's not the case.
[12:08:37] <TJ> Gopal: You have an interoperable protocol between 2 devices that are the same. Age-old industry problem. Not every protocol specifies how to do redundancy, i.e. VPN concentrators
[12:09:17] <TJ> Vijay: If you postpone this, it's probably worthless because people will implement their own mechanism.
[12:09:24] <TJ> Gopal: Do you need interop with reliability?
[12:09:38] <TJ> Vijay: If I decide to put 2 different vendors on the same subnet, I'm screwed
[12:10:35] <TJ> Hesham: I've been working w/ MIP for deployments. And of course we don't want to see a HA fail that isn't detected. Why does it need to be interoperable? Some vendors have 2 routers back-back, some don't. You're not going to need interoperability anyway. Looks like there should be some operator input to this.
[12:11:35] <TJ> James Kempf: I can't really say at this point. I have to think about it a little bit. I don't see a burning need for interoperable HA protocol. Some vendors might want to transfer binary context b/t HAs and that can't be interoperable. I think interop protocols are really good, but I don't have an opinion here.
[12:12:18] <TJ> Gerardo: I think an interoperable solution can be useful but I'm not sure if it's needed for us in the short term.
[12:12:51] <TJ> Erik N: If it's perceived to be necessary, is it required that it be completely transparent to Mh? If it's short term, it should be transparent to Mobile Hosts.
[12:13:09] <TJ> Rajeev: for me, it's not clear. There are different ways of providing this functionality.
[12:13:39] <TJ> Vidya N: When you refer to reliability, are you referring to state sharing b/t HAs or when HA notifies MN what it needs to do (setting up SAs)
[12:14:23] <TJ> Gopal: minimize interruption.
[12:15:34] <TJ> Hesham: If you have multi-vendor, each vendor can come with their own reliability mechanism
[12:15:49] <TJ> But we really need to be able to send a message that says "I crashed"
[12:16:22] <TJ> Kent Leung: A lot of vendors have their own features. So you need to have comparable features between vendors when you do failover
[12:16:47] --- abaire has left: Disconnected
[12:16:47] <TJ> Gopal: How many of you think that in the short term, we should work on an interoperable protocol that addresses reliability?
[12:17:06] <TJ> James: You need to distinguish b/t inter-HA protocol and HA to MN protocol
[12:17:12] <TJ> Gopal: I am referring to HA-HA protocol
[12:17:20] <TJ> Erik: Multiple levels of longer term.
[12:17:46] <TJ> You could have one where everybody does SHIM6, or have something where multiple HAs interact on the same link
[12:18:30] <TJ> Gopal: In the short term, how many think we need an interoperable protocol b/t 2 HAs to increase reliability?
[12:18:45] <TJ> About 10 hands
[12:19:08] <TJ> Gopal:How many think we're better off doing other things?
[12:19:15] <TJ> About 6 1/2 hands.
[12:19:36] <TJ> B.Patil: We should get more operator input on the ML
[12:19:48] <TJ> James: Are we going to ask /decide about HA-MN reliability?
[12:20:36] <TJ> ---
[12:20:47] <TJ> MIPv6 Route Optimization Enhancements
[12:20:51] <TJ> =Christian Vogt=
[12:20:55] <TJ> "Reviewers"
[12:21:02] <TJ> "Discussion and Clarifications"
[12:21:50] <TJ> "Additions to the Draft"
[12:22:16] <TJ> "Perspectives and Future Work"
[12:23:07] <TJ> "Experimentation Results for Early Binding Updates and Credit-Based Authorization"
[12:23:16] <TJ> "Testbed Topology"
[12:23:40] <TJ> "Evaluated Mobility Protocols"
[12:24:32] <TJ> "Voip-like UDP.."
[12:25:47] <TJ> "Same with 120 ms RTT"
[12:26:17] <TJ> "TCP: Std vs. EBU+CBA"
[12:28:11] <TJ> Gerardo: on 120-ms RTT.. does handover delay include movement detection delay?
[12:28:45] <TJ> A: Yes, we are sending high frequency RtrAdv. It does not include LL handover delay. It also does not consider delay that normal IPv6 autoconf would require. We use optimistic DAD.
[12:28:52] <TJ> ---
[12:29:02] <TJ> Securing Home Agent List in MIP6
[12:29:08] <TJ> =Sachin Dutta=
[12:29:23] <TJ> B.Patil: on list, it has been discussed whether there is really a problem. Let's not spend too much time on this.
[12:29:28] <TJ> "Problem Statement"
[12:29:49] <TJ> "Issue"
[12:30:54] <TJ> "problem.."
[12:30:57] <TJ> "solution 1"
[12:31:09] --- nm has left
[12:32:05] <TJ> "solution 2.. solution 3.. solution 4"
[12:32:58] <TJ> Jari Arkko: "Solution 2-SEND". What is the 2nd issue that will not be resolved?
[12:33:14] <TJ> A: The frequency is high. So if multiple HAs send RA frequency,..
[12:33:45] <TJ> Jari: I'm not sure I agree. Frequent RAs are for the host. if the home link has hosts, it makes sense to have those RAs. If the HAs are on the same link, there's no need for high frequency.
[12:34:12] <TJ> Erik N: It might even be possible, even if you do have hosts and want 30ms beacons, have those RAs not include information updates, HA list, SEND stuff.
[12:34:50] <TJ> ---
[12:35:28] <TJ> = Francis Dupont =
[12:35:34] <TJ> Rcookie draft.
[12:35:45] <TJ> *RRcookie
[12:36:00] <TJ> The idea is to use a state cookie as in SCTP and IKE
[12:36:11] <TJ> SCTP explanations are very good.
[12:36:56] <TJ> No state creation on CN, so no DoS problems with many BUs.
[12:37:49] <TJ> there are IANA considerations, want to publish as experimental.
[12:38:40] <TJ> In MIPSHOP, Jari found a nice way to solve it...__
[12:38:45] <TJ> ---
[12:38:50] <TJ> Mobility Socket API
[12:39:08] <TJ> Gopal: Not sure what to do on this draft, but please take a look at this draft and we'll discuss it on the ML
[12:39:57] <TJ> B.Patil: Specifies an API that allows applications to acces info related to mobility. But we don't usually do APIs in the IETF, so should this go in the WG or as a separate draft?
[12:40:25] <TJ> Alex: I don't see any other way of doing it other than BSD sockets. And if it is bsd sockets, there's a document for that.
[12:40:26] --- aibo7 has left
[12:40:41] <TJ> ---
[12:40:44] <TJ> Next steps
[12:40:48] <TJ> =Gopal Dommetty=
[12:42:32] <TJ> Vijay: Regarding auth option draft, there are some security ADs discuss on the draft, but not on the mailing list. I don't know what the security concerns are.
[12:43:02] <TJ> the real technical expertise is hear. We're in the blind about what's happening because the WG is done with it.
[12:44:40] <TJ> Margaret Wasserman: I can tell you what the status is, but not how it's going to get resolved. Both Security ADs have discusses on the document. We had a brief meeting yesterday, and there/'s not definite resolution on the table. We might be able to make some traction with an applicability statement that it's specific to 3GPP2 networks, or that it should only be used on nets with some properties. But that won't necessarily resolve the discusses. There's a lot of bad feeling because one of the ADs was on the security directorate when it was asked to review this. Nothing was communicated back to them to clear this up.
[12:45:16] <TJ> Vijay: WG last call for IKEv6 and MIPv6 draft. We can do it before next IETF. We already have 4 reviews.
[12:45:21] <TJ> -end of meeting-
[12:45:24] --- TJ has left
[12:45:43] --- momose has left
[12:45:46] --- faw has left
[12:45:50] --- shamus has left
[12:45:52] --- rune has left
[12:46:25] --- bonninjm@jabber.org has left: Logged out
[12:46:39] --- gr8k@jabber.org has left: Logged out
[13:03:31] --- FDupont has left: Disconnected
[13:04:05] --- fp has left: Disconnected
[13:07:57] --- mo7sen has left: Disconnected
[17:57:32] --- yushun has joined
[20:04:29] --- yushun has left