#8 Sending node number lookup

3.2.1
closed
None
2
2014-07-14
2013-05-17
Anonymous
No

When a node receives a bundle, it's often helpful to know which node sent that bundle. (We need this for BABs, for example, and there are other potential uses.) That information could be provided in a previous-hop extension block, and if we did a 5050bis it could even be provided in the primary block; in either case, though, how would we know that information was trustworthy? We could use something in BSP to authenticate it, but maybe not all nodes will have BSP.

Currently in ION we figure this out by looking at the sender's convergence-layer endpoint ID: LTP engine number, or TCP or UDP socket address. For LTP, no problem because LTP engine numbers are the same as BP node numbers by convention; of course, that breaks down if somebody decides not to follow the convention. For TCP and UDP it's trickier: we have to walk through the routing Plans, looking for a Plan that maps a node number to an outduct with matching duct name, and that's not guaranteed to work because at most we can identify the node's host address -- if there are multiple nodes on the host, we can't tell which one sent the bundle.

Maybe an easier, more reliable, and safer mechanism would be simply to manage a lookup table that directly and explicitly associates nodes with the convergence layer endpoint IDs they use for bundle transmission. The best mechanism for populating that table isn't yet obvious, but maybe it's not an insuperable problem.

Discussion

  • Scott Burleigh

    Scott Burleigh - 2013-06-21

    Building this feature might also enable us to use predicted contacts (from the contact plan) to initiate and terminate transmission/reception for convergence layer adapters other than LTPCL. I think inability to match node number to convergence-layer endpoint ID is the only obstacle here.

     
  • Scott Burleigh

    Scott Burleigh - 2013-12-20

    A further wrinkle: this mechanism is indispensable for multicast, because if you don't know the sending node then the multicast forwarder has got no way of knowing which of its neighboring nodes (in the multicast tree) it must refrain from forwarding a bundle to in order to avoid a routing loop.

    And one more: each sending-node convergence layer endpoint ID must correspond to a single node but the reverse is not necessarily true. BSSP will use two convergence-layer channels (best-efforts and realtime) for traffic between a given pair of neighboring nodes.

    It is beginning to look as if the only workable mechanism is to obtain the sending node ID from an extension block in the bundle. If the bundle has a dictionary, the sending node's notionally identifying singleton endpoint ID can be referenced in the BAB's list of EID references (as the security source) if the bundle has a BAB; absent a BAB, the bundle could have a Previous Hop Insertion Block (PHIB, RFC 6259). For CBHE bundles, the sending node's node number needs to be provided in a new Sending Node ID Block (SNIB) that performs essentially the same function as the PHIB but in a more bit-efficient fashion: the block-type-specific data field is simply the sending node number expressed as an SDNV. This relieves the BAB (if present) of any responsibility for identifying the sending node.

    Separately, the problem of using predicted contacts to initiate and terminate transmission for convergence layer adapters other than LTPCL may actually be doable with the current data structures. A transmission contact event (start or stop) identifies the remote receiving node; that node number can be used to look up the corresponding Plan in the .ipnrc file; the Plan indicates the convergence-layer protocol endpoint ID (e.g., socket name) on which transmission should be started or stopped.

     
  • Scott Burleigh

    Scott Burleigh - 2013-12-20
    • status: open --> accepted
     
  • Scott Burleigh

    Scott Burleigh - 2013-12-20
    • Group: 3.2.0 --> 3.2.1
    • Priority: 8 --> 2
     
  • Scott Burleigh

    Scott Burleigh - 2013-12-31
    • status: accepted --> pending
     
  • Scott Burleigh

    Scott Burleigh - 2013-12-31

    Feature branch req-0008-sending-node implements a new Sending Node ID (SNID) extension block, which just contains the CBHE node number of the sending node. Mechanisms for inferring node number from convergence-layer EID are removed because they can generate false information, particularly in the event that multiple nodes are resident on the same machine.

     
  • Scott Burleigh

    Scott Burleigh - 2014-07-14
    • status: pending --> closed
     
  • Scott Burleigh

    Scott Burleigh - 2014-07-14

    For now, the ID of the sending node must be obtained from a SNID or PHIB extension block, and we have no way of authenticating that information. In the future, if we revise BP to recognized node IDs explicitly then the BAB should always assert the sending node ID and validation of the BAB will authenticate that assertion.

     


Anonymous

Cancel  Add attachments





Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks