Subject: [MEXT] Rethink on Mobile IPv6

From: <[email-masked]>
Date: Wed, 3 Mar 2010 16:55:58 +0100

Mobile IPv6 (RFC3775) has been an RFC since 2004, and Dual-stack
Mobile IPv6 (RFC5555) since 2009. Implementations of the protocol has
been lacklustre to say the least. Several SDOs have considered MIP6
and DSMIP6 as a solution for interworking and mobility between
different access technologies and only 3GPP has adopted it in a very
limited manner for Rel 8 (for use on the S2c interface) with the
likelihood of it being actually deployed quite low (IMO).

While there are many reasons that can be attributed to the lack of
implementations and use, one that I would like to raise is the the
concern with the overly complex security model that MIP6/DSMIP6 relies
on today. MIP6/DSMIP6 requires IPsec and IKE/IKEv2 (RFC3776/4877) to
secure the signaling between the MN and HA. The fundamental purpose of
MIP6/DSMIP6 is to provide mobility to hosts. At a very high level the
MIP6/DSMIP6 protocol boils down to the ability to setup a tunnel
between the MN and HA and update the MN tunnel end-point whenever
there is a change in the associated IP address (CoA). The signaling to
establish the tunnel needs to be secure. But using a protocol like
IKEv2 and IPsec to achieve this security is just an overkill. It
increases the complexity of the implementation as a result of many
factors that have been captured in I-D:
draft-patil-mext-mip6issueswithipsec and discussed in the MEXT WG
meetings. 

Given the objective of the protocol is to enable IP mobility for hosts,
it should focus on doing that well in a manner that makes it easy to
implement/adopt/deploy/scale. My opinion as a result of implementation
experience is that MIP6/DSMIP6 can be significantly simplified,
especially the security architecture. The protocol as specified
currently in RFC3775/RFC5555 is a kitchensink of features. Getting back
to basics of simply establishing a tunnel between the MN and HA and
managing that tunnel is all that is needed and would potentially see
the light of day in the real world.

You may want to call it as Mobile IPv6-lite if you wish. But I do
believe that a simplification of the protocol is needed without which
I fear it will remain an academic exercise with many years spent in
developing a spec. I hope the working group and people who are
involved in mobility related work would consider undertaking such an
effort in the IETF.

-Basavaraj

---

From: [email-masked] (Arnaud Ebalard)
Date: Wed, 03 Mar 2010 18:25:39 +0100

Hi,

with some salt ...

<[email-masked]> writes:

> currently in RFC3775/RFC5555 is a kitchensink of features.

I don't think RFC 3775 is. There are some questionable features (DHAAD,
...) but it's a good document IMHO. As for RFC 5555, it inherits the
complexity of NAT traversal mechanisms. Blame NAT, not IPsec/IKE for
that.

Sure, it is always possible to reduce MIPv6 to a simple data tunnel
between a MN and a HA which needs to be updated from time to time via
some secure signaling. And then it's easy to flag IPsec/IKE use as
overkill, all the more if you include RFC 5555 in the game.

But MIPv6 is expected to provide more than that.

First, the Route Optimization is an integral part of the protocol and
IMHO, without it, MIPv6 can advantageously be replaced by some
MOBIKE-enabled IPsec VPN solution or some DTLS-based equivalent. 

Additionally, MIPv6 is probably just a milestone and the main building
block for NEMO in many scenarios: in those scenarios, the ability to
secure the data tunnel with the HA to protect traffic from MR's clients
sometimes make a lot of sense. Future aeronautical networks will have
that need, in order to provide protection of data traffic, no matter
the wireless communication link or the foreign network. IPsec/IKE is
perfect for the job.

> Getting back to basics of simply establishing a tunnel between the MN
> and HA and managing that tunnel is all that is needed and would
> potentially see the light of day in the real world.
>

Why don't you write a draft for that MIPv6-lite protocol? It seems like
the best approach to see if people are interested.

Personally, I will continue to work on finishing the integration of
IPsec/IKE and MIPv6 (for the RO part).

At some point if you write the draft, get implementations done, get
people to use your protocol, if they ask for some security for tunneled
data (let say for nemo) and secure RO (say for releasing the core of
their architecture), I suggest pointing them to MIPv6.

As a side note, I have MIPv6 and IPsec/IKE running on my Nokia N900
(Native IPv6 on 3G and Wifi) and the main problem I have with that
setup are not IPsec/IKE related: they are due to Cisco firewall in the
network which basically drop packets with RH2. If you write your
MIPv6-lite draft, I would suggest getting rid of HAO in Destopt and
RH2.

Cheers,

a+

---

From: Ed Jankiewicz <[email-masked]>
Date: Wed, 03 Mar 2010 12:36:20 -0500

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" security, 
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, [email-masked] wrote:
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area
>
>

---

From: "Davis, Terry L" <[email-masked]>
Date: Wed, 3 Mar 2010 11:31:09 -0800

Ed/Basavarai

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

sMIP6 would be a good start!

Take care
Terry

PS: Maybe if I'd been a better/louder "hummer" simpler might have been here already.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Ed Jankiewicz
> Sent: Wednesday, March 03, 2010 9:36 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [MEXT] [Int-area] Rethink on Mobile IPv6
>
> MEXT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mext
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 03 Mar 2010 21:57:26 +0200

I agree that a discovery procedure is useful BUT
>
>
> 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.
> _
>

This is not necessarily true. There no absolute need to have 
interoperability between the MN and the HA unless you want a Mobile IP 
client to work with a random HA. There are examples today where this is 
also desired but not necessary to get a huge amount of deployment, such 
as IM clients and VPNs. If you look around what different SDOs have done 
with mobile IP then you will notice that everyone came up with different 
key derivation mechanisms (some call it "bootstrapping"). This pure fact 
makes Mobile IP clients non interoperable beyond SDOs.

If you make it sufficiently easy to install the client software then an 
operator can very easily ship a client to you.

Just some random thoughts....

Ciao
Hannes

---

From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" <[email-masked]>
Date: Wed, 3 Mar 2010 14:02:29 -0600

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

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.

--
Wes Eddy
MTI Systems

>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>Davis, Terry L
>Sent: Wednesday, March 03, 2010 2:31 PM
>To: 'Ed Jankiewicz'; [email-masked]
>Cc: [email-masked]; [email-masked]; [email-masked]
>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.
>
>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
>globally.
>

---

From: Wassim Haddad <[email-masked]>
Date: Wed, 3 Mar 2010 15:30:31 -0500

Hi Raj, 

Mobile IPv6 (RFC3775) has been an RFC since 2004, and Dual-stack Mobile IPv6
(RFC5555) since 2009. Implementations of the protocol has been lacklustre to
say the least. Several SDOs have considered MIP6 and DSMIP6 as a solution
for interworking and mobility between different access technologies and only
3GPP has adopted it in a very limited manner for Rel 8 (for use on the S2c
interface) with the likelihood of it being actually deployed quite low
(IMO).

While there are many reasons that can be attributed to the lack of
implementations and use, one that I would like to raise is the the concern
with the overly complex security model that MIP6/DSMIP6 relies on today.
MIP6/DSMIP6 requires IPsec and IKE/IKEv2 (RFC3776/4877) to secure the
signaling between the MN and HA. The fundamental purpose of
MIP6/DSMIP6 is to provide mobility to hosts. At a very high level the
MIP6/DSMIP6 protocol boils down to the ability to setup a tunnel between the
MN and HA and update the MN tunnel end-point whenever there is a change in
the associated IP address (CoA). The signaling to establish the tunnel needs
to be secure. But using a protocol like
IKEv2 and IPsec to achieve this security is just an overkill. It increases
the complexity of the implementation as a result of many factors that have
been captured in I-D:
draft-patil-mext-mip6issueswithipsec and discussed in the MEXT WG meetings. 

Given the objective of the protocol is to enable IP mobility for hosts, it
should focus on doing that well in a manner that makes it easy to
implement/adopt/deploy/scale. My opinion as a result of implementation
experience is that MIP6/DSMIP6 can be significantly simplified, especially
the security architecture. The protocol as specified currently in
RFC3775/RFC5555 is a kitchensink of features. Getting back to basics of
simply establishing a tunnel between the MN and HA and managing that tunnel
is all that is needed and would potentially see the light of day in the real
world.

=> Does this mean that you want also to take out the RO mode or you want to
simplify it?

Wassim H.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 03 Mar 2010 12:50:39 -0800

Hello Basavaraj,

I also think we need to do some rethinking.

To be brief:
- I think we need to allow network operators to
   utilize security mechanisms they deem appropriate,
   whether or not standardized by the IETF.

- I think we need to allow network operators to
   utilize tunneling mechanisms they deem appropriate,
   whether or not standardized by the IETF.

I'm happy to break down the specification
into components (such as route optimization, etc.).
I'll even volunteer to hack the text.  But I do
not think this is a major stumbling block.
After all, the mobile node is the one initiating
route optimization.  If the home agent does not
support it, there is no route optimization --
in other words, this function is trivially
controllable by operators.

I'm concerned because I know that Mobile IP
offers very high-performance mobility management
and session persistence -- yet, in one SDO
after another we see suboptimal, slow signaling
for clunky interworking schemes that don't even
support VoIP very well.

Something is wrong.  I have a hard time believing
that the operators insist that their customers
cannot have the best available.  It's much more likely
that they don't see a comfortable evolutionary
path because of the limited security and tunneling
options available with RFC 3775.

Regards,
Charlie P.

---

From: Wassim Haddad <[email-masked]>
Date: Wed, 3 Mar 2010 16:51:39 -0500

Hi Charles,

To be brief:

I'm happy to break down the specification into components (such as route
optimization, etc.).
I'll even volunteer to hack the text.  But I do not think this is a major
stumbling block.
After all, the mobile node is the one initiating route optimization.  If the
home agent does not support it, there is no route optimization -- in other
words, this function is trivially controllable by operators.

=> IMHO, it also makes (much) sense to simplify the RO mode and not just
split it.

Regards,

Wassim H.

On 3/3/2010 7:55 AM, [email-masked] wrote:
> Given the objective of the protocol is to enable IP mobility for 
> hosts, it should focus on doing that well in a manner that makes it 
> easy to implement/adopt/deploy/scale. My opinion as a result of 
> implementation experience is that MIP6/DSMIP6 can be significantly 
> simplified, especially the security architecture. The protocol as 
> specified currently in RFC3775/RFC5555 is a kitchensink of features.

---

From: <[email-masked]>
Date: Thu, 4 Mar 2010 01:24:23 +0100

Wassim,

> => Does this mean that you want also to take out the RO mode or you want to

The basic Mobile IPv6 protocol as I mentioned is about establishing a tunnel
between the MN and HA and updating the binding when the tunnel end-point on
the MN changes. Period.
If we start including everyones favorite features, then we end up with the
same status quo. 

Enhanced features like RO etc. can be specified separately. But basic MIP6
implementations and operations should not require it.

-Raj

---

From: Hesham Soliman <[email-masked]>
Date: Thu, 04 Mar 2010 13:25:48 +1100

Hi Raj, 

A couple of thoughts.
First, you've redefined the purpose of MIPv6 to be about setting up a tunnel
between the MN and the HA. Whether this is correct or not, it's worth noting
that your basis for such definition is unknown. It certainly doesn't match
our reference for MIPv6 (RFC 3775).

Regarding the complexity of DSMIPv6. Arnaud is 100% right in his response
and this was discussed on the mext list more times than I can remember. The
complexity is due to NAT traversal. Yes, we could have reduced the
complexity if we relied on MIP-only traversal techniques instead of having
both MIP and IPsec traversal run simultaneously, but what is the other
alternative for negotiating a security association behind a NAT?
The problem *is* NAT. I'm afraid that once you plant the seeds of hackiness
(if that's a word) by using NATs you have to harvest the output at some
point. There is no free lunch when you have a deployed base of 2 billion
users. 

I continued to suggest (for about 6 years now) that we use CGAs for MIPv6.
It's by far the cleanest solution we have. My best description to the
resistance of adopting CGAs is: Politics. There is no technical reason for
not using them and we all know that. So if you want to come up with
alternatives, you'd be doing the community a disservice if you don't
seriously consider CGAs. In fact, I'd go further and say you need to explain
why not. We've already seen what happens when we produce half cooked
security proposals tailored to a specific SDO's needs (read: RFC 4285).

I look forward to the continuation of these discussions.

Hesham

---

From: Xiangsong Cui <[email-masked]>
Date: Thu, 04 Mar 2010 10:30:16 +0800

Dear Raj,

I support the simplified mobile IPv6, but I would like to see it as an Informational, or Experimental document.
So the relation between sMIP6 and MIP6 may also be simplified, imho.

Regards
Xiangsong

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 03 Mar 2010 22:58:28 -0800

Raj:

I agree with your point that IPsec support is one of the complex areas of
the Mobile IPv6 protocol definition. Lack of standardized interfaces to
IPsec module, the needed interactions between Mobile IPv6 and Ipsec modules,
never made the protocol an easy implementation. And the recent new
extension, Dual-stack Mobile IPv6 support, surely took the complexity to a
new level. Not to trivialize the efforts, the solution under the given
constraints is probably the best chosen approach. We can blame NAT Traversal
support, or may be its the nature of the requirement, but the resulting
protocol is an implementation nightmare and we cannot deny that.

However, I'm not sure if this is the sole reason for the lack of protocol
adoption. As I see it the issues are multifold.

1. We have not realized that the protocols we develop at IETF have zero
value, if the approaches are not aligned with the SDO interests and if there
is no adoption of those protocols.

2. We do not respond to the SDO needs in a time bound manner. We are taking
years to standardize and deliver a feature, and in the process we are
hurting the protocol adoption. Looking at NETEXT WG, after two years of
debate, we barely made any progress, leaving the 3GPP group confused, as
when the IETF will provide the needed solutions.

Bottom line, I agree with your argument principle, that if the SDO groups
have a true need for alternative security approaches, we need to realize
that and provide the needed solutions, and in a time bound manner. And if
that is indeed the issue. I do realize that there are some elements in the
protocol that are surely adding to the protocol complexity and we should
make efforts to simplify it. And above all, we need to make sure the design
approaches are aligned with the SDO interests, IMO, that is probably the
bigger issue.

Regards
Sri

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 4 Mar 2010 12:45:06 +0200

> We've already seen what happens when we produce half cooked

What are the issues with RFC 4285? Is it written somewhere, or can someone
summarize please?

I agree with IKE/IPsec being an overkill for MIPv6.
RFC 4285 addresses that.
WiMAX architecture already uses it.

The missing piece in IETF world for RFC 4285 is the bootstrapping of keys.
WiMAX architecture handles this its own way. We could be talking about a
generic solution to that in IETF.

Alper

---

From: Tony Whyman <[email-masked]>
Date: Thu, 04 Mar 2010 15:58:44 +0000

Terry,

Is one standard ever enough to achieve "out of the box" multi-vendor 
interoperability, no matter how well written (or lightweight) it is? We 
have a working ATC Data Link System today, but the ATN Technical Manual 
alone has about 13 pages of references to other (included) standards, 
add to that VDL2 and its references - and then you the interop standards 
(ED-110B), safety (ED-120) - and even that is not enough: the LINK2000+ 
baseline also includes agreed defect resolutions that have not yet made 
it into the base standards. Achieving interoperability has much in 
common with "herding cats".

You only have multi-vendor ATN interoperability today because there is a 
strong centre, a co-ordinating group with all the vendors participating, 
and a test centre at Bretigny checking out the products and rigorously 
policing interoperability. Having good quality or even simple base 
standards helps, but is far some being a sufficient condition for 
interoperability.

When the industry moves from the current ATN/OSI to ATN/IPS, end-to-end 
security is going to be a given and that almost certainly means tackling 
the implementation of IPsec and ensuring multi-vendor IPsec 
interoperability. I know that IPsec works well in a single vendor 
scenario - download Ubuntu Linux, add in the "racoon" and "ipsec-utils" 
packages and it is then only a matter of setting up the configuration 
file - been there done that. However, I don't pretend that it won't be a 
technical challenge translating that experience into multi-vendor IPsec 
as part of a much larger system - on the other hand, that is what we are 
paid to do - and something like the LINK2000+ approach will probably be 
needed to achieve it.

You also mention the PKI. As we have discussed before, that will 
probably be the most challenging part of achieving global 
interoperability in the context of end-to-end communications. However, 
this is not really an IPsec dependency. No matter how you implement 
end-to-end security, there will always be a need to establish and 
maintain trust relationships. The problem will not go away simply by 
choosing a different approach to end-to-end security.

I would also observe that in all the applications that I have studied, 
it is the aircraft that makes first contact. The aviation mobility 
requirement is for seamless movement between different air/ground 
networks, rather than for the ground to initiate contact with the 
aircraft wherever it might be.

In IPsec, moving a tunnel end-point between IP Addresses is fairly 
straightforward and with ike2/Mobike, very efficient. If you accept that 
IPsec is necessary to meet the end-to-end security requirement then it 
is, I believe, also sufficient to meet the aviation mobility requirement 
for seamless make before break movement. Hence why I don't really see a 
role for Mobile IP, as it stands today, in the ATN/IPS - especially as 
it introduces additional ownership, reliability, regulatory and 
certification issues with the Home Agent.

If a requirement did emerge for the ground being able to contact the 
aircraft before the aircraft had itself made contact, then I would 
expect that Mobile IP would only be used to establish first contact. 
Once the IKE exchange had taken place end-to-end, the aircraft would 
then handoff the tunnel to its care of address, using MOBIKE, achieving 
both route optimisation and taking the Home Agent out of the loop for 
the rest of the dialog - and thereby avoiding the issues associated with it.

Now, the original post was lamenting the low take up of Mobile IP and 
perhaps the above is indicating why. I would argue that efficient and 
seamless (make before break) movement of a mobile node between care of 
addresses is a much more common requirement than for a mobile node to be 
globally contactable (i.e. taking on a server role). However, Mobile IP 
focuses on the latter and forces the overhead and cost of the Home Agent 
on those that simply require seamless movement during communication. It 
is a heavyweight approach for a simple requirement and it is perhaps not 
surprising that users either make do with "break before make" or find an 
alternative approach.

My criticism of Mobile IP is thus focused on Route Optimisation, in that 
it depends upon the use of the Home Agent rather than being standalone.

If there is work to be done on a lightweight Mobile IP then I would 
focus on providing a lightweight (no Home Agent) approach to seamless 
movement between care of addresses, which can then be extended into a 
full blown Mobile IP (Home Agents et al) for those that need it. Such a 
lightweight approach could be very interesting to the ATN/IPS as it has 
the potential to avoid the tunnelling overhead that comes with IPsec.

On the other hand, would a simpler relationship between the Mobile Node 
and Home Agent make a difference? To me the answer is no. This is not 
the issue. The problem is having to deploy a Home Agent in the first place.

Regards

Tony Whyman

Davis, Terry L wrote:
> 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.
>
> 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 globally.
>
> ------------------------------------------------------------------------
>

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 4 Mar 2010 09:45:24 -0800 (PST)

Hi Raj,

  I agree that basic MIP6 should not have RO feature, just like PMIPv6.

I think in basic MIP6 we should define an IP entity close to MN, like AR.

Again like PMIPv6.

Regards,

Behcet

----- Original Message ----
> From: "[email-masked]" <[email-masked]>
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> Sent: Wed, March 3, 2010 6:24:23 PM
> Subject: Re: [Int-area] [MEXT] Rethink on Mobile IPv6
> 
> 
Wassim,

On 3/3/10 2:30 PM, "ext Wassim Haddad" <> ymailto="mailto:[email-masked]" 
> href="mailto:[email-masked]">[email-masked]> 
> wrote:

> => Does this mean that you want also to take out the 

The basic Mobile IPv6 
> protocol as I mentioned is about establishing a tunnel
between the MN and HA 
> and updating the binding when the tunnel end-point on
the MN changes. 
> Period.
If we start including everyones favorite features, then we end up 
> with the
same status quo. 

Enhanced features like RO etc. can be 
> specified separately. But basic MIP6
implementations and operations should 
> not require it.

-Raj

> Wassim 
> H.

Int-area mailing 
> list
> href="mailto:[email-masked]">[email-masked]
> href="https://www.ietf.org/mailman/listinfo/int-area"; target=_blank

---

From: Wassim Haddad <[email-masked]>
Date: Thu, 4 Mar 2010 12:48:35 -0500

Hi Behcet, 

=> What would be the real difference with PMIPv6 in this case?

Regards,

Wassim H.

----- Original Message ----
Wassim,

On 3/3/10 2:30 PM, "ext Wassim Haddad" <>
ymailto="mailto:[email-masked]" 

The basic Mobile IPv6 
between the MN and HA 
the MN changes. 
same status quo. 

-Raj

---

From: Ahmad Muhanna <[email-masked]>
Date: Thu, 4 Mar 2010 12:56:27 -0500

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Behcet Sarikaya

Hi Raj,

I think in basic MIP6 we should define an IP entity close to MN, like AR.
[Ahmad]
Hi Behcet,
May be we can reuse MIP4 signaling and save ourselves a lot of efforts and time:-)

Regards,
Ahmad

Again like PMIPv6.

Regards,

Behcet

----- Original Message ----
Wassim,

The basic Mobile IPv6 
between the MN and HA 
the MN changes. 
same status quo. 

-Raj

---

From: "Devarapalli, Vijay" <[email-masked]>
Date: Thu, 4 Mar 2010 15:26:53 -0600

Anybody for transporting EAP over MIPv6 messages? We could define a new EAP
transport mobility header message and use a key from the EAP exchange with
the MN-HA authentication option. :)

On 3/3/10 7:55 AM, "[email-masked]" <[email-masked]>
wrote:

> IKEv2 and IPsec to achieve this security is just an overkill.

Well, it has its advantages too. Being able to connect to the home agent
from an unsecure WiFi access is one of them.

Vijay

---

From: <[email-masked]>
Date: Thu, 4 Mar 2010 22:58:21 +0100

Hi Hesham,

> our reference for MIPv6 (RFC 3775).

As I wrote, the very basic functionality of MIP6 is to establish the tunnel
and then manage the end-point change. This is my PoV. But maybe you see it
differently. 

> alternative for negotiating a security association behind a NAT?

I am not disagreeing that part of the complexity results from the presence
of a NAT and having to develop means to traverse the NAT.
I am of the view that the use of IPsec and IKEv,v2 in conjunction with
Mobile IPv6 is complex. There is really no good reason to bind MIP6 with
Ipsec and IKE. This is a legacy decision and one that is just proving to be
plain wrong. An IPsec SA between the MN and HA is not required for enabling
IP mobility. We overcome the NAT related complexities by dropping the
reliance on Ipsec/IKE. The security model for MIP6 is a relic that needs to
be revisited for simplification of the protocol itself.

> point. There is no free lunch when you have a deployed base of 2 billion

Deployed base of 2 billion users??? You mean behind a NAT? But none of them
will ever use MIP6/DSMIP6 (IMO at least) if we have to employ the hackiness
of traversing NATs. Obviously NATs are not going away for sure and we will
probably have other variants as well in the future (NAT64s and NAT464s
etc.). We do not have as much of an issue with the NATs if we don't have to
rely on Ipsec/IKE,v2.

> seriously consider CGAs.

I think we should consider all alternatives. I don't know if you have
proposed how CGAs could be used in the context of MIP6 security. I am more
than happy to build a MIP6 protocol that uses CGAs if such an approach would
reduce the complexity.

> In fact, I'd go further and say you need to explain
> why not. 

I don't need to explain because I am quite happy to consider the CGA
proposal. 

> security proposals tailored to a specific SDO's needs (read: RFC 4285).

4285 IMO is quite okay in certain deployments. If the network in which you
deploy MIP6 already has a means to securely exchange keys (eg. 3GPP/2, WiMAX
networks) then you could very well use RFC4285. Why would you need to
establish an IPsec SA using IKE/v2 between the MN and HA in such networks?
Just does not make sense. And FWIW, I am not raising the topic of
simplifying MIP6/DSMIP6 with a specific solution in mind. But rather from
the perspective that we need to revisit the protocol and simplify it to meet
the basic mobility needs first.

> I look forward to the continuation of these discussions.

Sure. 

-Raj

---

From: <[email-masked]>
Date: Thu, 4 Mar 2010 23:07:33 +0100

Vijay,

> the MN-HA authentication option. :)

If you go down the path of attempting to define MIP6 as a transport for EAP
messages, you will face the question of why not use PANA instead? Hence I do
not want to even broach this subject or suggest such an approach.

IMO it is better to separate the user authentication and key exchange from
the MIP6 signaling itself. As long as the MN and HA are able to obtain
session keys securely, MIP6 signaling can be secured with the same.

-Raj

---

From: <[email-masked]>
Date: Thu, 4 Mar 2010 23:28:39 +0100

Inline:

> complexity of NAT traversal mechanisms. Blame NAT, not IPsec/IKE for

RFC3775 is indeed a good document given the amount of time and effort
invested in it (6+ years). While NAT does indeed add further complexity in
the case of RFC5555, the dependency of MIP6 on IPsec/IKEv2 is also
unwarranted. 

> some secure signaling.

At least there is a far better likelihood that it would at least get
implemented and used with a simpler approach.

> And then it's easy to flag IPsec/IKE use as

I am going to stick by my view that Ipsec/IKE is an overkill for the purpose
of IP mobility. 

> MOBIKE-enabled IPsec VPN solution or some DTLS-based equivalent.

RO AFAICT is not even a consideration for many deployments. The industry
will decide if Mobike or MIP6 or something else will meet the requirements.
Building all kinds of fancy features simply to bolster the case for MIP6 is
not going to help. In fact it will do the exact opposite.
And RO can be specified as a plugin (if you will) for those deployments that
care about it. But it does not have to be a fundamental part of the basic
protocol. 

> the wireless communication link or the foreign network. IPsec/IKE is

The use of IPsec/IKE comes at a cost. Lets see what the requirements for
these aeronautical networks are and whether they can be met via
non-IPsec/IKE security. Imagining all kinds of requirements that may exist
in the future will result in building a protocol that does not meet the
basic needs. You could just as well build a protocol that is simple to begin
with and then add the extensions for those deployments which have specific
needs. 

> the best approach to see if people are interested.

Yes. Something to do.
 
> IPsec/IKE and MIPv6 (for the RO part).

We did this for DSMIP6 (without RO). And understand the complexity involved.
 
> their architecture), I suggest pointing them to MIPv6.

They should be able to tell from such a spec about RFC3775 and the extensive
feature set and capabilities.

> MIPv6-lite draft, I would suggest getting rid of HAO in Destopt and

Thanks for the suggestion.
We will have DSMIP6 (with security based on draft-korhonen-mext-mip6-altsec)
on the N900 sometime in the next few months. And possibly even an HA that is
accessible hosted by us for interop and testing.

-Raj

---

From: "Devarapalli, Vijay" <[email-masked]>
Date: Thu, 4 Mar 2010 17:16:02 -0600

Hi Raj,

> not want to even broach this subject or suggest such an approach.

Why would you want to tie MIPv6 to PANA? I thought you wanted MIPv6lite. :)

Running EAP directly over Mobility header messages allows you use to
SIM/AKA/AKA' to setup the MN-HA key. If you have a pre-shared MN-HA key,
then you directly send a BU with the authentication option. No EAP exchange.
Call this "MIPv6 with pre-shared key mode", if you want.

> session keys securely, MIP6 signaling can be secured with the same.

Sure, if you have a deployment specific mechanism for deriving the MN-HA
key, you run MIPv6 with pre-shared key mode (send a BU with the
authentication option).

Vijay

---

From: Junghoon Jee <[email-masked]>
Date: Fri, 5 Mar 2010 08:33:37 +0900

Hi Raj,

I completely agree with you.
We really need to do something valuable under concerning real world deployment

BR,
Junghoon

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 4 Mar 2010 15:51:49 -0800

Hi Tony,

You bring up good points, and I do think there is reason
to consider alternatives such as Mobike. You also mentioned
end-to-end security, which I agree with and makes me wonder
whether mobility management really requires things like
tunnel-mode IPsec in the network. In particular, if there
is some way to authenticate the mobility events within the
network without using IPsec (perhaps using an asymmetric
signed certificate on a mobility indicator), and also to
prevent off-path DOS attacks, then the end-to-end security
can ride over the otherwise unsecured network.

IRON (draft-templin-iron) and RANGER (RFC5720) provide
just such an approach. Together, IRON/RANGER support
mobility and route optimization without causing a ripple
effect in BGP routing tables. Mobility and multihoming
events are therefore made visible only within the FIBs
of those specific routers that need to know about it,
and the interdomain RIB is not disturbed. IRON/RANGER
concerns itself with site mobility and multihoming, while
fast-moving end systems in this model would use an adjunct
mechanism such as HIP as they move between sites. HIP
coincidentally provides the end-to-end securing
capabilities we talked about earlier.

RANGER (RFC5720) and now RANGERS (draft-russert-rangers)
examine the sorts of use cases which I think may be of
interest to you.

Thanks - Fred
[email-masked]  

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Tony Whyman
> Sent: Thursday, March 04, 2010 7:59 AM
> To: Davis, Terry L

---

From: Hesham Soliman <[email-masked]>
Date: Fri, 05 Mar 2010 11:59:42 +1100

> and then manage the end-point change. This is my PoV. But maybe you see it

=> I know, I wanted to point out that this is one PoV and not an agreed upon
definition. There are people on the list who might not know that.

> be revisited for simplification of the protocol itself.

=> Removing IKEv2 will not remove the NAT issues and depending on what you
will replace it with, it might make it worse. The problem here is not in the
name of the technology, it's what it does. I'm very open to listening to new
ideas on how to simplify things, but what I don't accept is to define the
goal to "remove IPsec and IKEv2". That's not a goal. IKE provides a way of
negotiating an SA, IPsec applies those credentials to securing packets. Now,
these are the two basic functions required to secure a connection. Do you
want to replace them because they're badly designed? Or because you believe
we don't need one of those functions? I'm sure it's the former not the
latter. So it's the former, let's see something that it better designed and
see how it works under the same conditions.
The whole idea of interoperability being an issue is a non-starter for me
because it's not technology-specific, so solving it by designing a new
protocol seems ...counter-productive.

> etc.). We do not have as much of an issue with the NATs if we don't have to

=> I wish it was so easy. You're assuming that if we remove IKE/IPsec NAT
will not be causing problems? I think there are problems with NATs
regardless. These are not technology specific problems, they're fundamental
problems because of how a NAT works.

> than happy to build a MIP6 protocol that uses CGAs if such an approach would

=> Great. I still don't know if it will be an improvement over IKEv2 in
terms of this discussion, but I'm glad you're open to all approaches. Of
course, whatever we do, there will always be the challenge of setting a
default mechanism, and potentially negotiating the security mechanism.

> establish an IPsec SA using IKE/v2 between the MN and HA in such networks?

=> I think this shows that we still need to get to the bottom of what you
think is wrong with IPsec. 4285 replaces the IPsec authentication with a
"different" header. That's all it does. IMO that's completely useless and
the only reason I could see people doing that is some kind of ideology or
allergy against the word IPsec. 4285 is exactly the same as using IPsec AH
with pre-shared keys. Except, it's designed in a terrible way whose flaws
were discussed on the mailing list for a long time.
I don't think we need to design a new Authentication header, we already have
one that can be used without IKE.

Hesham

---

From: Jean-Michel Combes <[email-masked]>
Date: Fri, 5 Mar 2010 02:20:48 +0100

Hi Raj,

[company hat on]
1. On one side, you _never_ reply to technical questions (cf.
http://www.ietf.org/mail-archive/web/mext/current/msg03594.html) about
your issues regarding MIPv6/IPsec interactions.
2. OTOH, MIPv6 open-source implementations work with IPsec/IKE.

Conclusion: Have I recommend to chose open-source implementations
rather than your company's implementation? :)
[company hat off]

Best regards.

JMC.

---

From: Hesham Soliman <[email-masked]>
Date: Fri, 05 Mar 2010 12:52:23 +1100

Hi Raj,

> session keys securely, MIP6 signaling can be secured with the same.

=> This is quite confused. Device authentication and SA negotiation is most
separated today from MIPv6 signalling as it is done with other protocols and
is least separated with 4285, which piggybacks it on MIPv6 signalling. If
you're for separation then your support for 4285-like mechanisms confuses
me. Your statement above is a justification for the exact opposite of what
you're asking us to consider.

Hesham

---

From: <[email-masked]>
Date: Fri, 5 Mar 2010 05:42:53 +0100

Vijay,

> Why would you want to tie MIPv6 to PANA? I thought you wanted MIPv6lite. :)

I don't. That's what I said when suggesting not going down that path. And
yes MIP6-lite is the end goal.

> Call this "MIPv6 with pre-shared key mode", if you want.

We are getting into the design of a solution now. This can be discussed
separately once we get the effort to do it started.

> key, you run MIPv6 with pre-shared key mode (send a BU with the

Yes. 

-Raj

---

From: [email-masked] (Arnaud Ebalard)
Date: Fri, 05 Mar 2010 08:45:01 +0100

Hi,

<[email-masked]> writes:

> We are getting into the design of a solution now. 

Are we?

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 05 Mar 2010 11:37:55 +0100

>> We are getting into the design of a solution now.

YEs, and methinks the lightest of the MIP-lite solutions is:

"MN" uses IPv4 and a modified DHCP which does not remove the previously
assigned address (the "HoA").  "HA" runs a daemon listening for
LightestMIP requests sent by "MN" with the "CoA" and the "HoA".  "HA"
and "MN" use iptables scripts to add/remove routes and encapsulation.

This is as simple as it can get and still offer session continuity
(or "persistence") and reachability (inexistent word) at a permanent HoA.

Any simpler?

Do we modify the requirements? modify or not the MN, permanent home
address or not, session continuity or not, modify apps or not.

Alex

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

---

From: Hesham Soliman <[email-masked]>
Date: Sat, 06 Mar 2010 00:50:32 +1100

> it depends upon the use of the Home Agent rather than being standalone.

=> Correction, RO doesn't actually depend on the home agent. It involves
packets being sent *through* the home agent but the home agent doesn't get
actively involved in anything. Any packet addressed to the mobile node's
home address will go through the HA. So, perhaps your criticism is that MIP
in general uses the HA.

Hesham

---

From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" <[email-masked]>
Date: Fri, 5 Mar 2010 08:28:42 -0600

>Hesham Soliman
>Sent: Friday, March 05, 2010 8:51 AM
>To: Tony Whyman; Davis, Terry L

Right; and I've never understood why the HA is of such
concern since when VPN solutions are proposed people
don't seem to treat the VPN gateway with similar disdain.
It's just as fragile of a single point of failure, as
VPN gateway redundancy and failover solutions are dismal.
VPN is even worse if you analyze it from the fact that
with MIP using RO, the HA isn't even needed for the vast
majority of packets once initialized (only as an
indirection point for new connections to find the MN) and
RO flows survive for some time after the loss of an HA,
but when using VPN all packets flow through the gateway
and any loss completely breaks communication.

--
Wes Eddy
MTI Systems

---

From: Tony Whyman <[email-masked]>
Date: Fri, 05 Mar 2010 15:03:49 +0000

Hesham,

You are correct in assuming that my criticism is that RO involves 
packets being sent via the Home Agent i.e. that a Home Agent is required 
in order to be mobile.

My argument is that there is a class of applications out there that 
would benefit from seamless mobility but do not need to be on a well 
known IP Address. For these applications, the overhead of a Home Agent 
is not justifiable. My view is that the Home Agent should only be 
required when:

1. Seamless mobility is required even when the correspondent node is not 
"mobile aware", and/or when

2. The Mobile Node needs to be contactable on a well known IP address.

In the long term it seems reasonable to assume that most correspondent 
nodes will be mobile aware and hence Mobile IP should have an objective 
that in the long term a Home Agent is only required when the Mobile Node 
needs to be contactable on a well known IP address. As this is not a 
requirement for perhaps the majority of mobile users, there could be 
real benefits in achieving such an objective.

I could also add that RO via the Home Agent is unnecessarily inefficient 
and unnecessarily demands that the Home Agent is available every time 
the care-of-address is changed. When end-to-end IPsec is also required, 
it really does get far too complicated.

My idea is a relatively simple use of Diffie-Hellman to set up a shared 
secret which can be used to support a secure change of the 
care-of-address without reference to or use of a Home Agent. For example,

1. The first time a MN is in contact with a CN, it includes an extra 
"skip over" IPv6 Destination Options Header that includes its part of a 
Diffie-Hellman exchange and a proposed SPI.

2. If the CN ignores this then RO is not possible and the MN has to 
suffer the consequences. However, if the MN does support this then it 
similarly returns its part of the Diffie-Hellman exchange and its SPI. 
Both sides can now generate a shared secret.

3. When and if the MN changes its care-of-address, it includes another 
Destination Options Header that includes the agreed SPIs and an HMAC 
generated from the shared secret and over the whole packet including the 
source IP Address. The CN recognises this header, uses the SPIs to 
relate it to the earlier exchange and validates the HMAC and thus gains 
a proof that the packet has come from the same system but from a 
different care-of-address. It returns an acknowledgement as another 
Destination Options Header again with an HMAC. Internally, in the CN, 
the new care-of-address is translated into the original IP Address so 
that applications are unaware of the change of address for both incoming 
and outgoing traffic.

4. In practice, there will have to be a time limit on the address 
translation and hence the procedure must be regularly repeated.

Now there is no authentication here and hence no PKI, etc. The only 
proof offered is that MN on a new care-of-address is the same system as 
was on the original IP address. There is also no limit on the number of 
times it can move. Effectively, it is a form of NAT managed by the MN, 
and performed on the CN.

This type of RO can work standalone or with a Home Agent. If the MN 
connects through a Home Agent then it can still be mobile even when the 
CN does not support this RO. On the other hand, if the CN does support 
it, then the MN can use this procedure to immediately handoff to its 
care-of-address. The Home Agent is thus only involved during the initial 
phase of communication.

The scheme should also work well with IPsec when it reduces to a simple 
means of switching the tunnel end-point on movement between 
care-of-addresses.

Anyway, I'll be interested to see what flaws people can see in this.

Regards

Tony Whyman

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 05 Mar 2010 16:13:54 +0100

With respect to the deployment of Mobile IPv6.

I just wanted to add to this thread the fact that a "Mobile IPv6
(EXPERIMENTAL)" button exists since some time now in the main linux
kernel.  This is a great achievement for the Mobile IPv6 community, I think.

Alex

Le 03/03/2010 16:55, [email-masked] a écrit :
> Mobile IPv6 (RFC5555) since 2009. Implementations of the protocol
> has been lacklustre to say the least. Several SDOs have considered
> MIP6 and DSMIP6 as a solution for interworking and mobility between
> concern with the overly complex security model that MIP6/DSMIP6
> relies on today. MIP6/DSMIP6 requires IPsec and IKE/IKEv2
> (RFC3776/4877) to secure the signaling between the MN and HA. The
> fundamental purpose of MIP6/DSMIP6 is to provide mobility to hosts.
> At a very high level the MIP6/DSMIP6 protocol boils down to the
> ability to setup a tunnel between the MN and HA and update the MN
> tunnel end-point whenever there is a change in the associated IP
> address (CoA). The signaling to establish the tunnel needs to be
> secure. But using a protocol like IKEv2 and IPsec to achieve this
> security is just an overkill. It increases the complexity of the
> implementation as a result of many factors that have been captured in
> I-D: draft-patil-mext-mip6issueswithipsec and discussed in the MEXT
> WG meetings.
>
>  Getting back to basics of simply establishing a tunnel between the
> MN and HA and managing that tunnel is all that is needed and would
> believe that a simplification of the protocol is needed without
> which I fear it will remain an academic exercise with many years
> spent in developing a spec. I hope the working group and people who
> are involved in mobility related work would consider undertaking such
> an effort in the IETF.
>
> -Basavaraj
>

---

From: Hesham Soliman <[email-masked]>
Date: Sat, 06 Mar 2010 02:24:18 +1100

> 2. The Mobile Node needs to be contactable on a well known IP address.

=> I don't disagree with the scenario. The question to ask is whether those
application are being hurt with the presence of a "permanent" address? They
would still work right?
I think the issue with the home agent is that it actually delays the
deployment of MIP in general because of it's reliance on infrastructure. I
think that's a better argument for not having an HA. Unfortunately (or
fortunately) this would require a new protocol. shim6 might be interesting
in that regard. Although, if you want to handle frequent mobility then you
will need infrastructure support.

> real benefits in achieving such an objective.

=> That would be nice. If MIP is used in the long term then I think the way
to go is to have a secure (better than the current mechanism) RO mechanism
that reduces the reliance on the HA significantly. But I think as long as
we're talking about MIP, we are still stuck with the HA.
Pekka Nikander proposed homeless MIP nearly 10 years ago, but we couldn't
make it work at the time, perhaps it's something to try again.

> it really does get far too complicated.

=> The first part of your statement can be dealt with if you use a better RO
method, it's certainly doable without any problems. IPsec is not needed e2e
between the MN and the CN.

> translation and hence the procedure must be regularly repeated.

=> Without getting into too much detail, it sounds like another take on
shim6 using DH instead of hash-based addresses or CGAs.

> Anyway, I'll be interested to see what flaws people can see in this.

=> Have you considered shim6?

Thanks,
Hesham

---

From: Pekka Savola <[email-masked]>
Date: Fri, 5 Mar 2010 16:12:55 +0200 (EET)

> potentially see the light of day in the real world.

There appear be different opinions on RO requirement.

Once you discard it, you get pretty close to a VPN solution. VPNs use 
secure mechanisms (IPsec etc.) for updates and packets.  In the mobile 
general case (WLAN etc.) this seems warranted and a strict 
requirement.  You may have special deployments (e.g. cellular) in mind 
where you ensure the integrity and confidentiality (to some degree) 
via some other means.  So I suppose a mechanism would need to have a 
mandatory secure mechanism.

Apart from that the main difference between VPN and MIP technologies 
appears to be the update mechanism (how often, how quick).

I wonder if this has been analyzed in more detail. I suppose so. I'd 
be interested especially in hearing a "VPN binding update" comparison.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 05 Mar 2010 16:54:38 +0100

Le 05/03/2010 16:24, Hesham Soliman a écrit :
>
>
>
> On 6/03/10 2:03 AM, "Tony Whyman"<[email-masked]>
> wrote:
>
>> Hesham,
>>
>> packets being sent via the Home Agent i.e. that a Home Agent is
>> required in order to be mobile.
>>
>> My argument is that there is a class of applications out there
>> that would benefit from seamless mobility but do not need to be on
>> a well known IP Address. For these applications, the overhead of a
>> Home Agent is not justifiable. My view is that the Home Agent
>> should only be required when:
>>
>> 1. Seamless mobility is required even when the correspondent node
>> is not "mobile aware", and/or when
>>
> =>  I don't disagree with the scenario. The question to ask is
> whether those application are being hurt with the presence of a
> "permanent" address? They would still work right? I think the issue
> with the home agent is that it actually delays the deployment of MIP
> in general because of it's reliance on infrastructure. I think that's
> a better argument for not having an HA. Unfortunately (or
> fortunately) this would require a new protocol. shim6 might be
> interesting in that regard. Although, if you want to handle frequent
> mobility then you will need infrastructure support.

I believe this is right... any existing protocol dealing with IP
"mobility" either modifies both MN and CN or relies on the presence of a
gateway.  MIP, MIP RO, SHIM6, Mobike, LISP all are so.

"Mobility" is not the only requirement which does so, most other
protocols do too.  Except that many are in widespread use whereas MIP is
not.

I believe it's wrong to go on rethinking a protocol yet continue to
consciously ignore the problem we have right at hand.  What is the
problem at hand?

I don't want to solve the Mobile IPv6 problem as yet another
intellectual exercice based on much speculation, I want to solve
problems arising in the deployed Internet.

I can't imagine forming a WG based only on the problem of Mobile IP not
being deployed.

Alex

>
>>
>> In the long term it seems reasonable to assume that most
>> correspondent nodes will be mobile aware and hence Mobile IP should
>> have an objective that in the long term a Home Agent is only
>> required when the Mobile Node needs to be contactable on a well
>> known IP address. As this is not a requirement for perhaps the
>> majority of mobile users, there could be real benefits in achieving
>> such an objective.
>
> =>  That would be nice. If MIP is used in the long term then I think
> the way to go is to have a secure (better than the current mechanism)
> RO mechanism that reduces the reliance on the HA significantly. But I
> think as long as we're talking about MIP, we are still stuck with the
> HA. Pekka Nikander proposed homeless MIP nearly 10 years ago, but we
> couldn't make it work at the time, perhaps it's something to try
> again.
>
>>
>> I could also add that RO via the Home Agent is unnecessarily
>> inefficient and unnecessarily demands that the Home Agent is
>> available every time the care-of-address is changed. When
>> end-to-end IPsec is also required, it really does get far too
>> complicated.
>
> =>  The first part of your statement can be dealt with if you use a
> better RO method, it's certainly doable without any problems. IPsec
> is not needed e2e between the MN and the CN.
>
>>
>> My idea is a relatively simple use of Diffie-Hellman to set up a
>> shared secret which can be used to support a secure change of the
>> 1. The first time a MN is in contact with a CN, it includes an
>> extra "skip over" IPv6 Destination Options Header that includes its
>> part of a Diffie-Hellman exchange and a proposed SPI.
>>
>> 2. If the CN ignores this then RO is not possible and the MN has
>> to suffer the consequences. However, if the MN does support this
>> then it similarly returns its part of the Diffie-Hellman exchange
>> and its SPI. Both sides can now generate a shared secret.
>>
>> 3. When and if the MN changes its care-of-address, it includes
>> another Destination Options Header that includes the agreed SPIs
>> and an HMAC generated from the shared secret and over the whole
>> packet including the source IP Address. The CN recognises this
>> header, uses the SPIs to relate it to the earlier exchange and
>> validates the HMAC and thus gains a proof that the packet has come
>> from the same system but from a different care-of-address. It
>> returns an acknowledgement as another Destination Options Header
>> again with an HMAC. Internally, in the CN, the new care-of-address
>> is translated into the original IP Address so that applications are
>> unaware of the change of address for both incoming and outgoing
>> traffic.
>>
> =>  Without getting into too much detail, it sounds like another take
> on shim6 using DH instead of hash-based addresses or CGAs.
>
>>
>> Now there is no authentication here and hence no PKI, etc. The
>> only proof offered is that MN on a new care-of-address is the same
>> system as was on the original IP address. There is also no limit on
>> the number of times it can move. Effectively, it is a form of NAT
>> managed by the MN, and performed on the CN.
>>
>> This type of RO can work standalone or with a Home Agent. If the
>> MN connects through a Home Agent then it can still be mobile even
>> when the CN does not support this RO. On the other hand, if the CN
>> does support it, then the MN can use this procedure to immediately
>> handoff to its care-of-address. The Home Agent is thus only
>> involved during the initial phase of communication.
>>
>> The scheme should also work well with IPsec when it reduces to a
>> simple means of switching the tunnel end-point on movement between
>> care-of-addresses.
>>
> Thanks, Hesham
>>>> My criticism of Mobile IP is thus focused on Route
>>>> Optimisation, in that it depends upon the use of the Home Agent
>>>> rather than being standalone.
>>>>
>>>
>>> =>  Correction, RO doesn't actually depend on the home agent. It
>>> involves packets being sent *through* the home agent but the home
>>> agent doesn't get actively involved in anything. Any packet
>>> addressed to the mobile node's home address will go through the
>>> HA. So, perhaps your criticism is that MIP in general uses the
>>> HA.
>>>
>>> Hesham
>>>
>>>
>>>
>>>> If there is work to be done on a lightweight Mobile IP then I
>>>> would focus on providing a lightweight (no Home Agent) approach
>>>> to seamless movement between care of addresses, which can then
>>>> be extended into a full blown Mobile IP (Home Agents et al) for
>>>> those that need it. Such a lightweight approach could be very
>>>> interesting to the ATN/IPS as it has the potential to avoid the
>>>> tunnelling overhead that comes with IPsec.
>>>>
>>>> On the other hand, would a simpler relationship between the
>>>> Mobile Node and Home Agent make a difference? To me the answer
>>>> is no. This is not the issue. The problem is having to deploy a
>>>> Home Agent in the first place.
>>>>
>>>> Regards
>>>>
>>>> Tony Whyman
>>>>
>>>> Davis, Terry L wrote:
>>>>
>>>>> Ed/Basavarai
>>>>>
>>>>> 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.
>>>>>
>>>>> "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 globally.
>>>>>
>>>>> Take care Terry
>>>>>> -----Original Message----- From: [email-masked]
>>>>>> [mailto:[email-masked]] On Behalf Of Ed Jankiewicz
>>>>>> Sent: Wednesday, March 03, 2010 9:36 AM To:
>>>>>> [email-masked] Cc: [email-masked];
>>>>>> [email-masked]; [email-masked] 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" security, 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.
>>>>>>
>>>>>> Ed J. On 3/3/2010 10:55 AM, [email-masked]
>>>>>> wrote:
>>>>>>
>>>>>>> _______________________________________________ Int-area
>>>>>>> mailing list [email-masked]
>>>>>> _______________________________________________ MEXT
>>>>>> mailing list [email-masked]
>>>>> MEXT mailing list [email-masked]
>>>> _______________________________________________ Int-area
>>>> mailing list [email-masked]

---

From: Tony Whyman <[email-masked]>
Date: Fri, 05 Mar 2010 16:35:14 +0000

Hesham,

No I haven't really considered shim6. There are obvious similarities 
between multi-homing and mobility, but shim6 is not really the 
lightweight solution I am looking for.

Moving on to the MN to Home Agent protocol, I would observe that it only 
looks complicated because two protocols are being used where only one is 
needed. I have never really understood why (expect for historical 
reasons) the binding updates are not sent as part of the IKE. IKE is an 
extensible protocol and could easily incorporate the binding update 
functionality and hence with one protocol you can authenticate a MN, 
establish its care of and home address and set up the tunnel needed to 
exchange end-to-end packets via the Home Agent. With IKE2 it could all 
be done in a four packet exchange, with a simple MOBIKE exchange when 
the MN changes its care-of-address.

Regards

Tony Whyman

---

From: <[email-masked]>
Date: Fri, 5 Mar 2010 18:41:18 +0100

> There appear be different opinions on RO requirement.

Right. Deployments for example have solved to a certain degree the RO
problem by dynamically assigning an HA which is close to the point of
attachment. While not the same as MIP6 RO, it does solve to a certain extent
the problem of an anchor point.

> appears to be the update mechanism (how often, how quick).

True. However the need for a secure tunnel (akin to VPNs) for user-plane
packets is not always necessary in MIP. The need for user-plane security
depends on the access type or location from where the MN is connected.

Frequency of updates also depends on the networks to which the MN is
attached (eg. If the attached to network includes network based mobility
like GTP or PMIP, then the updates between the MN-HA are significantly
reduced) as well as whether the MN moves between different access types
(multi-interfaced MN).

-Raj

---

From: Alberto García <[email-masked]>
Date: Fri, 5 Mar 2010 19:07:36 +0100

Hi

|  -----Mensaje original-----
|  De: [email-masked] [mailto:[email-masked]] En
nombre de
|  Tony Whyman
|  Enviado el: viernes, 05 de marzo de 2010 17:35
|  Para: Hesham Soliman
|  CC: [email-masked]; [email-masked]; Davis, Terry L; [email-masked]
|  Asunto: Re: [Int-area] [MEXT] Rethink on Mobile IPv6
|  
|  Hesham,
|  
|  No I haven't really considered shim6. There are obvious similarities
|  between multi-homing and mobility, but shim6 is not really the
|  lightweight solution I am looking for.

Well, if you take out some multihoming-specific features of shim6 (such as
REAP -RFC5534- almost entirely and some forking capabilities, etc.), shim6
can be used just a four-way handshake with identity protection based on
CGAs, and some messages to update locators when nodes move. 
Why do you say this is not lightweight?

|  
|  Moving on to the MN to Home Agent protocol, I would observe that it only
|  looks complicated because two protocols are being used where only one is
|  needed. I have never really understood why (expect for historical
|  reasons) the binding updates are not sent as part of the IKE. IKE is an
|  extensible protocol and could easily incorporate the binding update
|  functionality and hence with one protocol you can authenticate a MN,
|  establish its care of and home address and set up the tunnel needed to
|  exchange end-to-end packets via the Home Agent. With IKE2 it could all
|  be done in a four packet exchange, with a simple MOBIKE exchange when
|  the MN changes its care-of-address.
|  

Yes, four packet exchange, and a simple exchange when the MN changes its
care-of-address, just like shim6.
In fact IKE includes cryptographic negotiations, etc. which makes it much
more complex by far (although it may worth what you pay for it, of course). 

Regards,
Alberto
|  
|  Regards
|  
|  Tony Whyman
|  
|  Hesham Soliman wrote:
|  > => Have you considered shim6?
|  >
|  > Thanks,
|  > Hesham
|  >
|  >
|  _______________________________________________
|  Int-area mailing list
|  [email-masked]
|  https://www.ietf.org/mailman/listinfo/int-area

---

From: <[email-masked]>
Date: Fri, 5 Mar 2010 20:16:55 +0100

Hesham,

On 3/4/10 7:52 PM, "ext Hesham Soliman" <[email-masked]> wrote:

> is least separated with 4285, which piggybacks it on MIPv6 signalling.

4285 relies on the MN and HA obtaining keys via an out-of-band mechanism
(which for all practical purposes is access network specific). So I disagree
that 4285 relies on MIP6 signaling for key exchange. 4285 simply uses the
keys to compute the authenticator that is carried in the BU. So I don't see
how you believe that 4285 is more tightly coupled than IPsec/IKE.

-Raj

> If

---

From: Hesham Soliman <[email-masked]>
Date: Sat, 06 Mar 2010 10:30:48 +1100

Hi Raj,

> how you believe that 4285 is more tightly coupled than IPsec/IKE.

=> Well, both mechanisms don't couple key exchange with MIPv6, but 4285 uses
a MIPv6 option to authenticate the messages whereas IPsec doesn't. So 4285
is more coupled to MIPv6 than IPsec. 4285 can't be used with any other
protocol so I'm not sure why you don't think it's tightly coupled to MIPv6.

Hesham

---

From: <[email-masked]>
Date: Mon, 8 Mar 2010 05:23:50 +0100

Hi Hesham,

> protocol so I'm not sure why you don't think it's tightly coupled to MIPv6.

But the authentication option within the MIP6 signaling essentially makes
the protocol devoid of dependency on IPsec. And that's a strong +ve from an
implementation and simplicity perspective. The auth-option specified in 4285
is intended for MIP6 signaling messages. So I don't see why it needs to be
used by some other protocol.

-Raj

---

From: Hesham Soliman <[email-masked]>
Date: Mon, 08 Mar 2010 16:07:34 +1100

> used by some other protocol.

=> we're getting away from the initial subject, I was responding to your
comment about the need to separate Auth and key exchange from MIP6
signalling. IPsec and IKE do that, 4285 doesn't. That's my comment. So I
find it confusing that you ask for this separation while supporting 4285
type authentication.
Whether 4285 is a good idea (I don't think it is for all the reasons
discussed on the mext list) is another subject I think.
Hesham

---

From: <[email-masked]>
Date: Mon, 8 Mar 2010 17:55:16 +0100

> find it confusing that you ask for this separation while supporting 4285

I agree that we are discussing 4285 vs IPsec/IKE... And that was not the
intent. My point is that the MIP6 protocol itself should be independent of
how the user is authenticated and keys exchanged that are used by the
signaling messages. (4285 does not do any of this).

> discussed on the mext list) is another subject I think.

No reason to debate about 4285 here. The focus is on simplifying MIP6 and
that does not equate to just 4285.

-Raj