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

RE: Protection Suites in ... (was RE: Comments on draft-ietf-ipsec-ike-01.txt (long) )



---
Tim Jenkins                       TimeStep Corporation
tjenkins@timestep.com          http://www.timestep.com
(613) 599-3610 x4304               Fax: (613) 599-3617



> -----Original Message-----
> From: Dan Harkins [mailto:dharkins@Network-Alchemy.COM]
> Sent: June 2, 1999 1:40 PM
> To: Tim Jenkins
> Cc: ipsec@lists.tislabs.com
> Subject: Re: Protection Suites in ... (was RE: Comments on
> draft-ietf-ipsec-ike-01.txt (long) ) 
> 
> 
>   A protection suite is not a bundle nor is it any subset of a bundle.
> You may wish to refer to it that way but I will, 
> respectfully, say that
> you're wrong. A protection suite is an atomic offer. The whole concept
> of this suite was that very early on (perhaps before you took 
> part in this
> group) people wanted to mix and match offers. One offer was 
> 3DES and MD5 
> and group 2, the other was CAST, SHA, and group 1. So people 
> wanted to 
> accept a mix of 3DES, SHA, group 2. That is not allowed and 
> the concept 
> of the protection suite was defined to limit that.

If you define a protection suite as an atomic offer, and that atomic
offer may contain IPCOMP and ESP and AH (with the assorted transforms and
attributes), then you and I are actually pretty much in agreement. I would
actually call it a protection suite proposal or a protection suite offer.

But in phase 1, why not just call this an SA offer? Could you not just
define what an atomic phase 1 SA offer is without giving it a new name?

> 
>   The protection suite is an atomic offer which must be negotiated in
> its entirety. RFC2408 is somewhat confusing. Maybe not to 
> you, fine, but
> to plenty of other people. I'm attempting to rectify that situation.

I've already said I agree with this attempt.

But my original points were:

1) RFC2408 quite clearly refers to protection suites as being part of
phase 2, both from the definition and the text and the examples I referred
to earlier.
2) Your IKE draft quite clearly only refers to protections suites as
being part of phase 1, and never mentions them in a phase 2 context.
(More on that below...)

If you're attempting to define what is an atomic SA offer, then call it
that.
Call it a protection suite offer to make it clear that the offer may propose
multiple SAs (in phase 2) if you insist on using in phase 1 as well.

> 
>   I have no idea whether RFC2408 will be revved but I don't 
> want to leave
> the confusion in place.
> 

Re-using a term in what seems to be a completely different way when RFC2408
will also be valid will still leave confusion in place, even if you state
that
the new IKE supercedes anything contradictions.

We have the opportunity to clear up this confusion without contradictions
between
documents. Wouldn't that be a better route?

>   You seem upset that the definition explictly disallows your 
> broad idea
> of what it was. Can you explain how this impacts your 
> implementation? Are
> you somehow constrained because the term "protection suite" 
> does not refer
> to a bundle of offers? 
> 
>   Dan.

I've tried to point out the real differences between SA bundles negotiated
using a single SA payload and SA bundles negotiated (functionally) by
iteration. These differences are significant, and I think they should be
stated explicitly, because this is where there is a lot confusion. Remember
the debate about how to create SA bundles where some people said that
separate
negotiations of SAs with the same selectors and different protocols created
a bundle? Also, while the handling of a single SA is relatively clear, the
handling of SA bundles negotiated with a single SA payload is not.

Based on what you said above, I think you're saying there is a need to
explicitly define an atomic offer that cannot be pulled apart.

I'm saying there is a need to explicitly define an SA bundle where the
bundle
is a result of an offer using a single SA payload.

It seems we both like the term "protection suite" for that.

I'm basing my case on the fact that RFC2408 (which may or may not be
updated)
already defines a protection suite as an SA bundle that was negotiated in a
single SA payload, and even provide examples of exactly that.

And intuitively, the term protection suite makes sense: it's a suite of SAs
providing protection.

In your case, protection suite means a suite of offers? Without the word
"offers" in what I think you're defining a protection suite, it doesn't
work as well. Things like this help add clarity: minimal overloading of
meanings and reduced ambiguity.

Maybe that was not the original intent of the definition of a protection
suite.
But new ipsec implementers should only need the RFCs to implement; the
history behind them should not be a requirement in order to implement them.

In any case, here's a proposed solution:

If the definition of protection suite is expanded to allow it to mean both
an
atomic offer and the result of acceptance of an atomic offer in both phase 1
and phase 2, and I think we'll effectively have agreement. (Although I still
think an offer should be called an offer, not a suite.)

Alternatively, we could call what I want to call a protection suite a "super
SA"
or a "multi-SA" or something like that. No matter what we call it, it's
still a
subset of an SA bundle.

We still need explicit rules about handling a protection suite, to reduce
confusion
about expiration when the protection suite contains multiple phase 2 SAs.

Another thing which may be causing problems here is what seems to be an
attempt to
make IKE completely independent of the things it creates. That would be fine
if
we had a document that described SA management. But the only thing we have
that
attempts to deal with any of that is my re-keying document, which is not
complete
from a total SA management point of view. There are also private
implementations
of keep-alives, which are also part of that issue.

So in the absence of a true SA management document, I tend to want to see
the
missing stuff placed in IKE, because that's who created the SAs.

And to evolve this back to the protection suite issue, the management of SA
bundles
that are created with a single SA payload is different than SA bundles
created by
iterated negotiations. Therefore, I want to see that explicitly written
somewhere.

And I don't want to continually say "SA bundles that are created with a
single SA payload". I want those to have their own name. And since that's
what it looks like
RFC2408 calls them, that's what I want to call them.

Tim