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

Proposed changes to ESP (andf a little AH too)



Folks,

	In working on revisions to the AH and ESP specs, we've noticed that
there is an opportunity to make a change to the ESP format and processing
that would simplify implementations, introduce greater consistency between
AH and ESP, and offer greater protection against denial of servioce
attacks.  However, in setting out to revise the ESP spec, the intent was
NOT to make any changes to the format (for backward compatability) and
hence I am somewhat reluctant to prose such changes at this point in time.
Nonetheless, I ask the WG to consider these  proposed changes relative to
the benefits noted above, and balance them against the cost to implementors.

	ESP transforms that include an anti-replay counter place this
counter at the begining of the encrypted portion of the ESP payload.  This
motivates negotiating a random starting value for the counter (to minimize
known plaintext attacks) and it creates the requirement for the AR window
mechanism to deal with modular arithmetic, since the counter may wrap
around the 32 bit space legitimately.  Note that for AH, recent I-Ds defin
ethe counter value to begin at 1, which makes life much easier.  I propose
to move the counter value out of the encrypted portion of the payload (it
would appear immediately after the SPI), and to define it to begin at 1.
This would simplify counter and counter window management and make it
uniform with AH in this regard.  It also allows for very fast rejection of
replays by a receiver.  After matching an inbound packet to an SA (using
the SPI) the counter value can be checked, prior to any crypto processing.

	Moving the counter to this location causes the IV (if present) to
appear immediately before the encrypted portion of the payload, and to be
aligned on an 8-byte boundary.  This offers potential (though probably
minor) performance improvements for receivers, since crypto that uses
explicit IVs tend to view it as an immdeiate prefix for the ciphertext.

	Now for a bigger change!  I suggest that we reverse the order of
encryption and authentication processing, when both are employed.  Now,
authentication processing occurs first, then encryption.  This means that a
receiver must decrypt then autehnticate.  While most systems I have seen in
the past have adopted this strategy, we are now more concerned with denial
of service attacks.  A likely common use of ESP is to create VPNs thorugh
IPSEC implementations in security gateways.  If we reverse the order of
processing, then a secruity gateway can validate the integrity and
authenticity of a packet befor edecrypting it, thus rejecting bogus packets
faster (about twice as fast, in many instances), than if we had to decrypt
then authenticate.  Combined with the psoposed positional change for the
counter (suggested above), we now have an ability to reject duplicate or
spurious packets very quickly, providing better defense against DoS attacks.

	One final note re ESP formats and processing:  I-Ds discussing
anti-replay require support of a window size of 1, which implies strict
sequencing of packets.  I'd like to remove this requirement.  In fact, I'd
like to suggest that supporting a window size of 1 is inappropriate.  The
IP layer does NOT guarantee ordered delivery and by imposing strict
sequencing via IPSEC we are violating a fundamental characteristic of the
IP layer.  Note that such sequencing could have adverse affects on TCP
connections (ofrcing unnecessary retransmission), merely because of packets
arrived at a security gateway out of order, due to no malicious actions.
The motivation for the counter and window mechanaims was to protect against
replays, not to enforce strict sequencing at the IP layer.

	Please respond to these proposed changes.   We're submitting
revised versions of AH and ESP, designed to reduce the proliferation of
distinct transform documents, to meet the 3/36 cutoff.  We'll put the
changes I noted above in these I-Ds, but if the WG does not endorse some or
all of these changes, we will quickly revise the documents and re-issue
them.  Presentations on these changes, and on other issues that we've
encountered in the course of revising the architecture document, will be
made in Memphis.  I also will be sending out a message on the architecture
issues next week, providing fodder for discussion prior to Memphis.  The
revised architecture I-D will not be ready for Memphis, because of the many
issues that we want to get Wg feedback on, and because we are re-writing
the document from scratch to better articulate these and other issues.

Thanks in advance for your carefuyl reading and feedback,

Steve




Follow-Ups: