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

Re: Comments on draft-ietf-ipsec-ike-01.txt

  As I said in a previous post (which you must've ignored) I said the
text is changing. Please go back and read it, and the other post it
mentions. Since seeing the words "policy" and "mandate" in the same
sentence is causing you fits I suggest you stop reading that text
and wait for the next rev.

  This text is necessary because there are enough people running around
who say, "if that behavior isn't in the RFC then you can't do it" and
enough people who, for whatever reason, want things spelled out in
great detail (e.g. what to do with a vendor ID payload that isn't
recognized? Drop the connection? Reboot? Panic?). This behavior is
the common sense thing to do and that point is underlined by your
inability to mention a case why one would not want to do that (when
would you want to refuse an offer of a cipher with a key length greater
than what you would've offered had you initiated?).

  There are also some people who think that all things must be symmetric 
and if Alice can initiate to Bob that Bob must therefore be able to initiate 
to Alice. Unfortunatly some of these people are the "certifiers" of what is 
and what is not a compliant IPSec product. I want to expressly point out
that that belief is false and there are very good reasons-- in fact,
recommended reasons-- why that situation can arise.

  Dan.

On Fri, 04 Jun 1999 17:39:32 PDT you wrote
> Hi Dan,
> 
> Dan Harkins wrote:
> > 
> > Your religious approach to policy is clouding your vision. The policies do
> > indeed intersect. Alice's says "blowfish of at least 256 bits", Bob says
> > "blowfish of at least 128". The union of the two ends up being Alice's
> > policy.
> 
> You've substantially changed the discussion basis here. If the policies
> intersect, then there is no need for the text to begin with, and you can
> delete it entirely. We're arguing about the case where they do not. You
> said in the document
> 
>    Certain negotiable attributes have ranges or multiple acceptable
>    values.  For instance, if the policy specification on a peer mandates
>    group 2 but is offered group 5, as part of an otherwise acceptable
>    protection suite, the peer SHOULD accept that value as it provides
>    more security than demanded.
> 
> That's a far cry from what you're saying above, i.e. "blowfish of at
> least 256 bits". In fact, that is entirely my point. If this is truly
> the policy, then there is no need for the language in the document, and
> it should be deleted, as I said. But if, on the other hand, the policy
> MANDATES something, you are saying it SHOULD be circumvented - and this
> is a slippery slope.
Follow-Ups: References: