Document: draft-ietf-sipping-nat-scenarios-08 Reviewer: Philip Matthews Review Date: 5/21/2008 Review Due: 5/23/2008 Review Type: WGLC - RAI Area (MMUSIC) Summary: My general assessment of this document is that it is useful and on the right track. I feel that a document that brings together all the various NAT traversal pieces for SIP would be very helpful. However there are a number of technical issues which need addressing. Most seriously, it advocates the use of STUN and TURN without ICE, which is no longer supported. I have divided my comments up into technical comments and presentation comments. Technical comments ================== 1) Section 3.2.5.2 (Consumer Profile) recommends the use of STUN alone (without ICE). However, the use of STUN in this manner is problematic, insecure, and is no longer supported by the latest STUN spec (draft- ietf-behave-rfc3489bis). STUN is now a toolkit which is used by other protocols. To use STUN in the manner described in section 3.2.5.2, someone would have to write a draft describing this usage of STUN, describe what is in this usage, and describe the security considerations of this usage. This draft would have to somehow deal with the problems and security concerns that are known to plague this usage in general. It might be possible to fix or avoid these problems by constraining the use of this technique to specific situations, but I am not aware of any attempt to do so. This comment also applies to the examples using STUN alone. Though not mentioned in the profile, the document seems to also advocate the use of TURN without ICE. My comments on STUN without ICE mostly apply to the use of TURN without ICE as well. 2) The status of ICE-TCP is unclear at the current time. There are some technical problems with the proposal, and no agreement yet on how to proceed. It is possible that ICE-TCP will be dropped and work will go in a different direction. This document normatively references ICE- TCP, but ICE-TCP is not really required for client-server SIP. So I suggest either removing the reference, or changing it to an informative reference. 3) I haven't been following the Outbound and GRUU work closely, but my imperfect understanding is that both of these are part of the NAT traversal solution for SIP. Don't you need to include Outbound and GRUU in the solution profiles? Similarly, shouldn't GRUU be discussed in the first part of section 3? 4) The best practices described in this document are for "client- server"-style SIP. It seems likely that P2PSIP will recommend these same practices between a P2PSIP client and a P2PSIP peer, but will recommend different practices for use between peers in a peer-to-peer network. Should the title be changed to "Best Current Practices for NAT Traversal for Client-Server SIP" and a paragraph be added to the introduction to explain what is meant by this? 5) The document uses the terminology "Endpoint-Independent NAT", "Address Independent NAT", "Address and Port Dependent NAT" etc. This terminology is not consistent with the BEHAVE terminology used in RFC 4787, which instead discusses mapping vs. filtering behavior. 6) In section 4.2.1.2, there is an example of media traversal using ICE. This example is out-of-date, as their have been some technical changes to the ICE standard since it was prepared. There are also a few other errors: some are typos, some are terminology errors; plus a few details that should be changed to make the example more realistic (e.g., in reality, the Answer (R) would almost certainly initiate the connectivity checks). 7) In section 4.2.2.2, there is an example using TURN. This example is also out-of-date, as the TURN specification has also changed recently. Also, the correct usage of TURN is in conjunction with ICE, which is not shown in this example. Using TURN without ICE is not supported, in the same way that STUN without ICE is not supported. [Note that if ICE _is_ used in this example, then the media path would end up going directly, as this is not an example that needs TURN.] 8) In section 4.2.2.3, there is another ICE example. This example is again out-of-date, and it also fails to discuss the very important aspect of learning peer-reflexive candidates which happens in the situation shown in this example. 9) In section 5.2, there is an example of using TURN to translate between IPv4 and IPv6. As before, this example needs to be updated to the latest TURN specification and also needs to include ICE. Also, the details of how TURN will be used in such a situation are still under discussion, and I expect there may be changes. Presentation comments ===================== The following comments deal only with the presentation of the information in the document. Feel free to ignore any suggestions you do not agree with. General comments I found it a bit difficult to read this document, because the text in section 3 mixes problem description, solution description, and requirements. I also find the relationship between the first part of section 3 and the solution profiles in the second part to be confusing. Is the first part of section 3 supposed to be just an overview of the solution pieces?? Or do they present basic requirements which are then covered more fully in the solution profiles? I suggest: a) Move all the problem description text into section 2 b) Clearly differentiate between the informative and normative text describing the solution c) Clearly stating, using normative language, what is required to comply with this BCP. Section 2: Problem Statement Though this section gives a general overview of the types of problems encountered, I think it might be useful to give each problem a name, a short description, and then an illustrative example. As I see it, for signaling, the problems are: * Responses do not re-use the NAT mapping and filtering entries created by the request * Inbound requests are filtered out by the NAT because there is no long-term connection between the client and the proxy. * NAT bindings will time out unless kept alive by traffic flowing in the appropriate direction. and for media, the problems are: * Each endpoint has a variety of addresses. In different situations, a different pair of (local endpoint, remote endpoint) addresses should be used, and it is not clear when to use which pair. * Many NATs filter inbound packets if the local endpoint has not recently sent an outbound packet to the sender [same problem as second one under signaling] * Classic RTCP usage is to run RTCP on the next highest port. However, NATs do not necessarily preserve port adjacency. * Classic RTP and RTCP usage is to use different 5-tuples for traffic in each direction. Though not really a problem, doing this through NATs is more work than using the same 5-tuple in both directions. * NAT bindings will time out unless kept alive by traffic flowing in the appropriate direction. [Same problem as third under signaling] In particular, I think that the description of the media problems could be improved. Also: s/number seconds/number of seconds/ Section 3.1.1 (Symmetric Response) and 3.1.2 (Re-use of Connections) The general comments about describing the problem vs. the solution etc apply here. Section 3.2 (Media Traversal) "This document has already provided guidelines that recommend using extensions to the core SIP protocol to enable traversal of NATs. While ultimately not desirable, the additions are relatively straight forward and provide a simple, universal solution for varying types of NAT deployment." What is ultimately not desirable? The wording suggests that it is these guidelines, but I think you might mean NATs. Also: in the first sentence, you use the word "guidelines" and in the second you use "additions". I suggest removing this whole paragraph as it is not really adding anything. Section 3.2.1 (Symmetric RTP/RTCP) Unfortunately, I feel this section does not give a very good description of the actual problem. [As an aside, I will note that it also makes it seem more important than it actually is, since ICE could support non-symmetric RTP and RTCP; it would just requires more work.] I suggest describing the problem in section 2, and just specify the requirements on the endpoints here, e.g, "endpoints MUST comply with RFC 4961" or whatever. Section 3.2.1.1 (RTCP) I don't understand why this is a subsection of 3.2.1, since it describes a different problem; namely, that most NATs do not preserve port adjacency. I also feel the document must be clearer on what an endpoint must do: can an endpoint do either RFC 3605 or ietf-avt-rtp- and-rtcp-mux?? In particular, having not read the latter, are they compatible with each other? Sections 3.2.2 (STUN), 3.2.3 (TURN), and 3.2.4 (ICE) In my opinion, the document organization here is suggesting that STUN, TURN, and ICE are separately solving different parts of the media traversal problem. However, in reality they are a single integrated solution that solve the first two of the four media traversal problems I listed above. I suggest having just one section, clearly indicating which problems ICE/STUN/TURN solve, clearly indicating that ICE/STUN/TURN are a suite of 3 inter-related protocols, and clearly indicate what an endpoint must do in this area to comply with this BCP. Section 3.2.5 (Solution Profiles) For each profile, I suggest giving a bulleted list of which specification must be supported. Section 4.1.1.1. UDP as defined in [I-D.ietf-sip-outbound]. The connection tuple creation is clearly shown in Figure 5. This ensures that any inbound request that causes a registration lookup will result in the re-use of the connection path established by the registration. This exonerates the need to manipulate contact header URI's to represent a globally routable address as perceived on the public side of a NAT. The s/Figure 5/Figure 6/ "any inbound request that causes a registration lookup" -- should "that causes" actually be "caused by" ?? "This exonerates the need ..." -- though I understand what you mean, I think many readers would not, and I think you could easily just remove this sentence. Section 4.1.1.2. Reliable Transport Since the diagram is the same as the previous section, you could perhaps merge these two sections together and just show the TCP version of the register request. More generally, the document always presents the unreliable and reliable transport cases separately, but perhaps they should always be combined because they are not that different, and the document should just describe the differences in one place. Section 4.1.2. Registration(Registrar/Proxy not Co-Located) The proxy will create the connection tuple as described in SIP Outbound at the same moment as the co-located example, but for subsequent messages to arrive at the Proxy, the element needs to request to remain in the SIP signaling path. To achieve this the proxy inserts to REGISTER message (5) a SIP PATH extension header, as defined in RFC 3327 [RFC3327]. The previously created flow association token is It is not clear to me what you are trying to say here. By "subsequent messages" do you mean subsequent messages in the REGISTER transaction, or in other transactions? I think what you are saying is that the proxy always needs to be in the path for all messages to/from the client. It also sounds like there might be another problem being solved here that should be described in section 2. Also: "the proxy inserts to REGISTER message" -- s/to/into the/ Section 4.1.4.1. Registrar/Proxy Co-located It is a standard SIP INVITE request with no additional functionality. The major difference being that this request will not follow the address specified in the Request-URI, as standard SIP rules would enforce but will be sent on the flow associated with the registration binding (look-up procedures in RFC 3263 [RFC3263] are overridden). This then allows the original connection/mapping from the initial registration process to be re-used. If I understand things correctly, it is Outbound that is overriding the standard SIP rules. I suggest rewording the paragraph to say that the rules of Outbound are being followed, and noting that this updates the standard SIP rules. Section 4.1.4.2. Registrar/Proxy Not Co-located Same comment as above. Section 4.2.1.1. STUN Solution As previously described, there are lots of known problems with this approach, and there is no longer any document that formally describes it (once RFC 3489 is made obsolete by draft-ietf-behave-rfc3489bis). Because of this, I did not review the text and figures in this section. (After this point in the document, I stopped reading for presentation errors, since I found a number of technical errors in the examples which seemed to me to require significant changes in the text.)