Subject: [MMUSIC] 1 Week WGLC for draft-ietf-mmusic-rtsp-nat-evaluation-06

From: Flemming Andreasen <[email-masked]>
Date: Thu, 09 May 2013 10:52:10 -0400

We previously had a 2 week WGLC on the rtsp-nat-evaluation draft which 
resulted in several updates to the draft. The resulting -06 has been out 
for review without any additional comments for quite some time now. 
Based on that, we are announcing a 1 week Working Group Last Call for

     draft-ietf-mmusic-rtsp-nat-evaluation-06

as Informational. Please review and provide any comments you may have on 
the document by May 16, 2013. Comments should be sent to the document 
authors and the MMUSIC WG list. If you review the document but do not 
have any comments, please send a note to that effect as well.

Thanks

        Flemming

Draft Info:

A New Internet-Draft is available from the on-line Internet-Drafts directories.
  This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF.

	Title           : The Evaluation of Different Network Address Translator (NAT) Traversal Techniques for Media Controlled by Real-time Streaming Protocol (RTSP)
	Author(s)       : Magnus Westerlund
                           Thomas Zeng
	Filename        : draft-ietf-mmusic-rtsp-nat-evaluation-06.txt
	Pages           : 41
	Date            : 2012-11-23

Abstract:
    This document describes several Network Address Translator (NAT)
    traversal techniques that were considered to be used for establishing
    the RTP media flows controlled by the Real-time Streaming Protocol
    (RTSP).  Each technique includes a description on how it would be
    used, the security implications of using it and any other deployment
    considerations it has.  There are also discussions on how NAT
    traversal techniques relates to firewalls and how each technique can
    be applied in different use cases.  These findings where used when
    selecting the NAT traversal for RTSP 2.0.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-rtsp-nat-evaluation

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-mmusic-rtsp-nat-evaluation-06

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rtsp-nat-evaluation-06

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 17 May 2013 09:54:11 -0400

The WGLC has now ended. We did not receive any comments and hence the 
document is ready to move forward at this point.

Thanks

-- Flemming

On 5/9/13 10:52 AM, Flemming Andreasen wrote:
> resulted in several updates to the draft. The resulting -06 has been 
> out for review without any additional comments for quite some time 
> now. Based on that, we are announcing a 1 week Working Group Last Call for
>
> as Informational. Please review and provide any comments you may have 
> on the document by May 16, 2013. Comments should be sent to the 
> document authors and the MMUSIC WG list. If you review the document 
> but do not have any comments, please send a note to that effect as well.
>
> Thanks
>
>        Flemming
>
>
> Draft Info:

---

From: Ari Keränen <[email-masked]>
Date: Fri, 17 May 2013 18:49:36 +0300

Hi,

I had a quick read over the draft and have a few comments:

3.  Requirements on NAT-Traversal

    1.  Must work for all flavors of NATs, including NATs with address
        and port restricted filtering.

The term used by RFC 4787 is "Address and Port-Dependent Filtering"

3.  Requirements on NAT-Traversal

    The list of feature requirements for RTSP NAT solutions are given
    below:

I guess this should say "RTSP NAT traversal solutions".

        *  Address discovery for NAT traversal should take automatically,
           if possible

I assume this means the discovery of the address assigned by the NAT? 
Maybe say that explicitly, e.g., "Discovery of the address(es) assigned 
by NAT should happen automatically if possible".

4.7.4.  Security Considerations

    An ALG will not work whit deployment of end-to-end RTSP signaling

Typo: whit

4.9.1.  [TURN] Introduction

    On the external side this is
    limited to the source address/port pair of the first packet arriving
    on the binding.  After the first packet has arrived the mapping is
    "locked down" to that address.  Packets from any other source on this
    address will be discarded.

This doesn't sound right. This behavior was changed (eventually into 
using permissions) somewhere back in draft-rosenberg-midcom-turn-06. See 
http://tools.ietf.org/html/rfc5766#section-2.3 for up-to-date behavior. 
Check also steps 5 & 7 in the next section and section 4.9.4 for more 
lock down text.

6.  Comparison of NAT traversal techniques

    C2:  How Robust is the solution to changing NAT behaviors

Since the answer is yes/no, maybe this should be "is the solution robust..."

10.  Informative References

    [STUN-IMPL]
               "Open Source STUN Server and Client, http://
               www.vovida.org/applications/downloads/stun/index.html",
               June 2007.

This site seems to be unavailable nowadays. Better reference would be 
"http://sourceforge.net/projects/stun/". And of course, there are plenty 
of other open source STUN implementations, but likewise there are for 
ICE (PJNATH, libnice, ice4j, etc.) if we want to use that as an argument.

Cheers,
Ari (as individual)

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 23 May 2013 11:37:57 +0200

Thanks Ari,

I will try to role a new version within the next few days addressing
your comments. If there are any issues in implementing them I will come
back with such discussion.

Cheers

Magnus

-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
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: Thu, 23 May 2013 16:47:20 +0200

> Check also steps 5 & 7 in the next section and section 4.9.4 for more

I changed this to:

To prevent DoS attacks on either recipient, the packets forwarded are
restricted to the specific source address. On the client side it is
restricted to the source setting up the allocation. On the external side
this is limited to the source address/port pair that have been given
permission by the TURN client creating the allocation. Packets from any
other source on this address will be discarded.

I will shortly submit an updated draft.

Cheers

Magnus Westerlund

---

From: Ari Keränen <[email-masked]>
Date: Thu, 23 May 2013 20:58:41 +0300

> I will shortly submit an updated draft.

Looks good to me. However, also the following sections had some "lock 
down" text that should be updated (see details on my original mail above).

Cheers,
Ari

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 27 May 2013 11:29:49 +0200

Hi,

Sorry for missing the other changes. I think I gotten all the lock down
changed now. This has resulted in some significant changes in the text
for TURN relays, including a server implementation requirement. I
recommend that people do take a look at the diff:

http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rtsp-nat-evaluation-08

Cheers

Magnus

-- 

Magnus Westerlund

---

From: Ari Keränen <[email-masked]>
Date: Wed, 29 May 2013 12:51:30 +0300

Hi Magnus,

The diff looked good. Couple of quick nits:

    5.  The RTSP Client uses the RTSP Servers response to create TURN

s/Servers/Server's/

    7.  The first media packet to arrive at the TURN server on the
        external port; If matching established permissions the TURN
        server forwards the media packets to the RTSP client.

s/If matching/If there exists a matching/
or /If the packet matches an/

Cheers,
Ari

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 29 May 2013 15:02:37 +0200

> or /If the packet matches an/

Thanks,

I have updated the draft to resolve these issues.

Cheers

Magnus Westerlund