[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: proposed changes to ISAKMP/Oakley
--- On Wed, 22 Oct 1997 00:32:45 -0700 Daniel Harkins <dharkins@cisco.com> wrote:
> I don't particularly like "proxy identities". If you have a different term
> I'd be happy to entertain a change. But I think whether it's called blah or
> foo or proxy id, the information passed in those payloads is the identities
> for whom this negotiation is performed and not the identity of the ISAKMP
> peer. The peer's identity is determined by the cookies in the ISAKMP header.
> This doesn't mean that a compliant implementation can't take this blob-- of
> foo or blah or "proxy identity"-- and map it into the PF_KEY proxy sockaddr
> field (although since PF_KEY only allows a single sockaddr for this purpose
> I wonder how that mapping is done).
>
> This seems to be a semantic issue which can be solved by changing terminology
> somewhere. If anybody has any ideas-- either for PF_KEY or ISAKMP/Oakley--
> now's the time....
After reading Dan H's draft in closer detail again, I concur that
the capabilities there are fine. Not clear to me whether its better
or not, but its clearly sufficient.
The model is different, but that is mostly irrelevant because the
two models can be mapped 1:1 trivially.
What I'd suggest is that we wordsmith here a bit to try to minimise
terminology-induced confusion.
Perhaps the term Proxy-ID in ISAKMP/Oakley could be changed to
something like "Client Identity" since in the ISAKMP/Oakley model,
the entity whose identity is in the "Source Identity" field is
_always_ the IPsec/ISAKMP entity. The other field in ISAKMP/Oakley
is blank when the IPsec/ISAKMP entity is acting on its own behalf,
but non-blank when the IPsec/ISAKMP entity is proxying on behalf
of some other client node. :-)
> > 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.
>
> Fine. I know a certain router vendor which can satisfy this capability
> (hint: it's the one that's not selling to that copying company). A user has
> the ability to specify which traffic requires which policy.
Cool.
> But is the semantics of what a "proxy" is a determining factor of what
> you'll buy or is the functionality the determining factor?
Technical capabilities are the determining factor, so long as the
vendor has clearly documented their semantics and knobs so that
the administrator can find/configure the knobs correctly. I suspect
that this won't be a problem for some router vendors by release time. :-)
Ran
rja@home.net
Follow-Ups:
References: