Tunnel Loops and Its Detection draft-ng-intarea-tunnel-loop-00.txt Chan-Wah Ng chanwah.ng@sg.panasonic.com Mohana Jeyatheran mohana.jeyatharan@sg.panasonic.com Benjamin Lim benjamin.limck@sg.panasonic.com 20081119 IETF-73 Minnepolis

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 20081119 IETF-73 Minnepolis

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 20081119 IETF-73 Minnepolis

Example of Tunnel Loop Formation HA 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 20081119 IETF-73 Minnepolis

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 20081119 IETF-73 Minnepolis

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 20081119 IETF-73 Minnepolis

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 20081119 IETF-73 Minnepolis

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!!! 20081119 IETF-73 Minnepolis

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 24.303 20081119 IETF-73 Minnepolis

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 20081119 IETF-73 Minnepolis

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 20081119 IETF-73 Minnepolis

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? 20081119 IETF-73 Minnepolis