Minutes IETF105: dtn
minutes-105-dtn-00

IETF DTN Working Group Minutes
July 26th, 2019
IETF105, Montreal
Chairs: Marc Blanchet & Rick Taylor
================================================================================

Administrativia
--------------------------------------------------------------------------------
- Notewell noted.
- Ed Birrane, Adam Wiethuechter, and Ron in 't Velt will take notes.
- Reviewed status of WG documents:
     * 3 major items in the review pipeline (BpBis, BPSec, TCPCLv4)
     * BPBis and BPSec reviewed by AD. TCPCLv4 reviewed by next week.
- Some new documents need to be moved to WG Last Call
     * Minimal TCP CL, BPSec Security Contexts, Bundle-in-Bundle Encapsulation


Agenda Bashing
--------------------------------------------------------------------------------
- No changes.
 


YouTube link to proceedings:
--------------------------------------------------------------------------------
https://www.youtube.com/watch?v=UqO7P72jOQQ



ACTIONS
--------------------------------------------------------------------------------

0. Chairs to schedule interim meeting to discuss milestones, recharter, etc.
1. DTNWG to review all changes to BpBis on mailing list.
2. M. Wsterlund to provide normative reference for time. 
3. S. Burleigh to post to mailing list discussion on max hop count limit.
4. M. Westerlund to review TCPCLv4 next week.
5. S. Burleigh to post request on SHOULD vs MUST on BPSec implementation and
   SHOULD vs MUST on BPSec usage. 
6. S. Burleigh to bring IANA registries from RFC6255 into Bpbis document.
7. S. burleigh to discuss whether CRC is optional on the mailing list.




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


Presentation 1: BpBis AD comments (Scott Burleigh)
-------------------------------------------------------------------------------
Review of individual comments received for BpBis from AD review.


=== DTN URI Scheme ===

(Q) R. Taylor: DTN URI scheme useful to let external tooling (e.g., Safari)
               know it is using a DTN protocol stack. Less useful if this is
               just a way to distinguish endpoint names in a DTN only network.
               Is URI the right thing to do here?

(A) S. Burleigh: Schemes need to be defined somewhere. No strong opinion on 
                 whether needs to be a registered URI scheme. We have IPN
                 in the registry now and DTN defined in this draft. Maybe that
                 is sufficient.

(C) M.Blanchet: Two are registered and deployed.

(Q) R. Taylor: Is this a public definition supported by external devices?

(C) M. Westerlund: Good question. If you use formatted URI, you should keep the
                   registration, even if used primarily by DTN. Large freedom
                   for placing items in registry.

(Q) R. Taylor: Agree to register DTN as a top level URI. Is IPN also a top-level
               URI or is it kept under the DTN scheme instead?

(C) E. Kline: No harm in keeping DTN, it will not be recycled for something
              else. Don't know enough about IPN.

(C) S. Burleigh: IPN exclusive to current implementation and deployments of DTN
                 to identify endpoints. Running on space station.

(Q) E. Kline: Do we need a mapping between them?

(C) R. Taylor: Naming and addressing is a future charter item. If you had a
               single DTN scheme it would be dtn:free-text, such as dtn:ipn:...

(C) S. Burleigh: People are deploying what we currently have specified.

(C) M. Westerlund: You need to decide. There are instructions in the protocol.

(C) R. Taylor: Retract my suggestion - the status quo will work for us.

(Q) S. Burleigh: Does section 10.3 satisfy need to define DTN scheme?

(A) M. Westerlund: yes.


=== Time Representation ===

(C) M. Westerlund: Inserted text is fine. No intention to override WG consensus.

(C) S. Burleigh: Request for Normative Ref to use for time. 


=== Lifetime ===

- no comments


=== Report-To EID ===

- no comments


=== Maximum Hop Count Upper Limit ===

(Q) S. Burleigh: This is out of scope. We can jam a number, but what number?

(C) M. Blanchet: Hop count useful to detect routing loops. Setting a large
                 number helpful: if you reach a large number, you are in a loop.

(C) Ron in 't Velt: Sometimes a routing loop can be a good thing.

(C) S. Burleigh: How about 255?

(Q) R. Taylor: Can intermediate nodes replace the extension block? Is so, then
               a lower number makes sense. If this is immutable a larger number
               makes sense.

(A) S. Burleigh: Extension blocks can be added, changed, or removed.

(C) R. Taylor: Take to the mailing list.


=== Congestion From Status Report ===

(C) S. Burleigh: Added text that policy mst exist to reduce extra traffic. This
                 requires management mechanism to defend against that. Cannot 
                 legislate that in this spec. 

(C) M. Westerlund: Ok.


=== Node Disavowal ===

- no comments


=== Incorrect section reference ===

- no comments


=== Definition of unintelligibile === 

- no comments


=== Service Description ===

(C) M. Westerlund: Comments for this may come back in review of CL documents.


=== Mandating BPSEC ===

(C) S. Burleigh: Agnostic on whether BPSec is required.

(C) M. Blanchet: Important use case is space where DTN is both network protocol 
                 and layer down. Just as trying to force IPSec with IP failed,
                 forcing BPSec in this case may also fail. Deploy security
                 services higher in stack closer to application level. Also
                 BPSec heavy duty and forcing all implementations may be too
                 much. Strongly against requiring it in all implementations.

(C) M. Westerlund: Understand argument - choices for particular deployments. 
                   Try recommending BPSec and make it clear this is a 
                   deployment consideration. This is up the stack anyway and
                   not wasting store-forward resources is relevant.

(C) S. Burleigh: Spaceflight increasingly needing security. End-to-end for BP
                 will be good for that. Recognize processing overhead. 
                 Inclination is to say BPSEc strongly recommended not required.

(C) R. Taylor: Say implementation is required but not required to use it.

(Q) M. Blanchet: If I am a relay in space why do I need BPSec?

(A) E. Birrane: Multiple ways to achieve security. BPSec only if you need block
                level security. If relay needs to do inspection to throw out
                bad data, then yes, relays need BPSec. Relays should filter.

(C) E. Birrane: I vote for strongly recommend.                

(C) M. Westerlund: If this is required you need to say which context(s) are
                  required. Think this should be recommended.

(C) M. Blanchet: In IETF we woudl say SHOULD instead of MUST.                

(C) R. Taylor: We should hum on the issue.

Those in favor of SHOULD: (many hums)
Those in favor of MUST:  (no hums)

(Q) Ron in 't Velt: Does MUST mean must implement or must use?

(A) R. Taylor: Consensus here is SHOULD implement. Take to the list.

=== Encryption on CL ===

- no comments


=== Reason code for bundle storms ===

- no comments


=== Guidance for Setting lifetime and Max Hops ===

(C) S. Burleigh: Still research topics. Ought to emerge from course of 
                 operations and deployment and research. Prefer to not say more.


=== IANA Considerations ===

(C) E. Kline: RFC7116: title is "LTP CBHE and BP IANA registries"

(C) M. Westerlund: Bring registration rules for registries (including RFC6255)
                   into the BPbis document. Thenobsolete RFC6255.


=== Registries ===


(C) R. Taylor: Developers look to registries for enumeration sizing, etc... If
               they might mix we should separate them. 

(C) S. Burleigh: We don't need new registires for BPv7 because it is a superset
                 of BPv6.

(Q) M. Westerlund: Can anyone extend BPv6 registries?

(A) R. Taylor: Not in the IETF. Bpbis obsoletes RFC5050. If others take 
               ownership they maintain their own.


=== CRC References ===

- no comments


=== Normative References ===

(Q) S. Burleigh: Can we treat information references as normative?

(A) M. Westerlund: Need to check. It is possible to reference informative
                  documents, but need to specify that during last calls. 

-- this is overcome by events, pull RFC6255 into BpBis and obsolete 6255 ---


=== Primary Block Immutability ===

- no comments


=== Optional CRCs ===

(C) S. Burleigh: CRCs optional. Don't need them if you have BIB. 

(C) M. Blanchet: Source may not use BPsec and not know that some downstream
                 node will use BPSec. If you ar eunsure, you should use CRCs.

(C) S. Burleigh: If source does use BIB, then it does not need CRC.                

(C) M. Westerlund: Might be easier to always use CRC. May be an unnecessary
                   optimization to try and remove it. 

(C) E. Birrane: If we have a bundle with 100 blocks and each block carries a
                CRC the size and processing of each one is going to add up. 
                Mandating CRC doesn't scale. 

(C) Ron in 't Velt: We must also consider when a bundle is corrupted at rest.

(C) R. Taylor: CRC on the primary block is important - primary block is 
               immutable. 

(C) M. Westerlund: No strong opinion. Might require CRC only for certain blocks.
                   Use should be based on deployment. Implementation 
                   mandaotry and deployment optional. 

(C) S. Burleigh: Discuss on list. Recommend CRC mandatory on the primary block
                 and optional for others. 

(C) M. Blanchet: Let's hum.

MUST have CRC on primary block? Some hums.
Don't need CRC: no hums. 


=== Obsoleting RFC5050 ===

(C) M. Blanchet: Like IP there concurrently exist multiple versions of the
                 protocols. When you say one obsoletes the other, it just
                 signals that there is a new version, bot that you cannot use
                 the older version.

(C) S. Burleigh: Obsoleting has to do with RFC standards track and 5050 was
                 experimental.

(C) M. Westerlund: Since RFC5050 is IRTF need to consult on them, but 
                   probably fine. IESG is also working a new set of labels to
                   be clearer.

(C) E. Kline: Note that IPv6 does not obsolete IPv4 - they are not the same
              thing. If not obsoleted, move 5050 to historic draft document.


(Q) M. Westerlund: What is the intention for BPv7? 

(A) S. Burleigh: Intention is for BPv7 to become the standard.


(C) R. Taylor: Hearing consensus: BPv7 is lessons learned from BPv6.




Presentation 2: BPSec AD comments (Ed Birrane)
-------------------------------------------------------------------------------

BPsec : Ed
- just got commetns two days ago
- give some recommendations

slide 1:
- 11 comments
- 6 minor changes
- nothing changes really, just cleanup and clarification
- will pause and move on

slide 2:
- security context description
- create second doc
- can site in section 1.2

slide 3:
- term for security souce
- no defintation for peer of such (security dst)
- there was a concept
- difficult
  - conflated routing and security
  - could tunnel
  - spec does not mandate
- can give name,
- will return to concept as whole

sldie 4:
- BIB over BCB?
- if have blocks end-to-end in nature, cant use encrypted payload
- if bundle has two security context
  - 1st for payload
  - 2nd for signature
  - create two security users
    - those who have keys
    - those who can check integrity

slide 5:
- concept of security context
- provide additional service on blocks
  - blocks refencing eachother is not recommended
- security could define additional results captured by bcb
- no contraints as part of security context
- check section 7
- larger issue is circular deps and ambaguity with those kind of blocks
- happy to provide more calrify text and example
magnus:
  - point to encapsulation?
ed:
  - elegant way to do it
  - totally resaonable
magnus:
  - foward refence to it
  - despirtre limitations
rick:
  - analogy to ipsec
  - tunnel mode or transport mode

slide 6:
- uniquiness of security serivce in bundle
- only target block and security service or aslo context itself?
- multiexcruption
- multikey/algo
- rather than with multi bcb and have discussion over how it works
  - push into sec context
- bcb -> sec context (1:1)

slide 7:
- use of reserved bits flag on sec ctx
- done for backwards compatability
- no issue with reordering bits

slide 8:
- AEAD cipher req?
- bpsec 06 for review, strongest comment was (from sec area) mandate for AEAD
- bibs are plaintext
- bcb are ciphertext
- should be gen sig

slide 9:
- policy guideline for removed blocks along way
- can happen
- we did consider it

sldie 10:
- security src or bundle src
- manifest blocks
- they must exist in bundle
- can be signed
- destination check for it and if missing questionable
- many other ways to handle
- 8.2.2 discusses this
- must be a bib that signs primary block
  - if not, not within policy (from out of band)
- not appropiate to define in bpsec doc

slide 11:
- clarify moving sigs

sldie 12:
- what does this mean?
- existing cipher suite ids, why make our own?
- would that cause confusion?
- came to understand enumarting sec ctx no cipher suites
- strike all text as it does not apply

slide 13:
- how sec dst determined?
- its unclear who should process secuiryt block
- if bundle has been at rest long time, things have changed
- waypoints for sec processinf
- boundries between sec and dst are dynamic
- policy can determine if you should be evaluation security service
- policy to add sec service and policy to use
- encap with bundle to bundle

slide 14:
- registry for iana for context ids
- will add


Presentation 3: Asynchronous Management Protocol (Andrew Haberman)
-------------------------------------------------------------------------------

Andrew went through AMP-07 updates and converter utilities.


=== AMP-07 CBOR Encoding Updates ===

(Q) R. Taylor: You have removed implicite structure not using CBOR encoding, to
               remove TLVs. So, present entire command as an OCTET string. Does
               this mean you are adding whitespace sensitivity to these? Or 
               preparsing into a canonical form?

(A) A. Haberman: Removed array headers for some (not all) structures. Do some
                 preparsing.

(Q) R. Taylor: So, unpack, concat, and then encode?

(A) A. Haberman: Yes.                

(Q) R. Taylor: As DTN Chair: AMA/ADM/AMP work has been shopped to find a home in
               OPs area (netmod, anima, etc...). That area not interested but
               this is because mostly relevant to DTNs. The work is far down
               the line and would like to see it taken on in DTN. Will that
               cause a problem at the AD level since DTN is in transport area?


(A) M. Westerlund: Will require a recharter, so discussion will happen at next
                   meeting. We should discuss offline.

(C) M. Blanchet: Spent 2 years shopping for a place. Concern is that the new
                 OPs ADs will cause reboot to shopping this. It has been
                 shown in the WG that people are working on this. When any
                 network management work goes into last call we can do a
                 cross-area review with OPs.



Presentation 4: Future Work Items (Scott Burleigh)
-------------------------------------------------------------------------------


=== BIBE ===

(C) S. Burleigh: Urgently needed for 2 reasons: First, custody transfer taken 
                 out of BPv7 and need to reatin feature and BIBE does that.
                 Second, BPSec removed security destinations and BIBE is one
                 way to get security-destination-like behvior. Can also
                 prevent traffic analysis to obscure primary block. Also
                 useful for source-path routing. Initial draft posted in
                 January that has no major issues. Needs review.

(C) M. Blanchet: Agreed to add BIBE.                 



=== Quality of Service ===

(C) S. Burleigh: QoS taken out of BPv7. Customers want it. Customers using 
                 it in implementation.  


=== Key Management ===

(C) S. Burleigh: Draft exists and should be discussed in WG.


=== Network Management ===

(C) S. Burleigh: important to manage these networks.


(C) M. Blanchet: Also convergence layers (LTP? SMTP?), addressing, naming,
                 routing, neighbor discovery, NM, key management, quality of 
                 service. 


(C) M. Westerlund: No issues. Submit new milestones were needed.