Re: [dtn] BPbis

+1 to this

Ronny

On Wed, 2020-07-29 at 13:26 +0000, Taylor, Rick wrote:
> &nbsp;
> Ran,
> 
> +1 (personal opinion, not chair)
> 
> I think that text is excellent, and is an elegant way of capturing
> what I believe the best way forward is, namely:
> 
> * If you do not want security, you do not have to use cryptography,
> but don't blame us if your secrets leak.
> * If you do want security, you MUST use BPSec, don't go inventing
> something else, it's hard to get right and we think we have got it
> right.
> 
> Sorry for the top-post.
> 
> Cheers,
> 
> Rick
> 
> Rick Taylor
> Product Design Authority, Mobile IP Node/PlexOS
> Principal Engineer (eXpert), Mobile Communications
> Airbus Defence and Space 
> Celtic Springs
> Coedkernew
> Newport
> NP10 8FZ
>  
> Phone: +44 (0) 1633 71 5637 
> rick.taylor@airbus.com
> www.airbusdefenceandspace.com
> 
> 
> 
> THIS DOCUMENT IS NOT SUBJECT TO EXPORT CONTROL.
> 
> -----Original Message-----
> From: dtn [mailto:dtn-bounces@ietf.org] On Behalf Of R. Atkinson
> Sent: Wednesday, July 29, 2020 2:17 PM
> To: DTN WG <dtn@ietf.org>
> Subject: Re: [dtn] BPbis - mandatory BPsec
> 
> All,
> 
> The usual and decades-long IETF practice is that “security is
> mandatory to implement, but optional to use”.
> 
> If security is NOT mandatory to implement, then experience shows it
> is unlikely to be widely available for users (or sessions) who wish
> to use security.
> 
> All that noted, I think Edward Birrane at JHU/APL had a possibly
> useful construct:
> % I agree that a BPA which does not source, verify, or accept
> security blocks % does not need to implement BPSec.
> 
> I would invert that sentence, but (I think) keep the same
> intention.  I propose adding the quoted two sentences just below to
> the Security Considerations:
> 
> “A Bundle Protocol Agent (BPA) which sources, verifies, and/or
> accepts a Bundle MUST IMPLEMENT support for BPsec.  Use of BPsec for
> a particular Bundle Protocol session is optional.”
> 
> This means that any BPA which doesn’t provide any of those
> (source/verify/accept) services need not implement BPsec.  For
> example, a pure forwarder would not need to implement BPsec.
> 
> The text above tries to crisply differentiate implementation from
> actual use by any particular BP session, in part because long-
> standing IETF practice is to levy requirements on implementations but
> (generally) avoid specifying mandatory operational practices (e.g.,
> RPF filtering for IP routes is a BCP but is not a hard
> requirement.)  
> 
> In the context of BP and DTN, it is easy to imagine
> deployments/environments where high-assurance link-layer
> communications security might be provided, thereby significantly
> reducing the potential value of BPsec for a given BP session.
> 
> I think the text above will go a long way towards keeping the IETF
> Security Area happy and greatly reducing the chances of security-
> related objections during the approval process.
> 
> I really think some form of “mandatory to implement” text for BPsec
> is important.
> 
> Yours,
> 
> Ran
> 
> > On Jul 28, 2020, at 20:49, Burleigh, Scott C (US 312B) <
> > scott.c.burleigh=40jpl.nasa.gov@dmarc.ietf.org> wrote:
> > 
> > Hi.  At IETF-108 there was discussion on whether implementation of
> > the BPsec security extensions should be mandatory in every BP
> > node.  Version 26 of the BPbis I-D (now posted) includes some
> > revision to the first paragraph of section 9.0 to address this
> > question.  It would be helpful to discover the WG consensus on this
> > matter.
> >  
> > Please use this thread for your comments.
> >  
> > Scott
> > _______________________________________________
> > dtn mailing list
> > dtn@ietf.org
> > https://www.ietf.org/mailman/listinfo/dtn
> 
> _______________________________________________
> dtn mailing list
> dtn@ietf.org
> https://www.ietf.org/mailman/listinfo/dtn
> This email and its attachments may contain confidential and/or
> privileged information.  If you have received them in error you must
> not use, copy or disclose their content to any person.  Please notify
> the sender immediately and then delete this email from your
> system.  This e-mail has been scanned for viruses, but it is the
> responsibility of the recipient to conduct their own security
> measures. Airbus Operations Limited is not liable for any loss or
> damage arising from the receipt or use of this e-mail.
> 
> Airbus Operations Limited, a company registered in England and Wales,
> registration number, 3468788.  Registered office:  Pegasus House,
> Aerospace Avenue, Filton, Bristol, BS34 7PA, UK.
> _______________________________________________
> dtn mailing list
> dtn@ietf.org
> https://www.ietf.org/mailman/listinfo/dtn