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

From: Alissa Cooper <[email-masked]>
Date: Thu, 15 May 2014 14:31:19 -0700

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/

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 16 May 2014 13:04:53 +0200

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:
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
> 

-- 

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 28 May 2014 18:23:17 +0200

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.

> touched on here and there, but it would be good to set out the scope at

Ok, will add a paragraph on that.

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

> a middlebox blocking the traffic.”

Sure, this is more correct.

> in Section 4 covers cases where the server is behind a NAT and where it is

I have replaced first with primary. It being the most important case to
resolve.

> open”? And are you recommending minimal impact only in the case of

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.

> This is only true for servers that already implement RTSP 2.0. This should

Ok

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

> the mechanisms but not others. Could the authors provide a justification

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.

> discussion” and this section just points back to 4.1.5. Was that

Yes, to not break the template.

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

> really a matter of “correctness,” but an implementation choice that

Yes, added.

"An important factor is to secure the signalling, i.e. use TLS between
RTSP client and server."

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

> Need different phrasing for “virtual RTP connection” — it’s not actually

Sure, what about:

 the first packet that the client sends to the server to establish a
bi-directional transport flow for RTP streams.

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

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

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

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

> 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

-- 

Magnus Westerlund

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 28 May 2014 10:44:20 -0700

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

---

From: Alissa Cooper <[email-masked]>
Date: Fri, 30 May 2014 12:12:07 -0700

Comments inline.

>is not behind a NAT compared to a SIP user-agent.

s/is recommended/are recommended/
s/likely hood/likelihood/

>a NAT traversal solution that allow for security.

Yes, good.

>relayed through the same TURN server.

How about:
Alternatively, TURN can be used if both the RTSP TCP connection and the
RTP media are relayed through the same TURN server.

>the transport flows for the media.

Looks good.

>perspective, just maybe not as clear or where you may have expected it

This doesn’t make much sense to me — if you’re going to make a numbered
list of requirements, why not include them all in the list?

>will also simplify spoofing of STUN binding messages by revealing the

The above looks good. It might help to work in a reference to RFC 5245
section 18.

Thanks,
Alissa