Subject: [DMM] Comments on DMM Gap Analysis.

From: Jong-Hyouk Lee <[email-masked]>
Date: Fri, 27 Jul 2012 14:53:55 +0200

Dear Anthony and Juan.

I enjoyed the both gap analysis
documents (draft-chan-dmm-framework-gap-analysis-02
and draft-zuniga-dmm-gap-analysis-01). Here I give some comments that
should be used directly in the gap analysis documents if you guys like.

Kindly consider the followings during the gap analysis discussion (since I
will not be attending the IETF meeting this time).

1. Comment on address (resource) management in a DMM environment.
2. Comment on a deployment of a client-based mobility solution (i.e.,
MIPv6) in a DMM environment.
3. Commnet on neighbor mobility anchors' information in a DMM environment.
4. Commnet on an establishment of security associations in a DMM
environment.

=== 1. Comment on address (resource) management in a DMM environment. ===
When existing IP mobility support protocols (e.g., MIPv6 and PMIPv6) are
considered to be deployed in a DMM environment, a mobile node (MN) is
allowed to configure a new address while keeping its previous address(es).
It introduces the following differences with the address (resource)
management of the existing ones:

MN’s address configured at the interface with a DMM environment: n = (IP
address at the current access network + previously configured IP
address(es) with ongoing sessions)
MN’s address configured at the interface without a DMM environment: 1 =
(care-of address in MIPv6 or MN’s home address in PMIPv6)

This leads a couple of considerations we didn’t have with the existing IP
mobility support protocols. For instance,

1) MN’s address management: use of a newly configured address at the
current access network for new communication sessions while a proper
address selection for previously established ongoing communication sessions.

2) Additional treatment for ingress filtering: Ingress filtering is widely
used against source address spoofing. The source addresses (especially, the
network prefix part) of incoming packets are strictly checked to make sure
that those packets are actually from the network that they claim to be
from. As the MN are allowed to send data packets with the previously
configured address(es) at the new access network, those data packets would
be filtered at the ingress filtering place because the source address of
those data packets is not belonging to the new access network. Accordingly,
an additional treatment for ingress filtering is required.

3) MN’s address increase at the MN’s interface: Recall the number of MN’s
address configured at an interface is n. Then, n is increased, as the MN
changes its point of attachment while keeping its ongoing communication
sessions. It brings the question: “How many addresses are currently
possible to be configured at an interface?”

4) Routing entry increase at the serving mobility anchor: Let the serving
mobility anchor is the mobility anchor serves the MN. Traffic associated to
the MN travels via the serving mobility anchor. The increase of the
addresses associated to the MN, n, is not only concerning to the MN, but
also concerning the serving mobility anchor as it contributes the increase
of routing entries for the MN.

=== 2. Comment on a deployment of a client-based mobility solution (i.e.,
MIPv6) in a DMM environment. ===
When a client-based mobility solution (i.e., MIPv6) is consiered to be
deployed in a DMM environment, an MN is involved in mobility signaling such
as Binding Update and Acknowledgement messages. This is the big difference
with the network-based mobility solution (i.e., PMIPv6). As the MN send
signaling to inform its movement to its mobility anchor, the client-based
mobility solution allows the MN to supply client-centric decision for
mobility management.

Suppose that the origin mobility anchor is the mobility anchor where the MN
has configured its IP address and established ongoing communication
sessions with the IP address. The number of origin mobility anchors are n -
1. Recall that the serving mobility anchor is the mobility anchor where the
MN is being served by. Then, the MN’s involvement in mobility signaling
brings us the questions: “Should we let the MN send mobilty signaling to
its all mobility anchors?” or “Would it make sense that the MN only sends
mobility signaling to its serving mobility anchor?” Depending on the
choice, we will have different results:

1) “MN sends mobility signaling to its all mobility anchors” causes:
1.1 increased mobility signaling load, e.g., signaling * (n - 1).
1.2 bidirectional tunnels are established between the MN and its mobility
anchors.
1.3 tunneling overhead over the air is present.
1.4 but the tunnels are terminated at the MN so that the MN has control
over the tunnels.

2) “MN sends mobility signaling only to its serving mobility anchor” causes:
2.1 reduced mobility signaling load, e.g., signaling * 1.
2.2 bidirectional tunnels are established between the serving mobility
anchors and origin mobility anchors.
2.3 tunneling overhead over the air can be avoided.
2.4 but the MN does not have control over the tunnels so it might affect to
NEtwork MObility (NEMO) as the MN (i.e., MR in NEMO) loses the tunneling
control.

=== 3. Neighbor mobility anchors’ information in a DMM environment. ===
In the client-based mobility solution such as MIPv6, the network topology
information does not required to be known to the mobility anchor, i.e.,
home agent (HA), since the HA is informed the current location of the MN.
As the HA knows the current location of the MN, it is able to tunnel
packets associated to the MN. In the network-based mobility solution such
as PMIPv6, the similar things happen, i.e., the tunnel between the local
mobility anchor (LMA) and the mobile access gateway (MAG) is established
for a given MN.

However, as mobility anchors are distributed and bidirectional tunnels (for
a given MN) between the distributed mobility anchors are required, the
neighbor mobility anchors’ information should be provided to the MN or the
mobility anchor for the establishment of the directional tunnels or the
update of the MN’s current location.

Decoupling the data plane and control plane while keeping a centralized
node maintaining the mobility context including neighbor mobility anchors’
information (e.g., identification, IP address, etc) in a DMM environment is
one of possible solutions.

=== 4. Comment on an establishment of security associations in a DMM
environment. ===
For each IP mobility support protocol, different security associations
(SAs) are required for providing secure mobility services to MNs as follows:

1) MIPv6
1.1 SA between MN and HA.
1.2 SA between MN and serving access router (AR) providing wireless link to
the MN.

2) Fast Handover MIPv6 (FMIPv6)
2.1 SA between MN and HA.
2.2 SA between MN and serving AR.
2.3 SA between previous and new ARs.

3) PMIPv6
3.1 SA between MN and serving MAG.
3.2 SA between serving MAG and LMA.

4) Fast Handover PMIPv6 (FPMIPv6)
4.1 SA between MN and serving MAG.
4.2 SA between serving MAG and LMA.
4.3 SA between previous and new MAGs.

Note that the above ones do not consider the cases of SA with a
security-backend server (e.g., AAA server) and with a correspondent node
(CN).

However, depending on DMM solutions, SAs are configured that are different
from those of the existing IP mobility support protocols. For instance,

1) the case of “MN sends mobility signaling to its all mobility anchors”
(client-based mobility solution)
1.1 SA between MN and serving mobility anchor providing wireless link to
the MN.
1.2 SA between MN and origin mobility anchors, i.e., (n - 1) SAs required
with MN and origin mobility anchors.

2) the case of “MN sends mobility signaling only to its serving mobility
anchor” (client-based mobility solution)
2.1 SA between MN and serving mobility anchor.
2.2 SA between serving mobility anchor and origin mobility anchors, i.e.,
(n - 1) SAs required with serving mobility anchor and origin mobility
anchors.

3) the case of “serving mobility anchor sends signaling on behalf of the MN
to origin mobility anchors” (network-based mobility solution)
3.1 SA between MN and serving mobility anchor.
3.2 SA between serving mobility anchor and origin mobility anchors, i.e.,
(n - 1) SAs required with serving mobility anchor and origin mobility
anchors.

Note that as like before SAs with a security-backend server (e.g., AAA
server) and with a CN are not presented.

As shown above, DMM solutions (that relies on bidirectional tunnelings for
packet forwarding between MN and mobility anchors or between just mobility
anchors) might bring the key management issues to establish such SAs.

Since it's a holiday season, I cannot fully address all of them in my mind,
but kindly consider these ones.

Cheers.

-- 
RSM Department, TELECOM Bretagne, France
Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random

#email: jonghyouk (at) gmail (dot) com
#webpage: http://sites.google.com/site/hurryon/