Re(7): [dtn-interest] "security destination"

[Lloyd Wood <[e-mail]>]

At Saturday 13/10/2007 10:24 -0400, Peter Lovell wrote:
>Hi lloyd,

hi Peter - inline below.

>On Fri, Oct 12, 2007, Lloyd Wood <[e-mail]> wrote:
>
>>At Friday 12/10/2007 15:42 -0400, Peter Lovell wrote:
>>>This discussion is indeed helpful.
>>>
>>>Parts are turning, though, on semantics and definitions so I'll add a
>>>few thoughts.
>>>
>>>Stephen views the suggestion as "routing" and I think that's too narrow.
>>>It can be viewed that way but is not quite the same. 
>>>
>>>It's worthwhile to note, as Susan mentioned, that the push/pop
>>>suggestion does not *add* a new pathing requirement. That has already
>>>been done by the use of security-destination fields in security blocks.
>>>The suggestion is not adding the path requirement but is just an
>>>implementation mechanism to help make the requirement work, and get
>>>bundles properly to their destinations. If we don't want to have such a
>>>pathing requirement then the solution is to disallow security-
>>>destination. If there are security-destinations then there's a path
>>>requirement. It's that simple. Choose one.
>>
>>What if the specified security destination is the same as the final endpoint?
>>Using the security destination in that way with multiple nested popping at
>>the same destination avoids imposing any pathing requirement, imo; you
>>can use a security destination without a path requirement.
>>
>>This could allow security 'tunnelled' in a separate reliability wrapper, as is
>>commonly done by reliable protocols - with both the error detection 'tunnel'
>>and the inner encryption being removed at the final endpoint.
>>Previously suggested on in [1].
>>
>>(Looping could be addressed with a TTL/hopcount mechanism.)
>>
>>L.
>>
>>[1] http://mailman.dtnrg.org/pipermail/dtn-interest/2007-September/002917.html 
>
>
>If the security destination is the same as the final bundle destination
>then it could work that way.
>
>However you and others have described scenarios where various nodes have
>limited ability, such as 
>>My understanding is that most intended uses of DTN nodes 
>>are for embedded nodes -- that is, nodes not capable of 
>>running Windows.
>Nodes such as these might not have the necessary capabilities.

My take here is that such embedded nodes will want reliable delivery of data.
The only current way to get that reliability and resistance to introduced errors
with DTN protocols (bundle and LTP) is to implement the security frameworks
and reuse security for reliability (outlined in the LTP optional extensions draft
and in the irtf-dtnrg-bundle-checksum draft.)

As you say, such nodes likely won't have the necessary horsepower/resources to
implement the security frameworks. Yet, they do need reliable delivery, so likely
won't look to DTN protocols for their needs. I think this is a missed opportunity
for DTN, which is aimed more at the 'high end' of processing power.


>In addition, network configurations using an insecure dtnet to connect
>two secure subnetworks may wish to super-protect the traffic between the
>gateways just to make it look uniform, in addition to any end-to-end
>protection there might be. The keys and ciphersuites used might exist
>only at the bastion gateways, and perhaps the storage and processing
>power too.

Yes, that problem had given me pause for thought earlier.
Let's examine that scenario in more detail.

A - G1 - C1 - C2 - C3 ... Cn - G2 - B

A needs to communicate with B via security bastion gateways G1
and G2. The private DTN networks that A and B reside in are
connected by a carrier network C, with multiple hops between
G1 and G2. A and B are communicating via the bundle protocol.
It's a DTN network, so connectivity is intermittent at best.

Now, A and B don't implement security per se, but do want to
ensure reliable communication between them, so they have to
have an end-to-end checksum. In the bundle protocol, such a
checksum can only get implemented via the bundle security
protocol, via either a private key or via an known public-keyed
or insecure method outlined in irtf-dtnrg-bundle-checksum-00.

G1 and G2 implement more security, so they add a(nother)
security layer.

Now, when G1 hands a bundle to C1, the first node in the
third-party carrier network, C1 has to know that the bundle it has
just been handed is actually not corrupted and worth expending the
effort on forwarding across the carrier network C to G2.

But C1 doesn't have G1's private keys, so it doesn't know about the
worth of the bundle content that it has just been handed, which
contains opaque sections of bits. Errors in these sections can't be
detected. Another bundle checksum is needed - one that G1 has
computed and C1 can use to validate the bundle.

Each node has this problem - 'is the bundle I've just been handed
even worth forwarding on'? Thus, a reliability checksum needs to be
added by G1 outside the encryption, to allow verification by each node
of C that Ck has received the bundle correctly from Ck-1, and is actually
going to forward something that won't just be discarded at G2, and, if
discarded there, should have been discarded much earlier to conserve
network resources.

Conserving network resources is pretty important for bundle networks -
unlike the terrestrial Internet, you can't just send on the corrupted frame
to the endnode to finally detect the problem, discard the frame, and
expect resends to take care of it. (There's a weak analogy with ATM
early/partial packet discard here, as far as conserving resources goes.)

Unlike the Internet, the cost of delivery is higher; there may be no chance
of a resend at a late point of error detection as nodes are no longer
connected, though the chance of a resend earlier when e.g. C1 and C2
are still talking may be possible. But for that local resend to work, C2 needs
to be able to check the validity of the bundle it receives and detect errors.
As the bundle content is encrypted with G1's key which C doesn't have,
another checksum is needed around that.

This reliability check for third-party carriage of encrypted content is quite
important, given sparse resources in bundle networks. C needs a reason to
know that this bundle is worth carrying, rather than just drop it as encrypted
noise it can't check in favour of its own bundles that it can decode, check or
parse for errors, and G2 wants to receive a bundle known to be error-free.

(We have talked about this in the security considerations of
draft-irtf-dtnrg-bundle-checksum-00, which outlines the drawbacks to
implementing the approach in draft-irtf-dtnrg-bundle-checksum-00.)

So, the final picture looks like this:

A - G1 - C1 - C2 - C3 ... Cn - G2 - B
A ------- e2e reliability  -------- B
    G1 ---- added security --- G2
    G1 -- subnet reliability - G2

There's three layers there. Pathing is used because the (outer G) security
destination is different. The security destination G needs to implement
push-pop to support the outer reliability checksum that is needed so that
C can recognise that all of G's content, including the encrypted content,
is transferred correctly, and do resends internal to C nodes if necessary.

Does the BSP as-is cover this scenario?

(An alternative would be mandate that the convergence layers implement
some sort of checksum over bundle payloads, which covers each hop. But
that is weaker than the subnet checksum, as it doesn't cover programming
errors or single event upsets in the nodes, and recomputing a checksum 
at each node actually takes more resources overall. A single subnet
checksum is far preferable. Reliability is best implemented top-down, not
bottom-up, in accordance with the end-to-end principle.)


>So although the scheme you describe will work, BSP has already included
>extended capability allowing intermediate security destinations. My
>intent is to make that work reliably, rather than making more extensive
>changes to BSP.

'reliably' has its own semantic connotations, of course. Here, I'm using it to mean
'without errors introduced in transmission or within a bundle node'.

cheers,

L.

>Regards.....Peter