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

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

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://tools.ietf.org/html/rfc2402>] and [RFC-2406<https://tools.ietf.org/html/rfc2406>], respectively.



Best regards

Kapali