Delay/Disruption Tolerant Networking (dtn) WG

IETF 120, Vancouver
2024-07-25, 09:30-11:30 PT, Canada

Area Director: Erik Kline
Chairs: Edward Birrane, Rick Taylor
Secretary: Adam Wiethuechter

Introduction, Note Well & Milestones (5 mins)

Speaker: Chairs
Document: N/A

cEB:
Welcome and good morning! Sessions are recorded and posted on YouTube.
Bound by Notewell. Please behave all of the time with impersonal
discussions focusing on technical solutions.
Agenda is online and other materials.
Please join via the meetecho queue for mic.
Agenda bash - no changes!
recharter discussion due to WG moved to INT area.

BPSec COSE Context Status (10 mins)

Speaker: Brian Sipos
Document: https://datatracker.ietf.org/doc/draft-ietf-dtn-bpsec-cose/

Background as last session.
This is a more featured and longer term security context than the
default.
COSE is expanding support for PKI and PKIX, near future for CBOR
Compressed Certs.
Reuse the COSE mechanisms in BPSec.
Editorial changes - minimum interop for some algorithms
Single layer encryption
Ticker 27 -- wraps one of the parameters in the byte string, to reduce
burden on the block processing. Not really specific to COSE Context but
probably should be for future ones. Something unbound with size and
complexity good to byte string wrap to simplify things.
Establish minimum interop of algorithms nothing about policy.
Has been through WGLC, but Ticket 27 might invalidate that?
Everything since WGLC (other than 27) has been editiorial text.

cRT:
Needs a shepard, its not hard.

cEB:
Anyone have issue with short WGLC due to the last technical change?
No objection.

Further implementation experience was what drove the change.

cEB:
Any other questions for this presentation? -- None

EID Patterns Feedback (15 mins)

Speaker: Brian Sipos
Document: https://datatracker.ietf.org/doc/draft-sipos-dtn-eid-pattern/

Chairs one up eachother on excitement.

Existing BP Agents, tools, configuration, etc. already have some notion
of a way to structure an EID set that is more than enumeration of EIDs.

Standardize a way to do this, so users of patterns have same
interpretation.
One way is glob or regex. Difficulty (IPN) those mechanisms are text
based, no instrinstic properties of EID. Can not be compressed.
Pattern matching have network effect. No retraining required if tools
share common syntax.
Proposal is compatible with IPN update.
Security identities
CIDR notion can be used not just for routing.
BP Configuration
Human friendly way to interperet and understand.
Updated and still open issues.
Update for Any-SSP, this has not be disucssed elsewhere. Interior router
does not need to understand all schemes. For a specific scheme, treat as
X.
IPN/DTN is tailored to scheme specific part.
Unknowns of DTN scheme pattern matching - defer DTN scheme patterns out
of document.
Any scheme specific pattern should not and does not need to have that
set logic. Enables assertions, catch problems quicker but no assumption
of being able to do it.
Adds EID patterns for PKIX Name Constraints for nice security uses.
Feedback to switch to RFC9485, disallow empty regex dtn scheme pattern,
and unknown dtn authority
EID pattern is NOT an EID and can not be interchanged.
EID pattern is superset of EIDs
Goal: incorporate feedback, trail and example implementations. Hackathon
topic?

RT:
Love it, implemented it! Got better as it went on. There is also CBOR
encoding that opens routing protocols to change things based on sets of
EIDs. You can build very dense lookup structures - FIB style lookups.
Pulling out DTN piece; agreed on list. Jut enough DTN wildcards for now
should stay in.

Any authority pattern, specific or otherwise might be good starting
point.

RT: we can move without having that yet.

Scott Johnson:
Excellent work! You are saying to target draft IPN update, support 2 and
3 element?

Way it works now, it always has 3 elements. there is no relation between
pattern and eid in terms of components. Uses logic but does not care if
started as 2 or 3. No restriction.

EK:
Like the range collapsing. Appropriate and useful. Putting into a
routing table, we will have all the same overlap problems again.
Cognizant of the overlap issue for using in routing table. Given that
definition of DTN is a string blob - can we just say string regex stuff
works (without slash)?

That is a doable thing and opens door for wildcard later.

EB:
JA: would we seperate dtn at large from this document? keep dtn matching
as generic as possible in this document, so subdocument may go finer?

Yes, its workable based on restrictions on DTN scheme.

EB: suggestion from chat to cavet that this is the most generic and
updates later.

cEB: would you think it ready for adoption?

Yes, want to do last update with DTN scheme but adoption call can
proceed.

cEB: any objection for calling adoption? -- none.

RT: implementation in Rust on GitHub:
https://github.com/ricktaylor/hardy/tree/main/bpv7/src/eid_pattern

cEB: any other questions? -- None

Updates to DTNMA Drafts (15 mins)

Speaker: Jenny Cao
Document: https://datatracker.ietf.org/doc/draft-ietf-dtn-adm/
Docuemnt: https://datatracker.ietf.org/doc/draft-ietf-dtn-ari/

cEB: DTNMA has been picked up by RFC Editor, expect in a few months.

ADM/ARI has been adopted.
ADM YANG is now seperated.
AMP has been revived.
Implementation from NASA-AMMOS and APL.

cRT: available?

Public repos of old versions, working to update.
List of topic areas (slide 3)
Depedency graph (slide 4)
ARI as arguments for type-naming statements.
Display hints.
AMP document revived and updated to line up with ARI
BPv7 is not the only binding to transports
Open issues:
patches for dtnma yang
display hints
hierarchy in namespaces: flat, or two level like EIDs. Do ODMs need two
levels or one?
ACL ADM needs some discussion
Implementation experience: things have been prototyped

RT:
ODMs and increased hierarchy. Think there is some benefit to have a bit
more hierarchy in the ODM standard, numbers could get big.

Brian Sipos:
If there is only one ODM namespace there is the increased possibility
for collision.

EB:
Referenced document on autonomy model, dtnma-14 and come back with
uestions.

cRT: foreshawoing at end of meeting.
Binding transport
How to management monitor and control devices in a DTN. This is not BP
specific.

EB: what this has done has taken standard automony model in deep space
how is this expresed in network management models.

AMP document has a BP binding but encourage other documents with other
bindings.

CoAP over BP (15 mins)

Speaker: Charles Gomez
Document: https://datatracker.ietf.org/doc/draft-gomez-core-coap-bp/

Intro on CoAP
Application layer for IOT envirorments, and their constraints.
Based on REST, but optomized for lightweight operation and overhead.
Goal: CoAP over BP
New section Encapsulating Bundle.
CoAP message carried as the block-type-sepcific data field
lifetime MUSTs
message response EID SHALL be identicial of source
MAY aggregate messages as one bundle; RFC8323?
Parameters and related times
Most are for CON messages
NON might be fine wiwhen protocol below BP support reliability and
congestion control

Laurent Toutain:
Wondering using non response option when getting feedback when
necessary?

Yes, might be useful and in future revisions.

Observer behavior. notifications should use timestamps of bundle.

RT:
Giving running over BP, do we think we are optomizing for rare case? An
implementation MUST push up as it solves an issue.

Agree.
coap+bp was suggest just leave as coap
new .arpa namespaces
.dtn.arpa
.ipn.arpa
Securing CoAP over BP
use of DTLS for CoAP over BP NOT RECOMMENDED

EB:
COSE Context for BPSec useful here?

OSCORE also uses COSE - might be already covered or if something needed

Following 6761 for new arpa schemes.

RT:
arpa registration - very interesting and parallel. Everything under
bp.arpa?

adEK:
Transport allocator and node number to domain and CLA stuff. This is
different - just need to fit a format for URI scheme. 81.2 node and
service?
Service name maybe not in dns?
This feels like CoAP thing rather than BP.

We might need to think again about all this?

adEK: encap, make sure that all be routed by same EID?

Depends on application a little bit. Aggregation...

adEK: coap server might unpack and do other routing?

Scott Burleigh:
Observation -- taro did an implementation for coap over bp. if
interested will send.

Did try to contact from published paper, no response.

Adam W:
Agree with EK on arpa. Might want to discuss as why put in .arpa if no
lookups?

Scott Johnson:
forward for CLA RRs have been approved for forward lookups.

cRT:
great to see application stuff over BP.

BIBE Updates (20 mins)

Speaker: Scott Burleigh
Document: https://datatracker.ietf.org/doc/draft-ietf-dtn-bibect/

Revised draft just pushed - expired before.
Motivation and history of BIBE
Open questions:
BPv7 as reliable CL ("custody transfer")?
"custody transfer" correct term?
How BIBE works:
CL which adapter is Admin Element
PDUs for BIBE and custody
BIBE CLA acts as BPv7 App to BPA (which sends data over its CLAs)

RT:
dont understand why retransmission time included?

rx aggregate acks, knowing the time the sender is a good indicatior

RT:
okay
can i have multiple bundles in flight while waiting for ack?
what if i lose an ack?

yes, and its aggregated ack you will fail on all bundles and all will be
retransmited.

cEB: at time, can we wrap up? want time for recharter disucssion

Yes! speed through the benefit diagrams.

RT: tunneling! you can do a lot with it!

cRT: this is very welcome and thanks for working on this!

Rechartering Discussion (20 mins)

Speaker: Chairs
Document: N/A

cRT:
For unware, we are part of INT rather than TRANSPORT area. We can think
of DTN as make internet work better rather than replacement for TCP.
Perfect time for recharter. 3.5 years old. Made good progress on things.
Old charter was focused on BP and its management piece.
DTNRG output was BP good thing and handed to IETF for standardization.
Hint delay/disruption is part of a lrager problem space than we were
looking at.
DTN is more than BP.
Recent work/conversations around Deepspace show there is interest in
adapting IP for DTN use-cases.
Hybrid models of BP/IP, inclusion of DTN an applications.
Broaden scope of charter
Maintain focus on BP as this is its home
Management pieces
QUIC over long latency and other DTN things. QUIC can be a CLA but also
can just use QUIC in some places only.
DNS role in DTN; DNSOPS, and other areas in IETF
WG decides and final decision is consensus on ML, but what should we
work on next?
What should be in charter, big hand wavey topics please!

cEB:
not every hop is a bundle hop

Dean Bogdanovic:
Getting involved in constelation networks with arch question, how to
make routing arch most effecient? Expanding work to other IETF tech
shoud be considered as industry wants solutions. IP reachabe UE wherever
it is. Real life is about reaching UE on earth surface, but also used
for flying in LEO or intra constellation and autonomic purposes.

Laurent Toutain:
Constrained networks. LP1 communities where there are long delays. No
permanant comms, and how to apply protocol.

cEB:
some early work was underwater acoustic work: kevin fall.

Alberto Montilla:
Fully support QUIC and how IP lives together with BP or on its own. How
to ake progress in time allocated.

cRT: we do great work with BP and not discarding it for something cool.

cEB: the IETF is a volunteer organization. If we bring energy in for
QUIC to have a place for conversation and learn from them.

AM: how do we deal with evolutionary vs. ???

adEK: one way to tackle that is that we have scope statements. we
estimate for this use-case/constraints. recommendations can overlap,
dont need to be disjoint.

Marc Blanchet:
puts mask on as Ben Solo and played star wars music.

misunderstanding as whole ip stack, quic is only a piece. considerations
with what alberto said - faculties of having to prioritie work for both
stacks. what we have seen in year for strong support for IP approach.
worried of consensous with storng positions that we have seen so far.

cRT: the best way to judge and concieve is on technical merit. if you
understand purpose than you can make objective judegement on the
technical aspect. ietf is best sdo for these wide ranging technical
standards.

Sauli Kiviranta:
Fully support what Marc said that IP is not QUIC. Opposing opinions and
want to expand to
Support objective asssement from Rick.

adEK:
If you are making comments and feedback sometimes hard to tell if you
want to a recharter or not.

cRT: as chair we should recharter
cEB: but we go to mailing list about it

Scott Burleigh:
Support Ricks comments on technical/objective based assement. Assert
strong opposition to express ideas is around technical that is not a
problem with justification.
For rechartering, will make a lot of difference. Some of things should
be advanced in priorirty (like multicast)

RT:
Rev to LTP as it references BPv6 not v7
Housekeeping things

cEB:
what are technical solutions to defined problems and what are the
problems we are solving.

Marc Blanchet:
I have no responded to the question and will not. To vague in what it
is. Only seems related as its not QUIC. Will delay until have more
details.

RT:
Some very broad examples, QUIC should say IP, none of that is binding.
Will make stuff with chair hat off on list. Show of hands here is not
about commitment.

Scott Johnson:
Concerning role of DNS and DTN. Wlecomes expansion of scope in this
area. We are getting good feedback in the IPNSIG community and DNS
community to understand the limiation of space comms.

cEB: echo from chat, ensure that there is alignment with CCSDS and IETF.

CRT: we have an official liason, chairs meet once a month to avoid
collisions.
cEB: thanks everyone! see you are 121!