[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: IPsecAction granularity again



Jamie

Except for the IP address range which was overlooked, I believe that the
4 choices cover all real life implementations. We could possibly argue
that the wild card is to be applied on one side only of the 5-tuple
(i.e. from my local IP address to all your remote subnet). If so,
the granularity property should rather be a 5-tuple mask.

Just my 0.01 EUR

-eric

At 09:47 15/02/01 -0800, Jason, Jamie wrote:
>In the next version of the model, the granularity enumeration has 4
>different values.
>
>1.  use the subnet from the filter that matched...although I think that this
>may have to be reworded to also include if the filter has an address range.
>I need to look into the filter entry from CIM again to see what it has in
>it.
>2.  use the IP addresses from the packet that triggered the action, i.e.,
>wildcard the IP protocol and the ports.
>3.  use the IP addresses and IP protocol from the packet, i.e., wildcard the
>ports if the IP protocol is a layer-4 protocol which uses ports.
>4.  use the IP addresses, IP protocol, and ports (if there are layer 4
>ports) from the packet that triggered the action.
>
>So, (1) above corresponds to (b) and (4) corresponds to (a) below.  (2) and
>(3) are kind in the middle.
>
>Although I am beginning to wonder if these are sufficient...I'll have to get
>back to you on that.
>
>Jamie
>
>> -----Original Message-----
>> From: Man.M.Li@xxxxxxxxx [mailto:Man.M.Li@xxxxxxxxx]
>> Sent: Wednesday, February 14, 2001 10:56 AM
>> To: ipsec-policy@xxxxxxxx
>> Subject: IPsecAction granularity again
>> 
>> 
>> Hi,
>> 
>> I think the ietf IPsec information model uses the granularity 
>> in a different
>> way and that is the way I like. Correct me Jamie if I 
>> mis-understand the
>> intention. The granularity is used to indicate the following function
>> specified in Section 4.4.1. RFC2401:
>> 
>> "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."
>> 
>> In the ietf IPsec info model, the granularity is in the 
>> filter list and has
>> two choices: narrow and wide that correspond to (a) and (b).
>> 
>> 
>> Man Li
>> Nokia 
>> 5 Wayside Road, Burlington, MA 01803
>> man.m.li@xxxxxxxxx
>> phone 1-781-993-3923
>> GSM 1-781-492-2850 
>> 
>> -----Original Message-----
>> From: ext Lee Rafalow [mailto:rafalow@xxxxxxxxxxxxxxx]
>> Sent: Wednesday, January 10, 2001 10:46 AM
>> To: ipsec-policy@xxxxxxxx
>> Cc: tm-ipsec
>> Subject: Re: IPsecAction granularity
>> 
>> 
>> Ricky, Here's the reasoning for its location in the model.
>> 
>> The conditions (filters) are used to determine which rule applies to a
>> packet (for which there's currently no SA).  As with other action
>> properties, the granularity is used to determine how to 
>> negotiate and build
>> the SA.  In this case, the granularity is used (in 
>> conjunction with the
>> filters) to determine the selector for a given IPsec SA.
>> 
>> So, the same rule can be evaluated (i.e., filter) and yield different
>> selectors.
>> 
>> IHTH.  Lee
>> 
>> ----- Original Message -----
>> From: "Ricky Charlet" <rcharlet@xxxxxxxxxxxx>
>> To: ".ipsec-policy" <ipsec-policy@xxxxxxxx>
>> Sent: Tuesday, January 09, 2001 7:30 PM
>> Subject: ICIM: IPsecAction granularity
>> 
>> 
>> > Howdy,
>> >
>> > I dislike the granularity property of IPsecActions. It 
>> purports to be
>> > controlling whether subnet mask, or protocol, or port 
>> fields should be
>> > wild-carded in SA Proposals. And this makes the granularity property
>> > part of a selector. I think any property of a selector 
>> should be over on
>> > the Filter Entry side and not in an IPsecAction.
>> >
>> >
>> > --
>> >   Ricky Charlet   : Redcreek Communications   : usa (510) 795-6903
>> 

Eric Vyncke                        
Distinguished Engineer             Cisco Systems EMEA
Phone:  +32-2-778.4677             Fax:    +32-2-778.4300
E-mail: evyncke@xxxxxxxxx          Mobile: +32-475-312.458 (CHANGED)
PGP fingerprint: D35F BEF9 643F 656F 90F5  76C5 9CA1 C289 D398 B141