Subject: Re: [dtn] BPSec optional Security Source

From: "Birrane, Edward J." <[email-masked]>
Date: Mon, 4 Jan 2021 20:52:55 +0000

Brian,

  I agree that it is a little inefficient to include a security source EID in a security block when that EID is the exact same as the bundle source.  However, I would prefer to not have BPSec prohibit this duplication.

  BPSec states that if a security source EID is not present, then "the source MUST be inferred from other information, such as the bundle source, previous hop, or other values defined by security policy."

  What if local policy on a BPA requires that, absent an asserted security source EID, the security source EID should be inferred as being the previous hop? In such a case, omitting the security source because it was the same as the bundle source would result in undesired behavior.

  Omitting a security source EID should be done when the security source node "believes the network can infer the security source correctly" which is different than saying "whenever it is the same as the bundle source".  In many cases those two statements have the same practical result, but not in every case.

-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: Brian Sipos <[email-masked]>
Sent: Wednesday, December 16, 2020 11:55 AM
To: [email-masked]; Birrane, Edward J. <[email-masked]>
Subject: [EXT] BPSec optional Security Source

APL external email warning: Verify sender [email-masked]<mailto:[email-masked]> before clicking links or attachments

Ed,
My interpretation of the purpose of the ASB Security Source field is to indicate the EID only if it's different than the bundle's source, but there's no actual requirement that I can see in the spec about this. Does it seem like a reasonable statement to say something like "If the security source EID is the same as the bundle source EID, as identified in the primary block, the Security Source field SHALL NOT be included in the ASB." but rephrased as needed?
Thanks,
Brian S.

---

From: Brian Sipos <[email-masked]>
Date: Mon, 4 Jan 2021 21:45:45 +0000

Ed,
Thanks for that clarification. Could this be added to the spec itself?
Right now, as you mention, there is a requirement on the how the security acceptor handles that field but no requirement or expectation on the security source. It seems like that Security Source EID is expected to be present and it's a special case (based on network knowledge) that it would be absent. I mistakenly made the opposite assumption.
e.g. The Security Source field SHOULD be present unless all security verifiers and acceptors are known to infer the correct implied security source.

Slightly related about terminology, that Security Source is defined as "This field identifies the Endpoint that inserted the security block in the bundle." But is the real situation that the source isn't an arbitrary endpoint but must always be a BP node (with a Node ID). Section 1.4 mentions that the security source has a Node ID and not a more general Endpoint ID.

Also, there are several places in the document where "security verifier" is used but that isn't present in Section 1.4 terminology listing. Can this be clarified? I assume a verifier is an acceptor which only performs read-only security operations related to a bundle. Maybe that's the wrong exact phrasing.
________________________________
From: Birrane, Edward J. <[email-masked]>
Sent: Monday, January 4, 2021 15:52
To: Brian Sipos <[email-masked]>; [email-masked] <[email-masked]>
Subject: RE: BPSec optional Security Source

Brian,

  BPSec states that if a security source EID is not present, then “the source MUST be inferred from other information, such as the bundle source, previous hop, or other values defined by security policy.”

  Omitting a security source EID should be done when the security source node “believes the network can infer the security source correctly” which is different than saying “whenever it is the same as the bundle source”.  In many cases those two statements have the same practical result, but not in every case.

-Ed

---

Space Exploration Sector

Ed,

Thanks,
Brian S.

---

From: "R. Atkinson" <[email-masked]>
Date: Mon, 4 Jan 2021 18:21:53 -0500

All,

For the sake of interoperability, maybe just say the “Security Source EID always must be present.”  It seems terribly optimistic to think the sender will have a priori knowledge of what downstream nodes plan to do.

Always including it might cost a few bytes, but doesn’t preclude a local policy at some node to look at other things, but including it always definitely helps with interoperability.

Postel’s Law:
	Be conservative in what you send and liberal in what you receive.

“Conservative” in this case means including the Security Source EID always - even if some downstream node did not require that datum some of the time.

Yours,

Ran

> On Jan 4, 2021, at 16:45, Brian Sipos <[email-masked]> wrote:
> 
> Ed,
> APL external email warning: Verify sender [email-masked] before clicking links or attachments
>  
> Ed,
> _______________________________________________
> dtn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dtn

---

From: Adam Wiethuechter <[email-masked]>
Date: Mon, 4 Jan 2021 23:25:07 +0000

+1 to Ran's suggestion.

--------
73,
Adam T. Wiethuechter
Software Engineer; AX Enterprize, LLC
________________________________
From: dtn <[email-masked]> on behalf of R. Atkinson <[email-masked]>
Sent: Monday, January 4, 2021 6:21 PM
To: DTN WG <[email-masked]>
Subject: Re: [dtn] BPSec optional Security Source

All,

Postel’s Law:

Yours,

Ran

---

From: Mehmet Adalier <[email-masked]>
Date: Mon, 04 Jan 2021 17:29:41 -0800

+1 for Ran’s guidance. Our BPsec implementation requires that a Security Source EID is always present.

mehmet

From: dtn <[email-masked]> on behalf of Adam Wiethuechter <[email-masked]>
Date: Monday, January 4, 2021 at 3:25 PM
To: DTN WG <[email-masked]>
Subject: Re: [dtn] BPSec optional Security Source

+1 to Ran's suggestion.

--------

73,

Adam T. Wiethuechter

All,

Postel’s Law:

Yours,

Ran

_______________________________________________ dtn mailing list [email-masked] https://www.ietf.org/mailman/listinfo/dtn

---

From: "Birrane, Edward J." <[email-masked]>
Date: Fri, 8 Jan 2021 21:36:20 +0000

Brian,

  For terminology - the "Security Source" is the bundle node that originates a security service. Or the Node ID of that node when using the Node ID to refer to the concept of the bundle node.

  The "Security Source EID" is an EID associated with the Security Source. This may be the Node ID of the node or any other EID active on that node.

  For example, if I were to have a sensor node with an IPN Node Id of ipn:1.0 and endpoints ipn:1.1 and ipn:1.2 we could say things like:

  The sensor node will sign any primary blocks using a BIB and a security source EID of ipn:1.1.
  Node ipn:1.0 will sign any primary blocks using a BIB and a security source EID of ipn:1.1.
  Node ipn:1.0 will sign any payload block using a BIB and a security source EID of ipn:1.0.

-Ed

---

From: Brian Sipos <[email-masked]>
Sent: Monday, January 04, 2021 4:46 PM
To: Birrane, Edward J. <[email-masked]>; [email-masked]
Subject: [EXT] Re: BPSec optional Security Source

Ed,

Also, there are several places in the document where "security verifier" is used but that isn't present in Section 1.4 terminology listing. Can this be clarified? I assume a verifier is an acceptor which only performs read-only security operations related to a bundle. Maybe that's the wrong exact phrasing.
________________________________
From: Birrane, Edward J. <[email-masked]<mailto:[email-masked]>>
Sent: Monday, January 4, 2021 15:52
To: Brian Sipos <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: RE: BPSec optional Security Source

Brian,

-Ed

---

Space Exploration Sector

From: Brian Sipos <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, December 16, 2020 11:55 AM
To: [email-masked]<mailto:[email-masked]>; Birrane, Edward J. <[email-masked]<mailto:[email-masked]>>
Subject: [EXT] BPSec optional Security Source

Ed,

Thanks,
Brian S.