|
|
12.5. Tunnel ModeESP tunnel mode is used to provide a VPN between two networks or between a host and a network. A typical configuration is shown in Figure 12.4, in which the two security gateways, GWA and GWB, connect networks A and B with a tunnel-mode ESP VPN. (Contrast this diagram with Figure 12.2.) Figure 12.4. An ESP Tunnel-Mode VPN
With this VPN in place, any host on network A can communicate securely with any host on network B. Before looking at how this works, let's examine the ESP tunnel-mode encapsulation. Figure 12.5 shows an IP datagram carrying a TCP segment before and after ESP encapsulation. As we see, the entire IP datagram is swallowed and encrypted by the ESP packet. This means that the ultimate recipient of the packet can be sure that the original IP header has not been tampered with during its transit of the WAN, because it is both encrypted and authenticated. Although the outer IP header is still vulnerable, the final datagram that gets delivered to the recipient is protected. Figure 12.5. ESP Tunnel-Mode Encapsulation
Another aspect of the ESP tunnel-mode encapsulation is that it provides some protection from traffic analysis. That is, an attacker who is capturing the packets as they transit the network is unable to determine the source or destination hosts. The only visible information is that some undetermined host on network A is communicating with some other undetermined host on network B. The construction of the outer IP header follows simple and mostly obvious rules, which are specified in RFC 2401 [Kent and Atkinson 1998c]. Most of the fields in the outer IP header are constructed from scratch, using the expected values. These fields include the header length, total length, ID, fragment offset, checksum, TTL, protocol, and the source and destination addresses. The TOS field is copied from the inner header. The DF flag may or may not be copied, depending on implementation and configuration. Looking again at Figure 12.4, we see that network A has an RFC 1918 private address, as does network B. Although this is not necessary, it is a common practice, and it will also illustrate how the nonroutable RFC 1918 addresses can be sent through the Internet or other WAN. We also see that GWA has a routable address of 1.1.1.1 on its WAN interface. Similarly, GWB has the routable address 2.2.2.2 on its WAN interface. Assume that host A2 sends a TCP segment to host B3. Let's follow the IP datagram as it leaves host A2 until it reaches host B3. As shown in Figure 12.6, when the datagram leaves host A2, it is a "normal" IP datagram with a source address of 10.0.1.2 and a destination address of 10.0.2.3. The protocol field in the IP header is set to 6, indicating that the upper-layer protocol is TCP. Because host A2 either has its default route set to GWA or has a route to the 10.0.2.0/24 network with GWA as the next hop, the datagram is routed to GWA. Figure 12.6. Packet Flow from Host A2 to Host B3
When the datagram reaches GWA, the gateway checks its SPD and notices that it has a policy specifying that any datagram from the 10.0.1.0/24 network to the 10.0.2.0/24 network should be encapsulated with tunnel-mode ESP and sent to GWB at 2.2.2.2. After GWA encapsulates the IP datagram, the outer IP header has a source address of 1.1.1.1 (GWA) and a destination address of 2.2.2.2 (GWB). The protocol field of the outer IP header is 50, indicating that the upper-layer protocol is ESP. The next header field of the ESP packet is 4, indicating that the ESP packet is encapsulating an IP datagram. The inner IP header is unchanged. When the encapsulated IP datagram arrives at GWB, the gateway sees that it contains an ESP packet and retrieves the authentication and encryption keys from the appropriate SA, performs the authentication checks, and decrypts the ESP payload. The outer IP header, the ESP header and trailer, and the ICV are stripped off, and the inner IP datagram is forwarded to its destination, which is 10.0.2.3 (host B3). One more thing is worth noting in this example. Although neither of the gateways performs any NAT functions on the datagram as it passes through, we have connected two networks with private, nonroutable addresses. Unlike NAT, neither the inner IP header nor the TCP segment is modified. Now let's look at an example of ESP tunnel mode on the wire. For this example, we set up an ESP tunnel-mode VPN between the 192.168.123.0/24 and 172.30.0.0/24 networks in our testbed. We will plug host laptop into the 192.168.123.0/24 network and use it to telnet into host solaris over the VPN. The relevant portions of our testbed are shown in Figure 12.7. Figure 12.7. A Portion of the Network Testbed
Here is a copy of the IPsec policy on laptop: 172.30.0.0/24[any] 192.168.123.5[any] any in ipsec esp/tunnel/192.168.123.1-192.168.123.5/require spid=2 seq=1 pid=372 refcnt=1 192.168.123.5[any] 172.30.0.0/24[any] any out ipsec esp/tunnel/192.168.123.5-192.168.123.1/require spid=1 seq=0 pid=372 refcnt=1 The policy on bsd is the same except that the roles of the in and out directions are reversed. We have set the encryption algorithm to NULL so that we can see the contents of the ESP packets. From laptop we telnet into solaris: laptop:~ $ telnet solaris Trying 172.30.0.3... Connected to solaris.jcs.local. Escape character is '^]'. SunOS 5.8 login: guest Password: Sun Microsystems Inc. SunOS 5.8 Generic February 2000 $ Here is the tcpdump output of the SYN segment from laptop to solaris: 1 18:50:51.262663 192.168.123.5 > 192.168.123.1: ESP(spi=0x09e95635, seq=0x34) [tos 0x10] 1.1 4510 0068 0788 0000 4032 fb74 c0a8 7b05 E..h....@2.t..{. 1.2 c0a8 7b01 09e9 5635 0000 0034 4510 003c ..{...V5...4E..> 1.3 0787 4000 4006 4b56 c0a8 7b05 ac1e 0003 ..@.@.KV..{..... 1.4 040d 0017 1939 f0e5 0000 0000 a002 e000 .....9.......... 1.5 c660 0000 0204 05b4 0103 0300 0101 080a .'.............. 1.6 0004 ae90 0000 0000 0102 0204 4d60 d80b ............M'.. 1.7 56a6 7e32 b9ac 51fc V.~2..Q. The outer IP header is typeset in boldface. The tenth byte of the IP header (Figure 2.11) is the protocol number of the upper-layer protocol. As expected, it is set to ESP (50=0x32). The following two 32-bit words are the source and destination addresses192.168.123.5 (0xc0a87b05) and 192.168.123.1 (0xc0a87b01)as shown in line 1. The next 8 bytes are the ESP header: 1.2 c0a8 7b01 09e9 5635 0000 0034 4510 003c ..{...V5...4E..< We see that the SPI is 0x09e95635 and that the sequence number is 0x34; both of these are shown on line 1 of the tcpdump output. After the ESP header is the inner IP header. As before, the tenth byte of the header is the protocol, which this time has the value 6, indicating that the upper-level protocol contained in the IP datagram is TCP. The source address is again 192.168.123.5 (0xc0a87b05), the address of laptop. The destination address is 172.30.0.3 (0xac1e0003), the address of solaris: 1.2 c0a8 7b01 09e9 5635 0000 0034 4510 003c ..{...V5...4E..< 1.3 0787 4000 4006 4b56 c0a8 7b05 ac1e 0003 ..@.@.KV..{..... Next comes the TCP header (Figure 2.16): 1.4 040d 0017 1939 f0e5 0000 0000 a002 e000 .....9.......... 1.5 c660 0000 0204 05b4 0103 0300 0101 080a .'.............. 1.6 0004 ae90 0000 0000 0102 0204 4d60 d80b ............M'.. The fourteenth byte of the TCP header (0x02) contains the flags. This represents the SYN flag, as expected. The next 4 bytes are the ESP trailer. The last 2 bytes of the trailer are the pad length and next header, as shown in Figure 12.1. We see that there are 2 bytes of padding (0x01 and 0x02) and that the next header is 4, reflecting that the ESP packet is encapsulating an IP datagram, as we saw earlier: 1.6 0004 ae90 0000 0000 0102 0204 4d60 d80b ............M'.. Finally, the last 12 bytes are the 96 bits of the HMAC-SHA1-96 ICV: 1.6 0004 ae90 0000 0000 0102 0204 4d60 d80b ............M'.. 1.7 56a6 7e32 b9ac 51fc V.~2..Q. |
|
|
