[01:04:46] --- rune has become available
[01:04:52] --- rune has left
[01:05:37] --- rune has become available
[01:05:44] --- rune has left
[01:49:31] --- rune has become available
[01:49:35] --- rune has left
[01:53:06] --- rune has become available
[02:00:28] --- aibo7 has become available
[02:04:56] --- aibo7 has left
[02:09:58] --- FDupont has become available
[02:17:03] --- FDupont has left
[02:20:47] --- kk has become available
[02:23:18] --- FDupont has become available
[02:23:22] --- FDupont has left
[02:25:53] --- kk has left
[02:26:36] --- geir_egeland has become available
[02:26:49] --- geir_egeland has left
[02:31:14] --- jschoenwae@jabber.org has become available
[02:35:44] --- jschoenwae@jabber.org has left
[02:42:28] --- rune has left
[02:44:04] --- sureshk has become available
[03:14:23] --- kk has become available
[03:26:02] --- rune has become available
[03:29:25] --- kk has left: Replaced by new connection
[03:29:29] --- kk has become available
[03:30:41] --- FDupont has become available
[03:32:38] --- faw has become available
[03:40:13] <FDupont> Can someone with power play the scribe role?
[03:42:13] --- TJ has become available
[03:42:35] <TJ> 2 Hour timeslot. FMIPv6 received RFC # - first RFC for Wg. Security issues for HMIPv6 - H. Soliman - Current scheme relies on local HA (MAP); relies on IPsec SA - MN can pick any address, and is not reachable there. - Issues raised: use of certificates on the host is difficult.
[03:42:58] <TJ> - (guessed as to why this is a problem - no standard way to manage certs)
[03:43:14] <TJ> Alex petrescu: if certs difficult on host, could they be used on AR?
[03:43:30] <TJ> A: a lot less routers than there are hosts
[03:44:09] <TJ> James Kempf: Security protocols with host-based certs have not been successful. Cable networks use them. But in general, it is a problem. TLS, w/ server-side certs, are more widely used and deployable.
[03:44:33] <TJ> Another reason, as discussed in netlmm - if you get a virus or spyware on host, virus could distribute address of MAP
[03:44:49] <TJ> Hesham: Any other reasons why this is an issue? Want to stick to this.
[03:44:57] <TJ> James- I'll hold on to comment for later.
[03:45:40] <TJ> - Hesham going through slide "Different trust models for deployment"
[03:46:03] <TJ> - Current solution in HMIPv6 draft addresses both models. So maybe we need other ways, on top of existing model
[03:46:27] <TJ> - Authentication-only case.
[03:46:57] <TJ> - Whoever has access to network in this case gets access. Certificates are just a means of setting up dynamic keying
[03:47:58] <TJ> - A/A case. When mobility assumed, authentication only is sufficient. But this is a case where mobility is an add-on service.
[03:48:10] <TJ> - Certificate is used to authorize user as well.
[03:49:21] <TJ> - Authentication & authorization (B) - IKEv2 and IPsec. EAP method in IKEv2 uses AAA credentials of MN, and ipsec SA bootstrapped from there
[03:51:00] <TJ> - working on a new draft to use CGAs for authentication-only model
[03:51:34] <TJ> - Last slide - way forward
[03:52:11] <TJ> - Suggestion to keep current mech in HMIPv6 as default, then once we agree where problem is, we can add alternatives such as CGAs
[03:53:04] <TJ> - Wants to move current solution to PS after cleanup
[03:53:32] <TJ> Greg Daley - on last slide. For A&A mechanisms, why not IKEv1 w/ preshared keys in aggressive mode? Subject to some attacks if keys are weak
[03:53:46] <TJ> A: Definitely deployable. Thought there was enough controversy as is
[03:54:04] <TJ> Francis Dupont: on last slide, replace authentication only by ownership (?)
[03:54:25] <TJ> AAA function in IKE is well-known by IPsec. Don't reinvent the wheel. Refer to PKI for IPsec.
[03:54:58] <TJ> A: I'm just saying this is one way of doing it
[03:55:31] <TJ> AA: What do you mean by keep the current mechanism? Certificates? EAP support is not there in the draft.
[03:55:45] <TJ> A: When this draft came out, there was no IKEv2.
[03:55:47] <FDupont> pki4ipsec
[03:56:36] <TJ> James Kempf: 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
[03:56:49] <TJ> Vijay Devarapalli: This is similar to assigning HA on visited link. Security for that is hard
[03:57:05] <TJ> Not possible to have cert for each MN, for each MAP. So I agree w/ James.
[03:57:17] <TJ> A: There is aggregate trust b/t domains. So it's not for each MAP.
[03:57:27] <TJ> Vijay: You can't authorize MAP in visited domain.
[03:57:43] <TJ> A: This is chain of trust -- CA in visited domain trusts CA in home domain
[03:57:53] <TJ> Vijay: We don't have something like this today
[03:57:56] <TJ> A: yes we do, PKI
[03:58:29] <TJ> Hesham: Point James made - if we have dynamic home agent mechanism we don't need this. But we don't have one today.
[03:58:47] <TJ> Vijay: When you do local HA assignment in visited link, you have to set up security, so that solution would be applicable here
[03:59:01] <TJ> James: We've discussed this, and it's not entirely as easy as you've made it.
[03:59:37] <TJ> Shinta Sugimoto: You mentioned a scheme for MAP to verify uniqueness of rcoa of MN. in draft, it mentios that that will be used, but when MN is away,...
[03:59:51] <TJ> Hesham: it's internal -- you check BCache, and if one already exists, you don't use it.
[03:59:57] <TJ> It's just a way of checking for duplicates.
[04:00:11] <TJ> Sugimoto: It should be done in initial BReg.
[04:01:12] <TJ> 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)
[04:01:26] <TJ> stick to that, and don't worry about adding new security mechanisms
[04:01:43] <TJ> Next presentation - Christian Vogt,
[04:01:55] <TJ> Towards Efficient Route Optimization
[04:02:06] <TJ> CGA and credit-based
[04:03:14] <TJ> Goals for improving RO: Make authentication faster, but still infra-less. avoid delays of CoA tests by doing them concurrently. Incorporate ML discussion and reviews.
[04:03:46] <TJ> Main ingredients: CGA, credit-based authorization for concurrent coa tests
[04:04:40] <TJ> During initial handshake, normal return routability, and info is bootstrapped for subsequent optimization
[04:05:41] <TJ> (still on initial exchange slide)
[04:07:35] <TJ> Peers have established BCE with 24 hr lifetime, extended sequence #, semi-permanent security assn (all valid for 24 hours)
[04:08:45] <TJ> on "How Subsequent Exchanges Look Like" slide
[04:10:55] <TJ> Alexandru petrescu: There were only 2 messages before, and now there are 4. Why would this be quicker?
[04:11:00] <TJ> A: You have 6
[04:11:20] <TJ> Alex: Well during initial exchange yes. But now in subsequent excahges you have 4
[04:11:48] <TJ> 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.
[04:12:09] <TJ> on slide "Where Credit-Based Auth comes into play"
[04:13:13] <TJ> (describing how credit-based authorization works). Can use address up to a certain data volume, before it is verified
[04:13:17] <TJ> Last slide.
[04:14:02] <TJ> Have re-written credit-based auth to make it more clear.
[04:15:09] <TJ> Vijay D: I don't understand why you need extended sequence #s
[04:15:40] <TJ> 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.
[04:15:49] <TJ> Charlie: That's a new coa every 2 seconds
[04:16:02] <TJ> Might suggest a different value.
[04:17:03] <TJ> 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.
[04:17:25] <TJ> A: When you are still w/in 24 hours, CN still has shared key, so you will do an optimized "handover" (re-registration)
[04:18:08] <TJ> J Kempf: 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?
[04:18:28] <TJ> A: in that case, CN would say it can do auth, but ...
[04:19:01] <TJ> 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.
[04:19:18] <TJ> BB: Bidding down can happen, but it's not really an attack.
[04:19:50] <TJ> Hesham: On a high level, I like the idea. But how do you earn credit in real implementation?
[04:19:54] <TJ> A: By sending data to CN.
[04:19:59] <TJ> Hesham: No matter the content?
[04:20:18] <TJ> A: IP traffic. You want to prevent CN to send more data to unverified address, to avoid amplification attacks.
[04:20:31] <TJ> Hesham: Earning credit doesn't mean you are "[?]"
[04:21:43] <TJ> Francis: Size of ? is 550. So you need a way to have larger options. So we have to fix this problem somewhere.
[04:21:50] <TJ> A: So option space is insufficient?
[04:21:58] <TJ> Gabriel: Please send that to the ML.
[04:22:09] <TJ> Next presentation: Vidya Narayanan
[04:22:15] <TJ> Handover Keys using AAA
[04:23:23] <TJ> Same problem statement as James's presentation with SEND, but we're trying to solve it using AAA
[04:23:41] <TJ> Concept is handover master key shared between MN and AAA server
[04:25:23] <TJ> (overview description of protocol)
[04:26:00] --- gr8k@jabber.org has become available
[04:27:08] --- bonninjm@jabber.org has become available
[04:27:26] <TJ> Rajeev: I see it's an optimization and you can do it, but why?
[04:27:33] <TJ> A: Useful when MN is rapidly between subnets
[04:27:34] --- rbless has become available
[04:27:38] --- sureshk has left: Logged out
[04:27:50] <TJ> Rajeev: What timespace are we looking at? 1-3 seconds? We should understand that part better.
[04:28:17] <TJ> 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.
[04:28:42] <TJ> Something like this will help when you are changing subnets frequently.
[04:28:52] <TJ> We couldn't come up with a reason why we shouldn't do this.
[04:29:08] <TJ> Rajeev: It's good to have, but maybe better to have the base thing well specified
[04:29:38] <TJ> Rajeev: You have AAA MN nonce. Have you thought about MN generating nonce so it can challenge network?
[04:29:57] <TJ> 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.
[04:30:11] <TJ> Rajeev: In AKA system, you have mutual authentication.
[04:30:31] <TJ> (more discussion on this)
[04:31:25] <TJ> CC: Pre-authentication information. I agree it can help obtaining ? ,. there are 2 layers, using 802.11i,... Which are you using?
[04:31:46] <TJ> A: Protocol for deriving network key not relating to network access at this point. Not pre-auth as defined in 11i.
[04:32:11] <TJ> 1st message from MN to AR1, it can send an HO request to AR2 while it's attached to AR1.
[04:32:48] <TJ> Hesham S: 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).
[04:33:18] <TJ> 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
[04:33:32] <TJ> A: This has been beaten to death, and it's not considered secure enough.
[04:33:57] <TJ> This is really a single round trip with every AR, and it's not in the critical path.
[04:34:12] <TJ> You only need HO key when you're about to send FBU to old AR.
[04:34:37] <TJ> Hesham: Depends on what requirements are on performance of HO. ..
[04:34:47] <TJ> Continuing with slides. "Mailing List Discussions"
[04:40:29] <TJ> 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.
[04:40:46] <TJ> A: Leverage is that you don't have to share any other key with AAA server than what you already have for EAP.
[04:41:29] <TJ> 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.
[04:41:42] <TJ> A: Today with roaming, AAA-L acts as a proxy.
[04:41:53] <TJ> DD: ?
[04:42:48] <TJ> Hesham: You don't actually need .... 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
[04:42:54] <TJ> A: Between AAA server and AR?
[04:43:00] <TJ> A: That's exactly what we're doing
[04:43:06] <TJ> JAmes: ends up on NAS and not the router.
[04:43:17] <TJ> Hesham: You authenticate, profile comes down, and you attach that
[04:43:27] <TJ> A: Tying this protocol closely to network access.
[04:43:40] <TJ> James: Sounds like you haven't read the draft. I was trying to figure out a way to derive the key from AAA
[04:43:44] <TJ> (continue on ML)
[04:44:01] <TJ> Next Presentation: Neighborhood information Elements Discovery
[04:44:06] <TJ> presented by Rajeev Koodli
[04:44:22] <TJ> "Background" slide
[04:44:26] --- gr8k@jabber.org has left: Logged out
[04:45:17] --- gr8k@jabber.org has become available
[04:46:42] <TJ> "Problem" slide
[04:47:52] <TJ> "NED" slide
[04:49:03] <TJ> 2nd NED slide
[04:51:00] <TJ> DD: I have several questions. I think we are trying to re-invent CARD with a different name.
[04:51:48] <TJ> A: Let me answer that. (on Background slide) You resolve L2 identifier to something more useful for L3. No service attributes,. We could have extended FMIP or CARD to do this.
[04:52:37] <TJ> DD: When CARD was designed, we wanted to provide this mapping, and get ? 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.
[04:52:44] <TJ> Stefano: Let's talk about 21 later.
[04:53:25] <TJ> A: Transport is client-prtocol specific. CARD uses ICMP.
[04:53:34] <TJ> DD: Can be carried over other protocols as well.
[04:53:47] <TJ> Stefano: don't want to have discussion on CARD vs NED here.
[04:54:12] <TJ> 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.
[04:54:36] <TJ> EE: If information element is described in XML format, do you think it should be combined into ? in this protocol?
[04:55:00] <TJ> A: Message structure followed by TLV. Each option has its own data part. You can define your own structure in the data part.
[04:55:25] <TJ> Suresh: Why did you want to model this after EAP? You're limiting yourself to 255 octets of data.
[04:55:43] <TJ> A: Good point. We wanted the multiple protocols listed to use it. So we have to live with that limitation.
[04:56:14] <TJ> James: It was an architectural sense. We wanted people to use it in different ways as mentioned.
[04:56:28] <TJ> Next presentation: A.J. Rajkumar
[04:57:57] <TJ> Media Independent Handover
[04:58:36] <TJ> 802.21 working on media-independent handovers across various interfaces
[04:58:52] <TJ> "Scenarios considered" slide
[05:00:01] <TJ> "Reference model" slide
[05:00:24] <TJ> Primarily looking at MIH - media-independent handover function/layer
[05:00:35] <TJ> multi-mode station w/ 802 interfaces, protocol stack
[05:01:17] <TJ> "Information service" slide
[05:01:52] <TJ> Events flow from lower to higher layers. Command services where handover gets controlled and can be network or mobile initiated
[05:02:00] <TJ> and Information services, which is where we're talking to IETF
[05:02:22] <TJ> These are examples of information elements that we could get (on slide)
[05:02:26] <TJ> "IS Requirements" slide
[05:02:44] <TJ> These are high-level requirements and we're still deliberating on them.
[05:03:27] <TJ> 2 types of requirements - transport and protocol. Terminology - network MIHF instance called NMI, and mobile instance called MMI.
[05:03:48] <TJ> NMI to MMI and NMI to NMI are the interfaces we're thinking of
[05:03:56] <TJ> (greg will show pictures)
[05:04:29] <TJ> Able to acquire HO information in advance, from Information Server
[05:05:02] <TJ> "Arch / Protocol Reqs for MIIS"
[05:06:16] <TJ> "... (2)"
[05:06:42] <TJ> "... (3)"
[05:07:47] <TJ> 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?
[05:07:52] <TJ> A: No, this is for the L3.
[05:08:07] <TJ> Separate L2 requirements to discuss in another forum
[05:08:16] <TJ> Alex P: You are developing an L3 protocol?
[05:08:31] <TJ> A: These are specifically for L3 and above. So transport would be L3.
[05:08:39] <TJ> And protocol would be carried in L3
[05:08:49] <TJ> Hesham: Can you carry L2 information in L3?
[05:09:17] <TJ> A: Yes, it could carry L2 infomation which is static, that is from information server
[05:09:23] <TJ> ---
[05:09:36] <TJ> Next presentation: Greg Daley
[05:09:42] <TJ> Example Scenarios for Information Services
[05:10:40] <TJ> These are personal ideas, that might help people visualize things. Once pictures have come up, we can take questions.
[05:10:49] <TJ> This is not the 802.21 group's view, but my own view.
[05:14:06] <TJ> DD: When you say IS server, ..?
[05:14:21] <TJ> A: This is not a single cell or IP subnet. Enterprise domain or service provider.
[05:14:31] <TJ> (on "Example IS entities")
[05:14:44] <TJ> DD: So you have 3 components. One in mobile, one in access network. ...?
[05:15:13] <TJ> 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.
[05:15:35] <TJ> Could be on access router, access point, server in the network.
[05:16:14] <TJ> 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.
[05:17:53] <TJ> 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
[05:18:10] <TJ> EE: Do you restrict that client can not contact server directly?
[05:18:26] <TJ> a: may not know server.
[05:19:18] <TJ> (Last slide)
[05:20:45] <TJ> 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, ...
[05:21:18] <TJ> DD: If you have to add SRP record for DNS,..
[05:21:24] <TJ> A: We need to check that it's valid and secure.
[05:21:45] <TJ> Suresh: Circular dependency. If it's L3, we might end up with reactive handover, and we need discovery phase in the 1st hop.
[05:22:10] <TJ> 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.
[05:22:46] <TJ> ff: if 1st hop NMI does not have information, then.. ?
[05:23:03] <TJ> 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.
[05:23:30] <TJ> 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?
[05:24:08] <TJ> 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.
[05:24:18] <TJ> Hesham: So can we call it mobility information service?
[05:24:29] <TJ> A: Maybe we need mobility independent blah blah blah...
[05:25:04] <TJ> Next Presentation
[05:25:12] <TJ> Rajeev.. just saying a couple words at the mic.
[05:25:44] <TJ> We got an RFC # (applause). Those who still have references to -03, please update to RFC 4068. Moving forward, issue tracker for bis version
[05:26:50] <TJ> Q: Experimental or PS?
[05:26:53] <TJ> A: Experimental
[05:26:58] <TJ> Next presentation:
[05:27:03] <TJ> Rechartering by Gabriel M.
[05:30:08] <TJ> Thanks to all presenters. Please send presentations to chairs.
[05:30:45] <TJ> Ajay: Can we have comment on how CARD does not solve problem?
[05:30:54] <TJ> James: I tried it and it didn't work. Why don't you write a draft?
[05:31:06] --- gr8k@jabber.org has left
[05:31:11] <TJ> Stefano: Let's define requirements first, and then analyze what is available, including CARD
[05:31:52] --- faw has left
[05:31:54] <TJ> James: Are you going to write up a charter and post it to the list?
[05:32:02] <TJ> A: Yes. Most important things are deliverables.
[05:32:14] <TJ> FF: Can you talk about -16 and CDMA?
[05:32:22] <TJ> A: Informational documents
[05:32:29] <TJ> (end)
[05:32:31] --- TJ has left
[05:32:38] --- bonninjm@jabber.org has left: Logged out
[05:32:41] --- rune has left
[05:34:44] --- kk has left
[05:48:07] --- rbless has left: Disconnected
[05:51:26] --- FDupont has left: Disconnected
[07:12:42] --- WH has become available
[07:39:58] --- WH has left: Disconnected
[10:19:31] --- WH has become available
[10:19:54] --- WH has left