Subject: [MEXT] Madrid Interim Meeting Minutes

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 7 Mar 2008 17:21:26 +0100

Hi,

Please find the minutes attached. Let me know if you want to make any  
correction

----------------------------------------------------------------------------
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							

_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext