<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content="text/html; charset=iso-8859-1" http-equiv=Content-Type>
<META name=GENERATOR content="MSHTML 8.00.6001.19019">
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT size=2 face="MS Sans Serif">Dear Experts,</FONT></DIV>
<DIV><FONT face="MS Sans Serif"></FONT> </DIV>
<DIV><FONT face="MS Sans Serif">I ran into a ESP dh-group mismatch problem in
StrongSwan 4.4.1. Re-tested the scenario in 4.6.1 with same
results.</FONT></DIV>
<DIV><FONT face="MS Sans Serif">The esp (and ike) transforms of the peers are as
follow:</FONT></DIV>
<DIV><FONT face="MS Sans Serif"></FONT> </DIV>
<DIV><FONT face="MS Sans Serif">host65</FONT></DIV>
<DIV><FONT face="MS Sans Serif">========</FONT></DIV>
<DIV><FONT size=2
face="MS Sans Serif"> ike=3des-sha2_384-modp1024!<BR> esp=aes128-sha1-ecp256!</FONT></DIV>
<DIV><FONT face="MS Sans Serif"></FONT> </DIV>
<DIV><FONT face="MS Sans Serif">host118</FONT></DIV>
<DIV><FONT face="MS Sans Serif">==========</FONT></DIV>
<DIV><FONT size=2
face="MS Sans Serif"> ike=3des-sha2_384-modp1024!<BR> esp=aes128-sha1-modp2048!</FONT></DIV>
<DIV><FONT face="MS Sans Serif"></FONT> </DIV>
<DIV><FONT face="MS Sans Serif">When host118 initiated the connection, both
sides said that they received ESP proposal with </FONT><FONT
face="MS Sans Serif">no dhgroup:</FONT></DIV>
<DIV><FONT face="MS Sans Serif"></FONT> </DIV>
<DIV><FONT size=2 face="MS Sans Serif">192.168.12.65
side<BR>===================<BR>Jul 21 19:29:56 host65 charon: 16[IKE] maximum
IKE_SA lifetime 28267s<BR>Jul 21 19:29:56 host65 charon: 16[CFG] selecting
proposal:<BR>Jul 21 19:29:56 host65 charon: 16[CFG] proposal matches
<BR>Jul 21 19:29:56 host65 charon: 16[CFG] received proposals:
ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ<BR>Jul 21 19:29:56 host65 charon:
16[CFG] configured proposals:
ESP:AES_CBC_128/HMAC_SHA1_96/ECP_256/NO_EXT_SEQ<BR>Jul 21 19:29:56 host65
charon: 16[CFG] selected proposal:
ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ</FONT></DIV>
<DIV><FONT size=2 face="MS Sans Serif"></FONT> </DIV>
<DIV><FONT size=2 face="MS Sans Serif">192.168.12.118
side<BR>===================<BR>Jul 21 19:29:56 host118 charon: 16[CFG] selecting
proposal:<BR>Jul 21 19:29:56 host118 charon: 16[CFG] proposal
matches<BR>Jul 21 19:29:56 host118 charon: 16[CFG] received proposals:
ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ<BR>Jul 21 19:29:56 host118 charon:
16[CFG] configured proposals:
ESP:AES_CBC_128/HMAC_SHA1_96/MODP_2048/NO_EXT_SEQ<BR>Jul 21 19:29:56 host118
charon: 16[CFG] selected proposal:
ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ</FONT></DIV>
<DIV><FONT face="MS Sans Serif"></FONT> </DIV>
<DIV><FONT face="MS Sans Serif">Despite in strict mode, the log said that
they chose the received proposal with no dh-group.</FONT></DIV>
<DIV><FONT face="MS Sans Serif"></FONT> </DIV>
<DIV><FONT face="MS Sans Serif">Not so amiable at re-key time:</FONT></DIV>
<DIV><FONT face="MS Sans Serif">=======================</FONT></DIV>
<DIV><FONT face="MS Sans Serif">Jul 21 20:12:59 host118 charon: 12[CFG]
selecting proposal:<BR>Jul 21 20:12:59 host118 charon: 12[CFG] no
acceptable DIFFIE_HELLMAN_GROUP found<BR>Jul 21 20:12:59 host118 charon: 12[CFG]
received proposals: ESP:AES_CBC_128/HMAC_SHA1_96/ECP_256/NO_EXT_SEQ<BR>Jul 21
20:12:59 host118 charon: 12[CFG] configured proposals:
ESP:AES_CBC_128/HMAC_SHA1_96/MODP_2048/NO_EXT_SEQ<BR>Jul 21 20:12:59 host118
charon: 12[IKE] no acceptable proposal found<BR>Jul 21 20:12:59 host118 charon:
12[IKE] failed to establish CHILD_SA, keeping IKE_SA</FONT></DIV>
<DIV><FONT face="MS Sans Serif"></FONT> </DIV>
<DIV><FONT face="MS Sans Serif">This left the tunnel in a peculiar
state.</FONT></DIV>
<DIV><FONT face="MS Sans Serif"></FONT> </DIV>
<DIV><FONT face="MS Sans Serif">Question 1:</FONT></DIV>
<DIV><FONT face="MS Sans Serif">Is there anything I can do (in terms of messing
with strongswan.conf or ipsec.conf or changing charon code) to make the
mismatch detected at setup time?</FONT></DIV>
<DIV><FONT face="MS Sans Serif"></FONT> </DIV>
<DIV><FONT face="MS Sans Serif">But problem seems a match with the last
paragraph in Section 1.2 of RFC 5996:</FONT></DIV>
<DIV><FONT face="MS Sans Serif"><PRE>IKE_AUTH does not contain KE or Nounce payloads... IKE_AUTH exchange cannot contain Transform Type 4 (Diffie-Hellman group) with any value other than NONE.</PRE></FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=2 face="MS Sans Serif">Question 2:</FONT></DIV>
<DIV><FONT face="MS Sans Serif">If this is indeed a RFC standard problem, is it
possible to configure StrongSwan to not include the SA2i, SA2r in IKE_AUTH?
Instead do a standalone create_child_sa exchange. NB: our nodes only talk to
StrongSwan that are compiled in-house. We don't interop with other
implementations very often.</FONT></DIV>
<DIV><FONT face="MS Sans Serif"></FONT> </DIV>
<DIV><FONT face="MS Sans Serif">Question 3:</FONT></DIV>
<DIV><FONT face="MS Sans Serif">Another option: I can append a no dh-group
proposal to esp, i.e.</FONT></DIV>
<DIV><FONT face="MS Sans Serif">esp=aes128-sha1-ecp256,aes128-sha1!</FONT></DIV>
<DIV><FONT face="MS Sans Serif">Thus at re-key time, hopefully the no dh-group
proposal will act as a safety net.</FONT></DIV>
<DIV><FONT face="MS Sans Serif">Question is, will ecp256 be the first
choice at re-key time? Or will the no dh-group proposal take
precedence because, at IKE INIT time it matches? (The one with dh-group can
never match if my interpretion of rfc5996 is right.)</FONT></DIV>
<DIV><FONT face="MS Sans Serif"></FONT> </DIV>
<DIV><FONT face="MS Sans Serif">Question 4:</FONT></DIV>
<DIV><FONT face="MS Sans Serif">Another thing I can do is ban dh-group in
ESP altogehter. Man page and RFC 5996 all said that will make
the connection less secure. Is there anything I can to mitigate the
risk? E.g. make the ikelifetime shorter than keylifetime so that
at re-key time SK_d is fresh.</FONT></DIV>
<DIV><FONT face="MS Sans Serif"></FONT> </DIV>
<DIV><FONT face="MS Sans Serif">Thanks in advance for help.</FONT></DIV>
<DIV><FONT face="MS Sans Serif">Simon</FONT></DIV></BODY></HTML>