Subject: [dtn] BPv7 node ID and node identity

From: "Sipos, Brian J." <[email-masked]>
Date: Fri, 3 Dec 2021 20:55:22 +0000

All,

After re-reading some of the to-be-RFC 9171 I realize that I had been making
an incorrect assumption for a long time: that the administrative endpoint ID
of a node is the same as its node ID. I see now that more technically that
EID can be the node ID but doesn't have to be. In that light I have some
deeper questions about a node and its node ID:

1.      Is it operational practice that the administrative EID is in fact
the node ID? Early examples that I read led me to expect this.

2.      Is it required that a node has only a single node ID at any
point-in-time? In many parts of the document (and other documents and
discussions) the phrasing is ". the node ID ." and not ". a node ID ." or
similar phrasing.

3.      Is it expected or required that a node ID be stable over time for a
node? If not, there seem to be operational issues related to how peers can
identify a node with a time-varying node ID. This is especially the case
with respect to node authentication and how an authority may grant
identifier use to a node.

These questions are coming up in the context of the "Node ID Validation"
document [1] and its assumptions that the answer to all the above questions
are "yes." There are definitely parts of that document which are ambiguous
or incorrect now that I see it with the perspective that a node ID is not
equivalent to the administrative EID.

Thanks for any clarification,

Brian S.

[1] https://www.ietf.org/archive/id/draft-ietf-acme-dtnnodeid-07.html

---

From: <[email-masked]>
Date: Fri, 3 Dec 2021 16:30:42 -0800

Hi, Brian.  A couple of answers, which may or may not be helpful:

1.	This is a recent change, responding to objections that disallowing
demuxes (for the dtn scheme) and non-zero service numbers (for the ipn
scheme) in the source node ID was unnecessarily restrictive - the identity
of the node could be accurately determined by inspection even if those rules
were violated.  The BPv7 specification has been revised to state that any
endpoint ID from which the identity of the node can be discerned without
consulting any other information source may serve as a node ID.  This is
sort of by definition - it's a string that identifies the node, so it's a
node ID, even if it contains some additional information that identifies a
particular endpoint in which that node is registered.  (Nodes have in fact
always been able to have multiple administrative endpoints, hence multiple
node ID strings, i.e., one for the dtn scheme and another for the ipn
scheme.)
2.	It is not required that a node be identifiable only by a single EID.
3.	The ID of an administrative endpoint of a node may always be used to
identify the node; such endpoints implicitly exist so long as the node
itself exists.  (That is, if and only if a node exists it is registered in
its administrative endpoint(s).)  Other EIDs may serve as node IDs as well -
in particular, they may be cited as the sources of bundles - but the
identified endpoints are not guaranteed to be in existence at any particular
moment.  (Nodes may register and unregister in other singleton endpoints at
will.)

Scott

From: dtn <[email-masked]> On Behalf Of Sipos, Brian J.
Sent: Friday, December 3, 2021 12:55 PM
To: [email-masked]
Subject: [dtn] BPv7 node ID and node identity

All,

Brian S.

---

From: "Sipos, Brian J." <[email-masked]>
Date: Sat, 4 Dec 2021 14:41:16 +0000

Scott,

I agree that in concept "the identity of the node can be discerned ." but
unfortunately there is neither a definition nor an algorithm included to do
this discerning or some kind of normalization of the EID. And the problem is
now this more lax use of Node ID is likely to cause issues with both BPSec
source identifying and TCPCL/TLS authentication. It's not that the current
mechanisms are broken in a simple sense, but that they no longer cover valid
situations and will fail or be ambiguous in some cases.

For TCPCL now, if I have a PKIX certificate which is issued to "ipn:100.0"
(authorizing the key holder to act as that Node ID) then the current
certificate profile's NODE-ID definition fails to handle the case where my
CLA identifies itself as "ipn:100.1" (or with any other service number).
Likewise the certificate could be issued to "ipn:100.1" and fail when the
CLA identifies as "ipn:100.0".

For BPSec and the default security contexts, there is a potential situation
where I source a bundle, include in it a BIB with a BIB-HMAC-SHA2 context
and security source of "ipn:100.1", then some security acceptor attempts to
verify the MAC but has a keystore containing a key associated with
"ipn:100.0". Should that verifier count this as integrity verified? The key
does properly verify the MAC but how does the verifier associate this key
with that security source in the BIB?

It seems like there needs to be a concrete definition of node identity
similar to the URI-ID comparison (of only the authority part) from RFC 6125
[2] and probably also a normalized form of Node ID for things like a PKIX
certificate or a keystore can contain the normal form of the Node ID which
will then compare "properly" to any other non-normal forms on-the-wire.

Again, I don't think this strictly breaks either current specification but
it leaves them in a very fragile situation where all entities in the network
must agree on a normal form that's not specified anywhere. And, especially
in the security domain, leaves a door open to all kinds of ad-hoc mechanisms
that will not interoperate (see the mess of PKIX wildcard certificates) or
leave security holes.

Brian S.

[2] https://www.rfc-editor.org/rfc/rfc6125.html

From: [email-masked] <[email-masked]> 
Sent: Friday, December 3, 2021 7:31 PM
To: Sipos, Brian J. <[email-masked]>; [email-masked]
Subject: [EXT] RE: [dtn] BPv7 node ID and node identity

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

Scott

From: dtn <[email-masked] <mailto:[email-masked]> > On Behalf Of
Sipos, Brian J.
Sent: Friday, December 3, 2021 12:55 PM
To: [email-masked] <mailto:[email-masked]> 
Subject: [dtn] BPv7 node ID and node identity

All,

Brian S.

---

From: "Birrane, Edward J." <[email-masked]>
Date: Sat, 4 Dec 2021 15:03:23 +0000

Scott, Brian,

I certainly agree that it is possible the ACME work misinterpreted BPv7 and
BPSec. But, I do not see the correction of Node ID to be a "change" to the
functioning of BPv7 nor do I see it to be a security issue. 

  A few things:

1.      The Source Node ID of a bundle should be a singleton endpoint of the
node on which the BPA resides. 

The Source Node ID of a bundle was never meant to be restricted to the
administrative endpoint of the node - if that were the case, every bundle
would be sourced from, for example, ipn:1.0 and never ipn:1.1 or ipn:1.2.
Section 5.2 of -31, which explains how to populate the bundle source node ID
for bundle transmission,  has been clear on this and unchanged for a very
long time:

"The source node ID of the bundle MUST be either the null endpoint ID,
indicating that the source of the bundle is anonymous, or else the EID of a
singleton endpoint whose only member is the node of which the BPA is a
component."

2.      Forcing all bundles to be sourced only from an administrative
endpoint (thus destroying other source information) is not a security
benefit. 

Forcing all security to be based on only the administrative endpoint of a
Node (ipn:1.0) rather than allowing differentiation (ipn:1.1, ipn:1.2) is a
more dangerous (because it is implicit and loses fidelity) wildcarding. I
would not agree with a change that *required* security policy to only be
based on the administrative endpoint on a node, versus any singleton
endpoint on that node.

  Generally, there has been some utility in drawing parallels between a node
id /  service in the IPN scheme and an IP address and port numbers. While
that helps bootstrap thinking on naming and addressing, the IPN scheme is
NOT an IP scheme (which is, of course, why it is different) and EIDs are not
the same as IP addresses so trying to keep the concepts 1-1 in all cases
isn't the correct approach here, IMO.

-Ed

Edward J. Birrane, III, Ph.D. (he/him/his)

Chief Engineer, Space Constellation Networking

Space Exploration Sector

Johns Hopkins Applied Physics Laboratory
(W) 443-778-7423 / (C) 443-690-8272

From: Sipos, Brian J. <[email-masked]> 
Sent: Saturday, December 4, 2021 9:41 AM
To: [email-masked]; [email-masked]
Cc: Birrane, Edward J. <[email-masked]>
Subject: RE: [EXT] RE: [dtn] BPv7 node ID and node identity

Scott,

Brian S.

From: [email-masked] <mailto:[email-masked]>
<[email-masked] <mailto:[email-masked]> > 
Sent: Friday, December 3, 2021 7:31 PM
To: Sipos, Brian J. <[email-masked] <mailto:[email-masked]>
>; [email-masked] <mailto:[email-masked]> 

Scott

All,

Brian S.