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

[Rick Taylor <[e-mail]>]

Thank you for this Ed.

I think it is a good repository for opinions on Stephen's comments, and
it would be nice to extend it to include other peoples comments as
well.  But, I don't want to see the mailing list fall silent, and would
ask that people explain their comments on the list, and then update the
relevant row in the spreadsheet.

Can I also request some more comments and feedback on the latest TCPCL
draft as well, please - it too is in Last Call.

Rick

On Sat, 2017-01-28 at 20:27 +0000, Birrane, Edward J. wrote:
> 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-hNv8F03QxhNzdW8
> aitOEOcVfoOmUM/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] and [RFC-2406], respectively.
>  
> Best regards
> Kapali 
>  
>  
>  
>  
> _______________________________________________
> dtn mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dtn