Minutes IETF99: dtn
minutes-99-dtn-00

IETF DTN Working Group Meeting
July 17th
Prague, CZ

Chairs: Marc Blanchet & Rick Taylor

Minutes taken by Victoria Pritchard & Ed Birrane

Rick Taylor: Reviewed schedule and where we are behind.
Milestones - 5050bis and TCPCLv4 were due to be finished December 2016, Custody
(split out from 5050bis) and Bundle Security Protocol due May 2017. We are
slipping. These are key items and we need to make progress. We have other items
which are waiting. Please review (even a light review)!

BPSec is critical. Needs better review because it's security-related,
especially requires reviews as it goes up through IETF.

Look through next charter items:
        * Opinions on neighbor discovery and drafts.
        * We need BPBis finished so we can build upon them.
        * Work not visibly in progress slide - need the basic building blocks
        done.

Any comments on fact that we are delayed?

Scott Burleigh - BIBE and BPSec are not alternatives. BIBE depends on BPSec
existing. It doesn’t supplant it in any way.

Scott Burleigh - Bundle Protocol Status presentation
----------------------------------------------------
        * Overview of -07: 7th draft was posted June 22nd 2017. Removes custody
        transfer and reflects consensus on all comments received on draft 06
        (except a couple of small items, and a couple of comments in the last
        few weeks on the mailing list). * Custody transfer split - one way is
        to retain as an extension block. Another way is to combine with BIBE
        (internet draft posted) and make an optional feature of BIBE. *
        Overview of custody transfer in BIBE: Turn BIBE into reliable CL
        protocol like TCPCL, able to operate over disrupted links. Key benefit
        of custody transfer is preserved. Retransmissions after timeouts. 5050
        will always re-transmit too early or too late. Prefer to use reliable
        CL protocol. Use cases where Custody Transfer is necessary for
        reliability.

Jorg Ott: Semantic question: It occurs to me that TCP end-to-end model secures
bytes on the wire, but not how they are handled at receiver side. Reliable
transfer not pick-up-storage-and-what-not. Comparing CT which also talks about
durability in receiver side storage may be different than transport semantics.
Are you taking those two semantic aspects apart or mingling them? Scott: BIBE
approach unifies those concepts. Depending on implementation, it provides
security on a hop-by-hop basis and reliable transmission compatible with that
security, Jorg: Guarantee also enough space to rx something reliable and keep
it. Not worried about security, worried about reliability and storage. If you
take custody you can’t evict it because you have taken custody. Otherwise, if
you rx something reliably you can drop it if you have not taken custody. Do we
need to spell this out? Scott: Gives security hop by hop and reliability. Need
to spell out clearly what the implications are here.

Advantages:
Reliability over sections which dont use a reliable CL.
Simplifies Bundle Protocol.
BIBE is self contained well structured specification. Fits neatly.
Additional layer of security. Encapsulated bundle can be encrypted, defense
against traffic analysis. Simplifies Custody Transfer - no partial custody
transfer. RFC5050 issue with multi-point delivery. This is compatible with
multi-point delivery. Custody acknowledgements from multiple places hard to
track. With this, each neighbor you forward the bundle to is a custodian, each
one is a separate transaction. Tracked individually in implementation.
Multicast tree. Previous work on Bundle Delivery Time Estimation by researcher
at JPL. This is a way to estimate the round trip time, and therefore
retransmission timeout interval. Reasonably efficient retransmissions.

Disadvantages:
Overhead of encapsulation. Additional overhead is tolerable unless bundle is
tiny. Next custodian must be known. Important use cases where that is not the
case. In realistic operational uses you usually know who the next custodian is.
If you don't know, you have no way of knowing when to retransmit. Potential
impact on network performance is unacceptable. In opportunistic forwarding, the
next custodian is likely the neighbor you just discovered.

Marc: Within DTN network, say Node 1,2,3,4  Node 4 is dest, N1 source I know
that from N1 perspective, N2, N3 are custodians. And there possible additional
nodesin between. When N1 does that, it will address to N2 as custodian. Right?
Scott: If it knows N2, N3 are custodians, it could address to N3 and not expect
custody to N2. Marc: If I want to use many custodians, node2 will decapsulate
and re-encapsulate. How does node2 know node3 is the next one? Or it doesn’t
know? Scott: 2 answers: 1: It can be argued that N1 should not tell N2 that
because it is source routing. Otherwise, if we want it to happen, you can do
that because N1 could encap bundle in another bundle. Marc: Hop by hop custody.
Scott: Consistent with 5050. Difference is you need to determine in advance who
the custodians at each hop will be.

John Dowdell: Thanks Scott. Interesting. Initial reaction to separation from
5050 was great, put it in BIBE, not convinced, but make interesting arguments.
In world of opportunistic, move custody in more than 1 direction, multi-path.
Does this support multi-path? Scott: Yes. Because you can send 4 different
copies. Hold bundle and send to next discovered neighbor. To each neighbor you
do custodial to that node. That node, in itself would extract bundle and could
determine on its own whether it needed to go over BIBE or not. John: Said that
all nodes in network must support custody xfer. You can send more than 1 bundle
hop away. Is that correct. Intervening bundle hops are not custodial. Custody
signal wouldn’t come from encapbundle. Scott: Custody signals come from
destination of encapsulated bundle. Rick Taylor: Like it for 2 reasons: 1,
5050bis with CT came close to routing. 5050bis should be about transport and
not routing. Happy with separation. Also likes that BIBE is definitely
happening. Let's define it. In favour of this combination with BIBE.

Ed Birrane on Jabber: In BPSec there were issues with destinations, as it
implied routing - will we have the same problem? Scott: Fair question, think we
do not because we do this at the convergence layer, the route from the current
custodian and the next custodian can be entirely defined by the routing
protocol. The route from A-D with nodes in between, convergence layer protocol
does not need to know specific nodes along the route. So, it is a little brain
-bending since it is BP at both levels, but it avoids the problem that we
properly identified in bpsec. CL transmission is something that we already have
in the architecture and makes a clean separation for what is end-to-end at the
CL. Rick: During the BPSec discussion - we decided we can do this with BIBE,
self fulfilling prophecy.

Rick: Are you asking for BIBE-CT to be accepted as a WG document?
Scott: If sense of room is that we are ready to go, would like this adopted. Or
we can discuss further. Believe this idea is mature. Ready for adoption.

Not many in the room have read it. Of those who have, none object. Take
decision to list.

John Dowdell: Point of order: as mentioned, someone will want to do BIBE
anyway. Personally think it is worthy of WG adoption. Does it have to be
perfect before adopted. Suggest not. Rick: Question isn’t “is this perfect” it
is “can we adopt it”.

Ed Birrane - BPSec Updates presentation
---------------------------------------

05 version of BPSec. Talked about 04 last time, received some comments and some
got rolled in, will address those that didn't.

4 people in room have read a recent version.

Summary of BPSec
Motivation - in-bundle security mechanism, because different blocks may need
different security. Classic example, payload block encrypted, but other
extension block only integrity-signed. If you don't want in-bundle: You can
protect at application layer, or use secure CL.

Scott: An additional motivation is protection of data at rest, not just while
in transmission.

Use extension blocks, offering confidentiality (BCB) and integrity (BIB). List
targets to which they apply (avoids redundant information).

Processing rules and Security Considerations (see slide Summary (2/3) and
Summary (3/3))

Covered updates since 04 as in slides.
Primary block now immutable so doesn't need canonicalization.

Discuss current comments - request that these are sent to the mailing list.

At last WG meeting, noted that BPSec could go forward but needs an
interoperability cipher suite - posted a draft with recommendations for
integrity and for confidentiality to use for interoperability. These have COSE
definitions. Needs review and updates. Should be ready for Last Call by next WG
meeting.

Spencer Dawkins: Need a registry because these are specific for BPSec?
Ed: Yes, DTNs may need new cipher suites. Would point to existing in cases. In
security considerations, should include DTN specific notes, especially
regarding security at rest, and define new cipher suites. Spencer: When do you
expect to send this to IETF Last Call? Rick: Do we think it is ready? Needs
some more public review. Show of hands - 4 have read.

John Dowdell: Worth an early security AD review?
Rick: Yes, they do that. We can certainly request that, as it goes into last
call. Spencer: They do. And as an advert for this: all review teams and
directorates will do reviews as requested. You don’t have to wait until close.
Even seen one review before adoption. Transport is doing review now. Review
teams are becoming a lot more helpful and less source of late surprises. Rick:
Will take final question on Last Call to list - general consensus seems it is
good to go. Security people like to see more comments on the list. Marc: Need
to wait until BpBis is out – changes to BPBis would cause a problem, and BPSec
would drop out of Last Call. Scott: Do not anticipate significant changes to
BPbis.

Brian Sipos - TCPCLv4 presentation
----------------------------------

Few changes since last IETF. Not making major changes.

Resolved questions:
TLS mandatory to implement but optional to use. Negotiated per session.
New IANA registries to separate from TCPCLv3.
Extensions added to contact header.
Message content headers modified to be octet-aligned.

All comments to date have been incorporated.
No open issues - but also no concurrence.

A working implementation exists and is available for interoperability testing.
Up-to-date to current Internet Draft. Only CL behavior.

John Dowdell: TLS - why mandatory to implement but not use?
Brian: Strong objection at previous IETF to make mandatory to use.
Rick: Viewed as standard IETF practise to mandate to implement. A good
compromise. Brian: Endpoint can say it does support or not. Rick: Request to
post a link to the implementation.

John Dowdell: Have read the security considerations - because this is based on
another protocol (TCP), it should be referencing the TCP security
considerations, and note any further considerations based on the usage in
TCPCL. Offering text.

Rick: Due to the time of year, holidays etc., 2 week Last Call is not long
enough. Suggest end of August for end of Last Call. This applies to BPbis,
TCPCLv4. Time for final reviews.

Scott: If list decides BPSec is ready for last call, can it be included in the
same time scale? Rick: Yes, they will end up in sync.

Ed Birrane - Asynchronous Management Architecture presentation
--------------------------------------------------------------

Draft not updated from 05 at last WG, since no additional comments. Few emails
this week about additions.

How network management is different in a DTN - needs some automation and
autonomy. Does this draft satisfy requirements for management in a DTN? Is
something missing, can we add to this document as a WG item?

Most people in room are familiar with this draft.

Cover requirements, assumptions, constraints. There was an IRTF management
document we could draw from?

Rick (not as chair): think this is very interesting. Could spend a LOT of time
wordsmithing, would prefer to see it concise, general. Think a lot is there
already. Supporting this. Adopt, finesse if required. It is a useful asset for
the WG. Marc: Target is Informational document. John: This as arch and
informational. What's the roadmap for this topic? Marc: Charter does not have
room for a protocol. Scott: Support of Rick's idea and that we adopt this as a
WG item. Spencer: Text for NM req: Would not go into business for ourselves and
replace NETCONF - Would it be good do an applicability statement, not proposing
standards, based on the architecture document? Rick: Ed, myself, others have
been talking with netconf, netmod groups, and cbor-lightweight mgmt. group. The
point of this document is to say here are the arch specific to DTN with
applicability outside of traditional DTN community. Some interest from
data-center guys: async is useful when data is moving so fast. Rick (personal):
multi-disciplinary effort, not a re-invention for DTN. Relevant even if not on
charter. Spencer: Would be supportive if WG want to work on this. Marc: To me,
answer to this is having some draft of what that would be. Jefferson (?): Think
there are some specific parts of the old draft (IRTF DTN NM Req) that maybe
should be merged to this one. Other option is to leave this work as a new draft
for DTNRG. Rick: Please suggest on mailing list. Discuss where this should be
done and how much time to spend on it. Rick: Who says no: Rick: Who supports:
Show of hands: no one thinks it shouldn't be worked on - most people willing to
help work on this. Spencer: This is not what DTN does particularly - it can be
chartered, more people may come to DTN to work on this, not just people in the
room and on the DTN mailing list. Mention to IESG at afternoon session. Rick:
Ed and I talking to Benoit, netmod groups. Yang-push and async-notifiction.
This document described DTN perspective of mgmt.. How that is addressed may
happen out of this group. Spencer: put the work forward and it will find a home.

Marc: summarizing:
Aim for end August to be finishing Last Call. Love to get feedback if agreement.
Ask for WG adoption for Custody Transfer.
BPSec WG Last Call
AMA - ask for WG adoption.

Rick: Draft for recommendations for cipher suites - should this be rolled in,
or separate draft which needs to be adopted? Take to list. Ed on Jabber: Last
WG, Ran seemed OK with these as separate documents. Rick: Benefit is that we
can up-rev the recommendations without touching the protocol.

Thank you all :)