Hi, I would like to submit the minutes and additional material for the MEXT interim meeting. please find them attached: The meeting slides can be downloaded from: Meeting Materials: http://www.it.uc3m.es/marcelo/MEXT_interim_madrid/C2C.pdf http://www.it.uc3m.es/marcelo/MEXT_interim_madrid/ISO.pdf http://www.it.uc3m.es/marcelo/MEXT_interim_madrid/nemo-aero-reqs.ppt http://www.it.uc3m.es/marcelo/MEXT_interim_madrid/nemo-solutions.xls Regards, marcelo ---------------------------------------------------------------------------- MEXT Interim meeting ---------------------------------------------------------------------------- Date: 7,8 February 2008 Place: University Carlos III of Madrid, Madrid, Spain ---------------------------------------------------------------------------- Assistants: Julien Laganier Wesley M Eddy Carlos J Bernardos John Zhao Eivan Cerasi Jean-Michel Combes Christian Bauer Ryuji Wakikawa Vilmos Nebehaj Thomas Heide Clausen Roberto Baldessari Serkan Ayaz Thierry Ernst Antonio de la Oliva Maria Calderon Francisco Javier Diez Castro Jozsef Kovacs Hugh Mote Jari Arkko Marcelo Bagnulo ---------------------------------------------------------------------------- Minutes by: Carlos Jesus Bernardos, Antonio de la Oliva, Wesley Eddy, Jari Arkko and Marcelo Bagnulo ---------------------------------------------------------------------------- Agenda: - NEMO RO Requirements for vehicular networks, C2C viewpoint R. Baldessari - NEMO RO Requirements for vehicular networks, ISO viewpoint T. Ernst - NEMO RO Requirements for aviation networks W. Eddy - Solution space analysis All ---------------------------------------------------------------------------- Summary: The focus of the meeting was route optimization for NEMO. In particular, the meeting talked at length about the aviation industry's requirements for this and what kind of architectural approaches are possible. Overall, the aviation business case seemed stronger than perceived in the IETF and there now were more people in the meeting and not just NASA & Boeing that had participated in the IETF. Airbus and Eurocontrol folks were also present. Their requirements are relatively stable in draft-ietf-mext-aero-reqs. They are going forward with moving air traffic control networks to IP, adding networks to deal with operational communications, and adding passanger communication mechanisms. For at least some of the communication some mobility solution will be needed, e.g., NEMO, host mobility or application changes. The MEXT WG is chartered to add support to NEMO so that it can provide more optimal routing. Suboptimal routing is a real problem in passenger networking, for instance. Basically, on intercontinental flights a tunnel-based solution will incur an extra continent roundtrip. In general, the main route optimization approaches that could be employed by these networks are: (1) Route updates a la Connexion. Dismissed by IETF and ICAO. (2) Federated home agents and anycast routing, one HA for each continent, airplane picks always the closest home agent as it moves around. This avoids extra tunnel latency to the other side of the world and works with existing Internet hosts on both sides of the communication. Similar to existing VPN and mobile networks, no impacts in the rest of the Internet. (3) End-to-end (or router-to-router) route optimization based on prefix ownership certificates. New planes like A380 have certificates already, and the community is ready to deploy new ones for new purposes. This approach allows also operation without going through a home agent, such as in network problem cases. The main issue is that for passenger etc. traffic we cannot expect the servers in the Internet to be updated with such support, so it would be mostly applicable to ATC domain. Very secure and architecturally appealing. (4) Application modifications to be able to deal with address changes. Next steps include an update of the draft and starting a discussion of what architecture to choose. Need more people interested in pursuing solutions. Need more of the aviation community participating in the IETF. ---------------------------------------------------------------------------- Meeting Materials: http://www.it.uc3m.es/marcelo/MEXT_interim_madrid/C2C.pdf http://www.it.uc3m.es/marcelo/MEXT_interim_madrid/ISO.pdf http://www.it.uc3m.es/marcelo/MEXT_interim_madrid/nemo-aero-reqs.ppt http://www.it.uc3m.es/marcelo/MEXT_interim_madrid/nemo-solutions.xls ---------------------------------------------------------------------------- Minutes: - NEMO RO Requirements for vehicular networks, C2C viewpoint R. Baldessari [Hugh] What safety means? in the aero environment it means safety of life. [Roberto Baldessary (RB)] It also means safety of life in this context, but NEMO is only used for non-safety, but for infotaintment. [Jari Arkko (JA)] What kind of link does the C2C Net layer? [RB] It provides a geographical broadcast link. The link concept is map for a geographical area. Multicast link addressing can be mapped to a particular geographical area. [JA] Have you successed in keeping the IPv6 multicast semantics over this geographical link? Do IPv6 ND, regular non-mobility multicast things work over this? [RB] If the system is designed properly, I think yes. Besides, some of these functions can be also done by using geographical funcitonalities, such as for example the generation of IPv6 addresses. [JA] So you keep the normal behaviour, but you want to do also some optimisations, that may have an impact on how normal nodes operate. [Eivan] What's the reasioning that let you to say that NEMO is only for non-safety apps? [RB] V2V have time constraints, direct commns are needed. V2V must not rely on the infraestructure. [Marcelo Bagnulo (MB)] question about infrastractureless NEMO RO [RB] We didn't want to use infrastructure-less NEMO RO, due to the use of the C2C-C Net, we didn't want to make the solution more complex... [Eivan] I still don't get it, what is the reasonal to use NEMO for non- safety apps? [Juliena Laganier (JL)] Where is the HA? [RB]: In the infrastructure, C2C-C assumes an operator would provide that. Where the HA would be deployed has not been thought yet. [EIVAN] I see benefits from using NEMO, such as traffic aggregation. [RB] The benefits are those provided by general mobility: global reachability, etc. [MB] I don't think that for this specific purporse they want there are many other options. I don't know what other options can be used if session continuity is required? [EIVAN] Proxy-like approaches? [MB] then you don't have session continuity [JA] there are different approaches, such as using VPN-like approaches, having the AU running mobility themselves instead of in the MR, there is a tradeoff there. [EIVAN] Is there any document describing this? [RB] the c2c-c manifesto [EIVAN] i think we neede this kind of document for our problem Roberto resumes his presentation... RO scenarios (non-nested NEMO RO case, RO between MR and CE) [JA] I agree with your priorities, I don't understand the 4) point, do you assume that it's possible to perform NEMO RO with a MIPv6-enabled CN? It's not obvious to me. [MB] Do you need session continuity with the RSUs? I'm talking to it because it is the closest one, right? [RB] I don't need session continuity, but RO optimisation [MB] if you need session continuity, you may use the CoA [JA] with current technologies, the nodes of the nemo would not be able to use the local prefix, because it's not know by them. if the prefix is exposed, some tricky things may be required to enable this working (exposing the prefix to some nodes), but not a general NEMO RO. [JA] I think there's actually 3a and 3b. 3a: NEMO RO-enabled CN in the road (RSU), 3b: NEMO RO-enabled CN in the infrastructure (e.g., some node in Germany) Roberto resumes his pressentation, now describing requirements. Req 1 - Triggerability (was Separability) [MB] I think you need to specify more the type of situations when you want this triggering: on a per-destination basis? on a per-CN basis? in which kind of situations you want to trigger? [RB] I don't think in a per-CN basis [MB] For example, I'd say that you never want RO with DNS [RB] I was think on an on and off mechanism- [JA] How you would make that decision on turing on-off the NEMO RO? do you have any sensible idea? [RB] YOu have information such as position, speed, so you may know the time a communication will last. You can use that info in the decision process. [RB] why not having a run-time parameter to switch on off RO? [JA] You can set it incorrectly. Maybe it's the car manufacturer or the network operator who provides you with the config file, or maybe is application based... This is an area you need to think about. You'll assuming something will happen, but it's not clear to me how it'll happen. [JA] For the system to work, you need that decision (switching on-off) to happen somehow. Maybe an opportunistic approach can be used. [MB] If I understood correctly, you consider that if the communication is going to last, then it'll make it worth to optimise traffic. [RB] to avoid signalling involved [JA] it'll be important to clarify which kind of situation you'll consider [JL] which will be the criteria to use or not to use NEMO RO? will you have a polocy table? based on timers? [EIVAN] We have the same problem. Maybe the best approach would be to consider a policy-based approach. [Wesley Eddy (WE)] I'd use the same of the same use it's used for IPsec policy table. Of course we have a concern about accountability. Some traffic should always go trough the HA to have a record of that. [EIVAN] Do you consider the RO only for the NEMO case or also for the C2C-C Net? [RB] Only for NEMO, non critical, non-safety part. [WE] This seems that this would not affect the solution, it seems you would be able to do this with any solution. This req is just to avoid you do something stupid. RB resumes, Req 2 - RO Security [MB] I understand that in the case of MIPv6 with RR you only protect off-path attacks. [RB] It should be corrected. In Chicago IETF we discarded to target the use of C2CCC security features for NEMO RO. We are going to remove it. [JA] Clarrification: would these certificates that you have in the C2C- C NET used or not for the NEMO RO? [RB] It might be used. [JA] If you have the input that all devices have certificates, that doesn't mean that all devices are authorised to move prefixes of other nodes. [MB] Certificates might be useful for critical applications with known nodes, but not for infotainment apps, with nodes in the Internet. [RB] Ceritficates could only be used in a sub case of 1: the CE is a NEMO MR using a C2C-C Net. [MB] I'm assuming that case 2 (slide 7) would impose that you have NEMO RO-enabled routers deployed in the infrastrucutre. For example if CNN has a service for vehicular users, they would deploy a NEMO RO-enabled router. (missed some discussion between MB, JL and JA) [JA] ambitious goal to assume deployment of NEMO RO-enabled routers and CNs only for car communications. Assumin youtubes, CNNs would install an additional system seems too ambitious. It'd be maybe better to design something more general. RB resumes his presentation. Req 3 - Privacy protection [MB] you don't want all your neighbouring cars know your prefixes, you don't advertise them through your WLAN ifaces, right? couldn't you solve that with L2 techniques? [JA] Are you using 802.11i? [RB] We are usin 802.11p [JL] Can't you use 802.11i with .11p? [RB] I'm not an expert, but I don't think so. I think .11i was left out of .11p on purpose [MB] the NEMO, would it use only .11 or also .11p? [RB] Both [MB] This cannot be done with current .11? [MB] If you only concern is restricted only to wlan ifaces, then the solution should be done by wlan techniques, trying to solve that at NEMO layer seems to be an overkill. [RB] Good point [RB] Each vehicle has a set of identifiers, it can change the one it uses periodically. [JA] What about random MAC addresses? [RB] Problem with liability, there'd be no way of knowing which car owned a MAC. [Thierry Ernst (TE)] governamental issues? [Jean Michell Combes (JMC)] Contradiction req 1 and 3. [TE] If you do NEMO RO, there is a risk you expose your prefix. [Rjuyi Wakikawa (RW)] When you say RO, is RO for prefixes or for addresses? Does the MR resgister the complete MNP to the CN? RO per address or per prefix? [RB] Prefix, but we didn't mention. It seems solution space [MB] For outgoing traffic, it's a local MR's decision. For the way back, if the same CN/CR you want to run some traffic optimised and some traffic not optimised here is the point. [MB] I think this should be on the separability/triggerability requirement. [Carlos Bernardos (CB)] This is solution space, right? [RW] a car may have a prefix for a secure newtwork where we don't want to perform RO and a infotaimnet networ, where we do RO. The MR needs some mechanism to decide which prefix is optimised. [CB] I think this is solution space and falls within the separability requirement. If you have this policy-table thing that says that the traffic of certain nodes has to be optimised, how this is done is solution space. [JL] I think we should make separability as a requirement, and that includes triggerability. RB resumes, Req 4 - Multihoming [MB] The problem is what multihoming means. Scenarios can get very complex. If by multihuming you mean multiple interfaces and/or multiple MRS, then this is perfectly in scope and should be reasonable done. If you mean something else, then it may become something really complex. [JL] this is multihoming in MONAMI6 scope. [MB] My problem is the second bullet (slide 11): "multiple prefixes" [TE] In the vehicle you mayh have sensors, in addition to this you will have infotainment devices that do not necessary belong to the car manufactures. [MB] Then you don't have nodes inside with multiple addresses, but multiple prefixes within the car. You don't want to preserv communications when one prefix fails, right? [MB] the multiple prefixes is not so clear to me. RB resumes..., Req 5 - Efficient Signalling (not in the available draft, to be included in the draft to be published. I don't think it makes sense to provide some figures. [MB] In the aero drafts there were some comments about signalling storms [WE] There were something, yes, I don't remember exactly [HUGH] But we agree that this is a requirement we want, right? [TE] It's more a way to compare solutions [JL] It's implicit. [WE] Some solutions could be adding headers, some others not. RB resumes, "Removed from previous version". RO should not prevent MNN's IPsec to work, this should be taken for granted [EIVAN] What is the endpoint of the IPsec, not in the car side. [RB] Arbitrary. - NEMO RO Requirements for vehicular networks, ISO viewpoint T. Ernst What ISO and C2C-C does is very similar, but ISO goes a little bit further. [JL] How can we get the CALM documents? [TE] They are not confidential, but not publicly advertised. You have to ask someone to provide them. I can provide them. TE resumes his presentation. You have multiple interfaces and it's the application who decides the interface selection, not the MR. This doesn't mean that a normal application will not work, just it will not benefit from the interface selection. They don't want to use IP for safetu applications currently. [MB] I think requirements for safety and nonsafety are very different, right? [TE] Yes. So far I'm not talking about RO, just only about the arch. [MB] If these guys are not considering using IP for safety, then they are not going to use NEMO. [MB] You are saying that if we manage to come up with a good enough solution for safety using IP, they will use it? [TE] There is no statement saying safety apps shouldn't use IP, but people with radio background are pushing for a non-IP solution. Terminology is also a problem, although they think they have different visions, they have the same. [MB] My current concern is when you integrate this on the current draft, how would you use it, because C2C-C explicitely discards NEMO for safety applications. [RB] This doesn't mean that IPv6 cannot be used for safety apps, but C2C-C does not rely on the infra for safety apps. [EIVAN] For me it seems that they think IP is for the Public Internet, then we don't use it. [RB] There are more reasons. They didn't want (C2C-C) to extend IP to enable it to have all the geographical features. Besides they wanted to have something more flexible. Thay had 2 options: extend IP or desing a new layer? They chose the quicker option, not to extend IP. [JL] what you said about geogrpahical feautres. This wouldn't be possible with current IP stack. If you ended reinventing the stack on top of IP, then it's easier to do from scratch. [TE] But CALM is not considering geogrpahical routing. They want to allow multiple solutions. [JL] What is the link between two cars? [TE] In C2C-C is .11p, so is a shared media. In CALM there is no requirement TE resumes his talk. He switches to CVIS, which is an European project, sort-of proof of concept of CALM but using IP. [RB] Road System, it is not clear to me, is that IP at all? [TE] It might be non-IP, but in principle the IPv6 features should be implemented everywhere, so in case IP is needed it can be used. In CVIS, roadside unit is IPv6. The AP most likely is L2, can be IPv6. [JMC] are the sensors IPv6 addressed? [TE] no, they are not IP. The gateway is IPv6 enabled. TE continues with a presentation of "CALM: NEMO RO and Multihoming requirements" [MB] From a NEMO perspective, case V2I via another vehicle is not the same than the previous one? [TE] If it is done at the L2 it's not an issue. [MB] if it's done at L3, how come is a NEMO issue? [TE] it's a MANEMO issue. It has not been investigated yet. [MB] before the VMN case, I'd expect the generic case of a node talking to a fixed node in the infrastructure. [TE] It was implicit. [JL] (asking about multiple HA slide) why don't you want to use HA at Germany when you are at France? because of latency? why don't use HMIP? [TE] HMIP is a good solution for RO, but you may have multiple HA because of other reasons. [JL] Why do you mean by switching HA? [TE] Reallocation, to keep the connection. TE slide about multiple MRs [JL] You don't need to add a new MR, but to add a new access technology to the existing MR. [RB] This might not be possible. [JL] So you have one MR and it works, then you add one more MR and it works, right? [JL] What are the CALM requirements that are different from the C2C-C ones? [TE] In CALM we have multiple interfaces, in C2C-C is .11p. [MB] We have tried to identify a set of interesting scenarios, to avoid exploid with multiple scenarios. [TE] yes, I wanted to go throgh the conclusion slide first. All scenarios may nt be deployed at once, but the communication architecture should not prevent them. [JL] I think multihoming is more difficult than RO, IETF is still working on that. [TE] RO is about performance, it's not as important as multihoming. Multihoming is needed because of operational reasons. I think the discussion about multihoming has not been appropriate enough so far. Work about RO and multihoming should be done at the same time. [JL] I don't see why we need to add support for multiple MRs instead of enabling the MR supporting the addition of new technologies. [TE] Well, that's the view of people working on the automotive industry. [RB] The OBU is something really automotive, something embedded. I support Thuerry's view on supporting multiple MRs per car. [JL] If you have multiple MRs, you will need something on the nodes to decide which MR to use. [TE] you may need or not. One MR can be the master and the other the slave. [JL] You need to do trick things to support this. [MB] If we consider all these things, then we don't follow the approach we have been considering: separate problems, first address RO, after that multihoming. You consider this is not the right way, what do you propose? [TE] First multihoming, then RO. [JL] I think mulrihoming is more complicated. [JA] do you consider something more than what is on the draft (multiple coas)? [JL] we should go for experimental, concentrate on ro with mcoa and then go for experimental and review things. [HUGH] we need to have a strategy first. the important thing is to get the more complex set of requirements understood first. [JA] I agree the strategy should be understood first. I'm concerned about trying to solve very complex problems. [Thomas Clausen (TC)] I think it's good to get the complex picture and then decompose it into problems [MB] From my perspective, the thing that concerns me the most: what is the thing that has the most impact? if you consider multiple HAs in multiple domains then you need to switch from one prefix to another beloning to a different domain. If we can make the assumption that we don't want to work with multiple HAs at multiple ISPs, then I think you might get to the conclusion that RO and multihoming are somehow orthogonal. - NEMO RO Requirements for aviation networks W. Eddy Req 1 - Separatability [MB] as far as i understand, ATS is Req, AOS is Des, and PIES is not much considered, right? [WE] yes [JA] you might have only one radio link and still have the ROptimised path and the path trhough the HA. [Serkan Ayaz (SA)] ATS has strong latency requirements, that's the reason we want NEMO RO. [MB] critical traffic, you want to go it fast and you want to have it recorded. [WE] if you have global HAHA, the traffic go through the HA and the latency is not so high. The thing is where HAs are located, who manages them, etc... [Chriastian Bauer (CA)] The CNs changes as the plane moves. [RA] CN is close to the MR topologically [EIVAN] I think we should split this into two requirements. [WE] Maybe the right wording is flexibility, if we need to be flexible enough to have separability. [JA] What I'm hearing is that you will need to be able to select RO based on port numbers, etc. The things I found in current text is ***missing***. The other thing is what Marcelo brought up about the recordability of traffic and the RO issue. [MB] Just to be clear on how to update the document. RO should be decided based on traffic selectors. The document should clearly state what it means and how it's done. The other thing is to add a requirement of accountability. [EIVAN] The recording is done at source and destination not in the middle. [EIVAN] Recodfing at end-points is network management procedures not operational requirements [MB] what is the reason you may end up not optimising? I understood it was because you want to record at the HA [RA] because of signalling overhead [WE] We want to be able to control whether we optimise or not, whether the optimised path is authorised or not. [EIVAN] today we have a very small footpring of HAs, but this may change in the future. [MB] depending how you distribute the CNs with respect to the HAs it may be not worth to try to RO, and that it will depend on the application your are using, mainly on a per-domain basis. [EIVAN] Not only the application, but the context of the flight itself. For example in the context of flight landing you don't want to mess up with the RO. [MB] you may want to decide on a RO traffic selectors, and on a per- domain basis and on a completely arbitrarily basis (such for example that we are about to land). [EIVAN] Makes sense to me. [WE] Makes sense to me. [JA] Makes sense to me as well. But this should be clear in the document what is related to NEMO and what is not. [WE] Part of the problem is that the requirements came up without separating what is NEMO, what is MONAMI6, etc. But this is easy to resolve, I think. WE resumes. Req 2 - Multihoming. [MB] Air ground network is the visited network? so basically this multihoming is about connecting to multiple visited networks. [WE] Yes and about having multiple plefixes. [JA] This is not clear in the text. This is something also outside of NEMO, because you may run multiple instances of this whole thing. Question: even if you run multiple instance, you still want multiple MNPs for a single domain? [WE] No, I don't think so. [JA] You have some non-requirements in the document. This is somehting you may want to write down as well. [MB] what is required is to be able to have multiple interfaces active simultanouesly or sequencially and to be able to connect to multiple visited networks, right? [JA] what about a sentece about multiple CoAs and one more about multiple MNPs [WE] Right. [MB] simultaneously connected mean that you are able to send traffic simultaneously? [WE] that you should be able to. [MB] using multiple interfaces simultaneously or as a backup? [MB] So on a per-domain basis you will not have simultaneous use of multiple interfaces. [RA] there's no use case now, but it could be useful in the future from the point of view of handovers. [EIVAN] ATS not required, AOS desirable [MB] it'd be able to understand wheter we want simultaneous usage of this fault tolerance feature (one fails you rever to the other) [MB] the conclusion is that we do want simultaneous usage? [WE] rewording: you should be in possesion of multiple CoAs but this does not mean that you use them simultaneously [MB] on a per domain basis? [HUGH] Yes. WE resumes his presentation. Req 3 - Latency [CB] for me the statement is OK. It might reasonable to consider some fast handover stuff. [WE] But this would be outside of NEMO, right? [JMC] this is more NEMO fast handover than NEMO RO. [JL] after you do a handover, it's faster to update the HA than the CN. what you want is to use the BR while you update the CN? is that the requirement? [MB] so this is maybe a desirable feature, but not a requirement? [JA] if I was designing a NEMO RO protocol I'd do in a way that traffic flows while the optimisation is being set-up. It seems something natural. [MB] so it's a requirement. We only rephrase the unoptimised packet flow. [JMC] but this is not linked to NEMO again. This is fast MIP, you want to use the old link while setting-up the new one [JA] the same problem appears at different layers: L2 mobility, RO, etc. [JA] This is not a requirement, is a desirable thing. Req 4 - Availability [CB] not clear what the NEMO RO solution should do and what can be done by using a different mechanism [EIVAN] example of NAT state [MB] RO is an optimisiation, what do you mean by failure? failure of the NEMO RO? would it be OK to fall back to the BT solution? [EIVAN] yes [WE] should we do something about this req? [MB] you have this type of sentences "falling back to the non- optimised path would be OK"... [EIVAN] is VRP compatible with NEMO RO? [MB] what you are saying is much stronger. you are saying that you are going to use this protocol to provide router reliability. [EIVAN] this is the standard approach, can I use NEMO RO with VRP? there are standard ways and they should not be incompatible with NEMO RO [JL] NEMO doesn't work with NEMO, a router is stateless, an MR is not. You need some mechanism to transmit that state. The problem is NEMO not NEMO RO. Req 5 - Packet loss [MB] wouldn't this req trivially met if yodo with the latency one? [WE] yes [JA] Duplicating packets may have an impact. Question about assuming FMIP [WE] is that right to talk about solutions in the reqs draft? I guess not. Req 6 - Scalability [JA] I think it'd be useful if the document explicitly forbids the injection of routing entries. There have been previous NEMO document discussed in the IESG because this was not clear enough. [MB] it's not clear to what nodes mean here? [WE] MRs [MB] then you are talking about NEMOs [WE] airplanes is more specific [HUGH] aircrafts :-D Req 7 - Efficient Signalling [CB] maybe it's good to say that where we are concerned is to be efficient on the wireless link [WE] it's said in the text [CB] maybe it's good to add 3-4 word in the req phrase [WE] OK Req 8 - Security [JA] I'd split that requirement. The part of IPsec and other things on the payload has to work. The part about IPsec signalling should be more ellaborated. Issues about authorisation have to be more ellaborated. [WE] do we agree with Jari's suggestion? [MB] I'd say that we should actually phrase what Jari said. [EIVAN] exposing addressing on the wireless link (shown in the car discussion today). This is the same basic requirement. [MB] if the MNP is hidden, then it's hard for someone to steal it. Well, I agree that this is true, specially from a privacy perspective. But security by obscurity is not a good approach. [MB] we cannot assume L2 encryption, right? [EIVAN] today not, hopefully in the future yes [WE] one question today was if we planned to run NEMO over current links or not. [MB] if you use BT, you can always encrypt the MR-HA BT and protect that part. With NEMO RO, you lose that part. [EIVAN] you must ask IETF to consider IPsec (since L2 encryption cannot be assumed today) [JL] can you assume a trusted anchor? for ATS maybe? [RA] for PIES not [JL] if the user wants location privacy, it might use end-to-end IPsec [MB] who is authorised to claim ownership of a prefix? so, who is authorised to send a BU? [EIVAN] service provider assings a block to an airline and this airline to a plane [MB] which element is authorised to actually perform a BU of a given prefix? [EIVAN, TE] The MR [MB] you want protection for on-path and off-path attacks... [JL] we need to split requirements per domain? [CB] security seems the only one that is different per domain, the rest seems the same, solution would be probably different [JL] ATS, AOS, centralised security only authorised MR is able to perform the BU signalling [MB] flooding attacks, [JMC] some discussion I raised in ML with MCoA [MB] who is authorised to use a CoA? [JL] we should decide on an attacker model [MB] we should decide on what level of authorisation is required to allow a BU for a given CoA [JL] if you have a limited number of links you can get for each of the providers a certificate that allows you to use a particular CoA. [JL] it's again centralised [MB] authorised by the ISP? [HUGH] discussion offline? [MB] the other issue that Jari was pointing out in his e-mail -- that is not really part of the requirements -- is what kind of assumptions you make about the infrastructure [JMC] in MIPv6/NEMO we have the same problem, the HA trusts the MR and if it's lying there is no way no know [JL] do we know a RO operation mode more secure than the non-RO NEMO? [MB] we should ask Jari about this. [MB] what security infrastructure you are willing to accept to support this? I guess you are willing to accept a PKI (for ATS and AOS). [RA] PKI for the BU or for everything? [EIVAN] for CNs as well, I don't think so [WE] you can even preconfigure it, you have the flight plan [MB] can you extend the PKI to a node that is topologically close to the CNs you want to talk to? so then this node can ROptimise the traffic to the CNs. [MB] by supporting PKI is rather accepting certificates than issuing certificates for them (point made by JMC). These are different things. Would be acceptable the CNS to accept certificates from the MRs. [JL] That's what we need, the authorisation goes in that way. [JL] I still don't get why it's not possible to have certificates for everything. You want a strong level of security you are going to need a PKI, there is no doubt about that. [MB] let's put in another way, how do you plan to perform the authorisation of the BU of the MR to HA. [EIVAN] if we have L2 security, we don't need that [CB] then you need L2 security all the path [EIVAN] yes [JL] but you will then need to configure the SAs in the L2 links [MB] possible to extend the trust model between the HA and MR to all CNs? [RA] no, I don't think so [MB] and with an anchor close to the CNs? [RA] in that case, yes [MB] then, to answer Jari's question, we can assume a trust relationship between the MR and the HA and between the MR and one anchor point topologically close to the CNs. Req 9 - Adaptability [CB] related to the policy table we talked about before (separability req), if there's something new, we should be able to decide whether this should be optimised or not. [TE] Yes - Solution space analysis All Notes from the discussion about the major items. Req8 - Security is a main driver of the solution space should anchor points be HAs or not? what are benefits and costs (especially wrt trust establishment)? RFC 4889 is key reference - points out that CR needs to be detected somehow by the MR MAP could be an HA, a CR, and sometimes even a CN different possible ways suggested for MR to discover MAP: (1) HA informs (2) CN suggests (needs to be verified by MR) (3) static configuration on MR minimum state to be setup is certificate of common trusted root are the entities doing NEMO basic support and RO different? CR needs to be an egress router of CN's network ON-PATH vs. TOPOLOGICALLY-CLOSE assumption on MAP location is important 3 different types of architectures: (1) global HA-HA style - all providers advertise all address space they serve, have multiple distributed HAs (e.g. per continent), HAs tunnel traffic between themselves that is received on the wrong continent … downside is that scale is limited in the sense that you won't be able to have one HA in every CN network (2) two alternatives one HA, but e2e RO capability, MR contacts another (a) CR or (b) CN … possible for much more optimal routing than first approach, downside is requires different type of security whereas option 1 is much closer to current security, certificate showing ownership of prefix gives ability to run completely disconnected (3) MNN modifications - the MR exposes local connectivity information to MNNs and they employ some means to do RO with CNs how optimal does the routing have to be? - answer was "not very" is operation without connectivity to the HA important? "nice to have, but not very" do we accept changes in the CN networks or CN nodes? "for ATS/AOS yes, but not PIES -- may drive 2 different solutions" … how tailored or off-the-shelf can the equipment be? "difficult to answer" are changes to mobile network nodes acceptable? … may be an additional architecture alternative for ATS/AOS but precluded in PIES how to setup state is a separate protocol design choice from the architecture