Minutes for DTN at interim-2015-dtn-1
minutes-interim-2015-dtn-1-1
| Meeting Minutes | Delay/Disruption Tolerant Networking (dtn) WG | |
|---|---|---|
| Date and time | 2015-08-28 07:00 | |
| 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: Cant 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 dont 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 arent 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 doesnt 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 dont 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 doesnt 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 didnt 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.