Subject: changes in draft-ietf-ippcp-lzs-03.txt

From: Robert Friend <[email-masked]>
Date: Fri, 6 Feb 1998 11:33:53 -0800

Hi,

I made the following changes to the draft-ietf-ippcp-lzs-02.txt based on
inputs from the Washington DC meeting.  The draft-ietf-ippcp-lzs-03.txt
is in the process of being posted.  It is attached for comment.

1) Added Section 4 which suggests that ISAKMP MAY be used for key
management.

2) Added section 4.1, which specifies the transform ID of 0x03.

3) Added section 4.2, which specifies no other parameters needed for the
SA.

4) Added section 4.3, which specifies that manual configuration uses
0x03.

5) Added section 4.4, which specifies the minimum packet size for LZS
IPPCP compression.

6) Added section 4.5, which specifies that there is no compressibility
test for LZS IPPCP compression.

Comments are welcome.

Regards,
_____________________________________________________________

Robert C. Friend              Hi/fn
Applications Engineering      5973 Avenida Encinas, Suite 110
voice: (760) 827-4542         Carlsbad, CA 92008
FAX:   (760) 827-4577         email: [email-masked]

---

From: Avram Shacham <[email-masked]>
Date: Fri, 20 Feb 1998 18:47:45 -0800

At 05:59 PM 2/20/98 -0800, Robert Friend wrote:
>As requested, I made some changes to draft-ietf-ippcp-lzs-03.txt.
>Attached is draft-ietf-ippcp-lzs-04.txt which reflects these changes.
>This draft has been submitted to IESG.
>
>Changes:
<snip
>4) Replaced section 5 with Deflate version of Security Considerations.

5. Security Considerations

   This document does not add any further security considerations that
   [IPCOMP] and [Deutsch96] have already declared.
            ^^^^^^^^^^^^^^^

?

---

From: Avram Shacham <[email-masked]>
Date: Wed, 18 Feb 1998 14:43:42 -0800

Robert,

As an implementor of LZS in IPComp, I can easily state that the document
provides all the information required to incorporate LZS in the context of
IPComp.

The main suggestion that I would like to re-raise: Could you minimize the
duplications from the IP Payload Compression Protocol document?  The
benefits of such separation are obvious. I pointed to few examples in the text.

Also, see some editorial comments attached.

Regards,
avram

>                    IP Payload Compression Using LZS
>                      <draft-ietf-ippcp-lzs-03.txt>

<snip>

>2.2 Anti-expansion of Payload Data

<snip>

>   If the size of a compressed IP datagram, including the Next Header,
>   Flags, and CPI fields, is not smaller than the size of the original
>   IP datagram, the IP datagram MUST be sent in the original non-
>   compressed form, as described in [IPCOMP].

Duplication...

>2.3 Format of Compressed Datagram Payload

<snip>

>    0                   1                   2                   3
>    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  |     Flags     | Compression Parameter Index   |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Duplication...

<snip>

>4.1 ISAKMP Transform ID
>   The LZS Transform ID as 0x03, as specified in The Internet IP
>   Security Domain of Interpretation [SECDOI].  This value is used to
>   negotiate the LZS compression algorithm under the ISAKMP protocol.

The [IPDOI] defines:  

      Trabsform ID     Value
      ------------     -----

      IPCOMP_LZS       3

Could you reference the Transform ID name, in order to avoid a possible
confusion if and when the value changes?

<snip>

>4.3 Manual configuration
>   The CPI value 0x03 is used for a manually configured IPComp
>   Security Associations.
    ^^^^^^^^  
    Compression ?

Also, see comment to 4.1.

<snip>

>   IP payload compression potentially reduces the security of the
>   Internet, similar to the effects of IP encapsulation [RFC-2003].  For
>   example, IPComp makes it difficult for border routers to filter
>   datagrams based on header fields.  In particular, the original value
>   of the Protocol field in the IP header is not located in its normal
>   positions within the datagram, and any transport-layer header fields
>   within the datagram, such as port numbers, are neither located in
>   their normal positions within the datagram nor presented in their
>   original values after compression.  A filtering border router can
>   filter the datagram only if it shares the IPComp Association used for
>   the compression.  To allow this sort of compression in environments in
>   which all packets need to be filtered (or at least accounted for), a
>   mechanism must be in place for the receiving node to securely
>   communicate the IPComp Association to the border router.  This might,
>   more rarely, also apply to the IPComp Association used for outgoing
>   datagrams.
>
>   When IPComp is used in the context of IPSec, it is not believed to
>   have an effect on the underlying security functionality provide by
>   the IPSec protocol; i.e., the use of compression is not known to
>   degrade or alter the nature of the underlying security architecture
>   or the encryption technologies used to implement it.

Is this not-updated duplication really needed?  I recommend following Roy's

>   [IPCOMP] and [Deutsch96] have already declared.

=== end of comments ===

---

From: Robert Friend <[email-masked]>
Date: Fri, 20 Feb 1998 17:59:07 -0800

Changes:
1) Removed Section 2.2, as it was deemed redundant with the protocol
draft.
2) Removed Section 2.3, as it was deemed redundant with the protocol
draft.
3) Refered to the literal instead of the value for the Transform ID.
4) Replaced section 5 with Deflate version of Security Considerations.

Regards,

Robert C. Friend              Hi/fn