Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-rtsp-nat-evaluation-05

From: Magnus Westerlund <[email-masked]>
Date: Thu, 15 Nov 2012 16:08:19 +0100

Hi Flemming,

Thanks for the comments.

On 2012-10-11 21:35, Flemming Andreasen wrote:
> I have reviewed the RTSP NAT Evaluation document and have several
> comments on it, both technical and editorial. I will provide the main
> technical comments below and send the minor and editorial comments
> directly to the authors in a more "user-friendly" format.
> 
> 
> Major comments
> 
> - STUN based on either RFC 3489 or RFC 5389 (or both). The draft
> discusses use of STUN as a NAT traversal mechanism (with some RTSP
> operational "extensions"), and in so doing it references both RFC 3489
> (which is obsolete) and RFC 5389 (the replacement). Furthermore, in
> several places, it bases and describes operation on now defunct
> (obsolete) RFC 3489 logic and messages instead of RFC 5389. This either
> needs to be rectified, or we should have a very good explanation in the
> document as to why we are using RFC 3489 (and then be clear which parts
> are based on RFC 3489 and which are based on RFC 5389).

I intended to go with an background explanation. This document was
evaluating RTSP NAT proposals at a time and in a context which is
significantly before RFC 5389. Yes, the limits to the classification
techniques exist and should be correctly described. But the fact that
they was considered can not be undone in a document intended to document
the considerations done at that time of picking ICE as a solution. Which
is now 7+ year into history.

> 
> - "Symmetric RTP" is called out as a potential solution for NAT
> traversal with 3 different variations. Note that symmetric RTP is
> defined in RFC 4961, and what is described in this document as
> "symmetric RTP" looks a lot more like latching to me, with all the
> potential issues that brings (and then some due to the shared use of
> ports and hence shared SSRC space between different clients, as noted in
> the document). The document needs to clear up its terminology in this
> area ("connect", "binding", latch, symmetric RTP, etc.) and be clearer
> about what is being proposed (which is latching as far as I can tell,
> however it makes reference to certain mechanisms that aren't fully
> described, e.g. binding packets with random nonces).

Yes, it is what called latching today. When this was originally written
latching wasn't called latching in this community. But I will work
through the text to try avoid any missunderstandings. There is after all
a basic requirement on latching that one uses symmetric RTP after the
latching or things don't work.

> 
> 
> Other significant comments
> 
> - The draft intends to investigate and outline different RTSP NAT
> traversal proposals with the goal of picking one for further detailed
> specification (which can be found in the draft-ietf-mmusic-rtsp-nat
> spec). There is a mixture of RFC 2119 language and more informal
> language in several of these descriptions. Given that these are
> high-level descriptions and have not been specified in detail, I do not
> think we should give any other impression and hence I think RFC 2119
> language should be avoided.

Fully agreed. There should be no RFC 2119 language in this doc.

> 
> - The draft suggests that the RTSP server needs to enforce that
> signaling and media come from the same IP-address as a security remedy
> in several places, however this may not work with larger scale NATs
> (e.g. carrier-grade NATs) where the NAT may be using more than one
> external IP-address.

It is more than a suggestion. It is an fact that servers implements this
protection. If a CGN fails to give a host the same IP address then
unfortunately that client will not get any content. I will claim it is
the CGN that is more broken than the security mechanism.

> 
> - The comparison section is missing two of the alternatives considered
> (namely ALG and TCP tunneling). Also, the comparison chart would lead
> most people to a different solution than the one chosen. To some extent,
> I think it's because the requirements list is a simplified list of all
> the considerations behind each of the proposals (as more fully explained
> in the document overall). There are additional drawbacks to some of
> these other solutions that do not show up in the table (e.g.
> unauthenticated "latching" and requirement for RTSP server to have
> public IP-address). It would be worthwhile briefly recapping those and
> hence further motivate the choice of ICE in this section.

Ok, will see what I can do with reasonable work effort.

cheers

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: Flemming Andreasen <[email-masked]>
Date: Thu, 15 Nov 2012 10:59:12 -0500

> is now 7+ year into history.
Perhaps this is a more general question since we have at least other 
document in the WG with a similar issue:

- For documents that have been underway for a long time, and the 
technology/references they describe has since evolved, should we base 
this on the original technology and knowledge at the time or should it 
reflect the state of affairs at time of publication ?

I tend to think it should be the latter, although I don't see anything 
with also including references to older technology, as long as the 
limitations are noted, the new technology is called out, and we don't 
make any normative recommendations around use of the old technology 
unless there is a very good reason to do so.

In the specific case, is there any particular reason (apart from this 
obviously being more/new work again) why we wouldn't reference RFC 5389 
at this point and possibly note the limitations of the RFC 3489 approach 
as well (for background) ?

> latching or things don't work.
Ok.
> the CGN that is more broken than the security mechanism.
Ok - I think it's worth calling out explicitly.
> Ok, will see what I can do with reasonable work effort.
Sounds good.

Thanks

-- Flemming

> .

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 16 Nov 2012 11:19:52 +0100

> unless there is a very good reason to do so.

I would tend to agree with you. At the same time I am feeling the
authors pain with having to make substantial changes to the document
which likely was correct, but which requires more work due to the slow
publication of the document. And in retrospect we probably should have
published this document a long time ago. It isn't really dependent on
the technical specifications.

> as well (for background) ?

Not for the functionality that is present in RFC 5389 I don't see any
issues. But for this document, I will clearly be required to reference both.

> Ok - I think it's worth calling out explicitly.

Sure.

Cheers

Magnus Westerlund