|
|
13.4. An Example NegotiationThe phase 2 SAs are negotiated under the protection of the phase 1 SA, so only the ISAKMP header is visible, and we can't tell very much from looking at a network trace of those negotiations. Phase 1 negotiations, on the other hand, take place mostly in the clear, so we can watch them with a trace and follow their progress. For debugging IPsec SA negotiations, the logs from the IKE daemon are almost always the first place to look. Where these logs are stored (if they even exist), what their names are, and what information they provide and in what format are, of course, implementation-specific details, so we won't pursue those questions any further. Nevertheless, we should not underestimate the value of learning to interpret these logs when we are debugging IPsec. To see SA negotiation in action, let's revisit the AH transport tunnel that we built in Chapter 11. Recall that the tunnel was between bsd and laptop, as shown in Figure 11.7. On laptop, we start IPsec and dump the SAD, using the FreeBSD command setkey. We discover that there are no active SAs. Next, we ping bsd, which causes the IKE daemon to negotiate the necessary SAs. After we terminate ping, we again dump the SAD and see that there are now two AH transport mode SAs: laptop# setkey -D No SAD entries. laptop# ping 192.168.123.1 PING 192.168.123.1 (192.168.123.1): 56 data bytes 64 bytes from 192.168.123.1: icmp_seq=2 ttl=64 time=0.551 ms 64 bytes from 192.168.123.1: icmp_seq=3 ttl=64 time=0.487 ms 64 bytes from 192.168.123.1: icmp_seq=4 ttl=64 time=0.487 ms 64 bytes from 192.168.123.1: icmp_seq=5 ttl=64 time=0.536 ms ^C --- 192.168.123.1 ping statistics --- 6 packets transmitted, 4 packets received, 33% packet loss round-trip min/avg/max/stddev = 0.487/0.515/0.551/0.029 ms laptop# setkey -D 192.168.123.5 192.168.123.1 ah mode=transport spi=84200268(0x0504cb4c) reqid=0(0x00000000) A: hmac-sha1 e6166a5b 32a65b4f 6baa95dc 7c989e2d 400f1a3c seq=0x00000004 replay=4 flags=0x00000000 state=mature created: Mar 7 18:00:01 2005 current: Mar 7 18:00:17 2005 diff: 16(s) hard: 1800(s) soft: 1440(s) last: Mar 7 18:00:05 2005 hard: 0(s) soft: 0(s) current: 432(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 4 hard: 0 soft: 0 sadb_seq=1 pid=339 refcnt=2 192.168.123.1 192.168.123.5 ah mode=transport spi=173251830(0x0a539cf6) reqid=0(0x00000000) A: hmac-sha1 88daa625 04dc3596 c41cdbf5 9de98243 967132a9 seq=0x00000004 replay=4 flags=0x00000000 state=mature created: Mar 7 18:00:01 2005 current: Mar 7 18:00:17 2005 diff: 16(s) hard: 1800(s) soft: 1440(s) last: Mar 7 18:00:05 2005 hard: 0(s) soft: 0(s) current: 336(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 4 hard: 0 soft: 0 sadb_seq=0 pid=339 refcnt=1 We capture the SA negotiation and the first ping packet with tcpdump and show the result below. We've reformatted the tcpdump output slightly: 1 18:00:00.373099 IP 192.168.123.5.isakmp > 192.168.123.1.isakmp: isakmp 1.0 msgid : phase 1 I agg: (sa: doi=ipsec situation=identity (p: #1 protoid=isakmp transform=1 (t: #1 id=ike (type=lifetype value=sec) (type=lifeduration value=0e10) (type=enc value=3des) (type=auth value=preshared) (type=hash value=sha1) (type=group desc value=modp1024)))) (ke: key len=128) (nonce: n len=16) (id: idtype=IPv4 protoid=udp port=500 len=4 192.168.123.5) 1.1 4500 0110 00a3 0000 4011 01e3 c0a8 7b05 E.......@.....{. 1.2 c0a8 7b01 01f4 01f4 00fc 439e 4598 0d8e ..{.......C.E... 1.3 0b43 b113 0000 0000 0000 0000 0110 0400 .C.............. 1.4 0000 0000 0000 00f4 0400 0034 0000 0001 ...........4.... 1.5 0000 0001 0000 0028 0101 0001 0000 0020 .......(........ 1.6 0101 0000 800b 0001 800c 0e10 8001 0005 ................ 1.7 8003 0001 8002 0002 8004 0002 0a00 0084 ................ 1.8 2aa6 27ab a407 e593 f013 5bbe c25f 1be4 *.'.......[.._.. 1.9 fcab 63a3 348c 4fa9 4a1f 4328 155b 4ca1 ..c.4.O.J.C(.[L. 1.10 62dd d762 6808 e226 c442 adc5 545d c336 b..bh..&.B..T].6 1.11 077a e70a 16d4 f583 7b3f e014 753b ccb2 .z......{?..u;.. 1.12 5357 e025 3ce8 8ea3 9572 db05 3593 5d3e SW.%<....r..5.]> 1.13 cca8 7987 305f 016e 52c4 e70c 1dc3 82c9 ..y.0_.nR....... 1.14 0bab 06f0 ea3a 9c49 71e4 3aa7 edba 1af5 .....:.Iq.:..... 1.15 1a8e d5bd a8d6 896f 1390 5c83 360d d9fe .......o...6... 1.16 0500 0014 c7e2 d68a 8e8f 1b55 3936 2ca0 ...........U96,. 1.17 e458 6e4b 0000 000c 0111 01f4 c0a8 7b05 .XnK..........{. 2 18:00:00.429855 IP 192.168.123.1.isakmp > 192.168.123.5.isakmp: isakmp 1.0 msgid : phase 1 R agg: (sa: doi=ipsec situation=identity (p: #1 protoid=isakmp transform=1 (t: #1 id=ike (type=lifetype value=sec) (type=lifeduration value=0e10) (type=enc value=3des) (type=auth value=preshared) (type=hash value=sha1) (type=group desc value=modp1024)))) (ke: key len=128) (nonce: n len=16) (id: idtype=IPv4 protoid=udp port=500 len=4 192.168.123.1) (hash: len=20) (vid: len=16) 2.1 4500 013c f287 0000 4011 0fd2 c0a8 7b01 E..<....@.....{. 2.2 c0a8 7b05 01f4 01f4 0128 e01c 4598 0d8e ..{......(..E... 2.3 0b43 b113 7f1c 2f30 c56c cf66 0110 0400 .C..../0.l.f.... 2.4 0000 0000 0000 0120 0400 0034 0000 0001 ...........4.... 2.5 0000 0001 0000 0028 0101 0001 0000 0020 .......(........ 2.6 0101 0000 800b 0001 800c 0e10 8001 0005 ................ 2.7 8003 0001 8002 0002 8004 0002 0a00 0084 ................ 2.8 066e e57e 3b5f 6470 53ed e233 42b7 e585 .n.~;_dpS..3B... 2.9 bb44 7b7d 7f5c b811 b424 b73a 1027 2f67 .D{}....$.:.'/g 2.10 6e23 0769 e04a f6ee a802 0971 ac90 f556 n#.i.J.....q...V 2.11 4b21 6764 c87f 3758 aea5 b267 080a d002 K!gd..7X...g.... 2.12 0683 ed2a d080 e2f1 897e 1fe3 67b9 193e ...*.....~..g..> 2.13 06e5 2676 252b 8c12 061f 6f1d fc53 90a2 ..&v%+....o..S.. 2.14 e59d 8be1 aaeb 8b1b 7a5c e6e1 33c2 ae18 ........z..3... 2.15 da28 087f ec03 ac50 5188 6063 ac22 d956 .(.....PQ.'c.".V 2.16 0500 0014 b0f7 d512 2fb2 e41b 9fd1 1227 ......../......' 2.17 d795 a479 0800 000c 0111 01f4 c0a8 7b01 ...y..........{. 2.18 0d00 0018 6d70 6043 8779 6e0d 4963 01cf ....mp'C.yn.Ic.. 2.19 e803 cac4 aa13 ccb5 0000 0014 7003 cbc1 ............p... 2.20 097d be9c 2600 ba69 83bc 8b35 .}..&..i...5 3 18:00:00.492011 IP 192.168.123.5.isakmp > 192.168.123.1.isakmp: isakmp 1.0 msgid : phase 1 I agg: (hash: len=20) 3.1 4500 0050 00a4 0000 4011 02a2 c0a8 7b05 E..P....@.....{. 3.2 c0a8 7b01 01f4 01f4 003c 6346 4598 0d8e ..{......<cFE... 3.3 0b43 b113 7f1c 2f30 c56c cf66 0810 0400 .C..../0.l.f.... 3.4 0000 0000 0000 0034 0000 0018 7aa7 7e5d .......4....z.~] 3.5 9a54 8e4c 59cb d0ea cca1 177b 79f5 1788 .T.LY......{y... 4 18:00:00.493857 IP 192.168.123.1.isakmp > 192.168.123.5.isakmp: isakmp 1.0 msgid : phase 2/others R inf[E]: [encrypted hash] 5 18:00:01.526554 IP 192.168.123.5.isakmp > 192.168.123.1.isakmp: isakmp 1.0 msgid : phase 2/others I oakley-quick[E]: [encrypted hash] 6 18:00:01.541429 IP 192.168.123.1.isakmp > 192.168.123.5.isakmp: isakmp 1.0 msgid : phase 2/others R oakley-quick[E]: [encrypted hash] 7 18:00:01.548966 IP 192.168.123.5.isakmp > 192.168.123.1.isakmp: isakmp 1.0 msgid : phase 2/others I oakley-quick[E]: [encrypted hash] 8 18:00:02.334647 IP 192.168.123.5 > 192.168.123.1: AH(spi=0x0504cb4c,sumlen=16,seq=0x1): icmp 64: echo request seq 512 In line 1, we see a breakout of the first message in the phase 1 negotiation. Notice that this is an Aggressive mode (agg) negotiation. The first payload is the SA offer (sa:) with a single Proposal payload (p:), which in turn has a single Transform payload (t:). The Transform payload has six attributes that describe the SA's lifetime, encryption algorithm, authentication method, integrity method, and Diffie-Hellman group. After the SA payload, are the Key, Nonce, and Identification payloads. Let's examine the packet itself to see how this data is carried in the message. Lines 1.1 and 1.2 contain the IP and UDP headers. On lines 1.21.4, we see the ISAKMP header set in boldface. As we see from Figure 13.1, the first 16 bytes are the initiator and responder cookies. Notice that the responder cookie is 0 in the first message, as expected. The next byte (0x01) tells us that the next payload is an SA payload (see Figure 13.2), followed by the major and minor version (0x10) and the exchange type (0x04). From Figure 13.3, we see that this is an Aggressive mode exchange. The next byte is the flags; as we see, no flags are set. The next 8 bytes are the message ID (0) and the length of 244 (0xf4). On lines 1.4 and 1.5, we see the SA payload: 1.4 0000 0000 0000 0120 0400 0034 0000 0001 ...........4.... 1.5 0000 0001 0000 0028 0101 0001 0000 0020 .......(........ Notice from Figure 13.6 that the next header field (0x04) is a Key Exchange payload, not the Proposal payload, which comes next but is considered part of the SA payload. The second 4 bytes are the DOI, which is IPSEC (1). The last 4 bytes of the SA payload proper are the situation, which in this case is SIT_IDENTITY_ONLY. Following the SA payload is the Proposal payload on line 1.5. The format of this payload was shown in Figure 13.7. 1.5 0000 0001 0000 0028 0101 0001 0000 0020 .......(........ The length of 40 (0x28) includes the following Transform payload, just as the SA payload length field included the Proposal and Transform payloads' lengths. Also, the next payload field is NONE (0), even though there is a following Transform payload. If there were another Proposal in the SA payload, this field would be set to Proposal (2). The proposal ID in the fifth byte is 1, as we saw in line 1. The protocol ID (in the sixth byte) is a 1, indicating ISAKMP (see Figure 13.8). The seventh byte is the SPI size. Because this is 0, the SPI field is not present in the payload. Recall that the SPI for phase 1 SAs is the two cookies. Finally, the last byte tells us that there is one Transform payload for this proposal, shown on lines 1.51.7: 1.5 0000 0001 0000 0028 0101 0001 0000 0020 .......(........ 1.6 0101 0000 800b 0001 800c 0e10 8001 0005 ................ 1.7 8003 0001 8002 0002 8004 0002 0a00 0084 ................ As we see from Figure 13.9, most of the information in a Transform payload is carried in the attributes. We see from the first 2 bytes on line 1.6 that this is transform 1 and that the transform ID is IKE (1)see Figure 13.10. The remaining bytes in the payload are the attributes. For example, the first attribute (on line 1.6) is 800b 0001. Because the AF bit is set (see Figure 13.5), this is a basic attribute, and its value is carried in the second 2 bytes. From Figure 13.11, we see that attribute 11 (0x000b) is the lifetime type for this SA. From the IKE specification (RFC 2409), we see that a value of 1 is seconds. The next attribute, 800c 0e10, is the lifetime duration attribute, which tells us how many seconds the SA should live before being replaced. Note from Figure 13.11 that this is a variable attribute but that because the value fits in 16 bits, it was encoded as a basic attribute instead. The lifetime is 3,600 (0xe10) seconds, or 1 hour. The other attributes are similar, and we can see what they are from line 1. The Key Exchange payload is on lines 1.71.15. Its generic header is the last 4 bytes on line 1.7. The rest of the payload is the key-exchange data. Its length is 132 (0x84), but tcpdump shows the length of the data as only (128), instead of the total length. The Nonce payload on lines 1.16 and 1.17 is similar. It consists of a generic header and 16 bytes of nonce. Its next payload is set to Identification payload (5). The Identification payload appears on line 1.17: 1.17 e458 6e4b 0000 000c 0111 01f4 c0a8 7b05 .XnK..........{. Its next payload field is set to NONE (0), indicating that this is the last payload. The fifth byte (0x01) is the identification type. From the DOI (RFC 2407), this specifies that the identification is an IPv4 address. The protocol ID is 17 (0x11), indicating UDP (Figure 2.12), and the port is the default value of 500 (0x1f4). The initiator's IP address is 192.168.123.5 (0xc0a87b05), as expected. The other two phase 1 messages are similar. Exercise 13.11 asks us to perform a similar analysis on them. The phase 2 Quick mode messages are encrypted, so we can't see their contents. On line 8, we see the AH protected ping that initiated the negotiation we have been studying. |
|
|