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

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



Still long, but only on the protection suite issue.

---
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 1, 1999 8:08 PM
> To: Tim Jenkins
> Cc: ipsec@lists.tislabs.com
> Subject: Re: Comments on draft-ietf-ipsec-ike-01.txt (long) 
> 
> 
> On Tue, 01 Jun 1999 09:42:47 EDT you wrote
> > 
> > 1) Use of the term "protection suite"
> > 
> > I am both concerned and confused by the use of the term 
> "protection suite"
> > in this document. As it turns out, this term has been 
> re-defined from that
> > in ISAKMP (RFC2408) to refer to only the services provided 
> by a phase 1 SA.
> > (See section 3.1 of draft-ietf-ipsec-ike-01.txt.)
> 
> The abstract of this draft explicitly says that where there 
> are conflicts
> it will be supreme. 

Even over RFFC2408? We really need that document to be updated
then.

That's not my point anyway. My point was that it appears that
"protection suite" is being re-defined in a completely different
way than RFC2408, and I don't see why.

> 
> > On this issue, what is the purpose of adding any new 
> definition of these
> > services? If that is necessary, why change the existing 
> definition of
> > protection suite? Why not find a term that won't result in 
> ambiguity and
> > confusion.
> >

(Above are my original questions; I didn't see a response to them.)

I think my understanding of your position would be clearer if
the above questions were answered. I'll expand them:

1) What is the purposes of defining any new term for the set of
proposals and attributes offered for phase 1?

2) If question 1's answer is valid, why would the term "protection
suite" be chosen when it quite clearly (IMHO) already has a very
different and clear definition?

(I realize that it's not clear to others.)

> > To clarify the existing definition of "protection suite", 
> see section 2.1 of
> > RFC2408:
> > 
> >    Protection Suite: A protection suite is a list of the security
> >    services that must be applied by various security protocols.  For
> >    example, a protection suite may consist of DES 
> encryption in IP ESP,
> >    and keyed MD5 in IP AH. All of the protections in a suite must be
> >    treated as a single unit.  This is necessary because security
> >    services in different security protocols can have subtle
> >    interactions, and the effects of a suite must be analyzed and
> >    verified as a whole.
> 
> I was under the impression that this was confusing people and 
> hence decided
> to spell out what the term means to IKE. If DES in ESP is a protection
> suite what about the lifetime of the ESP offer? Is that part 
> of the protection
> suite as defined by RFC2408? That's not explicitly spelled 
> out and people
> asked me about it. I happen to agree with them. That text 
> doesn't really
> capture the meaning of the term and is open to interpretation.

If clarity of the existing definition is the problem, then that
is what should be done. The existing changes will create more
problems by re-defining it completely differently.

Here's my definition of a protection suite:

"A protection suite is an SA bundle in which the SAs in the bundle
are negotiated using the same SA payload in the same quick mode."

That definition is entirely consistent with RFC2408. RFC2408 also says
that the individual SAs in a suite must be treated as a unit. This
means that when one SA in a suite expires, all SAs must be expired.
It also should mean, and this was demonstrated at interoperability
workshops, that the encapsulation applies to the SAs as a group, or
stated alternatively, to the suite as a whole. (In other words, there
are no extra IP headers added between the headers added by the
individual SAs in the protection suite.)

> 
> > Also see the discussion in section 4.2 of RFC2408 and the 
> example in section
> > 4.2.1 of RFC2408. All of these quite clearly indicate that the term
> > "protection suite" applies to phase 2 SA establishment.
> >
> > While I agree that it does not necessarily preclude phase 1 SA
> > establishment, I do not see the need to apply it to that 
> case only, as
> > draft-ietf-ipsec-ike-01.txt appears to do.
> 
> The DOI defines what IKE negotiates in phase 2. Would it be 
> better if I
> called a protection suite "an collection of attributes that 
> are negotiated 
> as a single unit"? And then said that during phase one the 
> components of 
> such a suite is <blahblahblah> and leave it up to a DOI to 
> define the term 
> if it so chooses?

That might be preferable. But to me (phase 1 aside), that's what
RFC2408 has already done.

And I still don't know why you want to apply the term to
phase 1 anyway.

>  
> > Also, the use of the term "protection suite" is a very good 
> way to refer to
> > a subset of SA bundles where the SAs in the bundle are 
> negotiated using a
> > single SA payload. This allows them to be differentiated 
> from SA bundles
> > that are negotiated by the effective recursion of policy to 
> packets that are
> > IPSec processed.
> 
> This is a slippery slope. If I now state that a protection suite is a
> subset of a bundle of SAs then what sort of subset? 3 offers 
> out of the
> 5 in the bundle? Is that a protection suite? And I don't 
> think that's the
> correct meaning. Even if all 3 of the five were ANDed 
> together, it's still
> 3 protection suites. Perhaps you can come up with another 
> term to describe
> a subset of a bundle.

The protection suite is a result of the negotiation. If I propose

(IPCOMP and ESP and AH) or (ESP or AH)

to you, I'm offering you a choice of two protection suites. Hopefully,
you'll respond with 1 of those, and the result will be that we create
between us a single protection suite. That protection suite will contain
either one or two SAs.

What's slippery about this?

> 
> > As such, I think the use of "protection suite" in this 
> document is confusing
> > and should be changed to align with RFC2408, or it should be removed
> > altogether.
> 
> RFC2408 is confusing and I was asked about it many times. I'm 
> addressing
> that issue. 

I've no problems with that: only that I don't think you're clarifying,
but changing.

> 
> At the last bakeoff someone was passing a message ID in the 
> SPI field of
> an notify message. This was justified by noting that nothing 
> expressly 
> prohibits such behavior. When things reach this state I think 
> we've gotta 
> spell everything out in gory detail and RFC2408 doesn't to the job.

I agree. Is there someone working on a next generation ISAKMP document?

> 
> Does my suggested modification come closer to what you think 
> it should say?
> 

I don't know. I don't think we're really that close in what we think
a protection suite is. I think it's an SA bundle where the SAs in 
the bundle were negotiated using the same SA payload. I think that
you think it's a collection of proposals (including transforms and
attributes). To me, that's still just a proposal.

To try and further clarify why I think this is important, I'll elaborate
more on the differences between what I call a protection suite and
SA bundles in general.

To say that you support SA bundles (in general) means that you support:

1) Iterative SA negotiation with both a single peer and multiple peers,
and
2) Protection suite negotiation.

To do 1 above is a significantly different implementation issue than
to do number 2 above, and a significantly different negotiation method.

For example, a generic SA bundle that results in ESP and AH applied to
the same packet could result from a policy like the following:

  H1 --- SG1 ----- SG2 --- H2

 H1 <-> H2,  all protocols  : (ESP) tunnel
SG1 <-> SG2, ESP protocol   : (AH) transport

For number two, a similar (but different result) comes from a policy of

 H1 <-> H2,  all protocols  : (ESP and AH) tunnel

Both are SA bundles. The second is also a protection suite since it was
negotiated in a single SA payload, and both SAs live and die at the same
time. In the first case, the two SAs are independently negotiated and
live and die completely independently. The AH SA might also carry traffic
from other packets that ended up with ESP protection from hosts I didn't
illustrate above.

Those rules of negotiation and treatment of the SAs is important, and
needs to be clearly spelled out, since it is different. This is why
there were so many issues at the interoperability workshop with respect
to IPCOMP: Does the IPCOMP SA proposal in the offered protection suite
have to have the attributes of the protection suite? (I'm offering this
question to illustrate the protection suite issue, not to start a
discussion on this issue in this thread...)

Has this clarified the issue for anyone???

Tim

Unrecognized Data: application/ms-tnef


Follow-Ups: