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

Re: Proposed changes to ESP (andf a little AH too)

> 	In working on revisions to the AH and ESP specs, we've noticed that

Ummm, I've a quick question.  Who are, "we"?  I thought you (singular) were
rewhacking these drafts.  Are there others we (the good folks in IPsec-land)
do not currently know?

> 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.

Good points on the cleanup, the backward compatibility, and the implication
that there is a tradeoff between the two.

> Nonetheless, I ask the WG to consider these proposed changes relative to
> the benefits noted above, and balance them against the cost to
> implementors.

My first and foremost concern is that we don't hold up this IPsec
specification train any longer.  We need to stop the target from moving as
much as it is.  Some of us have enough implementation headaches w/o changing
specs.

After that urgent concern, the question becomes:

	Is improvement <foo> worth the time <t> and pain <p> that it'll take
	to implement said improvement?

	Is:		<foo>   >>    <t> X <p>

It seems we have quite a few working systems already.  So while time might be
relatively small, pain might be high because things might be deployed
already.

Enough philosophy, I got shredded for that once already.  ;)

<SNIP!>
> 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.

It _seems_ very rational.  How much replay-enabled code do we have out there?
I personally haven't approached replay protection yet, and this seems easy
enough to build.  OTOH, I can't speak for my fellow implementors.  Also,
consider this potential attack when taking your "It also allows for very fast
rejection..." sentence into account:

	I'm receiving ESP packets.  I get packets #1, #2, and #3 from the
	actual source.  Now assume active attacker Mallory injects an ESP
	packet with #4 into the flow.  My "quick reject" algorithm accepts
	Mallory's #4, while rejecting the geniune #4 that arrives while I'm
	attempting to decrypt Mallory's #4.  (Remember folks, some of us
	live in a multi-threaded, multi-processing world.)

Granted, this is a denial-of-service attack, and as your paper with Voidoc
(sp.?) points out, you can't shut down all denial-of-service attacks.  My
question is, does this attack exist with the previous method of implementing
replay counters?

<SNIP!>
> 	Now for a bigger change!  I suggest that we reverse the order of
> encryption and authentication processing, when both are employed.  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.

Ahhhhh, so _THAT's_ how you solve my problem mentioned above.  My "quick
reject" algorithm doesn't reject until auth passes/fails.

Let me reiterate that this seems rational, and that as a fresh-from-scratch
implementor I can build this.  Let me also reiterate that there is running
code out there now (I'd like to know how widely deployed, actually.  It could
be useful data.), and it may be not operationally painless.

> 	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.
<SNIP!>

At the risk of sounding like a parrot, it's a nice idea, but will it break
anyone's back too much?  In this case, however, it really seems like it's not
difficult to achieve.  Replay window size is negotiated in Key mgmt., so you
can just have key mgmt. reject such window replay window sizes.

<SNIP!>
> We're submitting revised versions of AH and ESP, designed to reduce
> the proliferation of distinct transform documents, to meet the 3/36 cutoff.

That's 3/26, and while it may reduce the number of transform documents, will
it reduce the number of transforms?

> 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.

Again, the issue of transforms vs. algorithm vectors is foremost in my head.
I've envisioned an IPsec module (AH or ESP) doing as much common work as
possible and only farming out the algorithm-specific stuff.  With
"transforms" it's not clear to me that you can farm out as little.  Hard to
say, and I do live in a different kernel-internals world than other
implementors.

I'd like resolution on that issue.  Is my unit of difference a transform, or
(algorithm + option) combinations?

> Thanks in advance for your carefuyl reading and feedback,

Hope this helps!

--
Daniel L. McDonald  -  Solaris Internet Engineering  ||  MY OPINIONS ARE NOT
Mail: danmcd@eng.sun.com, danmcd@kebe.com <*>        ||  NOT NECESSARILY SUN'S!
Phone: (415) 786-6815            |"rising falling at force ten
WWW: http://www.kebe.com/~danmcd | we twist the world and ride the wind" - Rush
Follow-Ups: References: