Re: Move TS to optional (RE: Don't remove TS from IKEv2)

[Markku Savela <msa@burp.tkv.asdf.org>]

> From: "sankar ramamoorthi" <sankar@nexsi.com>

> Another alternative worth considering is to do policy change
> inband to ipsec traffic.

NO! NO! You cannot change policy from IKE.

There is some serious misunderstanding about what policy is.

In my view policy can never be changed as a result of IKE
negotiation. That would be a huge security hole.

Surely you are not suggesting something like if, I have

  selector -> require ESP with 3DES

IKE negotiation could change this  into

  selector -> allow data in clear

!!!

Apparently other people include into policy what I would just consider
SA parameters (which look like selectors). These parameters are used
to distinguish different SA's between same nodes.

This is related to text "4.4.1 The Security Policy Database (SPD)"

-----------------
            ....  For each selector, the policy entry specifies how
   to derive the corresponding values for a new Security Association
   Database (SAD, see Section 4.4.3) entry from those in the SPD and the
   packet (Note that at present, ranges are only supported for IP
   addresses; but wildcarding can be expressed for all selectors):

   a. use the value in the packet itself -- This will limit use
      of the SA to those packets which have this packet's value
      for the selector even if the selector for the policy entry
      has a range of allowed values or a wildcard for this
      selector.

   b. use the value associated with the policy entry -- If this
      were to be just a single value, then there would be no
      difference between (b) and (a).  However, if the allowed
      values for the selector are a range (for IP addresses) or
      wildcard, then in the case of a range,(b) would enable use
      of the SA by any packet with a selector value within the
      range not just by packets with the selector value of the
      packet that triggered the creation of the SA.  In the case
      of a wildcard, (b) would allow use of the SA by packets
      with any value for this selector.

And in "4.4.3 Security Association Database (SAD)"

   ....
   For each of the selectors defined in Section 4.4.2, the SA entry in
   the SAD MUST contain the value or values which were negotiated at the
   time the SA was created.  For the sender, these values are used to
   decide whether a given SA is appropriate for use with an outbound
   packet.  This is part of checking to see if there is an existing SA
   ...
-----------------------

That is, the negotiated values are put into SA, not into SPD. There is
*NOTHING* in IKE negotiation that needs to be put into SPD!