Subject: [IPsec] is there any proposed solution to solve the anti-replay problem for IPsec pkts when subject to QOS classification

From: Prabhat Hegde <[email-masked]>
Date: Wed, 25 Mar 2009 16:27:35 +0530

Hi,
      In case we do QOS re-ordering (caused due to shaping & queueing) for
traffic classes after encryption, the encrypted pkts get re-ordered thus
changing the order of sequence numbers. At the receiving end, such
out-of-order pkts are droped by IPsec since they do not fall under the
anit-replay window range.
        Is there any proposed solution/draft which caters to this problem?
If yes, it would be great if someone can point me to it.

-- 
With regards,
Prabhat

---

From: Yoav Nir <[email-masked]>
Date: Wed, 25 Mar 2009 13:07:19 +0200

RFC 4306 specifically requires implementations to support multiple parallel child SAs.

If you use a different SA for each QoS class, you should not have problems with the replay window

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Prabhat Hegde
Sent: Wednesday, March 25, 2009 12:58 PM
To: [email-masked]
Subject: [IPsec] is there any proposed solution to solve the anti-replay problem for IPsec pkts when subject to QOS classification

Hi,
      In case we do QOS re-ordering (caused due to shaping & queueing) for traffic classes after encryption, the encrypted pkts get re-ordered thus changing the order of sequence numbers. At the receiving end, such out-of-order pkts are droped by IPsec since they do not fall under the anit-replay window range.
        Is there any proposed solution/draft which caters to this problem? If yes, it would be great if someone can point me to it.

--
With regards,
Prabhat

Email secured by Check Point

---

From: Francis Dupont <[email-masked]>
Date: Wed, 25 Mar 2009 15:34:01 +0100

In your previous mail you wrote:

=> this issue is well known in the IPsec community but:
 - after encryption there should be no reason to classify (then reorder)
  packets in different ways
 - before encryption you can setup with IKEv2 different SAs between the
  same end-points and then apply different QoS.
In both cases the anti-replay window should not drop "old packets" from
QoS reordering.

Regards

[email-masked]

---

From: Stephen Kent <[email-masked]>
Date: Wed, 25 Mar 2009 11:30:03 -0400

At 4:27 PM +0530 3/25/09, Prabhat Hegde wrote:
>Hi,
>       In case we do QOS re-ordering (caused due to shaping & 
>queueing) for traffic classes after encryption, the encrypted pkts 
>get re-ordered thus changing the order of sequence numbers. At the 
>receiving end, such out-of-order pkts are droped by IPsec since they 
>do not fall under the anit-replay window range.
>         Is there any proposed solution/draft which caters to this 
>problem? If yes, it would be great if someone can point me to it.
>
>--
>With regards,
>Prabhat
>
>

I agree with Frances's reply; we made explicit provisions for this in 4301:

If different classes of traffic (distinguished by Differentiated
    Services Code Point (DSCP) bits [NiBlBaBL98], [Gro02]) are sent on
    the same SA, and if the receiver is employing the optional
    anti-replay feature available in both AH and ESP, this could result
    in inappropriate discarding of lower priority packets due to the
    windowing mechanism used by this feature.  Therefore, a sender SHOULD
    put traffic of different classes, but with the same selector values,
    on different SAs to support Quality of Service (QoS) appropriately.
    To permit this, the IPsec implementation MUST permit establishment
    and maintenance of multiple SAs between a given sender and receiver,

    with the same selectors.  Distribution of traffic among these
    parallel SAs to support QoS is locally determined by the sender and
    is not negotiated by IKE.  The receiver MUST process the packets from
    the different SAs without prejudice.  These requirements apply to
    both transport and tunnel mode SAs.  In the case of tunnel mode SAs,
    the DSCP values in question appear in the inner IP header.  In
    transport mode, the DSCP value might change en route, but this should
    not cause problems with respect to IPsec processing since the value
    is not employed for SA selection and MUST NOT be checked as part of
    SA/packet validation.  However, if significant re-ordering of packets
    occurs in an SA, e.g., as a result of changes to DSCP values en
    route, this may trigger packet discarding by a receiver due to
    application of the anti-replay mechanism.

Steve

---

From: Prabhat Hegde <[email-masked]>
Date: Fri, 27 Mar 2009 22:01:21 +0530

Hi Francis,
       - *after encryption there should be no reason to classify (then
reorder) packets in different ways *
  -> There are two cases here:
1. QOS policies being applied on the logical tunnel interfaces
          Here, classification & marking take place before the crypto
accelerator & the actual queueing & shaping of the resulting encrypted pkts
happen on the physical interface facing the ISP. For queing & shaping to
happen before the crypto engine we would have to change the driver code,
equip the h/w accelerator with different set of queues, etc since the crypto
engine serves mulitple interface each which can hold different QOS policies.

2. QOS policies being applied on the physical interface (or in addition to
the one being applied in the logical interfaces)
     Here pkts destined to the physical interface matching an ipsec ruleset
have to proceed to the crypto engine & then back to the physical interface
after encryption.
      So in both of the above cases, the queueing & shaping happen on the
physical interface which would cause re-ordering of encrypted pkts.

 - *before encryption you can setup with IKEv2 different SAs between the
same end-points and then apply different QoS.*
You mean IPSec SAs here. I am taking a look into this. But I must see how it
affects the existing scalability.

*In both cases the anti-replay window should not drop "old packets" from QoS
reordering.*
   Work around would be to increase the size of the replay window, but I
feel this is not a clean solution.

On Wed, Mar 25, 2009 at 8:04 PM, Francis Dupont
<[email-masked]>wrote:

> problem?

-- 
With regards,
Prabhat

---

From: Francis Dupont <[email-masked]>
Date: Fri, 27 Mar 2009 18:33:39 +0100

=> in my English "before" is the opposite of "after", i.e., you are
clearly in the second case.

   
=> queueing and shaping are done according to some kind of packet
classification: there is nearly nothing usable to perform classification
of encrypted packets. So what you say doesn't make sense for me.

    - *before encryption you can setup with IKEv2 different SAs between the
   same end-points and then apply different QoS.*
   You mean IPSec SAs here. I am taking a look into this.

=> yes, they are the IPsec SAs on which traffic will be sent.

   But I must see how it affects the existing scalability.

=> please read the messages (*) you receive before arguing...
The issue you believe you discovered was already addressed: IPsec works
perfectly with (and without) QoS. The only concerns I ever saw about this
was about the fact QoS handling is a covered channel (some communities
are very paranoid about covered channels :-).

PS: (*) mine and Steve Kent's.

---

From: Stephen Kent <[email-masked]>
Date: Fri, 27 Mar 2009 13:37:51 -0400

Prabhat,

With regard to your first observation, I'll note that your argument 
appears to be based on particular implementation choices. We don't 
generally consider changes to standards based on such choices, unless 
a lot of vendors indicate that there are no viable implementation 
options consistent with the standard.

With regard to your second observation, the text I cited from 4301 
clearly identified IPsec (not IKE) SAs as the way to accommodate 
QoS-induced reordering.

The 64-packet receive window is a MINIMUM value. So a receiver is 
always free to make the window bigger. The impact of this is minimal 
for software implementations, but might be an issue in hardware, 
depending on how the window is implemented.

Steve