Skip to main content

Shepherd writeup
draft-weis-gdoi-rekey-ack

Shepherd write-up for draft-weis-gdoi-rekey-ack-05

> (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?

This document is requested for publication as a Standards Track RFC with AD
sponsorship.

The document defines a protocol extension to RFC 6407 which is itself a
Standards Track document. Thus, Standards track is appropriate for this
document as indicated on the title page.

Notes:
1. Although this document defines an extension to RFC 6407 it does not Update
that RFC because
   it is not a requirement that future implementations of RFC 6407 include the
   function described in this document.

2. This document is advanced for publication as AD sponsored because there is
no current WG
   dedicated to this work, but the work is very definitely within the purview
   of the IETF.

> (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

The Group Domain of Interpretation (GDOI) defined in RFC 6407 includes the
ability for a Group Controller/Key Server (GCKS) to provide a set of current
Group Member (GM) devices with additional security associations (e.g., to rekey
expiring security associations).  GDOI meets the requirement of the Multicast
Security (MSEC) Group Key Management Architecture (RFC 4046), and defines both
a Registration Protocol and Rekey Protocol.

Usually the GCKS does not require a notification that the group member actually
received the policy. However, in some cases it is beneficial for a GCKS to be
told by each receiving GM that it received the rekey message and by implication
has reacted to the policy contained within.

This memo adds the ability of a GCKS to request the GM devices to return an
acknowledgement of receipt of its rekey message, and specifies the
acknowledgement method.

> Working Group Summary

This document is not the product of a WG there being no working group for which
this work is specifically in scope.  The MSEC WG would have been the logical
place for the work, but it closed several years ago.

Attempts to gather interest in the Security Area and specifically the IPSECME
WG were not successful.

That said, there were no responses indicating controversy about or objection to
the technical work.

> Document Quality

Two vendor implementations are "in the pipe".
Review has been light other than the shepherd's review (q.v.). However, the
document is short and simple.

> (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.

I reviewed -04 and found a number of points that needed clarification, and some
nits. These have been fixed in -05 to my satisfaction. I had no issues with the
substance of the technical solution.

> (4) Does the document Shepherd have any concerns about the depth or breadth
of the reviews that >     have been performed?

More would have been good, but given the implementation status and the
simplicity of the work, I think it is OK.

> (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.

No.

> (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 interested community has discussed those
issues >     and has indicated that it still wishes to advance the document,
detail those concerns here.

No concerns.

> (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.

All authors have confirmed to me by email.

> (8) Has an IPR disclosure been filed that references this document? If so,
summarize any discussion >     and conclusion regarding the IPR disclosures.

IPR has been disclosed at https://datatracker.ietf.org/ipr/2217/
There has been not public discussion of this IPR that I am aware of.
The license terms are "MAD"

> (9) How solid is the consensus of the interested community behind this
document? Does it represent >     the strong concurrence of a few individuals,
with others being silent, or does the interested >     community as a whole
understand and agree with it?

The community of interest is very small. It appears to be limited to the
implementers at two vendors, and the operators at one service provider. They
are all represented as co-authors.

> (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 threats.

> (11) Identify any ID nits the Document Shepherd has found in this document.
(See >      http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks >      are not enough; this check needs to be
thorough.

Nits are clean except for a warning about a reference to RFC 2408 that has been
obsoleted. See item 14).

> (12) Describe how the document meets any required formal review criteria,
such as the MIB Doctor, >      media type, and URI type reviews.

N/A

> (13) Have all references within this document been identified as either
normative or informative?

Yes

> (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?

This document has a normative reference to RFC 2408.
RFC 2408 was obsoleted by RFC 4306 which was itself obsoleted by RFC 5996,
which was obsoleted in its turn by RFC 7296.

However, a normative reference to RFC 2408 seems right, as follows...

When RFC 2408 was obsoleted it was assumed that the only interesting user of
ISAKMP was IKE and since IKEv1 was being replaced by IKEv2 it appeared to make
sense to obsolete the base RFCs (RFC 2407, 2408, 2409).

At the time, GDOI was still using RFC 2408 and RFC 2409, and no attempt was
made to update/obsolete the GDOI spec. (Hearsay has it that the security ADs at
the time said that this was OK.)

So the questions are:
- Why not make a reference to RFC 7296 from this document?
  Unfortunately, the namespaces and payload formats are not all identical, and
  the protocols themselves are very different.
- Why not move GDOI to IKEv2 instead of IKEv1?
  Firstly, this would be a substantial piece of work.
  Secondly, there are GDOI-based VPN deployments (and a specific one that
  exercises the authors) that need to be kept functional rather than subjected
  to a major upgrade. Lastly, there is a GDOI-like protocol based on IKEv2 that
  may see implementation and deployment one day
  (https://tools.ietf.org/html/draft-yeung-g-ikev2-11) thereby replacing GDOI,
  but that is not ready for action yet.

Hence the reference seems good.

> (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.

N/A

> (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
interested community considers it unnecessary.

N/A

> (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 5226).

My review gave rise to some updates.
All good now.

> (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.

This documnt defines two new registries (see Section 8) that use "Specification
Required" as the assignment policy. That implies the use of expert Review as
described in RFC 5226.

DEs should be familiar with ISAKMP.

> (19) Describe reviews and automated checks performed by to validate sections
of the document written >      in a formal language, such as XML code, BNF
rules, MIB definitions, etc.

N/A
Back