Re: [MMUSIC] AD evaluation: draft-ietf-mmusic-rtsp-nat-evaluation-13

[Alissa Cooper <[e-mail]>]

Thanks. These mostly look good. I will send detailed responses in a
separate mail so that together with the nits there will be a record of
what further changes need to be made after IETF LC, and after that I’ll
issue the LC.

Alissa

On 5/28/14, 9:23 AM, "Magnus Westerlund" <[e-mail]>
wrote:

>Hi,
>
>Once more thanks for the review. Please response to the comments here. I
>have not yet addressed the nits, these will have to be addressed in a
>later stage.
>
>On 2014-05-15 23:31, Alissa Cooper wrote:
>> I have reviewed draft-ietf-mmusic-rtsp-nat-evaluation-13 and I have a
>> number of comments and questions below that I’d like to see resolved
>> before sending this document to IETF LC. I’ve also included a long list
>>of
>> nits below to be resolved along with any LC comments. Overall, although
>> the content of this document is good, I wish the clarity would have been
>> better — it was quite difficult to review.
>> 
>> Comments and questions:
>> 
>> General:
>> It might be good in the introduction to characterize the extent to which
>> this document is focused on single-NAT environments versus CGN/multiple
>> NAT. The applicability of the various solutions in CGN environments is
>> touched on here and there, but it would be good to set out the scope at
>> the beginning.
>
>Ok, will add a paragraph on that.
>
>> 
>> There are a number of references to an RSTP server being “in the public”
>> or “public.” I think it would be better in those cases to say that the
>> server is not behind a NAT, as opposed to “public."
>
>Ok, I have reworded a number of cases where it is not specific to
>discuss public IP addresses.
>
>> 
>> Sec 2:
>> "If a client does not receive data within a few seconds after
>>    having received the "200 OK" response to a PLAY request, there are
>>    likely some middleboxes blocking the traffic.”
>> 
>> This seems like a fairly sweeping statement. Surely the lack of response
>> could be caused by congestion somewhere along the path? I would suggest:
>> 
>> "If a client does not receive data within a few seconds after having
>> received the "200 OK" response to a PLAY request, it may be the result
>>of
>> a middlebox blocking the traffic.”
>
>Sure, this is more correct.
>
>> 
>> 
>> Sec 3:
>> "In terms of requirements, the
>>    first requirement should be to solve the RTSP NAT traversal problem
>>    for RTSP servers deployed in a public network, i.e. no NAT at the
>>    server side.”
>> 
>> What does “the first requirement” mean? It seems to me that the analysis
>> in Section 4 covers cases where the server is behind a NAT and where it
>>is
>> not.
>
>I have replaced first with primary. It being the most important case to
>resolve.
>
>> 
>> "Should have minimal impact on clients in the open and not dual-hosted."
>> 
>> I don’t understand this. What does it mean for a client to be “in the
>> open”? And are you recommending minimal impact only in the case of
>> single-hosted RTSP?
>
>I changed this to:
>
>"Should have minimal impact on clients not behind NATs and which are not
>dual-hosted."
>
>So open is the client not behind NATs or Firewalls.
>
>The requirement was written so that we should keep in mind that the
>impact on the clients that worked without a NAT traversal solution
>should not be significantly impaired by the solution.
>
>> 
>> Sec 4.1.4:
>> "Using STUN does not require RTSP server modifications”
>> 
>> This is only true for servers that already implement RTSP 2.0. This
>>should
>> be made explicit.
>
>Ok
>
>
>> 
>> Sec 4.2.5:
>> "The removal of STUN capability in
>>    the client implementations will have to wait until there is
>>    absolutely no need to use STUN.”
>> 
>> I don’t quite get why this text is here. Of course if NAT ever
>>disappears
>> entirely, then none of the mechanisms described in this document will be
>> necessary, but that seems unlikely any time soon.
>
>I made a minor tweak to be even clear on how absurd they are. Please see
>below.
>
>> 
>> In general, I’m not sure I understand the purpose of the “Transition”
>> sections in this document, nor do I understand why they appear for some
>>of
>> the mechanisms but not others. Could the authors provide a justification
>> for that?
>
>
>Short Answer: Because IAB made us do it ;-). The long answer is that
>these are the UNSAF "transition" sections that RFC 3424 requires when
>discussing UNSAF mechanisms. Thus, all sections containing UNSAF
>solutions have them, not the others.
>
>> 
>> Sec 4.2.6:
>> The previous section said "See next section for an in-depth security
>> discussion” and this section just points back to 4.1.5. Was that
>> intentional?
>
>Yes, to not break the template.
>
>> 
>> Sec 4.3.2:
>> “High performance rather than always successful is recommended, as it
>>        is most likely to be a server in the public.”
>> 
>> Not quite sure what this means. I assume the “it” refers to the server
>>to
>> which the client is connecting? Even so, I don’t understand the claim.
>>Is
>> it that in general RTSP servers are more likely to be directly
>>addressable
>> than they are to be behind a NAT?
>
>I think this is clearer:
>
>High performance candidates is recommended rather than candidates with
>the highest likely hood of success, as it is more likely that a server
>is not behind a NAT compared to a SIP user-agent.
>
>
>> 
>> Sec 4.3.5:
>> For a section that is meant to explain the security properties of this
>> solution choice, this seems a little thin. In particular, it’s not clear
>> what it means to use ICE “correctly.” There are some attacks that are
>>only
>> mitigated if RTSP signaling is confidentiality protected — that’s not
>> really a matter of “correctness,” but an implementation choice that
>> deserves mention here.
>
>Yes, added.
>
>"An important factor is to secure the signalling, i.e. use TLS between
>RTSP client and server."
>
>
>> 
>> Sec. 4.4.3:
>> "The format of the RTP packet for "connection setup" (a.k.a
>>       Latching packet) is yet to be defined.  One possibility is to use
>>       RTP No-Op packet format in [I-D.ietf-avt-rtp-no-op].”
>> 
>> I’m assuming there isn’t actually any plan to define this. If that’s the
>> case, it would be better to just say so, rather than implying otherwise.
>> The text in 4.5.1 gets this right.
>
>I have reformulated this bullet to:
>
>   o  The format of the RTP packet for "connection setup" (a.k.a
>      Latching packet) is not defined.  One possibility considered was
>      to use RTP No-Op packet format in [I-D.ietf-avt-rtp-no-op], a
>      proposal which has been abandoned.
>
>> 
>> Sec 4.5.1:
>> "Latching as described above requires the usage of a valid RTP format
>>    as the Latching packet, i.e. the first packet that the client sends
>>    to the server to set up virtual RTP connection.
>> 
>> Need different phrasing for “virtual RTP connection” — it’s not actually
>> virtual.
>
>Sure, what about:
>
> the first packet that the client sends to the server to establish a
>bi-directional transport flow for RTP streams.
>
>> 
>> Sec 4.7.4:
>> "An ALG will not work with deployment of end-to-end RTSP signaling
>>    security.  Therefore deployment of ALG will likely result in clients
>>    located behind NATs not using end-to-end security.”
>> 
>> Not sure that’s the only conclusion to be drawn here, particularly if
>>the
>> client can traverse the NAT using some other mechanism.
>
>Are you fishing for something like this?
>
>An ALG will not work with deployment of end-to-end RTSP signaling
>security. Therefore deployment of ALG will likely result in clients
>located behind NATs not using end-to-end security, or more likely select
>a NAT traversal solution that allow for security.
>
>> 
>> Sec 4.9.1:
>> "This means that TURN could only be used if the server knows and
>>    accepts that the IP belongs to a TURN server and the TURN server
>>    can't be targeted at an unknown address or also the RTSP connection
>>    is relayed through the same TURN server.”
>> 
>> Not sure what is meant by the clause that begins “or also.”
>
>Is this clearer (instead of the "or also ...")
>
>Alternatively, both the RTSP TCP connection as well as the RTP media is
>relayed through the same TURN server.
>
>> 
>> Sec 5:
>> Is it worth noting here the implications for firewalls when RTSP uses
>> confidentiality protection?
>
>Something like this?
>
>The above possibilities for firewalls to inspect and respond to the
>signalling are prevented if confidentiality protection is used for the
>RTSP signalling, e.g. using the specified RTSP over TLS. This results in
>that firewalls can't be actively opening pinholes for the media streams
>based on the signalling. Instead other methods have to be used to enable
>the transport flows for the media.
>
>> 
>> Sec 6:
>> Why are C1 and C2 not discussed in Section 3?
>
>The case for C1 is discussed in the second paragraph of the section. C2
>I think you are correct are not discussed in that section, but it is
>discussed in Section 2.
>
>Yes the linkage could be greater, but the information is present from my
>perspective, just maybe not as clear or where you may have expected it
>to be.
>
>> 
>> Sec 8:
>> Conspicuously missing from this section is a discussion of the security
>> properties of ICE. Given that it is the chosen mechanism, those need to
>>be
>> discussed here, at least at the same cursory level as the security
>> considerations for all of the other mechanisms.
>
>I propose to add the following:
>
>ICE resolves the binding vulnerability of latching by using signed STUN
>messages, as well as requiring that both sides perform connectivity
>checks to verify that the target IP address in the candidate pair is
>both reachable and willing to respond. ICE can however create a
>significant amount of traffic if the number of candidate pairs are
>large. Thus pacing is required and implementations should attempt to
>limit their number of candidates to reduce the number of packets. If the
>signalling between the ICE peers (RTSP client and Server) is not
>confidentiality and integrity protected ICE is vulnerable to attacks
>where the candidate list is manipulated. Lack of signalling security
>will also simplify spoofing of STUN binding messages by revealing the
>secret used in signing.
>
>
>
>
>Will address the below nits in a later revision. I intended to submit a
>version now, to enable this document to take at least some more step
>towards publication while I am away.
>
>Cheers
>
>Magnus
>
>> 
>> ---
>> 
>> Nits to be resolved with any IETF last call comments received:
>> 
>> General:
>> “Firewall" should not be capitalized unless it appears at the beginning
>>of
>> a sentence or in the title of referenced document.
>> 
>> Sec 1:
>> s/This document is capturing/This document captures/
>> 
>> Sec 2:
>> s/techniques in the next chapter/techniques discussed in the next
>>section/
>> 
>> s/A RTP session/An RTP session/
>> 
>> s/no RTP packets has arrived/no RTP packets have arrived/
>> 
>> s/client can not get through/client cannot get through/
>> 
>> Section 3:
>> s/for RTSP NAT solutions/for RTSP NAT traversal solutions/
>> 
>> s/connection till arrival/connection until arrival/
>> 
>> Sec 4.1.2:
>> s/See [RFC4787] for full definition of these terms.//
>> (terms are also defined in this document
>> 
>> s/A RTSP client/An RTSP client/
>> 
>> s/a NAT(s)/a NAT/
>> 
>> s/a RTSP PLAY request/an RTSP PLAY request/
>> 
>> Sec 4.1.4:
>> s/a RTSP-aware ALG /an RTSP-aware ALG /
>> 
>> Sec 4.2.2:
>> s/one of the can/one of them can/
>> 
>> s/establishing TCP connection/establishing a TCP connection/
>> 
>> Sec 4.2.5:
>> s/a IETF standard/an IETF standard/
>> 
>> Sec 4.4:
>> s/Latching/latching/ (throughout the document)
>> 
>> Sec 4.4.3:
>> s/an public IP address./a public IP address./
>> 
>> Sec. 4.4.4:
>> s/the possible address a latching packet can come from to the same as
>>the
>> RTSP TCP connection are from/the source address of a latching packet to
>>be
>> the same as the source address of the RTSP TCP connection/
>> 
>> s/it is difficult to determine the address usage for the network the
>> client connects from./it cannot be assumed that addresses within the
>>range
>> all belong to the same client./
>> 
>> s/the server will send from and also the SSRC the client will use./that
>> the server will send from and that the SSRC client will use./
>> 
>> s/Having this information/Having this information,/
>> 
>> s/legit/legitimate/
>> (two occurrences)
>> 
>> s/which results in that the media server sends the RTP/RTCP traffic to
>> ports the client isn’t listening for RTP/RTCP on./which results in the
>> media server sending the RTP/RTCP traffic to ports on which the client
>>is
>> not listening for RTP/RTCP./
>> 
>> s/client to server network path/client-to-server network path/
>> 
>> s/To improve the security against attackers/To improve the security
>> against attackers,/
>> 
>> Sec. 4.5.1:
>> s/[I-D.ietf-avt-rtp-no-op], however, that work was
>> abandoned./[I-D.ietf-avt-rtp-no-op]. However, that work was abandoned./
>> 
>> OLD:
>> There exists a RFC that discusses the implication of different type of
>>    packets as keep-alives for RTP [RFC6263] and its findings are very
>>    relevant to the format of the Latching packet.
>> 
>> NEW:
>> The findings of [RFC6263] concerning the implications of different types
>> of packets as keep-alives for RTP are very relevant to the format of the
>> Latching packet.
>> 
>> s/there has been/there have been/
>> 
>> Sec. 4.5.2:
>> s/so called/so-called/
>> 
>> s/as Latching packet/as a Latching packet/
>> 
>> Sec 4.5.3:
>> s/(Requirement 4 in Section 3), instead a Latching protocol must be
>> defined./(Requirement 4 in Section 3). Instead a Latching protocol must
>>be
>> defined./
>> 
>> Sec 4.5.4:
>> s/more unlikely/less likely/
>> 
>> s/works and when it didn’t/worked and when it did not/
>> 
>> s/security issue remain/security issue remains/
>> 
>> s/a RTSP client/an RTSP client/
>> 
>> s/likes to/intends to/
>> 
>> s/an DoS target/a DoS target/
>> 
>> Sec 4.6:
>> s/three way Latching/three-way latching/ (throughout)
>> 
>> Sec 4.6.2:
>> s/Uses the same RTSP extensions/Three-way latching uses the same RTSP
>> extensions/
>> 
>> s/client to server latching packet/client-to-server latching packet/
>> 
>> s/an UDP packet/a UDP packet/
>> 
>> s/nonce.  Thus confirming/nonce, thus confirming/
>> 
>> s/a RTSP client/an RTSP client/
>> 
>> Sec 4.6.3:
>> s/have the following/has the following/
>> 
>> Sec 4.7.4:
>> s/an UDP mapping/a UDP mapping/
>> 
>> s/with RTSP ALG/with an RTSP ALG/
>> 
>> Sec 4.8.3:
>> s/where the RTSP server in not NATed or at least reachable like it was
>> not./where the RTSP server is not NATed or is reachable as if it were
>>not
>> NATed./
>> 
>> Sec 4.9.1:
>> s/a RTSP client/an RTSP client/
>> 
>> s/the IP belongs/the IP address belongs/
>> 
>> Sec 4.9.2:
>> s/addresses also the TCP connection must be done through the same TURN
>> server as the one in the next step./addresses, the TCP connection must
>>be
>> made through the same TURN server to be used for NAT traversal./
>> 
>> s/that it desires/where it desires/
>> 
>> Sec 4.9.3:
>> s/has public/has a public/
>> 
>> Sec 4.9.4:
>> s/a RTSP session/an RTSP session/
>> 
>> s/Which would/This would/
>> 
>> Sec 5:
>> s/a RTSP session/an RTSP session/
>> 
>> 
>> s/what type of transport and from where, the media stream packets will
>>be
>> sent./what type of transport will be used and from where the media
>>stream
>> packets will be sent./
>> 
>> Sec 6:
>> s/R1:  Work/R1:  Must work/
>> 
>> s/use, Implement and administer/use, implement and administer/
>> 
>> OLD:
>> C1:  Will solution support both Clients and Servers behind NAT
>> 
>>    C2:  Is the solution robust to changing NAT behaviors
>> NEW:
>> 
>> C1: Supports both clients and servers behind NAT
>> 
>>    C2:  Is robust to changing NAT behaviors
>> 
>> s/using TCP Tunneling or Three-Way Latching is the solutions that best
>> fulfill/TCP Tunneling or Three-Way Latching is the solution that best
>> fulfills/
>> 
>> s/is acceptable/are acceptable/
>> 
>> s/When it comes to Three-Way Latching it is a very competitive technique
>> given that you don't need support for RTSP servers behind
>>NATs./Three-Way
>> Latching is a comparable technique in situations where support for RTSP
>> servers behind NATs is not required./
>> 
>> s/were some discussion/were some discussions/
>> 
>> s/In the end the authors believe that reuse of ICE, the greater
>> flexibility and anyway need to deploy a new solution was the decisive
>> factors./In the end, the WG concluded that reuse of ICE, its greater
>> flexibility, and the need to deploy a new solution in either case were
>>the
>> decisive factors in favor of ICE./
>> 
>> Sec 8:
>> s/IP-address/IP address/
>> 
>> s/those variants/of those variants/
>> 
>> Sec 9:
>> s/has commented/have commented/
>> 
>> s/protocol/document/
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> mmusic mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mmusic
>> 
>
>
>-- 
>
>Magnus Westerlund
>
>----------------------------------------------------------------------
>Services, Media and Network features, Ericsson Research EAB/TXM
>----------------------------------------------------------------------
>Ericsson AB                 | Phone  [phone]
>Färögatan 6                 | Mobile [phone]
>SE-164 80 Stockholm, Sweden | mailto: [e-mail]
>----------------------------------------------------------------------
>