[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: inconsistencies in IKE specs
On Tue, 24 Aug 1999 17:54:10 EDT John Shriver wrote
> From: Dan Harkins <dharkins@network-alchemy.com>
> On Tue, 24 Aug 1999 14:17:13 EDT you wrote
>
> > Personally, I think it would make a great deal of sense to say that
> > Phase 2 ID's may only be ID_IPV4_ADDR or ID_IPV6_ADDR. I'd really
> > love to see more MUST NOT's in these specs.
>
> Limiting these to only a single IP addr would mean that IKE would be
> unable to express selectors with wildcarded addresses. Since those
> are required for all implementation (i.e. you MUST support them per
> RFC2401) I don't think it would make too much sense to remove support
> for them from RFC2409 (or the draft that will hopefully depricate
RFC2409)
>.
>
> Of course, allowing these to address a range or subnet means that you
> have just defined "incoming" SA's with the same SPI and key for a
> large group of hosts. That's a very strange thing to do. Broad key
> sharing is not considered good for you.
This really applies to IPSEC gateways, and the keys aren't being shared
beyond the two gateways involved in the IKE exchange. Sure all the traffic
is being protected by a common key, but I don't see this as being a great
weakness.
Consider the alternative for a VPN where the IPSEC gateways are each
protecting a private subnet. Each gateway may be protecting, say, 10-100 IP
addresses. If there are 10 such gateways the using ranges results in each
gateway needing 9 SAs to be fully interconnected. If you only allow one
address per SA then you potentially need thousands...
Chris