question

Linux 2.6 内核上配置IPSec VPN 的工具

		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 scratch

Q: 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 hairy

Q: 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: <[e-mail]>
Subject: CERT_REQ_PAYLOAD usage
From: Tero Kivinen <[e-mail]>
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: [e-mail]
Message-Id: <[e-mail]>
Subject: Re: simplifying rekeying [draft-jenkins-ipsec-rekeying-06.txt]
From: Bill Sommerfeld <[e-mail]>

	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-range

Q: 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).