Subject: 2401bis Issue # 82 -- Creation of SAs -- clarifications

From: Karen Seo <[email-masked]>
Date: Tue, 30 Sep 2003 01:49:07 -0400

Folks,

Here's a description and proposed approach for:

IPsec Issue #:	82

Title:		Creation of SAs -- clarifications

Description:
============
2401's text on the SPD currently says:

"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."

[Note that in IPsec issue 47, it was proposed that all selectors can 
be a list of ranges, per IKEv2 spec.]

A number of questions have arisen about the 2 options above, in 
particular for Option a -- use the value in the packet.  We need to 
clarify how the SPD entries can be used to create SAs for various 
combinations of selectors, e.g., to ensure creation of separately 
key'd SAs for each pair of hosts.

Proposed approach:
==================
Clarify the text about the SPD to say that Option (a) for 
instantiating selectors when creating an SA (use the value in the 
packet itself)...

"can not only be used to create per-host, per-port, or per-protocol 
keyed SAs, but also to create new SAs based upon unique values of any 
set of selectors."

Note: For implementors using decorrelation, there will be an appendix 
with implementor's notes describing how to avoid creating any 
unnecessary SAs for a set of decorrelated SPD entries created from 
the same original correlated SPD entry when one or more selector 
values are populated from subscriber traffic.

Thank you,
Karen

---

From: Ravi Kumar <[email-masked]>
Date: Tue, 30 Sep 2003 17:04:30 +0530

Hi,
      I feel, clarification on QM ID payload contents and their 
interpretation when
     SP is configured to use packet selectors.
     SP(Security Policy) can be configured with IP address ranges or subnet 
along with
     these as Packet selectors. As a QM initiator, it needs to send the 
packet IP address
     to the remote SG. Remote SG should not reject this ID, if it falls in 
SP selector space
    when configured with Packet Selector option. It seems that some 
implementations
    reject the QM if the ID contents don't match exactly with what is 
configured in the SP.
    This is OK when SP is configured with Policy selectors, but not when 
configured with
     Packet selectors.

    I feel this needs to be clarified in 2401bis.
   Thanks
   Ravi

At 01:49 AM 9/30/03 -0400, Karen Seo wrote:
>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):
>
>[Note that in IPsec issue 47, it was proposed that all selectors can be a 
>list of ranges, per IKEv2 spec.]
>
>A number of questions have arisen about the 2 options above, in particular 
>for Option a -- use the value in the packet.  We need to clarify how the 
>SPD entries can be used to create SAs for various combinations of 
>selectors, e.g., to ensure creation of separately key'd SAs for each pair 
>of hosts.
>
>
>Proposed approach:
>==================
>Clarify the text about the SPD to say that Option (a) for instantiating 
>selectors when creating an SA (use the value in the packet itself)...
>
>"can not only be used to create per-host, per-port, or per-protocol keyed 
>SAs, but also to create new SAs based upon unique values of any set of 
>selectors."
>
>Note: For implementors using decorrelation, there will be an appendix with 
>implementor's notes describing how to avoid creating any unnecessary SAs 
>for a set of decorrelated SPD entries created from the same original 
>correlated SPD entry when one or more selector values are populated from 
>subscriber traffic.
>
>Thank you,
>Karen

The Views Presented in this mail are completely mine. The company is not 
responsible for what so ever.

----------
Ravi Kumar CH
Rendezvous On Chip (I) Pvt Ltd
Hyderabad, INDIA

ROC HOME PAGE:
http://www.roc.co.in