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

From: Praveen Muley <[email-masked]>
Date: Wed, 12 Jul 2000 14:03:01 -0700 (PDT)

Hi Brian/David,
     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. 
            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.  
        I am also not very clear as to what is meant
by reordering-based differentiation.
      To conclude this discussion somewhere I would
like to know  
    1. Do we allow multiple classes to use one tunnel
?
 If not, then why such imposition architecture wise as
said earlier if the issues is solved by other means.
We can always say that parallel tunnel is one of the
solution but may not be the best one. If there is any
other then probably can use that. 
   
Thanks,
Praveen

--- Brian E Carpenter <[email-masked]> wrote:
> Correct, it says you can't look inside the tunnel.
> That is
> my point.
> 
>   Brian
> 
> Praveen Muley wrote:
> > 
> > Hi Brian,
> >      The para in 5.1 of diffserv-tunnels-01.txt
> > 
> >   [Diffserv implementations should not attempt to
> look
> > within such tunnels to provide reordering-based
> > differentiation to the encapsulated microflows.
> >   If reordering-based differentiation is desired
> > within such tunnels, multiple parallel tunnels
> between
> > the same endpoints should be used. This enables
> > reordering among packets in different tunnels to
> > coexist with an absence of packet reordering
> within
> > each individual tunnel.]
> >     I felt second part doesn't allow to use one
> tunnel
> > for multiple class in any case.
> >         Will appreciate your comments &
> clarification.
> > Thanks,
> > Praveen
> > 
> > --- Brian E Carpenter <[email-masked]>
> wrote:
> > > I don't think it is excluded, since David's
> draft
> > > specifically allows traffic conditioning at
> > > that point.
> > >
> > >    Brian
> > >
> > > Praveen Muley wrote:
> > > >
> > > > 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,
> > > > > >        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:
> > > > > > > > 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
> 
=== message truncated ===

__________________________________________________
Do You Yahoo!?
Get Yahoo! Mail – Free email you can access from anywhere!
http://mail.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: Brian E Carpenter <[email-masked]>
Date: Thu, 13 Jul 2000 09:34:17 -0500

I thought that's what we were saying.

  Brian