[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Q about SA bundles
On Fri, 22 Jan 1999 11:32:23 +0200 Markku Savela wrote
>
> *IF* there is a need of negotiating policy issues, let that be a
> different and independent standard (it could be even an extension to
> ISAKMP). This negotiation could transform the "meta policy"
> selector -> apply bundle1 or bundle2
> into either
> selector -> apply bundle1
> or
> selector -> apply bundle2
> to be used in the SPD as specified in RFC-2401.
So write a draft then! What we already have as draft standard is _not_
what you're proposing. Neither is it in violation of RFC2401 in any way.
People wanted to make conjunctive offers in KM and so IKE does that. That
doesn't break any concepts in RFC2401.
> > interoperable way that precludes the problems described above but
> > because a PF_KEY ACQUIRE message is unable to express conjunctions
> > you're hoping that the problem can just go away if everyone agrees
> > to constrain their implementations in a similar manner.
>
> In this sense you are right, I'm trying to reach a solution, where the
> "problem" goes away. But, without constraining the
> implementations. I'm just trying get the key and policy management
> separated.
The "problem" goes away if you don't use PF_KEY or if you change your
PF_KEY (so that it's not RFC2367).
If you truely want to get "key and policy management separated" then write
some drafts and try to get everyone to agree to depricate RFC2407-2409.
Don't just ask people to not use a portion of a protocol that exists for
a good reason. That's not gonna happen, especially since there's many
independent, interoperable implementations which do it this way.
> > It seems that PF_KEY has put you in a box that you're
> > (intentionally?) not looking out of. Imagine an ACQUIRE-like
> > message (with the corresponding ADD/UPDATE-like message) that could
> > express compound, conjunctive offers....
>
> Yes, intentionally. I prefer to use simple concepts to build very
> complex systems (hey, I like LISP approach!!).
>
> If the current ISAMKP is to be used, what you suggest (complex ACQUIRE
> with conjuctive offers) does become necessary. The current ISKAMP and
> PFKEY v2 do not work together. And, of course, my point is: ISAMKP
> should adjust, not the PFKEY v2.
You're asking for a standards track RFC to change to accomodate an
informational RFC? An informational RFC that has absolutely no impact
on the bits-on-the-wire (except to constrain the richness of IKE). An
informational RFC which is not even required to implement to have a
fully compliant IPSec system! And the reason for this request is some
heart-felt belief in the separation of KM and policy? Sounds like religious
fundamentalism to me.
I like the idea of PFKEY. I wrote one of the first apps with PFKEYv1. IKE
and ISAKMP are complicated protocols. At times I hate them. But with them
I can express complex statements like: "I must authenticate everything with
either HMAC-SHA or HMAC-MD5, in addition I'm willing to also encrypt with
either CAST-CBC or Blowfish-CBC, and in addition to that I'm willing to
compress using either LZS or DEFLATE". And that's cool. To hamstring it
merely to satisfy another document which is _intentionally_ not compatible
with IKE is ludicrous.
Dan.
Follow-Ups:
References: