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

[Magnus Westerlund <[e-mail]>]

On 2012-11-15 16:59, Flemming Andreasen wrote:
> 
> On 11/15/12 10:08 AM, Magnus Westerlund wrote:
>> Hi Flemming,
>>
>> Thanks for the comments.
>>
>> On 2012-10-11 21:35, Flemming Andreasen wrote:

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

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

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.

> 
> 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) ?

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.


>>>
>>> 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.
>>
> Ok - I think it's worth calling out explicitly.

Sure.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------