Skip to main content

Minutes for DTN at interim-2015-dtn-1
minutes-interim-2015-dtn-1-1

Meeting Minutes Delay/Disruption Tolerant Networking (dtn) WG
Title Minutes for DTN at interim-2015-dtn-1
State Active
Other versions plain text
Last updated 2015-09-02

minutes-interim-2015-dtn-1-1
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.