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

[Magnus Westerlund <[e-mail]>]

Alissa, WG,

Thanks for the review.

I will attempt to address these before my parental leave that starts at
the end of the month, but I am uncertain if I will be able. So in worst
case this might be left hanging for the rest of the year for your
knowledge. My co-author is also not any longer an active participant in
the IETF.

Cheers

Magnus

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.
> 
> 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."
> 
> 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.”
> 
> 
> 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.
> 
> "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?
> 
> 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.
> 
> 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.
> 
> 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?
> 
> 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?
> 
> 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?
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.”
> 
> Sec 5:
> Is it worth noting here the implications for firewalls when RTSP uses
> confidentiality protection?
> 
> Sec 6:
> Why are C1 and C2 not discussed in Section 3?
> 
> 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.
> 
> ---
> 
> 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]
----------------------------------------------------------------------