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

Re: granularity property in Common Information Model



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