IETF DTN working group meeting
IETF 109 - Virtual

Fri 2020-11-20 12:00 - 14:00 (Asia/Bangkok)

Co-chairs: Rick Taylor, Ed Birrane

Agenda

• Admin, Chairs, 5 min.

  • Ed Birrane - new chair, welcome!
  • Be sure to engage when stuff comes back to WG during the reviews on DISCUSSION items
  • Don't mind overrunning time on key docs as they are blocking other work

• BPbis updates and IESG review comments, 15 mins
  (https://datatracker.ietf.org/doc/html/draft-ietf-dtn-bpbis-28)
  Scott Burleigh

  • Status - version 29 is now up (as of 2 days ago)
  • Looked back the past 4-5 months to get open questions
  • Big question: bpsec security within core bundle spec (if so how)?
    • First two paragraphs of section 9 seems to fit best, aside from Mark (poor Mark)
    • All agreed with some sort of mandate
    • Rick: reinterate statement in latest draft so everyone; mandatory to implement, optional to use?
    • First two paragraphs of Section 9 spoken out over meeting
    • MUST implement, OPTIONAL to use bpsec for a given use
  • Resolved with Magnus section 10.3 and 10.4
    • Clarify; back to spec required and will be rechecked (Magnus)
  • Mandate TCPCL?
    • Agreed that implementation is mandatory at a minimum for bp nodes
    • No further discussion AFAIK on list
    • Silence == consent (Rick)
  • Override bundle lifetimes?
    • enable congestion mitigation by deleting bundle lifetime locally
    • Rick: confused. what not disucssion intermeddiate agent before forwarding
      • Local drop decision, not a change of the primary block (forwarding info)
    • Ed: if we delete bundle by overriding lifetime and reason code as admin record for a purpose would the reason code that the lifetime expired or something else?
      • Bakc and forth - currently "traffic cleansed" reduction in traffic as reason code
    • Ed: different from normal lifetime expiration?
      • Yes
    • Stu: Resources are finite so drops will happen somehow. This seems a perfectly reasonable way to decide which bundles to drop, but should not be mandated as the only way? E.g. maybe I am holding a huge bundle, which if dropped, will allow many others to live on.
  • dtn-scheme endpoint id
    • tilde characters at bottom?
  • language of 10.6 about uri scheme type codes
    • recognize may be large than 255 so we permit that
  • time value denomination
    • millisecond instead of seconds/microseconds
    • devolved into immutability discussion
      • added text for this that cbor has to be in canonical form
    • Rick: what was decision
      • it is milliseconds right now
      • personally seconds was fine, but was a fine change to milliseconds
    • Rick: keen due to disruption tolernt over delay
      • correct
    • Will: was there a discussion of a variable denomination scheme?
      • there was discussion, for changes over time
      • this would violate immutability
      • for simplicity endorse at all times for all times be milliseconds
      • payloads could make a change - integrity block would not decode unless
  • section 4.3 mandatory or conditional
    • preference to be present conditionally for extension blocks, omit where not needed
    • opposed to make mandatory
    • Rick: mandatory to implement, optional to use?
      • from a comment by Benjamin
      • Some extension blocks seem important enough to be mandatory
    • Benjamin: can we ensure that if extesion is in will the other side understand it? mandatory to implement, optional to use
      • fine to mandatory to implement
      • mechanism with dealing with bp block that are not supported at forwarding node
        • flags what to do with unknown ext block
      • its not that we havent thought of it but question of it moot due to all need to be understood
    • Rick: confused by word ext, mechanism of additional functionality [extending protocol] as compared to mean flexible extra blocks
      • language silent in 4.3 if implementation is mandatory
      • clear that addition of block is due to constraint
    • Rick: Marc points out on chat: On extensions mandatory to implement: the issue is that we have a very disconnected network protocol, therefore we can't have a negotiation protocol between the two endpoints to negotiate the extensions and capabilities. Therefore, we may need to make extensions mandatory to implement. But that could create an issue in the future as new extensions could then require implementations to become unconformant right away.
      • this is different
      • Action for WG on this - please double check this section
    • Adam: ext is wrong word?
      • bad idea to add new terms
      • we can say in 4.3 ...?
    • Magnus: support explicitly change to avoid large sweeping changes
    • Ronald: a well known term for those in DTN!
      • Rick: yes, but need to make sure its definition understood
  • Rick: Take this to list
  • Rick: Propose stuff on list

• BPSec updates and IESG review comments, 10 mins
  (https://datatracker.ietf.org/doc/html/draft-ietf-dtn-bpsec-24)
  Ken McKeever

  • 1 outstanding discuss - mandatory security context
    • v24 fixes this we think
  • update for 108 highlight updates
  • Mandatory to implement security contexts (1 at least)
    • Ed: this text was drafted by Ran and brought in based on other security work
    • Rick: thank you Ran!
  • nested signatures
    • multiple sigs in a security operation
    • implemented through custom context/blocks - so outside mainline spec
      • Ed: getting questions related to bundle going through network and each node puts a signature on it based on security target. this becomes nightmare for verification, if madness is allowed then it should be in a single security context that allows multiple results otherwise 1. bad idea, 2. bpsec wont support out of box
      • Rick: mulit-verify scenario; in definition of spec the horrors would be avoided
      • Ed: processing behavoir can be defined in the context
  • signature/encryption over multiple blocks
    • added in custom security context
    • avoid madness inside mainline implementation
    • Rick: fan of reducing madness. original critisim was older versions were too flexible and security contexts are amazing
  • reason codes
    • v24 adds 5 new codes, to be added in bundle status report
  • commonality
    • negative values reserved
    • Ed: typo in bpsec is defined as unsigned int - must change to signed
    • Ed: suggestion came to Benjamin
    • Rick: this doesnt follow pattern of registered ids in bpbis - using negative seems unusual
    • Ed: no strong opinion
    • Brian: investion into cose/sbor does use position and negative for these kind of things
    • Rick: okay i see some benefits, avoid getting to IANA being like "no..."

• BPSec Default Security Contexts, 15 mins
  (https://datatracker.ietf.org/doc/html/draft-ietf-dtn-bpsec-interop-sc-02)
  Ken McKeever

  • companion doc to bpsec
  • take away:
    • in update Ed made from 01 to 02 additions for more flexability in the spec of context
    • adds details
  • multiple key lengths
  • context scope
    • Ed: this was based on list. how would u crypto bind a bundle to which it exists? sig of primary block in bib, include primary block would have same function of binding and carrying a single sig
  • Input canonicalization algo
    • put in for completness
  • slide 6
    • Rick: thought while reading; why is this not in bpsec itself? answer is in security context can use same primitave but different canonicalization
      • avoiding having bpsec having specific implementation
    • Ed: encrypt only portions of targets and ranges, etc. should not be in bpsec or defaults
  • context params
    • new params based on previous changes
  • Ed: as we work way - bpsec has a single discuss needs a single set to go with it. this needs to go out
  • Rick: need a doc sheppard for this
  • Magnus: yes but discusses arent enforced? not blocking but need to make progress as dependecy
  • Rick: agreed
  • Magnus: To be clear BPSec has no active discussed, but security context are mandatory to support per BPSec. Thus I-D.ietf-dtn-bpsec-interop-sc is a normative reference and BPSec can't be published prior to that document becoming available.

• TCPCLv4 updates and IESG review comments, 15 mins
  (https://datatracker.ietf.org/doc/html/draft-ietf-dtn-tcpclv4-22)
  Brian Sipos

  • Changed based on editorial (Ben) and Martin Duke
    • focused on PKI and TLS
    • make it behave with best current practices
    • pulling in line with other specs covering same ground
    • added termination refusal reason
  • Remaing questions
    • CAN_TLS contact header flag?
      • Ran/Ben discussion on list and take verbage
    • Supported version set?
      • currently just walks down the version list
      • could take 2-3 connection attempts until a pairing version
      • would add a little complexity to contact header, probably not worth?
      • add version too high, version too low?
      • Rick: does TLS handshake have a mechanism for this...?
        • this is top level issue, not like TLS
      • Rick: might have some ideas...
      • Near term is leave as open item
      • Rick: preference would be error response - like upgrade
        • that was alternative; version too high, version too low
        • discovery mechanism thing
      • Rick: problem with version too high; how do i know it is version 6?
      • Rick: take this offline
    • Is there value for PKI extended usage in DTN?
      • Rick: question about enforcement. as one side as tls connection and want to verify cert we can look at EKU OID and can make a local decision. should spec say "you must check eku and if not special thing for tcpcl you cant auth."
        • way this work; if cert has eku it must have this value
        • ca issued it for a purpose
      • Rick: happy with should term for this
        • way spec as follow recommend security policy
      • good news it converging
      • Ben: sometimes will not have eku at all - based on ca specifying. could have single cert with many eku's - unusal but valid. define eku and say that if one is received and has eku you should check for a specific one but not strong check. forcing to have it would cause many to break spec
      • recommend is aspirational but realizable
    • intent to publish another revision

• BPSec COSE context, 10 mins
  (https://datatracker.ietf.org/doc/html/draft-bsipos-dtn-bpsec-cose-02)
  Brian Sipos

  • take away
    • pki with existing mechanisms
  • last draft defines one security context with single id
    • idea is structure is same, what type of message in result will change
    • results are cose messages
  • cose profile
    • narrows down madness of cose to what is in results
    • has examples of this
  • specilizations
    • cose has protected vs non-protected header
    • params are not in aad so flipping bits will cause things to break
    • Ed: 1. thanks for writing this and having more than 1 sec contxt, can do comparisons when impls come out; 2. sec ctx template is out
      • has browsed template

• BPSec Security templates, 10 mins
  (https://datatracker.ietf.org/doc/html/draft-birrane-dtn-scot-00)
  Sarah Heiner

  • work on lifecycle of ext block
    • finite and unchanging
    • success and fail of block processing
    • value to document events in blocks cycle to discuss policy
  • bpsec alone does not get e2e security
    • need policy to derive semantic interop
  • defining sec policy
    • configurable actions to get consistent behavior
    • policy gives context and meaning
  • operation lifecycle diagram
    • 13 events
    • driven by role of processing node
  • proposed action
    • propose this lifecycle in bpsec
    • common language to discuss and define policy
    • can not std reactions but at least can std events
  • Rick: information draft is great! comments on list!

• UDP Convergence Layer, 10 mins
  (https://datatracker.ietf.org/doc/html/draft-templin-dtn-ltpfrag-00)
  Fred Templin

  • LTP fragmentation, anything with udp conv. layer
  • problem statement
  • observation
    • 64k udp
    • bursts in kernel
    • sendmsg determines network utilization
    • ip fragmentation may not be compatible
    • some os support send multiple message call
  • considerations
    • in ION implementation
    • further performance characteristics on the way
  • Rick: really interesting! question will go to list. retransmission and packet subdivision is interesting
  • draft expired but will be reuploaded in next couple days

• AMP message processing with Amp.me, 10 mins
  David Edell

  • sharing screen of demo
  • amp.me prototype
  • currently encode/decodes things
  • both web based and command line (javascript)
  • work in progress gui
  • adm listings
  • sql support in command line
  • planned to be in next ION release
  • Rick: effecitvely a prototype for stuff in network operation center for managing devices using amp. handling and decoding stuff and forms for humans to see traffic flow.
    • both devs and user support of it
  • Ed: really interesting work - what does it mean for async network management, can be really good to help configure and management the agents running the protocols
  • hope that tools will work together to get bigger picture
  • Ed: live demo is always better!

• Any other business / Open Mic, 20 mins

  • out of time
  • virtual in early march
  • please look at drafts in iesg review
  • please look at discusses
  • please provide feedback
  • thanks for the notes
  • secretary slot open!