Re: [MEXT] [Int-area] Rethink on Mobile IPv6
Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] <wesley.m.eddy <at> nasa.gov>
2010-03-03 20:02:29 GMT
I think I basically agree with Terry, though I do have
a little bit different perspective.
It's become commonplace with many protocols to define
"profiles" that tailor the bells-and-whistles and other
configuration parameters that an implementation needs to
include for a specific environment. I've always assumed
that this would be the case for aeronautics in order to
bound the level of conformance testing required and ensure
In some sense, the IETF already does this with MUST, MAY,
SHOULD language in our documents, as the MUSTs define
a minimal profile. However, this is often not really
minimal enough for some people, and to further complicate
matters, it tends not to be enough to do a lot of what
people really want. So we have a persistent problem
in understanding how to add features onto the base
with all of the proper dependencies as the text in RFCs
doesn't indicate the linkages between pieces of one
document with multiple other documents as clearly as a
database system might.
Going down this path of profiles can quickly lead to
profiles developed for different user communities
becoming incompatible to the point where the advantages
of having a common protocol and commodity providers and
implementations are lost. Hannes mentioned that
having an operator ship you software is possible, but
in an air or space environment where you need cross
support, that's not really feasible nor is it really
sustainable long-term for such smaller user communities.
So what I think Basavaraj and others have argued for is
a minimal MIPv6 profile where IKE is not necessary, and
perhaps other parts of IPsec aren't either. The
challenge is to define this such that not only can it
live in conjunction on the network with RFC 4877
compliant hosts, but also can be built-up with
capabilities in a well-understood way rather than by
drawing from a grab bag of options and extension headers.
It's possible that one way of building-it-up would be to
replace the minimal security mechanisms it would have
with the heavier-weight mechanisms like IKE & IPsec.
>From: mext-bounces <at> ietf.org [mailto:mext-bounces <at> ietf.org] On Behalf Of
>Davis, Terry L
>Sent: Wednesday, March 03, 2010 2:31 PM
>To: 'Ed Jankiewicz'; Basavaraj.Patil <at> nokia.com
>Cc: mext <at> ietf.org; int-area <at> ietf.org; rdroms <at> cisco.com
>Subject: Re: [MEXT] [Int-area] Rethink on Mobile IPv6
>I agree 100%! Without something that can actually interoperate "out of
>the box" with another vendor's systems, it becomes almost impossible to
>deploy in a large heterogeneous systems space where you have no control
>of the link's other end.
>At least some of us in the aviation space find ourselves in a quandary
>as we ponder how to try to implement IPSec with Mobility (or actually
>even without mobility in ground systems). Every vendor that ever made
>"one of whatever" we have in the global aviation environment to deal
>with! In some scenarios, especially for international operations in the
>future, an aircraft utilizes more than half dozen communication service
>providers and sets up links through them with a similar number of
>different air traffic control centers during a single flight. And the
>next flight is likely with at least a different set of centers.
>The CI sectors I understand are starting to see similar problems too.
>I suppose we could have managed to build in more "non"-interoperability
>into IPSec but then maybe we succeeded as the associated PKI has similar
>implementation problems between different CAs.
>I actually think the problem started with the designers assumption that
>the user controlled both ends of the link being secured. In reality
>this is becoming less and less the case as we work more and more
>sMIP6 would be a good start!
>PS: Maybe if I'd been a better/louder "hummer" simpler might have been
>> -----Original Message-----
>> From: mext-bounces <at> ietf.org [mailto:mext-bounces <at> ietf.org] On
>> Behalf Of Ed Jankiewicz
>> Sent: Wednesday, March 03, 2010 9:36 AM
>> To: Basavaraj.Patil <at> nokia.com
>> Cc: rdroms <at> cisco.com; int-area <at> ietf.org; mext <at> ietf.org
>> Subject: Re: [MEXT] [Int-area] Rethink on Mobile IPv6
>> While I support the philosophy that IPsec and IKE(v2) are the core
>> security solution for most IP layer requirements, I agree with your
>> contention that it is a heavyweight solution presenting a barrier to
>> entry for mobility devices. The only thing that keeps me
>> from agreeing
>> without reservation is that any alternative method must peacefully
>> coexist with RFC4877. In other words, it should be possible for a HA
>> and MN to detect/negotiate whether MIP6lite or RFC4877 is supported.
>> Thus it becomes a choice for the end-user: build a network with the
>> appropriate level of security (none, MIP6lite, RFC4877) by
>> selecting the
>> products that support the required level. Ideally a HA would support
>> both to accommodate both types of MNs.
>> Also, to be truly useful, MIP6lite must be simple, modular
>> and timely -
>> i.e. solve the basic problem soon with "better than nothing"
>> with the ability to be extended with more protection, perhaps
>> even up to
>> the level of RFC4877, as needed. We don't need yet another
>> long process
>> attempting to solve all the problems before anything happens, but
>> something well-defined and constrained to enable an
>> entry-level secure MIP6
>> I don't know if I have much to offer in contribution, but this is
>> something I would be interested in, and support as a reviewer as it
>> evolves. If done in a timely fashion, it would remove an obstacle to
>> the wider adoption of MIP6 with a reduced but appropriate
>> level of security.
>> Might I suggest sMIP6 (simple/secure MIP6) as a name?
>> Ed J.
>> On 3/3/2010 10:55 AM, Basavaraj.Patil <at> nokia.com wrote:
>> > Mobile IPv6 (RFC3775) has been an RFC since 2004, and Dual-stack
>> > -Basavaraj
>> > _______________________________________________
>> > Int-area mailing list
>> > Int-area <at> ietf.org
>> > https://www.ietf.org/mailman/listinfo/int-area
>> MEXT mailing list
>> MEXT <at> ietf.org