IETF DTN Working Group Minutes November 15th, 2016 IETF97, Seoul, South Korea ======================================== Administrativia ---------------------------------------- - Ed Birrane and John Dowdell to take notes. - Notewell noted. Agenda Bashing ---------------------------------------- - No changes. Summary ---------------------------------------- - BPBis should be considered for last call. Will take to the list. - BPSec can be standardized without requiring standardizing a suite-b profile and without standardizing a security best practices guide. - DTNWG members encouraged to read and comment on the TCPCLv4. - Take to mailing list consideration of AMA for inclusion in the DTNWG items as part of defining network management requirements. - Ed Birrane and Brian Sipos to write ADM template and YANG model document. - John Dowdell and Rick Taylor to write internet draft for static addressing. Questions (Q), Answers (A), and Comments (C): Presentation 1 : BPBis (Scott Burleigh) ---------------------------------------- Review of items from the interim meeting. Walked through changes from list and interim review. C: Rick Taylor: Request comments now since we are getting ready for last call. C: Kevin Fall: Section describing custody delegation seems newer. Suggest people go read this section, as it is different than stuff from before. C: Scott Burleigh: Custodial retransmission relies on timeouts - intent of delegation is to give new info to current custodian about future transmission that custodian can use with other info to figure out most accurate timeout. C: Kevin Fall: Concern is situation where bundle requesting custody goes through nodes and all generate something like this and no-one takes custody, so amplification problem. Q: Rick Taylor: Any concerns with putting BPbis to last call? C: Ron in Õt Velt: Would like chance to review. C: Marc Blanchet: Final call is a chance to review. HUM on last call for BPBis Ready for last call: Several hums Not ready for last call: Silence. Presentation 2 : BPSec (Ed Birrane) ---------------------------------------- Summarized updates to BPSec. - Cleaned up language. - Added section on how to extend the spec for new security blocks. - Discussion of three created expired drafts. Q: Rick Taylor: Given your ÒOther Security BlockÓ (OSB) section, do you need additional reserved values and an IANA request section? Are you suggesting we request values for 3rd party OSBs? A: Ed Birrane: No. OSB authors need to go and register with IANA. No need to pre-reserve numbers. Q: Ed Birrane: Can we standardize BPSec without also standardizing other documents: the suite-b profile/cipher-suite specs and the security best practices? Q: John Dowdell: Can these be informational, as examples? A: Ed Birrane: Yes, can be useful for people who want to deploy in certain areas, but should not hold up bpsec in standards track. C: Marc Blanchet: One answer is whether the documents are necessary to bpsec. <> C: Marc Blanchet: If you are defining a new registry you can place values in the specification. Otherwise, you must leave these values TBD and let IANA assign them. Presentation 3 : TCPCLv4 (Brian Sipos) ---------------------------------------- Reviewed changes since last IETF - Reduced sequencing variability from TCPCLv3 - Does not change workflow of TCPCL - Uses fixed sequence, removes all SDNV - Initiate TLS, add transfer id, add segment/transfer maximum size Q: Rick Taylor: Who has read the latest version of the draft? << No hands >> Q: Brian Sipos: I removed the TLS cipher suite and referred instead to best practices. Is that OK or do I need to specify a minimum cipher suite? C: Marc Blanchet: We should ask Spencer. Current policy is to encrypt everything everywhere. C: Rick Taylor: Also, there is a privacy concern over discovering fact that two parties are having a BP conversation. C: Spencer Dawkins: Speaking as AD and channeling Security ADs, right answer is that in order to not encrypt everything everywhere, you need security considerations to explain that. We should not produce protocols that are not safe for the Internet and transport is usually not safe over the Internet. I would take these documents to the IESG if you can pull off a convincing security considerations section that does explain what the exposures are. Q: Marc Blanchet: Where should security be discussed? You have BP, multiple convergence layers beneath it, and BPSec. You could have security in each area, or in none. A: Spencer Dawkins: The considerations should be in the base protocol. It is the only thing that you know everyone is running. I would be happy to take first draft text and talk with the security ADs. Do not want to start a conversation without text because they have really lurid imaginations. Q: Rick Taylor: Does the security best practices guide that Ed talked about help us here? C: Scott Burleigh: The security section in BPbis is inherited from RFC5050. I will update this, but am not an expert in this area and would ask for some review. C: Spencer Dawkins: Security ADs can be asked to review before a WG last call. C: Ed Birrane: Security best practice guide does not help here. it is a recipe book for achieving security results, but is driven by security considerations, not the other way around. C: Ed Birrane: BPSec has a security considerations section that may be useful for BPbis if we want to migrate it over. Presentation 4 : AMA/AMP (Ed Birrane) ---------------------------------------- Walked through document map of network management documents and then each in turn. - AMA as a description of the motivation/needs for asynchronous management. - ADMs and templates as a way to capture the data model for this concept - AMP as one (of maybe many) ways to communicate these models on constrained, embedded devices. Q: Rick Taylor: Any YANG gurus willing to help moving the ADM model to be more YANG-like? Do we think ADM in YANG is necessary or can we re-use existing work in YANG? C: Eric Voit: I like the AMA/AMP concept, I know YANG, and would be happy to review a YANG ADM. Can see problems, but are there any common rules and syntax between platforms? Q: Marc Blanchet: This looks like MIB++ with additional semantics. Is there a reason to use YANG? A: Ed Birrane: YANG has RPCs, data type definitions, so seemed reasonable. For a constrained system we canÕt use long strings. We need to encode in CBOR for constrained devices. C: Marc Blanchet: Using YANG may reduce the complexity of the model. C: Ed Birrane: AMA/ADM/AMP are not tied to SNMP OIDs. We just need a good, compact encoding of identifiers. C: Eric Voit: In SNMP for every trap you have to define what that is, you canÕt define your own. YANG has no pre-defined traps - can do any query you want. This sounds like the best of both. C: Rick Taylor: Like how data models can be simply defined in YANG. How we transmit the data is a different problem. C: Brian Sipos: Important to note that for AMA/AMP, YANG is decoupled from NETCONF. Using the YANG data model is useful, and there are no technical limitations because YANG is open-ended. Q: Ed Birrane: Brian, will you help author the ADM Template in YANG? A: Brian Sipos: yes. Also, there is an expired draft for a YAND ADM model. Q: Rick Taylor: Are you bringing these drafts to the DTNWG for adoption? A: Ed Birrane: Yes. C: Marc Blanchet: Network management is not yet in the charter. C: Ed Birrane: Agreed not all of this is in the charter. Suggest that the AMA be submitted to speak to the existing charter item of network management requirements. C: Rick Taylor: We should take this to the list. Presentation 5 : Static Addressing (John Dowdell) ---------------------------------------- Q: Jorge Ott: DidnÕt we have something like areas or zones 15 years ago that gave a 2-layer hierarchy? Are we introducing something that we previously abandoned? A: Scott Burleigh: They were regions, and the term region should be exhumed and rehabilitated but not for this concept. Addressing is not routing and we are talking 2 distinct things: (1) migration of the bundle into a namespace shared with the destination namespace so routing can happen and (2) topological routing itself which, for scaleability might need to be hierarchical and federated and need a structure for that. My preference is to use the term ÒnamespaceÓ for (1) and the term ÒregionÓ for (2). C: Rick Taylor: This is similar to MPLS and label switching. Q: Marc Blanchet: This is like tunneling to another namespace. Do we really need this? Are people gatewaying between different namespaces? Q: Jorge Ott: The slide has 2 separate clouds that presume namespaces are neatly isolated, similar to topologies. If you think in this way, a resolver may make sense. In a grand deployment, many routers may support multiple namespaces. Will this be workable with intertwining namespaces? C: Rick Taylor: The default route is a resolver. If you do not understand the namespace, give it to someone else; this is late binding. A: Scott Burleigh: The resolver is something that knows how to do the binding, and the source is someone who does not know how to do that binding. It is the ability to do that late binding that is an issue. Regarding tunneling, that is a way to do this, but also doing this with some pushing and popping of extension blocks may be a lower impact way of doing it. C: Rick Taylor: There is an implicit understanding when tunneling that the wrapped packet/bundle is now opaque and to look at that external header for forwarding. Reason I am keen on the ESB, there is nothing to stop intermediate nodes en-route from looking at the primary block (unencapsulated) and saying ÒI know where to route thisÓ. Q: Ed Birrane: Do all resolvers understand all namespaces and, if not, does this imply something like BGP for resolvers? A: Rick Taylor: No, different resolvers can understand different namespaces. And no, we do not need BGP, we would look to a DNS-like architecture instead. C: Jorge Ott: I recommend to NOT leave out the Òden:Ó from the bundle. Some schemes, like named information could be useful, so want to avoid always assuming den:. The scheme might not be obvious. Q: Marc Mosko: For URIs, // is not part of the path. Why did you choose to use // in this way? A: Rick Taylor: because the open source implementations of DTN use it this way. C: Scott Burleigh: We would have 2 levels of scheme. In BPBis an EID is a scheme ID and a scheme-specific part. The SSP can be numeric or whatever. Probably not a problem, but an angle I had not realized. Think it is doable. Q: Rick Taylor: If John and Rick wrote this up as a draft, would the DTNWG want to read it? A: Jorge Ott: It would be an interesting exercise. A: Scott Burleigh: At the very least, a definition of the DTN scheme would be produced. Even if it did nothing else, that would be enough.