[dtn] AD review of draft-ietf-dtn-bpsec-10

[Magnus Westerlund <[e-mail]>]

Hi,

 

I have now done my AD review of draft-ietf-dtn-bpsec-10. I want to point out
that I am going to ask about the reasons behind certain choices in the
document. Note the intention here is not to change what your specified  but
to understand the choices made. 

 

1.	Section 1.2: 

   It is expected that separate documents will be standardized to define

   security contexts and cipher suites compatible with BPSec, to include

   those that should be used to assess interoperability and those fit

   for operational use in various network scenarios.

 

As the WG actually have one example specification for a security context and
cipher suits, it would be good to reference this so that people realize that
it exist and can be looked at in parallel. 

 

2.	Section 1.4: I am missing a term for the receiver / target either if
that is any holder of the security context or an intended bundle receiver,
in other words the peer to security source. 

 

3.	Section 3.1: 

 

      The BIB is used to ensure the integrity of its plain-text security

      target(s).  The integrity information in the BIB MAY be verified

      by any node along the bundle path from the BIB security source to

      the bundle destination.  Security-aware waypoints add or remove

      BIBs from bundles in accordance with their security policy.  BIBs

      are never used to sign the cipher- text provided by a BCB.

 

This is only part of a conflict between the order between BIB and BCB
processing and the possibility for a node along the Bundle path to verify
the integrity of parts of the bundle. So my thoughts here is that bundle
sender has two security contexts. One with the receiver that it will use to
secure the BUNDLE Payload and other Blocks that are of end-to-end nature and
not needed on path. Then I will have another security context that a set of
the bundle forwarding nodes share so that they can verify the bundle being
sent. However, to my understanding this is not possible as any BIB using the
second context can't use encrypted payload block as its input. 

 

So although the documents talks about this, it appears to have limited
utility. Any comments about this limited utility? 

 

4.	Section 3.2:

  Security operations in a bundle MUST be unique; the same security

   service MUST NOT be applied to a security target more than once in a

   bundle.

 

This uniqueness requirement, isn't this missing a dependency on security
context? To me there appear that being able to use more than one security
context has some benefits, or is it making things to complex, or are there
other reasons? 

 

5.	Section 3.6: 

Security Context Flags: 

 

What is the meaning of the Reserved bits? What should the sender and
receiver do with these bits. Can they be assigned in the future? 

 

6.	Section 3.8:

      The Security Context Id MUST utilize a confidentiality cipher that

      provides authenticated encryption with associated data (AEAD).

 

Why is AEAD a requirement? If the requirement is that no confidentiality
without integrity, then that can be stated in an other way than requiring
AEAD. 

 

7.	Section 3:

 

Looking at the BIB and how it is structured and how the signature is created
and stored with one signature per block implies that any on path attacker
can remove individual blocks without it being noticed. So aren't there a
missing possibility to create a BIB that actually ensures that if it
validates a set of blocks was correctly provided? I know that with the
current mechanisms such a BIB could be stripped. However, such a block could
easily be required in a security policy for a particular deployment. Was
such aspects considered?

 

8.	Section 3.9: 

   o  When adding a BCB to a bundle, if some (or all) of the security

      targets of the BCB match some (but not all) of the security

      targets of a BIB, then a new BIB MUST be created and all entries

      relating to those BCB security targets MUST be moved from the

      original BIB to the newly created BIB.

 

This comment is linked to the pervious one. When reading this, I had a hard
time to understand what "moved" in the above text actually meant. Finally I
realized that you could actually move a signature from one BIB to another. I
think this could be made a bit clearer. 

 

9.	Section 3.10:

   Individual BPSec security context identifiers SHOULD use existing

   registries of identifiers and CBOR encodings, such as those defined

   in [RFC8152], whenever possible.  Contexts SHOULD define their own

   identifiers and CBOR encodings when necessary.

 

I find the above paragraph unclear.  I think one part is what "security
context identifiers". 

 

10.	Section 5.1.1:

If the receiving node is

   not the destination of the bundle, the node MUST decrypt the BCB if

   directed to do so as a matter of security policy.

 

I think this is an example of the unclarity of who is to process a
particular security block, because I don't understand how the node will be
able to do this. 

 

11.	Section 11:

 

   A registry of security context identifiers will be required.

 

If you need a registry for security context identifiers then you need to
create it and defines its rules. 

 

Cheers

 

Magnus Westerlund