Re: [dtn-interest] Re: [ltp] draft-irtf-dtnrg-ltp-extensions-00

Wesley Eddy <weddy@grc.nasa.gov> Mon, 07 February 2005 20:22 UTC

Received: from mx1.grc.nasa.gov (mx1.grc.nasa.gov [128.156.11.68]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j17KMe106601 for <dtn-interest@mailman.dtnrg.org>; Mon, 7 Feb 2005 12:22:41 -0800
Received: from lombok-fi.grc.nasa.gov (seraph1.grc.nasa.gov [128.156.10.10]) by mx1.grc.nasa.gov (Postfix) with ESMTP id 33A92C2F3 for <dtn-interest@mailman.dtnrg.org>; Mon, 7 Feb 2005 15:22:35 -0500 (EST)
Received: from apataki.grc.nasa.gov (apataki.grc.nasa.gov [139.88.112.35]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.12.10/8.12.10) with ESMTP id j17KMYRs002110; Mon, 7 Feb 2005 15:22:34 -0500 (EST)
Received: from localhost (localhost [127.0.0.1]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.1/8.13.1) with ESMTP id j17KMY5e001285; Mon, 7 Feb 2005 15:22:34 -0500 (EST)
Received: from apataki.grc.nasa.gov ([127.0.0.1])by localhost (apataki.grc.n asa.gov [127.0.0.1]) (amavisd-new, port 10024)with ESMTP id 00690-03; Mon, 7 Feb 2005 15:22:34 -0500 (EST)
Received: from drpepper.grc.nasa.gov (gr2134391.grc.nasa.gov [139.88.44.123] )by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.1/8.13.1) with ESMTP id j17KMY G6001282; Mon, 7 Feb 2005 15:22:34 -0500 (EST)
Received: by drpepper.grc.nasa.gov (Postfix, from userid 501)id 5160C4FC48; Mon, 7 Feb 2005 15:17:50 -0500 (EST)
Date: Mon, 07 Feb 2005 15:17:50 -0500
From: Wesley Eddy <weddy@grc.nasa.gov>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Cc: ltp@masaka.cs.ohiou.edu, dtn-interest@mailman.dtnrg.org
Subject: Re: [dtn-interest] Re: [ltp] draft-irtf-dtnrg-ltp-extensions-00
Message-ID: <20050207201750.GF4292@grc.nasa.gov>
Reply-To: weddy@grc.nasa.gov
References: <20050204172646.GI2865@grc.nasa.gov> <4203B856.8020702@cs.tcd.ie > <20050204190853.GL2865@grc.nasa.gov> <4203D2B1.6010707@cs.tcd.ie> <200502 07144409.GA4292@grc.nasa.gov> <20050207171201.GD4292@grc.nasa.gov> <4207AE2 8.70300@cs.tcd.ie>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="9ADF8FXzFeE7X4jE"
Content-Disposition: inline
In-Reply-To: <4207AE28.70300@cs.tcd.ie>
X-People-Whose-Mailers-Cant-See-This-Header-Are-Lame: true
User-Agent: Mutt/1.5.5.1i
X-imss-version: 2.19
X-imss-result: Passed
X-imss-scores: Clean:0.00000 C:100 M:100 S:100 R:100
X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000)
Sender: dtn-interest-admin@mailman.dtnrg.org
Errors-To: dtn-interest-admin@mailman.dtnrg.org
X-BeenThere: dtn-interest@mailman.dtnrg.org
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Help: <mailto:dtn-interest-request@mailman.dtnrg.org?subject=help>
List-Post: <mailto:dtn-interest@mailman.dtnrg.org>
List-Subscribe: <http://mailman.dtnrg.org/mailman/listinfo/dtn-interest>, <mailto:dtn-interest-request@mailman.dtnrg.org?subject=subscribe>
List-Id: Delay Tolerant Networking Interest List <dtn-interest.mailman.dtnrg.org>
List-Unsubscribe: <http://mailman.dtnrg.org/mailman/listinfo/dtn-interest>, <mailto:dtn-interest-request@mailman.dtnrg.org?subject=unsubscribe>
List-Archive: <http://mailman.dtnrg.org/pipermail/dtn-interest/>

I will not publicly respond further in this thread.  I think this and
previous messages make my point abundantly clear.  I will continue
discussion offlist, if you'd wish.  Here are some final responses:

On Mon, Feb 07, 2005 at 06:06:32PM +0000, Stephen Farrell wrote:
> 
> >>I can't understand why you continue to ignore the following:
> >>
> >>  Running LTP over a radio link leaves open potential DoS and
> >>  other directed attacks which are worse than jamming and
> >>  many, in fact, almost all, of the practical options for such
> >>  links (802.11b/WEP,BT,GSM) suffer from known security problems.
> 
> I take it you accept this then?
>


No I don't.  I haven't seen any threat model that presents why LTP
should attempt to operate over clearly compromised links.  A sane LTP
implementation can't be effectively DoSed, in any case.

 
 
> I guess my experience tells me that authentication support is a
> requirement for pretty much all protocols. Isn't that also a very
> reasonable guideline?


No.  Authentication is not a requirement (or even a desirable feature)
for a large (and important) set of network uses, eg casual web browsing.


> > Applying
> >this to authentication mechanisms in LTP ... the mere presence of an
> >attacker on a link indicates that it is no longer point-to-point.
> 
> Hang on. Your initial argument against LTP authentication was that
> it could be done by a link layer, and you mentioned GSM/GPRS & BT.
> Now, you seem to be saying that such cases are out of scope.
> So which is it?


I don't follow your question.  I've always said that authentication does
not belong in LTP and that lower (and upper) layers can do this just
fine.  Several rather useful transport protocols (TCP, UDP, DCCP, etc)
exist without any cryptographic authentication mechanisms.  When these
have been needed, they've been provided at other layers.

 
> >Authentication mechanisms in LTP would attempt to maintain a semblance
> >of the designed-for precondition of point-to-pointedness over a
> >compromised link.  
> 
> Not at all. Authentication mechanisms allow an LTP peer to detect
> segment modification/insertion which is possible in the cases
> mentioned.


In which case an attacker would just fully utilize the link with noise.
With or without authentication, LTP can get no useful work done once the
link is compromised.


> > Except for being futile, this is not a bad goal, only
> >somewhat out of scope, given the current lack of a lucid description of
> >even a single use case where an attacker would wish to forge LTP
> >segments.
> 
> Hyperbole again. Honestly, it doesn't help me understand you.


Disagree.

 
> >If particular applications are worried about being attacked by bogus
> >data, then they'll surely have their own end-to-end methods of
> >authenitcating data.  
> 
> I already responded a couple of time wrt the multiple layers
> where security is appropriate I guess.


No one is arguing about the virtues of a multi-layered approach.  We've
all read Saltzer, Reed, & Clark.  What we're talking about here is what
layers a specific feature has merits at.

 
> > LTP need not protect them.  The worst thing, it
> >seems, that an attacker could really do is waste capacity at additional
> >links by spoofing segments that an upper layer would decide to route
> >onwards.  
> 
> DoS is a killer for basically any unattended host, regardless of
> the layer at which it occurs. Turns out that all our experience
> shows that almost all complex systems have DoS opportunities
> all over the place.

LTP itself cannot be DoSed.  There are no resources there, aside from the
segment buffers.  Forcing segment buffers to be maintained indefinitely
is possible with or without an LTP-based authentication scheme.
Resistance is futile.

-Wes

-- 
Wesley M. Eddy
NASA GRC / Verizon FNS
http://roland.grc.nasa.gov/~weddy