Subject: [Diffserv] ToS, IPSec and Anti replay

From: "Scott Fanning" <[email-masked]>
Date: Fri, 23 Jun 2000 08:46:09 -0700

All

Thanks for the responses to my e-mail concerning the above topic, but I don't think I described the
problem completely so I will try again. Being new to diff-serv, please excuse my lack of correct terminology.

In ESP and AH, there are sequence numbers that are monotonicly
increasing. IPSec expects the packets to arrive in order.

Let DS = QoS Classification
Let GW = Gateway

                                            <---------IPSec Tunnel------>
User A
User B<---->GW A / DS<-------------->DS<---------->GW B<--->User D
User C

User A, B and C all have different classes of service applied to them, but all on the same subnet.
GW A to GW B has a IPsec Tunnel that will tunnel all packets across a service providers network for that subnet to the subnet on the other side (GW B). Since all traffic goes through one tunnel (Avery common Service provider setup), each user with a different ToS octet, when the diff-serve device classifies the traffic on the other end, it will go into separate queues.

As these queues will be serviced at different times, the Seq Numbers to GW B will be out of order and will be dropped.

Has anyone seen, or experienced this. As I stated before, anti-replay
can be turned off at the Receiver end, but it would be better to
maintain the anti-replay service.

Thanks
Scott

---

From: [email-masked] (Michael Richardson)
Date: Fri, 23 Jun 2000 14:24:26 -0400

>>>>> "Scott" == Scott Fanning <[email-masked]> writes:
    Scott> In ESP and AH, there are sequence numbers that are monotonicly
    Scott> increasing. IPSec expects the packets to arrive in order.

  No. It expects them to arrive not-too-far out of order.

  Implementations keep a window and accept the last 32 to 64 packets out of
order. This is implementation dependant. See, for instance RFC2402,
section 3.4.3, paragraph 4-6:

   Duplicates are rejected through the use of a sliding receive window.
   (How the window is implemented is a local matter, but the following
   text describes the functionality that the implementation must
   exhibit.)  A MINIMUM window size of 32 MUST be supported; but a
   window size of 64 is preferred and SHOULD be employed as the default.
   Another window size (larger than the MINIMUM) MAY be chosen by the
   receiver.  (The receiver does NOT notify the sender of the window
   size.)

   The "right" edge of the window represents the highest, validated
   Sequence Number value received on this SA.  Packets that contain
   Sequence Numbers lower than the "left" edge of the window are
   rejected.  Packets falling within the window are checked against a
   list of received packets within the window.  An efficient means for
   performing this check, based on the use of a bit mask, is described
   in the Security Architecture document.

    Scott> User A, B and C all have different classes of service applied to them, but all on the same subnet.
    Scott> GW A to GW B has a IPsec Tunnel that will tunnel all packets
    Scott> across a service providers network for that subnet to the subnet on the
    Scott> other side (GW B). Since all traffic goes through one tunnel (Avery
    Scott> common Service provider setup), each user with a different ToS octet,
    Scott> when the diff-serve device classifies the traffic on the other end, it
    Scott> will go into separate queues. 

  Assuming that GW A is putting different DS marks on the outer header on
based upon its knowledge of the contents of the packets, then yes this will
occur. GW A should negotiate three SA's for the traffic. Most gateways can 
do this if you ask for "per-host" keying.

   :!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/