Skip to main content

Last Call Review of draft-ietf-rum-rue-09

Request Review of draft-ietf-rum-rue
Requested revision No specific revision (document currently at 11)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2021-10-26
Requested 2021-10-12
Authors Brian Rosen
I-D last updated 2021-11-11
Completed reviews Artart Last Call review of -09 by Rich Salz (diff)
Genart Last Call review of -09 by Matt Joras (diff)
Secdir Last Call review of -09 by Russ Mundy (diff)
Tsvart Telechat review of -09 by Dr. Bernard D. Aboba (diff)
Assignment Reviewer Russ Mundy
State Completed
Request Last Call review on draft-ietf-rum-rue by Security Area Directorate Assigned
Posted at
Reviewed revision 09 (document currently at 11)
Result Has issues
Completed 2021-11-10
Reviewer: Russ Mundy
Review result: Almost Ready

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area directors.
 Document editors and WG chairs should treat these comments just like any other
last call comments.

The Interoperability Profile for Relay User Equipment (draft-ietf-rum-rue-09)
document is well structured and written as well as providing very
understandable information about the Video Relay Service (VRS) and the Relay
User Equipment (RUE).  Although I have very limited exposure to this technology
area, the functional aspects of this profile seem well thought out and
described in the draft.

As an Interoperability Profile, I don't find it surprising that there is
absence of specific (or even general) security requirements in the current
draft.  However, this may result in interoperability challenges because RUE and
VRS make different choices with respect to the (50+) normative references
particularly with respect to security implementations. For example, RFC 7575
defines an "opportunistic security" scenario that might (or might not) be
appropriate for some of the RUE activities perhaps anonymous calls as described
in 5.2.1. Also, it might (or might not) be acceptable for implementations to
negotiate the use of earlier versions of TLS or cryptographic algorithms for
some (or none) of the capabilities defined in sections 5 through 10 of the
draft.  These sections (5 - 10) describe a sufficiently different set of
functions that it seems as though some of them might have different security
requirements but no specifics security requirements (besides the use of TLS and
HTTPS), it would be useful to state the security requirements for each of the
sub sections.

Although I think that it would be useful to include other security details,
identifying at least the basic security requirements that must be provided for
each of the defined sub-sections in sections 5 -10 of the draft seems
essential.  I.e., does each one of the functions require Authentication,
Confidentiality and Integrity as defined in section 1 of RFC 8446 (or another
RFC) or do some of the defined capabilities only require a subset of these
security services?  Or do some of the defined functions need something

Identifying the specific security services required for each of the defined
sub-sections would provide more useful information for implementors and
deployers who will depend on this specification as well as more consistent
security properties in the deployments.