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

[Alissa Cooper <[e-mail]>]

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/