Latching: Hosted NAT Traversal (HNT) for Media in Real-Time Communication
draft-ietf-mmusic-latching-08

This is an excellently written document.  Thanks for that.
I just have a couple of minor comments -- non-blocking, and no need to discuss them.

-- Abstract --

   Latching, which is one of the components of the HNT components, has a
   number of security issues covered here.  Because of those, and unless
   all security considerations explained here are taken into account and
   solved, the IETF advises against use of this mechanism over the
   Internet and recommends other solutions such as the Interactive
   Connectivity Establishment (ICE) protocol.

That seems an odd detail to put into the abstract, and should probably be only in the body of the document, and not in the abstract.

Also, it's not clear whether "this mechanism" refers to just latching, or HNT in general.  The paragraph in the Introduction that begins "In no way does this document try to make a case for HNT or present it as a solution that is somehow better than alternatives such as ICE," is clearer, and says it better, I think.

Probably best to just delete that paragraph from the abstract... but this is non-blocking, and if you think it best to keep it, I'll not mention it further (though if you keep it, please replace "this mechanism" with "latching").

-- Acknowledgements --
You might check the spelling of Ari's name in the Acknowledgements.

-- References --
My view of normative references is that they are the references that are necessary for understanding the document... and informative references are those that provide additional information.  That clearly doesn't match the shepherd's view, which says that Informational documents don't have normative references.  I think they do.

Please consider (again, non-blocking, and no discussion needed) selecting some of the most critical references, the ones that really are central to understanding what this document is about, and making them normative.  It serves to give readers a starting point, a "read these first" list, especially when the reference list is long.

Thanks.

I happy recommending the document move forward, but I also though the s5 minor issue and the nits listed in Elwyn's Gen-ART review would be useful to address:

----

Summary: Ready with nits.  Generally a well argued document.  In the
light of the comment that the IETF advises the use of ICE or STUN rather
than HNT, I wondered if it might be helpful to explain how these
mechanisms mitigate or resolve the security issues in s5.   

Major issues:
None

Minor issues:
s5: Section 4 talks about problems with XMPP but the security concerns
in s5 are all discussed in the context of SIP/SBC.  I think some words
about the corresponding security issues in XMPP (or just a statement
that all - or a subset - of these apply to XMPP) ought to be added.

s8: <Heresy Starts> Barry Leiba in his comments in the tracker suggests
that the references would be usefully split into Normative and
Informative subsets.  Given the number of references, splitting them up
seems like a good idea.  I am going to suggest something highly
heretical:  Split them up but call them "Key References" and "Additional
References".  "Normative" has become such a loaded word in the standards
community that, despite its underlying English meaning, it is probably
better to confine its usage to Standards Track documents.  I feel that
we usefully adopt this alternative classification for non-standards
track documents as a general technique to avoid the ongoing discussions
about split refetrence sections. <Heresy Ends> 


Nits/editorial comments:
General:  Would probably be useful to explain the "address:port"
terminology;  Also both the terms "couple" and "set" are used for the
tuple - better to stick with one and use "address:port sets/couples"
instead of "address:ports".

General: s/e.g./e.g.,/g

s1:  Need to expand SDP

s3, last sentence:
OLD:
the SBC may decide not to send media to that customer UA until a SIP 200
response for policy reasons, to prevent toll-fraud.
NEW:
the SBC may decide, for policy reasons, not to send media to that
customer UA until a SIP 200 response has been received, [e.g., ???] to
prevent toll-fraud.

s4, para 1: s/ address:port set that once packets cross the NAT, will be
mapped/address:port set that, once packets cross the NAT, will be
mapped/

s4, Figure 2:  The figure doesn't reflect the address mapping done in
the NATs.  the clients Alice and Bob are shown with public
(documentation) addresses whereas they should presumably have private
addresses that are mapped to these public addresses by the NAT.

s4, Figure 3: The previous comment doesn't apply to this figure which
shows the NAT mapping.  Arguably it would be nice to use private address
space addresses on the private side of the NAT, but I notice we never
managed to allocate a specific private address for documentation - I
suppose since they are private it doesn't matter!

s4, Figure 3, title: Cut and paste error... this figure is about XMPP
not SBC!

s5, para 2: s/In all/All/

Thank you to the editor for addressing my discuss & comment, included here only for informational purposes.

The discuss I raised was addressed with the following text for the purpose of spelling out monitoring threats and available solutions:

   Naturally, SRTP [RFC3711] would help mitigate such threats and, if
   used with the appropriate key negotiation mechanisms, would protect
   the media from monitoring while in transit.  It should therefore be
   used independently of HNT.  [RFC3261] Section 26 provides an overview
   of additional threats and solutions on monitoring and session
   interception.

Original discuss question:

Shouldn't the security considerations section mention the intermediaries as a point of vulnerability?  If they are compromised and SRTP for end-to-end encryption is not used, the intermediary could be a point of monitoring.  This might be to track all media received by specific end users, etc.

Comment below was addressed as well.

Security Considerations, second section:
I'd say it would be likely that the user would end the call, but not necessarily the case.  Or is this a feature built into the agent that does not rely upon the user taking action?  Should the language be tweaked here?  
   In this latter
   case, which may be of particular concern with Carrier-Grade NATs, the
   legitimate SIP UA will end the call anyway, because a human user
   would not hear anything and will hang up.

- Section 5 says: "Failing to implement this would
represent a serious threat to users connecting from
behind Carrier-Grade NATs [RFC6888] and is considered
a harmful practice." That's not very clear really.
The "this" presumably is SRTP, but it'd be failing
to use that creates the vulnerability even if
implemented. If so, I'd suggest: "Failing to
implement and use SRTP therefore represents a serious
threat to users connecting from behind Carrier-Grade
NATs [RFC6888] and is considered a harmful practice."

- The secdir review [1] suggested some nit fixes, but
I didn't see a response.

   [1] https://www.ietf.org/mail-archive/web/secdir/current/msg04800.html