Re: [dtn] BABs in the SBSP/BSP

["I-Viswanathan, Kapaleeswaran" <[e-mail]>]

Hi Ed

Many thanks for forwarding the mail to the working group. The following are my contributions to the discussions.


1.      Should we continue to have a concept of an authentication block in the bundle security specification?

>> The security objective for having a BAB and BIB are not explicitly stated in [BSP] or [SBSP] (please see references below). For the reasons stated below, I recommend that: (a) BAB is made optional (but not mandatory); and, (b) the security-target specifications for BAB and BIB are altered for efficiency and simplicity of design.



Functionally, BAB verification needs to be performed by all routers and the destination of the bundle. While, only the destination of the bundle needs to perform BIB verification. Thus, BAB is a link-by-link authentication protocol while BIB is an end-to-end authentication protocol.



Therefore, the only security objective of BAB that can be inferred is: to prevent unauthorized injection of packets into a DTN instance. Since authentication needs to precede authorization, BAB provides the authentication hook for subsequent authentication functions. Although such a security objective may be valuable, it (BAB) MUST not be made mandatory. It MUST be an optional, network-level (or, better still, router-level) configuration parameter than can be turned on, if an operator of DTN (or DTN router) wishes to enforce such a policy.



Also, if BAB were to be retained as an optional security protocol (just like the Authentication Header in IPSec [IPSec]), it will be sufficient that the security-target for BAB is only the source EID and Creation Timestamp time fields of the primary bundle.  Today, the security tar-get for BAB is specified [SBSP] to include the entire bundle - this is wastage of processing power and can lead to Denial of Service attacks [KThesis, Chapter 1, Section 1.1] [JAJJK].



Also, it is specified that the security-target for BIB MUST uniquely identify a block within the bundle as either the singleton primary block or the singleton payload block [SBSP]. The security-target for BIB can be alternatively specified to mandatorily include the payload block and optionally the Source EID along with the Creation Timestamp Time fields of the primary bundle. This ensure that BIB can provide message-origin authentication along with message authentication.



The only difference between such a redefined BIB and BAB is that BIB can use cryptography key material shared between the source and destination of the bundle (that is two BPA nodes but not a DTN router). While, BAB can use cryptography key material shared between the sender and receiver of a link - the sender and receiver can be a BPA node or a DTN router.



References:

[BSP] http://tools.ietf.org/html/rfc6257

[SBSP] http://tools.ietf.org/html/draft-birrane-dtn-sbsp-00

[IPSec] http://tools.ietf.org/html/rfc4301#section-3.2

[KThesis] http://eprints.qut.edu.au/61032/1/Lakshmi_Kuppusamy_Thesis.pdf

[JAJJK] http://www.researchgate.net/publication/27463135_Denial_of_Service_Issues_in_Voice_Over_IP_Networks



2.      Is whole-bundle BABs are not used, is there value in having a smaller hop-by-hop block for something like the primary block?
>> Whole-bundle BABs are not useful. As stated previously, the security-target for BAB needs to include only the source EID and the Creation Timestamp time fields of the primary block.

Also, the key management protocol for BAB processing MUST be specified for interoperability purposes. When a DTN operator configures a router or DTN to use BAB, it must be specified that the bundles for carrying the key management protocol messages need not contain BABs so as to avoid a chicken-and-egg scenario, namely: establish cryptography keys for sending valid bundles and send valid bundles for establishing cryptography keys. If we try to circumvent the chicken-and-egg scenario using costly public-key operations, then Denial of Service vulnerability will be induced in the design. Costly cryptography operations are known to be a source of denial of service attacks [KThesis, Chapter 1, Section 1.1]  [JAJJK].

References:

[KThesis] http://eprints.qut.edu.au/61032/1/Lakshmi_Kuppusamy_Thesis.pdf
 [JAJJK] http://www.researchgate.net/publication/27463135_Denial_of_Service_Issues_in_Voice_Over_IP_Networks


3.      What is the practical impact of using authentication to mitigate DOS attacks in a network?

>> Use of costly authentication functions is known to result in DoS vulnerability in networked systems [KThesis][JAJJK].

Best regards
Kapali

From: Birrane, Edward J. [mailto:[e-mail]]
Sent: Tuesday, August 04, 2015 12:31 AM
To: [e-mail]
Subject: [dtn] BABs in the SBSP/BSP

DTNWG,

  Scott, Kapali, and I wanted to forward some existing technical conversation (below) on the SBSP and security for bundles in general, to open the discussion to the DTNWG at large.

  Below are discussions around the following questions:


1.      Should we continue to have a concept of an authentication block in the bundle security specification?

2.      Is whole-bundle BABs are not used, is there value in having a smaller hop-by-hop block for something like the primary block?

3.      What is the practical impact of using authentication to mitigate DOS attacks in a network?

  Comments welcome!

-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: Burleigh, Scott C (312B) [mailto:[e-mail]]
Sent: Thursday, July 30, 2015 2:52 AM
To: Birrane, Edward J.; I-Viswanathan, Kapaleeswaran
Cc: Templin, Fred L
Subject: RE: Query on (Streamlined) Bundle Security Protocol and Bundle Protocol Specification

Okay, I agree that it would be feasible if constrained in this way.  If there's a customer for it, cool.  Still, I'd rather not move in that direction if we don't have to.

Scott

From: Birrane, Edward J. [mailto:[e-mail]]
Sent: Wednesday, July 29, 2015 7:58 AM
To: Burleigh, Scott C (312B) <[e-mail]<mailto:[e-mail]>>; I-Viswanathan, Kapaleeswaran <[e-mail]<mailto:[e-mail]>>
Cc: Templin, Fred L <[e-mail]<mailto:[e-mail]>>
Subject: RE: Query on (Streamlined) Bundle Security Protocol and Bundle Protocol Specification

Scott,

Oh how I deeply want to avoid that madness.

You could, however, have a BAB with a security source and the implied security destination of "whoever received this". At the receiving BPA the BAB is always dispositioned - either the BPA is security-aware and does the associated processing or the BPA is not security aware and drops the block or bundle.  In such a tightly controlled environment there is no looping or nesting or weird boundary cases such as was the case in BSP for PIBs and PCBs.  BABs are also never forwarded by a BPA. If you also specify that a BAB must not be replicated in any fragment you cover the fragmentation cases as well.

Now, whether there is value in doing that from a security perspective is a different question.

-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: Burleigh, Scott C (312B) [mailto:[e-mail]]
Sent: Wednesday, July 29, 2015 10:20 AM
To: Birrane, Edward J.; I-Viswanathan, Kapaleeswaran
Cc: Templin, Fred L
Subject: RE: Query on (Streamlined) Bundle Security Protocol and Bundle Protocol Specification

Except I worry that this would re-introduce the concept of a security destination that is not the bundle destination, and that way lies madness.

The essence of the idea I lifted from Kevin Fall was to simply rely on the convergence layer for all pairwise authentication between topologically adjacent BP nodes, whether provided by TLS over a TCP hop, by a BAB-like wrapper over an LTP hop, or simply by assertion that the ability to use the link itself constitutes sender authentication (due to physical-layer security or whatever).  I think that functionality provides the defense against DOS attack that the BAB design was aiming for.

If we've got an identified requirement for something that goes beyond that (other than the integrity protection provided by the BIBs), by all means let's think about what's needed.

Scott

From: Birrane, Edward J. [mailto:[e-mail]]
Sent: Wednesday, July 29, 2015 6:58 AM
To: I-Viswanathan, Kapaleeswaran <[e-mail]<mailto:[e-mail]>>; Burleigh, Scott C (312B) <[e-mail]<mailto:[e-mail]>>
Cc: Templin, Fred L <[e-mail]<mailto:[e-mail]>>
Subject: RE: Query on (Streamlined) Bundle Security Protocol and Bundle Protocol Specification

Kapali,

  I am as open to building a reduced-scope BAB as I am to removing the BAB completely. The major issue Scott identified with BAB processing was the description of its behavior related to hop-count. In a DTN overlay we could reasonably expect three kinds of nodes: Link-layer-only nodes with no BPA associated with them, BPA-aware nodes with no security, and BPA-aware nodes with security.

  BABs expect to operate between adjacent security-aware nodes in a network. However, there is no practical mechanism for determining when this is and is not the case. When defining a BAB as between two adjacent nodes, it becomes important to understand the specific relationship between most-recent forwarder/transmitter and the current receiver to ensure that the correct authentication keys are used. This is more straightforward at the link-layer and more complex at the bundle layer.

  It is not unreasonable to have a BAB with a reduced scope which encodes the BAB source in the BAB meta-data, but now you have a reduced-scope authentication mechanism that works across many hops which may be logically indistinguishable from a PIB.  I can be convinced that while there is no logical distinction in this case, there may be a useful practical distinction for implementers: namely that along a route one would expect to see MANY BABs (come and go) but only 1 PIB.

-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: I-Viswanathan, Kapaleeswaran [mailto:[e-mail]]
Sent: Wednesday, July 29, 2015 9:30 AM
To: Birrane, Edward J.; Burleigh, Scott C (312B)
Cc: Templin, Fred L
Subject: RE: Query on (Streamlined) Bundle Security Protocol and Bundle Protocol Specification

Hi Ed

Dropping BAB is one strategy. Another strategy is as follows.

1.      Define the objective for specifying BAB clearly

a.      Why is this objective needed? Without this objective what can go wrong? With this objective what will not happen?

b.      It would be useful to explain the objective in terms of authentic and unauthentic bundles.

                                                    i.     For example, can we say that an unauthentic bundle will not travel beyond a single hop (or link)? What does this achieve?

2.      Explore for redefining the scope for BAB protection to be the header of the bundle and not its payload.

3.      Explore options for making BAB an optional structure in the bundle. That is introduce a concept of trusted bundles and untrusted bundles. Bundles with authentic BAB are considered trusted because we know the origin of the bundle.

a.      This is a useful way of separating policy from mechanisms. DTN may only provide mechanisms and the domain of application needs to choose the policy (have BAB for all bundle, have BAB for specified types of bundles, BAB not needed).

I can assist Scott and you in developing the alternative strategy if time is available for such changes and there is an appetite for such changes.

Best regards
Kapali

From: Birrane, Edward J. [mailto:[e-mail]]
Sent: Tuesday, July 28, 2015 7:43 PM
To: I-Viswanathan, Kapaleeswaran; Burleigh, Scott C (312B)
Cc: Templin, Fred L
Subject: RE: Query on (Streamlined) Bundle Security Protocol and Bundle Protocol Specification

Kapali,

  Yes, I completely agree with your reasoning as it applies to a hub-and-spoke topology. In fact, there are several weaknesses with this topology beyond DOS attacks.

  I do not understand the use of a hub-and-spoke topology with a peer-to-peer networking concept (or a challenged/opportunistic network in general). It is much more likely that you are dealing with a mesh network topology with an attacker seeing only a subset of the mesh at any given time.  Said more simply, if you engineer a single-point-of-failure (SPOF) into the network then a DOS will always be able to target that SPOF. If you do not engineer a SPOF into your network then an attacker would need to disable multiple nodes to disable your operations. Authentication at every node in the mesh prevents the spread of such an attack.

  A very good point that you make is that authentication at the overlay might not protect a node without authentication at the link-layer, which is why we are proposing to remove BAB from the (S)BSP and assume authentication is a link-layer service.

-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: I-Viswanathan, Kapaleeswaran [mailto:[e-mail]]
Sent: Tuesday, July 28, 2015 9:42 AM
To: Birrane, Edward J.; Burleigh, Scott C (312B)
Cc: Templin, Fred L
Subject: RE: Query on (Streamlined) Bundle Security Protocol and Bundle Protocol Specification

Hi Ed

The reasoning in your note is: when there is a particular (hub-and-spoke) network topology over which DTN is an overlay, BAB provides DoS protection. Clearly, if DTN were to be an overlay over a peer-to-peer network, then BAB will not provide DoS protection. This may need to be specified in the SBSP, if we do not wish to change the design principles of BAB.

Now I will provide a short proof why even with a powerful-hub-and-spoke model, BAB may not prevent DoS. Let H be a powerful hub protecting weaker spokes, S. There are two cases.


1.      H has a finite buffer space to store bundles that are to be (BAB) authenticated.

2.      H has infinite buffer space to store bundles that are to be (BAB) authenticated.

Case 1: When an attacker fills the finite buffer space in H, then H will need to drop bundles that may arrive when the buffer is full. During that time, when the buffer is full, the attacker has denied access to H for bundles from legitimate spokes, S.

Case 2: The attacker continuously fills the infinite buffer space in H with as many random BAB-bundles. Since H will never drop any bundle, the view of buffer in H will be something as follows: Head(LB1), (AB, ...., AB), LB2, LB3, (AB, .....,AB), LB4,....., where AB is attack bundle and LB is legitimate bundle. Without the attack the view of the buffer will be: Head(LB1), LB2, LB3, LB4, .... In the attack scenario, the attacker has caused denial of service to LB4 by delaying it further than needed or delaying it forever depending on how many attack bundles are in the queue before (say) LB4.

Thus, in both cases DoS is not prevented as claimed in your note.

BTW: The reasoning that I used is in an old NSA document on IP networks that may have been cited in my paper that I referenced in my previous mail. I do not have the reference in my memory any longer.

Best regards
Kapali

From: Birrane, Edward J. [mailto:[e-mail]]
Sent: Tuesday, July 28, 2015 6:32 PM
To: I-Viswanathan, Kapaleeswaran; Burleigh, Scott C (312B)
Cc: Templin, Fred L
Subject: RE: Query on (Streamlined) Bundle Security Protocol and Bundle Protocol Specification

Kapili,

  A quick note: authentication does not prevent a DOS attack on a single machine (we have also in the past spoken of the hypothetical "bundle of death"). However, it does prevent a DOS on a *network* if the entries to the network are the ones providing the authentication services.  For example, in a space network, the ground-to-space entry node may be consumed by the DOS, but the challenged space network behind it would not be.

-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: I-Viswanathan, Kapaleeswaran [mailto:[e-mail]]
Sent: Tuesday, July 28, 2015 8:49 AM
To: Burleigh, Scott C (312B); Birrane, Edward J.
Cc: Templin, Fred L
Subject: RE: Query on (Streamlined) Bundle Security Protocol and Bundle Protocol Specification

Hi Scott:

Again, apologies for delayed response.

Scott >> On the second point: as I recall, the original intent of the BAB was to detect and immediately discard "bad" bundles: any bundle transmitted by a hostile entity (authentication, to guard against DoS attacks) and any bundle that had been modified in any way while en route from one legit BP node to another (integrity check, to guard against man-in-the-middle attacks).  So not just header authentication; the target has always been the entire bundle.

I believe that the original intent for BAB may not be correct. I do not believe that (heavy) authentication mechanisms (such as use of cryptography) can prevent DoS attacks. It is known that authentication does not prevent DoS attacks. The detailed explanation for these assertions are available, for example, in the following paper, which I co-authored.
http://eprints.qut.edu.au/419/1/Reid2004-VoIPDoS.pdf

In order to provide more evidence that (heavy), I present the following papers.
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.69.7881&rep=rep1&type=pdf
"Public-key authentication does not completely protect against the attacks because the authentication protocols
often leave ways for an unauthenticated client to consume a server's memory
space and computational resources by initiating a large number of protocol runs
and inducing the server to perform expensive cryptographic computations."

http://www.giac.org/paper/gcwn/144/ipsec-tutorial/102271 (Page 22, Section 7.5)
"To help prevent DoS attacks, the IPSec
receiver calculates a HMAC for the packet. If the result matches the HMAC the sender
placed in the packet (in clear text) then IPSec proceeds with decrypting the packet. If
the hash values do not match the packet is discarded. This prevents IPSec from
performing expensive decryption."

PS: signature verification and decryption have similar computation complexity. This is the reason or using simple hash algorithms.

Let's apply the above information to DTN. Let us assume that the size of bundles can be arbitrarily long. Then the attacker can generate very long bundles, choose random authentication values for BAB, and flood the receiver. The receiver will attempt to authenticate the long bundles using the random authentication values for BAB. The receiver would just throw away the bundles because with a very high chance the authentication will fail.

Even if the receiver may be a DTN network node, that network node can be overwhelmed. Also, since the authentication failed, the receiver will not be able to black-list any sender. If the receiver does black-list in spite of authentication failure, then the attacker can cause a DoS for the sender by masquerading as the attacker and inducing the receiver to blacklist the sender using the above mentioned attack.

Now, if we are to assume that a lower layer protocol shall efficiently prevent or mitigate DoS attacks for the receiver, then we will realize that it is the lower layer protocol that provide DoS protection but not BAB. In other words, BAB would be redundant.

I believe that BAB provides the same security service as the Authentication Header (AH) of IPSec. It provides hop-by-hop authentication, which is useful when the bundle needs to travel from secure network into an insecure network and back into a secure network before reaching the designated receiver. Thus, it will be useful in the BIBE (bundle-in-bundle encapsulation) use-case.

Even in IPSec, protocol version header of IP packet is essentially unauthenticated. Authentication Header does not  This does not lead to DoS scenarios. In fact, the reason KINK was proposed was because in resource-constrained embedded systems, public-key based key distribution can lead to Denial of service attacks. This is because a Public key (signature or decryption) algorithm is at least 20 time more expensive than a symmetric key algorithm or a hash function.

My submission is to see BAB as a link-by-link authentication mechanism and PAB as an end-to-end authentication mechanism. DoS is usually mitigated by having system level redundancies like having multiple network paths, network throttling, and so on.

Best regards
Kapali


From: Burleigh, Scott C (312B) [mailto:[e-mail]]
Sent: Tuesday, June 23, 2015 5:07 AM
To: I-Viswanathan, Kapaleeswaran; Birrane, Edward J.
Cc: Templin, Fred L
Subject: RE: Query on (Streamlined) Bundle Security Protocol and Bundle Protocol Specification

Kapali, the answer to your first question is no, ION does not currently provide a way to make security policy conditional on key management state.  The information for implementing this functionality is available, but the code doesn't currently do this.

On the second point: as I recall, the original intent of the BAB was to detect and immediately discard "bad" bundles: any bundle transmitted by a hostile entity (authentication, to guard against DoS attacks) and any bundle that had been modified in any way while en route from one legit BP node to another (integrity check, to guard against man-in-the-middle attacks).  So not just header authentication; the target has always been the entire bundle.

The motivation was exactly as you say in point 1 below.  But there has never been a BSP concept of access control, as far as I know; any BP node is always allowed to transmit bundles.  You're not required to process all of the bundles you receive, but the sender is authorized to send then.

If the convergence-layer protocol underlying BP from node A to node B is itself a guarantor of the authenticity of node A (because it's TLS or equivalent) then there's no obvious need for BAB: its intent is served.

If not, then maybe it still makes more sense to provide a convergence-layer plug-in of some sort that does essentially what BAB does, but at the convergence layer.

I think the union of these two addresses all the items in your point 3.

Scott

From: I-Viswanathan, Kapaleeswaran [mailto:[e-mail]]
Sent: Monday, June 22, 2015 2:59 PM
To: Birrane, Edward J.; Burleigh, Scott C (312B)
Cc: Templin, Fred L
Subject: RE: Query on (Streamlined) Bundle Security Protocol and Bundle Protocol Specification

Hi Ed:

>>    So, Node B can receive a bundle without a BAB. The provision for this is given in the SBSP in section "3.3.1 - Receiving BAB Blocks" where it states:
I see this. We now have to see how can the security policy be specified in a machine parseable manner. Since this can affect interoperability, would it make sense to specify the same in the RFC for SBSP?

Again, my question remains: does ION implementation support such selective verification of BAB depending on key management states.

>>   There is some discussion ongoing as to the overall utility of the BAB block.  If BABs are defined as being hop-by-hop (which they are) and if secure networks provide link-layer security (which they do), then what is the benefit of having a BAB at all? Why would we not just use BIB and BCB at the overlay?


1.      DTN bandwidth is highly constrained and, therefore, of high value. Therefore, only authorized entities should be allowed to inject bundles into DTN.

2.      When a bundle is received by Node B, the node needs to verify the claimed origin of the bundle and if the origin is authorized to send bundles.

a.      (Authentication) BAB is useful to verify claimed origins of bundles.

b.      (Access Control) A list of authorized origins will help in determining if an origin is authorized to send bundles.

3.      The question is: since BIB provides information for verifying claimed origin of bundles, why do we need BAB?

a.      This question becomes relevant when:

                                                    i.     Bundle fragmentation is not allowed - when fragmentation occurs BAB is recomputed but not BIB.

                                                   ii.     BAB computation complexity is similar to BIB computation complexity. That is the amount of CPU time and memory needed to process BAB is approximately same as BIM processing.

1.      Typically the security-target of BAB must not be the entire bundle but must exclude payload.

2.      If security-target of BAB is the entire bundle just like BIB, then the question is valid.

a.      The SBSP specifies the  BAB security target to be the entire bundle. https://tools.ietf.org/html/draft-irtf-dtnrg-sbsp-00#section-2.3

b.      The BSP does not specify the target of BAB. https://tools.ietf.org/html/rfc6257#section-2.2

The difference between BAB and BIB may be similar to that between the IP Authentication Header and Encapsulated Security Payload.
https://tools.ietf.org/html/rfc4302

"The primary difference between the integrity
   provided by ESP and AH is the extent of the coverage.  Specifically,
   ESP does not protect any IP header fields unless those fields are
        encapsulated by ESP (e.g., via use of tunnel mode). "

In short, the utility of BAB is purely to authenticate the headers. That is the security-target must not be the entire block but only the headers of the block including the Custody Transfer flags, which are may be expected to change with every hop.

Best regards
Kapali


From: Birrane, Edward J. [mailto:[e-mail]]
Sent: Tuesday, June 23, 2015 1:57 AM
To: Burleigh, Scott C (312B); I-Viswanathan, Kapaleeswaran
Cc: Templin, Fred L
Subject: RE: Query on (Streamlined) Bundle Security Protocol and Bundle Protocol Specification

Kapali,

  As Scott points out, we can also use other mechanisms, such as PKI and DTKA.

Whether or not to add a BAB is a matter of policy. SBSP, for example, defines the structure and processing rules for when a BAB is in place. However, it is the responsibility of Node B to understand whether to require a BAB from Node A.

  So, Node B can receive a bundle without a BAB. The provision for this is given in the SBSP in section "3.3.1 - Receiving BAB Blocks" where it states:

   Nodes implementing this specification SHALL consult their security
   policy to determine whether or not a received bundle is required by
   policy to include a BAB.

 In your scenario, Node B would not require a BAB from Node A until such time as it has exchange sufficient information (either with Node A, or with other nodes via DTKA, or other mechanism) to subsequently expect that node A would be able to add BABs.

  Until such time, note that individual links can have hop-by-hop link-layer security in them.

  A question back to you:

  There is some discussion ongoing as to the overall utility of the BAB block.  If BABs are defined as being hop-by-hop (which they are) and if secure networks provide link-layer security (which they do), then what is the benefit of having a BAB at all? Why would we not just use BIB and BCB at the overlay?

-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: Burleigh, Scott C (312B) [mailto:[e-mail]]
Sent: Monday, June 22, 2015 3:41 PM
To: I-Viswanathan, Kapaleeswaran; Birrane, Edward J.
Cc: Templin, Fred L
Subject: RE: Query on (Streamlined) Bundle Security Protocol and Bundle Protocol Specification

Hi, Kapali.  I am sure that Ed will have additional light to shed on this, but I'll offer one comment.

The ciphersuites for BAB are not defined in SBSP, and I realize that all current implementations of BAB (as far as I know) exercise a ciphersuite based on a shared symmetric key.  But that is not the only (nor even the best, I think) possibility.  If a public key distribution mechanism along the lines of DTKA is in place, then nodes A and B can know each other's public keys long before they ever exchange messages.

If that is the case, then a message sent from A to B can include a hash computed in a one-time symmetric key that is included in the message, along with a hash of the symmetric key that is computed in A's private key.  On reception of the message, node B can validate the symmetric key's hash in the public key of A and then use that validated symmetric key to validate the message hash, ensuring that the message was sent by A and was not modified en route.

Scott

From: I-Viswanathan, Kapaleeswaran [mailto:[e-mail]]
Sent: Monday, June 22, 2015 12:19 PM
To: Burleigh, Scott C (312B); Birrane, Edward J.
Cc: Templin, Fred L
Subject: Query on (Streamlined) Bundle Security Protocol and Bundle Protocol Specification

Hi Ed and Scott

While reading the BSP and SBSP along with the specification for BIBE (Bundle-in-Bundle-Encapsulation) and the Bundle Protocol Specification, I have a doubt about the BAB processing logic. I shall present my understanding first followed by the doubt. Please can you clarify my doubt?


1.       BAB is a link-by-link authentication mechanism. If Node A needs to send a bundle to Node C through B, then:

a.       Nodes A and B must have a shared cryptography key for processing BAB; and,

b.      Nodes B and C must have a shared cryptographic key for processing BAB.

2.       Suppose that a new Node is joining the DTN. Let us say that Node A is joining the DTN. There are two ways to ensure that the condition mentioned in Point 1 (above) is satisfied before Node A can successfully send a bundle.

a.       Node A and Node B are configured with a pre-shared key before Node A joins the DTN.

b.      Node A and Node B engage in a cryptographic protocol for establishing a shared key.

3.       In order to establish the shared cryptographic key, Node A will need to send Node B at least one bundle without a BAB.

4.       Is it possible in DTN for a node to send a bundle without a BAB to a node for processing?

a.       We can assume that the sending node has a valid cryptographic token (or certificate) from a trusted entity that can be processed (or verified) by the receiving node.

b.      But the sending node may not be able to form a valid BAB as yet until the receiving node accepts the first bundle that it had sent.

5.       If such (as mentioned in Point 4) is possible in DTN, which provision should I read in the specification that allows for such a possibility?

a.       Does ION support such a possibility?

Looking forward to your response.

Many thanks.

Best regards
Kapali