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

[Stephen Kent <kent@bbn.com>]

At 10:03 PM +0200 3/26/02, Markku Savela wrote:
>  > 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!

As the author of this text, let me try to clarify a few things:

	- the term "policy" is used in many ways by many folks. high 
level security policy is usually expressed in natural language and 
thus is not suitable as a basis for automated enforcement in security 
technology. low level security policy is directly enforceable by such 
technology, and that is what the SPD represents. One could imagine an 
intermediate form of policy expression, which may be (I'm not sure) 
what IPSP addresses. in any case, I think the use of the term 
"policy" is appropriate for what the SPD does.

	- the symbolic selector values that are permitted in the SPD 
are intended to represent IP address selectors, with the intent that 
they be transformed into transient SPD entries, as well as SAD 
entries, as a side effect of the IKE exchanges.  It's clear that 
symbolic values cannot be directly matched against packet headers, 
yet 2401 mandates checking against such headers for both outbound and 
inbound SA traffic. In the rev of 2401 we will introduce the notion 
of an SPD cache, and using that model, we will do a better job of 
describing how a symbolic value in an SPD entry is transformed into 
an SPD cache entry, rather than talking about a transient or 
temporary SPD entry. I think this will clarify what we envisioned.

	- since the above example does involve (under the current 
2401 description) dynamic modification of the SPD, I would not argue 
that such modification is prohibited by 2401.  IPSP has discussed 
dynamic modification of the SPD as a result of a policy negotiation, 
so that notion is embraced by others as well.  I would like to see a 
way to deal with these sorts of protocols as we progress, in a 
fashion consistent with the revised 2401 model we're developing, and 
I solicit suggestions on how to do this.

Steve