DTN WG Minutes Interim Meeting, August 28, 2015 ============================== Administrativia ------------------------------ - Attendance (from webex screenshot) Ed Birrane, Marc Blanchet, Amy Alford, Brian Haberman, Charles Sheehe, Fred Templin, Keith Scott, Gilbert Clark, John Dowdell, Juan Fraire, Kevin Fall, Rick Taylor, Ronald in 't Velt, Scott Burleigh, Tomaso de Cola, Kapali Viswanathan, Travis, Will Ivancic, Audric, Jeremy Meyer - Notewell noted. Agenda Bashing ------------------------------ * None. Summary ------------------------------ 1. General agreement to segment Bundle Protocol into an abstract data model and one or more encoding documents for that data model. 2. The data model for BP may need to support signals independent of encoding to capture items such as "encoding not recognized" feedback. 3. Security serializations must be done on a canonical representation of data so that security results can be reviewed, when necessary, hop-by-hop even when waypoint nodes use different underlying encodings. 4. Payload block can be last block in the bundle. 5. Bundle sources and custodians are identified by NodeIDs and not EndpointIDs. 6. Another interim meeting will be schedule for end of September. Questions (Q), Answers (A), and Comments (C): Presentation 1: BP Open Technical Issues (Scott Burleigh) ------------------------------ Q: Fred Templin: Is there an issue with interoperability and multiple encoding formats? A: Scott Burleigh: Yes, but manageable. If each bundle has the same information, the translation amongst encoding formats should be mechanical. C: Brian Haberman: Some blocks look at every step of the way and others have meaning only to end destinations. Should be fine as long as we are clear on encoding for each block. C: Scott Burleigh: Remove encoding from BP spec and have abstract functional definitions. Then, write separate RFCs for each encoding (e.g., JSON, CBOR, 5050bis). These would lay out in detail the representation for each of the defined blocks of the protocol. As supplementary RFCs define additional extension blocks, we would update encoding RFCs. C: Keith Scott: A separate mapping is how to encapsulate encodings into different convergence-layer protocols. That should be standard regardless of the representation of a serialized bundle. Q: Jeremy Meyer: Are multiple representations a problem for routing? Do nodes need to understand paths based on supported encodings? A: Keith Scott: That is built-in now - some machines have Ethernet, others have PPP or SLIP, that defines possible topology and route on top of it. C: Scott Burleigh: This is analogous to convergence layer protocols, but orthogonal. It is somewhat complex, but manageable. Q: Ed Birrane: This approach produces lots of RFCs over time. Do you foresee us developing mechanisms to generate different encodings from the data model via tool rather than hand-crafted RFCs? A: Scott Burleigh: Anything we can do to streamline is good, but does not alter the overall approach, which should stand on its own. C: Marc Blanchet: Agree with Scott. Generally, worried about additional complexity as we have been trying to simplify BP not make it more complex. Q: Marc Blanchet: For interoperability, how do we select what is a "must implement" and what is "should" or "may"? A: Scott Burleigh: For foreseeable future there is not an overarching DTN. Today we have smaller, homogenous, stand-alone networks. If encoding translation is mechanical, gateways between networks is not a problem. No requirement for must-implement parts of a specifications across networks, just a gateway. C: Rick Taylor: The BP data model captures data that MUST be represented, independent of the encoding mechanism. But also there is a MUST on how to push and pull bundles across islands. One can build isolated islands but if you want to interoperate then you MUST make sure at the gateway to include sufficient data items in a suitable encoding for others. YANG may be a way to do it, it is a DDL we are looking for. C: Keith Scott: Agreed for data definition and for compatible mappings onto serialized formats, but not a mandatory mapping. C: Scott Burleigh: We have an existence proof for this approach in CBHE which has been doing this for years on a smaller scale. Q: Kevin Fall: Is there any signaling for receiving an encoding that I do not support, or is it silent? C: Scott Burleigh: We could have an encoding-independent signal. Perhaps to support encoding-independent representations for certain types. C: Rick Taylor: Classic example of a "MUST" in the core spec. If a bundle arrived from a CL and is missing important parts that a gateway requires, then some kind of non-delivery report is sent back. C: Keith Scott: CL could send something that says what encodings are supported. Will need to know what encoding scheme got used. That is where you add unsupported encoding message. C: Rick Taylor: Separate translation from wire-protocol away from CL itself. So you have in-out pair. Close to implementation-specific feature. C: Kevin Fall: Similar to network coding. Another layer of encoding. << Call for additional comments on multiple-encoding approach >> Q: Ed Birrane: Why do we need separate encodings below BP rather than above BP? IP networks today handle their encodings above IP. A: Rick Taylor: Because of different requirements for underlying network. Some networks have high bandwidth, others not. Some can tolerant the CPU/memory resources and queuing delays of compression and binary encodings. Others have the bandwidth to not have to do that. It is the most tolerant way of dealing with different processing overheads and link technologies. C: Scott Burleigh: Stephen has additionally argued for wider availability of tools for operating on data in JSON format. Packing JSON into binary loses the ability for intermediate nodes to operate on data without having to unmap binary to JSON and then remap. C: Rick Taylor: Also, nice to split the BP process/procedures into manageable sections. Q: Ed Birrane: Which encodings should be adopted by the WG? C: Scott Burleigh: Open a channel for multiple encodings, not all will succeed. Some will try and discard. C: Rick Taylor: Suggest JSON and CBOR. That gets us a binary and webby encoding. C: Scott Burleigh: More work. But those 2 encoding documents and a BP Data Model all fall within the charter for the WG. If we did this, we would have person-cycles to throw at the problem. Rick, for example, may take on the JSON encoding document. No additional work for others. << Marc: Does anyone oppose this approach?>> Q: Kapali Viswanathan: For integrity and confidentiality, usual practice is to encode/encrypt or encode/sign. If you put encoding afterwards, what does that mean? C: Keith Scott: Can’t move encoding to CL. How do we serialize? Generic way of serializing a block into an encoding. What comes out is a bag of bits, serialized with security. C: Kapali Viswanathan: Agree. Using our current vocabulary, signature/encryption is done on the model. C: Rick Taylor: JSON's loose whitespacing make hashing and CRCs a pain. Might need to provide CRC/hash or cryptographic primitive, defined in the wire protocol spec. C: Jeremy Meyer: Or, store required security bits (primary block for example) in a key-value thing, but when you convert back from JSON the types must be representative. C: Keith Scott: Same thing as an internal serialization mechanism,. Take data model and check security, serialize it. Canonical model including a data representation. C: Kapali Viswanathan: If we confidentiality and integrity at the data model we must serialize the model in a standard way, pass it through the algorithm, get the signature or cipher back, and then send through the encoding. That has to be a canonical encoding. Q: Rick Taylor: Do we need a canonical encoding? If you specify a CL wire format MUST supply suitable primitives in order to check. Can you pass the buck to a lower layer that does the check. C: Ed Birrane: Authentication can work that way for hop-by-hop, but how does this work for end-to-end integrity (for example) that should be verified at every hop along the way? General Agreement: Use a canonical format for integrity/confidentiality. CLA will do hop-by-hop authentication. General Agreement: Write a BP Data Model in the RFC5050bis and then go forward with CBOR and JSON encoding documents. Presentation 2: Payload Block Placement (Scott Burleigh) ------------------------------ Q: Scott Burleigh: Can we assert the Payload is always last block in the bundle. Makes things simpler. Re-introduces plausibility of reactive fragmentation. No more post-payload extension blocks. C: Rick Taylor: Any issue with dumping at end of the packet? C: Fred Templin: More natural way to put values at the back. A: Scott Burleigh: To protect the network, you only need to authenticate the primary block. So don’t need to wait until end of the payload. A: Keith Scott: For hop-by-hop where streaming issue comes up most it does make sense to push that down in the CLs as they are doing the streaming of the serialized bundle. C: Rick Taylor: For end to end, having the payload as the final block is fine, because hop-by-hop uses trailers as sees fir w/o interrupting higher level bundle. General Agreement: Payload can be last block in the bundle. Q: Rick Taylor: Is there a consensus of bundle instance IDs for the security protocols. For authentication and integrity checks. Whether defining integer IDs and specifying payload as 0, at this point in the protocol, whether we can answer this question. A: Scott Burleigh: Defer detail until later is fine. Would anticipate that the abstract data model would not dictate representation of things, will dictate the nature of things in the sense that items in the Abstract data model will be numeric data items. For example, Canonical format is a 64-bit Integer, how you encode that is up to you. C: Kapali Viswanathan: For canonicalization of DM, might be looking as a TLVs format. Which JSON is not, but CBOR is. Presentation 3: EID versus NodeIDs (Scott Burleigh) ------------------------------ Q: Scott Burleigh: Can bundle source and custodian be captured as NodeIds and not EIDs? Destinations can still be EIDs allowing for multi-point delivery. General Agreement: Bundle Sources are nodes. There may be multiple individual custodians in a network, but they are individually represented as nodes and not endpoints. Presentation 4: Key Distribution (Fred Templin) ------------------------------ Q: Charles Sheehe: How often do you update the blacklist? Whenever a key is revoked? C: John Dowdell: Issue with key authorities against physical attacks. DTNs generally have nodes that aren’t secured and wandering. A: Fred Templin: You need some set of authorities protected. They would need to be considered critical infrastructure. Q: Ed Birrane: Is the broadcast signed with public key. A: Fred Templin: Signed with it from key authority. You need Some root level trust basis at some point. Q: Charles Sheehe: What model are you using? Overlapping key sharing? A: Fred Templin: Model is that the public keys get propagated to all other nodes in a secure fashion. Q: Charles Sheehe: How do you bring in a node that doesn’t do security into a network? A: Fred Templin: Unknown. Nodes are pre-provisioned. Without keys they are not admitted into the network. Discussion: Nodes can join the network, but they will not be trusted. They could pass traffic if the data is encrypted, but a non-authenticated node will produce non-authenticated traffic. C: Fred Templin: How does this work on the internet. We don’t trust routers along the way. They simply forward along. Q: Rick Taylor: Can you generalize this for directory services, so more than public keys, but extra meta-data or data. Address book, payload information, etc… A: Scott Burleigh: Exactly. When putting together a prototype for a system that does this, only thought distribution of public keys. This is secure distribution of information in the clear. C: Charles Sheehe: Root of trust is an issue. This is a good start and how you bring new nodes into the network. NM is the hardest part to get in writing. C: Scott Burleigh: System doesn’t rely on being constantly and continuously available. Relies on reliable multi-cast. It is complex and no single key authority. Conveyance of PKI to authority can take however long it takes, so long as all keys are tagged with an active time. Nothing time-critical over a DTN, that is true. Other point about CA node being hacked, that is what the structure is aimed at managing. Fred didn’t go into the details of collaboration among the distributed nodes of a single key authority, but that is the intent of the design. Details of that are coming. Erasure coding of the bulletin. C: Fred Templin: A draft is being published for a public key distribution network.