[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: inconsistencies in IKE specs
To: John Shriver <jas@shiva.com>
cc: ipsec@lists.tislabs.com
Subject: Re: inconsistencies in IKE specs
Date: Tue, 24 Aug 1999 12:36:00 -0700
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.
Dan.
Perhaps we also should make it clear that ID_i2 and ID_r2 are the
identity of the "outer" (endpoint) IP address when using transforms in
tunnel mode. Someone might mistakenly think that they are used to
negotiate the inner addresses for tunnel mode, and that the outer
remains the ISAKMP peer's address.
John.
Follow-Ups:
References: