Subject: Re: Last Call: IP Payload Compression ...

From: Bob Monsour <[email-masked]>
Date: Mon, 02 Feb 1998 22:57:16 -0800

Bill,

If you have objections or recommendations regarding the IP Payload
Compression working group activities or the draft, I'd suggest copying them
to the wg list. If you've made informal recommendations, it's likely to be
news to those working on the drafts.

At 08:00 PM 2/2/98 GMT, William Allen Simpson wrote:
>While I'm thinking about it (with regard to IP compression techniques),
>I'd like to make a more formal objection to the IP Payload Compression.
>The Last Call expired Jan 20, but the new draft (-05) went the exact
>opposite of my informal recommendations.
>
>This is a not unreasonable proposal.  The main problem is that the
>authors are coming from the IPSec arena, and thus concieved this as
>an extension to IPSec, rather than taking a more general approach,
>and incorporating both Header and Data compression.

The wg was formed to solve the payload compression problem, not the header
compression problem. As the IESG is attempting to set up working groups to
solve specific problems and this was the scope agreed to with the area
directors involved. See the charter excerpt below.

>This draft suffers the same myopia that afflicts the Header Compression
>with IPv6.  The authors come from a particular background, and have not
>envisioned a more general solution.
>
>But the worst problem, in my view, is that the draft does not stand on
>its own.  It is dependent on ISAKMP, used by some in the IPSec WG.

As stated in the charter for the wg:

The immediate problem the Working Group will address is the development
of a payload compression protocol for use in conjunction with IPSec.
The working group will develop its specifications to support both IPv4
and IPv6. Although the primary motivation for this WG is the need to
compress packets when IPSec is used, the WG will develop an
architecture that does not preclude its use with other potential
protocols or the absence of IPSec.

The working group will identify and document the mechanisms that allow
two communicating parties to negotiate the use of compression as well
as the compression format to be employed. The Working Group will
consider defining extensions to ISAKMP to support the negotiation of
compression parameters. Use of ISAKMP as the immediate effort shall not
preclude compression in the absence of IPsec.  Alternate negotiation
mechanisms (or even static negotiation), if appropriate, shall be
identified and extended as needed to accommodate the use of payload
compression functionality. Since compression will be negotiated,
existing implementations of IP will interoperate with implementations
that support compression.
[end charter excerpt]

>In this recent draft, the compression numbers have been removed to the
>ISAKMP DOI.  Instead, those numbers should remain in this document, and
>the ISAKMP DOI should refer to this document.  All references to ISAKMP
>should be removed!
>
>That change would allow this document to be referenced by other WG
>efforts, including L2TP, MobileIP, and TLS.

Why would TLS need to reference the IP payload specifications when TLS
already includes the capability to negotiate and deploy compression (even
though no algorithms have been defined for its use)? I would expect that in
the absence of IPSec, L2TP and MobileIP would make use of PPP compression.
If IPSec is present to protect those connections, then it would make sense
to use IPPCP.

>As in the Header Compression draft, terminology and typography could be
>cleaned up considerably.  In addition, these folks could learn a bit
>about grammar from the non-native English speakers that wrote the Header
>Compression draft.  (heavy sigh)
>
>[email-masked]
>    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32
>
>
>

----------------------------------------------------------------
Bob Monsour                                Hi/fn Inc.
[email-masked]                          2105 Hamilton Avenue
408-558-8065                               Suite 230
408-558-8074 fax                           San Jose, CA  95125
----------------------------------------------------------------

---

From: Naganand Doraswamy <[email-masked]>
Date: Tue, 03 Feb 1998 09:36:25 -0500

One of the goals of the working group was to define a compression protocol
that works with or without ISAKMP. We thougth it should be generic enough
to work with any key mgmt. protocol. However, it was decided to use ISAKMP
as it is an Internet Standard Key Mgmt. Protocol. In the absence of ISAKMP,
one can use their own key mgmt. protocol to negotiate keys. As we all know,
all we need to is SPI and how the SPI is negotiated is upto the
implementations.

The DOI is key mgmt. protocol specific. We had a discussion on where to put
the DOI values- the architecture draft or the DOI document and there was a
consensus that it should be defined in the DOI draft.
--Naganand

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

---

From: Avram Shacham <[email-masked]>
Date: Tue, 03 Feb 1998 15:05:39 -0800

William Allen Simpson,

Bob Monsour, Bernard Aboba, and Naganand Doraswamy already answered most of
the technical issues that you raised in your message, which Bob was kind
enough to post to the IPPCP mailing-list.  I'll add some facts and my
comments on your history perspective and style.

First, let me put some facts forward:

1. You are a member of the IPPCP mailing-list.
2. You _never_ posted a comment to the list, as grep-ing the 777KB archive
shows.
3. The archive also shows that you were explicitly CC-ed to two messages,
both dealing with the DOI aspects of IPComp and both dated 6-97. I'll
forward these messages to you if you have any problem scanning the IPPCP
archive.
4.  A reference to the DOI draft was present in all versions of my draft,
starting with version 00, posted 7-97, and continuing through the latest
version, version 05.
5.  The wg last-call for the protocol was issued and passed 11-97.  The IESG
last-call passed 1-19-98.

And with these facts cleared, let's refer to the specifics of some of your
issues:

>>The Last Call expired Jan 20, but the new draft (-05) 

Version 05 of the draft incorporated the recommendations of the IANA for
wording the reference to DOI, as conveyed to the AD during the IESG
last-call. Run any diff utility between version 04 and 05 to see the exact
changes.  You may also read the details of the changes, as included in my
note to the mailing-list.

>>went the exact opposite of my informal recommendations.

What are those "informal recommendations" of yours?  To what forum did you
post your comments?

>>authors are coming from the IPSec arena, and thus concieved this as
                                                    ^^^^^^^^^  conceived (?)
>>and incorporating both Header and Data compression.

(a) The wg explicitly detached its work and drafts from IPSec. Had you
attended the Munich meeting, you could have heard this fact yourself.
(b) And, as the editor of the IPComp draft, I am far from being involved
with IPSec. True, sometimes I read the exchanges on the IPSec list,
including those in which you are involved.  No doubt that your style is
consistent cross mailing-lists.
(c) The wg _decided_ not to compress the IP header. This increased the
overall compression performance.

>>its own.  It is dependent on ISAKMP, used by some in the IPSec WG.

The draft specifies three (3) mechanisms of negotiations. ISAKMP is one of
those options.  Please read section 4 of the document.

>>the ISAKMP DOI should refer to this document.  

The compression numbers were never included in the IPComp document. All
post-Munich versions referred to the DOI draft.

>>All references to ISAKMP should be removed!

And your reasons are?

>>efforts, including L2TP, MobileIP, and TLS.

Why should L3 compression be referred to by other-layer protocols?

>>Compression draft.

I duly note that you made this comment without referring to a single
instance in the document where "terminology," "typography", or "grammar" is
lacking.  If you wish to present compositional inadequacies in the draft,
you are welcome to do so, so long as you cite concrete examples.  Doubtless
one or two such mistakes slipped through the rigorous proof-reading process;
you are welcome to bring your presumably illustrious knowledge of English to
bear on these unfortunate errors.

>>  (heavy sigh)

Heavy sigh indeed.

avram

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 3 Feb 1998 22:03:48 -0800

Bob Monsour wrote:

> I would expect that in

Most PPP compression methods are stateful, while IPPCP is stateless. This
means that IPPCP is more robust against packet loss for media (like the
Internet) where ordering is not guaranteed, and substantial packet loss can
occur. As a result, L2TP and MobileIP *should* use IPPCP, instead of PPP
compression. It makes sense for the draft to encourage this.