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

Re: proposed changes to ISAKMP/Oakley


--- On Tue, 21 Oct 1997 13:57:51 -0400  "C. Harald Koch" <chk@utcc.utoronto.ca> wrote:

> 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.

Source-ID with IP_SUBNET style identity with prefix 0.0.0.0 and netmask 
of 255.255.255.255.  

Request for Dan H. &/or Steve Kent:
	Please document this in the ISAKMP/Oakley spec or the IPsec
	Architecture Spec.  The latter is IMHO really the right place
	since deployed manual keying supports Proxy-IDs and non-ISAKMP
	KM protocols might well support ISAKMP/Oakley.  Obviously
	support for Proxy-IDs would be optional-to-implement for nodes
	not implementing a KM protocol that required them.

The Proxy-ID is the identity of the entity that is performing outbound
IPsec on behalf of the originator of the IP packet.  The Proxy-ID is
*NOT* the identity of the original cleartext IP packets.  If Dan's
document defines Proxy-ID differently, then it has changed the years-old 
definition of the term Proxy-ID and we should correct this before RFC. 

Please lets not change the standard terminology in the middle of things. :-)

> 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.

Moreover, it doesn't match the policy that you negotiated with them.

> 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. 

Almost.  Change it to "...only use that SA for traffic related to the Source-ID."

> Since the
> most common ID used is ID_IPV4_ADDR, this leads to an SA per host-pair.

Nothing says you cannot use an ID of ID_IPv4_ADDR however, 
so that isn't a real issue.

> Even ID_IPV4_ADDR_SUBNET is only a slight improvement for sites with large
> numbers of networks behind their security gateways.

Thanks to the wonders of CIDR, things generally aren't as bad as you imply.
 
> 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?). 

Again, its the (Source-ID == 0.0.0.0/32) that you mean (not Proxy-ID).

> 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?

Please note that I won't buy products that lack an administrative knob
permitting me to cause the implementation to refuse all requests with
a Source-ID of 0.0.0.0/32.  I might or might not be a majority, but
I'm sure I'm not entirely alone.  In general, vendors that want to sell
lots of product will let the box administrators have lots of policy knobs.

Regards,

Ran
rja@inet.org
Follow-Ups: References: