[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