Subject: The two problems we're trying to solve

From: Bob Monsour <[email-masked]>
Date: Fri, 25 Jul 1997 10:16:34 -0700

Unfortunately, yesterday I read my mail from another system (in another
city) and failed to leave it on the server for later home retrieval. This
is a response to the replies from Naganand and Roy regarding my most recent
post about how we specifically negotiate the use of compression using ISAKMP.

The way I see the efforts of the WG, we're chartered to develop a protocol
that provides compression services for IP. I see two problems that have to
be solved to do that. (Note that this post excludes the problem of defining
specific compression algorithms/formats to use.)

1. Definition of the protocol to support compressed IP payloads. Avram's
and Matt's drafts are the first attempts to solve this.

2. Definition of a negotiation mechanism to allow two parties to
agree/disagree on what kind of compression, if any, to perform.

Since we're trying to support the use of compression in the absence of
IPSec/ISAKMP, I think that the drafts that solve (1) above should be
independent of the negotiation mechanism definition. This is consistent
with the wg charter milestones, which have us producing a base architecture
of the IP compression protocol, specific compression transofrm specs, and a
spec that defines the use of ISAKMP as the negotiation mechanism.

Am I alone in assuming that the use of ISAKMP as the negotiation mechanism
is intended _only_ to cover the use of compression in the IPSec context? If
so, then we'll need to develop a separate (or extend some other mechanism -
I don't know of one - to support negotiation in absence of IPSec).

Again, as I look at the charter, I think that the architecture doc that is
an intended output of the group is represented by Matt's and Avram's
drafts. However, I think we need to extract the negotiation elements as
those should be documented in a separate draft. This is one of the reasons
I raised the issue of whether compression should be a "protocol" vs. a
transform "attribute" during ISAKMP phase 2 negotiation.

With all that said, my plan is to make a run at an architecture/protocol
spec which combines what I (personally) belive are the best of the two
drafts and include what is intended by the charter.

Comments?

-Bob

---

From: Roy Pereira <[email-masked]>
Date: Fri, 25 Jul 1997 13:57:56 -0400

>From: 	Bob Monsour[SMTP:[email-masked]]
>

I won't rule out using ISAKMP for IPComp without using IPSec.  ISAKMP
was designed to be used for any other protocol, not just ESP and AH, and
thus isn't solely linked to IPSec.

As for defining other negotiation protocols;  I don't like that idea.
It complicates things greatly.  Can we not have static
CryptoAssociations between two hosts just like we can have static SAs
between two IPSec hosts?
What about having the first 256 CPI values represent specific Static
CryptoAssociations? (example,CPI=1 could be do LSZ, CPI=2 is do
ZLIB-deflate)
>drafts. 

I dont agree.  I see Matt's and Avram's documents as compression
protocol documents and not an overview (architecture) of IP compression.
 Avram's draft did have some good architecture sections, but it was
mostly a protocol document.  Matt's was all protocol.

>However, I think we need to extract the negotiation elements as

We should write down the pros and cons of both of these methods and then
present them at Munich.

>drafts and include what is intended by the charter.

This is what Avram, Bob and I are suppose to be writing .  The outline
that was presented was a combination of all of the ip compression drafts
up to date and with an emphasis on architecture.

---

From: Naganand Doraswamy <[email-masked]>
Date: Fri, 25 Jul 1997 15:35:57 -0400

I agree with Roy. Avram's and Matt's documents describe the protocol.
Avram's draft also talks about some architecture issues. There are two
things we need- A base architecture document and a protocol document.

The base architecture document should discuss issues such as integration of
ippcp with ipsec, how one could negotiate the compression paramters (static
versus key mgmt), implication on other protocols etc. 

The protocol draft will discuss in detail the various fields in the header,
how they are built and any implementation guidelines. 

We need to produce the first document now and should do it before 30th (if
possible). We also need to discuss the advantages/disadvantages of the two
approaches. It will go good if this is also put in the first revision of
the architecture document so that it will give us a starting point.

We should define something that can also be used in the absence of IPsec
although one might question the utility of ippcp then. My approach is if we
can define something that will work in the absence of ipsec but that is not
too complicated, then let us do it. Comments?

Bob and Roy, I am hoping that you are working on the architecture document
and will have it done by the 30th!

Thanks,
--Naganand

-----------------------------------------------------------------
Naganand Doraswamy				(508)916-1323 (O)
Bay Architecture Lab				(508)670-8153 (Fax)
3 Federal St, Mail Stop BL3-04
Billerica, MA 01821

---

From: Bob Monsour <[email-masked]>
Date: Fri, 25 Jul 1997 16:16:10 -0700

Ok. I have started work on the document and that is what drove my
questions. In refering back to the other drafts and ultimately back to the
charter, I was driven by what the charter was calling for (which seemed to
be _a_ combined architecture/protocol spec. I agree that the issue I raised
do have a home in an overall architecture document. And now, after hearing
from you and Roy, I have a clearer picture of what is expected. I don't
expect the architecture doc to provide answers to everything, but it
will/should raise all the issues, and available options for resolving them,
related to the use of compression in IP (with or without IPSec).

Roy, below is a revised outline, based on the one you provided. I hope to
be able to email a rough draft to you and Avram by the end of the weekend.
I could definitely use some help on the "implications with ipv4 and ipv6
sections" and also on sections 2.1 and 2.2. Let me know what you can do on
these. I feel comfortable addressing the rest of them.

1.  Introduction
    1.1  Background
    1.2  Specification of Requirements
    1.3  IP Payload Compression Overview
2.  Use of IP Compression with IPSec
    2.1  Interaction of IP Payload Compression with AH & ESP
    2.2  Position of IP Compression Protocol within IPSec
3.  IP payload Compression without IPSec
4.  Anti-expansion of Payload Data
5.  Optional use of Compression
6.  Negotiation Mechanisms for IP Compression
    6.1  Use of ISAKMP in IPSec Contexts
    6.2  Other Mechanisms for Non-IPSec Contexts
7.  Implications with Ipv4
8.  Implications with Ipv6
9.  Compression Algorithm/Format Registration Mechanism
10. Document Roadmap
11. Security Considerations
12. References

I see no reason why we can't have something prepared by the 30th. I know
it's soon, but I'm confident we can get there.

-Bob