Subject: [IPsec] RFC-4303 - Does ESN really worth/help to reduce/avoid replayed packets?

From: Ashok Kumar <[email-masked]>
Date: Mon, 15 Dec 2014 12:28:14 +0530

Hi All,

As per my understanding, the anti-replay feature in IPsec helps to save CPU
cycles
in the IPsec gateway (or host) by discarding the replayed packets so that
costly
operation like MAC calculation and decryption can be avoided for such
packets.
Is my understanding right?

>From "A2.3. Pseudo-Code Example" in RFC-4303, looks like any packet which
are older than the anti-replay window start, would skip the anti-replay
check
and MAC check will be done. Though MAC check would fail (because Seqh
would be incorrect), MAC calculation would still happens. It is most likely
to
happen for almost all replayed packets in a high throughput tunnel. Isn't
it?

Without ESN support, we will discard all packets whose sequence number
is less than the anti-replay window base. So the problem which I see is,
only with ESN support. Please correct me if I am missing something.

Regards,
Ashok Kumar

PS: The " Pseudo-Code Example" from the RFC-4303:

   The following pseudo-code illustrates the above algorithms for anti-
   replay and integrity checks.  The values for `Seql', `Tl', `Th' and
   `W' are 32-bit unsigned integers.  Arithmetic is mod 2^32.

        If (Tl >= W - 1)                            Case A

==> This is most likely case. The else case will hit only when

    the anti-replay window span across two 32-bit sequence number spaces.

            If (Seql >= Tl - W + 1)

==> This will hit only if the packet sequence number is *not* below

    anti-replay window start. For replayed packet in a high throughput tunnel,

    it is less likely to hit.

                Seqh = Th
                If (Seql <= Tl)
                    If (pass replay check)
                        If (pass integrity check)
                            Set bit corresponding to Seql
                            Pass the packet on
                        Else reject packet
                    Else reject packet
                Else
                    If (pass integrity check)
                        Tl = Seql (shift bits)
                        Set bit corresponding to Seql
                        Pass the packet on
                    Else reject packet
            Else

==> This case would most likely will hit for replayed packets

    in a high throughput tunnel (or replayed packets with little delay).

                Seqh = Th + 1
                If (pass integrity check)
                    Tl = Seql (shift bits)
                    Th = Th + 1
                    Set bit corresponding to Seql
                    Pass the packet on
                Else reject packet
        Else                                    Case B
            If (Seql >= Tl - W + 1)
                Seqh = Th - 1
                If (pass replay check)
                    If (pass integrity check)
                        Set the bit corresponding to Seql
                        Pass packet on
                    Else reject packet
                Else reject packet
            Else
                Seqh = Th
                If (Seql <= Tl)
                    If (pass replay check)
                        If (pass integrity check)
                            Set the bit corresponding to Seql
                            Pass packet on
                        Else reject packet
                    Else reject packet                Else

                    If (pass integrity check)
                        Tl = Seql (shift bits)
                        Set the bit corresponding to Seql
                        Pass packet on
                    Else reject packet

---

From: <[email-masked]>
Date: Mon, 15 Dec 2014 16:30:05 +0000

> On Dec 15, 2014, at 1:58 AM, Ashok Kumar <[email-masked]> wrote:
> 
> Hi All,
> 
> As per my understanding, the anti-replay feature in IPsec helps to save CPU cycles
> in the IPsec gateway (or host) by discarding the replayed packets so that costly
> operation like MAC calculation and decryption can be avoided for such packets.

No.  The anti-replay feature prevents replay attacks.  The purpose is to avoid delivering duplicate packets to the end system, where (depending on the protocol) they might cause applications to malfunction.  The benefit you describe (to the IPSec gateway) is insignificant.

	paul

---

From: Michael Richardson <[email-masked]>
Date: Mon, 15 Dec 2014 13:01:58 -0500

<[email-masked]> wrote:
    >> Hi All,
    >> 
    >> As per my understanding, the anti-replay feature in IPsec helps to
    >> save CPU cycles in the IPsec gateway (or host) by discarding the
    >> replayed packets so that costly operation like MAC calculation and
    >> decryption can be avoided for such packets.  Is my understanding
    >> right?

    > No.  The anti-replay feature prevents replay attacks.  The purpose is
    > to avoid delivering duplicate packets to the end system, where
    > (depending on the protocol) they might cause applications to
    > malfunction.  The benefit you describe (to the IPSec gateway) is
    > insignificant.

Paul: what you said is correct about the reply feature.

But what Ashok observed about the implementation recommendation is also correct.

The anti-replay *WINDOW* (a bit map of a particular size) in on the receive
allows the receiver to receive packets out of order, but puts a lower limit
on replay values that will be accepted.  Once the window is closed, the
gateway can discard packets without performing a MAC calculation.
The affect on the IPsec gateway is not insignificant if the IPsec gateway
can not perform MAC operations at wire speeds.  For much of the life of the
IPsec specification, software implementations of IPsec have been slower than
line card speeds.  It has only been in the past 7 to 9 years that this is
frequently not been the case; and it is still the case for most home
gateways, for instance.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Stephen Kent <[email-masked]>
Date: Tue, 16 Dec 2014 08:16:46 -0500

Ashok,
> save CPU cycles
only partially. The main reason for this is to protect an app from receiving
replayed traffic that it might not otherwise detect and reject. Not an 
issue for
TCP, but a possible issue for UDP-based apps.
> are older than the anti-replay window start, would skip the 
> anti-replay check
> would be incorrect), MAC calculation would still happens. It is most 
> likely to
> happen for almost all replayed packets in a high throughput tunnel. 
> Isn't it?
That's not the intent. The intent is to immediately drop any packet for 
which
the sequence number is older than the AR window, thus avoiding crypto 
operations
that are not necessary.
> only with ESN support. Please correct me if I am missing something.
See comments above.

Steve

---

From: Ashok Kumar <[email-masked]>
Date: Tue, 16 Dec 2014 22:15:26 +0530

Hi Paul,

I agree that it helps to avoid delivering duplicate packets to the end
system.
But I am not convinced about the following statement.

> The purpose is to avoid delivering duplicate packets to the end system,
where (depending
> on the protocol) they might cause applications to malfunction.

The IPsec is transparent to end system. So IIUC, end-to-end
system/application
shouldn't assume that it will never receive duplicate packets. So
regardless of
whether IPsec is used/deployed or not, it is end system/application
responsibility
to handle any duplicate packets. Isn't it?

Thanks,
Ashok Kumar

On Mon, Dec 15, 2014 at 10:00 PM, <[email-masked]> wrote:
> No.  The anti-replay feature prevents replay attacks.  The purpose is to
> avoid delivering duplicate packets to the end system, where (depending on
> the protocol) they might cause applications to malfunction.  The benefit
> you describe (to the IPSec gateway) is insignificant.
>
>         paul
>
>

---

From: <[email-masked]>
Date: Tue, 16 Dec 2014 17:01:48 +0000

> On Dec 16, 2014, at 11:45 AM, Ashok Kumar <[email-masked]> wrote:
> 
> Hi Paul,
> 
> I agree that it helps to avoid delivering duplicate packets to the end system.
> > The purpose is to avoid delivering duplicate packets to the end system, where (depending
> The IPsec is transparent to end system. So IIUC, end-to-end system/application
> shouldn't assume that it will never receive duplicate packets. So regardless of
> whether IPsec is used/deployed or not, it is end system/application responsibility

Conventional protocol design concentrates on handling events that occur normally in a network.  For example, accidental data corruption occurs on physical links due to noise and the like.  Packet reordering occurs due to how routing works.  Packet duplication may also occur normally on occasion.  In all these, the design focuses on non-malicious events: random or otherwise intermittent events but not events constructed by an adversary intent on breaking things.

By contrast, security protocols such as IPSec specifically aim to handle events created by a malicious adversary.  Consider the data corruption case: CRC works very well for random bit errors, which is why data link layers (such as Ethernet) use it widely.  CRC and checksums work well for some other classes of accidental data errors, which is why SCTP and iSCSI uses CRC, and TCP uses a simpler checksum.

None of those are any help at all against deliberate attacks.  It is utterly trivial to modify packets in a way that leaves the checksum or CRC unchanged (or, for that matter, to adjust the checksum so it still looks correct).  So IPSec does not do it that way; instead, it uses a keyed secure hash, which does have the property that it resists deliberate malicious modification.

So too with duplicate packets.  TCP, for example, deals with duplicate packets, within limits, and assuming that there isn’t an active attacker modifying the packet stream.  But the TCP mechanisms are not designed for and do not handle a deliberate attack by a skillful attacker.  On the other hand, the IPSec replay prevention mechanism does address such attacks.

So while it may seem that IPSec does a bunch of things that other protocols already do, or should already do, this is generally not the case; the key difference is “accidental” vs. “deliberate” in each of these areas.

	paul

---

From: Ashok Kumar <[email-masked]>
Date: Tue, 16 Dec 2014 22:41:57 +0530

Exactly. Michael has got my observation right.

With ESN, the receiver will unnecessarily do MAC calculation for replayed
packets
which falls before the replay window. The reason is, replayed packets whose
sequence
number is lesser than the window start, will be considered as newer packet
and anti-replay
check would be skipped for such packets (as per pseudo code given in the
RFC).

Thanks,
Ashok Kumar

---

From: Ashok Kumar <[email-masked]>
Date: Tue, 16 Dec 2014 22:56:00 +0530

Hi Steve,

> TCP, but a possible issue for UDP-based apps.

IMHO, the end system/application shouldn't assume that IPsec is deployed in
between.
Even if IPsec is deployed, the anti-replay may not be enabled. Though
anti-replay feature
helps to avoid delivering duplicate packets, the application should still
be able
to handle any potential duplicate packets.

> the sequence number is older than the AR window, thus avoiding crypto

Exactly, that was my point too. With ESN (as  per pseudo code given in the
RFC),
the replayed packet whose sequence number is older than window start
wouldn't be dropped immediately. It will be dropped only after MAC check
as higher 32-bit sequence number taken for MAC would be incorrect for
such packets. May be, the pseudo code didn't cover the exact intention.

Thanks,
Ashok Kumar

---

From: <[email-masked]>
Date: Tue, 16 Dec 2014 17:31:37 +0000

> On Dec 16, 2014, at 12:11 PM, Ashok Kumar <[email-masked]> wrote:
> 
> 
> With ESN, the receiver will unnecessarily do MAC calculation for replayed packets
> which falls before the replay window. The reason is, replayed packets whose sequence
> number is lesser than the window start, will be considered as newer packet and anti-replay
> check would be skipped for such packets (as per pseudo code given in the RFC).

It’s trivial for an attacker to force the receiver to do MAC calculations; all that he needs to do is send packets with new sequence numbers.

You’re right, if ESN is not in use, sequence numbers below the window are recognized as old, while with ESN they are assumed to be new (with the next higher value of the upper sequence number).  But either way, any replay will be rejected (possibly without requiring a MAC check, possibly with).

This is why I say that the purpose of sequence numbers is to prevent replay, and that optimizing the IPSec receive processing is not a goal.

	paul

---

From: <[email-masked]>
Date: Tue, 16 Dec 2014 17:36:12 +0000

> On Dec 16, 2014, at 12:26 PM, Ashok Kumar <[email-masked]> wrote:
> ...
> IMHO, the end system/application shouldn't assume that IPsec is deployed in between.
> Even if IPsec is deployed, the anti-replay may not be enabled.

But all useful IPSec deployments have anti-replay enabled.  See Steve Bellovin’s paper for why that is so.

End systems need cryptographic mechanisms if the environment is judged to be subject to malicous attack.  IPSec is one good mechanism of that kind; there are others (though given recent history, my first preference is IPSec if possible).  Applications can also build in their own crypto mechanisms rather than having lower layers provide the service, but doing so is very hard and quite risky.

	paul

---

From: Ashok Kumar <[email-masked]>
Date: Tue, 16 Dec 2014 23:10:12 +0530

Thanks Paul, Michael and Steve!

That clarifies my question.

Regards,
Ashok Kumar

On Tue, Dec 16, 2014 at 11:01 PM, <[email-masked]> wrote:
> It’s trivial for an attacker to force the receiver to do MAC calculations;
> all that he needs to do is send packets with new sequence numbers.
>
> You’re right, if ESN is not in use, sequence numbers below the window are
> recognized as old, while with ESN they are assumed to be new (with the next
> higher value of the upper sequence number).  But either way, any replay
> will be rejected (possibly without requiring a MAC check, possibly with).
>
> This is why I say that the purpose of sequence numbers is to prevent
> replay, and that optimizing the IPSec receive processing is not a goal.
>
>         paul
>