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

From: Praveen Muley <[email-masked]>
Date: Thu, 6 Jul 2000 22:30:24 -0700 (PDT)

At the receiving end of the tunnel we can have window
sliding mechanism per diffserv class basis but using
same SA. 
         In this case lets assume that packets of one
trafffic class  is fast than the other in the same
tunnel( using one SA only). 
     For ex. class one packets have sequence no.
1..99. Then class two having 100th ( for its first
packet) then again 99 packets from the First class and
the 200 th packet from the second class( 2nd packet).
          But since in case of  windows sliding  the
right edge always move if the counter is greater than
the previous one after authenticating the packet, the
sequence counter will be set to the new one. In our
example there will two different windows sliding for
two different diffserv class at receiving end.  So the
sequence number in for second class will jump to 200
for the second  packet it receives. 
         In the second class since there is lot of
delay between the two packets , I don't think there is
any chance of reordering so as to fail the windows
sliding mechanism.
       I mentioned to check inner IP header TOS value
in my earlier mail b'coz that is authenticated so even
though malacious user marks deliberately to other
class it won't affect our windows sliding mechanism. 
         I know changing the class can have its own
issues but this is at the max. security we can take
from our side. 
     I hope this answers the tunnel per TOS issue.
Will appreciate your comments.

Thanks,
Praveen
       
--- [email-masked] wrote:
> 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
> 
> > -----Original Message-----
> > 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,
> >       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
> 
=== 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: Scott Fanning <[email-masked]>
Date: Fri, 07 Jul 2000 08:55:29 -0700

Praveen

Thanks for your reply. In ESP, the outer IP header is not authenticated.
This is only the case of AH (which is slowly going away).

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.

Thanks
Scott

-- 
Scott T. Fanning                        Tel: (408)525-3166
Software Engineer                       E-mail: [email-masked]
VPN & Security Services BU              Fax: (408) 527-7099
Cisco Systems Inc.