1$KAME: question,v 1.27 2000/10/04 17:41:07 itojun Exp $ 2 3Q: how may policy matters are. can we interoperate ? 4 5Q. If there is the phase 1 spi size excepting 16 and 0 in SA payload. 6 warn it. and reject or accept ? 7 8Q. ID payload handling in phase 2 besides IPSECDOI_ID_IP*. 9 e.g. IPSECDOI_ID_DER_ASN1_DN. Well, are these used in phase 2 ? 10 11Q. The padding for data attribute. 12 in particular, variable-length attribute like ID-userfqdn. 13 14Q. vendorid's hash algorithm 15 For aggressive mode ?. 16 In main mode, should I use negotiated algorithm ? 17A. it's not needed any negotiation. 18 19Q. If we use different hash algorith to compute the value of the vendor id, 20 is it possible to be same result of the hash value ? 21 22Q. encryption during aggressive mode. 23 when i receive encrypted packet of 2nd message from responder, 24 it can be decoded. When i am responder, should i send encrypted one ? 25 26Q: phase2 PFS and KE payload 27 when the responder was not required PFS, if the initiator send KE ? 28 if the responder's pfs group is not match to the initiator's one ? 29 If initiator requests PFS, should we accept without acceptable check ? 30 reject the proposal and quit the phase 2. 31 accept it. 32 it's policy issue. 33 34Q. If tye type of ID payload is SUBNET, should it be allowed ::1/128 as host 35 address ? 36A. yes. consensus at bake-off. 37 38Q. how many proposal can we send ? 39 30? 300? infinite ? 40 41Q. Is there only one payload of RESPONDER-LIFETIME in a IKE message 42 even if SA bundle is required ? 43 At the moment, racoon sends this notify payload(s) against each protocol. 44 45Q. Which is SPI to be used initiator's or responder's when sending 46 RESPONDER-LIFETIME ? 47A. At the moment, racoon sends responder's one. 48 49Q. Is it typo in the base mode draft ? 50 HDR, SA, Idii, Ni_b => 51 Ni ??? 52 <= HDR, SA, Idir, Nr_b 53 Nr ??? 54A. Yes, typo. (network associates said.) 55 56Q. What's proto_id in notify message of the responder 2nd message with commit 57 bit processing when multiple different SA applyed ? 58 59Q. Is it forbidden to clear commit bit during phase2 negotiation ? 60A. not forbidden, 61 62Q. how many time is the notify message sent in phase 2 ? 63A. don't resend notify message because peer can use Acknowledged 64 Informational if peer requires the reply of the notify message. 65Q. phase 1 is ? 66 67Q. What kind of policy configuration is desired? 68 policy.conf makes sense in certain situations only, such as: 69 - we are the initiator, and trying to enforce certain configuration. 70 71 If we would like to talk with strangers (like IPsec-ready webserver, or 72 "IPsec with everyone" configuration), or need to move from place to place 73 (like IPsec-ready nomadic node), we need an ability to write "wildcard 74 policy entry" which matches situations/packets/whatever, and then install 75 non-wildcard policy entry into the kernel. 76 For example: 77 - policy.conf says 0.0.0.0/0 -> 0.0.0.0/0, protocol "any", type "use", 78 for "encrypt everything" configuration. 79 - phase 2 ID payload will be exchanged for real address we have, and the 80 peer has (a.b.c.d/32). This is not the same as "0.0.0.0/0" configured 81 onto policy entry. 82 - with the current code, policy.conf and phase 2 ID does not match, and 83 it will fail. 84 85 If we are acting as responder, we will be making policy entry from phase 2 86 IDs. Is it always okay to accept phase 2 IDs as is, into our kernel policy? 87 We'll need to have filtering rule, or mapping rules from phase 2 IDs to 88 kernel policy. 89 For example: 90 - we have 10.1.1.0/24 -> 10.1.2.0/24, protocol "any" in policy.conf. 91 - what happens if we get, as responder, 10.1.1.0/25 -> 10.1.2.0/25, 92 protocol "any"? should we accept it as is, or should we respect our 93 configuration? 94 if we respect our configuration, 10.1.1.128/25 -> 10.1.2.128/25 traffic 95 will be encrypted from our side, and end up being dropped by the peer. 96 - what happens if we get, as responder, 10.1.1.0/24 -> 10.1.2.0/24, 97 protocol "tcp"? should we accept it as is, or should we respect our 98 configuration? 99 if we respect our configuration, non-tcp traffic will be dropped on 100 the peer. 101 102 -> the question is obsoleted by configuration language change. 103 104Q. What's msgid of informational exchange for error notify message during 105 phase2 ? Is it same as msgid of phase2 negotiation caused error ? 106 Or new msgid created ? If later case, spi must be conveyed. 107A. new msgid should be used 108Q. how can we deduce phase 2 from the notification? 109A. see draft-ietf-ipsec-notifymsg-*.txt 110 111Q. I don't know the situation to initiate acknowledged informational. 112 113Q. How many certificate payload in a packet are sent ? 114 isakmp-test.ssh.fi send both CRL and CERT in a packet. 115A. multiple CERT payload can be sent. Or use PKCS#7. 116 117Q. What should we do if nonce size is greater than size of RSA modulus 118 in authentication with public key encryption, also size of body of 119 ID payload ? 120 121Q. For IKE negotiation of IPComp, how should we encode CPI (2 byte) into SPI 122 field of proposal payload (for AH/ESP, normally 4 bytes)? 123 Options are as follows: 124 (1) put it as 4 byte value, set SPI size to 4 125 1 2 3 126 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 ! Next Payload ! RESERVED ! Payload Length ! 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 ! Proposal # !ProtID = ipcomp! SPI Size(4)!# of Transforms! 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 ! SPI = 0x0000XXXX ! 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 135 (2) put it as 2 byte value, set SPI size to 2. No padding must be made. 136 1 2 3 137 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 ! Next Payload ! RESERVED ! Payload Length ! 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 ! Proposal # !ProtID = ipcomp! SPI Size(2)!# of Transforms! 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 ! SPI = 0xXXXX ! ... transform ... 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 146 IRE did (1), IIRC. (Jan 2000) 147 148 SSH does (2), and rejects (1). (Sep 2000) 149 150 The following email suggests (2) for normal case, and allow (1) for backward 151 compatibility (responder case I bet). 152 To: ipsec@lists.tislabs.com 153 From: Joern Sierwald <joern.sierwald@datafellows.com> 154 Subject: Re: issues from the bakeoff 155 Date: Wed, 16 Jun 1999 11:02:16 +0300 156 Message-Id: <3.0.5.32.19990616110216.00b77880@smtp.datafellows.com> 157 158A: (2) for normal case, and allow (1) for backward compatibility 159 (responder case I bet). <draft-shacham-ippcp-rfc2393bis-05.txt> 160 161Q. INITIAL-CONTACT message. 162 When should we send an INITIAL-CONTACT message? 163A. see jenkins rekey draft 164 165 We must ignore unencrypted INITIAL-CONTACT message. 166 167 If we have two nodes and they issue the first packet of phase 1 at the same 168 time, both may try to transmit INITIAL-CONTACT message, and effectively 169 kills both connection attempt. 170 171 node 1 node 2 172 | | 173 |----------\ /---------| phase 1 first packet 174 | \/ | 175 | /\ | 176 |<---------/ \-------->| 177 | | 178 |----------\ /---------| INITIAL-CONTACT 179 | \/ | 180 | /\ | 181 |<---------/ \-------->| 182 183 Options are as follows: 184 (1) don't throw INITIAL-CONTACT message. 185 (2) don't delete old phase 1 information, even if we get INITIAL-CONTACT 186 message.. 187 (3) don't delete phase 1 information, if it is very new. delete phase 1 188 information only if they are old. 189 (4) implement tie-breaker rule. for example, compare IP address and remove 190 phase 1 initiated by the one who has larger IP address. 191 192Q: IPv6 neighbor discovery. 193 When a security policy is set to "all packet require IPsec", it will 194 cover IPv6 ND packets as well. The node will try to secure ND, and 195 we will have chicken-and-egg problem (without ND we cannot send IKE 196 packets, without IKE negotiation we cannot send ND). 197 198 What can we do? 199 - always bypass IPsec policy lookup if a packet is for ND. 200 - Security policy should have more detail rules to filter 201 such packet, like icmp6 type/code filters. 202 203Q: When there are no ID payloads in phase 2 ? 204A. guess from the pair of address of IKE peer. 205 206Q: Delete payload. 207 Which SPI should I carry on Delete notify ? 208 There is no documentation. 209 210 An initiator should send a set of SPI of inbound SAs. 211 A responder should delete a set of outbound SAs which are sent by 212 an initiator. 213 214 When an IKE node deletes old SAs, should it send DELETE notify to 215 a peer ? 216 217 When does a node send DELETE notify ? 218 when a IKE node deletes old SAs expilicitly. 219 when a SA expires (hard lifetime reached). 220 It may not be necessary. 221 222 When a DELETE notify packet is dropped, SA will get inconsistent 223 between peers. 224 We can prevent from it by using "heartbeat" ? 225 226 when there is no phase 1 SA, should I negotiate phase 1 SA before 227 sending delete notify ? 228 A: no need. (the consensus made at the mailing list ?) 229 230Q: "heartbeat" 231 It means a signal of "I'm alive". 232 It is exchanged in phase 1.5. 233 When a responder dies/reboots, phase 2 SA sitll remains but 234 we can know the rebooting of the peer by using "heartbeat". 235 236 Is INITIAL-CONTACT message useless if we choise "heartbeat" ? 237 We don't know. 238 239Q: responder's action in a normal case. 240 A responder should never initiate both phase 1 and phase 2 at anytime. 241 Once we have decided which side we are (initiator/responder), the 242 relationship will never change. 243 244Q: only the byte type of lifetime on phase 2, not exist the type of time. 245 No ducumentation states explicitly. 246 We can choose to use default lifetime (28800). 247 We can reject it accortding to a policy. 248 249Q: phase 2 lifetime negotiation 250 what should I do if the peer has proposed the lifetime value which 251 does not match to our policy ? 252 - always reject it. 253 - use my lifetime, then send RESPONDER LIFETIME. 254 - during negotiation obey the initiator. install SA lifetime based 255 on the lifetime we have decided (not from the negotiation). 256 257Q: phase 1 lifetime negotiation 258 can we do like phase 2 ? 259 260Q: Does RFC2407 4.5.4 Lifetime Notification say for phase 2 ? or phase 1 ? 261 responder lifetime may be inapproprite for phase1 because 262 proposal is not encrypted, so bad guy can forge it. 263 264Q: phase 1 lifetime of bytes. 265 What should we count ? 266 Or it should be obsoleted ? 267 268Q: phase 2 lifetime of bytes. 269 byte lifetime of an SA is harder to implement/manipulate than 270 wallclock lifetime, because: 271 - if there's packet losses on the link, it will lead to disagreement 272 between peers about how much traffic were gone through the SA. 273 - it is unclear when to compute the lifetime. for example, for IPComp, 274 there's a big difference between computing byte lifetime before 275 compression, or after compression. [RFC2401 page 23: 276 should compute byte lifetime using a packet BEFORE IPsec processing] 277 278 it is more questionable to use byte lifetime for inbound SA, than 279 for outbound SA. we will have more problem if we expire inbound SA 280 earlier than the peer (if we expire an SA earlier than the peer, 281 inbound traffic will result in "no SA found" error). 282 283Q: soft and hard lifetime. [RFC2401 page 23] 284 RFC2401 talks about soft and hard lifetime. for stable rekeying 285 operation, it may help if we introduce another kind of lifetime; 286 287 soft lifetime (80% of hard lifetime, for example): 288 should inform IKE of the expiry, and IKE should try to negotiate 289 a new SA. 290 deprecation lifetime (90%): 291 no outbound packet should be generated by this SA. 292 inbound packet is handled okay. 293 hard lifetime (100%) 294 SA will be erased. 295 296Q: responder should not modify phase 2 attributes 297 even for phase 1, we should not modify attributes. 298 for lifetime attributes, it is okay to switch between V/B format. 299 300 draft-ietf-ipsec-ike-01.txt Appendix A: 301 If this is the case, an 302 attribute offered as variable (or basic) by the initiator of this 303 protocol MAY be returned to the initiator as a basic (or variable). 304 305Q: check if reserved field is zero, reject if 306 we should do this (sakane) 307 i don't think so, it will kill future protocol enhancements (itojun) 308 309Q: order of proposals in IKE phase 2 packet, and IPsec processing order 310 how to negotiate SA bundle. 311 IKE: esp+ah, or ah+esp 312 -> is it safe to consider both as IP|AH|ESP|ULP? 313 -> is the proposal prefered to send the order of ah+esp. 314 IKE: ah+ah? 315 reject? or policy issue. 316 RFC2401bis should state the pattern of SA bundle. 317 AH 318 AH+ESP 319 AH +IPCOMP 320 AH+ESP+IPCOMP 321 ESP 322 AH+ESP 323 AH+ESP+IPCOMP 324 ESP+IPCOMP 325 AH+ESP 326 AH+ESP+IPCOMP 327 Also RFC2401bis should state the meaning of protcol mode. 328 329 we are going to install both SAs, ESP and AH. and they are bundled. 330 we should negotiate both SAs in single phase2. 331 332 can we do that separately ? 333 it is hard to verify the policy because the policy might be 334 defined SA bundle. 335 when i make packet IP2|AH|ESP|IP1|ULP. 336 proposal and order must be 337 ah/transport + esp/tunnel ? 338 ah/tunnel + esp/tunnel ? 339 340Q: what should we do if phase 1 SA expires, during phase2 SA negotiation? 341A. restart phase 2 negotiation from scratch 342 343Q: what kind of notification message a node should send on decode failure? 344 ISAKMP_NTYPE_INVALID_PAYLOAD_TYPE 345 iked 346 ISAKMP_NTYPE_UNEQUAL_PAYLOAD_LENGTHS 347 racoon 348 ISAKMP_NTYPE_PAYLOAD_MALFORMED 349 sanity check would be hairy 350 351Q: Certificate Request. 352 where to attach CR? 353 obey draft-ietf-ipsec-pki-req-05.txt. 354 what should we put inside CR? 355 my own signer? 356 RFC2408 page 34 says; 357 358 o Certificate Authority (variable length) - Contains an encoding of 359 an acceptable certificate authority for the type of certificate 360 requested. As an example, for an X.509 certificate this field 361 would contain the Distinguished Name encoding of the Issuer Name 362 of an X.509 certificate authority acceptable to the sender of 363 this payload. This would be included to assist the responder in 364 determining how much of the certificate chain would need to be 365 sent in response to this request. If there is no specific 366 certificate authority requested, this field SHOULD not be 367 included. 368 369Message-Id: <200009262047.XAA10637@torni.hel.fi.ssh.com> 370Subject: CERT_REQ_PAYLOAD usage 371From: Tero Kivinen <kivinen@ssh.fi> 372Date: Tue, 26 Sep 2000 23:47:00 +0300 (EET DST) 373 374 1) If you absolutely need certificates from the other side for 375 the authentication to work, you MUST send certificate request 376 payload. 377 378 2) If the authentication can succeed without the other end 379 sending certificates (you have some certificate for the other 380 end, or you can fetch the certificate from the certificate 381 repository), you MAY send certificate request. 382 383 3) If you just want any certificate without specifying the CA 384 root, send certificate request having empty CA name. 385 386 4) When you receive certificate request you MUST send your own 387 certificate for that CA. 388 389 5) If you receive empty certificate request you MUST send the 390 certificate you are going use in the authentication. If you 391 have multiple certificates for the same private key, you 392 SHOULD send all of them. 393 394 6) If you do not receive certificate request, you SHOULD NOT 395 send any certificates, unless you have reason to belive that 396 the other end has wrong certificate for you (for example you 397 have enrolled a new certificate recently). 398 399 7) You MAY include extra certificates, CRLs etc if you have 400 them available (I.e include your other certificates also 401 (certificate pre-loading), include sub-CA certificates, 402 include CRLs etc. 403 404Q: retransmission method (implementation issue) 405 how can I realize that the last packet in phase 1 was dropped. 406 main/base mode: 407 no problem in initiator side. 408 responder should wait for the retransmited 5th(3rd) packet 409 from initiator. 410 aggressive mode: 411 responder should wait for the retransmited 2nd packet 412 from responder. 413 quick mode: 414 initiator should wait for the retransmited 2nd packet 415 from responder. 416 when i am initiator, if we don not use commit bit, i will 417 install the SAs after sending last message. 418 419 under the following situation we will see retransmisson of phase 1 3rd 420 packet (prior to the last packet) from the peer, even if we already 421 have started phase 2 negotiaiton: 422 - initiator have transmitted the last (5th) packet of phase 1 exchange. 423 the initiator believes that phase 1 is done. 424 - the last (5th) packet in phase 1 exchange was lost 425 responder retransmits phase 1 N-1 packet 426 main mode 427 FW-1 transmits the last packet in phase 1/2 exchange, 3 times. 428 429Q: retransmission timer? 430 should we manage it in per-peer basis? 431 yup. we may need to 432 RFC2408: change retransmission timer dynamically 433 gets harder to debug... 434 435Q: checks against retransmission 436 check ISAKPM header only (watanabe) 437 check MD5(msg) 438 439Sender: owner-ipsec@lists.tislabs.com 440Message-Id: <200007170936.e6H9a2J113489@thunk.east.sun.com> 441Subject: Re: simplifying rekeying [draft-jenkins-ipsec-rekeying-06.txt] 442From: Bill Sommerfeld <sommerfeld@East.Sun.COM> 443 444 pedants may need to worry about the following case: 445 446 initiator responder 447 | | 448 |-------(1)------->| 449 | | 450 | +--(2)--------| 451 | | | 452 |-------(1)--+ | 453 | | | | 454 |<---+ | | 455 | | | 456 |-------(3)------->| 457 | | | 458 |<------(4)--------| 459 | | | 460 | +---->| 461 | | 462 : : 463 464Q: Nonce size 465 a size of value MUST be 4 - 252 (RFC2409) 466 reject if the value is out-of-range 467 468Q: x.509 certificate and ID payload 469 if there is the certificate and the type of ID payload is 470 not DN, then compare with the subjectAltName in certificate. 471 DN, then compare with the subjectName in certificate. 472 must take care of the order of OID. 473 474Q: IP address of subjectAltName and of real entity. 475 There are two subjectAltName, email and IP address, in the certificate. 476 ID payload includes USER-FQDN, and same to email address of 477 subjectAltName. 478 If IP address of subjectAltName is different from the real entity's 479 IP address. What should we do ? 480 481Q: commit bit 482 who will set the commit bit? when? 483 484 no action. if the other end sets it to 1, we should do that too 485 (sakane) 486 responder should set it to 1. or it may leave it as is (watanabe) 487 488 should revisit rekey draft. 489 490Q: what happens if we have multiple phase 1 SAs for the same src/dst pair? 491 492Q: phase 1 ID payload 493 RSA signature and pre-shared key 494 same ID value. 495 must include the ID into subject alt name. 496 497Q: rekey. 498 - common: IPsec layer always use oldest SA. optionally, send a delete 499 payload for old SA when we got a new SA. 500 - freeswan: trust no informational exchange (including initial-contact). 501 assume everyone will be using the latest SA in IPsec layer. 502 assume that phase 2 responder will install new key when the 503 responder got 1st packet of phase 2 (not the 3rd packet). 504 505Q: for responder side, is it allowed to reorder proposals? for example, 506is it allowed to reply to the following proposal: 507with this: 508 509(initiator sends ESP then AH) 510 51146:51.456226 3ffe:501:ffff:0:250:daff:fe87:4bbe:500 -> 3ffe:501:ffff:0:2a0:ccff:fe3c:4093:500: isakmp 1.0 msgid 3827457a: phase 2/others ? oakley-quick: 512 (hash: len=20) 513 (sa: doi=ipsec situation=identity 514 (p: #1 protoid=ipsec-esp transform=15 spi=058a15c0 515 (t: #1 id=blowfish (type=lifetype value=sec)(type=life value=0e10)(type=enc mode value=transport)(type=keylen value=0080)(type=auth value=hmac-md5)(type=group desc value=modp1024)) 516 (t: #2 id=blowfish (type=lifetype value=sec)(type=life value=0e10)(type=enc mode value=transport)(type=keylen value=0080)(type=auth value=hmac-sha1)(type=group desc value=modp1024)) 517 (t: #3 id=blowfish (type=lifetype value=sec)(type=life value=0e10)(type=enc mode value=transport)(type=keylen value=0080)(type=group desc value=modp1024)) 518 (t: #4 id=3des (type=lifetype value=sec)(type=life value=0e10)(type=enc mode value=transport)(type=auth value=hmac-md5)(type=group desc value=modp1024)) 519 (t: #5 id=3des (type=lifetype value=sec)(type=life value=0e10)(type=enc mode value=transport)(type=auth value=hmac-sha1)(type=group desc value=modp1024)) 520 (t: #6 id=3des (type=lifetype value=sec)(type=life value=0e10)(type=enc mode value=transport)(type=group desc value=modp1024)) 521 (t: #7 id=1des (type=lifetype value=sec)(type=life value=0e10)(type=enc mode value=transport)(type=auth value=hmac-md5)(type=group desc value=modp1024)) 522 (t: #8 id=1des (type=lifetype value=sec)(type=life value=0e10)(type=enc mode value=transport)(type=auth value=hmac-sha1)(type=group desc value=modp1024)) 523 (t: #9 id=1des (type=lifetype value=sec)(type=life value=0e10)(type=enc mode value=transport)(type=group desc value=modp1024)) 524 (t: #10 id=cast (type=lifetype value=sec)(type=life value=0e10)(type=enc mode value=transport)(type=keylen value=0080)(type=auth value=hmac-md5)(type=group desc value=modp1024)) 525 (t: #11 id=cast (type=lifetype value=sec)(type=life value=0e10)(type=enc mode value=transport)(type=keylen value=0080)(type=auth value=hmac-sha1)(type=group desc value=modp1024)) 526 (t: #12 id=cast (type=lifetype value=sec)(type=life value=0e10)(type=enc mode value=transport)(type=keylen value=0080)(type=group desc value=modp1024)) 527 (t: #13 id=null (type=lifetype value=sec)(type=life value=0e10)(type=enc mode value=transport)(type=auth value=hmac-md5)(type=group desc value=modp1024)) 528 (t: #14 id=null (type=lifetype value=sec)(type=life value=0e10)(type=enc mode value=transport)(type=auth value=hmac-sha1)(type=group desc value=modp1024)) 529 (t: #15 id=null (type=lifetype value=sec)(type=life value=0e10)(type=enc mode value=transport)(type=group desc value=modp1024))) 530 (p: #1 protoid=ipsec-ah transform=2 spi=0f316870 531 (t: #1 id=md5 (type=lifetype value=sec)(type=life value=0e10)(type=enc mode value=transport)(type=auth value=hmac-md5)(type=group desc value=modp1024)) 532 (t: #2 id=sha (type=lifetype value=sec)(type=life value=0e10)(type=enc mode value=transport)(type=auth value=hmac-sha1)(type=group desc value=modp1024)))) 533 (nonce: n len=16) 534 (ke: key len=128) 535 (id: idtype=IPv6 protoid=tcp port=0 len=16 3ffe:501:ffff:0:250:daff:fe87:4bbe) 536 (id: idtype=IPv6 protoid=tcp port=0 len=16 3ffe:501:ffff:0:2a0:ccff:fe3c:4093) 537 538(respoinder swap order, sends AH then ESP) 539 54046:53.368883 3ffe:501:ffff:0:2a0:ccff:fe3c:4093:500 -> 3ffe:501:ffff:0:250:daff:fe87:4bbe:500: isakmp 1.0 msgid 3827457a: phase 2/others ? oakley-quick: 541 (hash: len=20) 542 (sa: doi=ipsec situation=identity 543 (p: #1 protoid=ipsec-ah transform=1 spi=f8dc5700 544 (t: #1 id=md5 (type=lifetype value=sec)(type=life value=0e10)(type=enc mode value=transport)(type=auth value=hmac-md5)(type=group desc value=modp1024))) 545 (p: #1 protoid=ipsec-esp transform=1 spi=f8dc5701 546 (t: #4 id=3des (type=lifetype value=sec)(type=life value=0e10)(type=enc mode value=transport)(type=auth value=hmac-md5)(type=group desc value=modp1024)))) 547 (nonce: n len=16) 548 (ke: key len=128) 549 (id: idtype=IPv6 protoid=tcp port=0 len=16 3ffe:501:ffff:0:250:daff:fe87:4bbe) 550 (id: idtype=IPv6 protoid=tcp port=0 len=16 3ffe:501:ffff:0:2a0:ccff:fe3c:4093) 551 552Q: IPComp SA with wellknown CPI in CPI field. how to handle it? 553 with the current code, wellknown CPI will be installed as is, because: 554 - racoon can negotiate an IPComp SA with wellknown CPI, and installs it as is 555 - the kernel have no check about it 556 however, by doing so we will have CPI (SPI) conflict on rekey, or with 557 multiple peers. 558 559 there could be couple of stragegies from implementation point of view 560 (workaround): 561 (1) do not install IPComp SA if we negotiated it with wellknown CPI. 562 this will introduce another trouble: no trigger for rekey, due to 563 no lifetime management on the IPComp SA. 564 (2) install IPComp SA with fabricated (local) CPI, with RAWCPI option flag 565 raised. confusing... 566 (3) use topmost 16 bits to turn wellknown CPI into unique numbers. 567 how to assign numbers? 568 the problem is not unique to racoon, it is a generic problem. 569 protocol-wise, we could have couple of fixes: 570 (1) never negotiate an IPComp SA with a wellknown CPI. 571 (2) disambiguate IPComp SA by using other attributes, like lifetime, 572 installation timestamp or whatever. 573 (3) always IPComp as a addendum to ESP/AH. do not treat it as an independent 574 SA. 575 I'm in favor of (1). 576