[dtn] Benjamin Kaduk's Discuss on draft-ietf-dtn-bpsec-18: (with DISCUSS and COMMENT)
Benjamin Kaduk via Datatracker <email@example.com> Thu, 06 February 2020 03:15 UTC
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CB38112006E; Wed, 5 Feb 2020 19:15:41 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
From: Benjamin Kaduk via Datatracker <firstname.lastname@example.org>
To: "The IESG" <email@example.com>
Cc: firstname.lastname@example.org, Scott Burleigh <Scott.C.Burleigh@jpl.nasa.gov>, email@example.com, Scott.C.Burleigh@jpl.nasa.gov, firstname.lastname@example.org
Reply-To: Benjamin Kaduk <email@example.com>
Date: Wed, 05 Feb 2020 19:15:41 -0800
Subject: [dtn] Benjamin Kaduk's Discuss on draft-ietf-dtn-bpsec-18: (with DISCUSS and COMMENT)
List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." <dtn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dtn>, <mailto:firstname.lastname@example.org?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dtn>, <mailto:email@example.com?subject=subscribe>
X-List-Received-Date: Thu, 06 Feb 2020 03:15:42 -0000
Benjamin Kaduk has entered the following ballot position for draft-ietf-dtn-bpsec-18: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dtn-bpsec/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I think we need to discuss how this document refers to the level of security provided by the network, "insecure network"s or portions thereof, etc.. In the normal RFC 3552 threat model, we assume the entire network is under the control of an attacker. Any exception to that is going to be treated as a special case (usually only grudgingly so), e.g., if a portion of a network is under administrative control of a single entity and physically controlled as well, or if a network uses MAC-layer security technologies. I don't think this mindset is well-reflected in the current text. I agree with Mirja that we need more clarity on usable security contexts for interoperable implementation. My suggestion would be to define a security context that is usable for normal Internet hosts over the normal Internet (i.e., not a stressed network) to have as a baseline secure configuration, and customizations for other environments would be treated as deviations from that well-established baseline in terms of algorithms and security strength. I furthermore note that even after reading draft-ietf-dtn-bpsec-interop-sc I do not have a clear picture of exactly which bytes are used as input to the various cryptographic algorithms and how the output is encoded. For example, is the block data contents of a target block always going to be a fixed-length bstr? Can the process of applying protection change whether the #6.24 tag is present? I understand the need to provide a defined processing order for message deprotection (and thus to avoid having the same operation applied to the same target), but I still don't have a clear picture of why we can't define things in such a way that allows (e.g.) nested signatures over the same content block. I understand the current mechanics where in the abstract model we only can protect a single block at a time (not a combination of blocks), so that blindly applying the current mechanics to an attempt at a nested signature would produce the problematic ambiguity of processing order, but I don't understand why it has to be that way. Relatedly, I think that the current formulation where the target list can be freely modified/split into separate BIB/BCBs by any waypoint will probably leave us open to some semantic attacks that drop some blocks but not others, when there is supposed to be semantic interdependence between those blocks. The diagram in Figure 2 seems to incorrectly indicate a degree of freedom in the number of results per target: if we are applying the same operation to all blocks in the target array, the operation should produce the same number of results for all target blocks, thus constraining 'K' to be equal to 'M'. Exclusion of most of the block parameters from confidentiality processing seems to be a critical flaw in the cryptographic hygeine; I think we should include the Block Type Code, Block Number, possibly Block Processing Control Flags, CRC Type and CRC Field (if present), and Block Data Length fields as "additional data" input to the AEAD to provide integrity protection, as well as use them as input to BIB calculation. Failing to include these parameters seems to leave us prone to "slice and dice" style attacks. Also, the description in Section 4 is unclear about whether the surrounding CBOR array encoding is excluded from AEAD iput (though it doesn't really seem like it would make sense to re-encode as a one-item CBOR array prior to applying message protection, the current text is worded such that one might think the array framing is not explicitly excluded). Section 9.1 gives an example of using a (presumed unprotected in the absence of any disclaimer) cryptographic key as a security context parameter; given that (per Section 3.6) the parameters are included in the wire-format abstract security block, and not subject to BCB protection, this is wholly insecure and cannot reasonably be used as an example. (At least draft-ietf-dtn-bpsec-interop-sc had a bit of note about "encoded or protected by the key management system" to give this a veneer of respectability.) There's a couple places (noted in the COMMENT) where we claim some combination of things to be "insecure" without justification; in the noted instances this doesn't seem to be immediately obvious, so I think the justification is needed (or the claim should be removed). Section 7 includes a note that "It is recommended that security operations only be applied to the blocks that absolutely need them. If a BPA were to apply security operations such as integrity or confidentiality to every block in the bundle, regardless of need, there could be downstream errors processing blocks whose contents must be inspected or changed at every hop along the path." While this statement, taken literally, is true, it also seems inconsistent with, e.g., BCP 188, as well as the RFC 3552 threat model, let alone the BPSec threat model of Section 8. I suggest phrasing that makes applying security operations the default behavior and requiring justification to diverge from that. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for the well-thought-out security considerations section; it's a pretty good treatment of the relevant issues for DTN-relevant scenarios and I only have minor comments about it. Unfortunately, I have pretty substantial comments on much of the rest of the document, which in many places seems internally inconsistent as if some sweeping changes were attempted but not completely implemented. (E.g., are security contexts IANA-registered values or site-local, including user-defined? Is there a single target block of a security operation or a list of targets?) Even among the comments that do not quite rise to Discuss level, there are some pretty significant flaws, especially relating to cryptographic terminology and usage. Section 1.1 3. Hop-by-hop authentication is a special case of data integrity and can be achieved with the integrity mechanisms defined in this specification. Therefore, a separate authentication service is not necessary. Data integrity is one thing that can be provided by hop-by-hop authentication (in combination with trust in the nodes on the path), but it is not the only benefit provided by hop-by-hop authentication; I don't think we should conflate them in this way. Section 1.3 The Bundle Protocol [I-D.ietf-dtn-bpbis] defines the format and processing of bundles, defines the extension block format used to represent BPSec security blocks, and defines the canonicalization algorithms used by this specification. I see a specification in draft-ietf-dtn-bpbis for a "canonical block structure" but not for a "canonicalization algorithm" used to produce them. Section 1.4 o Cipher Suite - a set of one or more algorithms providing integrity and confidentiality services. Cipher suites may define necessary parameters but do not provide values for those parameters. Could we give examples of such parameters? If it's things like "secret keys" that seems okay, but if it's "key length" or "number of rounds" I don't think that's appropriate to leave as a free parameter, and would be better expressed as separate cipher suite values. Is there a 1:1 mapping between security context and cipher suite? Should this be "integrity and/or confidentiality services"? o Security Service - the security features supported by this specification: either integrity or confidentiality. I wonder if we could make the definition more general in case future security services are defined in the future. Section 2.2 A bundle can have multiple security blocks and these blocks can have different security sources. BPSec implementations MUST NOT assume that all blocks in a bundle have the same security operations and/or security sources. nit: is it better to say "have the same security operations" or "have the same security operations applied to them"? The Bundle Protocol allows extension blocks to be added to a bundle at any time during its existence in the DTN. When a waypoint adds a new extension block to a bundle, that extension block MAY have security services applied to it by that waypoint. Similarly, a waypoint MAY add a security service to an existing extension block, consistent with its security policy. What about modifying existing blocks (e.g., Previous Node, Bundle Age)? Section 2.3 Some waypoints will determine, through policy, that they are the intended recipient of the security service and terminate the security service in the bundle. For example, a gateway node could determine that, even though it is not the destination of the bundle, it should verify and remove a particular integrity service or attempt to decrypt a confidentiality service, before forwarding the bundle along its path. This would not really be "end-to-end" as we claim in the Introduction. Some waypoints could understand security blocks but refuse to process them unless they are the bundle destination. I'm a little confused as to why this would be desirable. Section 2.4 in the implementation of their security services. BPSec must provide a mechanism for users to define their own security contexts. That seems highly risky, since defining a security context involves getting a value allocated by IANA in a 16-bit "Specification Required" codepoint space and it seems pretty unlikely that all users would actually do that. For example, some users might prefer a SHA2 hash function for integrity whereas other users might prefer a SHA3 hash function. The security services defined in this specification must provide a mechanism for determining what cipher suite, policy, and configuration has been used to populate a security block. Doesn't this imply a requirement for a registry or registries of the relevant types of values? Or are we claiming that this will all be part of the specification for the security context? Section 3.1 the bundle destination. Security-aware waypoints add or remove BIBs from bundles in accordance with their security policy. BIBs are never used to sign the cipher-text provided by a BCB. nit: most of this text is good about using a generic treatement of "integrity protection", but "sign" is a subset of the ways to get integrity protection. of security policy. BCBs additionally provide authentication mechanisms for the cipher-text they generate. I suspect this is going to be authentication in the AEAD sense, that is, protection against malleability (as opposed to source authentication that provides an indication of the identity of the party applying the protection). I don't think it's best to refer to such properties as "authentication mechanisms" as opposed to "integrity protection" Section 3.2 bundle. Since a security operation is represented as a security block, this limits what security blocks may be added to a bundle: if adding a security block to a bundle would cause some other security block to no longer represent a unique security operation then the new block MUST NOT be added. It is important to note that any cipher- Is it permissible to remove the existing block before adding the new (conflicting) one? o Signing the payload twice: The two operations OP(integrity, payload) and OP(integrity, payload) are redundant and MUST NOT both be present in the same bundle at the same time. They're not redundant if a recipient might have different levels of confidence in the two (different) signers. Though, IIUC, having the "second" signature include the first BIB as the signed content is permissible as a workaround, right? [ed. reading further this understanding seems contrary to the current text of the spec] Section 3.3 Under special circumstances, a single security block MAY represent multiple security operations as a way of reducing the overall number I'm not so sure that this is "special circumstances"; I would expect wanting to apply the same operation to multiple blocks to be quite common. o The security source for the security operations is the same. Meaning the set of operations are being added by the same node. nit: this second sentence is a sentence fragment. A security target is a block in the bundle to which a security service applies. This target must be uniquely and unambiguously Given that the ASB always uses an array of block numbers to identify the target, this use of the singular "a block" seems inappropriate. Section 3.5 o CRC Type and CRC Field (if present) o Block Data Length o Block Type Specific Data Fields nit: draft-ietf-dtn-bpbis-21 has the CRC field as the last field, and the block data length and type-specific data are encoded together as a definite-length byte string. Section 3.6 Does the array of block numbers in the "Security Targets" field need to be sorted in a particular order? Security Context Flags: [...] Bit 1 (the least-significant bit, 0x01): Security Context Parameters Present Flag. In draft-ietf-dtn-bpbis we start numbering bits at "bit 0", so it's confusing to start at "bit 1" here. Security Context Parameters (Optional): Why do we use an array of (index, value) tuples instead of a CBOR map? Security Results: This field captures the results of applying a security service to the security targets of the security block. This field (I note that here we properly refer to "targets" plural, in contrast to what I noted above.) SHALL be represented as a CBOR array of target results. Each entry in this array represents the set of security results for a specific security target. The target results MUST be ordered identically to the Security Targets field of the security block. This means that the first set of target results in this Per the discuss point, what's the motivation for having an array of results instead of applying the operation to the concatenation of the blocks in question and having a single result? Having multiple results negates most of the space savings we could get from coalescing an operation via "target multiplicity". I see that the BCB procedures can require splitting a BIB if only some of its targets are covered by the BCB (which requires an array of results), but the mechanics of processing would still be possible by encrypting the whole BIB. Are there reasons why that is not feasible? Section 3.7 o The Security Context Id MUST utilize an end-to-end authentication cipher or an end-to-end error detection cipher. Please don't use the word "cipher" here; "cipher" is a cryptographic term of art and does not apply here (see RFC 4949). o The EID of the security source MAY be present. If this field is not present, then the security source of the block SHOULD be inferred according to security policy and MAY default to the bundle source. The security source MAY be specified as part of security context information described in Section 3.10. Isn't the security context identified by an IANA-assigned value? I cannot see how the contex would specify the source itself as opposed to the procedure for inferring it from the bundle contents. o Since OP(integrity, target) is allowed only once in a bundle per target, it is RECOMMENDED that users wishing to support multiple integrity signatures for the same target define a multi-signature security context. As indicated above; I don't understand the need for this requirement. I also don't understand what is meant by a "multi-signature security context". o For some security contexts, (e.g., those using asymmetric keying to produce signatures or those using symmetric keying with a group key), the security information MAY be checked at any hop on the way to the bundle destination that has access to the required keying information, in accordance with Section 3.9. I am strongly reluctant to endorse the use of a group-shared symmetric key in a standards-track document. Also, nit: wouldn't an "error-detection cipher [sic]" also allow for a waypoint node to check the integrity information? Section 3.8 The Block Processing Control flags value can be set to whatever values are required by local policy, except that this block MUST have the "replicate in every fragment" flag set if the target of the BCB is the Payload Block. Having that BCB in each fragment (now we're back to "the target" singular) The Security Context Id MUST utilize a confidentiality cipher that provides authenticated encryption with associated data (AEAD). nit: is it the Id or the Context that utilizes the cipher? Additional information created by a cipher suite (such as additional authenticated data) can be placed either in a security nit: the "additional authenticated data" of an AEAD cipher is *input* to the AEAD, not output; perhaps you mean "authentication tag" here. bundle source. The security source MAY be specified as part of security context information described in Section 3.10. [same comment as for 3.7] o It is RECOMMENDED that designers carefully consider the effect of setting flags that either discard the block or delete the bundle in the event that this block cannot be processed. Can we even allow setting "discard this block", since we modify the contents of the target and the target would be wrongly interpreted in the absence of this block? o A BIB MUST NOT be added for a security target that is already the security target of a BCB. In this instance, the BCB is already providing authentication and integrity of the security target and the BIB would be redundant, insecure, and cause ambiguity in block processing order. The type of authentication that is provided by the BCB can be qualitatively different than the authentication provided by a BIB; ambiguity in block processing order alone is a sufficient reason to disallow this case and we probably shouldn't mention the other alleged reasons. I also don't understand why you say that this combination is "insecure" based just on the description here; please either remove the claim of justify it. o A BIB integrity value MUST NOT be evaluated if the BIB is the security target of an existing BCB. In this case, the BIB data is encrypted. What does "evaluated" mean here, and by whom? o A BIB integrity value MUST NOT be evaluated if the security target of the BIB is also the security target of a BCB. In such a case, the security target data contains cipher-text as it has been encrypted. I thought we already disallowed this from happening because the BIB contents are encrypted. Section 3.9 Since any cipher suite used with a BCB MUST be an AEAD cipher suite, it is inefficient and insecure for a single security source to add both a BIB and a BCB for the same security target. In cases where a Again, please justify or remove the claim of "insecure". Also, the authentication provided by a signature BIB remains qualitatively different from that provided by an AEAD. Section 3.10 I still don't have any real idea of what type(s) of parameters the "security context parameters" might be, which is worryisome. Section 3.11 It's not entirely clear to me what value is provided by using the Bn layer of abstraction for block IDs, as opposed to actual integer values (which makes it clear that the primary block has ID 0 and the payload has ID 1). Section 3.11.1 o An integrity signature applied to the canonicalized primary block [noting again that the core spec does not define a "canonicalization" procedure.] o Confidentiality for the first extension block (B4). This is accomplished by a BCB (B3). Once applied, the contents of extension block B4 are encrypted. The BCB MUST hold an nit(?): I don't think "contents" is the term used most often by the core spec for the block-type-specific data. authentication signature for the cipher-text either in the cipher- text that now populates the first extension block or as a security "authentication signature" is going to confuse people by its similarity to the cryptographic signature concept, which this is not. Please use "authentication tag" instead. Section 3.11.2 The resultant bundle is illustrated in Figure 4 and the security actions are described below. Note that block IDs provided here are ordered solely for the purpose of this example and not meant to impose an ordering for block creation. The ordering of blocks added to a bundle MUST always be in compliance with [I-D.ietf-dtn-bpbis]. Is there a particular ordering requirement from bpbis that is relevant here? o Since the waypoint node wishes to encrypt blocks B5 and B6, it MUST also encrypt the BIBs providing plain-text integrity over those blocks. However, BIB B2 could not be encrypted in its entirety because it also held a signature for the primary block (B1). Therefore, a new BIB (B7) is created and security results [I still don't understand why this is not an artificial rule, but no need to further discuss that here.] Section 4 the same target information (e.g., the same bits in the same order) is provided to the cipher suite when generating an original signature and when generating a comparison signature. Canonicalization For many integrity-protection algorithms it is not possible to "generate a comparison signature" and instead the destination node must "validate the signature" in a dedicated operation. Canonical forms are not transmitted, they are used to generate input to a cipher suite for security processing at a security-aware node. nit: comma splice. As far as I can tell from draft-ietf-dtn-bpbis, there is a single canonical representation form defined and that is what is transmitted; I do not see a separate canonicalization procedure specified. The canonicalization of the primary block is as specified in [I-D.ietf-dtn-bpbis]. [where?] All non-primary blocks share the same block structure and are canonicalized as specified in [I-D.ietf-dtn-bpbis] with the following exceptions. [ibid] o Reserved flags MUST NOT be included in any canonicalization as it is not known if those flags will change in transit. So they're ... set to zero? Or since the previous bullet says they're excluded, there's no problem by definition? These canonicalization algorithms assume that Endpoint IDs do not change from the time at which a security source adds a security block to a bundle and the time at which a node processes that security block. When might that not hold? Shouldn't this be stated much earlier in the document as a requirement/foundational assumption? Section 5.1.1 If the security policy of a security-aware node specifies that a bundle should have applied confidentiality to a specific security target and no such BCB is present in the bundle, then the node MUST process this security target in accordance with the security policy. This may involve removing the security target from the bundle. If the removed security target is the payload block, the bundle MUST be discarded. As written this seems to impose a requirement on security policies to specify what happens in this case. Perhaps we should give a default behavior (discard the bundle?) to avoid accidental omissions that lead to inesecure operation? Also, nit: "a bundle should have applied confidentiality" is weird grammar; I assume "a bundle should have had confidentiality applied" is the intended meaning (or perhaps with s/bundle/block/), albeit in a very awkward grammatical construction. The difficulty comes in that it is not the bundle that applies protection, but rather the BPA. If the Block Data Length field was modified at the time of encryption it MUST be updated to reflect the decrypted block length. "How would the node removing BCB protection know this?" (The security context and cipher suite, I know, but we should say it.) Section 5.1.2 If the security policy of a security-aware node specifies that a bundle should have applied integrity to a specific security target and no such BIB is present in the bundle, then the node MUST process this security target in accordance with the security policy. This [same comment as above about requirement on security policy and default behavior, and same grammatical nit] may involve removing the security target from the bundle. If the removed security target is the payload or primary block, the bundle MAY be discarded. This action can occur at any node that has the Removed from the bundle or as a security target? I note that removing the payload or primary block from a bundle produces a protocol violation, so "MAY" does not seem quite right... Section 5.2 Security processing in the presence of payload block fragmentation may be handled by other mechanisms outside of the BPSec protocol or by applying BPSec blocks in coordination with an encapsulation mechanism. Wouldn't it be worth mentioning the possibility for the application to just ensure that any needed confidentiality protection is applied prior to any need for fragmentation? Section 6 There exist a myriad of ways to establish, communicate, and otherwise manage key information in a DTN. Certain DTN deployments might follow established protocols for key management whereas other DTN deployments might require new and novel approaches. BPSec assumes that key management is handled as a separate part of network management and this specification neither defines nor requires a specific key management strategy. Just so we're clear: this is literally leaving the hardest part of building a secure system out of scope by saying this, and it's pretty disappointing to see no guidance at all for how one might do so. Section 7 o If a bundle is received that contains more than one security operation, in violation of BPSec, then the BPA must determine how Just to be clear: "more than one security operation" is not in and of itself a violation of BPsec. Perhaps we could rephrase to be more clear, presumably about blocks that are the target of the same type of security operation? o It is recommended that BCBs be allowed to alter the size of extension blocks and the payload block. However, care must be taken to ensure that changing the size of the payload block while the bundle is in transit do not negatively affect bundle processing (e.g., calculating storage needs, scheduling transmission times, caching block byte offsets). How would block byte offsets be relevant, given that it's forbidden to apply a BCB to fragments? 1. At the time of encryption, a plain-text integrity signature may be generated and added to the BCB for the security target as additional information in the security result field. Would the need to do this be part of a ... security profile? A security context? It remains unclear to me how these pieces are intended to interact. 2. The encrypted block may be replicated as a new block and integrity signed. (ditto) o It is recommended that security policy address whether cipher suites whose cipher-text is larger (or smaller) than the initial plain-text are permitted and, if so, for what types of blocks. It is *extremely* unclear to me in what cases a cipher-text might be smaller than the initial plaintext. I suggest to remove the parenthetical. Section 8.1 provide appropriate capabilities if they are needed. It should also be noted that if the implementation of BPSec uses a single set of shared cryptographic material for all nodes, a legitimate node is equivalent to a privileged node because K_M == K_A == K_B. So sharing a key like that is NOT RECOMMENDED, right? A special case of the legitimate node is when Mallory is either Alice or Bob (i.e., K_M == K_A or K_M == K_B). In this case, Mallory is able to impersonate traffic as either Alice or Bob, which means that "either Alice or Bob, respectively", right? Having K_B does not let Mallory impersonate traffic as Alice? Section 8.2.1 When evaluating the risk of eavesdropping attacks, it is important to consider the lifetime of bundles on a DTN. Depending on the network, bundles may persist for days or even years. Long-lived bundles imply that the data exists in the network for a longer period of time and, thus, there may be more opportunities to capture those bundles. [...] It's probably worth noting that Mallory is of course not limited by the bundle lifetime in how long she retains a given bundle. Section 8.2.2 removal of blocks. Within BPSec, both the BIB and BCB provide integrity protection mechanisms to detect or prevent data manipulation attempts by Mallory. The protection against removal of blocks (or entire bundles) seems a lot weaker, though. The following paragraph is a pretty good treatment; thanks! only validating that the BIB was generated by a legitimate user, Bob will acknowledge the message as originating from Mallory instead of Alice. In order to provide verifiable integrity checks, both a BIB It might be worth saying something about how "validating a BIB indicates only that the BIB was generated by a holder of the relevant key; it does not provide any guarantee that the bundle or block was created by the same entity". Section 8.2.4 BPSec relies on cipher suite capabilities to prevent replay or forged message attacks. A BCB used with appropriate cryptographic mechanisms (e.g., a counter-based cipher mode) may provide replay protection under certain circumstances. Alternatively, application This seems to imply keeping counter state across bundles, something that's pretty finicky to get right and risky to get wrong. I don't think we should be implying that this is a good idea without a lot more discussion of the potential pitfalls and how to avoid them. (Which basically means I don't think it's worth mentioning this approach, given the work involved in generating such discussion). Section 9.2 o Security Results. Security contexts MUST define their security result Ids, the data types of those results, and their CBOR encoding. Are these result Ids expected to be global to a security context or scoped to a specific block type? * Place overflow bytes, authentication signatures, and any additional authenticated data in security result fields rather than in the cipher-text itself. [same note as (far) above about "authenticated data"] * Pad the cipher-text in cases where the cipher-text is smaller than the plain-text. [same note about smaller ciphertext than plaintext] Section 10 o Other security blocks (OSBs) MUST NOT reuse any enumerations identified in this specification, to include the block type codes for BIB and BCB. I don't understand what this means. NOTE: The burden of showing compliance with processing rules is placed upon the standards defining new security blocks and the identification of such blocks shall not, alone, require maintenance of this specification. nit: I suggest using a different word than "standards" ("specifications"?), since the block type registry is just under the Specification Required policy. Section 11.1 This specification allocates two block types from the existing "Bundle Block Types" registry defined in [I-D.ietf-dtn-bpbis]. draft-ietf-dtn-bpbis-21 does not contain a direction to IANA to update the reference for the bundle block types registry away from its current reference, RFC 6255, so it seems "defined in [RFC6255]" would be more correct.
- [dtn] Benjamin Kaduk's Discuss on draft-ietf-dtn-… Benjamin Kaduk via Datatracker
- Re: [dtn] Benjamin Kaduk's Discuss on draft-ietf-… Birrane, Edward J.
- Re: [dtn] Benjamin Kaduk's Discuss on draft-ietf-… Benjamin Kaduk
- Re: [dtn] Benjamin Kaduk's Discuss on draft-ietf-… Birrane, Edward J.
- Re: [dtn] Benjamin Kaduk's Discuss on draft-ietf-… Magnus Westerlund