Subject: Re: [dtn] Proactive Fragmentation, was: Internet Draft for Bundle Security

From: Stephan Rottmann <[email-masked]>
Date: Sat, 17 Jan 2015 00:38:18 +0100

-------- Ursprüngliche Nachricht --------
Von: "Burleigh, Scott C (312B)" <[email-masked]> 
Datum: 16.01.2015  20:03  (GMT+01:00) 
An: Amy Alford <[email-masked]> 
Cc: [email-masked] 
Betreff: Re: [dtn] Proactive Fragmentation, was: Internet Draft for Bundle Security 
 
Right, that’s more or less the question I was asking at the end of my last email – what’s the downside of not supporting that use case?
 
I think it’s entirely valid to assume the coexistence of security-aware and non-security-aware nodes in a network, and the sort of bounded-subnetwork scenario I was describing might be an example.  In that case, sure, a security-aware node that is wholly inside the network might not require BABs from its neighbors but it might authenticate a bundle payload sent by a node that’s outside the network by verifying its PIB.  That doesn’t require support for passing a BAB unchanged through a non-security-aware node, though.
 
Part of what bothers me about the A-B-C-D scenario where A and C are security-aware, B is not, and C uses the BAB attached by A to authenticate bundles forwarded by B is that it seems to re-introduce dependency on routing into security: what if B decides to route to D through E instead of through C?  If BABs are using symmetric keys (not a foregone conclusion, but it’s what has been implemented so far), how does A  know which key to use in building its BAB?  Does it now have to go back to attaching BABs for all possible nodes that the bundle might get forwarded through on its way to D?  I think this goes a long way toward unraveling the simplification that we were aiming for with SBSP.  Can’t we please just Not Do It?
 
Scott
 
From: Amy Alford [mailto:[email-masked]] 
Sent: Friday, January 16, 2015 10:33 AM
To: Burleigh, Scott C (312B)
Cc: [email-masked]
Subject: Re: [dtn] Proactive Fragmentation, was: Internet Draft for Bundle Security
 
I think I didn't ask the question I meant to.  I want to know if there's a use case for BAB passing unchanged through a non-security aware node and then being accepted at the next hop.  
 
6257 clearly assumed that there were security aware and non-security aware nodes coexisting in a network and that security aware nodes might route data between themselves through non-security aware nodes.  This seems reasonable.  The implicit assumption seems to be that you might want to require BAB between all the security aware nodes.  I don't see any reason to assume that all nodes who happen to have BSP implementations also share keys with each other.  My sense is that if you want to require some kind of authentication in a heterogeneous network, you're going to use PIB (possibly with a symmetric key based ciphersuite).
 
The use case I see for BAB is in a network where you control the whole network and all nodes are security aware and share keys.
- Amy
 
On Thu, Jan 15, 2015 at 3:16 PM, Burleigh, Scott C (312B) <[email-masked]> wrote:
I think you might do this by configuring the gateways into the sub-network to require BABs on all bundles  forwarded from nodes outside the sub-net but not on bundles forwarded from nodes inside the sub-net.  It would be hop-by-hop authentication, but only at the boundary and only on the outer surface of that boundary.
 
Scott
 
From: Amy Alford [mailto:[email-masked]] 
Sent: Thursday, January 15, 2015 11:27 AM

To: Burleigh, Scott C (312B)
Cc: [email-masked]
Subject: Re: [dtn] Proactive Fragmentation, was: Internet Draft for Bundle Security
 
Maybe that was the flag I was thinking of.  Does anyone have a use case in which non-security aware routers are interspersed with routers that want to do hop-by-hop authentication?  
 
I can see wanting to build a sub-network that was closed to traffic originating elsewhere, but which also routes bundles across an open network.  In that case, it isn't really hop by hop authentication.  I think PIB would solve that.
- Amy
 
On Thu, Jan 15, 2015 at 2:18 PM, Burleigh, Scott C (312B) <[email-masked]> wrote:
I wrote this looking only at the SBSP draft, which says in 3.3.1 “A BAB received in a bundle MUST be stripped before the bundle is forwarded.”  I think this is perhaps a little ambiguous. Strictly speaking, as written it applies only to security-aware nodes, but I thought the intent was that it ought to apply universally: section 2 says “BABs operate between topologically adjacent nodes”, and that principle would be violated if security-aware node C received a bundle forwarded by non-security-aware node B with a BAB attached by security-aware node A.
 
We could easily preserve the principle by requiring that the “Discard block if it can’t be processed”  flag be set in all BABs.  The draft doesn’t say this, though, so maybe I’m mistaken.
 
However, the fact that the draft doesn’t require that bundles with BABs have the “do not fragment” flag set does make more sense if BABs are supposed to be stripped: the flag isn’t needed, because at the time you’d be considering fragmentation the bundle would no longer have a BAB.  Then, once the fragmentation has happened (if it has happened), you can safely attach a BAB to each fragment.
 
“The decision to fragment a bundle MUST be made prior to adding authentication to the bundle.  The bundle MUST first be fragmented and authentication applied to each individual fragment.”  (section 3.4)
 
On the other hand, you are right that the draft says “If a bundle with a BAB is fragmented by a non-security-aware node, then the entire bundle must be re-assembled before being processed to allow for the proper verification of the BAB.”  On reflection, I think this is an inconsistency in the spec: we really never want that condition to arise, do we?  Everything becomes way simpler if we just require that the “Discard block if it can’t be processed” flag be set in all BABs.
 
Scott
 
From: Amy Alford [mailto:[email-masked]] 
Sent: Thursday, January 15, 2015 10:12 AM
To: Burleigh, Scott C (312B)
Cc: [email-masked]
Subject: Re: [dtn] Proactive Fragmentation, was: Internet Draft for Bundle Security
 
If a non-security aware node receives a BAB, there's no mandate that they remove it.  I expect them to forward it and set the "block was forwarded without processing" flag. 
 
In SBSP, I thought we decided that bundles with BAB blocks must have the "do not fragment" flag set.  I don't see that in the draft.  It says first fragment, then BAB.  It also says that non-security aware nodes might fragment after BAB anyway, and in that case, reassemble before validating.  I'm trying to convince myself that receivers can distinguish whether they validate then reassemble or reassemble then validate every time.
- Amy
 
On Thu, Jan 15, 2015 at 11:36 AM, Burleigh, Scott C (312B) <[email-masked]> wrote:
I think one aspect of SBSP is especially relevant to this conversation.  SBSP removes “security destination” from the security block structure. (The rationale for this is too lengthy to go into here but, for example, it eliminates the possibility of conflicting security destinations in different blocks mandating routes that make no sense.)  Instead, all security destinations are implicit.  The security destination of every block other than the BAB is the destination of the bundle.  The security destination of the BAB is always simply the node that receives the bundle, in any hop-by-hop transmission, and the security source of the BAB is always the node that sent the bundle over that hop.
 
This eliminates one of the problems Amy mentioned earlier, the possibility of fragmentation occurring after a BAB block is added but before it is verified (because there is a non-security-aware router between a BAB security source and BAB security destination).  By definition, in SBSP the BAB security destination always receives the bundle directly from the BAB security source.
 
Of course it is still possible for the receiving node (the BAB security destination) to be non-security aware and for it to fragment the received bundle.  But at that point the BAB that accompanied the received bundle has been stripped off; the receiver(s) of the fragments will simply receive bundles lacking BABs.
 
Scott
 
From: Birrane, Edward J. [mailto:[email-masked]] 
Sent: Wednesday, January 14, 2015 2:10 PM
To: Burleigh, Scott C (312B); [email-masked]
Subject: RE: [dtn] Proactive Fragmentation, was: Internet Draft for Bundle Security
 
….
 
- RFC6257 has several issues with fragmentation. SBSP may solve some or all of them.
 
-Ed
 
---
Edward J. Birrane, III, Ph.D.
Embedded Applications Group Supervisor
Space Exploration Sector
Johns Hopkins Applied Physics Laboratory
(W) 443-778-7423 / (F) 443-228-3839

_______________________________________________
dtn mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dtn