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

["Burleigh, Scott C (US 312B)" <[e-mail]>]

Hi, Rick.  You raise a lot of good items for discussion; we have discussed many of them at length over the past 20 years, but they're well worth taking another look at with fresh eyes.

One important point: there are actually no addresses anywhere in bundle protocol.  There are names (of endpoints and of nodes), but those names are never required to have any topological significance.  This is the "late binding" concept that has been fundamental to DTN from the beginning: at every BP forwarding point in a bundle's end-to-end path, the forwarding node will use the name of the destination BP endpoint to compute the address of the convergence-layer endpoint (e.g., TCP/IP socket name) to which the bundle must be transmitted in order to reach the next BP forwarding point.  Mapping the destination endpoint name to convergence-layer endpoint addresses may be done any number of times; it may be done very differently each time (as the bundle traverses multiple types of networks); and the mapping for the final segment of the path might yield an answer that is very different from the answer that would have come up if the exact same mapping had been done at the moment when the bundle began its journey.  Bottom line: DTN addressing actually isn't a thing.

Another point, like it or not (it has its detractors): an EID identifies a BP endpoint, and a BP endpoint is simply a named set of nodes.  In practice, for convenience, we usually treat a BP endpoint as something much like a socket; this works because most BP endpoints are singleton (if you know the destination endpoint then you know the destination node) and any node can be a member of any number of endpoints (so multiple endpoints identified by different names can all be associated with the same node, making the variations in endpoint naming act a bit like port numbers).  But the protocol is more general than that.  There can be multicast BP endpoints, anycast BP endpoints, and probably some other variants that we haven't thought of yet.  The destination EID may imply an application, but that's not guaranteed in any way.

It probably would have simplified things long ago if we had started out recognizing that nodes and endpoints are distinct and that the protocol requires that both nodes and endpoints be uniquely identifiable for different purposes.  We didn't do that, for whatever reason.  So now, recognizing that for some purposes we have to be able to identify nodes (which are state machines that actually do things) in addition to identifying endpoints (which are just sets of nodes), in the bpbis specification we define a node ID as an endpoint ID that meets certain constraints: the identified endpoint must be a singleton, the sole occupant of that endpoint must be the identified node, and the node's membership in that endpoint must be (essentially) permanent.

We discussed including a Reply-to EID in the primary block many years ago and eventually decided not to.  The Bundle Protocol itself doesn't need it and wouldn't use it, because it would merely be the suggested destination of a bundle that the application (the receiver of the bundle containing the Reply-to EID) might or might not choose to send in response; only the application would have any use for it.

That in itself doesn't make the Reply-to EID a bad idea - certainly we do plenty of other things for the benefit of the application - but the Bundle Protocol has been around for a long time without anybody complaining that there's no Reply-to EID in the primary block.  In some cases the application natively knows how to form the ID of the destination endpoint of any bundle that it might issue in reply to reception of some bundle; in other cases the application data unit contains information that the receiving application needs to consider in order to formulate a reply; in many cases there will never be a reply, because most delay-tolerant communication is not conversational.  So maybe it's a good idea to include a Reply-to EID in a bundle, but since nobody is currently using any such thing (as far as I know) I think a strong case could be made for providing Reply-to EID in an optional extension block, not in the primary block.

Anonymous bundles - bundles for which the source is dtn:none - were built into the protocol from the beginning; it was argued that anonymity may be desirable for some kinds of applications in some environments.  I'm not a huge fan myself, but I don't think they do any harm in a well-managed network: security policy at any node may require that the authenticity of a bundle's source be guaranteed by a block integrity block signed by the source node, resulting in anonymous bundles being simply dropped.

The risk of cyber-attacks using status reports has been brought up a number of times, and certainly it's a concern.  The trouble is that, used judiciously, status reports are a powerful way to troubleshoot the network; I suspect that any other comparable mechanism that one used instead would either be less capable or else just as dangerous.   I think authorizing the forwarding node to drop bundles that look like an attack (the new "Traffic pared" reason code for the Forwarding Contraindicated procedure) is a workable solution.

The split between DEST and DST_PORT does indeed formally exist for the ipn EID scheme: node number and service number.  We could do the same sort of thing for the dtn scheme, but the WG has not yet reached consensus on the detailed syntax of dtn-scheme EIDs.  It's not that we haven't recognized this issue, it's that the issue is addressed in the EID schemes rather than in the protocol specification itself.

Scott

From: Rick Taylor <[e-mail]>
Sent: Friday, July 10, 2020 9:50 AM
To: Burleigh, Scott C (US 312B) <[e-mail]>; Brian Sipos <[e-mail]>; [e-mail]
Subject: [EXTERNAL] RE: DTN addressing, routing, and ownership

Hi Both,

This conversation has forced me to go back over the primary block (4.2.2) and think hard about what addresses are in there, especially comparing and contrasting with IP and the administrative record/status reporting, and I'm afraid I have a few problems.

Disclaimer - I may have misunderstood, but what I understand from the document is that the Primary Block (amongst other things) contains:


*         Destination *EID* - The Application-Layer endpoint to deliver the bundle to, unless it's an Administrative record, in which case it's a Node_Id.

o   No problem, has to be there.

*         Source *Node_Id* - The Id of ingress Node.  I have some problems with this:

o   As this is a Node_Id, then the application layer has to include a "Reply To" EID in the payload block if it wants to know where to send replies of work out who (at the app-layer) sent the bundle.

o   It may be EID_Null.  This is bad.  I appreciate the need for an application-layer entity to not want to announce its identity, as it may not be useful.  However, being able to inject bundles into a network from an anonymous source seems a very poor choice.

*         Report-to EID - An Endpoint Id - The EID to use for Status records.

o   4.1.4 Refers to using the "Source Node Id" (I believe incorrectly) for the generation of status reports.

o   I have concerns about an amplification attack using a multicast Report-To EID.

My worst DTN nightmare is we standardise another system for spam: and if I can create a bundle with an anonymous originator that sends reports to a multicast group on every hop then we have made a monster.

In IP, one has the layer-3 addressing in the IP header (SRC,DEST) and at a higher layer, e.g. UDP {SRC_PORT,DST_PORT}.  This combination (and I know this is simplified, and we all know this) allows administrative records to be sent by the IP layer back to the SRC, and allows the Application layer to send data-packets back to the source of the data, i.e. SRC+SRC_PORT.

I think you are trying to describe the same model, Scott, but with Bundle Protocol "late-binding" there is no split between DEST and DST_PORT.  However, I think the clarity has been lost in the reworking of the text over time.  May I suggest:

Primary Block:

*         Destination *EID*

o   MUST NOT be EID_NULL.

o   The application-layer destination of the bundle payload.  This is the key component of late-binding.

*         Reply-To *EID* - Application-layer supplied "Reply To" address for bi-directional communication,

o   MAY be EID_NULL.

o   This is not used by the Bundle forwarding system, but is there for convenience and OAM.  Many apps will want it, it may as well enjoy the immutability benefits of the Primary Block.

*         Source *Node_Id* - The Node_Id of the BPA that introduced the bundle into the network.

o   MUST NOT be EID_NULL.

o   The Destination EID of administrative records if Report-to is EID_NULL.

*         Report-To *EID*

o   An alternate EID to send administrative records.  I can see reasons for wanting this, but it is contentious.  I can see some 'public' networks not using it.

I know it's late in the day for these kind of suggestions, but I felt I wanted to raise my concern.

Cheers,

Rick

(and sorry for the top-post).



From: Burleigh, Scott C (US 312B) [mailto:[e-mail]]
Sent: 09 July 2020 17:38
To: Brian Sipos; Rick Taylor; [e-mail]<mailto:[e-mail]>
Subject: RE: DTN addressing, routing, and ownership

Brian, another good question.  I would say that point of requiring identification of the specific node that is the source of a bundle is that it's the only way the specification can make sense.  A BP endpoint is an identifiable set of nodes, possibly comprising thousands of nodes.  As such, an endpoint doesn't do anything; there are no requirements that endpoints perform any protocol procedures.  All procedures, including the transmission of bundles, are performed by the components of nodes (including the bundle protocol agent).

In particular, the identity of a bundle includes a sequence number that is generated by a node, not by an endpoint.  We ensure the uniqueness of a bundle identifier by including the identity of that node in the bundle identity as well.

We could merely require that the source of a bundle be a singleton endpoint rather than (more strictly) a node ID, so long as it's always the case that by inspection of that source singleton endpoint's ID we can determine the identity of the source node that is the sole member of that endpoint.  But that imposes some requirements on endpoint ID schemes that we have not yet articulated.  Is it important to do that?

Scott

From: Brian Sipos <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, July 8, 2020 7:09 PM
To: Burleigh, Scott C (US 312B) <[e-mail]<mailto:[e-mail]>>; Rick Taylor <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: [EXTERNAL] Re: DTN addressing, routing, and ownership

Scott,
Since DTN is quite asynchronous compared to other transports, it makes sense that most protocols would not follow a strict request--reply paradigm and, if necessary, have some notion of a protocol-level reply-to EID.

The point about the bundle source is more confusing to me now. I think part of my confusion is lack of realistic examples or historical use, so these are not merely theoretical questions. Is there a reason why BPbis changed from RFC5050 to have a requirement about source _node ID_ instead of more general endpoint ID?
And are the current implementations which allow a source general EID expected to continue to do so? In that case what's the benefit of BPbis requiring more specific behavior?
________________________________
From: Burleigh, Scott C (US 312B) <[e-mail]<mailto:[e-mail]>>
Sent: Friday, July 3, 2020 15:53
To: Brian Sipos <[e-mail]<mailto:[e-mail]>>; Rick Taylor <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: RE: DTN addressing, routing, and ownership


Hi, Brian.  Good point about the admin record flag in the primary block, this does give the implementation an opportunity to intercept misdirected administrative records.



Your point about reply-to EIDs is also well taken.  It is true that the source of every bundle is a node, and bpbis draft differs from RDFC 5050 in requiring that the source EID of an outgoing bundle identify the source node (except for anonymous bundles).  Forming the destination EID is always the responsibility of the application (even in the case of administrative records, as the source of an administrative record is the administrative element of the application agent - an application).



But at least in the ipn scheme, it would actually be fine for the source EID to have a service number other than zero; the node ID of the source node could always be formed simply by replacing the source EID service number with zero.  That would be one way to solve your conundrum, and in fact the ION implementation of BPv7 operates in this way.



I guess another mechanism would be to assume (or require) that service numbers be symmetrical/bidirectional so that the destination EID service number could be used as the return EID service number.  But that seems unnecessarily restrictive and I suspect it would raise more issues that we haven't thought of yet.



Scott



From: Brian Sipos <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, July 1, 2020 7:50 PM
To: Burleigh, Scott C (US 312B) <[e-mail]<mailto:[e-mail]>>; Rick Taylor <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: [EXTERNAL] Re: DTN addressing, routing, and ownership



Scott,

Regardless of the phrasing, I believe that requirements about the use of the Node ID to exchange admin. records would avoid confusion for agent implementers. Some informative text about the purpose of a Node ID and its relationship to the Source of generated bundles would also make crystal clear what I was confused about.

The one difference between your port/socket example and BP is that because BP gives an explicit admin. record flag this situation is detectable by the BP agent before the data ever makes it to the overlaying application(s).



I still do have one conundrum now that I believe I understand the Source ID parameter: Since outgoing bundles are marked with the Node ID of the source and not a service-specific EID from the source, there is no concept of a "return EID" for replying to a bundle with a bundle. Unlike UDP/IP, where the source port number provides a return path for a packet, or SMTP, where each message includes an RFC5322 From or Reply-To address. Without an explicit return EID, then a dictionary of well-known dtn-scheme service names (and ipn-scheme service numbers) is mandatory.



When I receive a bundle from Node ID "dtn://nodeB/bp" to my EID at "dtn://nodeA/xyz", which is for Future-Protocol-1, how do I know what EID implements Future-Protocol-1 on "nodeB"? Maybe it's "dtn://nodeB/efg". Unless the application payload data itself contains an explicit return EID, I will need to construct an EID from the Node ID. Is the expectation to have an application-data-specific reply-to EID? Or is EID construction from an application the expected mode?

________________________________

From: Burleigh, Scott C (US 312B) <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, July 1, 2020 10:03
To: Brian Sipos <[e-mail]<mailto:[e-mail]>>; Rick Taylor <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: RE: DTN addressing, routing, and ownership



I think we're thinking along the same lines, Brian.  The source EID of any bundle containing an administrative record should likewise be one of the source node's node IDs (or ideally - I believe - the node's [sole] node ID).



I think the Internet may once again serve as a model for answering your question.  When an email arrives at a socket bound to port 156, I expect SQL Server simply discards it as invalid SQL Server data, right?  It's up to the sender to address the bundle correctly.



Scott



From: Brian Sipos <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, July 1, 2020 6:48 AM
To: Rick Taylor <[e-mail]<mailto:[e-mail]>>; Burleigh, Scott C (US 312B) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: [EXTERNAL] Re: DTN addressing, routing, and ownership



Rick and Scott,

I actually don't see any problem now in the normative text in either BPbis or the current CL uses of "Node ID".

What I didn't pick up on are the secondary concerns of "how do I choose a Node ID?" and "what traffic is destined for that Node ID?" in BPbis Section 4.1.5.2. "Node ID" or elsewhere.

I had just assumed that the Node ID was just chosen from one of the Endpoints serviced by the node. In fact the Node ID is actually be separated on purpose from normal service EIDs.



This does bring up another point which I don't see addressed in Section 5.1.. "Generation of Administrative Records" or elsewhere: What is supposed to be the Source node ID of administrative-record bundles. I had earlier assumed they would match the Destination EID of the bundle which generated the Status Report (i.e. the status would be "coming from" the service EID). But looking at it now I realize the Source node ID of all bundles is *always* the singleton Node ID of the BP agent generating the bundle (admin or not).



Maybe some text in 4.1.5.2 similar to:

The Node ID is (MUST BE?) the Endpoint ID used as the (primary block) Source for all bundles originating from the node.

The Node ID is (SHOULD BE?) the endpoint ID with which the BP agent normally receives administrative bundles from other nodes. A Node ID is (SHOULD BE?) the destination EID of all administrative-record bundles.

Also related to this: what does a BP agent do when an administrative-record bundle is received on a normal service EID? Is that a valid situation? Does it still get processed with some internal warning?



________________________________

From: Rick Taylor <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, July 1, 2020 04:17
To: Burleigh, Scott C (US 312B) <scott.c.burleigh=[e-mail]<mailto:scott.c.burleigh=[e-mail]>>; Brian Sipos <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: RE: DTN addressing, routing, and ownership



Hi All,



Sorry for the top-post and my silence for the last months of COVID-19.



I have a concern that we have two node naming schemes (ipn + dtn) and neither is particularly well defined at the moment for historical reasons.  Looking forwards to a future interoperable DTN 'Internet', multiple schemes seems to require some kind of translation layer and I have had some long off-list conversations with Scott about such a topic - but we discussed ideas rather than concrete suggestions ready for drafts.



I wonder if a simple way forward for TCP-CL may be to keep the exact details of the "per-node administrative endpoint-id" as loose as possible in the CL specifications, i.e. requiring one exists, and defining how it shall be used for authentication, but leaving it to some other document (per-scheme perhaps) to define the actual details of the endpoint-id.



My open question is : would this be acceptable for a CL specification, or do the reviewers/authors require the "per-node administrative endpoint-id" defined, and is there sufficient text in BPbis to introduce the concept of a "per-node administrative endpoint-id"?



Cheers,



Rick



From: dtn [mailto:[e-mail]] On Behalf Of Burleigh, Scott C (US 312B)
Sent: 01 July 2020 00:35
To: Brian Sipos; [e-mail]<mailto:[e-mail]>
Subject: Re: [dtn] DTN addressing, routing, and ownership



I completely agree, Brian, we need to do a better job of documenting this.  It would also be good to document the corresponding semantics for the "dtn" scheme; that may actually be written down somewhere, but I can't lay my hands on it right now.



Scott



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



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<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<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]<mailto:[e-mail]>>
Sent: Tuesday, June 30, 2020 13:19
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



Hi, Brian.  More responses in-line below.



Scott



From: Brian Sipos <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, June 30, 2020 5:30 AM
To: Burleigh, Scott C (US 312B) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[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]..gov>>
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