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

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 12 Mar 2008 22:24:46 +0100

Hi MEXTers,

I have some comments on draft-ietf-mext-aero-reqs-01 which I finally
read in more detail.  I would have liked to browse the slides presented
today as well but they don't seem to be available at
https://datatracker.ietf.org/meeting/71/materials.html#wg-mext

I think the draft is describing in sufficient level of detail the
necessary requirements, with a language that is very pertinent to the
respective industry.  I think the requirements and desiderata are very
valuable for the potential work on solutions.

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.

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.

I think this is subject to further discussion.  I think if we're not 
sure what kind of session continuity is needed then it may be that MIP 
is not needed at all in a particular deployment.  There are _many_ 
software applications that work ok in mobile environments and with which 
many people are very happy.

Let me list the draft's reqs/deses here for brevity and ease of discussion:

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

> Req2 Multihoming

> Req3 Latency

> Req4 Availability

> Req5 Packet Loss

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

I think it is important because compared to many NEMO RO works which
were worked only on paper, this BGP network mobility support was
apparently experimented in practice and deserves being mentioned because
it teaches useful things.

> Req7 Efficient Signalling

> Req8 Security

> * The RO scheme MUST NOT further expose MNPs on the wireless link 
> than already is the case for NEMO basic support.

I agree.  Sounds like a confidentiality requirement.

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

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

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

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.

> Req9 Adaptability
> Des1 Configuration

> Des2 Nesting

> Des3 System Impact

> Des4 VMN Support

These look good to me.

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

Thanks,

Alex

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" <[email-masked]>
Date: Wed, 19 Mar 2008 08:13:12 -0500

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

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] 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.

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

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

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

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

>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
[email-masked]
https://www.ietf.org/mailman/listinfo/mext