Re: [dtn] [EXT] RE: BPv7 node ID and node identity

["Sipos, Brian J." <[e-mail]>]

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: [e-mail] <[e-mail]> 
Sent: Friday, December 3, 2021 7:31 PM
To: Sipos, Brian J. <[e-mail]>; [e-mail]
Subject: [EXT] RE: [dtn] BPv7 node ID and node identity

 


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

 

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 <[e-mail] <mailto:[e-mail]> > On Behalf Of
Sipos, Brian J.
Sent: Friday, December 3, 2021 12:55 PM
To: [e-mail] <mailto:[e-mail]> 
Subject: [dtn] BPv7 node ID and node identity

 

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