Subject: Re: [dtn] SBSP Goals and Objectives

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Sat, 17 Jan 2015 15:55:58 +0000

Ed, I absolutely would not sacrifice authentication; I think it is essential to the operational deployment of DTN.  But I disagree that requiring non-security-aware nodes to discard BABs constitutes a sacrifice of authentication.

If a BPA attaches a BAB before knowing which node will receive the transmitted bundle, doesn't it run the risk of attaching the wrong BAB (i.e., a BAB computed using the wrong key)?

Doesn't this imply that the BAB can only be attached at the moment when the bundle is about to be transmitted?

If so, doesn't that cover the discussion of Case 3 below?  At the time the BPA is about to transmit the bundle it determines that the node to which the bundle will be transmitted is non-security-aware, so it simply doesn't attach a BAB.

This isn't a systemic sacrifice of authentication.  It is a realistic determination that authentication over this hop is impossible.  That impossibility may or may not be due to an error in network management, but I don't think it's the responsibility of the security protocol to defend against such errors.

The sending BPA cannot, in the general case, attach a BAB that will be validated by the next security-aware node beyond the node that the bundle will be directly transmitted to, because in the general case it has got no idea which node that will be.  It can only know this by having comprehensive foreknowledge of the path the bundle will take, and most DTN routing systems don't provide that comprehensive foreknowledge.

Committing to that sort of structure reintroduces the concept of a security destination in SBSP - an implicit rather than explicit security destination.  It re-couples security and routing, which is exactly where the original BSP went wrong.

None of this is to say that a bundle forwarded through non-security-aware nodes can't be trusted: we can always attach BIBs that cover the primary block, payload block, etc.  But I think stretching the BAB to provide this capability would be a mistake.

Scott

From: Birrane, Edward J. [mailto:[email-masked]]
Sent: Saturday, January 17, 2015 6:32 AM
To: Burleigh, Scott C (312B); [email-masked]
Subject: RE: [dtn] Proactive Fragmentation, was: Internet Draft for Bundle Security

Scott,

  I am sorry if I wasn't clear in my last e-mail. In Case 3 and Case 4 the bundle should fail to authenticate and the receiving security-aware node should have the option to drop the bundle. The statement in Section 2 "BABs operate between topologically adjacent nodes" should be clarified to something like:"BABs validate between topologically adjacent security-aware nodes" as it is ambiguous what it means for a BAB to "operate" anyway...

  If we allow non-security-aware nodes to discard BABs (i.e. sacrifice authentication), we lose the ability to detect issues in the bundle.

 Consider Case 3 again. Case 3 can occur when a BPA thinks at bundle creation time the next hop is to SN3 so it adds a BAB and then, later, at bundle transmission time, the topology has changed and the next hop is now to N2. In this situation true hop-by-hop authentication is now impossible, so we can either sacrifice authentication or sacrifice the bundle.

  If we sacrifice authentication:

  Let an attacker change the bundle between SN1 and N2. N2 removes the BAB. SN3 receives the bundle from N2. SN3 cannot have a policy of requiring BABs from N2 since N2 is not security aware, so SN3 does not reject the bundle, which is then processed by SN3. That might be bad.

  Sacrificing authentication prevents two important pieces of information from getting to SN3: (1) that the previous "security-aware" hop was SN1 and (2) that a BAB signature was ever in the bundle.  If SN3 had *either* piece of information it could detect a problem and reject the bundle.

  So is authentication a nit which artificially prevents bundles from flowing or is it a necessary first-line defense in a contested overlay?

  My intuition is that it depends on the network and is likely a function of the stability of the topology. Hence, the thought that allowing non-security-aware nodes to remove BABs should be a matter of policy and not mandated in the specification. A security best-practices document could explain the pros and cons of the various approaches.

-Ed

________________________________
From: dtn <[email-masked]<mailto:[email-masked]>> on behalf of Burleigh, Scott C (312B) <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, January 15, 2015 7:07 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [dtn] Proactive Fragmentation, was: Internet Draft for Bundle Security

So, Ed, does the validity of case 3 mean that the statement in section 2 that "BABs operate between topologically adjacent nodes" is incorrect and should be revised?  Since SN1 and SN3 are not topologically adjacent?

I again suggest that everything becomes much simpler, without loss of generality, if we exclude cases 3 and 4 by setting the "Discard block if it can't be processed" flag in all BABs.  Is there a downside to this that I am not spotting?

Scott

From: Birrane, Edward J. [mailto:[email-masked]]
Sent: Thursday, January 15, 2015 3:07 PM
To: Burleigh, Scott C (312B); Amy Alford
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [dtn] Proactive Fragmentation, was: Internet Draft for Bundle Security

Scott, Amy,

  We left this open in the spec. From 2.4:

"The block processing control flags value can be set to whatever
      values are required by local policy.  Cipher suite designers
      should carefully consider the effect of setting flags that either
      discard the block or delete the bundle in the event that this
      block cannot be processed."

  I think the specification is ambiguous, but perhaps in a different manner than discussed. I.e., I claim Case 3 below is the ambiguity whereas I believe you are claiming Case 4 below is an ambiguity.

  First, some definitions.  A validated BAB means that a bundle was received, without modification, from the (topologically adjacent) BAB security source. When not asserted, the security source is presumed to be the BPA that transmitted the bundle to the receiving node.  The following convention may help when describing, textually, node topologies: SN# refers to a security-aware bundle node (SN1, SN2, etc...) and N# refers to a non-security-aware node(N1, N2, ...). Prepending an F_ to the label implies the node will fragment the bundle (F_SN1, F_N2, etc...).

  I think (at least) 4 cases are worth mentioning here.

- Case 1: SN1 -> SN2
- Description:  Two security-aware adjacent nodes exchange a bundle with a BAB.
- Expectation: Absent malice, the BAB validates.

- Case 2: F_SN1 -> SN3
- Description: Two security-aware adjacent nodes exchange a bundle which is first fragmented. A BAB is added to each fragment and each fragment is authenticated on receipt.
- Expectation: Absent malice, each fragment gets a BAB at F_SN1 which authenticates at SN3 and is then removed prior to re-assembly or forwarding.

- Case 3: SN1 -> N2 -> SN3
- Description: Unbeknownst to SN1, the next hop will be to N2 which passes the bundle with BAB on to SN3.
- Expectation: The BAB should fail to validate. This naturally occurs if N2 changes anything in the bundle, or if SN3 uses N2's identity when processing the BAB signatures based on the cipher suite. However, there is a case where N2 does not change the bundle and SN3 pulls the identity of SN1 from the security source option in the BAB itself and successfully validates the bundle.

- Case 4: SN1 -> F_N2 ->SN3
- Description: A bundle with a BAB routes through a non-security-aware node which fragments the bundle. At least one BAB remains with at least one fragment and is received by SN3.
- Expectation: SN3 fails to validate the BAB and the bundle is dropped. The bundle was modified between its security source and the next hop. By definition, it should not authenticate.  Removing the BAB at F_N2 we subvert authentication... consider a malicious F_N2.

So, to answer Amy's question, if I receive a fragment with a BAB, I try and validate the fragment using the BAB.

- If the BAB validates, the BAB was meant for the fragment and I continue processing the fragment.

- If the BAB fails to validate, there are two possibilities: (A) The BAB was meant for the fragment and the fragment was modified en-route, or (B) the BAB was meant for some superset of the fragment. Either way, the bundle has clearly been modified since leaving the security source and we should proceed with caution by considering the fragment not authenticated and handled in accordance with policy.

-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

From: dtn [mailto:[email-masked]] On Behalf Of Burleigh, Scott C (312B)
Sent: Thursday, January 15, 2015 2:19 PM
To: Amy Alford
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [dtn] Proactive Fragmentation, was: Internet Draft for Bundle Security

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]<mailto:[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]<mailto:[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]<mailto:[email-masked]>]
Sent: Wednesday, January 14, 2015 2:10 PM
To: Burleigh, Scott C (312B); [email-masked]<mailto:[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<tel:443-778-7423> / (F) 443-228-3839<tel:443-228-3839>

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