Hi All,
>From the comments received after the presentation of
draft-ng-intarea-tunnel-loop
during IETF at Minneapolis, the ADs wanted us to explain
the tunnel loop problem more clearly in the ML and also wanted
to make people understand the need to solve the problem. The following
text
explains the problem in detail and also highlights the need for a
solution.
This text explains the problem of tunnel loop being formed in a
multiple home agent scenario and the need for a proper solution.
+----+ +-----+
|P-GW| | HA |
| |___________________________________| |
+----+ \ / +-----+
\ /
\ /
\ -----+------+--------/
| ePDG |
| |
+------+
|
| WLAN
+------+
| |
| MN |
+------+
Scenario: MN has two home agents. One (P-GW) from 3GPP service provider
and another
from an independent Mobile Service provider (HA). The Home address
obtained
from P-GW is called MN.HoA(P-GW) and home address obtained from HA is
called
MN.HoA(HA)
The following are the steps which MN uses to create a tunnel loop
between
P-GW, HA and ePDG. This MN is a malicious node.
Step 1: MN binds MN nomadic address(MN care-of
address obtained from AR in the WLAN access network) to
MN.HoA(obtained from HA) at HA.
Step 2: MN sets up IKEv2 at ePDG and obtains an address from ePDG which
is called
the ePDG address (care-of address to use DSMIPv6 in 3GPP).
MN then binds the MN.HoA(obtained from HA) as the care-of address at
ePDG.
This binding will surpass the Return Routability test at ePDG.
The binding at ePDG will be ->ePDG address(Home address), MN.HoA(care-of
address)
Step 3: MN creates a MIPv6 binding at P-GW where the MN ePDG address is
registered as the
care-of address. Again if P-GW wants to check the validity of the ePDG
address it
can be done and the test would pass.
Step 4: MN binds MN P-GW HoA (MN.HoA(P-GW)) as the Care-of address at
HA. To overcome
ingress filtering this message will be tunneled via P-GW.
The binding created at HA would be ->MN.HoA(HA)(Home address),
MN.HoA(P-GW)(Care-of address)
It is important to understand, that all the above steps are done
sequentially
with sufficient spacing in time so that a succussful tunnel loop is
formed.
Now, when data packet arrives which is addressed to MN.HoA(HA), it will
be
tunneled to MN.HoA(P-GW). P-GW has a binding for MN.HoA(P-GW) which
points to an
address given from prefix rooted at ePDG(Step 3 binding). Thus the
packet will be tunneled to
ePDG. ePDG has a reachability state for the ePDG address which is
MN.HoA(HA). Thus the
packet will be further tunneled to HA. Again as described previously
this
packet will be again tunneled to MN.HoA(P-GW).
>From the above description, it is clear that the packet will go through
multiple tunneling
encapsulations and will be in an infinite tunnel loop. RFC 2473 limits
the tunneling encapsulations
by introducing an TEL option in the destinations option which can be
inspected by tunnel entry points.
However, it does not identify a tunnel loop. It only limits the
tunneling. Thus there needs to be a proper solution in place.
Once the problem is understood and the need for a solution is accepted,
we can further
explain the adequacy of the solution highlighted in
draft-ng-intarea-tunnel-loop
in solving this problem when compared to current existing methods if
any.
Probably a solution space analysis.
BR,
Mohana
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
