Re: [dtn] BPSec optional Security Source

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

mehmet

From: dtn <dtn-bounces@ietf.org> on behalf of Adam Wiethuechter <adam.wiethuechter@axenterprize.com>
Date: Monday, January 4, 2021 at 3:25 PM
To: DTN WG <dtn@ietf.org>
Subject: Re: [dtn] BPSec optional Security Source

+1 to Ran's suggestion.

--------

73,

Adam T. Wiethuechter

Software Engineer; AX Enterprize, LLC

From: dtn <dtn-bounces@ietf.org> on behalf of R. Atkinson <rja.lists@gmail.com>
Sent: Monday, January 4, 2021 6:21 PM
To: DTN WG <dtn@ietf.org>
Subject: Re: [dtn] BPSec optional Security Source 

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 <BSipos@rkf-eng.com> wrote:
> 
> 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. <Edward.Birrane@jhuapl.edu>
> Sent: Monday, January 4, 2021 15:52
> To: Brian Sipos <BSipos@rkf-eng.com>; dtn@ietf.org <dtn@ietf.org>
> Subject: RE: BPSec optional Security Source
>  
> 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 <BSipos@rkf-eng.com> 
> Sent: Wednesday, December 16, 2020 11:55 AM
> To: dtn@ietf.org; Birrane, Edward J. <Edward.Birrane@jhuapl.edu>
> Subject: [EXT] BPSec optional Security Source
>  
> APL external email warning: Verify sender BSipos@rkf-eng.com 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.
> _______________________________________________
> 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

_______________________________________________ dtn mailing list dtn@ietf.org https://www.ietf.org/mailman/listinfo/dtn 