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

[Scott Burleigh <[e-mail]>]

Wesley Eddy wrote:
> On Mon, Feb 07, 2005 at 11:52:55AM +0000, Stephen Farrell wrote:
> 
>>>>>Virtually all of LTP assumes that a link strictly
>>>>>connects 2 hosts, and that a path is simply one hop across that link.
>>>>
>>>>I'm not sure where that "strictly" comes from, but I guess
>>>>its a matter of emphasis more than anything else.
>>>>
>>>
>>>Take a look at the motivations document:
>>>"""
>>>  In contrast, LTP is a protocol for "point to point" reliability on a
>>>  single link: traffic between two LTP engines is expected not to
>>>  traverse any intermediate relays.
>>>"""
>>
>>So where's it say "strictly"? Must get better glasses:-)
>>
>>How you'd "expect" a protocol to work in nominal mode and what
>>you ought to protect against when there's a potential adversary
>>are not the same.
> 
> To me, the motivations draft seems to pretty explicitly state that any
> environment but a single point-to-point link is out of the potential
> deployment space for LTP.  The protocol includes several design
> assumptions that are based on this property, and would cause it to behave
> rather poorly if this condition is not met.  A single point-to-point link
> is not only the nominal operating environment, but the *required* one.
> Since we seem to have different interpretations here though, perhaps
> others can help obtain consensus on this.

Wes, you are perfectly correct in saying that LTP is designed to be run on point-to-point links and that a number of its design principles assume that this is how it is deployed.  After all, it is principally intended to be run over extremely long R/F links among interplanetary spacecraft and ground stations.

Saying that this is the *required* operating environment is a bit of an overstatement, though.  I don't think there's anything in the text of the spec that prohibits use of the protocol under conditions in which it might not (or might, depending) behave efficiently, and we wouldn't have any way of enforcing that kind of prohibition anyway.

People are going to do what they want to do, and often for perfectly good reasons that we didn't happen to think of in advance.  If LTP proves useful in some environments, I can imagine some experimentation with it in others.  Some of those experiments will not be successful, but perhaps others will.

One example: from LTP's point of view, an underlying TCP connection over the Internet looks a lot like a single, very clean point-to-point link.  Data arrive in transmission order, so the behavioral assumptions that LTP relies on are met.  It could well be argued that there's no good reason to run LTP on top of TCP, but it seems possible to me that someone could eventually construct a plausible ops concept along these lines; in that event, you might have security considerations to address and yet might not want to run a VPN.

> To me, it seems that the need, or lack of need, for authentication
> mechanisms is wholly dependant on how we clarify this design goal.  If
> your interpretation is favored (multiple hops and shared-links allowed),
> it seems like there would be several other issues to contend with, eg:
> dealing with segment reordering, developing some CC mechanisms (BCP re
> RFC 2914), etc.

Sure, a host of other issues come up, though I think some of them are relatively tractable: TCP/IP in the Internet already does congestion control, for example.

I personally am not putting a lot of effort into LTP security, partly because I'm inclined to think that DTN bundling security above it will be sufficient, but largely because I am very far from being an authority on security issues and am in any case not very good at predicting the future.  Although I wouldn't want the security measures Stephen is proposing to be mandatory elements of the core LTP protocol, as optional extensions I think they can't do any harm and in some cases they might well do a lot of good.

Scott