Subject: [RAI] RAI-ART review of draft-ietf-sipping-nat-scenarios-08

From: Philip Matthews <[email-masked]>
Date: Wed, 28 May 2008 14:09:24 -0400

I am the assigned RAI-ART reviewer for draft-ietf-sipping-nat- 
scenarios-08.

For background on RAI-ART, please see the FAQ at <http://www.softarmor.com/rai/art/FAQ.html 
 >.

This review was supposed to be done as part of the SIPPING WGLC on  
this document, which ended on May 23rd. Unfortunately, due to delays  
on my part, I was not able to complete the review until now. Please  
discuss with the working group chairs how to handle these comments.

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

- Philip

_______________________________________________
RAI mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rai

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 29 May 2008 11:30:03 -0500

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

I actually had exactly the same comment in my review.

My preference would be to get rid of the "profile" concept altogether,
i.e. remove section 3.2.5, since itoffers very little value and much confusion.

If we must keep the concept of profiles, then it needs to be expanded to
cover draft-ietf-sip-outbound.

As a side note: you don't need GRUU at all anymore for NAT traversal of
SIP. What you need is the +sip.instance id which is described in SIP
outbound (and yes, GRUU refers back to outbound). But you don't need
support for GRUU per say.

This is one of the many problems that I alluded in section 4.1 which is
now quite out-of-synch with outbound. There are others. For example,
usage of Supported and Required is incorrect. The tokens in the Path header
don't conform to the recomendations in outbound. The Route header usage is
not described properly. Furthermore, there are still remnants of pre-outbound
days in the text (e.g., innapropriate references to rport and connect-reuse).

I am planning to propose the changes to fix this section in a seperate email.

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 29 May 2008 11:40:34 -0500

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Philip Matthews
> Sent: Wednesday, May 28, 2008 11:09
> To: Chris Boulton
> Cc: [email-masked]; [email-masked]
> Subject: [RAI] RAI-ART review of draft-ietf-sipping-nat-scenarios-08
>
> 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, 
> 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.
> 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.

This is actually a very crucial comment. I was actually thinking about it
as well, but my conclusion was that it had been decided by the group to
allow using STUN without using ICE.

If we decide that we will NOT allow or recommend the use of STUN or TURN 
without ICE, then we need to revise the document accordingly, as recommended
by Philip.

At this point, I'm tempted to agree with Philip. I use to be a proponent
of using STUN-without-ICE: it made sense in the days when ICE was still in
its (very long) development, but it probably doesn't anymore.

I believe that this nat-senarios document has not completely caught up with
a number of changes on ICE and sip-outbound. There are a number of references
to historical artifacts that shouldn't be in there. I've pointed out 
ANAT, connect-reuse and rport, some errors in ICE and outbound usage and
terminology. And now there is this bigger issue of using STUN without
ICE.

Is it possible to decide on the list to allow for STUN-without-ICE?
_______________________________________________
RAI mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rai