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

[Magnus Westerlund <[e-mail]>]

Hi,

So finnaly following up on the new revision. See inline for my comments
and remarks. I think there are potentially two minor text changes and
one question to answer. 


On Wed, 2019-07-24 at 23:01 +0000, Magnus Westerlund wrote:
> 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.

Fixed

>  
> 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.
>  

Fixed. 

> 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?

So this was resolved in discussion that the solution to this is the
Bundle-in-bundle encapsulation. 

>  
> 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?

Same as 3. 

>  
> 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?
>  

I think the changes made things clearer, but didn't fully resolve the
question I have about if it intended that future extension may reserve
any of the other bits? Which would imply a ignore values of for
implementation undefined bits. 

If that is the intention please be explicit about that. 



> 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.

Discussed, no change needed. 

>  
> 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?

This was discussed and no furhter changes required. 

>  
> 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.

Fixed. 

>  
> 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”.

Fixed. 

>  
> 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.

Addressed. 

>  
> 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.

The new registry looks reasonable. The comment I have is that as draft-
ietf-dtn-bpsec-interop-sc is a example / template for future security
context identifiers, then it is actually good to perform the
registration with IANA in that document also, so that part of the
process is not forgotten. 

Cheers

Magnus Westerlund 


----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Torshamnsgatan 23           | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------