Re: [dtn] DTN addressing, routing, and ownership

[Brian Sipos <[e-mail]>]

Scott,
Your responses are most helpful!

The piece I was missing is that there _is_ a concept of a per-node administrative endpoint. And that in the absence of any other services on a router-type node, that endpoint would be expected to be 'reachable'. And it makes sense that this is the endpoint to which administrative records would be reported-to.
The language of BPbis Node ID definition [11] now makes more sense in this concrete context. The raw text indicates _what_ a Node ID is but, at least on my reading of it, didn't really indicate or imply that the Node ID is the specific channel for the BP agent itself to exchange bundles.

The unfortunate thing is that neither RFC7116 [12] nor the referenced RFC6260 [13] actually says what IPN service number zero is supposed to actually do or when it should (or should not) be reachable on a node. Nor is RFC7116 referenced by any other documents [14]. I agree that the scope of BPbis, which just prescribes how to generate and process v7 bundles, doesn't need to cover service naming but I don't know if I would have picked up on this kind of detail without your feedback (or some kind of hands-on experience with existing BP tools).

[11] https://datatracker.ietf.org/doc/html/draft-ietf-dtn-bpbis-25#section-4.1.5.2
[12] https://tools.ietf.org/html/rfc7116#section-3.2.2
[13] https://tools.ietf.org/html/rfc6260
[14] https://datatracker.ietf.org/doc/rfc7116/referencedby/

________________________________
From: Burleigh, Scott C (US 312B) <[e-mail]>
Sent: Tuesday, June 30, 2020 13:19
To: Brian Sipos <[e-mail]>; [e-mail] <[e-mail]>
Subject: RE: DTN addressing, routing, and ownership


Hi, Brian.  More responses in-line below.



Scott



From: Brian Sipos <[e-mail]>
Sent: Tuesday, June 30, 2020 5:30 AM
To: Burleigh, Scott C (US 312B) <[e-mail]>; [e-mail]
Subject: [EXTERNAL] Re: DTN addressing, routing, and ownership



Thank you for the response. I want to pose my questions in more concrete terms, so I'll use a few vignettes based on current or proposed DTN protocols. My intent is to figure out how these protocols are actually being used if  possible.



In all cases I run a BP agent with three endpoint IDs for three separate services: "dtn://nodeA/svc1", "dtn://nodeA/svc2", and "dtn://nodeA/svc3".

  1.  I use a single TCP CL (v3 or v4 doesn't matter, the same node info is exchanged in either case). I start a CL session (in either direction, contact data is the same) and send my Node ID. The CL requires exactly one Node ID for my side of the session. Which of the EIDs do I use as my Node ID? Or is it some other URI?  These are difficult questions to answer in terms of the dtn URI scheme, as the detailed semantics of that scheme are not (and have never been, AFAIK) standardized anywhere.  In ipn-scheme terms, let’s say you have a node whose node number is 91 that is a member of (singleton) endpoints ipn:91.1, ipn:91.2, and ipn:91.3.  That node is also implicitly a member of endpoint ipn:91.0, the administrative endpoint for that node (per RFC 7116).  The most useful node ID to pass when starting this TCPCL session would be “ipn:91.0”.
For outgoing CL sessions I could use a different EID for different outgoing bundles, but for incoming connections I have to send my Node ID before knowing what bundles may be incoming. Do I just choose one randomly? And then route bundles to the other EIDs as necessary?  No, in this context the right node ID to send is “ipn:91.0”.
  2.  I run a DTN IPND node and send out broadcast beacons to my local network. Each beacon holds a single "Canonical EID". Which of the EIDs do I use in the beacon?  Again, I would say the right EID to advertise in this case is “ipn”91.0”.  I will make a somewhat controversial assertion here and claim that BP endpoints are – in practice – functionally equivalent to sockets.  In UDP/IP the destination of a datagram is a socket, not a host; but we route to the host, which delivers the datagram’s content at the socket.  Similarly in DTN the destination of a bundle is an endpoint, not a node; but we route to the node, which delivers the bundle’s application data unit at the endpoint.  So for routing purposes the information that needs to be advertised in a beacon is the node ID, which in this case is the singleton EID “ipn:91.0”.
Do I need to send three beacons for three services? If so, I could run into situations where neighborhood topology is observed to be different for the three services even though they use the same network transports.  I would say no, just as in IP we don’t normally advertise all of the sockets that the host has got open.  Service numbers don’t normally bear on the topology.
  3.  For my question of "ownership" it means the same thing as "owning" an email address: I'm able to receive email for an address and send mail for an address. If I can prove to some third-party to be able to do those two things then I can claim to own an address.  I think that’s not really what you mean, though.  There are Internet tools that I can use to generate packets of arbitrary content and to snoop packets including emails; my use of those tools doesn’t demonstrate my ownership of the address.  I think what you really mean is that when a person receives an email for which the sending address is [e-mail]<mailto:[e-mail]>, that person can safely (modulo cyber-security as always) conclude that the sender of the email is Brian Sipos rather than Angela Merkel, because Brian Sipos is the registered owner of that address.  So what matters is the authenticity of the registered association between that name and that address; the integrity of the registry is paramount.
So my question for DTN is: if I can prove to own a Node ID (by proving to receive and send nonce-type bundles), does the network design allow my claim to cover not just the one Node ID URI for that bundle but any URI for that same "node-name".  And I think the answer is the same: your “ownership” of a node ID is an entry in a registry, somewhere, that associates your name with that node ID in a manner that is provably authentic.  If that ownership is established, then I would say that you also “own” (in the same sense) every ipn-scheme endpoint whose node number is the same as that of the node ID that you own.
To put another way: Would a DTN router ever actually make a routing decision based on the service part of an EID? I'm not asking the theoretical question but the practical one.  I guess it might, under the same kinds of circumstances under which an IP router would make a routing decision based on the port number of a socket address.  I don’t know enough about IP to identify all those circumstances; firewalls, I guess.  In DTN we don’t yet have anything like that, as far as I know.
A similar existing situation: To prove that I own an IP address I can use a mechanism like [10], which uses HTTP or TLS on TCP port 80/443. My proof-of-ownership is on a specific TCP port but the thing which I am proving to own is the entire IP address.  Again I would say that “ownership” is a matter of registration.  Currently the only such registry I know of for DTN is the node number assignments managed by nation space agencies under the auspices of the CCSD Space Assigned Numbers Authority.  Other registries are certainly possible, and the procedures for establishing node number ownership might vary wildly among registries.

I understand the Node ID/Endpoint ID theory, but when it comes to figuring out in practice I'm running into this brick wall related to multi-service nodes (which seems like it should be a common enough situation).



[10] https://tools.ietf.org/html/rfc8738





________________________________

From: Burleigh, Scott C (US 312B) <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, June 30, 2020 01:03
To: Brian Sipos <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: RE: DTN addressing, routing, and ownership



Brian, I will offer a few answers, in-line below, but I am sure others will jump in to correct anything I get wrong.



Scott



From: dtn <[e-mail]<mailto:[e-mail]>> On Behalf Of Brian Sipos
Sent: Sunday, June 28, 2020 8:05 AM
To: [e-mail]<mailto:[e-mail]>
Subject: [EXTERNAL] [dtn] DTN addressing, routing, and ownership



All,

I've been trying to figure out some details related to DTN addressing which are not covered in detail in the DTN architecture document [1]. My exposure to DTN has been from the protocol definition perspective and not from the historical-use perspective, so any undocumented current practices are probably unknown to me.



My questions are similar to the following:

1.      Are EIDs with identical dtn-scheme "node name" or ipn-scheme "node number" guaranteed to be routed to the same BP agent? How is this guaranteed? What document requires or disallows it?

--A BP agent is a component of a node.  The destination of a bundle is an endpoint, which is defined as a set of nodes but in practice is usually a set containing only a single node, a “singleton endpoint”.  RFC5050 defines the manner in which a bundle is forwarded to the sole occupant of a singleton destination endpoint.  Naturally, any program can be written to do anything one likes, so there are no guarantees.  But an alleged BP node that doesn’t do what RFC5050 (or, soon, BPbis) mandates is non-conformant.

2.      Are bundle routers allocated a well-known dtn-scheme "demux" text or ipn-scheme "service number"? i.e., is a bundle always routed through "dtn://NodeA/router" before it reaches endpoint "dtn://NodeA/svc1"?

--The dtn scheme actually isn’t very thoroughly defined.  There are some standard ipn-scheme service numbers defined by CCSDS, but there are no mandated routing policies associated with any of those numbers.

3.      Must each node run its own router service? Can a router on NodeA deliver bundles to an endpoint service on NodeB? Through what mechanism would this occur?

--“Delivery” of a bundle is defined in RFC5050; it is part of the defined behavior of the bundle protocol agent of a BP node.  The BPA presents to the appropriate application element (within the node’s application agent) the application data unit that is the payload of the bundle.  That application element could then pass the data on to whoever, but that’s outside of the bundle protocol.

4.      Can a single BP agent use convergence layers (CLs) which expose different Node IDs to neighbors? Can my BP agent use TCPCL sessions with local Node ID as "dtn://NodeA/svc1" and "dtn://NodeA/svc2"? Must it only expose the router service to CLs? Or does the CL itself constitute a service (e.g. as "dtn://NodeA/tcpcl")?

--Node IDs don’t have anything to do with convergence-layer adapters; the manner in which a node determines the ID of a neighboring node is completely unrelated to the convergence-layer protocols that will be used for communication between the nodes.

BPbis for Node ID schemes "dtn" [2] and "ipn" [3] has syntax explained but not full semantics. CBHE [4] gives some non-normative explanation of node number vs. service number semantics, but again doesn't dig into much detail about relationship requirements.



--I’d say that’s because the normative semantic issues are addressed by the protocol specifications rather than the scheme definitions.



The reason for all of these questions are two answer security topics such as:

1.      If I get a PKI certificate [5] for my node, do I need to authenticate (i.e. have a subjectAltName for) all possible Node IDs which could be used on my node? Or do I only need to authenticate for one "router" service, which is the only Node ID used by CLAs?

--I think this depends on exactly what the certificate is going to be used for, and I haven’t been following this thread closely enough to understand that.

2.      If I validate that I "own" a single Endpoint ID using a method such as [6], what else can be derived from that EID validation? Can I be said to own the entire dtn "node name" or ipn "node number"? Or can separate BP agents own EIDs with identical node-name/node-number?

--Since endpoints are identified by EIDs and an endpoint is a set of nodes, it’s certainly possible for multiple nodes to be registered in an endpoint identified by a single EID.  It’s not yet clear to me what “ownership” means in this context, though.

3.      When using BPsec [6] as a security acceptor, when I look up implicit keys associated with a security source Node ID must I relate keys to the full URI or can I relate keys to any URI with the same node-name/node-number? Will a security source always be a router service, or some other well-known service on a node?

--We don’t really have a concept of a “router service.”  Sharing a single key among multiple nodes (identified by different singleton endpoint IDs) is always going to be possible, I think, though not necessarily a good idea.

4.      When using a neighbor discovery (ND) protocol such as [8], which Node ID is supposed to be used as the "canonical EID" for each node? Just the router Node ID? Just the CL-based Node IDs? What about endpoint IDs directly delivered by the router on this node?

--Again, we really don’t have a concept of a router service or a router ID.  Nodes are just nodes.  Any node can be the source of a bundle, can be the destination of a bundle, or can forward a bundle that it receives but for which it is not the destination.  In implementation there is a notion of an endpoint that is the destination of all administrative bundles (bundles whose application data units are administrative records) directed toward a given node; the ID of that endpoint would nominally be the “canonical EID” for that node.

My own intuition makes me think that there is such a "router" service which is implicitly present on each node, which is used as the CL "Node ID" or ND "canonical EID", but that doesn't seem to actually be documented anywhere. It looks like there was a similar attempt to clarify DTN services in [9] but I don't see any movement on that after 2012.



Thanks in advance for clarification on any of these points.



[1] https://tools.ietf.org/html/rfc4838

[2] https://tools.ietf.org/html/draft-ietf-dtn-bpbis-24#section-10.7

[3] https://tools.ietf.org/html/draft-ietf-dtn-bpbis-24#section-10.8

[4] https://tools.ietf.org/html/rfc6260#section-2.1

[5] https://datatracker.ietf.org/doc/html/draft-ietf-dtn-tcpclv4-21

[6] https://datatracker.ietf.org/doc/html/draft-sipos-acme-dtnnodeid-01

[7] https://datatracker.ietf.org/doc/html/draft-ietf-dtn-bpsec-22

[8] https://datatracker.ietf.org/doc/html/draft-irtf-dtnrg-ipnd-03

[9] https://datatracker.ietf.org/doc/html/draft-blanchet-dtnrg-bp-application-framework-01