Subject: Two new issues...

From: Bob Monsour <[email-masked]>
Date: Sun, 03 Aug 1997 21:39:55 -0700

After simmering on the architecture draft that was recently submitted as
well as the two proposed protocol drafts, I have come up with the following
two architectural issues that I'd like to run by the group.

1. I understand that we can use the 'next header' field of ESP to indicate
that the "payload" is compressed and that the CPI will indicate which
compression algorithm, but...don't we also need a 'next header' field as
part of the compression header to indicate what the upper layer protocol
is? I would see this as a fixed part of the compression header and not part
of any algorithm-specific parameters. Comments?

2. While developing hardware that can (on the sender side) compress,
encrypt and authenticate a datagram in a single pass, it is also desirable
to be able to decrypt, authenticate and decompress a received datagram in a
single pass. However, to do this, it would "be nice" if you could tell,
without decrypting any part of the datagram, that it is compressed. To use
compression with IPSec, and with the path we're on now, the only piece of
data that indicates whether or not the datagram is compressed is located in
an encrypted area (the 'next header' field of an ESP payload). One approach
to solving this problem would be to use a different SPI for compressed and
uncompressed datagrams. This raises the question of the value of having a
CPI. The SPI in IPSec is used to indicate to the receiver which algorithms
to use to 'decode' a datagram, including encryption and authentication.
Since we're moving toward making compression a "peer" protocol of ESP and
AH, the choice of compression algorithm would also be an element of the SPI
algorithm set (would it not?). What specifically does the CPI buy us? In
the non-IPSec case, we can use the 'next header' field to indicate that
compression is the next layer protocol, and the compression header can have
a 'next header field' (see item #1) that indicates the 'final' ULP and any
other fields needed for compression. Am I missing something here?

Comments?

Thanks for listening.

-Bob

---

From: Roy Pereira <[email-masked]>
Date: Mon, 4 Aug 1997 14:24:00 -0400

1.  A Next header/protocol field would definately be required.  Perhaps
like AH;

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Next Header  | Payload Length  |          Reserved           | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|              Compression Parameters Index (CPI)               | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               | 
~                 Compressed Payload (variable)                 ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2. Your point about doing compression and encryption in one shot is a
good one.  

The problem with having two SPIs (one for encryption and another for
encryption/compression) is that this brings us back to having
compression as an attribute of ESP (ie. part of IPSec). 

>----------
>From: 	Bob Monsour[SMTP:[email-masked]]
>Sent: 	Monday, August 04, 1997 12:39 AM
>To: 	[email-masked]
>Subject: 	Two new issues...
>

---

From: Naganand Doraswamy <[email-masked]>
Date: Mon, 04 Aug 1997 14:29:07 -0400

>of any algorithm-specific parameters. Comments?
Yes. We do need this. We should probably make IPCOMP payload header to be 8
bytes with 4 bytes for CPI, one byte for next header, one byte for flags,
and two reserved fields.

>What specifically does the CPI buy us? In
This is a question that needs to be answered in the working group meeting.
Do all connections between two hosts use the same compression algorithm or
do we need to provide the capability so that different connections can use
differnet compression algorithms between two hosts. If it is latter then we
need CPI, if it is former then we dont.
--Naganand

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