[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Increased sequence number in ESP/AH
Derrell,
>Steve,
>
>Is there a summary of your presentation you could post for those of
>us who were unable to attend the last meeting?
I've attached the PPT slides to this message.
>A couple of comments on replay and clustering.
>
>I don't have any problem with 64-bit replay sequence numbers. The
>math is lost in the noise and the additional sequence space will be
>needed very soon now.
>
>Regarding clustered IPSec SA's, I like Bill's proposal, though I
>tend to want to try to solve the problem with a single SA (pair).
>However, something like a simple negotiated replay window set is
>also problematic when you allow your clusters to dynamically resize
>(as we do). You'd have to provide a mechanism to negotiate a new
>replay window when you added another node not present during the
>initial negotation. The beauty of Bill's proposal is that this is
>just another Quick Mode. However, this will cost us O(n) in IPSec
>SA memory usage, where 'n' is the size of a cluster, given our
>failover guarantees. We currently achieve our 250ms failover in
>O(1) IPSec SA memory usage. This isn't very appealing to us when
>you consider that we support 20K+ tunnels in our high end systems.
>On the third hand (:-), it's just memory.
>
>How about this:
>
> 1) add a replay 'flow id' to the ESP header or trailer and
>include it in the integrity check
> 2) require the receiver to support multiple replay windows,
>per SA, indexed by flow id
> 3) require that the flow id be unique for the lifetime of the
>SA and forbid reuse of flow id's
> 4) require the receiver to switch to a new replay window upon
>receipt of an unknown flow id
Well, I hate to add new fields to the packet format, but we may have
to do that at some point. However, the approach you propose here has
the advantage of being dynamic with less overhead (no QM exchange),
by allowing creation of new flows without creating new SAs. The flow
IDs separate out the sequence number spaces, each on a separate
crypto processor, right? So, the sequence numbers will be sequential
per flow, but packets for the same SPD-defined flow may be
distributed over various SA flows, to support parallelism.
>This allows the sender to start transmiting on a new replay window
>following load-balancing, failover,
>or a cluster resizing/remastering. With sufficient restrictions,
>there's no effective security risk.
I think one could make this adequately secure, as you suggest.
>I do think this is an important problem to solve. Despite the
>advances in COTS hardware acceleration, the only way we're going to
>deal with increased pipe sizes in the near future is through
>parallelism/clustering.
I'm not so sure about that assertion, but I guess it depends on your
definition of "near future." As someone else noted, if one assigns
sequence numbers to (pseudo) ESP headers prior to forwarding the
packet to a crypto module, then the transmitter can use multiple
modules w/o encountering this problem. At the receiver the same is
true, in reverse, i.e., checking the sequence number outside the
module avoids the problem. Now, if we move to a counter mode that
relies on the sequence number for per-packet variability, I would
begin to worry about this approach, because of the security
implications of duplicate sequence numbers. However, for CBC mode,
this is not an issue. True, the security boundary is extended beyond
the chip re anti-replay, but if other aspects of IPsec are off chip,
e.g., SPD lookup and mapping, then the relative security concerns
seem small in comparison.
Very fast individual chips are being developed or are available now.
they seem to be pretty good relative to individual subscriber access
speeds. I presume the problem you're trying to address here arises
in POP (vs. CPE) IPsec implementations. There one has more motivation
to use multiple chips and to share them among various subscriber
flows, hence the desire for maximum, efficient utilization of the
hardware.
Steve
IPsec_WG_12=00.ppt
References: