RE: [manet] QoS on ad-hoc networks-security problem

Bin Lu <b0l4549@cs.tamu.edu> Thu, 23 January 2003 23:53 UTC

Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24714 for <manet-archive@odin.ietf.org>; Thu, 23 Jan 2003 18:53:54 -0500 (EST)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0O0Cbk05120 for manet-archive@odin.ietf.org; Thu, 23 Jan 2003 19:12:37 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0O0CbJ05117 for <manet-web-archive@optimus.ietf.org>; Thu, 23 Jan 2003 19:12:37 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24707 for <manet-web-archive@ietf.org>; Thu, 23 Jan 2003 18:53:22 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NNs8J03785; Thu, 23 Jan 2003 18:54:08 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NNqhJ03734 for <manet@optimus.ietf.org>; Thu, 23 Jan 2003 18:52:43 -0500
Received: from cs.tamu.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24359 for <manet@ietf.org>; Thu, 23 Jan 2003 18:33:28 -0500 (EST)
Received: from dogbert.cs.tamu.edu (IDENT:4054@dogbert [128.194.130.18]) by cs.tamu.edu (8.11.0/8.11.0) with ESMTP id h0NNasF02062 for <manet@ietf.org>; Thu, 23 Jan 2003 17:36:54 -0600 (CST)
Received: from localhost (b0l4549@localhost) by dogbert.cs.tamu.edu (8.11.0/8.11.0) with ESMTP id h0NNas719955 for <manet@ietf.org>; Thu, 23 Jan 2003 17:36:54 -0600 (CST)
X-Authentication-Warning: dogbert.cs.tamu.edu: b0l4549 owned process doing -bs
Date: Thu, 23 Jan 2003 17:36:53 -0600
From: Bin Lu <b0l4549@cs.tamu.edu>
X-Sender: b0l4549@dogbert
To: manet@ietf.org
Subject: RE: [manet] QoS on ad-hoc networks-security problem
In-Reply-To: <00c901c2c30a$7b2f9380$ca413b80@SWEETPEA>
Message-ID: <Pine.SOL.4.10.10301231619130.17861-100000@dogbert>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="X-UNKNOWN"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by www1.ietf.org id h0NNqhJ03735
Sender: manet-admin@ietf.org
Errors-To: manet-admin@ietf.org
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Id: Mobile Ad-hoc Networks <manet.ietf.org>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit

I know "security" problem is not a consideration when designing a QoS
model, but probably because my interest is security, I can't help thinking
about it when looking at QoS architectures. 

In stateless models, once the packets are differentiated by the classifier
residing at border hosts, the intermediate nodes don't keep per-flow
information and therefore don't have any control over the admission. 
The intermediate nodes roughly just forward it according to the service
levels marked by the border hosts. But the problem is, what if a selfish,
greedy or malicious node who cooperates with the classifier node steals
the services? Or the classifier mismarks the packets? It is easy
because in some models (such as FQMM) the source node even classify the
packets by itself. The intermediate nodes can't do flow admissions and
therefore won't be able to detect any intrusions.

It is different in stateful QoS models. Since the intermediate nodes still
keep the per-flow information, they can check or perform admission
control.

Is there any solution for this problem in stateless models, or is there
any existing technique that can help solve the problem?

Any hint will help. Thanks in advance!

Bin 

On Thu, 23 Jan 2003, Andrew T. Campbell wrote:

> 
> Hello John and Carlos:
> 
> We looked at both stateful and
> (INSIGNIA http://comet.columbia.edu/insignia/
> stateless (SWAN http://comet.columbia.edu/swan/)
> approaches to MANET-QOS. There are papers
> and code there.
> 
> There are various tradeoffs to consider
> but I now feel that the solution space
> is more likely to be dominated by
> stateless solutions (SWAN is one) because
> they are less complex to implement and better suited
> to cope with mobility.
> 
> I'm sure there are a number of interesting
> solutions that lie between these stateful and stateless
> approaches. I do not think RSVP in a MANET is a
> good idea BTW.
> 
> IDs for our work:
> 
> INSIGNIA:
> 
> http://www.comet.columbia.edu/insignia/draft-ietf-manet-insignia-01.txt
> 
> 
> SWAN:
> 
> http://comet.columbia.edu/swan/draft-ahn-swan-manet-00.txt
> 
> QOS has never really been on the radar screen for the WG
> but maybe a good scope item for the new IRTF MANET initiative.
> 
> Its still early days for this topic I suspect.
> 
> ---
> Andrew
> http://comet.columbia.edu/~campbell
> 
> 
> > -----Original Message-----
> > From: manet-admin@ietf.org [mailto:manet-admin@ietf.org]On Behalf Of
> > John Tapsell
> > Sent: Thursday, January 23, 2003 12:29 PM
> > To: Carlos García
> > Cc: manet@ietf.org
> > Subject: Re: [manet] QoS on ad-hoc networks
> >
> >
> > Disclaimer:  I know nothing.  My knowledge is incomplete and
> > ba and you
> > shouldn't trust it at all.
> >
> > I had a look at this, and had a quite few problems trying to
> > set up such a
> > network.  Basically what I managed to learn was:
> >   * The idea has been around longer than I've been alive.
> >   * Hardly anyone seems to be working on it.
> >   * RSVP was played about with a lot, but died on adhoc's
> > because it is
> > trying to enforce stateful connections on a stateless network.
> >   * You need to have a very clear idea of what properties
> > your network has.
> > How much everything moves about, whether there are groupings,
> > whether there
> > are fixed points, etc.
> >   * If things are going to be moving about, then the QoS is
> > basically doomed
> > :)   So switch your focus on looking whether best-effort is
> > good enough.
> >   * Implementations of various QoS systems for linux are in a
> > bad state.  An
> > implementation of dRSVP that I tried to set up had bugs that
> > the author was
> > still trying to fix.  ( I found that out _after_ spending
> > ages trying to find
> > out what was wrong).  I did manage to get another
> > implementation of dRSVP
> > working tho.  Although this was through a lot of sweat and
> > blood - mostly due
> > to my ignorance in this area.  I still don't really get the
> > whole class based
> > queueing system.
> >   * If you want to study QoS, make sure you study and
> > understand routing on
> > adhocs first.
> >   * It seems to me, in my very humble opinion, that there
> > isn't likely to be a
> > 'wonder' protocol that works on any network, but rather you
> > need to evaluate
> > the network closely and see what fits best.
> >
> > Take what I've said with a pinch of salt, but I hope I can
> > help in some small
> > way.
> >
> > JohnFlux
> >
> > On Thursday 23 January 2003 3:35 pm, Carlos García wrote:
> > > Hi everybody,
> > >
> > > I am very interesting in the support of QoS on adhoc networks.
> > >
> > > I will be very pleased if someone could help me finding
> > papers or proyects
> > > related to this subject.
> > >
> > > Thank you very much,
> > >  Carlos García
> > >
> > > _______________________________________________
> > > manet mailing list
> > > manet@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/manet
> >
> 
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www1.ietf.org/mailman/listinfo/manet
> 



_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet