[MMUSIC] APPSDIR review of draft-ietf-mmusic-latching-05

["Vijay K. Gurbani" <[e-mail]>]

I have been selected as the Applications Area Directorate reviewer for
this draft (for background on appsdir, please see ​
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).

Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-mmusic-latching-05
Title: Latching: Hosted NAT Traversal (HNT) for Media in Real-Time
Communication
Reviewer: Vijay K. Gurbani
Review Date: May 23-2014
IETF Last Call Date: May-28-2014
IESG Telechat Date: May-29-2014

Summary: This draft is almost ready for publication as an Informational
RFC but has a few issues that should be fixed before publication.

The draft captures excellent discussions on latching and provides a
great overview on what it is, how it works, and despite its simplicity,
why not to use it.  However, the tone of the draft should change from
colloquial to something more objective (various examples of this in
the Nits section).

Major: 0
Minor: numerous (see below)
Nits:  numerous (see below)

Minor:

- S1, second to last paragraph: Not sure I understand what you mean by

    The SIP signaling-layer component of HNT is typically more
    implementation-specific and deployment-specific than the SDP and
    media components.

  SDP is as much of a standard as SIP is, no?  Maybe you mean to say that
  because of the complexity of representing SIP messages, the SIP portion
  of a RTC component's stack may vary between implementations and deploy-
  ments.  SDP, being a simpler protocol (at least syntactically), is not
  exposed to such vagaries.  Yes?

- S3, second paragraph: "newly introduced media relay" --- newly
  introduced to who?  Perhaps you mean "a media relay incorporated into
  session establishment"?  Is this paragraph saying that the SBC and
  media relay may be co-located on the same host?

- S4, the descriptional steps below the text "The latching mechanism
  works as follows:" will be improved if you used "UAC" or "UAS" instead
  of "UA" (I recognize that in SIP it is not necessary that the UAC
  make the first offer, but these steps are for illustrative purposes
  and it helps to be as clear as we can for neophyte readers).  Even
  much better if you could cast the actors in terms of the principals
  Alice and Bob that appear in Figures 2.  So, something like "After
  receving an offer from Alice (UAC) who is behind a NAT" is preferable
  (I think) to "After receiving an offer from a NATed UA".

- S4, the numbered steps in Figure 2: change UAC to Alice in all of
  the steps, and change UAS to Bob in all of the steps.  Easier for
  neophyte readers to follow.  Alternatively, you may put "(UAC)"
  above Alice and "(UAS)" above Bob to impart the same semantics.

- S4, Figure 2: the text between step 12 and step 13 ("(SBC latches
  to source IP address and port seen in (10))" --- what is this
  referring to?  Is it referring to the latching created by Alice?
  or Bob?  It is not clear, specially since I am not sure if the
  "(10)" in the text I quote is a typo or not.  Maybe you meant
  "(7)" or maybe "(2)"?

- S4, Figure 2, step 13: Much as you do in step 11, you should
  spell out the "dest" field here as well.  So,
  s/RTP/RTP, dest=198.51.100.2:22007/

- S5, first paragraph, line 12: s/onto packets/onto media packets/

- S5, first paragraph, line 14: "... a range of IP addresses belonging
  to the same network..."  Here, "same" as which one?  I suspect you
  mean the attacker's network.  But being explicit is better here.

- S5, first paragraph, towards the end: "widen the gap for potential
  attackers..." Here, I suspect you mean that it provides the attackers
  more IP address from which to mount attacks, i.e., advantage:
  attackers.  Yes?

- S5, second paragraph: s/In all/All/

- S5, second paragraph: s/disturb media/impact media/

- S5, third paragraph:
  s/since the SBC will not latch onto the attacker's packets./since the
  SBC will not latch onto the attacker's media packets, not having
  seen the corresponding signaling packets first./

- S5, third paragraph: I am not sure I understand case (2).  Why would
  an SBC latch on to an attacker if it is using restricted latching?
  Teasing this case further, if the legitimate user hangs up the call
  because it is not getting any media packets, then a BYE should go
  through the SBC causing it to discard latched states, thereby
  preventing any more media packets from going to the attacker.

  Assuming that the attacker had inserted itself as a man-in-the-middle
  and was relaying packets to the UA, then sure, the legitimate user
  will not hang up and continue conversing.

  The case of a non-human user (answering machine) is redundant since
  the behaviour of the user (non-human or otherwise) is essentially
  the same.

- S5, fourth paragraph: "For example, in cases where end-to-end
  encryption is used it would still be possible for an attacker to
  hijack a session despite the use of SRTP and perform a denial of
  service attack.  However, media integrity would not be compromised."

  Can you explain more broadly how the above would work?  If we assume
  that the endpoints exchange keys end-to-end and create secure channels
  end-to-end, how would the attacker hijack a session?  (Heartbleed and
  all such mechanisms aside, of course.  If we assume keys are derived
  end-to-end and don't follow the hop-by-hop model, how would the
  attacker prevail?)

Nits:

- Abstract, 3rd paragraph:
  s/components of the HNT components/components of HNT/

  In fact, the entire 3rd paragraph could be written more succinctly as
  follows:

    Latching, one of the components of HNT, has a number of security
    issues detailed in this document.  Based on the known threats, the
    IETF advises against use of this mechanism on the Internet and
    recommends other solutions, such as the Interactive Connectivity
    Establishment (ICE) protocol.

- S1, second paragraph: s/They use IP/These protocols use IP/

- S1, second paragraph: s/as, in the/as, and in the/

- S1, fourth paragraph:
  s/some manufacturers sometimes/a number of manufacturers sometimes/

- S1, fifth paragraph: s/creation time/publication/

- S1, fifth paragraph: s/in the foreseeable/for the foreseeable/

- S1, sixth paragraph:
  s/are not novel to experts/are well known in the community/

- S1, seventh paragraph:
  s/In no way does this document/This document does not/

- S4, first paragraph: s/couple/tuple/

- S4, Figure 3: why not use the principals Alice and Bob here as
  well instead of "XMPP Client 1" and "XMPP Client 2"?

- S5, last sentence of second-to-last paragraph:
  s/However it is sometimes argued that, neither S/MIME nor
  [RFC4474] are widely deployed and that this may not be
  a real concern./However, neither S/MIME or [RFC4474] are widely
  deployed, thus not being able to sign/verify requests appear not
  to be a concern at this time./

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / [e-mail]
Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq