Minutes for DTN at IETF-95
minutes-95-dtn-1

IETF DTN Working Group Minutes
April 4th, 2016
IETF95, Buenos Aires, Argentina
========================================

Administrativia
----------------------------------------
- Brian Haberman is in two meetings at same time, will attend DTNWG in person
and remote to other.

- Ed Birrane and Rick Taylor to take notes.

- Notewell noted.

Agenda Bashing
----------------------------------------
- None

Summary
----------------------------------------
- Agreed to put BPBIS in to last call, starting 2 weeks from today and having a
4 week review period.

- Agreed to remove BABs, security destinations, and First/Last blocks from
BPSEC. Will take removal of CMS blocks to mailing list.

- Discussion of key management protocol design is premature without key
management requirements and assumptions. Requirements must not encode/mask
design (e.g. PKDN or identity-based schemes).

- AMA document will be sent to the OPS area for review and comment.

- A neighbor discovery architecture, independent of CLA, is needed to put other
discovery protocols in context. Looking for volunteers to write this.

- Work on an addressing architecture is necessary in general, and most recently
to help explain the nature of routing table entries in the static routing
drafts.

Questions (Q), Answers (A), and Comments (C):

Presentation 0 : DTNWG Charter Review (Marc Blanchet)
----------------------------------------

Marc presented an overview of the working group charter. Including standards
track revision to RFC5050, architecture documents, security protocol, node
neighbor discovery, service registry, informational document on static routing,
investigations on enhanced neighbor discovery, key management, and network
management.

Presentation 1 : BPBIS (Scott Burleigh)
----------------------------------------
Scott summarized changes to BPBIS to include:
-       All blocks, not just primary, could include CRCs.
-       Considering removing one clause of the spec having to do with the
status report on forwarding over unidirectional links. -       Propose to move
ahead into last call and get an RFC out this year.

Q: Kevin Fall: If all blocks have a CRC and in the future I wish to define a
block that did not have a CRC, I could not do that without additional overhead,
correct? I would still need an indicator that the block did not contain a CRC.
Can we encode CRC type in the block type?

A: Scott Burleigh: We could do that.

Q: Ed Birrane: Could we add a CRC type bit to block flags

A: Scott Burleigh: Yes, but we don’t have block flags we just have flags.

Q: Brian Haberman: Any object to moving to last call and having this discussion
as part of last call?

C: Ronald in ’t Velt: If we go for last call: would like it to be a long
period, not just two weeks.

C: Brian Haberman: 4 weeks of last call, starting 2 weeks from today, so we
have 6 weeks total. Start reviewing it now.

C: Scott Burleigh: An initial draft of a CBOR encoding is posted as well.
Current discussion on the mailing list seemed reasonable and will drive some
revisions to the document. Otherwise, the CBOR spec is likely close to being
finished, too.

Presentation 2 : BPSEC (Ed Birrane)
----------------------------------------
Ed summarized changes to BPSEC to include:

- Continued discussion of the removal of authentication blocks and 5
alternatives to authentication absent these blocks. - Remove of security
destinations and having block processing be a matter of policy. - Removal of
first/last block types and stating that a security operation will have at most
1 security block. - Removal of CMS.

Q: Kevin Fall: You presented several options for authentication absent a BAB.
How does someone pick from amongst them?”

A: Ed Birrane: It depends on the requirements, and we plan to put the decision
criteria in a security practices document separate from the BPSEC document.

C: Scott Burleigh: In BPBIS, the payload is always the last block, which also
supports the concept of not having “first/last” blocks for items targeting the
payload.

C: Marc Banchet: Perhaps make the CMS a separate document, so as to simplify
implementations.

Presentation 3: Public Key Management (Kapali Viswanathan)
----------------------------------------
Kapali presented the requirements and design of a public key management system.
This system relies on a reliable, public DTN multicast and validators chosen by
configuration or discovery.

Q: Ed Birrane : Several assumptions encoded in this approach. Can you capture
the assumptions and constraints along with requirements for this system

A: Kapali Viswanathan: Yes, we can add bootstrapping assumptions.

Q: Ed Birrane: How do you validate yourself to (and from) the validator?

A: Kapali Viswanathan: Validation occurs out of band.

Q: Ed Birrane: PKDN would be used to communicate long-term keys, not session
keys, correct?

A: Kapali Viswanathan: Correct. Long-term keys only.

C: Kevin Fall: Your depiction of full operation depends on a reliable,
multi-cast DTN protocol - which is an unsolved research problem.  Let’s assume
that exists. We do have reliable multi-cast that might work in non-DTN
environments.

Q: Kevin Fall: If validators get different information over time, your choice
of validator will give you different behavior. (ties back to routing again).
How do you account for that?

A: Kapali Viswanathan: I heard 2 questions: (1) reliable multi-cast to
validators and (2) different validators have different states with respect to
CRL.

For reliable multi-cast you can also use a publish/subscribe mechanism. So you
can go unicast to the certificate revocation manager and unicast the same
message multiple times, if you do not have a reliable DTN multi-cast.

For validators we different state, we can only guarantee eventual consistency.
certificate validations will have a finite time (say valid for 8 hours) after
that the session must be re-initiated.

Q: Kevin Fall: It seems like endpoint needs to be cognizant to periodicity and
engagement with validators. How do endpoints know this, because it is path
dependent.

A: Kapali Viswanathan: Session has a finite duration.

C: Marc Blanchet: The purpose of this presentation was to discuss requirements.
This conversation is more concerns with a solution than with requirements.

Q: Kevin Fall: What is the charter item for this?

A: Marc Blanchet: Requirements, not a mechanism. In general, to pull
requirements that are well known and then modify based on what is special about
the DTN environment.

C: Ed Birrane: With assumptions and constraints added to requirements.

C: Kevin Fall: There is a significant amount of existing work on key management
using identity-based encryption which has different properties than what was
presented here and could be written down in requirements document and melded
together. Consider identify-based management as well, and some special items
implied by DTN environment.

C: Marc Blanchet: Agree with that approach. Process is to focus only on
requirements and assumptions.

C: Rick Taylor: Appreciate what this work is trying to do and what is trying to
solve. Get feeling that assumptions section is big (of the solution) and
possibly the requirements. Work is valuable but delayed until we are settled.

C: Brian Haberman: Agree we need to understand what we are trying to do and
agree with Rick that it is premature to talk about specifics right now.

Presentation 4: Asynchronous Network Management (Ed Birrane)
----------------------------------------
Ed discussed an architecture document for open-loop network management. This
includes the need for autonomy in network management and renaming associated
protocol AMP not DTNMP to distinguish the work from DTN.

C: Nalini Elkins: Consider taking this work to LMAP to see if there is any
crossover.

Q: Ed Birrane: If the AMA work sufficient to capture use-cases and act as
requirements?

A: Marc Blanchet: It is time to discuss with the OPs area. Particularly if you
are going to write ADMs in YANG.

C: Ed Birrane: Yes, AMA is probably ready for such review. AMP will be after
the next set of updates.

Presentation 5: IP Neighbor Discovery (Ronald in ’t Velt)
----------------------------------------

Discussion of neighbor discovery for IP.

C: Kevin Fall: Previous work in this area talked through discovery options.
There should be a neighbor discovery architecture that sits over all CLAs. 
Should be able to tell someone else I have other endpoints you can reach me on.
Discovery may also include things like clock sync, time, and other
capabilities. Hesitant to go down an IP-only route.

C: Ron in ’t Velt: Put in request for port number. Need a registry of hash
functions as well.

C: Brian Haberman: If there are issues related to neighbor discovery
architecture then asking IANA for multi-cast addresses is premature. IPv6
muticast addresses have lots of scopes that you can take advantage of without
asking for an IANA registry.

C: Rick Taylor: You would still need to register a port number.

C: Rick Taylor: I see three types of discovery:

1.      CLA-specific neighbor discovery
2.      Generic-for-CLA considerations requirements, tips and trick
3.      Endpoint discovery principles.

Q Rick Taylor: Given that, do we need multiple documents?

A: Marc Blanchet: We need direction from WG on where to go in terms of neighbor
discovery.  If there are other approaches on the table, we need people to work
on those.

C: Kevin Fall: There are lots of applicable things here, but it all must be
done in context of the discovery architecture which needs some meat on it.

Q: Will Ivancic: What is a neighbor definition in the sense of a bundle
architecture?

A: Ron in ’t Velt: A neighbor is another BP speaker

C: Kevin Fall: Concrete recommendation: We need an architecture document for
neighbor discovery.

C: Ron in ’t Velt: CLAs inherited from DTNRG are IP-based and LTP. TCP and UDP
CLA use IP. Would be fine to have neighbor discovery based on that.

C: Kevin Fall: Fine for now, but must be defined so that we can add new CLAs
later.

C: Marc Blanchet: Need to find someone to tackle neighbor discovery
architecture.

Presentation 6: Static Routing (Nabil Benamar)
----------------------------------------

Presentation of static routing approach, including discussion of what would be
present in a routing table entry.

C: Kevin Fall: Recommend string matching for EID addresses.

C: Ed Birrane: Consider data rate information in the routing table.

Q: Rick Taylor: What do we put into these EIDs? Say I have 100,000 EIDs in my
static routing table? Can I do some kind of compression on this? Can we subnet
these things?

A: Kevin: Compression like that doesn’t exist, but that doesn’t mean we can’t
make progress. Idea is that you could choose to have different addressing
structures per scheme name. If you do string matching in the EID you do not
need to develop here a mechanism to understand all such current and future
structures.

Q: Rick Taylor: Should Nabil and John treat the EID as an opaque string and
work on what goes in the entries, or should they capture some address stuff in
here. Otherwise, how do we actually use the table entries?

C: Brian Haberman: We have a work item for addressing architecture and making
straw proposals.  Need someone to work this.