Subject: [dtn] BPbis - mandatory BPsec

From: "Burleigh, Scott C (US 312B)" <[email-masked]>
Date: Wed, 29 Jul 2020 00:49:54 +0000

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

---

From: "R. Atkinson" <[email-masked]>
Date: Wed, 29 Jul 2020 09:16:40 -0400

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=[email-masked]> wrote:
> 
> _______________________________________________
> dtn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dtn

---

From: "Taylor, Rick" <[email-masked]>
Date: Wed, 29 Jul 2020 13:26:01 +0000

&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 
[email-masked]
www.airbusdefenceandspace.com

THIS DOCUMENT IS NOT SUBJECT TO EXPORT CONTROL.

-----Original Message-----
From: dtn [mailto:[email-masked]] On Behalf Of R. Atkinson
Sent: Wednesday, July 29, 2020 2:17 PM
To: DTN WG <[email-masked]>
Subject: Re: [dtn] BPbis - mandatory BPsec

All,

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.

Yours,

Ran

_______________________________________________
dtn mailing list
[email-masked]
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.

---

From: "Birrane, Edward J." <[email-masked]>
Date: Wed, 29 Jul 2020 13:56:37 +0000

To date, Ran's text most clearly captures the sentiment I am seeing on the list. 

+1

-Ed

Edward J. Birrane, III, Ph.D.
Embedded Applications Group Supervisor
Principal Staff, Space Exploration Sector
Johns Hopkins Applied Physics Laboratory
(W) 443-778-7423 / (F) 443-228-3839

> From: dtn <[email-masked]> On Behalf Of Taylor, Rick
> Sent: Wednesday, July 29, 2020 9:26 AM
> To: R. Atkinson <[email-masked]>; DTN WG <[email-masked]>
> Subject: [EXT] Re: [dtn] BPbis - mandatory BPsec
> 
> APL external email warning: Verify sender [email-masked] before
> clicking links or attachments
> 
> &nbsp;
> Ran,
> 
> * 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
> 
> 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.
> 
> 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.
> 
> > On Jul 28, 2020, at 20:49, Burleigh, Scott C (US 312B)
> <scott.c.burleigh=[email-masked]> 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.
> >
> 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.

---

From: [email-masked]
Date: Wed, 29 Jul 2020 10:50:57 -0400

+1 to this

Ronny

On Wed, 2020-07-29 at 13:26 +0000, Taylor, Rick wrote:
> 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 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
> 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.
> 
> % 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.”
> 
> (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.)  
> 
> 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.
> 
> > On Jul 28, 2020, at 20:49, Burleigh, Scott C (US 312B) <
> > scott.c.burleigh=[email-masked]> 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.
> >  
> 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
> registration number, 3468788.  Registered office:  Pegasus House,
> Aerospace Avenue, Filton, Bristol, BS34 7PA, UK.