Seamoby Working Group Thursday, March 21st, 3:30PM - 5:30PM [Editor's note: When I did not know a name, I used someone, or some guy. When two or more people whose names I did not know were talking, I tried to be consistent with the tags. I inserted [too fast] where the minute taker's buffer got full, and subsequently dumped] John L : Wants a hum to ask for consensus that we are happy with the direction we are going in. (Process), basically. David [IEEE guy]: What direction are we going on, in respect to 802.1f Pat said he would get Bob involved. Jim said he would go to the 802.11 meeting in July to inform them of what's going on here. [General "Who's going to be on the design team" comments] AD[but not Allison . . ]: If your design team is not the whole WG, there will be complaints. Jim: I understand. George: Wants information provided to the whole group when standards bodies or other companies start driving processes that affect us. Allison: If it is going to be an RFC then it will come back here, but joint ventures usually fail. Chairs: We just don't want to duplicate effort. (As in EAP) Pat: Input was provided to IEEE during the ballot process, but it was ignored. David: 11f passed ballot, and is going through re-circulation ballot. Between the two of us (Pat + Bob) and Dave, we will keep up with the proceedings in 802.11 Heesham wanted a question mark removed. Jim explained what a question mark was. Allison: [re comments of where things are going] Interest of IESG. Informational documents. She's going to straighten it out. ******* Marco Liebsch - NEC Heidelberg ******* DMHA design issues & framework discussion (IP Paging) Current Design Issues RFC 3154 requires mobility independence + support for existing protocols. Proposal 1 Different paging protocol for each mobility protocol Problems: Ignores 4.7 for RFC3154, will have different extensions. Advantages: Takes advantage of mobility specifics for IP paging Proposal 2 Dormant mode location tracking as well as paging trigger packet detection is part of paging, and independent of the mobility protocol. Problems: Mobile node has to keep track of two bindings of location information. There are stateful entities in the DMA and TA . . fail-over becomes complicated. Security between mobile host and TA/DMA Advantages: It's a cellular/VLR like system with active mode location maintained by the mobility protocol and dormant mode location maintained by the TA in foreign network. Allows having DMHA separated from mobility, but has strong requirements on fail-over handling. IP paging separated from mobility management. Allows flexible deployment of DMA function. Proposal 3 Partition the protocol into a core mobility protocol independent part and a separate mobility protocol dependent parts. Problems: Distributed functionality . . . SA is distributed. UNABLE TO UNDERSTAND NAME: Proposal 3 looks simpler, but it really has higher signaling requirements. He claims to have data to support his claims. Problems: Mobile may have to leave dormant mode to update SA. What happens if the mobile host has multiple interfaces? Some which use an IP mobility protocol and others don't? May require the host to wake up from dormant mode when it moves paging area Additional security association between DMA/TA and PA required. Advantages: Keeps location info and state maintenance in one node Implicit SA between MN and mobility agent could be taken. Easier fail-over handling. ANY COMMENTS? -- none Mode 1: DMA received paging trigger packets (is tunnel end-point) DMA is distributed Heesham: Wanted clarification that DMA could be an alternate CoA. Heesham: Have you considered the security issues of doing that? What about a return routability test? Speaker: For the registration? Heesham: Will you use the DMA as an alternate CoA? Would it be able to request another binding? Speaker: We assume that the binding does not exist when it's in dormant mode. Heesham: I don't think you can take it for granted that this will work. Speaker: I agree with you that we need to take care of this. Problem: Unnatural paging trigger packet processing at DMA having the HoA as MN identifier within IP-IP encapsulated packets Problem: Is there a risk of getting routing loops in case of not synchronizing binding caches. Mode 2: DMA in Capturing mode (distributed on routers) Requires a protocol between distributed DMAs and Tracking Agent additional security association between DMAs and TA. More distributed approach, efficient fail-over handling required. Allowing both modes to be deployed would allow high degree of flexibility. Heesham: [Some question I didn't quite catch] Heesham: If I'm on link A, and I'm dormant and move to link C, how does it send the packet to me on the link that I'm on? Heesham: So, you're mapping paging areas to links or subnets? Speaker: The mobile node has to send paging area updates to the tracking agent every time it moves. Heesham: So, if you have to do a paging update, why don't you just send a binding update? Chairs: We're not doing only mobile IP. This protocol is designed to work even if you're not using mobile IP. Heesham: [doesn't seem to understand] Speaker: Let's take it to the list. Question: Support for different IP versions? Implementation consideration: What's to be handled in the kernel, what can be in user space? Some guy: I don't understand either of these questions. Do you mean application layer? John: Comment about first question: I think most of us realize that IPv6 will be deployed in mobile environments fairly soon. And applications should be able to support both v4 and v6 (since v4 will be around for a while longer) How to handle individual paging areas and meet RFC 3154 requirements. Jim: I think this is a very interesting issue, and worth looking into. I think it might be like host routes, and very hard to implement, but it's definitely worth looking at. Speaker: ack. Misc: In General: Allow stationary hosts go dormant and to use paging? More specific: DMHA filtering vs filtering for DMHA Allow routers to enter dormant mode and to use paging? Signaling over UDP equivalent to "application layer signaling" Additional issues: Appropriate mechanism for fail-over handling w.r.t support of robustness Improvement on support of hosts having no explicit L2 paging Security support - as soon as the framework is agreed on, appropriate solutions should be studied and specified. Next Steps We can discuss all this on the list. We need to start on draft-ietf-seamoby-dmha-framework-00.txt Comments? ----------- Pat: We've been talking about paging quite a bit Jim: Proposal: If we focus on one topic, we'll get good technical discussion. Example: Mipv6 security discussion. Relation to seamoby: 3 technical topics currently, all of which are a significant amount of work. So: we need to focus on one. We're going to drop DMHA. We encourage a DMHA bof at the next ietf. Pat: We're at a point where we're building 3 protocols, and we need to free up cycles. George: But it's been so much fun. ------- Steve Deering (mystery guest) - CAR discovery I was asked to look at the two drafts on CAR Discovery, and was asked, as an old IP bigot to look at them (from an IP level). I'm nervous about this because I have no background in the problems you're trying to solve. Part of being an IP guy is to avoid contamination about L2 things. (L2s come and go . . IP is forever) I don't see how network controlled hand-off can handle the technological and administrative heterogeneity and scale of the Internet. Heesham: I've been trying to say the same thing for so long. A mobile node may have as CARs many different kinds of routers public cellular routers one or more wireless lan ARs one or more ARs accessible over wired links. one or more ARs accessible over satellite links, infrared links, etc. there's a potential for many access routers to be visible The notion that your CAR will look at the list and make the decision for the mobile is absurd. (It can't possibly scale) No one AR can make the complex multi-dimensional trade-offs entailed in deciding when to move and where to move. (price / usability / etc) The only entity in a position to know the existence of all the possible CARs is the MN itself. (It could collect them all and "tell" the AR but . . ) The only entity in a position to know how to weigh the various attributes offered by the CARs is the human using or owning the MN Challenging enough to figure out how to teach the MN how to do automatic selection. Crazy to think about teaching every AR with which the MN establishes a transitory relationship. Placing authority in the MN, instead of current AR, seems the obvious solution, and conforms to (at least some) IP "principles" (eg, "smart host, dumb network", "end-to-end" the effectiveness of the MN's decisions will depend greatly on the quality of the information that it can acquire about it's CARs An AR or a group of ARs under common or collaborating operators may well be able to provide info to let the MN take operator's desires into account. ("please move to ARx ASAP" the "seamlessness" of the hand-off will depend on the willingness of a current AR to provide context transfer to an MN requested next AR. Comments: CharlieP: I'm curious: couldn't in some cases the AR's decide where you're going? Deering: Yes, see the sub bullet. But, it can't do anything other than ask the mobile . . Charlie: What if the AR kicks the node out, and moves it to another AR. Deering: It could, but the mobile doesn't have to accept it. It AR can't know what all ARs the mobile has access to. Charlie: Yes it does. John: Generally, nodes do not participate in routing. I can see that that can be a role in CAR discovery. Deering: I wouldn't generalize this as a mobile node participating in routing. George: I think you're right to ignore the link layers. But, there could be a link layer that lets you talk to multiple ARs at a time. Or, there could be a link layer that only lets you talk to one. You can possible solve the problem at the IP layer, but you can't ignore the specifics o f the link layer. Someone: Automatic selection very difficult to do, but it really depends on what the situation is. David: At least in one homogeneous link layer (802.11) You can't have another access point tell you what to do. What happened last week in the 802.11 meetings, they're further going down the path that the mobile is controlling itself (not the network controlling the mobile) Deering: Are the CAR documents intended to allow mobile to 802.11 networks? If so, then they don't work. Heesham: Network control vs mobile control - the reason from deviating from the mode where the mobile sent the packet from the router . . . we should make this a general policy. ------------------ CAR Discovery Requirements Govind Do you still want to hear these requirements? One small note There was a small change to the issues draft. There is now a time based classification of Anticipated . . . [too fast] The requirements discussed henceforth in this talk are meant to be satisfied by ANY CAR DISCOVERY solution. These requirements are not specific to a particular solution. 1) Mapping AP identifiers to IP addresses of ARs. Once an AP identifier is forwarded as an input to the CAR discovery protocol, it MUST map the identifier to the IP address of the AR which the AP is connected to. Deering: So, my cellular router is going to tell me the IP address of an 802.11 AP that I just found? Heesham: We need to clarify this requirement more. Requirement 3: SUPPORT FOR HANDOFFS FROM PRIVATE AND SITE LOCAL ARs Needs to be separated for ipv4 <-> ipv6, sitelocal ipv6 -> ipv6, public ipv4 private ipv4 and combinations of above Comment: Too many combinations. George: Doesn't this degenerate into the problem of communicating between all these things. This isn't relevant to CAR in particular. Speaker: The discussion started because of the question that [too fast] comment: What about the different cases where the identification is necessary? And, the ARs could be on different spaces. It just makes the text longer. how many people are for the requirement? Against? Deering: The mobile needs to be able to identify it's CARS, but whether or not the ARs need to identify each other isn't clear. So, what do you mean?" Guy: Must identify IP address won't work because it could be an IP address in a private space. Heesham: Mention the entities involved, because right now it is too confusing. Jim: We've talked enough. Let's take it to the list. Pat: We've been going down one path, and Steve's brought up an alternative. (Try to get the mobile node to participate). Rough consensus: yes Jim: We need someone who has time to donate to do this. Guy: We already have the problem description. Michael: In San Diego we had a draft called <> with network initiated and mobile node initiated transfers. What happened? What religion overtook this group to make it happen now. Pat: Steve is very inspirational. Some guy will do requirements document. John: I do not think the thing Steve was asking for was to have a document with the union of all possible ideas in it. Jim: Should we drop the network model? (3 hands) John: I'd like to suggest that there are people interested in both models. We can have a pseudo draft, not a WG draft, to start some discussion. Michael: most of the applicability of a document like this is for a homogeneous case. But, our application is probably not going to be homogeneous . . I just wanted to be very clear that in a particular case for homogeneous network transfer is probably the best way. I don't want to preclude that case. Steve: Same thing. There are times when information from the ARs might help the mobile node make a better decision. I wasn't advocating killing this work, but it just needs to fit into a basic model. Jim: there is some considerable amount of evidence that information from the network helps to optimize mobile IP. What I'm saying is that there is some indication that network assistance is helpful, but in inter technology situations it may not be available. --- Requirement 6: SCOPE People were not too sure about interdomain. People now want interdomain to be a must too. Jist of it: Stay a SHOULD. New Requirement 1: PROVIDING MN's REQUIREMENTS FOR DETERMINATION OF CARS: The car discovery solution must provide a means for the MN to express it's requirements for the determination of CARs. The MN preference solution should be logically separate from the CAR information distribution solution in order to maintain separation of security requirements. Heesham: Something about QOS. So . . . what kind of list will the mobile node provide to this router? It sounds alright but the realization sounds quite difficult. Speaker: A simple case would be: "I want to watch a porno site, do you allow it?" Guy: It gives ultimate control to the mobile node to decide where it's going .. . Someone: The issues draft matches the requirements . So, that's why it's here. Pat: Steve is saying the network provides information and the node selects. This seems opposite. Someone: It doesn't say that there is a transfer of requirements from one box to another. George: Heesham was right when he said, you need to state "how far are you willing to go" Heesham: And, what kind of privacy and confidentially. Guy: The line here is that there is a problem and a harder problem. This as it stands is well worded. too fast. -- New Security Requirements CAR discovery MUST ensure that the AR claiming to be it's GAAR is a genuine AR CAR discovery MUST/SHOULD ensure that this genuine AR is it's GAAR. Steve: People keep saying that this is neutral as to who is making the solution, but that says that the AR has to be genuine. Why does it have to be an AR? It could be a mobile. -- Security Requirement 2 A solution to CAR discovery MUST provide means for secure capability exchange between AR and it's GAARs. Someone; It would be better to add MN/AR to not bias the solution (like Steve Said) -- Security Requirement 3 A solution to CAR discovery MUST provide secure means for the expression of MN requirements to car [too fast] Security Requirement 4 -- too long. Security on CAR information capabilities distribution MUST conform and interoperate with existing IETF security policies and protocols on the security of routing information distribution. Security on communication of MN preferences to ARs must conform and [too fast] Requirement 5 - FORMAT OF CAPABILITIES The capabilities MUST be described in a standard format which is TBD. George: This needs to be modular. but you will probably end up defining some minimal capabilities. Then you need a VERY big vendor specific space :) Guy: Time to define the formats? There is already work being done in this area. We need to start out with a study about what's already available in the market. -- Requirement 9 DEPENDENCE ON A MOBILITY MANAGEMENT PROTOCOL CAR discovery MUST NOT depend on a particular mobility [too fast] Requirement 10 EFFECT OF CHANGES IN NETWORK TOPOLOGY A CAR discovery protocol MUST be adaptive to changes in physical topology as well as logical topology. George: What does it mean? Heesham: I don't understand it either. If ARs are used to handle hot spots. -- New Requirement 2 - RE_USE OF EXISTING PROTOCOLS FOR CAR DISCOVERY The car discovery solution must re-use existing protocols wherever possible. Contention free requirements [too fast] Anything else?