Skip to main content

Last Call Review of draft-ietf-mmusic-latching-05

Request Review of draft-ietf-mmusic-latching
Requested revision No specific revision (document currently at 08)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2014-05-28
Requested 2014-05-15
Authors Emil Ivov , Hadriel Kaplan , Dan Wing
I-D last updated 2014-05-22
Completed reviews Genart Last Call review of -05 by Elwyn B. Davies (diff)
Secdir Last Call review of -05 by Takeshi Takahashi (diff)
Assignment Reviewer Takeshi Takahashi
State Completed
Request Last Call review on draft-ietf-mmusic-latching by Security Area Directorate Assigned
Reviewed revision 05 (document currently at 08)
Result Ready
Completed 2014-05-22

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.

This document describes the behavior of signaling intermediaries in RTC
deployments when performing hosted NAT traversal (HNT).	
The document begins with summarizing the problems with NAT traversal for
protocols such as SIP, and then outlines HNT and the latching mechanism that
approach the problems.
Nevertheless, this document is not recommending the use of latching.
Instead, the document alerts its use and elaborates its security concerns in
Section 5 "Security considerations" by showing several examples.
The security consideration covers issues such as DoS-resistance/resource
exhaustion, impersonation and addresses the use of encryption mechanism.

It is an interesting, tutorial-like document, and I think this document is

According to the mmusic mailing list, the security consideration section has
been discussed from the early stage of this draft, so the section also seems
to be mature, IMHO.
A bit of editorial review would be helpful.

1. It could be helpful if you could spell out the abbreviations when they
appear at the first time (e.g., UAC, UAS, SIP, SDP, and SBC), not at the
second time.
2. In section 1: " and described in [RFC3424]" should be "as described in
3. In section 4: "from from" -> "from" ?

The review was based on the document uploaded at


By the way, if RTC and SBC are used as the identical terms in this document,
why do we use the term RTC (Real Time Communication) in the document tile
while we use the term SBC in the main body texts?
In any case, it is a very minor comment, and I think the draft is ready to
move forward.