Subject: Re: Agenda for Munich -- conflicts
From: [email-masked] (Rodney Thayer)
To: [email-masked]
Date: 22 Jun 97 16:49:37 GMT
Newsgroups: cisco.ippcp

against pkix?  that will conflict for some security folks.

At 11:38 AM 6/20/97 -0400, you wrote:
>The meeting is scheduled on Wednesday, August 13th, 1300 - 15000 against
>find, tip, mboned, manet, and pkix working groups.
>
>On Fri, 20 Jun 1997, Avram Shacham wrote:
>
>> At 09:11 AM 6/20/97 -0400, Naganand Doraswamy wrote:
>> >We have 2 hrs at Munich. 
>> 
>> Could you be more specific, i.e. the date of the IPPCP meeting?
>> 
>> 
>
>
>

Path: cronkite.cisco.com!newsgate.cisco.com
From: [email-masked] (Naganand Doraswamy)
To: Rodney Thayer <[email-masked]>
Cc: [email-masked]
Newsgroups: cisco.ippcp
Subject: Re: Agenda for Munich -- conflicts
Message-ID: <Pine.SUN.3.96.970623082933.631k-100000@span>
Date: 23 Jun 97 12:31:08 GMT
References: <[email-masked]>
Organization: Cisco Systems, San Jose, California, USA
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Lines: 7
Xref: cronkite.cisco.com cisco.ippcp:2

It is pretty difficult to not schedule it against some security area.
Since we are in the Internet area, we cannot schedule it against any
Internet working groups as the area directors need to present.

If there is anybody who feels it is very important not to have it against
pkix, I can request the IETF to see if they can reschedule it.

Path: cronkite.cisco.com!newsgate.cisco.com
From: [email-masked] (Naganand Doraswamy)
To: [email-masked]
Cc: [email-masked]
Newsgroups: cisco.ippcp
Subject: ippcp docuements
Message-ID: <Pine.SUN.3.96.970624114022.1469D-100000@span>
Date: 24 Jun 97 15:48:40 GMT
Organization: Cisco Systems, San Jose, California, USA
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Lines: 19
Xref: cronkite.cisco.com cisco.ippcp:3

In order for us to move quickly, we need to produce the following drafts-

1. A base draft that explains the architecture. This should address issues
such as the header format, process of negotiating which algorithm to use,
dependency on any other protocols such as IPsec if any etc.

2. A draft explaining the use of ISAKMP to negotiate the compression
algorithm.

3. Individual drafts explaining the various compression algorithms and the
Payload formats.

I was thinking we can extend either Matt's or Avram's draft after we
decide whether to tunnel or create a new header to deal with architecture
issues. We need a volunteers for the other two drafts so that we have
something to discuss in Munich.

Does everybody agree with this approach? Comments?

Path: cronkite.cisco.com!newsgate.cisco.com
From: [email-masked] (Roy Pereira)
To: "[email-masked]'" <[email-masked]>,
        "'Naganand Doraswamy'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Newsgroups: cisco.ippcp
Subject: RE: ippcp documents
Message-ID: <c=US%a=_%p=TimeStep_Corpora%l=[email-masked]>
Date: 24 Jun 97 21:07:17 GMT
Organization: Cisco Systems, San Jose, California, USA
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Lines: 22
Xref: cronkite.cisco.com cisco.ippcp:4

>
>2. A draft explaining the use of ISAKMP to negotiate the compression
>algorithm.

Since Derrell Piper's draft is named "The Internet IP Security Domain of
Interpretation for ISAKMP", we cannot simply make an amendment to it.
Thus the easiest way to get ISAKMP to negotiate our compression
protocol, is to define a new Domain on Interpretation (DOI).

I propose that we create a document titled "The Internet IP Compression
Domain of Interpretation for ISAKMP".

This has a side effect, in that if we are negotiating ESP and/or AH as
well, then we need two SA payloads since the SA payload has the DOI.
Some implementations might not support this yet (although they must to
be ISAKMP compliant).  

The other alternative is to use the same DOI and make a compression
protocol amendment section to Derrell's DOI document.  I don't suggest
doing so.

Path: cronkite.cisco.com!newsgate.cisco.com
From: [email-masked] (Naganand Doraswamy)
To: [email-masked]
Newsgroups: cisco.ippcp
Subject: cc in mail messages
Message-ID: <Pine.SUN.3.96.970624171525.1574B-100000@span>
Date: 24 Jun 97 21:19:43 GMT
Organization: Cisco Systems, San Jose, California, USA
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Lines: 6
Xref: cronkite.cisco.com cisco.ippcp:5

I probably set a wrong precedence by cc'ing Thomas in my mail! Please cc
the messages to me iff it needs my immediate attention. Kindly dont
cc to Thomas. 

Thanks,

Path: cronkite.cisco.com!newsgate.cisco.com
From: [email-masked] (Rodney Thayer)
To: [email-masked]
Newsgroups: cisco.ippcp
Subject: RE: ippcp documents
Message-ID: <[email-masked]>
Date: 24 Jun 97 21:29:35 GMT
Organization: Cisco Systems, San Jose, California, USA
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Lines: 44
Xref: cronkite.cisco.com cisco.ippcp:6

I think we should go with the separate DOI.   I think someone should say
something on the IPsec list to remind ISAKMP implementors they are someday
going to have to work with multiple DOI's.

And I think I'll make sure the next IPSEC survey asks which DOI's the
ISAKMP supports...

>From: Roy Pereira <[email-masked]>
>To: "[email-masked]'" <[email-masked]>,
>        "'Naganand Doraswamy'" <[email-masked]>
>Cc: "[email-masked]'" <[email-masked]>
>Subject: RE: ippcp documents
>Date: Tue, 24 Jun 1997 17:07:17 -0400
>
>>
>>2. A draft explaining the use of ISAKMP to negotiate the compression
>>algorithm.
>
>Since Derrell Piper's draft is named "The Internet IP Security Domain of
>Interpretation for ISAKMP", we cannot simply make an amendment to it.
>Thus the easiest way to get ISAKMP to negotiate our compression
>protocol, is to define a new Domain on Interpretation (DOI).
>
>I propose that we create a document titled "The Internet IP Compression
>Domain of Interpretation for ISAKMP".
>
>This has a side effect, in that if we are negotiating ESP and/or AH as
>well, then we need two SA payloads since the SA payload has the DOI.
>Some implementations might not support this yet (although they must to
>be ISAKMP compliant).  
>
>The other alternative is to use the same DOI and make a compression
>protocol amendment section to Derrell's DOI document.  I don't suggest
>doing so.
>
>
>
>

-- Rodney Thayer <mailto:[email-masked]> Sable Technology Corporation
   246 Walnut Street Newton MA 02160 U.S.A.  +1 617 332 7292 +1 617 332
7970(Fax)

Path: cronkite.cisco.com!newsgate.cisco.com
From: [email-masked] (Roy Pereira)
To: "[email-masked]'" <[email-masked]>,
        "'Rodney Thayer'"
	 <[email-masked]>
Newsgroups: cisco.ippcp
Subject: RE: ippcp documents
Message-ID: <c=US%a=_%p=TimeStep_Corpora%l=[email-masked]>
Date: 24 Jun 97 22:15:31 GMT
Organization: Cisco Systems, San Jose, California, USA
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Lines: 58
Xref: cronkite.cisco.com cisco.ippcp:7

We also can define more than one compression protocol to negotiate with
our IPPCP DOI.  

ie. Avram's and Matt's.

Although, for a start we should choose one to work with.

>----------
>From: 	Rodney Thayer[SMTP:[email-masked]]
>Sent: 	Tuesday, June 24, 1997 5:29 PM
>To: 	[email-masked]
>Subject: 	RE: ippcp documents
>
>I think we should go with the separate DOI.   I think someone should say
>something on the IPsec list to remind ISAKMP implementors they are someday
>going to have to work with multiple DOI's.
>
>And I think I'll make sure the next IPSEC survey asks which DOI's the
>ISAKMP supports...
>
>>From: Roy Pereira <[email-masked]>
>>To: "[email-masked]'" <[email-masked]>,
>>        "'Naganand Doraswamy'" <[email-masked]>
>>Cc: "[email-masked]'" <[email-masked]>
>>Subject: RE: ippcp documents
>>Date: Tue, 24 Jun 1997 17:07:17 -0400
>>
>>>
>>>2. A draft explaining the use of ISAKMP to negotiate the compression
>>>algorithm.
>>
>>Since Derrell Piper's draft is named "The Internet IP Security Domain of
>>Interpretation for ISAKMP", we cannot simply make an amendment to it.
>>Thus the easiest way to get ISAKMP to negotiate our compression
>>protocol, is to define a new Domain on Interpretation (DOI).
>>
>>I propose that we create a document titled "The Internet IP Compression
>>Domain of Interpretation for ISAKMP".
>>
>>This has a side effect, in that if we are negotiating ESP and/or AH as
>>well, then we need two SA payloads since the SA payload has the DOI.
>>Some implementations might not support this yet (although they must to
>>be ISAKMP compliant).  
>>
>>The other alternative is to use the same DOI and make a compression
>>protocol amendment section to Derrell's DOI document.  I don't suggest
>>doing so.
>>
>>
>>
>>
>
>-- Rodney Thayer <mailto:[email-masked]> Sable Technology Corporation
>   246 Walnut Street Newton MA 02160 U.S.A.  +1 617 332 7292 +1 617 332
>7970(Fax)
>
>
>

Path: cronkite.cisco.com!newsgate.cisco.com
From: [email-masked] (Matt Thomas)
To: Roy Pereira <[email-masked]>
Cc: <[email-masked]>
Newsgroups: cisco.ippcp
Subject: RE: ippcp documents
Message-ID: <[email-masked]>
Date: 25 Jun 97 00:01:59 GMT
Organization: Cisco Systems, San Jose, California, USA
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Lines: 43
Xref: cronkite.cisco.com cisco.ippcp:8

At 05:07 PM 6/24/97 -0400, Roy Pereira wrote:
>>
>>2. A draft explaining the use of ISAKMP to negotiate the compression
>>algorithm.
>
>Since Derrell Piper's draft is named "The Internet IP Security Domain of
>Interpretation for ISAKMP", we cannot simply make an amendment to it.

Why not?  In the draft I'm writing, another protocol-id will be assigned
by IANA for CPH (Compressed Payload Header).  This protocol-id will then
have a set of transform-ids defined (one pre compression method).  There
can even be attributes defined to negotiate things on a per-compresion
method.

>Thus the easiest way to get ISAKMP to negotiate our compression
>protocol, is to define a new Domain on Interpretation (DOI).

I disagree.  A DOI should only be defined if it's fundamentally 
different (like TLS would require).

>I propose that we create a document titled "The Internet IP Compression
>Domain of Interpretation for ISAKMP".

Nooo.  That's severe overkill.

>This has a side effect, in that if we are negotiating ESP and/or AH as
>well, then we need two SA payloads since the SA payload has the DOI.
>Some implementations might not support this yet (although they must to
>be ISAKMP compliant).  

I just have them add a second proposal with a separate SPI space (ie.
CPI).

>The other alternative is to use the same DOI and make a compression
>protocol amendment section to Derrell's DOI document.  I don't suggest
>doing so.

I suggest doing so.  It's much cleaner.
-- 
Matt Thomas                    Internet:   [email-masked]
Internet Locksmith             WWW URL:    <coming eventually>
AltaVista Internet Software    Disclaimer: This message reflects my own
Littleton, MA                              warped views, etc.

Path: cronkite.cisco.com!newsgate.cisco.com
From: [email-masked] (Derrell Piper)
To: Matt Thomas <[email-masked]>
Cc: Roy Pereira <[email-masked]>, [email-masked]
Newsgroups: cisco.ippcp
Subject: Re: ippcp documents
Message-ID: <[email-masked]>
Date: 25 Jun 97 01:15:28 GMT
References: <[email-masked]>
Organization: Cisco Systems, San Jose, California, USA
Lines: 7
Xref: cronkite.cisco.com cisco.ippcp:9

FYI,

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.

Derrell

Path: cronkite.cisco.com!newsgate.cisco.com
From: [email-masked] (Bob Monsour)
To: Derrell Piper <[email-masked]>
Cc: Matt Thomas <[email-masked]>,
        Roy Pereira <[email-masked]>, [email-masked]
Newsgroups: cisco.ippcp
Subject: Re: ippcp documents
Message-ID: <[email-masked]>
Date: 25 Jun 97 02:41:05 GMT
Organization: Cisco Systems, San Jose, California, USA
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Lines: 58
Xref: cronkite.cisco.com cisco.ippcp:10

At 06:15 PM 6/24/97 -0700, Derrell Piper wrote:
>FYI,
>
>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.

Am I INcorrect to assume that the DOI is a base set of security parameter
definitions and their values and that any extensions to those in the DOI
spec itself are to be assigned using IANA. For most, but not all, of the
parameters in the DOI, it says that the range "next value through some
later value" is reserved to IANA (and the others are for private use). The
one place I didn't see that is in section 4.5 as shown below.

4.5 IPSEC Security Association Attributes

   The following SA attribute definitions are used in phase II of an
   ISAKMP/Oakley negotiation.  Attribute types can be either Basic (B)
   or Variable-Length (V).  Encoding of these attributes is defined in
   the base ISAKMP specification.

       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

If the DOI is NOT a base spec and subsequent additions made via IANA
assignment, can the DOI ever stabilize as standards track spec? or will it
have to change every time we add a new attribute/parameter-value?

On the specific topic being debated, I'm in favor of extending the existing
DOI and not writing a new one. Recalling from the charter:

	The immediate problem the Working Group will address is the
	development of a payload compression protocol for use in conjunction
	with IPSec. 

and

	The Working Group will
	propose extensions to ISAKMP to support the negotiation of compression
	parameters. 

To me, this says use the IPSec DOI and extend it to support compression.

-Bob

Path: cronkite.cisco.com!newsgate.cisco.com
From: [email-masked] (Derrell Piper)
To: Bob Monsour <[email-masked]>
Cc: Matt Thomas <[email-masked]>,
        Roy Pereira <[email-masked]>, [email-masked]
Newsgroups: cisco.ippcp
Subject: Re: ippcp documents
Message-ID: <[email-masked]>
Date: 25 Jun 97 03:46:00 GMT
References: <[email-masked]>
Organization: Cisco Systems, San Jose, California, USA
Lines: 15
Xref: cronkite.cisco.com cisco.ippcp:11

RE: Of reserved values, IANA, and Last Calls...

Bob,

I've actually got a note in the next draft to reserve a portion of
attribute namespace...

I'm not sure how a document like this stabilizes.  I haven't been involved
with this long enough to know.  I guess the actual tables will get turned
over to IANA at some point and then it becomes an IANA issue.  The DOI RFC
would then probably just list the last known set at the time of its last
revision, with subsequent RFC re-issues updating each list from the current
IANA list.  Or maybe something else magical happens...

Derrell

Path: cronkite.cisco.com!newsgate.cisco.com
From: [email-masked] (Rodney Thayer)
To: [email-masked]
Newsgroups: cisco.ippcp
Subject: is there an archive yet?
Message-ID: <[email-masked]>
Date: 25 Jun 97 09:49:58 GMT
Organization: Cisco Systems, San Jose, California, USA
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Lines: 7
Xref: cronkite.cisco.com cisco.ippcp:12

-- Rodney Thayer <mailto:[email-masked]> Sable Technology Corporation
   246 Walnut Street Newton MA 02160 U.S.A.  +1 617 332 7292 +1 617 332
7970(Fax)

Path: cronkite.cisco.com!newsgate.cisco.com
From: [email-masked] (Naganand Doraswamy)
To: Rodney Thayer <[email-masked]>
Cc: [email-masked]
Newsgroups: cisco.ippcp
Subject: Re: is there an archive yet?
Message-ID: <Pine.SUN.3.96.970625085956.1574D-100000@span>
Date: 25 Jun 97 13:00:43 GMT
References: <[email-masked]>
Organization: Cisco Systems, San Jose, California, USA
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Lines: 13
Xref: cronkite.cisco.com cisco.ippcp:13

Avram and Derrell are working on it. I am waiting to hear from them.

On Wed, 25 Jun 1997, Rodney Thayer wrote:

> 
> 
> -- Rodney Thayer <mailto:[email-masked]> Sable Technology Corporation
>    246 Walnut Street Newton MA 02160 U.S.A.  +1 617 332 7292 +1 617 332
> 7970(Fax)
> 
> 
> 

Path: cronkite.cisco.com!newsgate.cisco.com
From: [email-masked] (Naganand Doraswamy)
To: Derrell Piper <[email-masked]>
Cc: Matt Thomas <[email-masked]>,
        Roy Pereira <[email-masked]>, [email-masked]
Newsgroups: cisco.ippcp
Subject: Re: ippcp documents
Message-ID: <Pine.SUN.3.96.970625090626.1606A-100000@span>
Date: 25 Jun 97 13:09:20 GMT
References: <[email-masked]>
Organization: Cisco Systems, San Jose, California, USA
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Lines: 13
Xref: cronkite.cisco.com cisco.ippcp:14

My only concern on this is procedural. The IPsec chairs are moving very
fast to get a closure on all documents and we are just starting. If we
have to modify the DOI document then there is a probability that we could
hold it back.

I agree that it is simpler to put this in the existing DOI document but we
have to be careful in not holding the document back. If we can assure
ourselves of this, then I am open to extending the DOI spec. 

Comments?

Path: cronkite.cisco.com!newsgate.cisco.com
From: [email-masked] (Roy Pereira)
To: Roy Pereira <[email-masked]>,
        "'Matt Thomas'"
	 <[email-masked]>,
        "'Derrell Piper'"
	 <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Newsgroups: cisco.ippcp
Subject: RE: ippcp documents
Message-ID: <c=US%a=_%p=TimeStep_Corpora%l=[email-masked]>
Date: 25 Jun 97 14:30:18 GMT
Organization: Cisco Systems, San Jose, California, USA
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Lines: 54
Xref: cronkite.cisco.com cisco.ippcp:15

Derrel will have to change the name of his DOI to accomodate the
compression protocol.  Is he willing to do so?

>----------
>From: 	Matt Thomas[SMTP:[email-masked]]
>Sent: 	Tuesday, June 24, 1997 8:01 PM
>To: 	Roy Pereira
>Cc: 	[email-masked]
>Subject: 	RE: ippcp documents
>
>At 05:07 PM 6/24/97 -0400, Roy Pereira wrote:
>>>
>>>2. A draft explaining the use of ISAKMP to negotiate the compression
>>>algorithm.
>>
>>Since Derrell Piper's draft is named "The Internet IP Security Domain of
>>Interpretation for ISAKMP", we cannot simply make an amendment to it.
>
>Why not?  In the draft I'm writing, another protocol-id will be assigned
>by IANA for CPH (Compressed Payload Header).  This protocol-id will then
>have a set of transform-ids defined (one pre compression method).  There
>can even be attributes defined to negotiate things on a per-compresion
>method.
>
>>Thus the easiest way to get ISAKMP to negotiate our compression
>>protocol, is to define a new Domain on Interpretation (DOI).
>
>I disagree.  A DOI should only be defined if it's fundamentally 
>different (like TLS would require).
>
>>I propose that we create a document titled "The Internet IP Compression
>>Domain of Interpretation for ISAKMP".
>
>Nooo.  That's severe overkill.
>
>>This has a side effect, in that if we are negotiating ESP and/or AH as
>>well, then we need two SA payloads since the SA payload has the DOI.
>>Some implementations might not support this yet (although they must to
>>be ISAKMP compliant).  
>
>I just have them add a second proposal with a separate SPI space (ie.
>CPI).
>
>>The other alternative is to use the same DOI and make a compression
>>protocol amendment section to Derrell's DOI document.  I don't suggest
>>doing so.
>
>I suggest doing so.  It's much cleaner.
>-- 
>Matt Thomas                    Internet:   [email-masked]
>Internet Locksmith             WWW URL:    <coming eventually>
>AltaVista Internet Software    Disclaimer: This message reflects my own
>Littleton, MA                              warped views, etc.
>

Path: cronkite.cisco.com!newsgate.cisco.com
From: [email-masked] (Roy Pereira)
To: "'Matt Thomas'" <[email-masked]>,
        "'Derrell Piper'"
	 <[email-masked]>,
        Roy Pereira <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Newsgroups: cisco.ippcp
Subject: RE: ippcp documents
Message-ID: <c=US%a=_%p=TimeStep_Corpora%l=[email-masked]>
Date: 25 Jun 97 14:46:46 GMT
Organization: Cisco Systems, San Jose, California, USA
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Lines: 68
Xref: cronkite.cisco.com cisco.ippcp:16

BTW: I just want to say that I don't care if we create a new DOI or use
the existing one.  I don't want to come across as inflexible.  ;-)

>----------
>From: 	Roy Pereira
>Sent: 	Wednesday, June 25, 1997 10:30 AM
>To: 	Roy Pereira; 'Matt Thomas'; 'Derrell Piper'
>Cc: 	[email-masked]'
>Subject: 	RE: ippcp documents
>
>Derrel will have to change the name of his DOI to accomodate the
>compression protocol.  Is he willing to do so?
>
>>----------
>>From: 	Matt Thomas[SMTP:[email-masked]]
>>Sent: 	Tuesday, June 24, 1997 8:01 PM
>>To: 	Roy Pereira
>>Cc: 	[email-masked]
>>Subject: 	RE: ippcp documents
>>
>>At 05:07 PM 6/24/97 -0400, Roy Pereira wrote:
>>>>
>>>>2. A draft explaining the use of ISAKMP to negotiate the compression
>>>>algorithm.
>>>
>>>Since Derrell Piper's draft is named "The Internet IP Security Domain of
>>>Interpretation for ISAKMP", we cannot simply make an amendment to it.
>>
>>Why not?  In the draft I'm writing, another protocol-id will be assigned
>>by IANA for CPH (Compressed Payload Header).  This protocol-id will then
>>have a set of transform-ids defined (one pre compression method).  There
>>can even be attributes defined to negotiate things on a per-compresion
>>method.
>>
>>>Thus the easiest way to get ISAKMP to negotiate our compression
>>>protocol, is to define a new Domain on Interpretation (DOI).
>>
>>I disagree.  A DOI should only be defined if it's fundamentally 
>>different (like TLS would require).
>>
>>>I propose that we create a document titled "The Internet IP Compression
>>>Domain of Interpretation for ISAKMP".
>>
>>Nooo.  That's severe overkill.
>>
>>>This has a side effect, in that if we are negotiating ESP and/or AH as
>>>well, then we need two SA payloads since the SA payload has the DOI.
>>>Some implementations might not support this yet (although they must to
>>>be ISAKMP compliant).  
>>
>>I just have them add a second proposal with a separate SPI space (ie.
>>CPI).
>>
>>>The other alternative is to use the same DOI and make a compression
>>>protocol amendment section to Derrell's DOI document.  I don't suggest
>>>doing so.
>>
>>I suggest doing so.  It's much cleaner.
>>-- 
>>Matt Thomas                    Internet:
>>[email-masked]
>>Internet Locksmith             WWW URL:    <coming eventually>
>>AltaVista Internet Software    Disclaimer: This message reflects my own
>>Littleton, MA                              warped views, etc.
>>
>

Path: cronkite.cisco.com!newsgate.cisco.com
From: [email-masked] (Avram Shacham)
To: Naganand Doraswamy <[email-masked]>,
        Rodney Thayer <[email-masked]>
Cc: [email-masked]
Newsgroups: cisco.ippcp
Subject: Re: is there an archive yet?
Message-ID: <[email-masked]>
Date: 25 Jun 97 17:39:25 GMT
Organization: Cisco Systems, San Jose, California, USA
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Lines: 19
Xref: cronkite.cisco.com cisco.ippcp:17

The status is still "Work in Progress".

At 09:00 AM 6/25/97 -0400, Naganand Doraswamy wrote:
>Avram and Derrell are working on it. I am waiting to hear from them.
>
>On Wed, 25 Jun 1997, Rodney Thayer wrote:
>
>> 
>> 
>> -- Rodney Thayer <mailto:[email-masked]> Sable Technology Corporation
>>    246 Walnut Street Newton MA 02160 U.S.A.  +1 617 332 7292 +1 617 332
>> 7970(Fax)
>> 
>> 
>> 
>
>
>

Path: cronkite.cisco.com!newsgate.cisco.com
From: [email-masked] (Matt Thomas)
To: Derrell Piper <[email-masked]>
Cc: [email-masked]
Newsgroups: cisco.ippcp
Subject: Re: ippcp documents
Message-ID: <[email-masked]>
Date: 25 Jun 97 19:57:34 GMT
References: <[email-masked]>
Organization: Cisco Systems, San Jose, California, USA
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Lines: 13
Xref: cronkite.cisco.com cisco.ippcp:18

>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 Thomas                    Internet:   [email-masked]
Internet Locksmith             WWW URL:    <coming eventually>
AltaVista Internet Software    Disclaimer: This message reflects my own
Littleton, MA                              warped views, etc.

Path: cronkite.cisco.com!newsgate.cisco.com
From: [email-masked] (Roy Pereira)
To: "'IP Compression Mailing List'" <[email-masked]>
Newsgroups: cisco.ippcp
Subject: FW: Compression WG proposed charter
Message-ID: <c=US%a=_%p=TimeStep_Corpora%l=[email-masked]>
Date: 25 Jun 97 20:21:20 GMT
Organization: Cisco Systems, San Jose, California, USA
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Lines: 36
Xref: cronkite.cisco.com cisco.ippcp:19

>----------
>From: 	Roy Pereira
>Sent: 	Wednesday, June 25, 1997 1:14 PM
>To: 	[email-masked]; 'Derrell Piper'
>Cc: 	[email-masked]; [email-masked]; [email-masked];
>[email-masked]; [email-masked]; [email-masked];
>[email-masked]; [email-masked]; Theodore Y. Ts'o
>Subject: 	RE: Compression WG proposed charter 
>
>If IPPCP is added to the IPSec DOI, then it really should be a separate
>protocol and not another attribute.  Thus the DOI would have ISAKMP, AH, ESP,
>and PCP.  The transform id for the PCP protocol would be one of the
>compression algorithms (LZS, ZLIB,...).  I'm not sure if we need any
>attribute to support compression algorithms.
>
>----------
>From: 	Derrell Piper[SMTP:[email-masked]]
>Sent: 	Wednesday, June 25, 1997 1:04 PM
>To: 	[email-masked]
>Cc: 	Roy Pereira; [email-masked]; [email-masked];
>[email-masked]; [email-masked]; [email-masked];
>[email-masked]; [email-masked]; [email-masked]; Theodore Y.
>Ts'o
>Subject: 	Re: Compression WG proposed charter 
>
>There is not currently an attribute, but if the ippcp folks don't have
>any further objections to using the IPSEC DOI, I will add one before I
>release the next rev of the document.  The last time I read the draft,
>which was before Memphis, it just needed an attribute which was a 
>simple list of compression algorithms that could be negotiated.
>
>Derrell
>
>

Path: cronkite.cisco.com!newsgate.cisco.com
From: [email-masked] (Thomas Narten)
To: Matt Thomas <[email-masked]>
Cc: Roy Pereira <[email-masked]>, [email-masked]
Newsgroups: cisco.ippcp
Subject: Re: IP Payload Compression Protocol (IPComp)
Message-ID: <[email-masked]>
Date: 26 Jun 97 15:13:41 GMT
References: <[email-masked]>
Organization: Cisco Systems, San Jose, California, USA
Lines: 14
Xref: cronkite.cisco.com cisco.ippcp:20

>  0         8         16     32                32+N            EOP
>  +---------+---------+-------+--------------....+-------.....-+
>  | nxt hdr |  rsvrd  |  CPI  | CPI-specific hdr | comp. data  |
>  +---------+---------+-------+--------------....+-------.....-+
>  
> Having nxthdr in the compression is an interesting idea.  However
> the disadvantage is that it makes protocol screening/statistics
> almost impossible.

If one assumes that IPSec is where compression is going to be used,
all of the above will reside within the encrypted portion of an IPSec
header and be unavailable to network sniffers. 

Thomas

Path: cronkite.cisco.com!newsgate.cisco.com
From: [email-masked] (Rodney Thayer)
To: [email-masked]
Newsgroups: cisco.ippcp
Subject: Re: IP Payload Compression Protocol (IPComp)
Message-ID: <[email-masked]>
Date: 26 Jun 97 15:45:14 GMT
Organization: Cisco Systems, San Jose, California, USA
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Lines: 33
Xref: cronkite.cisco.com cisco.ippcp:21

next-header is nice because it allows you to decide what processing
component to hand off the data to after it's decompressed.  this is in the
ipv6 style.  the thing inside the compressed packet (the compression
payload) might be ipv4 or ipv6 or ah or something else.

>To: Matt Thomas <[email-masked]>
>Cc: Roy Pereira <[email-masked]>, [email-masked]
>Subject: Re: IP Payload Compression Protocol (IPComp) 
>Date: Thu, 26 Jun 1997 11:13:41 -0400
>From: Thomas Narten <[email-masked]>
>
>>  0         8         16     32                32+N            EOP
>>  +---------+---------+-------+--------------....+-------.....-+
>>  | nxt hdr |  rsvrd  |  CPI  | CPI-specific hdr | comp. data  |
>>  +---------+---------+-------+--------------....+-------.....-+
>>  
>> Having nxthdr in the compression is an interesting idea.  However
>> the disadvantage is that it makes protocol screening/statistics
>> almost impossible.
>
>If one assumes that IPSec is where compression is going to be used,
>all of the above will reside within the encrypted portion of an IPSec
>header and be unavailable to network sniffers. 
>
>Thomas
>
>

-- Rodney Thayer <mailto:[email-masked]> Sable Technology Corporation
   246 Walnut Street Newton MA 02160 U.S.A.  +1 617 332 7292 +1 617 332
7970(Fax)

Path: cronkite.cisco.com!newsgate.cisco.com
From: [email-masked] (Thomas Narten)
To: Rodney Thayer <[email-masked]>
Cc: [email-masked]
Newsgroups: cisco.ippcp
Subject: Re: IP Payload Compression Protocol (IPComp)
Message-ID: <[email-masked]>
Date: 26 Jun 97 16:21:49 GMT
References: <[email-masked]>
Organization: Cisco Systems, San Jose, California, USA
Lines: 20
Xref: cronkite.cisco.com cisco.ippcp:22

> next-header is nice because it allows you to decide what processing
> component to hand off the data to after it's decompressed.

I agree that the field serves a necessary purpose. But the field
itself could be part of the data that gets compressed. That is,
prepend the next-header field with the data and compress the entire
quantity.  The field would be restored during the decompression on the
other end, where it would subsequently be available for
demultiplexing.  So we wouldn't be doing away with the field.

Is there a need to have the field be available before the packet is
actually decompressed?

My previous comment was in response to Matt's observation that
compressing the next-header field would "hide" its value from packet
sniffers. They would need to be able to decompress packets in order to
determine that field. This would only be an issue for compressed --
but not encrypted -- packets.

Thomas

Path: cronkite.cisco.com!newsgate.cisco.com
From: [email-masked] (Rodney Thayer)
To: [email-masked]
Newsgroups: cisco.ippcp
Subject: Re: IP Payload Compression Protocol (IPComp)
Message-ID: <[email-masked]>
Date: 26 Jun 97 16:34:34 GMT
References: <[email-masked]>
Organization: Cisco Systems, San Jose, California, USA
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Lines: 34
Xref: cronkite.cisco.com cisco.ippcp:23

if you require it to be compressed you make it harder to compress a packet,
in cases where the compressed data has to be contiguous.  other than that,
sure.

At 12:21 PM 6/26/97 -0400, you wrote:
>> next-header is nice because it allows you to decide what processing
>> component to hand off the data to after it's decompressed.
>
>I agree that the field serves a necessary purpose. But the field
>itself could be part of the data that gets compressed. That is,
>prepend the next-header field with the data and compress the entire
>quantity.  The field would be restored during the decompression on the
>other end, where it would subsequently be available for
>demultiplexing.  So we wouldn't be doing away with the field.
>
>Is there a need to have the field be available before the packet is
>actually decompressed?
>
>My previous comment was in response to Matt's observation that
>compressing the next-header field would "hide" its value from packet
>sniffers. They would need to be able to decompress packets in order to
>determine that field. This would only be an issue for compressed --
>but not encrypted -- packets.
>
>Thomas
>
>

-- Rodney Thayer <mailto:[email-masked]> Sable Technology Corporation
   246 Walnut Street Newton MA 02160 U.S.A.  +1 617 332 7292 +1 617 332
7970(Fax)

Path: cronkite.cisco.com!newsgate.cisco.com
From: [email-masked] (Naganand Doraswamy)
To: Thomas Narten <[email-masked]>
Cc: Rodney Thayer <[email-masked]>, [email-masked]
Newsgroups: cisco.ippcp
Subject: Re: IP Payload Compression Protocol (IPComp)
Message-ID: <Pine.SUN.3.96.970626125037.1699D-100000@span>
Date: 26 Jun 97 16:52:46 GMT
References: <[email-masked]>
Organization: Cisco Systems, San Jose, California, USA
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Lines: 11
Xref: cronkite.cisco.com cisco.ippcp:24

I am probably missing something here. The compression header is not
compressed, right? If that is the case, then the next header field will
not hide any protocol information, correct?

If possible, I would like to avoid appending values in front of PDU only
because of implementation issue. I would like to compresses the payload as
I get it from the upper layers. In that case, I dont have to play around
with mbufs.

Path: cronkite.cisco.com!newsgate.cisco.com
From: [email-masked] (Matt Thomas)
To: Naganand Doraswamy <[email-masked]>
Cc: [email-masked]
Newsgroups: cisco.ippcp
Subject: Re: IP Payload Compression Protocol (IPComp)
Message-ID: <[email-masked]>
Date: 26 Jun 97 18:14:33 GMT
References: <Pine.SUN.3.96.970626125037.1699D-100000@span>
Organization: Cisco Systems, San Jose, California, USA
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Lines: 28
Xref: cronkite.cisco.com cisco.ippcp:25

At 12:52 PM 6/26/97 -0400, Naganand Doraswamy wrote:
>I am probably missing something here. The compression header is not
>compressed, right? If that is the case, then the next header field will
>not hide any protocol information, correct?

It depends on if it is in the compression header or in the compressed
data.

>If possible, I would like to avoid appending values in front of PDU only
>because of implementation issue. I would like to compresses the payload as
>I get it from the upper layers. In that case, I dont have to play around
>with mbufs.

The payload type (next header) is going to be contiguous to the data
no matter what.

If I'm negotiating a "Compression Association" for a particular protocol
(and possibly a fixed set of ports), that information can be constant
for the lifetime of the compression association.  If it constant, why
bother to transmit (even compressed) or you could think of it as
compressing down to 0 bits.  On the receiving side, you can restore
than information using the state information stored in the compression
association.
-- 
Matt Thomas                    Internet:   [email-masked]
Internet Locksmith             WWW URL:    <coming eventually>
AltaVista Internet Software    Disclaimer: This message reflects my own
Littleton, MA                              warped views, etc.

Path: cronkite.cisco.com!newsgate.cisco.com
From: [email-masked] (Matt Thomas)
To: [email-masked]
Newsgroups: cisco.ippcp
Subject: Early version of draft-thomas-ippcp-compression-00.txt
Message-ID: <[email-masked]>
Date: 26 Jun 97 18:08:58 GMT
Organization: Cisco Systems, San Jose, California, USA
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Lines: 304
Xref: cronkite.cisco.com cisco.ippcp:26

This is a very early version of my draft (just to give an idea of
how I'm approaching this).  Comments are welcome but be gentle,
I've only pent a handful of hours on this so far...

Compression Working Group                                    Matt Thomas
Internet Draft                               AltaVista Internet Software
                                                               July 1997

                     The Compressed Payload Header

                 draft-thomas-ippcp-compression-00.txt

Abstract

   This doucment defines the Compressed Payload Header.  The Compressed 
   Payload Header encapsulates payloads (TCP header and data for 
   instance) which have been compressed for traversal of the network. 
   The Compressed Payload Header is generally used in conjunction with 
   the IP Security Headers.

Status of This Memo

    This document is a submission to the Compression Working Group of 
   the Internet Engineering Task Force (IETF).  Comments should be 
   submitted to the [email-masked] mailing list.  This 
   document is not at this time a product of the Compression Working 
   Group, but a proposal to become a product of the Compression Working 
   Group. 

   This document is an Internet-Draft.  Internet-Drafts are working 
   documents of the Internet Engineering Task Force (IETF), its areas, 
   and its working groups.  Note that other groups may also distribute 
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six 
   months and may be updated, replaced, or obsoleted by other documents 
   at any time.  It is inappropriate to use Internet-Drafts as 
   reference material or to cite them other than as ``work in 
   progress.''

   To learn the current status of any Internet-Draft, please check the 
   ``1id-abstracts.txt'' listing contained in the Internet-Drafts 
   Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 
   ftp.isi.edu (US West Coast).

   Distribution of this document is unlimited.

Table Of Contents

       1. Introduction                                                 2
          1.1. Specification of Requirements                           2
       2. Compression Process                                          2
       3. Compressed Payload Header Format                             2
       4. Negotiation                                                  3
       5. Security Considerations                                      4

Expires December 1997                                           [Page 1]

Internet Draft        The Compressed Payload Header            July 1997

       6. References                                                   4
       7. Authors' Addresses                                           4

Expires December 1997                                           [Page 2]

Internet Draft        The Compressed Payload Header            July 1997

1. Introduction

   The use of IP Security will prevent layers below IP from being able 
   to compress data.  Thus in addition to the computational overhead of 
   IP Security, IP Security will also cause a significant loss in 
   effective throughput on those network paths that use compression at 
   the datalink level or below (e.g PPP).

   To aleviate this, before the data is encrypted by IP Security it 
   should be compressed.  For this case, the Compressed Payload Header 
   has been created.

   A notion of a Compress Association is used in this document.  It 
   refers to a set of compression information relating to a network 
   connection or a set of network connections.  It is analagous to a 
   Security  Assocation as used by IP Security.

1.1. Specification of Requirements

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
   document are to be interpreted as described in RFC 2119 [RFC-2119].

2. Compression Process

   The compression processing of IP datagrams has two phases, 
   compressing of outbound IP datagrams ("Compression") and 
   decompressing of inbound datagrams ("Decompression").  The 
   compression processing MUST be lossless, ensuring that the IP 
   atagram after being Compressed and Decompressed is identical to the 
   original IP datagram.

   The Compression of outbound IP datagrams MUST be done before any IP 
   security processing, such as encryption and authentication, and 
   before any fragmentation of the IP datagram.  Similarly, the 
   Decompression of inbound IP datagrams MUST be done after the 
   reassembly of the IP datagrams, and after the completion of all IP 
   security processing, such as authentication and decryption.  
   Processing of inbound IP datagrams MUST support both Compressed and 
   non-compressed IP datagrams.

   Each IP datagram is Compressed and Decompressed by itself without 
   any relation to other datagrams ("stateless compression"), as IP 
   datagrams may arrive out of order.  The Compression is applied to 
   only the upper layer protocol (ULP) payload and does not include the 
   IP header or other optional headers such as the Hop-By-Hop header or 
   Routing header.  The size of a Compressed datagram is always in 
   whole octet units.

3. Compressed Payload Header Format

   With inspiration from IPv6, the following header is defined as:

Expires December 1997                                           [Page 3]

Internet Draft        The Compressed Payload Header            July 1997

       0                   32      32+N                EOP
       +-------------------+--------+...--------------+
       |        CPI        |  CHDR  | compressed data |
       +-------------------+--------+...--------------+

   CPI             The Compression Parameters Index (CPI) is a 32-bit 
                   pseudo-random value identifying the compression 
                   association for this datagram.  The  Compression 
                   Parameters Index value 0 is reserved to indicate 
                   that "no compression association exists"; this value 
                   should only be used for development purposes.

                   The set of Compression Parameters Index values in 
                   the range 1 through 255 are reserved to the Internet 
                   Assigned Numbers Authority (IANA) for future use.  A 
                   reserved CPI value will not normally be assigned by 
                   IANA unless the use of that particular assigned CPI 
                   value is openly specified in an RFC.  A reserved CPI 
                   value SHALL NOT have implicit state (payload type, 
                   ports, etc.).

   CHDR            The Compression Header is a variable-length 
                   per-algorithm area which contains information on how 
                   to decompress the compressed data.  This  header MAY 
                   end on a byte boundary.

   The payload type (protocol type) of the Compress Payload Header is 
   <TDB>.

   The payload type of the compressed data MUST be obtained from either 
   the Compression Association, the Compression Header, or the 
   compressed data.  How is it obtained is algorithm-specific.

   Note that compression can be negotiated without AH or ESP.  The 
   Compression Algorithm SHOULD detect data corruption in the compress 
   payload.

4. Negotiation

   Before the compressed Payload Header can be used, it must be known 
   that the destination can decode the Compressed Payload Header.  This 
   can be done either manually or be negotiated using ``Internet 
   Security Association and Key Management Protocol (ISAKMP)'' 
   [ISAKMP], ``The resolution of ISAKMP with Oakley'' [OAKLEY], and 
   `The Internet IP Security Domain of Interpretation for ISAKMP'' 
   [IPDOI].

   When negotiating for the use of the Compressed Payload Header, an 
   ISAKMP proposal payload is generated with the PROTOCOL-ID set to CPH 
   <value is TBD by IANA> and a n.on-zero number of Transform payloads, 
   one for each compression protocol supported.

   When specifying the CPI in the proposal payload, the CPI is placed 
   in first 4 bytes of SPI field in network order and remaining 4 bytes 

Expires December 1997                                           [Page 4]

Internet Draft        The Compressed Payload Header            July 1997

   are filled with 0.

   If the negotiation fails, then compression MUST NOT be used.

5. Security Considerations

   This protocol presents a challenge to security gateways.  It is 
   expected that when the Compressed Payload Header is not encapulated 
   in an Encapsulating Security Payload, the CPI in conjuction with the 
   source and destination addresses will be used by security gateways 
   to permit or deny passage of the packet.  Any packet not matching 
   the  identities (e.g. protocol and/or port) of establishers of the 
   CPI MUST be discarded by the destination node and, optionally, an 
   audit entry SHOULD be created.

6. References

   [RFC-2119]      S. Bradner, "Key words for use in RFCs to Indicate 
                   Requirement Levels", Best Current Practices, March 
                   1997

   [IPDOI]         D. Pipper, "The Internet IP Security Domain of 
                   Interpretation for ISAKMP", 
                   draft-ietf-ipsec-ipsec-doi-02.txt, Febuary 1997

   [ISAKMP]        D. Maughan, M. Schertler, M. Schneider, J. Turner, 
                   "Internet Security Association and Key Management 
                   Protocol (ISAKMP)", draft-ietf-ipsec-isakmp-07.txt, 
                   March 1997

   [RFC-2119]      D. Harkins, D. Carrel, "The resolution of ISAKMP 
                   with Oakley", draft-ietf-ipsec-isakmp-oakley-03.txt, 
                   March 1997

7. Authors' Addresses

       Matt Thomas
       AltaVista Internet Software
       30 Porter Road
       Littleton, MA 01460
       Email: [email-masked]

Expires December 1997                                           [Page 5]

-- 
Matt Thomas                    Internet:   [email-masked]
Internet Locksmith             WWW URL:    <coming eventually>
AltaVista Internet Software    Disclaimer: This message reflects my own
Littleton, MA                              warped views, etc.

Path: cronkite.cisco.com!newsgate.cisco.com
From: [email-masked] (Avram Shacham)
To: Naganand Doraswamy <[email-masked]>
Cc: Rodney Thayer <[email-masked]>,
        Thomas Narten <[email-masked]>, [email-masked]
Newsgroups: cisco.ippcp
Subject: Re: IP Payload Compression Protocol (IPComp)
Message-ID: <[email-masked]>
Date: 26 Jun 97 18:35:46 GMT
Organization: Cisco Systems, San Jose, California, USA
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Lines: 47
Xref: cronkite.cisco.com cisco.ippcp:27

Naganand,

You are right, the compression header is not compressed. Also,
implementation may dictate which type of header we select for the IPComp
protocol.

The IPComp header should provide three basic pieces of information: (a) the
fact that the protocol is IPComp or, in other words, the IP payload is
compressed, (b) the length of compressed packet, and (c) the original
protocol and length of the payload. Two methods to provide this data were
presented so far. The first is IP-over-IP (as described in my
to-be-submitted I-D), where the original payload - starting with the
original IP header and including the upper layer protocol (ULP) payload - is
compressed and an IP header with new protocol (IPComp) and length fields are
marked. The second method, as I understood it, is to compress the ULP
payload only, to modify the original IP header to reflect a new protocol and
packet length and insert a specially added header between the IP header and
the compressed payload, where the original protocol is kept.

The difference between these approaches can be summarized as implementation
simplicity in the case of IP-over-IP vs. saving 12 octets of header in the
case of a special IPComp header insertion. 

I implemented the IP-over-IP in the Cisco stack and found the integration to
be very natural in the BSD code-base. Only minimal changes were required to
ip_output, ip_input, and IPSec processes. 

Has someone experienced with the other method?

avram

At 12:52 PM 6/26/97 -0400, Naganand Doraswamy wrote:
>I am probably missing something here. The compression header is not
>compressed, right? If that is the case, then the next header field will
>not hide any protocol information, correct?
>
>If possible, I would like to avoid appending values in front of PDU only
>because of implementation issue. I would like to compresses the payload as
>I get it from the upper layers. In that case, I dont have to play around
>with mbufs.
>
>
>
>
>

Path: cronkite.cisco.com!newsgate.cisco.com
From: [email-masked] (Roy Pereira)
To: "'Naganand Doraswamy'" <[email-masked]>,
        "'Avram Shacham'"
	 <[email-masked]>
Cc: "'Rodney Thayer'" <[email-masked]>,
        "'Thomas Narten'"
	 <[email-masked]>,
        "[email-masked]'"
	 <[email-masked]>
Newsgroups: cisco.ippcp
Subject: RE: IP Payload Compression Protocol (IPComp)
Message-ID: <c=US%a=_%p=TimeStep_Corpora%l=[email-masked]>
Date: 26 Jun 97 19:04:10 GMT
Organization: Cisco Systems, San Jose, California, USA
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Lines: 12
Xref: cronkite.cisco.com cisco.ippcp:28

>The second method, as I understood it, is to compress the ULP
>payload only, to modify the original IP header to reflect a new protocol and
>packet length and insert a specially added header between the IP header and
>the compressed payload, where the original protocol is kept.

Just like IPSec, though, we can tunnel the original IP header if
desired.

IP' CP IP UDP HTTP
or
IP' CP UDP HTTP
>

Path: cronkite.cisco.com!newsgate.cisco.com
From: [email-masked] (Avram Shacham)
To: Roy Pereira <[email-masked]>,
        "'Naganand Doraswamy'" <[email-masked]>
Cc: "'Rodney Thayer'" <[email-masked]>,
        "'Thomas Narten'" <[email-masked]>,
        "[email-masked]'" <[email-masked]>
Newsgroups: cisco.ippcp
Subject: RE: IP Payload Compression Protocol (IPComp)
Message-ID: <[email-masked]>
Date: 26 Jun 97 19:47:19 GMT
Organization: Cisco Systems, San Jose, California, USA
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Lines: 21
Xref: cronkite.cisco.com cisco.ippcp:29

At 03:04 PM 6/26/97 -0400, Roy Pereira wrote:
>>The second method, as I understood it, is to compress the ULP
>>payload only, to modify the original IP header to reflect a new protocol and
>>packet length and insert a specially added header between the IP header and
>>the compressed payload, where the original protocol is kept.
>
>Just like IPSec, though, we can tunnel the original IP header if
>desired.
>
>IP' CP IP UDP HTTP
>or
>IP' CP UDP HTTP
>>

In the first format, what purpose does CP serve?  As far as I see, all
IPComp information can be stored in the two IP headers (the tunnel and the
original). And, without CP, isn't this format identical to IP-over-IP as in
my draft?

Isn't the trend in IPSec community to move away from the second format?

Path: cronkite.cisco.com!newsgate.cisco.com
From: [email-masked] (Roy Pereira)
To: Roy Pereira <[email-masked]>,
        "'Naganand Doraswamy'"
	 <[email-masked]>,
        "'Avram Shacham'" <[email-masked]>
Cc: "'Rodney Thayer'" <[email-masked]>,
        "'Thomas Narten'"
	 <[email-masked]>,
        "[email-masked]'"
	 <[email-masked]>
Newsgroups: cisco.ippcp
Subject: RE: IP Payload Compression Protocol (IPComp)
Message-ID: <c=US%a=_%p=TimeStep_Corpora%l=[email-masked]>
Date: 26 Jun 97 20:05:23 GMT
Organization: Cisco Systems, San Jose, California, USA
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Lines: 35
Xref: cronkite.cisco.com cisco.ippcp:30

>
>At 03:04 PM 6/26/97 -0400, Roy Pereira wrote:
>>>The second method, as I understood it, is to compress the ULP
>>>payload only, to modify the original IP header to reflect a new protocol
>>>and
>>>packet length and insert a specially added header between the IP header and
>>>the compressed payload, where the original protocol is kept.
>>
>>Just like IPSec, though, we can tunnel the original IP header if
>>desired.
>>
>>IP' CP IP UDP HTTP
>>or
>>IP' CP UDP HTTP
>>>
>
>In the first format, what purpose does CP serve?  As far as I see, all
>IPComp information can be stored in the two IP headers (the tunnel and the
>original). And, without CP, isn't this format identical to IP-over-IP as in
>my draft?

CP is the Compression Protocol header.  It contains a CPI and any other
compression algorithm specific information required as well as the next
header.

>Isn't the trend in IPSec community to move away from the second format?

Tunneling provides identity protection if the original IP header is
encrypted.  It also is invaluable for tunneling to an endpoint other
than the original destination, thus the original IP addresses might not
be on the Internet.
>

Path: cronkite.cisco.com!newsgate.cisco.com
From: [email-masked] (Avram Shacham)
To: [email-masked]
Newsgroups: cisco.ippcp
Subject: keep thy mailing-list clean...
Message-ID: <[email-masked]>
Date: 26 Jun 97 20:43:32 GMT
Organization: Cisco Systems, San Jose, California, USA
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Lines: 14
Xref: cronkite.cisco.com cisco.ippcp:31

IPPCP WG,

Even though the ippcp mailing-list is very young, whenever I send a message
to the group, the mailer informs me that a certain subscriber is unreachable
as "Host unknown". Other members of the list reported similar symptoms.

In order to keep the list in good shape and reduce the noise, I removed this
member (x.y.soft.net) from the list.

I am sorry for any inconvenience that such step may cause.

Cheers,
avram

Path: cronkite.cisco.com!newsgate.cisco.com
From: [email-masked] (Avram Shacham)
To: Matt Thomas <[email-masked]>
Cc: [email-masked]
Newsgroups: cisco.ippcp
Subject: Re: Early version of draft-thomas-ippcp-compression-00.txt
Message-ID: <[email-masked]>
Date: 26 Jun 97 21:37:02 GMT
Organization: Cisco Systems, San Jose, California, USA
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Lines: 105
Xref: cronkite.cisco.com cisco.ippcp:32

At 02:08 PM 6/26/97 -0400, Matt Thomas wrote:
<SNIP>
>Abstract
>
>   This doucment defines the Compressed Payload Header.  The Compressed 
>   Payload Header encapsulates payloads (TCP header and data for 
>   instance) which have been compressed for traversal of the network. 
>   The Compressed Payload Header is generally used in conjunction with 
>   the IP Security Headers.

Why is the restriction? IPComp can be effective in non-IPSec environments,
such as slow or congested links.  Even you specify later:

   "Note that compression can be negotiated without AH or ESP."

<SNIP>

>1. Introduction
>
>   The use of IP Security will prevent layers below IP from being able 
>   to compress data.  Thus in addition to the computational overhead of 
>   IP Security, IP Security will also cause a significant loss in 
>   effective throughput on those network paths that use compression at 
>   the datalink level or below (e.g PPP).
>
>   To aleviate this, before the data is encrypted by IP Security it 
>   should be compressed.  For this case, the Compressed Payload Header 
>   has been created.
>

SHOULD is too strong. There is a performance penalty for using IP
compression, especially when the link speed is not the bottleneck. You may
want to revisit the data that I presented to IPSec WG in Memphis.

<SNIP>
>2. Compression Process
>
>   The compression processing of IP datagrams has two phases, 
>   compressing of outbound IP datagrams ("Compression") and 
>   decompressing of inbound datagrams ("Decompression").  The 
>   compression processing MUST be lossless, ensuring that the IP 
>   atagram after being Compressed and Decompressed is identical to the 
>   original IP datagram.
>
>   The Compression of outbound IP datagrams MUST be done before any IP 
>   security processing, such as encryption and authentication, and 
>   before any fragmentation of the IP datagram.  Similarly, the 
>   Decompression of inbound IP datagrams MUST be done after the 
>   reassembly of the IP datagrams, and after the completion of all IP 
>   security processing, such as authentication and decryption.  
>   Processing of inbound IP datagrams MUST support both Compressed and 
>   non-compressed IP datagrams.
>
>   Each IP datagram is Compressed and Decompressed by itself without 
>   any relation to other datagrams ("stateless compression"), as IP 
>   datagrams may arrive out of order. 

I see that we totally agree in this section. in fact, you just cut-and-paste
it from page 2 of my draft, without even referencing the source :(

And, you omitted the paragraphs in page 3 of this section of my draft, where
requirement for non-expansion and recommendation for threshold and
adaptive-algorithm for pre-compressed payload were defined.

>3. Compressed Payload Header Format
>
>   With inspiration from IPv6, the following header is defined as:
>
<SNIP>
>       0                   32      32+N                EOP
>       +-------------------+--------+...--------------+
>       |        CPI        |  CHDR  | compressed data |
>       +-------------------+--------+...--------------+
>
>   CPI             The Compression Parameters Index (CPI) is a 32-bit 
>                   pseudo-random value identifying the compression 
>                   association for this datagram.  The  Compression 
>                   Parameters Index value 0 is reserved to indicate 
>                   that "no compression association exists"; this value 
>                   should only be used for development purposes.
>
>                   The set of Compression Parameters Index values in 
>                   the range 1 through 255 are reserved to the Internet 
>                   Assigned Numbers Authority (IANA) for future use.  A 
>                   reserved CPI value will not normally be assigned by 
>                   IANA unless the use of that particular assigned CPI 
>                   value is openly specified in an RFC.  A reserved CPI 
>                   value SHALL NOT have implicit state (payload type, 
>                   ports, etc.).
>
>   CHDR            The Compression Header is a variable-length 
>                   per-algorithm area which contains information on how 
>                   to decompress the compressed data.  This  header MAY 
>                   end on a byte boundary.
>

This information is negotiated between the hosts. Why should this data be
sent with every packet?

How does the IP header look like? 

Have you implemented this header format in a real-world TCP/IP stack?

avram

Path: cronkite.cisco.com!newsgate.cisco.com
From: [email-masked] (Matt Thomas)
To: Avram Shacham <[email-masked]>
Cc: [email-masked]
Newsgroups: cisco.ippcp
Subject: Re: Early version of draft-thomas-ippcp-compression-00.txt
Message-ID: <[email-masked]>
Date: 27 Jun 97 00:43:00 GMT
References: <[email-masked]>
Organization: Cisco Systems, San Jose, California, USA
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Lines: 137
Xref: cronkite.cisco.com cisco.ippcp:33

At 02:37 PM 6/26/97 -0700, Avram Shacham wrote:
>At 02:08 PM 6/26/97 -0400, Matt Thomas wrote:
><SNIP>
>>Abstract
>>
>>   This doucment defines the Compressed Payload Header.  The Compressed 
>>   Payload Header encapsulates payloads (TCP header and data for 
>>   instance) which have been compressed for traversal of the network. 
>>   The Compressed Payload Header is generally used in conjunction with 
>>   the IP Security Headers.
>
>Why is the restriction? IPComp can be effective in non-IPSec environments,
>such as slow or congested links.  Even you specify later:

There is no restriction.  I said generally used since if you are using
hardware level compression there not much need to compression at the
IP layer.

>   "Note that compression can be negotiated without AH or ESP."
>
><SNIP>

Nothing contradictory here.

>>1. Introduction
>>
>>   The use of IP Security will prevent layers below IP from being able 
>>   to compress data.  Thus in addition to the computational overhead of 
>>   IP Security, IP Security will also cause a significant loss in 
>>   effective throughput on those network paths that use compression at 
>>   the datalink level or below (e.g PPP).
>>
>>   To aleviate this, before the data is encrypted by IP Security it 
>>   should be compressed.  For this case, the Compressed Payload Header 
>>   has been created.
>>
>
>SHOULD is too strong. There is a performance penalty for using IP
>compression, especially when the link speed is not the bottleneck. You may
>want to revisit the data that I presented to IPSec WG in Memphis.

The "should" (not SHOULD) is referring to that if you doing datalink
level compression and using IPsec, IPcomp should be used to achieve
similar performance.

><SNIP>
>>2. Compression Process
>>
>>   The compression processing of IP datagrams has two phases, 
>>   compressing of outbound IP datagrams ("Compression") and 
>>   decompressing of inbound datagrams ("Decompression").  The 
>>   compression processing MUST be lossless, ensuring that the IP 
>>   atagram after being Compressed and Decompressed is identical to the 
>>   original IP datagram.
>>
>>   The Compression of outbound IP datagrams MUST be done before any IP 
>>   security processing, such as encryption and authentication, and 
>>   before any fragmentation of the IP datagram.  Similarly, the 
>>   Decompression of inbound IP datagrams MUST be done after the 
>>   reassembly of the IP datagrams, and after the completion of all IP 
>>   security processing, such as authentication and decryption.  
>>   Processing of inbound IP datagrams MUST support both Compressed and 
>>   non-compressed IP datagrams.
>>
>>   Each IP datagram is Compressed and Decompressed by itself without 
>>   any relation to other datagrams ("stateless compression"), as IP 
>>   datagrams may arrive out of order. 
>
>I see that we totally agree in this section. in fact, you just cut-and-paste
>it from page 2 of my draft, without even referencing the source :(

As I said, the draft was not ready for submittal.  I'll give you credit
when I formally submit it.  (I couldn't improve on it so I plagiarized it).

>And, you omitted the paragraphs in page 3 of this section of my draft, where
>requirement for non-expansion and recommendation for threshold and
>adaptive-algorithm for pre-compressed payload were defined.

Good point.  I hadn't plagiarized those section yet. :-)

>>3. Compressed Payload Header Format
>>
>>   With inspiration from IPv6, the following header is defined as:
>>
><SNIP>
>>       0                   32      32+N                EOP
>>       +-------------------+--------+...--------------+
>>       |        CPI        |  CHDR  | compressed data |
>>       +-------------------+--------+...--------------+
>>
>>   CPI             The Compression Parameters Index (CPI) is a 32-bit 
>>                   pseudo-random value identifying the compression 
>>                   association for this datagram.  The  Compression 
>>                   Parameters Index value 0 is reserved to indicate 
>>                   that "no compression association exists"; this value 
>>                   should only be used for development purposes.
>>
>>                   The set of Compression Parameters Index values in 
>>                   the range 1 through 255 are reserved to the Internet 
>>                   Assigned Numbers Authority (IANA) for future use.  A 
>>                   reserved CPI value will not normally be assigned by 
>>                   IANA unless the use of that particular assigned CPI 
>>                   value is openly specified in an RFC.  A reserved CPI 
>>                   value SHALL NOT have implicit state (payload type, 
>>                   ports, etc.).
>>
>>   CHDR            The Compression Header is a variable-length 
>>                   per-algorithm area which contains information on how 
>>                   to decompress the compressed data.  This  header MAY 
>>                   end on a byte boundary.
>>
>
>This information is negotiated between the hosts. Why should this data be
>sent with every packet?

There is not one compression protocol.  The CPI is used by destination to
look up a structure which describes the compression information being used.
(Just like a SPI is looked up for security info).  I have a few ideas on
how you could compression with some state (while being tolerant of losses).

>How does the IP header look like? 

Like an IP header.  The protocol field would be <CPH> and the packet length
would equal the size of the IP header, the CPI, the Compression Header, and
the compressed data.  

>Have you implemented this header format in a real-world TCP/IP stack?

Not yet.  I plan on doing a "deflate" implementation for NetBSD using
manual CPIs.  This is really very similar to IPsec (and should be able
to take advantage of the same infrastructure).
-- 
Matt Thomas                    Internet:   [email-masked]
Internet Locksmith             WWW URL:    <coming eventually>
AltaVista Internet Software    Disclaimer: This message reflects my own
Littleton, MA                              warped views, etc.

Path: cronkite.cisco.com!newsgate.cisco.com
From: [email-masked] (Avram Shacham)
To: Matt Thomas <[email-masked]>
Cc: [email-masked]
Newsgroups: cisco.ippcp
Subject: Re: Early version of draft-thomas-ippcp-compression-00.txt
Message-ID: <[email-masked]>
Date: 27 Jun 97 03:11:37 GMT
Organization: Cisco Systems, San Jose, California, USA
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Lines: 41
Xref: cronkite.cisco.com cisco.ippcp:34

At 08:43 PM 6/26/97 -0400, Matt Thomas wrote:
<SNIP>
>As I said, the draft was not ready for submittal.  I'll give you credit
>when I formally submit it.  (I couldn't improve on it so I plagiarized it).
<SNIP>
>Good point.  I hadn't plagiarized those section yet. :-)
<SNIP>
>There is not one compression protocol.  The CPI is used by destination to
>look up a structure which describes the compression information being used.
>(Just like a SPI is looked up for security info).  I have a few ideas on
>how you could compression with some state (while being tolerant of losses).
<SNIP>
>Not yet.  I plan on doing a "deflate" implementation for NetBSD using
>manual CPIs.  This is really very similar to IPsec (and should be able
>to take advantage of the same infrastructure).
>-- 

Matt,

Your candor is appreciated.

Now, in order to move forward toward achieving the stated goals of IPPCP WG,
let's focus on the main issue that you raised - the packet structure.

The IP-over-IP packet structure is working and the implementation was
natural to the BSD code-base. However, if there is a more-flexible,
more-efficient, and implementable IPComp packet structure, I'll be the first
to accept it. But I am still waiting to read such clear alternative.

On the other hand, those parts of the IPComp draft that you accept - such as
"Compression Process" - leave as they are...

avram

After all, no one wants to repeat the path, as reflected in Hilarie's rhymes:

  IPSEC is a protocol
  As dead as dead can be
  First it killed a working group
  And now its killing me

Path: cronkite.cisco.com!newsgate.cisco.com
From: [email-masked] (Rodney Thayer)
To: [email-masked]
Newsgroups: cisco.ippcp
Subject: Re: Early version of draft-thomas-ippcp-compression-00.txt
Message-ID: <[email-masked]>
Date: 27 Jun 97 09:22:24 GMT
Organization: Cisco Systems, San Jose, California, USA
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Lines: 124
Xref: cronkite.cisco.com cisco.ippcp:35

As the author of the compression draft that started this all at the
Montreal IETF I feel authorized to suggest we not snap at each other about
attribution, eh?  There's plenty on all sides.

>X-Sender: [email-masked]
>Date: Thu, 26 Jun 1997 14:37:02 -0700
>To: Matt Thomas <[email-masked]>
>From: Avram Shacham <[email-masked]>
>Subject: Re: Early version of draft-thomas-ippcp-compression-00.txt
>Cc: [email-masked]
>
>At 02:08 PM 6/26/97 -0400, Matt Thomas wrote:
><SNIP>
>>Abstract
>>
>>   This doucment defines the Compressed Payload Header.  The Compressed 
>>   Payload Header encapsulates payloads (TCP header and data for 
>>   instance) which have been compressed for traversal of the network. 
>>   The Compressed Payload Header is generally used in conjunction with 
>>   the IP Security Headers.
>
>Why is the restriction? IPComp can be effective in non-IPSec environments,
>such as slow or congested links.  Even you specify later:
>
>   "Note that compression can be negotiated without AH or ESP."
>
><SNIP>
>
>>1. Introduction
>>
>>   The use of IP Security will prevent layers below IP from being able 
>>   to compress data.  Thus in addition to the computational overhead of 
>>   IP Security, IP Security will also cause a significant loss in 
>>   effective throughput on those network paths that use compression at 
>>   the datalink level or below (e.g PPP).
>>
>>   To aleviate this, before the data is encrypted by IP Security it 
>>   should be compressed.  For this case, the Compressed Payload Header 
>>   has been created.
>>
>
>SHOULD is too strong. There is a performance penalty for using IP
>compression, especially when the link speed is not the bottleneck. You may
>want to revisit the data that I presented to IPSec WG in Memphis.
>
><SNIP>
>>2. Compression Process
>>
>>   The compression processing of IP datagrams has two phases, 
>>   compressing of outbound IP datagrams ("Compression") and 
>>   decompressing of inbound datagrams ("Decompression").  The 
>>   compression processing MUST be lossless, ensuring that the IP 
>>   atagram after being Compressed and Decompressed is identical to the 
>>   original IP datagram.
>>
>>   The Compression of outbound IP datagrams MUST be done before any IP 
>>   security processing, such as encryption and authentication, and 
>>   before any fragmentation of the IP datagram.  Similarly, the 
>>   Decompression of inbound IP datagrams MUST be done after the 
>>   reassembly of the IP datagrams, and after the completion of all IP 
>>   security processing, such as authentication and decryption.  
>>   Processing of inbound IP datagrams MUST support both Compressed and 
>>   non-compressed IP datagrams.
>>
>>   Each IP datagram is Compressed and Decompressed by itself without 
>>   any relation to other datagrams ("stateless compression"), as IP 
>>   datagrams may arrive out of order. 
>
>I see that we totally agree in this section. in fact, you just cut-and-paste
>it from page 2 of my draft, without even referencing the source :(
>
>And, you omitted the paragraphs in page 3 of this section of my draft, where
>requirement for non-expansion and recommendation for threshold and
>adaptive-algorithm for pre-compressed payload were defined.
>
>>3. Compressed Payload Header Format
>>
>>   With inspiration from IPv6, the following header is defined as:
>>
><SNIP>
>>       0                   32      32+N                EOP
>>       +-------------------+--------+...--------------+
>>       |        CPI        |  CHDR  | compressed data |
>>       +-------------------+--------+...--------------+
>>
>>   CPI             The Compression Parameters Index (CPI) is a 32-bit 
>>                   pseudo-random value identifying the compression 
>>                   association for this datagram.  The  Compression 
>>                   Parameters Index value 0 is reserved to indicate 
>>                   that "no compression association exists"; this value 
>>                   should only be used for development purposes.
>>
>>                   The set of Compression Parameters Index values in 
>>                   the range 1 through 255 are reserved to the Internet 
>>                   Assigned Numbers Authority (IANA) for future use.  A 
>>                   reserved CPI value will not normally be assigned by 
>>                   IANA unless the use of that particular assigned CPI 
>>                   value is openly specified in an RFC.  A reserved CPI 
>>                   value SHALL NOT have implicit state (payload type, 
>>                   ports, etc.).
>>
>>   CHDR            The Compression Header is a variable-length 
>>                   per-algorithm area which contains information on how 
>>                   to decompress the compressed data.  This  header MAY 
>>                   end on a byte boundary.
>>
>
>This information is negotiated between the hosts. Why should this data be
>sent with every packet?
>
>How does the IP header look like? 
>
>Have you implemented this header format in a real-world TCP/IP stack?
>
>avram
>
>
>

-- Rodney Thayer <mailto:[email-masked]> Sable Technology Corporation
   246 Walnut Street Newton MA 02160 U.S.A.  +1 617 332 7292 +1 617 332
7970(Fax)

Path: cronkite.cisco.com!newsgate.cisco.com
From: [email-masked] (Rodney Thayer)
To: [email-masked]
Newsgroups: cisco.ippcp
Subject: compression with security
Message-ID: <[email-masked]>
Date: 27 Jun 97 09:24:18 GMT
Organization: Cisco Systems, San Jose, California, USA
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Lines: 129
Xref: cronkite.cisco.com cisco.ippcp:36

I thought the charter of this WG was to focus on compression for use with
security, so references to that are appropriate.  I have had many
experiences of being told that compression is stupid if you're not doing
encryption, because, like, dude, everyone uses compression on their PPP
links, don't you know?

That's one of the things we were told back at the Seattle IETF when we had
the compression BOF then.

>X-Sender: [email-masked]
>Date: Thu, 26 Jun 1997 14:37:02 -0700
>To: Matt Thomas <[email-masked]>
>From: Avram Shacham <[email-masked]>
>Subject: Re: Early version of draft-thomas-ippcp-compression-00.txt
>Cc: [email-masked]
>
>At 02:08 PM 6/26/97 -0400, Matt Thomas wrote:
><SNIP>
>>Abstract
>>
>>   This doucment defines the Compressed Payload Header.  The Compressed 
>>   Payload Header encapsulates payloads (TCP header and data for 
>>   instance) which have been compressed for traversal of the network. 
>>   The Compressed Payload Header is generally used in conjunction with 
>>   the IP Security Headers.
>
>Why is the restriction? IPComp can be effective in non-IPSec environments,
>such as slow or congested links.  Even you specify later:
>
>   "Note that compression can be negotiated without AH or ESP."
>
><SNIP>
>
>>1. Introduction
>>
>>   The use of IP Security will prevent layers below IP from being able 
>>   to compress data.  Thus in addition to the computational overhead of 
>>   IP Security, IP Security will also cause a significant loss in 
>>   effective throughput on those network paths that use compression at 
>>   the datalink level or below (e.g PPP).
>>
>>   To aleviate this, before the data is encrypted by IP Security it 
>>   should be compressed.  For this case, the Compressed Payload Header 
>>   has been created.
>>
>
>SHOULD is too strong. There is a performance penalty for using IP
>compression, especially when the link speed is not the bottleneck. You may
>want to revisit the data that I presented to IPSec WG in Memphis.
>
><SNIP>
>>2. Compression Process
>>
>>   The compression processing of IP datagrams has two phases, 
>>   compressing of outbound IP datagrams ("Compression") and 
>>   decompressing of inbound datagrams ("Decompression").  The 
>>   compression processing MUST be lossless, ensuring that the IP 
>>   atagram after being Compressed and Decompressed is identical to the 
>>   original IP datagram.
>>
>>   The Compression of outbound IP datagrams MUST be done before any IP 
>>   security processing, such as encryption and authentication, and 
>>   before any fragmentation of the IP datagram.  Similarly, the 
>>   Decompression of inbound IP datagrams MUST be done after the 
>>   reassembly of the IP datagrams, and after the completion of all IP 
>>   security processing, such as authentication and decryption.  
>>   Processing of inbound IP datagrams MUST support both Compressed and 
>>   non-compressed IP datagrams.
>>
>>   Each IP datagram is Compressed and Decompressed by itself without 
>>   any relation to other datagrams ("stateless compression"), as IP 
>>   datagrams may arrive out of order. 
>
>I see that we totally agree in this section. in fact, you just cut-and-paste
>it from page 2 of my draft, without even referencing the source :(
>
>And, you omitted the paragraphs in page 3 of this section of my draft, where
>requirement for non-expansion and recommendation for threshold and
>adaptive-algorithm for pre-compressed payload were defined.
>
>>3. Compressed Payload Header Format
>>
>>   With inspiration from IPv6, the following header is defined as:
>>
><SNIP>
>>       0                   32      32+N                EOP
>>       +-------------------+--------+...--------------+
>>       |        CPI        |  CHDR  | compressed data |
>>       +-------------------+--------+...--------------+
>>
>>   CPI             The Compression Parameters Index (CPI) is a 32-bit 
>>                   pseudo-random value identifying the compression 
>>                   association for this datagram.  The  Compression 
>>                   Parameters Index value 0 is reserved to indicate 
>>                   that "no compression association exists"; this value 
>>                   should only be used for development purposes.
>>
>>                   The set of Compression Parameters Index values in 
>>                   the range 1 through 255 are reserved to the Internet 
>>                   Assigned Numbers Authority (IANA) for future use.  A 
>>                   reserved CPI value will not normally be assigned by 
>>                   IANA unless the use of that particular assigned CPI 
>>                   value is openly specified in an RFC.  A reserved CPI 
>>                   value SHALL NOT have implicit state (payload type, 
>>                   ports, etc.).
>>
>>   CHDR            The Compression Header is a variable-length 
>>                   per-algorithm area which contains information on how 
>>                   to decompress the compressed data.  This  header MAY 
>>                   end on a byte boundary.
>>
>
>This information is negotiated between the hosts. Why should this data be
>sent with every packet?
>
>How does the IP header look like? 
>
>Have you implemented this header format in a real-world TCP/IP stack?
>
>avram
>
>
>

-- Rodney Thayer <mailto:[email-masked]> Sable Technology Corporation
   246 Walnut Street Newton MA 02160 U.S.A.  +1 617 332 7292 +1 617 332
7970(Fax)

Path: cronkite.cisco.com!newsgate.cisco.com
From: [email-masked] (Naganand Doraswamy)
To: Rodney Thayer <[email-masked]>
Cc: [email-masked]
Newsgroups: cisco.ippcp
Subject: Re: compression with security
Message-ID: <Pine.SUN.3.96.970627084842.1906M-100000@span>
Date: 27 Jun 97 12:50:53 GMT
References: <[email-masked]>
Organization: Cisco Systems, San Jose, California, USA
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Lines: 22
Xref: cronkite.cisco.com cisco.ippcp:37

Rodney,

The primary focus of the working group is to come up with a compression
protocol to work with IPsec. However, the charter says we will also try to
define to use compression in the absence of IPsec. So, I would say that we
should aim for the latter first. In case it gets too complicated, then we
could first concentrate on making it work with IPsec with the goal of
making it work in the absence of IPsec as well.

I dont think it is very difficult to make it work in both the environments
and I would say that we should try to solve this problem.

--Naganand

-------------------------------------------------------------------------------

Naganand Doraswamy		(508)916-1323 (O)				
Bay Architecture Lab		(508)670-8153 (F)
Bay Networks, Inc.
3 Federal St, BL3-04
Billerica, MA 01821

Path: cronkite.cisco.com!newsgate.cisco.com
From: [email-masked] (Roy Pereira)
To: "'Matt Thomas'" <[email-masked]>,
        "'Avram Shacham'"
	 <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Newsgroups: cisco.ippcp
Subject: RE: Early version of draft-thomas-ippcp-compression-00.txt
Message-ID: <c=US%a=_%p=TimeStep_Corpora%l=[email-masked]>
Date: 27 Jun 97 18:05:25 GMT
Organization: Cisco Systems, San Jose, California, USA
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Lines: 31
Xref: cronkite.cisco.com cisco.ippcp:38

>The IP-over-IP packet structure is working and the implementation was
>natural to the BSD code-base. However, if there is a more-flexible,
>more-efficient, and implementable IPComp packet structure, I'll be the first
>to accept it. But I am still waiting to read such clear alternative.

Not to be a pain, but I don't consider the fact that any implementation
is "natural to the BSD code-base" to be a factor in deciding on how to
design a compression protocol.  Most implementations will be running
Win3.1 (yikes!!) anyways.

I think that Avram's solution, while it works now, is inflexibile for
what I would consider a long-term Internet protocol.  

The notion of a Security Parameter Index (SPI) from IPSec is a great
idea and we should embrace it with a Compression Parameter Index (CPI)
as Matt has done.  With Avram's protocol, only one Association can exist
for each host pair, while the IPSec method allows any number of SPIs or
Associations to be assigned to host pairs.

Also the compresion algorithm specific header is a good idea that will
allow us to add any number of different compression algorithms in the
future.

from Matt's draft:
>  "The Compression is applied to only the upper layer protocol (ULP) payload
>and does not include the  IP header or other optional headers such as the
Hop-By-Hop header or  Routing header."

I'm not sure I understand why we do not allow tunneling.

Path: cronkite.cisco.com!newsgate.cisco.com
From: [email-masked] (Avram Shacham)
To: Roy Pereira <[email-masked]>,
        "'Matt Thomas'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Newsgroups: cisco.ippcp
Subject: RE: Early version of draft-thomas-ippcp-compression-00.txt
Message-ID: <[email-masked]>
Date: 27 Jun 97 19:48:34 GMT
Organization: Cisco Systems, San Jose, California, USA
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Lines: 45
Xref: cronkite.cisco.com cisco.ippcp:39

At 02:05 PM 6/27/97 -0400, Roy Pereira wrote:
<SNIP>
> Most implementations will be running Win3.1 (yikes!!) anyways.

Nothing prevents BSD code from running in Win 3.1 :)  However, that is
really not the issue...

>
>I think that Avram's solution, while it works now, is inflexibile for
>what I would consider a long-term Internet protocol.  
>
>The notion of a Security Parameter Index (SPI) from IPSec is a great
>idea and we should embrace it with a Compression Parameter Index (CPI)
>as Matt has done.  With Avram's protocol, only one Association can exist
>for each host pair, while the IPSec method allows any number of SPIs or
>Associations to be assigned to host pairs.

Your observation that my draft is based on a single host-to-host compression
policy is correct. If the market demand is to support multiple compression
policies between a single pair of hosts (i.e., per ULP content), than I
agree that CPI is the way to go. The question is - how do we make sure that
such market requirement really exists? I am trying to avoid building a
complex protocol, where only a trivial subset will be used.

>Also the compresion algorithm specific header is a good idea that will
>allow us to add any number of different compression algorithms in the
>future.

The support for different compression algorithms does exist in my draft, and
implemented in the negotiation phase. In stateless compression, I did not
find any per-packet data that is not included in the compressed payload. But
I used just one algorithm, so I may be missing something.

>from Matt's draft:
>>  "The Compression is applied to only the upper layer protocol (ULP) payload
>>and does not include the  IP header or other optional headers such as the
>Hop-By-Hop header or  Routing header."
>
>I'm not sure I understand why we do not allow tunneling.
>

Ditto.

avram

Path: cronkite.cisco.com!newsgate.cisco.com
From: [email-masked] (Matt Thomas)
To: Roy Pereira <[email-masked]>
Cc: <[email-masked]>
Newsgroups: cisco.ippcp
Subject: RE: Early version of draft-thomas-ippcp-compression-00.txt
Message-ID: <[email-masked]>
Date: 27 Jun 97 20:12:41 GMT
Organization: Cisco Systems, San Jose, California, USA
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Lines: 19
Xref: cronkite.cisco.com cisco.ippcp:40

>from Matt's draft:
>>  "The Compression is applied to only the upper layer protocol (ULP) payload
>>and does not include the  IP header or other optional headers such as the
>Hop-By-Hop header or  Routing header."
>
>I'm not sure I understand why we do not allow tunneling.

Depends on what you mean by tunnelling.  If you use IP in IP for where
the inner addresses differ from the outer addresses, the inner IP header
would be considered the upper layer payload.  I don't the see point of
using tunnel if the the inner and outer IP headers are going to be the
same.

-- 
Matt Thomas                    Internet:   [email-masked]
Internet Locksmith             WWW URL:    <coming eventually>
AltaVista Internet Software    Disclaimer: This message reflects my own
Littleton, MA                              warped views, etc.

Path: cronkite.cisco.com!newsgate.cisco.com
From: [email-masked] (Roy Pereira)
To: Roy Pereira <[email-masked]>,
        "'Matt Thomas'"
	 <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Newsgroups: cisco.ippcp
Subject: RE: Early version of draft-thomas-ippcp-compression-00.txt
Message-ID: <c=US%a=_%p=TimeStep_Corpora%l=[email-masked]>
Date: 27 Jun 97 20:37:57 GMT
Organization: Cisco Systems, San Jose, California, USA
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Lines: 36
Xref: cronkite.cisco.com cisco.ippcp:41

Just like IPSec though, I would like to be able to tunnel a packet to
another endpoint.  Thus I get a nornal IP TCP HTTP packet , I decide
from policy that I need to send this packet out to some one else and I
would like it compressed (not secured, dont ask me why).  I would set up
an SA with ISAKMP, then I would use CP to compress the entire IP TCP
HTTP packet and pre-pend another IP header with the new destination
address.  Exactly like ESP/AH tunneling...

>----------
>From: 	Matt Thomas[SMTP:[email-masked]]
>Sent: 	Friday, June 27, 1997 4:12 PM
>To: 	Roy Pereira
>Cc: 	[email-masked]
>Subject: 	RE: Early version of draft-thomas-ippcp-compression-00.txt
>
>
>>from Matt's draft:
>>>  "The Compression is applied to only the upper layer protocol (ULP)
>>>payload
>>>and does not include the  IP header or other optional headers such as the
>>Hop-By-Hop header or  Routing header."
>>
>>I'm not sure I understand why we do not allow tunneling.
>
>Depends on what you mean by tunnelling.  If you use IP in IP for where
>the inner addresses differ from the outer addresses, the inner IP header
>would be considered the upper layer payload.  I don't the see point of
>using tunnel if the the inner and outer IP headers are going to be the
>same.
>
>-- 
>Matt Thomas                    Internet:   [email-masked]
>Internet Locksmith             WWW URL:    <coming eventually>
>AltaVista Internet Software    Disclaimer: This message reflects my own
>Littleton, MA                              warped views, etc.
>

Path: cronkite.cisco.com!newsgate.cisco.com
From: [email-masked] (Matt Thomas)
To: Roy Pereira <[email-masked]>
Cc: <[email-masked]>
Newsgroups: cisco.ippcp
Subject: RE: Early version of draft-thomas-ippcp-compression-00.txt
Message-ID: <[email-masked]>
Date: 27 Jun 97 21:05:50 GMT
Organization: Cisco Systems, San Jose, California, USA
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Lines: 18
Xref: cronkite.cisco.com cisco.ippcp:42

At 04:37 PM 6/27/97 -0400, Roy Pereira wrote:
>Just like IPSec though, I would like to be able to tunnel a packet to
>another endpoint.  Thus I get a nornal IP TCP HTTP packet , I decide
>from policy that I need to send this packet out to some one else and I
>would like it compressed (not secured, dont ask me why).  I would set up
>an SA with ISAKMP, then I would use CP to compress the entire IP TCP
>HTTP packet and pre-pend another IP header with the new destination
>address.  Exactly like ESP/AH tunneling...

As I said, that's fine.  I can understand that.  The inner IP packet
is the upper-layer-payload to be compressed (IP header and all).  I
can't see why one would do that if the inner IP addresses were the
same as the outer IP addresses.
-- 
Matt Thomas                    Internet:   [email-masked]
Internet Locksmith             WWW URL:    <coming eventually>
AltaVista Internet Software    Disclaimer: This message reflects my own
Littleton, MA                              warped views, etc.

Path: cronkite.cisco.com!newsgate.cisco.com
From: [email-masked] (Naganand Doraswamy)
To: Avram Shacham <[email-masked]>
Cc: Roy Pereira <[email-masked]>,
        "'Matt Thomas'" <[email-masked]>,
        "[email-masked]'" <[email-masked]>
Newsgroups: cisco.ippcp
Subject: RE: Early version of draft-thomas-ippcp-compression-00.txt
Message-ID: <Pine.SUN.3.96.970630091431.2090E-100000@span>
Date: 30 Jun 97 13:17:46 GMT
References: <[email-masked]>
Organization: Cisco Systems, San Jose, California, USA
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Lines: 26
Xref: cronkite.cisco.com cisco.ippcp:43

Avram,

I agree with Roy on the subject of providing a separate compressoin header
so that we can support per socket compression. I do not know at present
what the market is looking for. At this time, it may be probably host to
host compression.

However, I feel it is not a good reason not to have a compression header.
I think we need to architect something that will scale and work in both
cases. I also feel adding a protocol header is not that complex for us to
adopt just the tunneling mechanism.

As Matt pointed out, defining a compressoin header does not preclude
tunneling. I still feel stongly that we should define a new compressoin
header.

--Naganand

-------------------------------------------------------------------------------

Naganand Doraswamy		(508)916-1323 (O)				
Bay Architecture Lab		(508)670-8153 (F)
Bay Networks, Inc.
3 Federal St, BL3-04
Billerica, MA 01821

Path: cronkite.cisco.com!newsgate.cisco.com
From: [email-masked] (Naganand Doraswamy)
To: [email-masked]
Newsgroups: cisco.ippcp
Subject: DOI document
Message-ID: <Pine.SUN.3.96.970630142730.2389E-100000@span>
Date: 30 Jun 97 18:30:27 GMT
Organization: Cisco Systems, San Jose, California, USA
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Lines: 25
Xref: cronkite.cisco.com cisco.ippcp:44

I have been thinking about the DOI document. The more I think about it, I
feel it is better to put it out as a separate DOI. The reason why I am
saying this is if one uses the compression protocol in the absence of
IPsec then they dont have to refer to IPsec DOI document which has lot of
fields.

All of us working on this have worked on IPssec and are comfortable with
the IPsec DOI but for someone who is not familiar with IPsec, I dont see
why they should read IPsec DOI.

The downside of this is that we will be publishing an extra one page
document, but I think it is worth it.

Comments?

--Naganand

-------------------------------------------------------------------------------

Naganand Doraswamy		(508)916-1323 (O)				
Bay Architecture Lab		(508)670-8153 (F)
Bay Networks, Inc.
3 Federal St, BL3-04
Billerica, MA 01821

Path: cronkite.cisco.com!newsgate.cisco.com
From: [email-masked] (Derrell Piper)
To: Naganand Doraswamy <[email-masked]>
Cc: [email-masked]
Newsgroups: cisco.ippcp
Subject: Re: DOI document
Message-ID: <[email-masked]>
Date: 30 Jun 97 18:37:46 GMT
References: <Pine.SUN.3.96.970630142730.2389E-100000@span>
Organization: Cisco Systems, San Jose, California, USA
Lines: 8
Xref: cronkite.cisco.com cisco.ippcp:45

Naganand,

In the absense of IPSEC, remind me what the usefulness is in negotiating
software compression using ISAKMP?  I think you should keep it simple and
use the IPSEC DOI because that's when you're likely to want to negotiate
compression.

Derrell

Path: cronkite.cisco.com!newsgate.cisco.com
From: [email-masked] (Naganand Doraswamy)
To: Derrell Piper <[email-masked]>
Cc: [email-masked]
Newsgroups: cisco.ippcp
Subject: Re: DOI document
Message-ID: <Pine.SUN.3.96.970630144436.2389G-100000@span>
Date: 30 Jun 97 18:46:32 GMT
References: <[email-masked]>
Organization: Cisco Systems, San Jose, California, USA
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Lines: 20
Xref: cronkite.cisco.com cisco.ippcp:46

Derrell,

Right now I cannot think of anything. One of the minor goal in the charter
is to make compression work in the absence of IPsec as well. In that case,
it would make sense to write a separate draft.

I am not adament of about a separate draft. However, I feel it is easier
to write have a separate draft. I am open to the what the working group
wants.

--Naganand

-------------------------------------------------------------------------------

Naganand Doraswamy		(508)916-1323 (O)				
Bay Architecture Lab		(508)670-8153 (F)
Bay Networks, Inc.
3 Federal St, BL3-04
Billerica, MA 01821

Path: cronkite.cisco.com!newsgate.cisco.com
From: [email-masked] (Derrell Piper)
To: Naganand Doraswamy <[email-masked]>
Cc: [email-masked]
Newsgroups: cisco.ippcp
Subject: Re: DOI document
Message-ID: <[email-masked]>
Date: 30 Jun 97 18:51:01 GMT
References: <Pine.SUN.3.96.970630144436.2389G-100000@span>
Organization: Cisco Systems, San Jose, California, USA
Lines: 6
Xref: cronkite.cisco.com cisco.ippcp:47

Naganand,

In the absense of IPSEC, do you think it likely that there will be a host
implementation of ISAKMP to negotiate your DOI for you?

Derrell

Path: cronkite.cisco.com!newsgate.cisco.com
From: [email-masked] (Matt Thomas)
To: Naganand Doraswamy <[email-masked]>
Cc: [email-masked]
Newsgroups: cisco.ippcp
Subject: Re: DOI document
Message-ID: <[email-masked]>
Date: 30 Jun 97 20:14:34 GMT
References: <Pine.SUN.3.96.970630142730.2389E-100000@span>
Organization: Cisco Systems, San Jose, California, USA
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Lines: 35
Xref: cronkite.cisco.com cisco.ippcp:48

At 02:30 PM 6/30/97 -0400, Naganand Doraswamy wrote:
>I have been thinking about the DOI document. The more I think about it, I
>feel it is better to put it out as a separate DOI. The reason why I am
>saying this is if one uses the compression protocol in the absence of
>IPsec then they dont have to refer to IPsec DOI document which has lot of
>fields.

It does have a lot of fields but many of them are for ISAKMP.
I am concerned about having another DOI since the ISAKMP 
implementations that I've skimmed seem to be tied to the IP DOI.
Having another DOI would be useful in break such dependencies but
that may cause deployment to pushed out or postponed forever.

>All of us working on this have worked on IPssec and are comfortable with
>the IPsec DOI but for someone who is not familiar with IPsec, I dont see
>why they should read IPsec DOI.

They need to read the IPsec DOI for ISAKMP and Oakley anyways.

>The downside of this is that we will be publishing an extra one page
>document, but I think it is worth it.

I'm hoping that within a few years that most/all IP implementations 
will incorporate IPsec and ISAKMP.  I hope IP compression can use
that code base.

I think the amount of that will need to copied from the IP DOI will
be larger that you currently think.  I'm not sure duplicating the
effort is worth it.

-- 
Matt Thomas                    Internet:   [email-masked]
Internet Locksmith             WWW URL:    <coming eventually>
AltaVista Internet Software    Disclaimer: This message reflects my own
Littleton, MA                              warped views, etc.

Path: cronkite.cisco.com!newsgate.cisco.com
From: [email-masked] (Naganand Doraswamy)
To: Matt Thomas <[email-masked]>
Cc: [email-masked]
Newsgroups: cisco.ippcp
Subject: Re: DOI document
Message-ID: <Pine.SUN.3.96.970630165957.2442F-100000@span>
Date: 30 Jun 97 21:00:42 GMT
References: <[email-masked]>
Organization: Cisco Systems, San Jose, California, USA
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Lines: 13
Xref: cronkite.cisco.com cisco.ippcp:49

OK. We will put the compression specific DOI in the IPsec DOI. If there is
strong reason to create a separate draft, we will deal with it later.

--Naganand

-------------------------------------------------------------------------------

Naganand Doraswamy		(508)916-1323 (O)				
Bay Architecture Lab		(508)670-8153 (F)
Bay Networks, Inc.
3 Federal St, BL3-04
Billerica, MA 01821

Path: cronkite.cisco.com!newsgate.cisco.com
From: [email-masked] (Bob Monsour)
To: Naganand Doraswamy <[email-masked]>
Cc: Matt Thomas <[email-masked]>, [email-masked]
Newsgroups: cisco.ippcp
Subject: Re: DOI document
Message-ID: <[email-masked]>
Date: 30 Jun 97 21:43:06 GMT
Organization: Cisco Systems, San Jose, California, USA
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Lines: 31
Xref: cronkite.cisco.com cisco.ippcp:50

I agree that negotiating using the IPSec DOI is the right thing to do.
While the wg is chartered to solve the
IP-compression-in-the-absence-of-IPSec problem, I don't think anyone really
has a feel for the interest level in this. I would expect that it is due to
the fact that PPP compression currently exists in many of those non-IPSec
environments; but I honestly don't know.

The pressing problem of interest seems to be solving the problem of
compressing prior to encrypting in IPSec. We'll learn a lot by doing that
and perhaps will gain some understanding of the need, or possible lack
thereof, for compression in the absence of IPSec

-Bob

At 05:00 PM 6/30/97 -0400, Naganand Doraswamy wrote:
>OK. We will put the compression specific DOI in the IPsec DOI. If there is
>strong reason to create a separate draft, we will deal with it later.
>
>--Naganand
>
>---------------------------------------------------------------------------
----
>
>Naganand Doraswamy		(508)916-1323 (O)				
>Bay Architecture Lab		(508)670-8153 (F)
>Bay Networks, Inc.
>3 Federal St, BL3-04
>Billerica, MA 01821
>
>
>

Path: cronkite.cisco.com!newsgate.cisco.com
Date: Mon, 30 Jun 1997 22:49:12 -0700
To: [email-masked]
From: Avram Shacham <[email-masked]>
Subject: ippcp archive is active

The ippcp mailing list archive is now active in a file named 'ippcp' on
Cisco's ftp site.

To retrieve the archive:
  FTP to ftp-eng.cisco.com
  log in as user:      ftp
            password:  your-e-mail-address
  then "cd /ippcp" and "get ippcp" to download the file.

Notes: 
* For security reasons people can not do an "ls" on the Cisco anonymous ftp
server. This fact prevents some GUI FTP clients from being useful, sorry.
* The first message in the archive is dated June 22, 1997.
    
avram