Re: [dtn] working group last call on draft-ietf-dtn-bpbis

["Birrane, Edward J." <[e-mail]>]

I spent some time going through Stephen's comments trying to figure out a good way to address them. Rather than making dozens of individual posts on this mailing list, I put together a Google Doc spreadsheet as a way to try and capture thoughts on the items.


The document can be found and edited at:

https://docs.google.com/spreadsheets/d/1NDY3WB6JGoM0I-hNv8F03QxhNzdW8aitOEOcVfoOmUM/edit?usp=sharing


I have 3 sheets (DISCUSS, Minor, Nits) and in each sheet a column where I tried to more concisely distill the comments and then provide my own thoughts.  I would encourage others to make their own columns in the same way. I would also encourage other rows (representing new comments) to be added as we have them.


Not trying to stop or alter discussion on the mailing list itself, but I thought it might be a good idea to also have a place to capture WG member opinions as we go.


Please feel free to use if helpful.


-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 <[e-mail]> on behalf of I-Viswanathan, Kapaleeswaran <[e-mail]>
Sent: Wednesday, January 25, 2017 9:09 AM
To: dtn
Subject: Re: [dtn] working group last call on draft-ietf-dtn-bpbis

Hello:

>>>>>>>>>SNIP(Fred -> Stephen -> Fred -> Stephen -> Spencer)
> I am still going through your comments, but one question that I have
> on one of your points for now:
>
>     "4) it's not ok to omit
>      security mechanism definition, (making [BPSEC] normative and
>      waiting on that in the RFC editor queue would fix this, and is
>     IMO needed),
>
> Wouldn't that create a circular dependency?

>That's not a problem. The RFC editor handles document clusters
>like that all the time.

It is certainly the case (in my experience) that there's a history of IESG Evaluations taking longer/being less enjoyable for all parties when the protocol specification says "please see this other draft for security" and the working group says "we owe you one draft on security" ;-)
<<<<<<<SNIP

I see two ways forward for Bundle Protocol specification.

1.      The IPv4 way: by providing generic data structures for security headers but without providing any detailed specification for these headers.

a.      This approach will be useful to publish the transportation protocol (bundle protocol) specification first and then publish the security protocol (BPSec).

2.      The IPv6 way: by providing clearly specified headers (data structures) for interfacing transportation and security protocols.

a.      This approach will require a complete specification of transportation and security protocols (in different documents) and releasing them at the same time.

I see this as a matter of style, because IPSec has been successfully deployed on IPv4 and IPv6.

But, purely from a documentation perspective, in its current specification style, Bundle Protocol appears to be a similar to IPv6. In the IPv4 document reference model, security specification (IPSec) refers to transportation specification (IPv4) but not the other way around. In the IPv6 document reference model, transportation (IPv6) and security (IPSec) specifications cross-reference each other. The document references in IP and IPSec documents are as follows.

1.      IPSec –refers to--> IPv4, IPv6

2.      IPv6 –refers to--> IPSec

3.      IPv4 –does not refer to--> IPSec

Bundle Protocol specifies security in extension blocks (https://tools.ietf.org/html/draft-ietf-dtn-bpbis-06#section-4.3). IPv6 specifies security in extension headers (https://tools.ietf.org/html/rfc2460#section-4.1). In IPv6, data confidentiality is specified as optional while authentication and data integrity are mandatory. IPv4 specifies security as something that is needed in “some simutations” (https://tools.ietf.org/html/rfc791#section-1.4) and minimizes any heavy-weight attention to the topic.

The following text from IPv6 could be interesting in this regard.


A full implementation of IPv6 includes implementation of the

   following extension headers:



           Hop-by-Hop Options

           Routing (Type 0)

           Fragment

           Destination Options

           Authentication

           Encapsulating Security Payload



   The first four are specified in this document; the last two are

   specified in [RFC-2402<https://sslvpn.jhuapl.edu/html/,DanaInfo=tools.ietf.org,SSL+rfc2402>] and [RFC-2406<https://sslvpn.jhuapl.edu/html/,DanaInfo=tools.ietf.org,SSL+rfc2406>], respectively.



Best regards

Kapali