Skip to main content

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

Revision differences

Document history

Date Rev. By Action
2014-09-08
08 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2014-09-08
08 Alissa Cooper Changed consensus to Yes from Unknown
2014-08-27
08 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2014-08-19
08 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2014-07-25
08 Elwyn Davies Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Elwyn Davies.
2014-07-01
08 Cindy Morgan IESG state changed to RFC Ed Queue from Approved-announcement sent
2014-07-01
08 (System) RFC Editor state changed to EDIT
2014-07-01
08 (System) Announcement was received by RFC Editor
2014-07-01
08 (System) IANA Action state changed to No IC from In Progress
2014-07-01
08 (System) IANA Action state changed to In Progress
2014-07-01
08 Cindy Morgan IESG state changed to Approved-announcement sent from IESG Evaluation::AD Followup
2014-07-01
08 Cindy Morgan IESG has approved the document
2014-07-01
08 Cindy Morgan Closed "Approve" ballot
2014-07-01
08 Cindy Morgan Ballot approval text was generated
2014-06-17
08 Emil Ivov New version available: draft-ietf-mmusic-latching-08.txt
2014-06-02
07 Gunter Van de Velde Closed request for Last Call review by OPSDIR with state 'No Response'
2014-06-02
07 Kathleen Moriarty
[Ballot comment]
Thank you to the editor for addressing my discuss & comment, included here only for informational purposes.

The discuss I raised was addressed …
[Ballot comment]
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.
2014-06-02
07 Kathleen Moriarty [Ballot Position Update] Position for Kathleen Moriarty has been changed to No Objection from Discuss
2014-06-01
07 (System) Sub state has been changed to AD Followup from Revised ID Needed
2014-06-01
07 Emil Ivov New version available: draft-ietf-mmusic-latching-07.txt
2014-05-29
06 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2014-05-29
06 Emil Ivov IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2014-05-29
06 Emil Ivov New version available: draft-ietf-mmusic-latching-06.txt
2014-05-29
05 Alia Atlas [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas
2014-05-29
05 Joel Jaeggli [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli
2014-05-29
05 Kathleen Moriarty
[Ballot discuss]
The draft reads well and I'm fine with it moving forward, but have a question/concern I'd like to discuss first.

Shouldn't the security …
[Ballot discuss]
The draft reads well and I'm fine with it moving forward, but have a question/concern I'd like to discuss first.

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.
2014-05-29
05 Kathleen Moriarty
[Ballot comment]
Security Considerations, second section:
I'd say it would be likely that the user would end the call, but not necessarily the case.  Or …
[Ballot comment]
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.
2014-05-29
05 Kathleen Moriarty [Ballot Position Update] New position, Discuss, has been recorded for Kathleen Moriarty
2014-05-28
05 Richard Barnes
[Ballot comment]
Figure 1: I'm not sure what a Logical Deployment Path is. Do packets flow along them?  Might be helpful to label this more …
[Ballot comment]
Figure 1: I'm not sure what a Logical Deployment Path is. Do packets flow along them?  Might be helpful to label this more clearly.
2014-05-28
05 Richard Barnes [Ballot Position Update] New position, Yes, has been recorded for Richard Barnes
2014-05-28
05 Ted Lemon [Ballot Position Update] New position, No Objection, has been recorded for Ted Lemon
2014-05-28
05 Brian Haberman [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman
2014-05-28
05 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel
2014-05-28
05 Jari Arkko
[Ballot comment]
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 …
[Ballot comment]
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:  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. 


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/
2014-05-28
05 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko
2014-05-28
05 Alissa Cooper IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead
2014-05-28
05 Benoît Claise [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise
2014-05-28
05 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2014-05-27
05 Stephen Farrell
[Ballot comment]


- Section 5 says: "Failing to implement this would
represent a serious threat to users connecting from
behind Carrier-Grade NATs [RFC6888] …
[Ballot comment]


- 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
2014-05-27
05 Stephen Farrell [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell
2014-05-27
05 Spencer Dawkins [Ballot Position Update] New position, Yes, has been recorded for Spencer Dawkins
2014-05-27
05 Martin Stiemerling [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling
2014-05-22
05 Tero Kivinen Request for Last Call review by SECDIR Completed: Ready. Reviewer: Takeshi Takahashi.
2014-05-22
05 Barry Leiba
[Ballot comment]
This is an excellently written document.  Thanks for that.
I just have a couple of minor comments -- non-blocking, and no need to …
[Ballot comment]
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.
2014-05-22
05 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2014-05-21
05 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2014-05-21
05 Pearl Liang
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-mmusic-latching-05, which is currently in Last Call, and has the following comments:

We understand that, upon approval of this …
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-mmusic-latching-05, which is currently in Last Call, and has the following comments:

We understand that, upon approval of this document, there are no IANA
Actions that need completion.

While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object.

If this assessment is not accurate, please respond as soon as possible.
2014-05-21
05 Alissa Cooper Ballot has been issued
2014-05-21
05 Alissa Cooper [Ballot Position Update] New position, Yes, has been recorded for Alissa Cooper
2014-05-21
05 Alissa Cooper Created "Approve" ballot
2014-05-18
05 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Peter Koch
2014-05-18
05 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Peter Koch
2014-05-16
05 Alissa Cooper Placed on agenda for telechat - 2014-05-29
2014-05-15
05 Jean Mahoney Request for Last Call review by GENART is assigned to Elwyn Davies
2014-05-15
05 Jean Mahoney Request for Last Call review by GENART is assigned to Elwyn Davies
2014-05-15
05 Tero Kivinen Request for Last Call review by SECDIR is assigned to Takeshi Takahashi
2014-05-15
05 Tero Kivinen Request for Last Call review by SECDIR is assigned to Takeshi Takahashi
2014-05-14
05 Amy Vezza IANA Review state changed to IANA - Review Needed
2014-05-14
05 Amy Vezza
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Latching: Hosted NAT Traversal (HNT) …
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Latching: Hosted NAT Traversal (HNT) for Media in Real-Time Communication) to Informational RFC


The IESG has received a request from the Multiparty Multimedia Session
Control WG (mmusic) to consider the following document:
- 'Latching: Hosted NAT Traversal (HNT) for Media in Real-Time
  Communication'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-05-28. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document describes behavior of signalling intermediaries in
  Real-Time Communication (RTC) deployments, sometimes referred to as
  Session Border Controllers (SBCs), when performing Hosted NAT
  Traversal (HNT).  HNT is a set of mechanisms, such as media relaying
  and latching, that such intermediaries use to enable other RTC
  devices behind NATs to communicate with each other.

  This document is non-normative, and is only written to explain HNT in
  order to provide a reference to the IETF community, as well as an
  informative description to manufacturers, and users.

  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.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-mmusic-latching/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-mmusic-latching/ballot/


No IPR declarations have been submitted directly on this I-D.


2014-05-14
05 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2014-05-14
05 Amy Vezza Last call announcement was generated
2014-05-14
05 Alissa Cooper Last call was requested
2014-05-14
05 Alissa Cooper Ballot approval text was generated
2014-05-14
05 Alissa Cooper IESG state changed to Last Call Requested from AD Evaluation
2014-05-06
05 Emil Ivov New version available: draft-ietf-mmusic-latching-05.txt
2014-03-14
04 Alissa Cooper Ballot writeup was changed
2014-03-14
04 Alissa Cooper Ballot writeup was changed
2014-03-14
04 Alissa Cooper Ballot writeup was generated
2014-03-13
04 Alissa Cooper Last call announcement was generated
2014-03-12
04 Alissa Cooper IESG state changed to AD Evaluation from Publication Requested
2014-03-05
04 Amy Vezza Shepherding AD changed to Alissa Cooper
2014-03-05
04 Gonzalo Camarillo IESG state changed to Publication Requested from Publication Requested::External Party
2014-02-17
04 Gonzalo Camarillo IESG state changed to Publication Requested::External Party from Publication Requested
2014-02-11
04 Ari Keränen IETF WG state changed to Submitted to IESG for Publication
2014-02-11
04 Ari Keränen IESG state changed to Publication Requested
2014-02-11
04 Ari Keränen
Writeup for draft-ietf-mmusic-latching-04

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper …
Writeup for draft-ietf-mmusic-latching-04

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

  Requested type is Informational, as indicated in the title page header.
  The document provides informative description of existing network
  intermediary behavior and hence the type is proper for this document.


(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 describes behavior of signalling intermediaries in
  Real-Time Communication (RTC) deployments, sometimes referred to as
  Session Border Controllers (SBCs), when performing Hosted NAT
  Traversal (HNT).  HNT is a set of mechanisms, such as media relaying
  and latching, that such intermediaries use to enable other RTC
  devices behind NATs to communicate with each other.


Working Group Summary

  There is WG consensus behind this draft. All issues raised during and
  before WGLC have been addressed. There were concerns regarding the
  harmfulness of the documented mechanisms, especially regarding security.
  The document was updated to stress that it only documents existing
  behavior and does not recommend them as good practices.


Document Quality

  The document is well written and readable. It documents existing behavior
  that has been already earlier implemented by various vendors.


Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

  Ari Keranen is the Document Shepherd, and the Responsible Area
  Director is Gonzalo Camarillo.


(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 reviewed past four versions of the
document and believes the document 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 concerns.

(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 such reviews were needed.


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

  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.

Yes, the shepherd has received confirmation from all authors.


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

  There are no IPR disclosures for the document.


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

  The WG has discussed the need for this document extensively and has
  agreed that one is needed. The security concerns raised some controversy
  but they were resolved with updated text.
 

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

  There are no such concerns.
 

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

  IDnits tool complains about "Obsolete informational reference", but
  the reference to an obsoleted RFC (first version of STUN) is
  intentional.
 

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

  There was no need for such reviews.
 

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

  The document, being purely informational, has only informative
  references.
 

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

  There are no such references.
 

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


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

  The publication of this document will not change the status of any
  existing RFC.
 

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

  This document has no actions for IANA.


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

  There are no new IANA registries defined by this document.


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

  The document does not contain such formal language.
2014-02-11
04 Ari Keränen State Change Notice email list changed to mmusic-chairs@tools.ietf.org, draft-ietf-mmusic-latching@tools.ietf.org
2014-02-11
04 Ari Keränen Responsible AD changed to Gonzalo Camarillo
2014-02-11
04 Ari Keränen Working group state set to Submitted to IESG for Publication
2014-02-11
04 Ari Keränen IESG state set to Publication Requested
2014-02-11
04 Ari Keränen IESG process started in state Publication Requested
2014-02-11
04 Ari Keränen Changed document writeup
2013-10-28
04 Ari Keränen IETF WG state changed to WG Consensus: Waiting for Write-Up from WG Document
2013-10-07
04 Emil Ivov New version available: draft-ietf-mmusic-latching-04.txt
2013-07-15
03 Emil Ivov New version available: draft-ietf-mmusic-latching-03.txt
2013-06-10
02 Emil Ivov New version available: draft-ietf-mmusic-latching-02.txt
2013-05-07
01 Emil Ivov New version available: draft-ietf-mmusic-latching-01.txt
2013-04-23
00 Ari Keränen Intended Status changed to Informational from None
2013-04-05
00 Ari Keränen Changed shepherd to Ari Keränen
2012-11-05
00 Emil Ivov New version available: draft-ietf-mmusic-latching-00.txt