Subject: Comments/questions on "draft-ietf-ippcp-protocol-01.txt"

From: Charles Kunzinger <[email-masked]>
Date: Mon, 10 Nov 1997 08:10:20 -0500

I like the draft in general, but offer the following comments to tighten up a
few loose ends:

1. In section 2.1, 4th paragraph, it says that "the size of a compressed
payload must be in whole octet units".  This implies that some form of padding
bits may be needed.  Since IPComp itself has no explicit fields to indicate the
presence or absence of padding, I assume that the responsibility for
identifying the presence of padding belongs to the compression transforms
themselves.  Is this a correct asumption?  If so, I would like to see a
statement to that effect included in this section.

2. In section 2.1, 5th paragraph, is worded somewhat imprecisely with respect
to "Next Header" fields.  For example, IPv6 does not even have a "Next Header"
field.  Also, Section 2.1, last paragraph, discusses details of header
modification for decompression operations.  I would rather see this section
just point the reader to Sections 3.1 and 3.2, where we can define the detailed
header modificaitons for IPv4 and IPv6, respectively.

3. In Section 2.1, it says that for IPv4, only the Upper Layer Payload is a
candidate for compression, while in IPv6 it appears that some header fields are
candidates as well.  The logic for this difference escapes me.   Would it not
be preferable to  limit compression candidacy to just the Upper Layer Protocol
in both cases, so that routers along the path can always see the  IP header
contents  "native" form for both IPv4 and IPv6?

4. Section 3.1 currently lists the modifications made by the system where the
compression takes place.  We also need to add text to describe the
modifications to be made by the system that decompresses the datagram.  Here's
some suggested text for IPv4:
   - Change "...IPv4 header fields are set:" to "...IPv4 header fields are set
before transmitting the compressed IP datagram:"
   - Add new text: "After receiving a compressed IP datagram and successfully
decompressing it, the IP header  is modified by removing the IPComp Header, and
then setting the following fields in the IP header: a) Total Length will
contain the length of the decompressed datagram, including the IP header and
the decompressed payload, b) the contents of the Next Header field in the IP
header will be replaced with the contents of the Next Header field of the
IPComp Header of the received datagram"

5. The header insertion mechanics outlined in Section 3 appear to be analogous
to those used in the IPSec protocols' "transport mode".  However, the
descriptive text in Section 1, "Introduction", indicates that IPComp can be
used both host-to-host and gateway-to-gateway.  If so, we would need to define
the mechanics for using IPComp in a "tunnel mode" in addition to its use in
"transport" mode.

6. In Section 3.3, we describe the CPI.  However, the text there is correct,
but I feel it assumes that the reader is familiar with IPSec and can make the
necessary inferences.  I would like to see more explicit text here to outline
some basic concepts, such as (in analogy with IPSec): a) both parties
participating can select a CPI value independently of each other, b) there is
no relationships between the two separately chosen CPIs, c) the compressing
system's IPComp header must use the CPI value chosen by the decompressing
system, d) the receiving system uses the pair <CPI, destination address> to
point to the correct compression algorithm characteristics, e) etc.

7. The draft on IPComp does not address any responses to common error
conditions, like receiving a datgram with a bad CPI.  I think we need to add a
section that will outline some basic error conditions and state the resulting
action on the part of the receiving system.  For example, if we were using
ISAKMP, we might want to say that if a received datgram has an invalid CPI, the
receiving system should discard the datgram and send an ISAKMP NOTIFY message
to the originator stating "INVALID-CPI" (which would be a new code point, since
only "INVALID-SPI" is not exactly correct.   In general, since SPI and CPI are
different, some work may be needed in the ISAKMP document just to bring it up
to a consistent level of terminology.

____________________________
Charles A Kunzinger ([email-masked])
TCP/IP Technology Management, JDGA/501, RTP
Phone: Tieline 8-444-4142 ,  External 1-919-254-4142
Fax: Tieline 8-444-6243,  External 1-919-254-6243
VM:  IBMUSM27(KUNZINGE)

---

From: Naganand Doraswamy <[email-masked]>
Date: Mon, 10 Nov 1997 08:56:11 -0500

Charles,

Here are my comments. Probably the authors will have more to say.

>statement to that effect included in this section.
Do we really need to worry about the bits? IP payload granularity is always
octet. As we are compressing IP payload is there any need to worry about bits?

>2.
I will defer this to the authors.

>contents  "native" form for both IPv4 and IPv6?
In case of IPv6, we want compress only those header that are end-to-end and
those that are not relevant to the routers which look at only hop-by-hop
headers. We recommend using compression mostly when ESP is turned on and in
that case the routers will not be able to parse end-to-end headers anyway.

>the mechanics for using IPComp in a "tunnel mode" in addition to its use in
I feel we can add verbiage on how to handle tunnel mode. It is implied in
the draft but is not very clear.

Points 4, 6 and 7 are good suggestions and we should incorporate them.

Cheers,
--Naganand

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

---

From: [email-masked] (Shawn Mamros)
Date: Mon, 10 Nov 1997 12:15:48 -0500

>the draft but is not very clear.

Speaking of IPsec tunnel mode: where does compression start?  Should one
leave the inner IP header uncompressed (as section 2.1 seems to at least
imply), or should/may the inner IP header be compressed as well as the
upper layer payload within?

-Shawn Mamros
E-mail to: [email-masked]

---

From: Avram Shacham <[email-masked]>
Date: Mon, 10 Nov 1997 23:23:41 +0200

Charles,

>I like the draft in general, 

Thanks.

>but offer the following comments to tighten up a few loose ends:
>

Yes. As some of (maybe most or even all) the compression algorithms are bit
oriented, and this requirement comes to make it the responsibility of the
compression algorithm to supply IPComp with a stream of bytes, similar to
the case of disk file compression.

I'll add some wording to clarify the above reasoning.

>field. 

Indeed, IPv4 uses "protocol" and IPV6 uses "Next Header". Some recent
RFCs/I-Ds used phrases such as "Next Header (protocol)", or "Next Header
(IPv6) or protocol (IPv4)".  Following these examples, I suggest to change
the wording to:

  "The original content of the Next Header (IPv6) or protocol (IPv4) field is
stored in the IPComp header."

>Also, Section 2.1, last paragraph, discusses details of header

The said paragraph is detailing the process of rebuilding of the original
datagram from the compressed payload, while Section 3 defines the actual
header structure fields and modifications. Do you suggest to add sections
3.x, defining the reconstruction of the original datagram?  Similar RFCs
(for example, rfc2003 - "IP Encapsulation within IP") contain only the
definitions of original -> encapsulated, and not encapsulated -> original.

>contents  "native" form for both IPv4 and IPv6?

Even in IPv6, only those parts of the header, that the routers on the way do
_not_ need to examine, are compressed (as defined in section 2.1 paragraph
3). This policy may reduce the packet size a bit more than the way you
suggested, with the same support for the routers on the way. 

As for IPv4, the WG in Munich requested to leave all the header (including
options) uncompressed and I think we may justify it by the way the IPv4
packet is built (header length, for example).

>IPComp Header of the received datagram"

See my comments to your 2 above. Basically, you suggest to move several
sentences from sec 2 to sec 3, but I am not sure that the result will be
more clear and readable than the original.

Any thoughts?

>the mechanics for using IPComp in a "tunnel mode" in addition to its use in

There are some historical reasons here:  My original draft (and prototype)
used IP-over-IP but the WG strongly opposed it and in IETF 39 (Munich) the
new header was formed. Maybe I changed the draft too swiftly :)

As for tunneling, nothing in this I-D is preventing the possibility of IP
encapsulation within IP (RFC 2003) _after_ apply the IP Payload Compression
protocol.

>point to the correct compression algorithm characteristics, e) etc.

Your assumptions of IPSec familiarity are correct :)

The co-authors felt that the current definitions are sufficient. How
strongly do you feel that the above requested details are a MUST add?

>to a consistent level of terminology.

The text in section 2.1 "If the decompression process is successfully
completed..." implies that erroneous packets are silently dropped. I agree
that explicit text will be helpful.  

However, I am reluctant to offer any modification to ISAKMP documents and I
guess the IPSec WG will not be too enthusiastic to see such change these
days. In Munich, an offer was made that a CPI failure should cause the
receiver to send an ICMP error message. 

Regards,
avram

---

From: Roy Pereira <[email-masked]>
Date: Mon, 10 Nov 1997 16:35:02 -0500

If we make the assumption that we perform tunneling during ESP or AH,
and since we must perform compression before security, then we wouldn't
compress the inner IP header.  But if implementation wish to perform
tunneling before compression and thus compress the inner IP header, it
should be fine to this proposal.

---

From: Roy Pereira <[email-masked]>
Date: Mon, 10 Nov 1997 16:39:03 -0500

> statement to that effect included in this section.

I believe that this is 'fluff'.  I think we can assume that we only work
with single octet units and not with bits.  I think having this wordage
in the document just confuses the reader as can be seen in the above
question.  

> contents  "native" form for both IPv4 and IPv6?

As far as I'm concerned any protocol after the IP header is a candidate
for compression.  When we are tunneling,  the inner IP header might also
be a candidate for compression.

I think sone of the suggestions are quite good and should be
incorporated.

---

From: Avram Shacham <[email-masked]>
Date: Tue, 11 Nov 1997 07:22:07 +0200

>should be fine to this proposal.

Roy's approach is another practical way to create tunneling without
duplicating this mechanism in IPComp. In general, the approach of the draft
is to use tools which can be found in other existing protocols.

avram

---

From: Naganand Doraswamy <[email-masked]>
Date: Tue, 11 Nov 1997 09:18:56 -0500

Would it make sense for us to say that when used in conjunctino with ESP,
compression should be performed just before encyrption the packet? That
way, if IPSec is used in tunnel mode, then we will encrypt the inner header
also. It makes more sense in IPv6 where there could be a few optional headers.
--Naganand

---

From: Roy Pereira <[email-masked]>
Date: Tue, 11 Nov 1997 10:39:47 -0500

Yes.

If both IPSec (ESP/AH) and IPComp are being used, then some optimization
would be helpful.

---

From: Avram Shacham <[email-masked]>
Date: Tue, 11 Nov 1997 21:36:59 +0200

>also. It makes more sense in IPv6 where there could be a few optional headers.

Your suggestion is to add "just before" to the current definition of the
draft seems too restrictive. Why prevent any future process post-compression
and pre-encryption?  And, what is the difference to ESP-tunneling if IPComp
is done not "just before" ESP?

avram

---

From: Avram Shacham <[email-masked]>
Date: Tue, 11 Nov 1997 21:37:15 +0200

At 10:39 AM 11/11/97 -0500, Roy Pereira wrote:
<snip>
>If both IPSec (ESP/AH) and IPComp are being used, then some optimization

For example?