1. Tunnel Loops and Its Detection draft-ng-intarea-tunnel-loop-00.txt
Chan-Wah Ng
Mohana Jeyatheran
Benjamin Lim
IETF-73 Minnepolis

2. Tunnel Loops Tunnel packet: A tunnel loop is formed when
Encapsulated by Tunnel Entry Node
Decapsulated by Tunnel Exit Node
A tunnel loop is formed when
A tunnel packet is routed back to its tunnel entry node before reaching its tunnel exit node
There can be multiple tunnel entry nodes in a tunnel loop
Tunnel Exit
Node
Tunnel Entry
Node
IETF-73 Minnepolis

3. Problem of Tunnel Loops
Tunnel Entry
Node 2
Tunnel Entry
Node 2
Each encapsulation increases packet size
leads to fragmentation
 amplifies the problem
Each encapsulation has a new hop count
 packet will be routed indefinitely
Tunnel Entry
Node 1
IETF-73 Minnepolis

4. Example of Tunnel Loop FormationHA
PDNGW
ePDG MN
INTERNET
3GPP
EPC
HoA
CoA
MN.HoA
Addr
3GPP.Addr
ePDG.Addr
Assigned
Nomadic 1
Binds MN.HoA to AR.Addr
Sets up Mobike mapping 2
Binds 3GPP.Addr to ePDG.Addr 3
MSP HA
PDNGW
ePDG MN
INTERNET
3GPP
EPC
HoA
CoA
MN.HoA
3GPP.Addr
ePDG.Addr
Assigned
Nomadic 4
Binds MN.HoA to AR.Addr 1
Sets up Mobike mapping 2 3
Binds MN.HoA to 3GPP.Addr
MSP
Binds 3GPP.Addr to ePDG.Addr HA
PDNGW
ePDG MN
INTERNET
3GPP
EPC
HoA
CoA
MN.HoA
Addr
Assigned
Nomadic
ePDG.Addr 1
Binds MN.HoA to AR.Addr
Sets up Mobike mapping 2
MSP HA
PDNGW
ePDG MN
INTERNET
3GPP
EPC
HoA
CoA
MN.HoA
3GPP.Addr
ePDG.Addr
Assigned
Nomadic 4
Binds MN.HoA to AR.Addr 1
Sets up Mobike mapping 2 3
MSP
Binds MN.HoA to 3GPP.Addr
Binds 3GPP.Addr to ePDG.Addr
Loop forms! HA
PDNGW
ePDG MN
INTERNET
3GPP
EPC
HoA
CoA
MN.HoA
AR.Addr
Binds MN.HoA to AR.Addr 1
MSP
Assigned
Nomadic HA
PDNGW
ePDG MN
INTERNET
3GPP
EPC
MSP
HoA
CoA
Assigned
Nomadic
IETF-73 Minnepolis

5. Current Protection
RFC 2473 specifies the Tunnel Encapsulation Limit Option for IPv6 packets
Adds a maximum number of encapsulation to Destination Header of outer packet
All Tunnel Entry Nodes must process this option
RFC 1701 has a 3-bit recursion field for IPv4 GRE based tunneling
IETF-73 Minnepolis

6. Inadequacies
Both mechanisms only limits the number of times a packet will traverse a loop
Does not allow a tunnel entry node to differentiate between
The case where a tunnel loop has occurred
The case where the initial TEL/Recursion value is set too low
IETF-73 Minnepolis

7. Add Identifier We propose
Adds an identifier to the tunnel packet header
Can be an additional field in TEL option
Can be coded using multiple TEL option
Can be an additional field in GRE header
Can be coded using the Key field in GRE header
The type of identifier is for further analysis
IETF-73 Minnepolis

8. Tunnel Entry Node Processing
Receives a
packet to be
encapsulated
Is there
an identifier
in received
packet?
Does
identifier indicates
a loop?
yes
yes no no
Encapsulate packet
Adds identifier
Encapsulate packet
Copy identifier
Loop detected!!!
IETF-73 Minnepolis

9. Comments So Far
Any practical situation where the problem is encountered?
Issue #17 in the ongoing work of RFC 3775-bis
3GPP CT1 has agreed that this is a realistic problem in TS
IETF-73 Minnepolis

10. Comments So Far Better to avoid the loop entirely
Using control plane signaling (if present)
However with possible malicious mobile nodes dynamically setting up tunnels, this is not possible
Address check mechanism
HA to check the validity of the care-of address before accepting the BU
With Monami6, a malicious mobile can still set up the loop while passing any address check mechanism
 But it is not always possible
IETF-73 Minnepolis

11. Comments So Far Rely on generic DoS defense
Most operators has defense mechanism to drop packets when a DoS attack is launched
Problems:
Reactive: network is already under attack before defense is triggered
Does not know if DoS attack is due to tunnel loop
Since DoS defense generally drops packets from a domain where the attack is suspected to have originated, a tunnel loop can be used to cause packets from an innocent domain to be dropped
Avoid a loop > Detect a loop > Defense against DoS
IETF-73 Minnepolis

12. Discussion Points Is this specific to Mobility? Should we solve it?
The problem is generic
But all practical scenarios identified so far are mobility related
Should we solve it?
If so, where?
IETF-73 Minnepolis