Re: [MMUSIC] [apps-discuss] APPSDIR review of draft-ietf-mmusic-latching-05

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

On 05/28/2014 05:32 PM, Emil Ivov wrote:
> Hey Vijay,
>
> Thanks for your review! Comments inline.

Emil: Thank you for indulging me.  More inline (please see to end).  I
have taken out items of agreement and only list those where more
discussion is required.  For reference, my original review is at
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg12014.html).

>>   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?
>
> Yes, exactly. [...]
> On the other hand there only so many ways you can change an IP address
> in SDP. So, how about the following wording?
>
>     SIP's many features in terms of controlling message routing provide
>     for various ways of addressing NAT traversal. As a result, the HNT
>     component for SIP is typically more implementation-specific and
>     deployment-specific than the SDP and media components.
>
> Would this be better?

Yes, much improved.  One minor modification to the suggested text:

   s/SIP's many features in terms of controlling message routing provide
   for various ways of addressing NAT traversal./
   SIP uses numerous expressive primitives for message routing and,
   consequently, NAT traversal./

>> - S3, second paragraph: "newly introduced media relay" --- newly
>>   introduced to who?  [...]
> So how about this?
>
>     While this is not necessary for HNT to work, quite often, the IP
>     address of that media relay may be the same as that of the signaling
>     intermediary (i.e. the SIP SBC and media relay are co-located on the
>     same host). Also, in almost all cases, the address of the media
>     relay would belong to the same IP address family as the one used for
>     signaling, as it is known to work for that UA.
>
> Is this better or do you prefer the original?

The problem with qualifying phrases like "In almost all cases" is that
one wonders what happens in other cases?  What do you think about the
following text:

    In typical deployments, the media relay and signaling intermediary
    (the SBC) are co-located, thereby sharing the same IP address
    family.  This works well because the UA also shares the same IP
    address family.  In deployments where the media relay belongs to
    a different address family, the signaling intermediary would
    rewrite it to correspond to the address family of the UA.

Feel free to push back and modify if this does not convey the right
semantics (especially the "In deployments..." part).

>> - 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".
>
> I agree this can be said better. What would you say about:
>
>     This way, while a session is still being setup, the signalling
>     intermediary is not yet aware what addresses and ports the caller
>     and the callee would end up using for media traffic: it has only
>     seen them advertise the private addresses they use behind their
>     respective NATs. Therefore media relays used in HNT would often use
>     a mechanism called "latching".

Umm ... I think there is a bit of a disconnect here.  I am referring to
all steps 1 - 6 above.  See next comment; it is related.

>> - 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.
>
> Agreed! Would be much better!
>
>> - 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)"?
>
> Latching happens as soon as the first media packet arrives so this meant
> (11). Thanks for the catch and sorry about the confusion!

No worries.

>> - 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/
>
> OK, that's going to require some ASCII art magic because we are out of
> place there already but I do agree it would be useful :)

Sure; will be helpful if put in.

>> - S5, first paragraph, line 12: s/onto packets/onto media packets/
>
> Well they don't need to be media. They would be ignored even if they
> weren't. WDYT?

Yes, you are right.  Disregard that comment.

>> - 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.
>
> It means the same as the one that the source address of the signalling
> packets belongs to. How about this:
>
>     In some cases the
>     limitation may be loosened to allow media from a predefined range of
>     IP addresses in order to allow for use cases such as decomposed UAs

Yes, much better.

>> - 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?
>
> Yes. Is this a clarifying question or do you think it would be better if
> changed that way?

I think it is better to say that "it provides the attackers a larger
attack surface" (or something similar).  Using the phrase "widen the
gap" is ambiguous.  One can read that as widening the gap between
attacker and defender (i.e., advantage defenders).

>> - 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?
[...]
> Well, automated UAs are often less picky than humans about the kind of
> media they get (if at all) and the intention was to warn aout that
> option. Happy to remove it if you find it unnecessary.

No leave all that in.  As I re-read my comment on case (2), it seems
that I may have been in error.  If the attacker is behind the same NAT
as the legitimate SIP UA, then what you describe is good.

>> - 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?)
>
> End-to-end was probably not the best choice of words here. Imagine
> something like ZRTP though. Given that such mechanisms rely exclusively
> on the media path for key negotiation, there would be no way for the SBC
> to authenticate the UA so it would still latch onto the wrong endpoint.
> Obviously ZRTP's authentication would prevent from an actual MitM attack
> but given that it's already on the media path, the attacker can simply
> stop relaying media and effectively perform a DoS. Does this make sense?

Yes, more now.  But, I think you will have to describe this attack using
ZRTP as an example in some more detail since there are various issues at
work here (the SBC not being able to authenticate the endpoint using
ZRTP, etc.).  I suspect that the security ADs may ask you to do this
anyway during IESG review.  Of course, if they don't you are free to
proceed, but as a matter of principle, it is best to explain the
security threat in enough detail that someone building these things can
appreciate the reasoning.  (In the current form, at least I had
questions on the scenario you had in mind, hence the comment.)

>> - Abstract, 3rd paragraph:
>>   s/components of the HNT components/components of HNT/
>
> thanks
>
>>   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.
>
> That paragraph was the result of literally tens of back and forths so,
> unless you think this is paramount, I think it would be better to keep
> it as is. Specifically, the above version is missing on the fact that a)
> using SRTP allows for the security concerns to be addresses and the
> mechanism becomes acceptable b) sometimes the security concerns simply
> don't come into play (e.g. public conferences) c) there are controlled
> environments where security is taken care of in another way.

Hmmm ... I don't see that the original version attends to (a), (b) and
(c) any more explicitly than the above version, but I will defer to your
judgment here.  Since the paragraph is crafted through a hard-won
battle, please feel free to retain it.

>> - S4, first paragraph: s/couple/tuple/
>
> well, in this case the text does refer to the address:port couple but I
> am ok with changing that to the "addres:port/transport" tuple (or triplet?)

Stevens used "tuple" in his seminal TCP books.  I personally think
"tuple" is better (and it is devoid of ordinal value, i.e., there can
be a 2-tuple, a quintuple, sextuple, etc.).  If, however, you'd like
to leave it as "couple", no problem.

>> - S4, Figure 3: why not use the principals Alice and Bob here as
>>   well instead of "XMPP Client 1" and "XMPP Client 2"?
>
> Frankly the main reason was because it otherwise looks exactly like SIP
> and it becomes confusing. But I don't mind switching to Romeo and Juliet
> (which are XSF's protagonists of choice ;) ).

Sure.  Out of curiosity, who is XSF's Eve?

Thanks for your time on this, Emil.

Cheers,

- 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