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

[Ravi Kumar <ravivsn@roc.co.in>]

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

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