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

[Emil Ivov <[e-mail]>]

Hey Vijay,

Apologies for the delay! I believe we have addressed all comments and a 
new version is available here:

Html: http://tools.ietf.org/html/draft-ietf-mmusic-latching-08
Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-latching-08

Please see inline for the rest of my responses (points of accord removed):

On 02.06.14, 17:20, Vijay K. Gurbani wrote:
> On 05/28/2014 05:32 PM, Emil Ivov wrote:
>> Hey Vijay,
>>
>> Thanks for your review! Comments inline.
>
> Emil: Thank you for indulging me.

Any time ;)

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

I like that! Although with your wording the first part of the sentence 
is enough so if we remove the second we get:

         SIP uses numerous expressive
         primitives for message routing. As a result, the HNT component
         for SIP is typically more implementation-specific and
         deployment-specific than the SDP and media components.

I think this matches exactly what we intended to say so if you are happy 
with it I think it's perfect.

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

Well ... we have media and signalling going over different IP versions 
... but I see what you mean.

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

Yes, I think there might have been a misunderstanding here. I used some 
of your wording and arrived at:

         In typical deployments, the media relay and signaling
         intermediary (i.e., the SBC) are co-located, thereby sharing the
         same IP address. Also, the address of the media relay would
         typically belong to the same IP address family as the one used
         for signaling, as it is known to work for that UA. In other
         words, signalling and media would either both travel over IPv4
         or IPv6.

Is this better?

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

Ah! Gotcha! Better now?

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

Done.

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

Got it. Changed.

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

This section got completely reworded during IESG review and the above 
text is no longer there so ...

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

Also rewritten during IESG review.

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

OK. Changed for tuple everywhere.

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

I assume if an "Eve" is necessary it is easier to just pick a couple of 
other common protagonists: [e-mail] and [e-mail], 
and then just go for [e-mail]

> Thanks for your time on this, Emil.

Thank you for yours Vijay!

Emil

-- 
https://jitsi.org