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

Re: proposed changes to ISAKMP/Oakley

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

I haven't negotiated any policy here; I've advertised a proposal, and had it
refused because the proxy_id was unacceptable (but of course, I don't
necessarily *know* that, depending on whether or not the remote sends a
meaningful NOTIFY message.)

My problem is that I can't *negotiate* policy here. I have to *advertise* a
proxy_id that matches the other guys policy in order to have the SA accepted.
Granted, if he denies the SA, then he should attempt a negotiation and
advertise an acceptable proxy_id, but then he has to advertise one that *I*
will accept. This quickly leads to non-interoperability between different
vendors, or a proliferation of too-specific SAs. 

[ I could go so far as to assert that ISAKMP is an advertisment protocol, not
  a negotiation protocol; there's no defined semantics for what to do when
  two sides disagree on various parameters. ]

What I'm trying to understand, right now, is what I have to advertise in
order for my SAs to be accepted by other implementors' policy engines.


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

That means you'll only accept packets with a source address of "0.0.0.0",
which is (mostly) and invalid address:

RFC 1122, section 3.2.1.3:

            (a)  { 0, 0 }
 
                 This host on this network.  MUST NOT be sent, except as
                 a source address as part of an initialization procedure
                 by which the host learns its own IP address.
 

I believe you mean prefix 0.0.0.0 netmask 0.0.0.0, often written in CIDR
speak as 0.0.0.0/0, or simply 0/0.


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

Yes they are. CIDR is a response to routing scalability for the global
Internet (and the RFCs say it is supposed to be a temporary measure). Since
renumbering IPv4 hosts is *hard*, many people are dealing with CIDR (and
provider based addressing) by using NAT technology. These people want to run
IP Security gateways on their NATs, to connect the interior networks to each
other. And, IME, Those interior network addresses are not CIDR compatible.

-- 
Harald <chk@utcc.utoronto.ca>
References: