question

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

$KAME: question,v 1.28 2003/05/23 05:13:03 sakane Exp $

This was sent to Kivinen and Paul at 20-Sep-2000.

Q: how may policy matters are.  can we interoperate ?

Q. If there is the phase 1 spi size excepting 16 and 0 in SA payload.
	warn it.  and reject or accept ?

Q. ID payload handling in phase 2 besides IPSECDOI_ID_IP*.
   e.g. IPSECDOI_ID_DER_ASN1_DN.  Well, are these used in phase 2 ?

Q. The padding for data attribute.
	in particular, variable-length attribute like ID-userfqdn.

Q. vendorid's hash algorithm
	For aggressive mode ?.
	In main mode, should I use negotiated algorithm ?
A. it's not needed any negotiation.

Q. If we use different hash algorith to compute the value of the vendor id,
   is it possible to be same result of the hash value ?

Q. encryption during aggressive mode.
	when i receive encrypted packet of 2nd message from responder,
	it can be decoded.  When i am responder, should i send encrypted one ?

Q: phase2 PFS and KE payload
	when the responder was not required PFS, if the initiator send KE ?
	if the responder's pfs group is not match to the initiator's one ?
	If initiator requests PFS, should we accept without acceptable check ?
		reject the proposal and quit the phase 2.
		accept it.
	it's policy issue.

Q. If tye type of ID payload is SUBNET, should it be allowed ::1/128 as host
   address ?
A. yes.  consensus at bake-off.

Q. how many proposal can we send ?
	30? 300? infinite ?

Q. Is there only one payload of RESPONDER-LIFETIME in a IKE message
   even if SA bundle is required ?
   At the moment, racoon sends this notify payload(s) against each protocol.

Q. Which is SPI to be used initiator's or responder's when sending
   RESPONDER-LIFETIME ?
A. At the moment, racoon sends responder's one.

Q. Is it typo in the base mode draft ?
            HDR, SA, Idii, Ni_b     =>
                           Ni ???
                                    <= HDR, SA, Idir, Nr_b
                                                      Nr ???
A. Yes, typo. (network associates said.)

Q. What's proto_id in notify message of the responder 2nd message with commit
   bit processing when multiple different SA applyed ?

Q. Is it forbidden to clear commit bit during phase2 negotiation ?
A. not forbidden,

Q. how many time is the notify message sent in phase 2 ?
A. don't resend notify message because peer can use Acknowledged
   Informational if peer requires the reply of the notify message.
Q. phase 1 is ?

Q. What kind of policy configuration is desired?
   policy.conf makes sense in certain situations only, such as:
   - we are the initiator, and trying to enforce certain configuration.

   If we would like to talk with strangers (like IPsec-ready webserver, or
   "IPsec with everyone" configuration), or need to move from place to place
   (like IPsec-ready nomadic node), we need an ability to write "wildcard
   policy entry" which matches situations/packets/whatever, and then install
   non-wildcard policy entry into the kernel.
   For example:
   - policy.conf says 0.0.0.0/0 -> 0.0.0.0/0, protocol "any", type "use",
     for "encrypt everything" configuration.
   - phase 2 ID payload will be exchanged for real address we have, and the
     peer has (a.b.c.d/32).  This is not the same as "0.0.0.0/0" configured
     onto policy entry.
   - with the current code, policy.conf and phase 2 ID does not match, and
     it will fail.

   If we are acting as responder, we will be making policy entry from phase 2
   IDs.  Is it always okay to accept phase 2 IDs as is, into our kernel policy?
   We'll need to have filtering rule, or mapping rules from phase 2 IDs to
   kernel policy.
   For example:
   - we have 10.1.1.0/24 -> 10.1.2.0/24, protocol "any" in policy.conf.
   - what happens if we get, as responder, 10.1.1.0/25 -> 10.1.2.0/25,
     protocol "any"?  should we accept it as is, or should we respect our
     configuration?
     if we respect our configuration, 10.1.1.128/25 -> 10.1.2.128/25 traffic
     will be encrypted from our side, and end up being dropped by the peer.
   - what happens if we get, as responder, 10.1.1.0/24 -> 10.1.2.0/24,
     protocol "tcp"?  should we accept it as is, or should we respect our
     configuration?
     if we respect our configuration, non-tcp traffic will be dropped on
     the peer.

   -> the question is obsoleted by configuration language change.

Q. What's msgid of informational exchange for error notify message during
   phase2 ?  Is it same as msgid of phase2 negotiation caused error ?
   Or new msgid created ?  If later case, spi must be conveyed.
A. new msgid should be used
Q. how can we deduce phase 2 from the notification?
A. see draft-ietf-ipsec-notifymsg-*.txt

Q. I don't know the situation to initiate acknowledged informational.

Q. How many certificate payload in a packet are sent ?
   isakmp-test.ssh.fi send both CRL and CERT in a packet.
A. multiple CERT payload can be sent.  Or use PKCS#7.

Q. What should we do if nonce size is greater than size of RSA modulus
   in authentication with public key encryption, also size of body of
   ID payload ?

Q. For IKE negotiation of IPComp, how should we encode CPI (2 byte) into SPI
   field of proposal payload (for AH/ESP, normally 4 bytes)?
   Options are as follows:
   (1) put it as 4 byte value, set SPI size to 4
                          1                   2                   3
      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ! Next Payload  !   RESERVED    !         Payload Length        !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !  Proposal #   !ProtID = ipcomp!    SPI Size(4)!# of Transforms!
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !                        SPI = 0x0000XXXX                       !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   (2) put it as 2 byte value, set SPI size to 2.  No padding must be made.
                          1                   2                   3
      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ! Next Payload  !   RESERVED    !         Payload Length        !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !  Proposal #   !ProtID = ipcomp!    SPI Size(2)!# of Transforms!
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !       SPI = 0xXXXX            !   ... transform ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IRE did (1), IIRC. (Jan 2000)

   SSH does (2), and rejects (1). (Sep 2000)

   The following email suggests (2) for normal case, and allow (1) for backward
   compatibility (responder case I bet).
	To: [e-mail]
	From: Joern Sierwald <[e-mail]>
	Subject: Re: issues from the bakeoff
	Date: Wed, 16 Jun 1999 11:02:16 +0300
	Message-Id: <[e-mail]>

A: (2) for normal case, and allow (1) for backward compatibility
   (responder case I bet).  <draft-shacham-ippcp-rfc2393bis-05.txt>

Q. INITIAL-CONTACT message.
   When should we send an INITIAL-CONTACT message?
A. see jenkins rekey draft

   We must ignore unencrypted INITIAL-CONTACT message.

   If we have two nodes and they issue the first packet of phase 1 at the same
   time, both may try to transmit INITIAL-CONTACT message, and effectively
   kills both connection attempt.

	node 1			node 2
	  |			  |
	  |----------\  /---------| phase 1 first packet
	  |	      \/	  |
	  |	      /\	  |
	  |<---------/  \-------->|
	  |			  |
	  |----------\  /---------| INITIAL-CONTACT
	  |	      \/	  |
	  |	      /\	  |
	  |<---------/  \-------->|

   Options are as follows:
   (1) don't throw INITIAL-CONTACT message.
   (2) don't delete old phase 1 information, even if we get INITIAL-CONTACT
       message..
   (3) don't delete phase 1 information, if it is very new.  delete phase 1
       information only if they are old.
   (4) implement tie-breaker rule.  for example, compare IP address and remove
       phase 1 initiated by the one who has larger IP address.

Q: IPv6 neighbor discovery.
	When a security policy is set to "all packet require IPsec", it will
	cover IPv6 ND packets as well.  The node will try to secure ND, and
	we will have chicken-and-egg problem (without ND we cannot send IKE
	packets, without IKE negotiation we cannot send ND).

	What can we do?
	- always bypass IPsec policy lookup if a packet is for ND.
	- Security policy should have more detail rules to filter
	  such packet, like icmp6 type/code filters.

Q: When there are no ID payloads in phase 2 ?
A. guess from the pair of address of IKE peer.

Q: Delete payload.
	Which SPI should I carry on Delete notify ?
	There is no documentation.

	An initiator should send a set of SPI of inbound SAs.
	A responder should delete a set of outbound SAs which are sent by
	an initiator.

	When an IKE node deletes old SAs, should it send DELETE notify to
	a peer ?

	When does a node send DELETE notify ?
		when a IKE node deletes old SAs expilicitly.
		when a SA expires (hard lifetime reached).
			It may not be necessary.

	When a DELETE notify packet is dropped, SA will get inconsistent
	between peers.
		We can prevent from it by using "heartbeat" ?

	when there is no phase 1 SA, should I negotiate phase 1 SA before
	sending delete notify ?
	A: no need.  (the consensus made at the mailing list ?)

Q: "heartbeat"
	It means a signal of "I'm alive".
	It is exchanged in phase 1.5.
	When a responder dies/reboots, phase 2 SA sitll remains but
	we can know the rebooting of the peer by using "heartbeat".

	Is INITIAL-CONTACT message useless if we choise "heartbeat" ?
		We don't know.

Q: responder's action in a normal case.
	A responder should never initiate both phase 1 and phase 2 at anytime.
	Once we have decided which side we are (initiator/responder), the
	relationship will never change.

Q: only the byte type of lifetime on phase 2, not exist the type of time.
	No ducumentation states explicitly.
	We can choose to use default lifetime (28800).
	We can reject it accortding to a policy.

Q: phase 2 lifetime negotiation
	what should I do if the peer has proposed the lifetime value which
	does not match to our policy ?
	- always reject it.
	- use my lifetime, then send RESPONDER LIFETIME.
	- during negotiation obey the initiator.  install SA lifetime based
	  on the lifetime we have decided (not from the negotiation).

Q: phase 1 lifetime negotiation
	can we do like phase 2 ?

Q: Does RFC2407 4.5.4 Lifetime Notification say for phase 2 ? or phase 1 ?
	responder lifetime may be inapproprite for phase1 because
	proposal is not encrypted, so bad guy can forge it.

Q: phase 1 lifetime of bytes.
	What should we count ?
	Or it should be obsoleted ?

Q: phase 2 lifetime of bytes.
	byte lifetime of an SA is harder to implement/manipulate than
	wallclock lifetime, because:
	- if there's packet losses on the link, it will lead to disagreement
	  between peers about how much traffic were gone through the SA.
	- it is unclear when to compute the lifetime.  for example, for IPComp,
	  there's a big difference between computing byte lifetime before
	  compression, or after compression.  [RFC2401 page 23:
	  should compute byte lifetime using a packet BEFORE IPsec processing]

	it is more questionable to use byte lifetime for inbound SA, than
	for outbound SA.  we will have more problem if we expire inbound SA
	earlier than the peer (if we expire an SA earlier than the peer,
	inbound traffic will result in "no SA found" error).

Q: soft and hard lifetime. [RFC2401 page 23]
	RFC2401 talks about soft and hard lifetime.  for stable rekeying
	operation, it may help if we introduce another kind of lifetime;

	soft lifetime (80% of hard lifetime, for example):