Subject: Re: ippcp documents

From: Naganand Doraswamy <[email-masked]>
Date: Thu, 24 Jul 1997 11:08:25 -0400

Bob,

There are two approaches as we have been discussing- one is negotiate
compression as part of the IPsec SA and the other is to negotiate
compression separately. There are some advantages and disadvatages to both
approaches. I agree that our first goal is to make this work with IPsec as
soon as possible. However, we should also consider making it work in the
absence of IPsec provided the overhead is not very high.

In Avram's proposal there is no compression header. The compression is host
based and not session based. However, as Avram has suggested, this is
simple to implement.

By adding the Compression Header, we get the capability to perform
compression on a per session basis. We will still use ISAKMP to negotiate
the compression parameters however in this case, it may not be negoitated
as part of ESP. You will negotiate the parameters in a different SA Payload
(ISAKMP gives you the capability to negotiate SA for multiple protcols in
the same negotiation). I for one feel that this is a better architecture.

We need to hash this out a little bit more. Probably, we can discuss this
at the Munich meeting. I will be sending out the agenda soon and will add
this.

--Naganand

---

From: Roy Pereira <[email-masked]>
Date: Thu, 24 Jul 1997 11:32:15 -0400

One of the problems with this approach is that if we ever want to use IP
Compression without ESP then it would not work.  

Now we have to ask ourselfs if we do want to support IP Compression
without ESP.

A separete protocol is more flexible, but isn't as simple as your
suggestion.

>----------
>From: 	Bob Monsour[SMTP:[email-masked]]
>Sent: 	Wednesday, July 23, 1997 7:34 PM
>To: 	Matt Thomas
>Cc: 	Derrell Piper; [email-masked]
>Subject: 	Re: ippcp documents 
>
>At 03:57 PM 6/25/97 -0400, Matt Thomas wrote:
>>>[some time earlier, Derrell Piper wrote:]
>>>I'll be happy to add a DOI attribute (or two) for IP Compression
>>>negotitiation.  I agree with Matt that it's severe overkill to create a new
>>>DOI just for one attribute.
>>
>>Actually, all I want is another protocol-id added for IPCOMP,
>>not an attribute.  There will then be IPCOMP specific transform-ids
>>(one for deflate, etc.) (e.g. a compress algorithm corresponds to
>>a transform in my view of this).
>
>Matt,
>
>Not being an implementor of ISAKMP, I took some time (not a small amount)
>to read the spec and the DOI to try to determine the simplest, cleanest and
>most straightforward way to handle the compression negotiation. While your
>suggestion of a protocol-id for compression would work, it would put the
>compression protocol at the level of ESP and AH, which I don't think is
>necessary. I view compression as an attribute of one of the transforms that
>gets negotiated using the ISAKMP Transform Payload. If you look at the
>existing attributes that can be associated with a Transform, they include
>the following (section 4.5 of ...DOI-2.txt):
>
> Attribute Classes
>
>             class               value           type
>       -------------------------------------------------
>       Auth Key Life Type          1               B
>       Auth Key Life Duration      2               B/V
>       Enc Key Life Type           3               B
>       Enc Key Life Duration       4               B/V
>       SA Life Type                5               B
>       SA Life Duration            6               B/V
>       Replay Protection           7               B
>       Group Description           8               B
>       CA Distinguished Name       9               B
>       Encapsulation Mode          10              B
>       HMAC Algorithm              11              B
>
>I see compression as something akin to a "feature" of the SA Transform (not
>unlike Encapsulation Mode or Replay Prevention). Making compression an
>attribute rather than a protocol still provides the mechanism to specify
>which algorithm. In Avram's draft, he specified "12" as the compression
>attribute. The SA attribute field provides the attribute type/class and
>also has a value field for specifying the compression algorithm/format.
>
>The only question this raises in my mind is how the compression option &
>algorithm negotiation plays out. Let's take an example where an initiator,
>during an ISAKMP phase II negotiation, sends a Transform Payload that
>proposes ESP using DES-CBC and has the replay prevention attribute turned
>on and also has the proposed compression attribute/algorithm specified.
>What I'm not sure of is the answer to the following question: If the
>responder does not support compression, does he reject the entire ESP
>Transform Payload proposal? If so, doe he just send an
>ATTRIBUTES-NOT-SUPPORTED message? If this is what happens, how does the
>responder know which of the attributes is not supported? Wild guessing
>doesn't seem appropriate. Perhaps the initiator starts stripping off
>attributes to find out which one is the culprit.
>
>If I'm just not understanding how to get over this, I trust someone will
>let me know. If this is surmountable, then I am strongly in favor of the
>transform attribute approach. I believe that defining CPH (compressed
>payload header) as a protocol at the ESP/AH level is excessive. Recall that
>our intitial goal is to solve the problem of supporting the use of
>compression in IPSec. To me this says that we should leverage/augment the
>IPSec DOI in the simplest possible way. Also keep in mind that with a
>compression header (similar to what you've proposed), we can have
>additional algorithm-specific info transmitted with each packet. 
>
>I see the harder part of our problem as coming up with the more general
>negotiation mechanism to support non-IPSec/ISAKMP environments. I don't yet
>know enough to know if we can "easily" extend TCP negotiation to
>support/turn-on compression at the IP layer.
>
>Comments?
>
>-Bob
>
>

---

From: Roy Pereira <[email-masked]>
Date: Thu, 24 Jul 1997 11:56:04 -0400

Would presenting the various approaches (both for the protocol and the
negotiation) at the ipcomp meeting in Munich be a good idea.  Everyone
would then understand and we could perhaps pick a direction?

>----------
>From: 	Roy Pereira
>Sent: 	Thursday, July 24, 1997 11:32 AM
>To: 	'Matt Thomas'; 'Bob Monsour'
>Cc: 	'Derrell Piper'; [email-masked]'
>Subject: 	RE: ippcp documents 
>

---

From: Naganand Doraswamy <[email-masked]>
Date: Thu, 24 Jul 1997 12:10:26 -0400

I guess that was the issue I thought we would discuss under "architecture".
We definitely need to discuss this at the meeting. At this point, this is
one of the unresolved issues.

--Naganand