Reverse Tunneling
|
| As you saw in Chapter 2, "Understanding Mobile IP," Mobile IP uses triangle routing for the Mobile Nodes's communication while it is roaming in a Foreign Network. That is, Mobile IP relies on tunneling to deliver all data-plane traffic to the Mobile Nodes while it is roaming, but by default, the traffic from the Mobile Nodes is sent directly to the Correspondent Node (CN). As shown in Figure 6-2, the Mobile Nodes sources traffic with its Home Address from the visiting network, which works well within a trusted autonomous system. However, when crossing autonomous system boundaries and traversing public networks, as in the metro mobility model, this traffic is difficult to distinguish from "source address spoofed" traffic. Figure 6-2. Direct Delivery (Triangle Routing) NOTE Spoofing is a malicious attempt to make traffic appear as if it is coming from a node other than the one from which it originated. Spoofing is possible because the connectionless nature of an IP network means that each packet is forwarded independently to the destination with no consideration of its origin. Spoofing can obscure the source of large denial-of-service attacks and other security exploits. These types of attacks and the growth of IP networking and the Internet have brought about an increased requirement for security. To eliminate spoofing, many edge networks deploy ingress filtering to block incoming packets with a source address from inside the network. Furthermore, most public networks implement an enhanced version of ingress filtering called unicast Reverse Path Forwarding (uRPF). uRPF checks the source address of each inbound packet at the edge of the public network to ensure that traffic destined for the source address would be routed out the same interface that the traffic came in on. If no return route exists, the router assumes that the packet is spoofed and discards it. Ingress filtering and uRPF spell a bit of trouble for Mobile IP. Ingress filtering and uRPF can prevent Mobile Nodess from communicating while they are in a Foreign Network"they can hear, but they cannot speak" (which, by the way, is not always a bad thing in life!). The return routability check in uRPF discards all traffic originated by a Mobile Nodes while it is not in its Home Network. Thus, if ingress filtering and uRPF are deployed in the network, a Mobile Nodes might not be able to communicate with its peer. To overcome the antispoofing mechanisms, Mobile IP uses a technique called reverse tunneling, as defined in Request For Comment (RFC) 3024. With reverse tunneling, traffic sourced from the Mobile Nodes is sent from the CoA back to the Home Agent through a reverse tunnel, and then forwarded to its final destination from the Home Network. Now the source address of the traffic is topologically correct. Figure 6-3 shows how reverse tunneling solves the problem represented in Figure 6-2 by presenting a topologically correct source address at the ingress interface of the firewall. Although specified in a separate RFC than core Mobile IP, reverse tunneling is becoming mainstream in Mobile IP deployments. Figure 6-3. Reverse Tunneling In addition to providing topological correctness, reverse tunnels also allow Mobile Nodess to now participate in multicast groups on their Home Networks. That is, a Mobile Nodes can be a source in a multicast group in its Home Network, and while it is in a Foreign Network, reverse-tunnel any multicast packets for the group back to the Home Network. This way, the multicast packets look as though they emanated from the Home Network before they are forwarded. Another implicit advantage of reverse tunnels is that the TTL on a packet traversing a reverse tunnel is only decremented by one, as with most tunnel mechanisms. Without reverse tunnels, the TTL on a packet from a Mobile Nodes to another node still on the Home Network can be too low, and thus, the TTL can expire before the packet reaches the Home Network. Reverse-Tunnel Delivery StyleReverse tunneling can use either the direct delivery style or encapsulated delivery style method of delivery. The type of delivery style to use depends on the type of traffic that needs to be reverse-tunneled. Direct delivery style is the simpler form but can only be used for unicast packets. In the direct delivery style, the Mobile Nodes sends its packets without encapsulation to the Foreign Agent (FA), with the IP source as its Home Address and the IP destination as the CN's address. The FA intercepts such a packet and encapsulates it with the IP source as the Care-of Address (CoA) and the IP destination as the Home Agent's address. When the Home Agent receives the packet, it decapsulates it to retrieve the original packet from the Mobile Nodes and sends the packet to the CN. With the encapsulated delivery style, the Mobile Nodes sends encapsulated traffic to the FA. The FA decapsulates the packets and then reencapsulates the packets in the reverse tunnel to the Home Agent. The Mobile Nodes must use the encapsulating delivery style for the reverse tunnel for multicast or broadcast traffic. This is because a multicast or broadcast packet for the Home Network should not be transmitted in the clear on the Foreign Network directly. If such packets are sent directly on the Foreign Network, nodes on the foreign link incorrectly think that the multicast or broadcast traffic is intended for them. Thus, the Mobile Nodes encapsulates the multicast or broadcast traffic into a packet destined for the FA. The FA decapsulates the packet and then reverse-tunnels the original multicast or broadcast packet to the Home Agent. The Mobile Nodes can request the encapsulating delivery style from the FA by appending the Encapsulating Delivery Style Extension, defined in RFC 3024, to its Registration Requests (RRQs). The extension is consumed by the FA and not forwarded to the Home Agent. Using the encapsulating delivery style method also allows the Mobile Nodes to use selective reverse tunneling, as follows:
Reverse-Tunnel SignalingTo use reverse tunneling, the Home Agent and the CoA endpoint must both support the technique. The Mobility Agents indicate support for reverse tunneling in their Mobile IP agent advertise-ments through the T bit. By setting the T bit in the advertisement extension, the Mobility Agent is saying that it offers reverse-tunneling service, and in the case of the FA, it necessarily supports the direct delivery style. Using this information from the agent advertisement, a Mobile Nodes can now choose to register through a FA that supports reverse tunneling. The T bit in agent advertisements is backward compatible, in the sense that it is not required to be understood by Mobile Nodess. If a Mobile Nodes does not understand the T bit, it simply ignores the bit and parses the rest of the agent advertisement as usual. A Mobile Nodes explicitly requests reverse-tunneling service by setting the T bit in its RRQ. (At the risk of stating the obvious, this is different from the T bit in the agent advertisement. Refer to Chapter 2 for the various option bits in the agent advertisement and RRQ messages.) This requests the FA to reverse-tunnel all the Mobile Nodes's packets to the Home Agent, and requests the Home Agent to accept a reverse tunnel from the CoA. The default method of delivery for the reverse tunnel is the direct delivery style, and thus, the Mobile Nodes must take care to use this FA as its default router to ensure that its packets are indeed reverse-tunneled to the Home Agent. If a Mobility Agent receives a RRQ with the T bit set and it cannot provide the reverse-tunneling service, it rejects the RRQ with an appropriate failure code. In addition to this failure, a RRQ can fail for other reasons with reverse tunnels. The following self-explanatory failure codes for reverse tunneling are used in Registration Reply (RRP) messages to the Mobile Nodes:
If a Mobile Nodes is operating in Colocated Care-of Address (CCoA) mode directly with its Home Agent, it can perform its own reverse tunneling. Reverse-Tunnel ConfigurationConfiguration for the reverse-tunnel feature is possible on both the Home Agent and FA as follows:
For cases in which reverse tunneling is a known requirement, for example, in domains where ingress filtering is deployed, the FA can be configured to force all Mobile Nodess connected through an interface to use reverse tunneling with the following command: ip mobile foreign-service reverse-tunnel mandatory |
|
EAN: 2147483647
Pages: 124