Re: [dtn-interest] Bundle Authentication and Fragmentatoin

Pardon me - I forgot there were no minutes. Sorry about that.

The DTNRG met at the IETF in Minneapolis and Susan presented on DTN security, including BAH which then (and now I guess) only authenticated headers and not payload. I guess her slides are on the DTNRG site somewhere.

It was pointed out that this contradicts the stated requirement that DTN security is mainly about protecting the DTN - it allows a node (who's not even a DTN router, just any old intermediary) to insert bogus fragments or at least to increase the length of fragments, or even if the length is known to modify the payload bytes. I guess that's what re-started all this discussion.

Stephen.

Matt Bradbury wrote:

> Stephen Farrell wrote:

>>
>> Wasn't this the position pre-Minneapolis, which caused
>> (justifiable) concern in the audience?
>>
>> Stephen.

>>
>> Scott Burleigh wrote:
>>
>>> Matt Bradbury wrote:
>>>
>>>> I've been watching the ebb and flow of this conversation and see 
>>>> that re-active fragmentation with bundle authentication is just 
>>>> going to be a mess and probably never work quite right, too many 
>>>> edge cases, too many situations where re-transmitting is easier than 
>>>> waiting, etc.  But most of these problems are due to the fact that 
>>>> Bundle Authentication is being applied to the whole Bundle.
>>>>
>>>> What if Bundle Authentication was only for the headers, not the 
>>>> entire bundle?
>>>> Advantages:   Re-active fragmentation will work just fine, since 
>>>> we're only authenticating the headers.
>>>>   Different fragments of a re-active fragmentation can take 
>>>> different routes.
>>>>
>>>> Disadvantage:
>>>>   Possible man in the middle insertion of bad data.  Though I think 
>>>> this can be solved at the endpoints using the Payload Security 
>>>> header, and can be detected by intermediate agents by checking for 
>>>> duplicate bundle headers.
>>>>
>>>> Thoughts?  Other advantages and disadvantages?
>>>
>>>
>>>
>>>
>>> I haven't been able to keep up with this thread, so it is likely that 
>>> I am missing some key points that would change my thinking.  But I 
>>> really like this approach.  It's true that we wouldn't be able to 
>>> detect alteration of payload until reassembly and validation against 
>>> the PSH, but could we maybe live with that so long as the 
>>> man-in-the-middle attack didn't threaten the network by injecting a 
>>> lot of additional (bogus) payload?  I'm thinking we could guard 
>>> against the latter somewhat by including original payload length in 
Do you need help?
In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software:
Learn more about Pantek's Technical Support offerings
Place an order for 24/7/365 Technical Support here
Learn more about Pantek, who we are, and what we do
Chat with a Live Operator
Related mailman.dtnrg.org Links
dtn-interest
Request more information about Pantek
>>> one of the end-to-end immutable headers rather than in the Fragment 
>>> header, and ditching bundles with payload length in excess of that 
>>> value.
>>>
>>> Scott
>>> _______________________________________________
>>> dtn-interest mailing list
>>> dtn-interest@mailman.dtnrg.org
>>> 
http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>>>
>>>
>> _______________________________________________
>> dtn-interest mailing list
>> dtn-interest@mailman.dtnrg.org
>> 
http://mailman.dtnrg.org/mailman/listinfo/dtn-interest