Subject: RE: IPsecAction granularity again

From: "Jason, Jamie" <[email-masked]>
Date: Thu, 15 Feb 2001 09:47:49 -0800

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: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, February 14, 2001 10:56 AM
> To: [email-masked]
> 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
> [email-masked]
> phone 1-781-993-3923
> GSM 1-781-492-2850 
> 
> -----Original Message-----
> From: ext Lee Rafalow [mailto:[email-masked]]
> Sent: Wednesday, January 10, 2001 10:46 AM
> To: [email-masked]
> 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" <[email-masked]>
> To: ".ipsec-policy" <[email-masked]>
> 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
>

---

From: Eric Vyncke <[email-masked]>
Date: Fri, 16 Feb 2001 14:31:04 +0100

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

>> > the Filter Entry side and not in an IPsecAction.

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

---

From: Ricky Charlet <[email-masked]>
Date: Fri, 16 Feb 2001 16:00:42 -0700

Howdy,

	I still content that granularity does not belong over in the Action
side of the house. It is confusing. Someone should be able to justify
the value of putting a part of the selector definition over with the
actions or we should move it back into the conditions.

--
Ricky Charlet