As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.
Changes are expected over time. This version is dated 24 February 2012.
(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why
is this the proper type of RFC? Is this type of RFC indicated in the
title page header?
A Proposed Standard is being requested. The title page header indicates that
the intended status is Standards Track, and the specification documented in the
current Internet Draft is not yet mature enough to qualify as an Internet
Standard.
(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:
Technical Summary
This document defines security features for the Bundle Protocol (BP)
[I-D.ietf-dtn-bpbis] and is intended for use in Delay Tolerant Networks
(DTNs) to provide end-to-end security services.
The Bundle Protocol specification [I-D.ietf-dtn-bpbis] defines DTN as
referring to "a networking architecture providing communications in
and/or through highly stressed environments" where "BP may be viewed
as sitting at the application layer of some number of constituent
networks, forming a store-carry-forward overlay network". The term
"stressed" environment refers to multiple challenging conditions
including intermittent connectivity, large and/or variable delays,
asymmetric data rates, and high bit error rates.
The BP might be deployed such that portions of the network cannot be
trusted, posing the usual security challenges related to
confidentiality and integrity. However, the stressed nature of the
BP operating environment imposes unique conditions where usual
transport security mechanisms may not be sufficient. For example,
the store-carry-forward nature of the network may require protecting
data at rest, preventing unauthorized consumption of critical
resources such as storage space, and operating without regular
contact with a centralized security oracle (such as a certificate
authority).
An end-to-end security service is needed that operates in all of the
environments where the BP operates.
Working Group Summary
bpsec is descended from the Bundle Security Protocol specification documented
in RFC 6257. That protocol was found to be impractical to implement in some
circumstances; simplifications were developed that were originally termed
"Streamlined Bundle Security Protocol" and then "bpsec" as of the DTN WG
meeting at IETF 94. Technical discussion of the details of bpsec over the
ensuing 3 years has been lively and well-informed, without sharp controversy.
WG consensus on the draft is strong.
Document Quality
The Interplanetary Overlay Network (ION) open-source implementation of the DTN
architecture includes an implementation of Streamlined Bundle Security
Protocol, which is nearly identical to bpsec. Marshall Space Flight Center
intends to add a similar implementation to the DTN2 code base. Early review of
the specification by Dan Harkins (Security Area) was reported at IETF 102
(review-ietf-dtn-bpsec-06-secdir-early-harkins-2018-05-31): the review result
was Has Issues, but it was the sense of the Working Group that no serious
problems were found.
Personnel
The Document Shepherd is Scott Burleigh. The Responsible Area Director is
Magnus Westerlund.
(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.
The Document Shepherd has been reviewing and commenting on drafts of this
specification since March of 2013. The current edition of the specification is
ready for publication.
(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?
No, reviews of the specification have been performed both by persons with good
understanding of Bundle Protocol and by persons with good understanding of
network security.
(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.
Early review of the specification by Dan Harkins (Security Area) was reported
at IETF 102 (review-ietf-dtn-bpsec-06-secdir-early-harkins-2018-05-31): the
review result was Has Issues, but it was the sense of the Working Group that no
serious problems were found. The Document Shepherd does not perceive any need
for review from additional perspectives.
(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.
The Document Shepherd has no specific concerns or issues with this document.
Technical questions have been discussed at length and resolved by consensus
within the WG.
(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.
Both authors have stated that they do not claim any intellectual property
rights regarding this document.
(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.
Kevin Fall has stated that patent USPTO 7,930,379 might or might not have a
bearing on this document. No formal IPR disclosure has been filed yet; the DTN
WG is investigating. No other claims of intellectual property rights regarding
this document have been stated.
(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?
It is the sense of the WG Chairs and the Document Shepherd that this document
represents the solid consensus of the WG. There are WG members whose expertise
in the subject matter of the document is limited, who are therefore not active
participants in bpsec discussions. However, the WG as a whole understands the
intent and, broadly, the design of the specification, and there is no audible
dissent at the WG meetings or on the mailing list.
(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)
No extreme discontent pertaining to bpsec has been evident in the WG meetings
or on the mailing list.
(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.
According to idnits:
• There is one error: the document includes a normative reference to an
Informational RFC (RFC 6255). • There is one warning: the reference to
the bundle protocol specification draft-ietf-dtn-bpbis-11 should be replaced by
a reference to later version draft-ietf-dtn-bpbis-13. (Not unexpected, as the
current bpsec I-D was posted 65 days ago and work on bpbis has continued since
then.)
In reference to the Internet-Drafts Checklist:
• The IANA Considerations section is present, but the details of the
required new namespace (a registry of security context identifiers) are not
provided. • Verbatim replication of the IPR Disclosure, IPR Notice, and
Copyright Notice and Disclosure are not provided. The language provided is
incomplete. • While the bpsec specification supersedes RFC 6257, that RFC
is experimental; the absence of Updates or Supersedes language in the Abstract
seems appropriate.
(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.
No formal review criteria are known to be applicable.
(13) Have all references within this document been identified as
either normative or informative?
Yes, with one error (detected by idnits) as noted above.
(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?
The Internet Draft for Bundle Protocol Version 7 is referenced. That document
is being forwarded to the IESG at the same time as the bpsec document itself.
(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.
There are no downward normative references, aside from the error (detected by
idnits) noted earlier.
(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.
Publication of this document will not change the status of any existing RFCs.
(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 8126).
As noted earlier, the details of the sole required new namespace (a registry of
security context identifiers) are not provided. Allocation of two additional
entries in the Bundle Block Types registry is noted appropriately.
(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.
Allocations from the requested new registry of security context identifiers
would likely require Expert Review by persons knowledgeable in cryptographic
algorithms, applicable configuration values, and policies associated with the
use of those algorithms.
(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.
No sections of the bpsec specification are written in any formal language.