Register
Submit a solution
The challenge is finished.

Challenge Overview

The Office of Space Communications and Navigation (SCaN) at NASA Headquarters leads the Delay Tolerant Networking (DTN) investigation with the goal of advancing the maturity and heritage (space flight use) of the DTN communication protocols.

Delay tolerant networks make use of store-and-forward techniques within the network in order to compensate for intermittent link connectivity. In the DTN the fundamental concept is an architecture based on Internet-independent middleware where protocols at all layers are used that best suit the operation within each environment, with a new overlay network protocol (bundle protocol) inserted between the applications and the locally optimized communications stacks.

We are performing a refactoring of the code to decouple the authentication mechanism from the main library code.

LTP authentication is just one of a possible assortment of LTP extensions, so it should not be hard-coded into libltpP.c. Instead, the general functions for attaching and processing LTP extensions should be coded in libltpP.c and the specific functionality of authentication should be relocated to a subdirectory. The implementation of BP extensions in ION (ion-open-source/bp/library/ext) should be used as a guide, meaning that the same sorts of mechanisms used to generalize extension processing in BP should also be used to generalize extension processing in LTP.

Note that this competition is not simply moving LTP code to extension folder or to BP folder. A general guideline from the customer is (this is not a strict guideline):

  • Write a source file named (for example) auth.c that only contains the functions for adding and ingesting (parsing and checking) the Authentication header and trailer. Place this file in a directory named ltp/library/ext/auth.
  • Define a general extension definition structure containing extension-specific function pointers: one for adding an extension to an LTP segment, one for ingesting an LTP segment extension. This definition could for example be in a file named ltpei.h in ltp/library.
  • Create a source file named ltpextensions.c in which an array of those structures (with just two members in the array – one for the Authentication header extension, one for the Authentication trailer extension) is hard-coded. The function pointers in those structures would be set to the names of the functions in auth.c. (At the top of this file, #include "ltpei.h") Place this file in a directory named ltp/library/ext.
  • At the top of libltpP.c, #include "ltpextensions.c". Remove all code that is now in auth.c, while retaining all extension processing code that would always be the same for any LTP extension. Modify that generic extension processing code to search the extensions array for the appropriate extension definition and then call – by function pointer – the functions referenced in that definition.

RSA public / private key issue commented by the customer and that needs a fix:

  • As currently coded, the LTP authentication rule that is applied to a segment in order to verify its authenticity is always the rule for the LTP engine that is the originator of the transaction. This is correct for data, RA, CS, and CAR segments, but for segments transmitted by the receiving engine it should be the receiving engine's rule. (The receiving engine ID is the engine ID in the Span object cited in the ExportSession object for the block transmission session to which the segment contributes.) The analogous modification applies to the insertion of authentication extensions during segment serialization.
  • If you're using public/private keys then you can't use the same key in both directions. The code has now been modified to use the source engine ID in some cases and the destination engine ID (the engine ID in the "span" on which the session is conducted) in others, which is good except that I believe it has not been done correctly.
  • We're doing only signing/verification in LTP auth, not encryption, correct? If we're using an asymmetric cipher for signing/verification then the sender of a segment (in either direction) always needs to produce a signature that is computed using the sending engine's own private key so that the receiver of the segment can use the segment sender's public key to verify the signature. Right?
  • The key name of an LTP engine's own private key would be determined by finding an LTP-Auth rule that matches the local LTP engine's own number. The key name of a remote engine's public key would be determined by finding an LTP-Auth rule that matches that engine's ID.
  • In constructDataSegment, the engine number that is used to find the rule naming the key to use for computing the segment's signature – which must be the private key of the sender of the segment, i.e., the source engine for the block – is currently the receiving engine ID (span->engineID). This is incorrect.
  • In enqueueCancelReqSegment, the engine number that is used to find the rule naming the key to use for computing the segment's signature – which must be the private key of the sender of the segment – is currently the receiving engine ID (span->engineID). This is correct when the engine that is issuing the cancellation segment is the receiving engine for the block, but it's incorrect when the sending engine is cancelling the session. In the latter case, the block's source engine ID must be used.
  • In constructCancelAckSegment, the engine number that is used to find the rule naming the key to use for computing the segment's signature – which must be the private key of the sender of the segment – is currently the receiving engine ID (span->engineID). This is correct when the engine that is issuing the cancellation acknowledgment segment is the receiving engine for the block, but it's incorrect when the sending engine is acknowledging the cancellation. In the latter case, the block's source engine ID must be used.
  • In constructRS, the engine number that is used to find the rule naming the key to use for computing the segment's signature – which must be the private key of the sender of the segment – is currently the receiving engine ID (span->engineID). This is correct.
  • In constructReportAckSegment, the engine number that is used to find the rule naming the key to use for computing the segment's signature – which must be the private key of the sender of the segment – is currently the receiving engine ID (span->engineID). This is incorrect; the sender of a report acknowledgment segment is always the block's source engine.
  • In verifyAuthentication, the engine number that is used to find the rule naming the key to use for verifying the segment's signature – which must be the PUBLIC key of the sender of the segment – is currently the block's source engine ID. This is correct when the engine that is verifying the segment is the receiving engine for the block, but it's incorrect whenever the block's sending engine is verifying a segment that it has received from the block's receiving engine. In the latter case, the receiving engine ID (span->engineID) must be used.


Final Submission Guidelines

The architecture competitor should download the ION-DTN 3.1.3 - http://sourceforge.net/projects/ion-dtn/files/ion-3.1.3.tar.gz/download

You should make changes above existing assembly and previous architecture. When using the previous architecture, make sure you synchronize the diagrams and documentation with the existing code. 

Previous Architecture contest contains relevant links and information: http://apps.topcoder.com/wiki/display/docs/ION-DTN+LTP+Authentication+Architecture

ELIGIBLE EVENTS:

2014 TopCoder(R) Open

Review style

Final Review

Community Review Board

Approval

User Sign-Off

ID: 30039054