[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: the COMPRESSION discussion

Ran,

	I think that we can make provision for compression in ESP, while
deferring some of the issues you raised.  For example, we already allow the
definition of additional encryption and authentication algorithms, in
addition to having define defaults that must be implemented.  For
compression, we could hold off on defining a MUST implement default, and
thus rely on specific choices that are defined later.  I admit that this is
not the preferred approach, and it certainly does not promote
interoperability as well as the tack we have taken with encryption and
authentication algorithms so far, but it is a start.

	We have debated the question of at what processing layer to
implement compression and there is agreement that one cabn do it at various
layers, with differing benefits.  But, the issue for us is not that more
general one, but rather do we wish to provide for optional compression in
the context of ESP.  I agree with Bob and others that the responses on the
list suggest that there is asubstantial support for this as an optional
feature, to be negotiated on a per-SA basis.

	Support for arbitrary algorithms is a good goal, but operating in
the IP layer, we have to limit ourselves to algorithms that do not rely on
ordered delivery.  I think that we understand the limitations on the
methods that will work in our context, and those become constraints on
applicable algorithms.  It does not seem appropriate to require than any
compression algortihm be a candiadte for IPSEC ESP use.  Only ones that are
fairly stateless should be candidates, given the out-of-order arrival and
packet loss that are characteristics of IP layer traffic.

	I agree with most of your proposed process for dealing with this
issue, and hope that we will receive submissions on specific, detailed
proposals.  However, I also believe that Bob has provided the necessary
details that are sufficient for mods to the ESP spec, to accommodate a
range of compression options and that we can add this to a later version of
the ESP I-D with little or no effort.  I do not agree with the suggestion
to explore whether this is a generic IP layer issue vs. just an ESP issue.
If we really want to make progerss on this, and meet the well-articulated
needs of folks like Bob Moskowitz, I think we must plan on putting
compression into IPSEC, since it is the use of ESP that especially
motivates the need for compression as a compensating factor.

	So, I'd like to see us proceed as follows to add compression to our
specs, if the WG agrees:
	- have the architecture document describe the optional use of
compression within ESP, to be negotiated on a per-SA basis
	- define in the relevant ISAKMP documents how to negotiate compression
	- set aside the high order bit from the ESP padding field to
indicate if compression has been applied to an individual packet
	- define in ESP the scope of compression and any alignment
considerations applicable to the use of compression
	- define compression algorithms for ESP use in separate base
documents, which can have backpointers to the architecture, ESP, and ISAKMP
docs

Steve
Follow-Ups: References: