should inform IKE of the expiry, and IKE should try to negotiate		a new SA.	deprecation lifetime (90%):		no outbound packet should be generated by this SA.		inbound packet is handled okay.	hard lifetime (100%)		SA will be erased.Q: responder should not modify phase 2 attributes	even for phase 1, we should not modify attributes.	for lifetime attributes, it is okay to switch between V/B format.	draft-ietf-ipsec-ike-01.txt Appendix A:	If this is the case, an	attribute offered as variable (or basic) by the initiator of this	protocol MAY be returned to the initiator as a basic (or variable).Q: check if reserved field is zero, reject if 	we should do this (sakane)	i don't think so, it will kill future protocol enhancements (itojun)Q: order of proposals in IKE phase 2 packet, and IPsec processing order	how to negotiate SA bundle.	IKE: esp+ah, or ah+esp		-> is it safe to consider both as IP|AH|ESP|ULP?		-> is the proposal prefered to send the order of ah+esp.	IKE: ah+ah?		reject? or policy issue.	RFC2401bis should state the pattern of SA bundle.	      AH	      AH+ESP	      AH    +IPCOMP	      AH+ESP+IPCOMP		 ESP	      AH+ESP	      AH+ESP+IPCOMP		 ESP+IPCOMP	      AH+ESP	      AH+ESP+IPCOMP	Also RFC2401bis should state the meaning of protcol mode.	we are going to install both SAs, ESP and AH.  and they are bundled.	we should negotiate both SAs in single phase2.	can we do that separately ?		it is hard to verify the policy because the policy might be		defined SA bundle.	when i make packet IP2|AH|ESP|IP1|ULP.		proposal and order must be			ah/transport + esp/tunnel ?			ah/tunnel + esp/tunnel ?Q: what should we do if phase 1 SA expires, during phase2 SA negotiation?A. restart phase 2 negotiation from scratchQ: what kind of notification message a node should send on decode failure?	ISAKMP_NTYPE_INVALID_PAYLOAD_TYPE		iked	ISAKMP_NTYPE_UNEQUAL_PAYLOAD_LENGTHS		racoon	ISAKMP_NTYPE_PAYLOAD_MALFORMED		sanity check would be hairyQ: Certificate Request.	where to attach CR?		obey draft-ietf-ipsec-pki-req-05.txt.	what should we put inside CR?		my own signer?	RFC2408 page 34 says;    o  Certificate Authority (variable length) - Contains an encoding of       an acceptable certificate authority for the type of certificate       requested.  As an example, for an X.509 certificate this field       would contain the Distinguished Name encoding of the Issuer Name       of an X.509 certificate authority acceptable to the sender of       this payload.  This would be included to assist the responder in       determining how much of the certificate chain would need to be       sent in response to this request.  If there is no specific       certificate authority requested, this field SHOULD not be       included.Message-Id: <200009262047.XAA10637@torni.hel.fi.ssh.com>Subject: CERT_REQ_PAYLOAD usageFrom: Tero Kivinen <kivinen@ssh.fi>Date: Tue, 26 Sep 2000 23:47:00 +0300 (EET DST)	1) If you absolutely need certificates from the other side for	the authentication to work, you MUST send certificate request	payload.	2) If the authentication can succeed without the other end	sending certificates (you have some certificate for the other	end, or you can fetch the certificate from the certificate	repository), you MAY send certificate request.	3) If you just want any certificate without specifying the CA	root, send certificate request having empty CA name.	4) When you receive certificate request you MUST send your own	certificate for that CA.	5) If you receive empty certificate request you MUST send the	certificate you are going use in the authentication. If you	have multiple certificates for the same private key, you	SHOULD send all of them.	6) If you do not receive certificate request, you SHOULD NOT	send any certificates, unless you have reason to belive that	the other end has wrong certificate for you (for example you	have enrolled a new certificate recently).	7) You MAY include extra certificates, CRLs etc if you have	them available (I.e include your other certificates also	(certificate pre-loading), include sub-CA certificates,	include CRLs etc.Q: retransmission method (implementation issue)	how can I realize that the last packet in phase 1 was dropped.	main/base mode:		no problem in initiator side.		responder should wait for the retransmited 5th(3rd) packet		from initiator.	aggressive mode:		responder should wait for the retransmited 2nd packet		from responder.	quick mode:		initiator should wait for the retransmited 2nd packet		from responder.		when i am initiator, if we don not use commit bit, i will		install the SAs after sending last message.	under the following situation we will see retransmisson of phase 1 3rd	packet (prior to the last packet) from the peer, even if we already	have started phase 2 negotiaiton:	- initiator have transmitted the last (5th) packet of phase 1 exchange.	  the initiator believes that phase 1 is done.	- the last (5th) packet in phase 1 exchange was lost	responder retransmits phase 1 N-1 packet		main mode	FW-1 transmits the last packet in phase 1/2 exchange, 3 times.Q: retransmission timer?	should we manage it in per-peer basis?		yup.  we may need to	RFC2408: change retransmission timer dynamically		gets harder to debug...Q: checks against retransmission	check ISAKPM header only (watanabe)	check MD5(msg)Sender: owner-ipsec@lists.tislabs.comMessage-Id: <200007170936.e6H9a2J113489@thunk.east.sun.com>Subject: Re: simplifying rekeying [draft-jenkins-ipsec-rekeying-06.txt]From: Bill Sommerfeld <sommerfeld@East.Sun.COM>	pedants may need to worry about the following case:            initiator          responder		|                  |		|-------(1)------->|		|                  |		|    +--(2)--------|		|    |             |		|-------(1)--+     |		|    |       |     |		|<---+       |     |		|            |     |		|-------(3)------->|		|            |     |		|<------(4)--------|		|            |     |		|            +---->|		|                  |		:                  :Q: Nonce size	a size of value MUST be 4 - 252 (RFC2409)	reject if the value is out-of-rangeQ: x.509 certificate and ID payload	if there is the certificate and the type of ID payload is		not DN, then compare with the subjectAltName in certificate.		DN, then compare with the subjectName in certificate.			must take care of the order of OID.Q: IP address of subjectAltName and of real entity.	There are two subjectAltName, email and IP address, in the certificate.	ID payload includes USER-FQDN, and same to email address of	subjectAltName.	If IP address of subjectAltName is different from the real entity's	IP address.  What should we do ?Q: commit bit	who will set the commit bit?  when?	no action.  if the other end sets it to 1, we should do that too	(sakane)	responder should set it to 1.  or it may leave it as is (watanabe)	should revisit rekey draft.Q: what happens if we have multiple phase 1 SAs for the same src/dst pair?Q: phase 1 ID payload	RSA signature and pre-shared key	same ID value.	must include the ID into subject alt name.Q: rekey.	- common: IPsec layer always use oldest SA.  optionally, send a delete		payload for old SA when we got a new SA.	- freeswan: trust no informational exchange (including initial-contact).		assume everyone will be using the latest SA in IPsec layer.		assume that phase 2 responder will install new key when the		responder got 1st packet of phase 2 (not the 3rd packet).Q: for responder side, is it allowed to reorder proposals?  for example,is it allowed to reply to the following proposal:with this:(initiator sends ESP then AH)46: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:    (hash: len=20)    (sa: doi=ipsec situation=identity        (p: #1 protoid=ipsec-esp transform=15 spi=058a15c0            (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))            (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))            (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))            (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))            (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))            (t: #6 id=3des (type=lifetype value=sec)(type=life value=0e10)(type=enc mode value=transport)(type=group desc value=modp1024))            (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))            (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))            (t: #9 id=1des (type=lifetype value=sec)(type=life value=0e10)(type=enc mode value=transport)(type=group desc value=modp1024))            (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))            (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))            (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))            (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))            (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))            (t: #15 id=null (type=lifetype value=sec)(type=life value=0e10)(type=enc mode value=transport)(type=group desc value=modp1024)))        (p: #1 protoid=ipsec-ah transform=2 spi=0f316870            (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))            (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))))    (nonce: n len=16)    (ke: key len=128)    (id: idtype=IPv6 protoid=tcp port=0 len=16 3ffe:501:ffff:0:250:daff:fe87:4bbe)    (id: idtype=IPv6 protoid=tcp port=0 len=16 3ffe:501:ffff:0:2a0:ccff:fe3c:4093)(respoinder swap order, sends AH then ESP)46: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:    (hash: len=20)    (sa: doi=ipsec situation=identity        (p: #1 protoid=ipsec-ah transform=1 spi=f8dc5700            (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)))        (p: #1 protoid=ipsec-esp transform=1 spi=f8dc5701            (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))))    (nonce: n len=16)    (ke: key len=128)    (id: idtype=IPv6 protoid=tcp port=0 len=16 3ffe:501:ffff:0:250:daff:fe87:4bbe)    (id: idtype=IPv6 protoid=tcp port=0 len=16 3ffe:501:ffff:0:2a0:ccff:fe3c:4093)Q: IPComp SA with wellknown CPI in CPI field.  how to handle it?  with the current code, wellknown CPI will be installed as is, because:  - racoon can negotiate an IPComp SA with wellknown CPI, and installs it as is  - the kernel have no check about it  however, by doing so we will have CPI (SPI) conflict on rekey, or with  multiple peers.  there could be couple of stragegies from implementation point of view  (workaround):  (1) do not install IPComp SA if we negotiated it with wellknown CPI.      this will introduce another trouble: no trigger for rekey, due to      no lifetime management on the IPComp SA.  (2) install IPComp SA with fabricated (local) CPI, with RAWCPI option flag      raised.  confusing...  (3) use topmost 16 bits to turn wellknown CPI into unique numbers.      how to assign numbers?  the problem is not unique to racoon, it is a generic problem.  protocol-wise, we could have couple of fixes:  (1) never negotiate an IPComp SA with a wellknown CPI.  (2) disambiguate IPComp SA by using other attributes, like lifetime,      installation timestamp or whatever.  (3) always IPComp as a addendum to ESP/AH.  do not treat it as an independent      SA.  I'm in favor of (1).