[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: proposed changes to ISAKMP/Oakley
In message <v03102807b0727cf0c4f3@[128.89.0.110]>, Stephen Kent writes:
>
> What I proposed for inbound processing does not require a separate SA per
> network pair. It requires that the receiver check the inbound packets
> against the set of selectors used to map traffic to the SA in question.
> So, if one maps traffic for a range of IP addresses to a single SA, one
> checks to make sure that the packets emitted from that SA contain an IP
> source address consistent with the selector set. This is not just a VPN
> issue, the same concerns apply to host SAs.
I understand this. The arch document is fine; the problem is ISAKMP proxy
IDs and how the relate to SA policy. My policy engine supports this kind of
discrimination and check, at least for IP addresses. My issues are:
1) other people appear to be expecting ISAKMP to advertise proxy_ids, *and*
to use those proxy_ids as selectors, as you describe.
2) I'm not sure how to 'advertise' my policy with ISAKMP exchanges.
If I attempt to negotiate an ISAKMP Phase 2 exchange *without* proxy_ids, or
with a different ID than the remote was expecting, then the SA is denied by
the remote, since it doesn't match their policy.
So in order to fully interoperate, I *must* negotiate a proxy_id with an SA,
and then only use that SA for traffic related to the proxy_id. Since the
most common ID used is ID_IPV4_ADDR, this leads to an SA per host-pair.
Even ID_IPV4_ADDR_SUBNET is only a slight improvement for sites with large
numbers of networks behind their security gateways.
I like Dan's 0/0 proxy_id; I don't know how many other's would accept it,
though (How many of you would?). Here's another question: how many of you
link ID_IPV4_ADDR, ID_IPV4_ADDR_SUBNET, and ID_IPV4_ADDR_RANGE in your
policy engines? e.g. if you're expecting a subnet, and I send you a host
within that subnet, will you accept the SA and use it?
--
Harald <chk@utcc.utoronto.ca>
Follow-Ups:
References: