Re: [MEXT] On draft-ietf-mext-aero-reqs-01

["Eddy, Wesley M. (GRC-RCN0)[VZ]" <[e-mail]>]

Thanks for your comments; they all make sense to me.  Here are
some responses and clarifications:

>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On 
>Behalf Of Alexandru Petrescu
>Sent: Wednesday, March 12, 2008 5:25 PM
>
>I would like to suggest a requirement for supporting 
>continuous IP sessions on MRs and on LFNs.  This is some basic 
>assumption in all MIP work, but I feel like it's never enough 
>emphasized.  I mean something like:
>
>Req0: it is required that a solution for NEMO RO for aero 
>industry to ensure running continuous sessions on MR and on 
>LFN, despite the MR changing its Care-of Address.  A normal 
>non-mobility aware IP application (TCP or UDP streamns) should 
>not be blocked (but could suffer some slight interruptions) by 
>the change of MR's CoA.
>
>The requirement is relatively important and should be well 
>stated.  If not stated well enough then MIP is not needed at 
>all.  For example, Skype, if one can be happy with a Skype 
>reachability and automatic reconnection upon each change of 
>CoA then one doesn't need MIP at all.
>One must need the capability of continuing a ongoing skype 
>call upon the change of CoA, without having to redial the 
>number, or to modify skype software.


Yes, we can describe this better.  There is some historic basis
for keeping an MNP that doesn't change in both the prior ATN
and Connexion systems in which the onboard prefix was fixed
throughout the course of flight.  This should probably be in the
introductory discussion rather than the requirements though,
because I think of the requirements as being for an RO solution,
which presumes MIP is an underlying technology.  This would only
be a full requirement in a more general document that contained
requirements in general for aero mobility solutions (not just MIP
RO solutions).


>Also, MIP is never needed if a plane never changes its CoA 
>travelling across continents because the underlying link-layer 
>ensures it gets same CoA from Sattelite and from Ground.
>


There are different access network providers that are transitioned
between during the course of a flight, so allowing the CoA to change
is operationally simpler than trying to keep it static.  Also, with
multiple links, some address that's independent of the currently
connected links (like a HoA) is needed.


>> Req1 Separability "an RO scheme MUST support configuration by a 
>> per-domain dynamic RO policy database."
>
>Could this be a goal for the MIB NEMOv6 work?  Maybe a new 
>knob to add to the MIB in the MR, such that one can control MR 
>from a distance, tell it for which domains to use RO for which not.


Possibly.  That would make sense to me.  The only possible downside
I can see is that it could be difficult to specify at the moment if
we envision multiple RO schemes being adopted rather than just one.


>> Req6 Scalability
>
>I agree mostly with this requirement.
>
>For the record of work mentioned on this list.  Would it be 
>possible to mention here and refer to the work that used BGP 
>to achieve network mobility.  Maybe just say that this work 
>happened and it was reported in so and so reference.


Sure, we already have a reference elsewhere in the document to
Connexion, so we can add another citation and explanation here
too.


>> * The RO scheme MUST permit the receiver of a BU to validate 
>the CoAs  
>> claimed by an MR.
>
>I'm not sure I understand.  In the slides there was something 
>about the Alt-CoA too.
>
>Maybe this req can be addressed simply by 3775-RO which would 
>validate the MR's CoA with HoT/CoT/I messages.
>
>I'm trying to understand why is this req here.  What do we 
>risk if we don't validate that CoA.  What more than MH-MIP6 
>(non-NEMO) risks are there if we don't validate the CoA.


In some sense, an attack is worse for NEMO RO because a single
forged BU redirects an entire MNP's worth of traffic, not just
a single /128 HoA, so it's a more effective way to DoS an address
by listing it as the CoA for the MR than for a MH.


>> * The RO scheme MUST ensure that only explicitly authorized MRs are 
>> able to perform a binding update for a specific MNP.
>
>I completely agree.
>
>I would also add some text on prefix ownership as a security 
>goal for NEMO-RO.  Francis stated today "authorization" sounds 
>better because a stronger tint.  I'm not personally sure but I 
>could live with that term too.  "Authorization" makes one 
>think of AAA usage and here I'm not sure we want to rely 
>completely on AAA to authorize.  My take.
>
>PRefix ownership is something which was discussed some time 
>ago around NEMO RO and was shown difficult to achieve as 
>opposed to 'address ownership' easily proven by return 
>routability tests - one couldn't return test all addresses 
>within a prefix.  However, prefix ownership could be proven 
>maybe by certificates or by some delegation between LFN and MR.
>
>Which brings me to ask related to the following text:
>> It is also reasonable to assume trust relationshiops between 
>each MR  
>> and a number of mobility anchor points topologically near to 
>its CNs  
>> (these anchor points may be owned by the service providers), but it  
>> is not reasonable to assume that trust relationships can be 
>> established between an MR and any given CN itself.
>
>Ok, sounds reasonable.  I'm not sure who exactly is the owner 
>of these anchor points, but it is understandable.


The ownership of the anchors isn't determined yet, and likely
doesn't matter to the RO protocol as long as those trust
relationships exist.


>I also wanted to ask: can we assume strong trust relationships 
>between LFNs and MRs moving with them?


I think so.


>Also comment on this:
>> The base NEMO standard [1] allows Mobile IPv6 [2] to be used 
>by mobile 
>> routers, although NEMO does not support Mobile IPv6's Route 
>> Optimization (RO) features.
>
>I would like to stress that MR running NEMOv6 can very well 
>run Route Optimization Return Routability tests for its own 
>Home Address, thus giving applications running on that MR the 
>possibility to use RO.  Of course, this is MR only, it is not 
>for LFN nor for VMN, but it is worth mentioning IMHO.


Ok.


>> Des5 Generality
>
>HEre one mentioned NEMO RO working on VANETs and consumer electronics.
>Which sounds excellent desideratum to me.
>
>But do we want an aero anchor point to be available for two 
>VANETs or two consumer PANs as well?  Or are these anchors 
>just optional?


At this point, they're just optional.  It would be nice if
they were supported well, but it's not crucial.
_______________________________________________
MEXT mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mext