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

Hi Wes,

Alright, now that I re-read this thread in peace, I seem to understand 
your positions slightly better. I think quite a bit of the disagreement
is because of misinterpretation of terminology, for example, the word
"relay". 

> 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 think there is quite a bit of truth in the above statement. Time and again
we find that link-layer security if at all available, is flimsy, and not
robust enough, etc. 
My personal gut feeling is that security in such technologies get to
be designed by teams of computer engineers/electrical engineers and that
their design team needs people with solid computer security background. [But
then again is a personal "gut" feeling. So ignore it if you disagree with
it. :-) ]

But more often than not you are stuck with hardware or device drivers as the
case may be, that offer flimsy computer security, if at all. But such
devices typically do provide a way of turning off their security mechanisms;
Thus we could turn it off and use a better more robust security mechanism at
a layer above of our choice. This problem, for example, is fairly realistic,
given that it exists atleast with something as prevalent
as 802.11b, bluetooth, etc. For such devices, it is certainly nice to have the
layer above offer robust security primitives. But continuing with (what I
understand as) your line of thought, you seem to suggest that if I were
having a bunch of blue-tooth devices (that seem to offer as good as no
security mechanism) communicating with one another and were worried about
the authentication needs of segments, I should just tunnel all my data over
an ssh connection (utilizing an RSA public/private key infrastructure). 
Sure this can be made to work, but this would probably be an overkill and
might need rewrite of all my applications to do this. In this case, it would
seem ideal to have the layer sitting right above the blue-tooth layer,
over which I have software control, offer robust security. If I was perfectly
happy with the blue-tooth security primitives of course, I shouldn't be
forced to use this security; I agree.

We can still argue on which layer above the raw datalink layer is ideal
for security, where ofcourse individual mileage varies. But such argument is
still not good enough to *not* have robust, optional usage, security
primitives in LTP.

LTP is certainly point-to-point, and of course I agree that quite a lot of
design assumptions of LTP are based on the fact that : 

Segments sent from the sender are received at the receiver in the same order
as sent (if at all received, that is). The only cause of segment loss is
data corruption. - [A] 

Certainly. But I guess you have to remember that LTP is point-to-point in
the way an 802.11b sender and receiver are point-to-point. This is a
reasonable analogy, valid for most LTP deployment scenarios. Everybody gets
to listen to whats going on in an LTP session, and any-one within the
environment may make-up a spoofed up segment purporting to come from the
sender, to the receiver. Sure, any such adversary in the environment may jam
the channel environment. It is an easy low-tech solution, that just needs a
lot of power (in the 802.11b case, for example). But a high-tech and clever
solution is ofcourse to make up an LTP cancel segment and close the session.

Similarly, I think what Stephen really means when he used the term "relay"
is a repeater. Atleast a relay that is operating as a pure repeater. Note
that from a layering perspective, it is a datalink layer relay, and given
that LTP sits right above the datalink, this would and should be transparent
for LTP purposes since condition [A] is guarenteed. 

As another LTP deployment example, consider a network of sensors, basically
802.11b nodes scattered in a lake as with Stephen's research deployment. It
would seem perfectly reasonable to have a mobile 802.11b base-station on a
boat that visits this lake occasionally, to have a protocol stack as below:

   --------
   Bundling
   --------
     LTP   
   -------
     UDP
   -------
     IP
   -------
   802.11b
   -------

Also assume the presence of similar stacks on the lake-bed nodes. 

In this setup ofcourse the entire layer below LTP serves as a datalink that
guarentees condition [A], and LTP is basically being used for its efficient
retransmission properties. Here ofcourse, I am assuming that IP is basically
being used just for its addressing capabilities, and no real routing is
being done when the base-station on the boat talks to each of the nodes.

All that being said, I certainly agree with you in that we need a decent
threat model for our extensions draft. For the first cut, we should atleast
clearly define what kinds of things we are protoecting ourselves against
with the mechanisms we propose. This is a 00 draft after all. More work
needs to be done here, obviously.

I would certainly like to hear what other people in the list think on this
topic; especially the folks researching on DTN security at MITRE.

Thanks guys,
Mani.

On Mon, Feb 07, 2005 at 06:06:32PM +0000, Stephen Farrell wrote:
> 
> Wes,
> 
> Wesley Eddy wrote:
> 
> >On Mon, Feb 07, 2005 at 03:00:55PM +0000, Stephen Farrell wrote:
> >
> >>Wes,
> >>
> >>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?
> 
> >>Can you provide an argument why a protocol to be used in such
> >>a context MUST NOT define authentication primitives? (Which is
> >>the case you're making).
> 
> Ok, you make an argument below. I don't buy it myself.
> 
> >No, that's not at all an accurate interpretation of my position.  I
> >would say that:
> >
> >  A protocol with design considerations as narrow and well-defined as
> >  LTP, SHOULD contain only those mechanisms absolutely necessary for the
> >  functionality of the protocol under the designed-for use cases.  The
> >  protocol SHOULD NOT contain premature optimizations or extensions to
> >  (possibly) satisfy tenuous use cases outside the protocol's
> >  well-articulated design goals.
> >
> >I hope we can all agree that this is a reasonable guideline.  
> 
> I think the language is a bit overblown (e.g. "premature", "tenuous"
> as used above aren't really technical terms are they?), which is not
> what I'd want in a "reasonable" guideline, but I think I agree with
> the sentiment (hard to tell given how its phrased).
> 
> 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?
> 
> > 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?
> 
> Anyway, your statement is not true of any wireless link, e.g.
> microwave is intended to be point to point, but can be eavesdropped
> upon and so of course segments could be inserted too. With a bit of
> effort I'd say optical links would be similarly vulnerable. For
> wired links, an attacker with physical access can generally insert
> segments. I guess its hard to see what kind of like is truely
> point-to-point and invulnerable to segment insertion (maybe
> something protected using wire-speed quantum crypto, but otherwise,
> I'm stuck!). Can you give some examples?
> 
> >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.
> 
> > 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.
> 
> >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.
> 
> > 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. Even more so, for power limited hosts.
> Separately, it also turns out to be fairly easy to take over
> many hosts when you can easily talk to them from the Internet -
> hence the firewall market. Much as I'd like this not to be the
> case, wishful thinking is not the correct reaction. Omitting
> basic security mechanisms from network protocols is a good
> example of such wishful thinking IMO.
> 
> Stephen.
> _______________________________________________
> ltp mailing list
> ltp@irg.cs.ohiou.edu
> http://irg.cs.ohiou.edu/mailman/listinfo/ltp

-- 
"'Beauty is truth, truth beauty,'--that is all
  Ye know on earth, and all ye need to know." - John Keats
____________________________________________________________________

* Manikantan Ramadas * IRG, OU * http://irg.cs.ohiou.edu/~mramadas *
____________________________________________________________________