[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: TO COMPRESS OR NOT TO CMPRS (please reply)
Bob,
I'm in favor of including a compression option in ESP. As I
mentioned at the last IPSEC WG meeting, I think this will be especially
helpful for folks using dialup or low-speed wireless links. While I agree
that this could be viewed as a separate protocol layer, and might be
beneficial in non-ESP contexts, I worry that if we wait for form a new WG
for this, debate the right protocol layer for providing this service, etc.,
that it will be a long time before we have the feature and ESP users in the
contexts noted above will suffer during that time. So, I vote (oops, I
just used a four letter word in the IETF context; I meat to say "I cast my
straw ballot for") the inclusion of a compression option in ESP.
As for your second question, I also favor stealing a bit out of the
padding field for this purpose. As I recall, the motivation here is to
negotiate the use of compression, and the specific algorithm, on a per SA
basis. So the per-packet bit is needed to allow some packets to not be
compressed, e.g., because the packets were sufficiently small that
compression would not be attractive. If we add a byte for this bit of
info, we will further complicate the alignment issues that are currenty
consuming a lot of WG bandwidth. Since I don't think highly of using
padding for trafiic flow confidentiality purposes, I'm in favor of donating
the high order bit of the padding field to this compression indication
purpose.
Steve
References: