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

Magnus Westerlund <magnus.westerlund@ericsson.com> Wed, 28 May 2014 16:23 UTC

Return-Path: <magnus.westerlund@ericsson.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A5CA1A0A17 for <mmusic@ietfa.amsl.com>; Wed, 28 May 2014 09:23:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jgOb3blubn1b for <mmusic@ietfa.amsl.com>; Wed, 28 May 2014 09:23:31 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E362D1A04C5 for <mmusic@ietf.org>; Wed, 28 May 2014 09:23:30 -0700 (PDT)
X-AuditID: c1b4fb3a-f79746d000006fe2-75-53860d7d11c3
Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 12.92.28642.D7D06835; Wed, 28 May 2014 18:23:25 +0200 (CEST)
Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.32) with Microsoft SMTP Server id 14.3.174.1; Wed, 28 May 2014 18:23:25 +0200
Message-ID: <53860D75.2010400@ericsson.com>
Date: Wed, 28 May 2014 18:23:17 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: Alissa Cooper <alissa@cooperw.in>, mmusic@ietf.org
References: <CF99093B.398BC%alcoop@cisco.com>
In-Reply-To: <CF99093B.398BC%alcoop@cisco.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCLMWRmVeSWpSXmKPExsUyM+JvjW4tb1uwwYdJNhbTz/xltJi6/DGL A5PHlycvmTyWLPnJFMAUxWWTkpqTWZZapG+XwJUxr/MFY8HVdsaKHVOXsjUwrs3qYuTkkBAw kfjU84oVwhaTuHBvPVsXIxeHkMBRRok5Tw+yQzjLGSWePfrNDFLFK6At8ePFRJYuRg4OFgFV id7J7iBhNgELiZs/GtlAbFGBYIkND/+yQ5QLSpyc+YQFxBYBqjn/9xPYMmEBX4n7DxexgowR EtCVOL/aDSTMKaAnse/PfCaQsISAuERPYxBImFlAU6J1+292CFteonnrbLBjhICOaWjqYJ3A KDgLybJZSFpmIWlZwMi8ilG0OLW4ODfdyEgvtSgzubg4P08vL7VkEyMwWA9u+W21g/Hgc8dD jAIcjEo8vAsutQQLsSaWFVfmHmKU5mBREue9qFEdLCSQnliSmp2aWpBaFF9UmpNafIiRiYNT qoFR8Ll2ejFbG+sW9vsJjROSUh1SvXO1K4sW/Hn2ZQrzrfczGFq5v1/O+f/g7sKZjoIFFus7 fvzdkjjnfaLAlQXGy7e/4DxVbm7w8yJXBOsBb+enEavslojorv17/3T8vjO7VgdFb/4boJHn czousqjju5Kwb+7ci0r/mZ7IK+T2qn41aPwk16CsxFKckWioxVxUnAgAH4+gKDcCAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/X3ONSQsOJHL2hzmNPX-PC1Bq8vw
Subject: Re: [MMUSIC] AD evaluation: draft-ietf-mmusic-rtsp-nat-evaluation-13
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 May 2014 16:23:34 -0000

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
> mmusic@ietf.org
> 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: magnus.westerlund@ericsson.com
----------------------------------------------------------------------