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

[Stephen Farrell <[e-mail]>]

Wes,

Yes, I think we've fairly well flogged the arguments. But, being
Irish, its hard to let anyone else get the last word:-)

Wesley Eddy wrote:

> 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.  

Fair enough. I've yet to convince you!

 > A sane LTP
> implementation can't be effectively DoSed, in any case.

That's wildly optimistic, according to my, perhaps jaundiced,
view of IT security.

>>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.

Eh...HTTP digest auth, HTTP proxy auth, HTTP/TLS with forms based
login, HTTP/TLS with TLS-client-auth, various of the many SAML
possibilities. Those are all things that according to you SHOULD NOT
have been *defined*, just because sometimes the same is provided at
another layer, or is not in use. I just can't see that argument
holding water.

>>>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.  

I agree that other layers can do it fine. I disagree that auth. does
not belong.

 > 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.

That is true. However, I could believe that that's largely for
historical reasons and that a TLS-like thing would have been
nice to have integrated with TCP (etc.). However, you do make a
fair point and if you could characterise *why* e.g. TCP is ok
without security primitives, then I'd be interested. I suspect
that the answer would turn out to be largely historical, but
others on this list certainly know better than I would.

>>>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.

Ok. You still don't recognise the difference between jamming and a
directed attack. That's ok, but I still maintain there is a difference.

>>>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.

Can't accuse you of hyberbole there:-)

>>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.  

Ahem. That's plain untrue. Say a session has successfully
gotten XXMB across a deep space link and I then manage to
cancel or corrupt the session via segment insertion from
some (off-path) compromised host (using a relay/repeater
or whatever) inside the Earth station. Wouldn't that be a
DoS? It is in my language.

 > 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.

I think you misunderstand how, at least I, approach DoS - the idea
is to build in mechanisms (e.g. picking sequence numbers at random)
so that its harder to mount an attack (in that case from an off
path attack point).

Stephen.