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
Hesham Soliman wrote:
Just one comment below:
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.
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: mext-boun...@ietf.org [mailto:mext-boun...@ietf.org] On
Behalf Of Ed Jankiewicz
Sent: Wednesday, March 03, 2010 9:36 AM
To: basavaraj.pa...@nokia.com
Cc: rdr...@cisco.com; int-area@ietf.org; m...@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"
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, basavaraj.pa...@nokia.com wrote:
Mobile IPv6 (RFC3775) has been an RFC since 2004, and Dual-stack
-Basavaraj
_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
_______________________________________________
MEXT mailing list
m...@ietf.org
https://www.ietf.org/mailman/listinfo/mext
------------------------------------------------------------------------
_______________________________________________
MEXT mailing list
m...@ietf.org
https://www.ietf.org/mailman/listinfo/mext
_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
