Hi David,
I have finally gotten to do the update of this document. I thank you
very much as I believe the document has gotten substantially better and
more consistent due to your and Sarah Banks review comments.
I will say upfront that the updated version has not become a
masterpiece, but it will suck a bit less. My view is that this document
contains some valuable pieces of information, but it is not worth
spending tons of time in editing.
I have some inline response to your comments and question below.
Black, David skrev den 2014-06-15 04:56:
Document: draft-ietf-mmusic-rtsp-nat-evaluation-14
Reviewer: David L. Black
Review Date: June 14, 2014
IETF LC End Date: June 13, 2014
Major issues:
[1] The abstract characterizes this draft as the evaluation that lead to
the mmusic WG's choice of the NAT traversal technique for RTSP, but
the evaluation in this draft did not drive that choice, as indicated
in Section 6:
Looking at Figure 1 one would draw the conclusion that using TCP
Tunneling or Three-Way Latching is the solutions that best fulfill
the requirements. The different techniques were discussed in the
MMUSIC WG. It was established that the WG would pursue an ICE based
solution due to its generality and capability of handling also
servers delivering media from behind NATs.
OTOH, there appears to be a lot of useful material in this draft that
should be published in an informational RFC, not only the comparison, of
NAT traversal techniques, but also documentation of some of those
techniques, as indicated in Section 4:
This section includes NAT traversal techniques that
have not been formally specified anywhere else. The overview section
of this document may be the only publicly available specification of
some of the NAT traversal techniques.
This may be fairly simple to address, as the last sentence in the
abstract and the Section 6 text quoted above are the primary sources
of this issue. It may also help to change the title of this draft
from "The Evaluation of ..." to "Comparison of ..." and do something
analogous to other occurrences of the word "evaluation" in this draft.
Yes, I have attempted to do what your suggest. I think it mostly
resolves the issue.
[2] Section 4 says:
Some other techniques have been recommended against or are no longer
possible due to standardization works' outcome or their failure to
progress within IETF after the initial evaluation in this document,
e.g. RTP No-Op [I-D.ietf-avt-rtp-no-op].
That's too vague, an explicit list should be provided of techniques in
Section 4 that should not or cannot currently be used, starting with RTP
No-Op including an explanation of why that is the case for each technique.
There's also an important editorial clarification needed - these
"other techniques" are not NAT traversal techniques; they are possible
elements of some NAT traversal techniques.
This text is 4.1.1 is part of this issue:
The first version of STUN [RFC3489] included categorization and
parameterization of NATs. This was abandoned in the updated version
[RFC5389] due to it being unreliable and brittle. Some of the below
discussed methods are based on RFC3489 functionality which will be
called out and the downside of that will be part of the
characterization.
I have attempted to be clearer in the text when methods are based on
either deprecated or abandoned proposals. However, from my perspective,
especially for abandoned work, if one would have wanted to pursue a
mechanism based on abandoned work it could have been resurrected.
Deprecated is worse as that usually have a good motivation behind its
removal.
Minor issues:
-- Section 2, last paragraph.
[E]
Note that if neither RTCP packets nor RTSP
messages are received by the RTSP server for a while, the RTSP server
has the option to delete the corresponding RTP session, SSRC and RTSP
session ID, because either the client can not get through a middle
box NAT/firewall, or the client is mal-functioning.
Is there any delay recommended before RTSP server reuse of that set of
identifying information (RTP session, SSRC and RTSP session ID)?
No, to my knowledge there exist no such recommendation. However, the
RTSP session is basically defined by the RTSP session context and the
used 5-tuples. The SSRC are scoped by session, and should be randomly
generated to minimize the risk of collision. RTSP session IDs needs to
be generated with very low probability of collision with any recently used.
[I] Still in Section 3
Note a simple preventative measure commonly
deployed is for the RTSP server to disallow the cases where the
client's RTP receiver has a different IP address than that of the
RTSP client. With the increased deployment of NAT middleboxes by
operators, i.e. carrier grade NAT (CGN), the reuse of an IP address
on the NAT's external side by many customers reduces the protection
provided. Also in some applications (e.g., centralized
conferencing), dual-hosted RTSP/RTP clients have valid use cases.
The key is how to authenticate the messages exchanged during the NAT
traversal process.
Is that "measure commonly deployed" recommended? The above text chunk
feels like Security Considerations text, and this text could usefully
be moved to Section 8.
In RTSP 2.0 this is well documented and recommended practice. See
Section 21.2.2 in
https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc2326bis/
[J] Section 4.1.1 relies on STUN's abandoned NAT type classification
functionality to determine where to send the hole-punching UDP packets.
What's wrong with always sending those packets to the "server's source
address/port"? That should work for both types of NATs, thereby removing
the dependency on STUN classification of NAT types.
Actually that is not the main reason. The difference between 4.1
Stand-alone STUN and 4.2 Embedded STUN is where the STUN server is. In
4.2 the STUN server is sharing the server port, thus taking care of
handling the STUN requests and sending respone. For 4.1 the server can
be either on its own IP or share IP but have a different port compared
to the RTSP server. The classification method is basically to detect
cases where the method would fail, prior to really attempting them. One
could skip the classification and instead fail during SETUP. But that
will result in the server starting to send media, which will not be
delivered to the client. This late failure I think is desirable to
avoid. But, this has been clarified:
The first version of STUN [RFC3489] included categorization and
parameterization of NATs. This was abandoned in the updated version
[RFC5389] due to it being unreliable and brittle. This particular
traversal method uses the removed RFC3489 functionality to detect the
NAT type to give an early failure indication when the NAT is showing
the behavior that this method can't support. This method also
suggest using the RTP NO-OP payload format [I-D.ietf-avt-rtp-no-op]
for key-alives of the RTP traffic in the client to server direction.
This can be replaced with another form of UDP packet as will be
further discussed below.
[K] Why are ALG considerations only applicable to STUN-based techniques?
They are applicable to all cases. I have corrected this in this version.
In most cases the main finding about ALGs was listed in the Deployment
considerations.
Cheers
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(_dot_)westerlund(_at_)ericsson(_dot_)com
----------------------------------------------------------------------