Subject: Re: [Diffserv] ToS, IPSec and Anti replay

From: Praveen Muley <[email-masked]>
Date: Thu, 6 Jul 2000 18:17:34 -0700 (PDT)

Hi Scott,
      I don't know why you are saying as equivalent to
IPsec tunnel per TOS. 
                B'coz even though we have anti-replay
( sliding window )  mechanism per DSCP we will have
only one SA for it. 
              Since the box is performing
Diffie-Hellman like operation this will not be that
memory intensive. 
        So I don't see scalability issue. Also I am in
agreement with Brian's view.
        
    Sorry Brian for mailing you twice the same mail.  

Thanks,
Praveen
--- Brian E Carpenter <[email-masked]> wrote:
> Scott,
> 
> Since a small box is hopefully only supporting a
> couple of diffserv traffic classes 
> anyway, I'm not sure I see the scaling issue here.
> 
>   Brian
> 
> Scott Fanning wrote:
> > 
> > While this would solve the problem, this is the
> equivalent of a IPSec Tunnel
> > per ToS (DSCP). That will not be acceptable on
> smaller boxes that can not do
> > large numbers of tunnels. I am going over the
> tunnels document over the
> > weekend and will get some comments back ASAP.
> > 
> > Thanks for everybody's comments. Looking forward
> to the WG meeting :-)
> > 
> > Thanks
> > Scott
> > 
> > > -----Original Message-----
> > > From: [email-masked]
> [mailto:[email-masked]]On Behalf
> > > Of Praveen Muley
> > > Sent: Tuesday, June 27, 2000 8:23 PM
> > > To: Brian E Carpenter; [email-masked]
> > > Cc: [email-masked]; [email-masked]
> > > Subject: Re: [Diffserv] ToS, IPSec and Anti
> replay
> > >
> > >
> > > Hi Scott,
> > >       Can have an anti-replay mechanism per
> Diff. Code
> > > point basis that too on inner IP header's Diff.
> code
> > > point ( of course for security reason).
> > >       Hope this might answer the scenario you
> are
> > > mentioning.
> > >       Will appreciate your comments.
> > >
> > > Thanks,
> > > Praveen
> > > --- Brian E Carpenter <[email-masked]>
> wrote:
> > > > To be even more explicit: we expect to
> last-call the
> > > > tunnels
> > > > document any time now. Anyone who doesn't
> believe
> > > > that it
> > > > adequately responds to Scott Fanning's
> question
> > > > needs to say
> > > > so, so that we can close this issue
> permanently.
> > > >
> > > >   Brian Carpenter
> > > >   diffserv co-chair
> > > >
> > > > [email-masked] wrote:
> > > > >
> > > > > This is a real issue; please read
> > > > >         draft-ietf-diffserv-tunnels-01.txt
> > > > > and let me (and the list) know whether the
> > > > > material in Section 5 (and its subsections)
> > > > > addresses this adequately.
> > > > >
> > > > > Thanks,
> > > > > --David
> > > > >
> > > > >
> > > >
> ---------------------------------------------------
> > > > > David L. Black, Senior Technologist
> > > > > EMC Corporation, 42 South St., Hopkinton, MA
> > > > 01748
> > > > > +1 (508) 435-1000 x75140, FAX: +1 (508)
> 497-6909
> > > > > [email-masked]  Cellular: +1 (978)
> 394-7754
> > > > >
> > > >
> ---------------------------------------------------
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Scott Fanning
> [SMTP:[email-masked]]
> > > > > > Sent: Friday, June 23, 2000 11:46 AM
> > > > > > To:   [email-masked]
> > > > > > Subject:      [Diffserv] ToS, IPSec and
> Anti
> > > > replay
> > > > > >
> > > > > > 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
> > > > > >
> > > > > >
> > > > >
> > > > >
> _______________________________________________
> > > > > diffserv mailing list
> > > > > [email-masked]
> > > > >
> http://www1.ietf.org/mailman/listinfo/diffserv
> > > > > Archive:
> http://www-nrg.ee.lbl.gov/diff-serv-arch/
> > > >
> > > > --
> > > > - - - - - - - - - - - - - - - - - - - - - - -
> - - -
> > > > - - - - - - -
> > > > Brian E Carpenter
> > > > Program Director, Internet Standards &
> Technology,
> > > > IBM
> > > > On assignment for IBM at http://www.iCAIR.org
> > > > Attend INET 2000: http://www.isoc.org/inet2000
> > > > Non-IBM email: [email-masked]
> > > >
> > > >
> _______________________________________________
> > > > diffserv mailing list
> > > > [email-masked]
> > > > http://www1.ietf.org/mailman/listinfo/diffserv
> > > > Archive:
> http://www-nrg.ee.lbl.gov/diff-serv-arch/
> > > >
> > >
> > >
> > >
> __________________________________________________
> > > Do You Yahoo!?
> > > Get Yahoo! Mail - Free email you can access from
> anywhere!
> 
=== message truncated ===

__________________________________________________
Do You Yahoo!?
Send instant messages & get email alerts with Yahoo! Messenger.
http://im.yahoo.com/

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

---

From: [email-masked]
Date: Thu, 6 Jul 2000 21:30:10 -0400

Let me add a little bit of precision.  An
SA is not needed per DSCP, only per traffic class
for classes among which ordering-based differentiation
is desired between tunnel endpoints.  In some cases,
a tunnel per DSCP is not a good idea - e.g., for the
various drop precedences of a single AF class.  If
resources to support multiple tunnels are tight, there
is always the option of putting all the traffic to
a single tunnel endpoint into a single tunnel,
marking one DSCP on the outer headers and foregoing
any diffserv differentiation between the tunnel
endpoints.  The result is a tradeoff between the
degree of differentiation and the number of tunnels;
aside from yet another application of the "no free
lunch" principle, I don't think I see a major problem
here.

--David

> From:	Praveen Muley [SMTP:[email-masked]]
> Sent:	Thursday, July 06, 2000 9:18 PM
> To:	Brian E Carpenter; Scott Fanning
> Cc:	Praveen Muley; [email-masked]; [email-masked]
> Subject:	Re: [Diffserv] ToS, IPSec and Anti replay
> 
> Hi Scott,

---

From: [email-masked]
Date: Fri, 7 Jul 2000 14:26:19 -0400

> So, just so I am clear. If I have 2 classes of service and one tunnel
> for both, and packets are out of order, you are saying that it is the
> IPSec anti-replay windows problem? The solution is a tunnel per class of
> service.

That's one possibility.  Here's the complete story -- IF

(1) You have two classes of service AND
(2) You want to run them in IPSec tunnel mode AND
(3) You want them differentiated in a way that reorders packets within the
tunnel AND
(4) You want to use IPSec anti-replay protection AND
(5) You want to use a single tunnel.

THEN you have a problem, because the last three items cannot in general be
done at
the same time without having the IPSec anti-replay protection complain or
worse.

There are three possible solutions based on which item is left out:

(A) Leave out (3) by marking the same class of service on the outer
	IP headers even though there are multiple classes carried in the
tunnel.
	There will be no packet reordering within the tunnel.
(B) Leave out (4) by not configuring IPSec anti-replay protection.
(C) Leave out (5) by using a tunnel per class of service that you want
differentiated.
	This uses additional resources to support the additional tunnels.

Again, please check the text in draft-ietf-diffserv-tunnels-01.txt, which
is in informal last call at the moment.  The text in Sections 5.1 and 5.2
is supposed to address *exactly* this issue - if the text is not
sufficiently clear, I need to make it so, and would appreciate suggestions.

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140, FAX: +1 (508) 497-6909
[email-masked]  Cellular: +1 (978) 394-7754
---------------------------------------------------

---

From: [email-masked]
Date: Mon, 10 Jul 2000 16:21:53 -0400

There's no prohibition.  What it comes down to is:

IF reordering is allowed within an IPsec tunnel,
THEN situations will arise in which the anti-replay
	support will complain.

Whether and when this actually happens depends on all
sorts of situation-specific configuration and behavioral
information (e.g., what other traffic is using the links).

IF the complaints aren't desired, and the anti-replay
	support is required.
THEN use separate tunnels.

If the complaints are acceptable, go ahead and use one
tunnel - other means are also available to address the
problem, such as not configuring anti-replay support.
Again - please check the wording in
draft-ietf-diffserv-tunnels-01.txt and let me know if
anything in there needs further explanation or
clarification.

--David

> Sent:	Monday, July 10, 2000 2:15 PM
> To:	[email-masked]; [email-masked]
> Cc:	[email-masked]
> Subject:	RE: [Diffserv] ToS, IPSec and Anti replay
> 
> Hi David, 
>        I think you must have touched this point
> earlier but would like to know as to why architechture
> wise we are restricting of not having reordering
> within a tunnel if by some other means we are able to
> solve the issue. 
>          Instead of should can we have a may over
> there.
>        Sorry about going all over back.
> 
> Thanks,
> Praveen
> 
> --- [email-masked] wrote:
> > Again, please check the text in
> > draft-ietf-diffserv-tunnels-01.txt, which
> Get Yahoo! Mail - Free email you can access from anywhere!
> http://mail.yahoo.com/

---

From: Praveen Muley <[email-masked]>
Date: Tue, 11 Jul 2000 11:37:02 -0700 (PDT)

Hi Brian,
     The reordering requirement really applies
to packets after traversing the tunnels
and before delivery to the application or
next processing module. this can be achieved
by processing at the tunnel endpoints. 
such a capability should not be excluded
from consideration. Having separate tunnels
per diffserv class removes the need for this
tunnel endpoint processing, but has significant
resource utilization and scalability disadvantages.
              
Thanks,
Praveen 
--- Brian E Carpenter <[email-masked]> wrote:
> Praveen,
> 
> In general, diffserv requires non-reordering of
> microflows,
> quite independent of any security/replay issues.
> Packets
> hidden inside a tunnel should respect this
> constraint.
> Because they are hidden, you can't see the
> microflows, so this 
> translates into a non-reordering requirement on the
> tunnel.
> 
>    Brian
> 
> Praveen Muley wrote:
> > 
> > Hi David,
> > > > for both, and packets are out of order, you
> are
> > > saying that it is the
> > > > IPSec anti-replay windows problem? The
> solution is
> > > a tunnel per class of
> > > > service.
> > >
> > > That's one possibility.  Here's the complete
> story
> > > -- IF
> > >
> > > the same time without having the IPSec
> anti-replay
> > > protection complain or
> > > worse.
> > >
> > > There are three possible solutions based on
> which
> > > item is left out:
> > >
> > >       IP headers even though there are multiple
> classes
> > > carried in the
> > > tunnel.
> > >       There will be no packet reordering within
> the
> > > tunnel.
> > >       This uses additional resources to support
> the
> > > additional tunnels.
> > >
> > > is in informal last call at the moment.  The
> text in
> > > Sections 5.1 and 5.2
> > > is supposed to address *exactly* this issue - if
> the
> > > text is not
> > > sufficiently clear, I need to make it so, and
> would
> > > appreciate suggestions.
> > >
> > > Thanks,
> > > --David
> > >
> > >
> > Get Yahoo! Mail – Free email you can access from
> anywhere!
> > http://mail.yahoo.com/
> > 
> - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - - - - - -
> Brian E Carpenter 
> Program Director, Internet Standards & Technology,
> IBM 

__________________________________________________
Do You Yahoo!?
Get Yahoo! Mail – Free email you can access from anywhere!
http://mail.yahoo.com/

---

From: [email-masked]
Date: Wed, 12 Jul 2000 17:33:29 -0400

>      Correct me if I am wrong. What I am interpreting
> is that author wants multiple tunnels to avoid the
> packet reordering issue at the tunnel end-point. So
> thats the reason, have parallel tunnels for multiple
> (for ex.)AF classes.

So far, this is correct; an important piece of the problem is
that the tunnel protocol mechanisms that are sensitive to
reordering tend to be per-tunnel, not per traffic class in a
single tunnel.  For example, each IPSec tunnel-mode
SA has its own tunnel.

>             My point is if the reordering issue can
> get solved at the tunnel end-point processing( like
> having anti-replay per class) why not to allow the
> multiple classes through same tunnel. I am not saying
> anything to do with micro-flow re-ordering but
> ordering per class.

In general, anti-replay only works per-tunnel, not per-class in
a single tunnel.  Changing this should be taken up with the WGs
that define the protocols involved (e.g. IPSec and L2TP).  If the
protocol can solve the problem per class, the language in the
draft allows multiple classes into the tunnel, and makes this
recommendation the responsibility of the WG that works on
the tunnel protocol, not diffserv.  Micro-flows come into the
picture only because a tunnel can look like a single microflow
to a diffserv node that doesn't realize that there is a tunnel involved,
especially if something fancy like IP in PPP in L2TP in
IPsec transport mode is being employed.  When this happens,
diffserv naturally refrains from reordering packets in the tunnel.

>         I am also not very clear as to what is meant
> by reordering-based differentiation.

Differentiation provided by diffserv nodes in the tunnel that causes
packets to exit in a different order than they went in.

>      To conclude this discussion somewhere I would like to know  
>    1. Do we allow multiple classes to use one tunnel?

Yes.  The draft advises not doing this when reordering-sensitive
features of protocols like L2TP and IPSec are configured, but the
ultimate decision is up to the specifiers of those protocols, as well
as the implementers, designers, and operators of the networks.
Keep in mind that the tunnels draft is intended to be informational,
and hence contains no MUSTs or SHOULDs; those belong in
documents generated for IPSec, L2TP, and the like.

--David