Subject: [Diffserv] IPSec and Anti-Replay

From: "Scott Fanning" <[email-masked]>
Date: Wed, 14 Jun 2000 18:05:56 -0700

Has anyone looked at the issue of the Sequence Number (Anti-Replay) checking in ESP/AH and interaction with the queuing in diffserv. 

The issue I have been told about is that since there is no guarantee that a single flow of ESP/AH traffic will be on the same queue, that anti-reply checking may fail due to different arrival times of packets. One suggestion has been to turn-off anti-replay checking. This is allowed according to RFCs

From RFC 2406 and RFC 2402

  This unsigned 32-bit field contains a monotonically increasing
   counter value (sequence number).  It is mandatory and is always
   present even if the receiver does not elect to enable the anti-replay
   service for a specific SA.  Processing of the Sequence Number field
   is at the discretion of the receiver, i.e., the sender MUST always
   transmit this field, but the receiver need not act upon it (see the
   discussion of Sequence Number Verification in the "Inbound Packet
   Processing" section below).

It would be very desirable to maintain the anti-replay security mechanism while doing QoS. Any guidance would be appreciated.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 14 Jun 2000 21:53:42 -0400

>>>>> "Scott" == Scott Fanning <[email-masked]> writes:
    Scott> [1 <text/plain; iso-8859-1 (quoted-printable)>] Has anyone looked
    Scott> at the issue of the Sequence Number (Anti-Replay) checking in
    Scott> ESP/AH and interaction with the queuing in diffserv.

    Scott> The issue I have been told about is that since there is no
    Scott> guarantee that a single flow of ESP/AH traffic will be on the same
    Scott> queue, that anti-reply checking may fail due to different arrival
    Scott> times of packets. One suggestion has been to turn-off anti-replay
    Scott> checking. This is allowed according to RFCs

  A certain amount of reordering is expected.
  How far back to keep the replay window is, as I recall, implementation
specific. Typically 32 or 64 packets of out-of-order arrival are permitted.

  I can not see that a single flow of ESP/AH would wind up on different
queues as a *policy*(%) --- only as a punishment for exceeding some queue
parameters.
  
  [%] - i am intending to write a draft on interaction of IPsec and
MF classifiers and why it isn't a problem that you can't see the TCP ports
numbers. 

   :!mcr!:            |  Solidum Systems Corporation, http://www.solidum.com
   Michael Richardson |For a better connected world,where data flows faster<tm>
 Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html
	mailto:[email-masked]	mailto:[email-masked]

_______________________________________________
diffserv mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

---

From: Michael Richardson <[email-masked]>
Date: Wed, 14 Jun 2000 22:58:37 -0400

>>>>> "Steve" == Steve Kohalmi <[email-masked]> writes:
    Steve> As a "punishment" you changing the packet's drop probability,
    Steve> while keeping it on the same queue. That is exactly the reason for
    Steve> AF differentiating between Classes and Drop Precedences. This is
    Steve> pretty clear in RFC-2597.

  So, reording of IPsec packets is not an issue.
  Problem solved.

---

From: Steve Kohalmi <[email-masked]>
Date: Wed, 14 Jun 2000 22:52:08 -0400

Michael,

As a "punishment" you changing the packet's drop probability, while keeping
it on the same queue. That is exactly the reason for AF differentiating
between Classes and Drop Precedences. This is pretty clear in RFC-2597.

   "If a DS node only implements two different levels of loss probability
    for an AF class x, the codepoint AFx1 MUST yield the lower loss
    probability and the codepoints AFx2 and AFx3 MUST yield the higher
    loss probability.

    A DS node MUST NOT reorder AF packets of the same microflow when they
    belong to the same AF class regardless of their drop precedence.
    There are no quantifiable timing requirements (delay or delay
    variation) associated with the forwarding of AF packets."

Steve

At 9:53 PM -0400 6/14/00, Michael Richardson wrote:
> Personal: 
>http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html

---

From: "Brijesh Kumar" <[email-masked]>
Date: Thu, 15 Jun 2000 10:27:31 -0400

The problem doesn't even exist. And even if this was not the case, any
security mechanism have to allow a window for accepting out of
sequence packets at the receiver assuming that packets may not be
delivered in the sequenced order.

Cheers,

--brijesh
Ennovate Networks Inc.

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf
> Of Michael Richardson
> Sent: Wednesday, June 14, 2000 10:59 PM
> To: [email-masked]
> Subject: Re: [Diffserv] IPSec and Anti-Replay
>
>
>