Re: granularity property in Common Information Model

[Eric Vyncke <evyncke@xxxxxxxxx>]

Rick,

Obviously both the I-D and my previous email messages are not crystal clear :-(

(I share your comment between parenthesis about the applicable phase 2 ID, 
for me this could possibly be IPV[46] address, subnet or range of addresses).

Section 4.6.2 of RFC 2407 specifies the possible formats for an ID payload. 
While it clearly says that IP protocol type and port is to be set to 0 or 
to UDP port 500 for phase 1 ID, it also says that protocol type and port 
can be set to 0 (with 0 meaning wild card) or to a specific value for phase 
2 ID.

Let's do it with an example, the 'triggering' packet is from 192.168.1.1 
TCP/1024 to 10.1.1.1 TCP/80, the SACondition filter is any source IP from 
192.168.1.* to 10.*.*.*, then depending on the granularity, IKE should 
negotiate phase 2 SA for the following phase 2 ID:
- subnet -> <192.168.1.*,protocol=0,port=0> & <10.*.*.*,protocol=0,port=0> 
for all protocols using ID_IPV4_ADDR_SUBNET format;
- host -> <192.168.1.1,protocol=0,port=0> & <10.1.1.1,,protocol=0,port=0> 
for all protocols using ID_IPV4_ADDR format;
- protocol -> <192.168.1.1,protocol=6,port=0> & 
<10.1.1.1,protocol=6,port=0> for all TCP ports using ID_IPV4_ADDR format;
- port -> <192.168.1.1,protocol=6,port=1024> & 
<10.1.1.1,protocol=6,port=80) only for the triggering TCP flow using 
ID_IPV4_ADDR format;

On purpose, we simplified the information model by removing some possible 
variations (like subnet on one side and address on the other side) because 
we feel that no implementation are using those variations. Of course, we 
can be wrong and the model could always be improved.

NB: there is currently no provision in the IM to model a phase 2 of 
ID_IPV4_ADDR_RANGE which may be a concern if some implementations are using 
this kind of ID (and some recent troubleshooting between Cisco and Redcreek 
concentrators make believe that you are using address ranges ;-) ). If 
needed, we could also extend the IM to represent an address range as a 
phase 2 ID.

Anyway, if you believe that the above explanation is clearer, I would be 
glad to augment the I-D with it.

Hope this helps

-eric



At 09:37 20/03/2001 -0700, Ricky Charlet wrote:
> Thanks Eric,
>
>         I see your point that the phase 2 ID needs to be specified as to 
> type.
> I had not thought of that before.
>
>         But, the granularity property in the IPsecAction (what do we call it,
> object, group, table, thingie?) seems to me to be mismatched with the
> set of possible 2 ID types. Specifically, we do not need ports and
> protocols in phase 2 IDs but on the other hand, we do need specific
> addresses, subnets, and ranges of addresses in IPv4 and IPv6. (I don't
> know if FQDN, user@FQDN, DN, GN, and keyID are supportable as phase 2
> IDs, could someone else inform our disussion here. I don't see any thing
> saying they can not be used at phase 2, but I also don't see how data,
> not verifiable in a packet, could be used as a phase 2 ID.) In the case
> of subnets and ranges of addresses, these cannot be inferred from a
> packet-on-hand and a granularity property.
>
>         So now I am left with my original request and a new question. Can we
> please provide filtering control for ports and protocols? And now, how
> should we know what client ID to use in (and the type of) the phase 2
> Identification payload?

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