Subject: [Sipping] review of draft-ietf-sipping-nat-scenarios-09

From: "Dan Wing" <[email-masked]>
Date: Thu, 12 Feb 2009 15:17:09 -0800

This document is an impressive tour de force of how NAT works with SIP and
with media.  

The IPv6 scenario in Section 6 needs updating to include TURNv6 or a
discussion of why TURNv6 is not the BCP; we may want to remove the NAT64 that
is in the current Section 6, but I'm not sure.  

Other than than, I didn't find anything earth-shattering but several of my
suggested changes will resolve internal inconsistencies in the document, and
correct what I believe are technical errors.

-d

-----

Section 1,

   The IETF has been active on many specifications for the traversal of
   NATs, including STUN[I-D.ietf-behave-rfc3489bis],
   ICE[I-D.ietf-mmusic-ice], symmetric response[RFC3581], symmetric
   RTP[RFC4961], TURN[I-D.ietf-behave-turn], SIP
   Outbound[I-D.ietf-sip-outbound], SDP attribute for RTCP[RFC3605], and
   others. 

Consider adding draft-ietf-avt-rtp-and-rtcp-mux to that list (it is
already mentioned later in the document).

   The best practices described in this document are for traditional
   "client- server"-style SIP.  It seems likely that other groups using
   SIP, for example 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.

To many non-SIP people, SIP is already a peer-to-peer protocol 
(because it started out that way).  I don't have a suggestion to
improve the paragraph, but some further discussion about how SIP
is really client/server where UAs talk to their own proxies and
not directly to other SIP UAs (thus making it client/server) seems
worth a sentence.  

Also if there is a citation for P2PSIP, that would be useful; as is,
I expect in 5-6 years someone reading this won't know what "P2PSIP"
meant.

Section 3,

   This document assumes NATs that do not contain SIP-
   aware Application Layer Gateways (ALG).  Some NATs that are available
   today contain such behavior that which makes much of the issues
   discussed in the document not applicable.

The 'such behavior' phrase in second sentence is vague; how about
just tightening that up to:

   This document assumes NATs that do not contain SIP-
   aware Application Layer Gateways (ALG), which makes much of 
   the issues discussed in the document not applicable.

Which begs the question:  why not just promote ALGs instead of 
this 61 page document?  A discussion of the drawbacks of ALGs
might be valuable here.

Section 3,

   In Figure 2 the original REGISTER request is sent from the client on
   port 8023 and received on port 5060, establishing a connection and
                         ^
                  insert "by the proxy"
   opening a pin-hole in the NAT. 

Section 3,

Figure 3 should show a proxy between the two Clients, so that it is
clear how their SIP signaling is established.  This can be done 
by replacing "->---<-" with ">Proxy<".

Section 3,

   The connection addresses of the clients behind the NATs will
   nominally contain a private IPv4 or IPv6 address that is not routable
                                    ^^^^^^^
                                delete "or IPv6" 
   across the public Internet.

Section 3,

   In general the problems associated with NAT traversal can be
   categorized as follows.
   ...
   For media:
   o  Each endpoint has a variety of addresses.
                                              ^
                                              ^
             add "addresses that can be used to reach it (e.g., native
               interface address, public NATted address)."

   o  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].
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^

It isn't quite the same problem; the second problem under signaling -- we
could imagine a long-term connection between a UA and its proxy, but we cannot
imagine a long-term connection between a UA and *all* potential peers on the
Internet.  I would simply remove the bracketed sentence.

Section 4,

Overall, I think it would be useful for all solutions in Section 4 to indicate
if they can be implemented by only the SIP UA initiating the request, only the
proxy, or need to be implemented by both UAs.

The text reads:

   As mentioned previously, the traversal of SIP through existing NATs
   can be divided into two discrete problem areas: getting the core
                                                               ^^^^
                                            replace "core" with "SIP"
   signaling across NATs,

Section 4.1.1,

The first paragraph of 4.1.1 seems to re-state the problem which seems
unnecessary as we have a separate problem section (Section 3) and solution
section (Section 4).  The text does not describe the solution depicted in
Figure 4, but the last two sentences of the paragraph describe the solution
depicted in Figure 4:

   This
   results in the pin-hole opened for the requests traversal of the NAT
   being reused, in a similar manner to that of reliable connection
   orientated transport protocols such as TCP.  Figure 4 illustrates the
   response traversal through the open pin hole using this method.

I think there was a cut-and-paste error?  The quick summarizing of the
problem, as done in the first paragraph of Section 4.1.2, seems adequate and
correct.

Section 4.1.1,

Figure 4 shows Client A talking to Client B.  I would call this "peer to peer
SIP" rather than "Client/Server SIP".  I suggest changing the right-hand side
thing to a SIP proxy.

Section 4.1.1,

   Even if the SIP Outbound draft is not used, clients generating SIP
   requests SHOULD use the same IP address and port (i.e., socket) for
   both transmission and receipt of SIP messages.  Doing so allows for
   the vast majority of industry provided solutions to properly
   function.  Deployments should also consider the mechanism described
           ^
           ^
        insert "(e.g., SBC hosted NAT traversal)"
   in the Connection Reuse[I-D.ietf-sip-connect-reuse] specification for
   routing bi-directional messages securely between trusted SIP Proxy
   servers.

Section 4.2.1,

   'Symmetric RTP/RTCP' SHOULD only be used for traversal
   of RTP through NATs when one of the participants in a media session
   definitively knows that it is on the public network and is using a
   'latching' technique as described in
   [I-D.ietf-mmusic-media-path-middleboxes]. Symmetric RTP/RTCP is
   important for everything that might want to traverse a NAT or speak
   with an endpoint that is behind a NAT - even if the remote endpoint
   is an SBC performing 'hosted NAT traversal'.

My interpretation of that sentence is that symmetric RTP/RTCP should
*not* be used in other cases (e.g., when using ICE).  I don't believe
that was intended.  Flip the sentence around and the intended meaning
is clear:

  When operating behind a NAT and using the 'latching' technique
  described in [I-D.ietf-mmusic-media-path-middleboxes], SIP user
  agents SHOULD implement 'Symmetric RTP/RTCP'.  This allows traversal
  of RTP across the NAT.

I would delete the last sentence of the paragraph (the one starting
with "Symmetric RTP/RTCP is important ...".)

Section 4.2.2,

   This
   assumption causes RTCP traffic to break when traversing certain types
   of NATs due to blocked ports.
                  ^^^^^^^^^^^^^
               replace with "various reasons (e.g., already-allocated 
                             port, randomized port allocation)."

Section 4.2.2,

   The use of RFC 3605 [RFC3605] MUST be supported.  

I don't think this is a MUST, if the SBC is doing 'latching' and provides
RTP+1 port for RTCP.  There are other exceptions in this BCP for SBCs that
allow softening, so we should remove them all (and be silent on it) or align
them all to talk about SBC operation explicitly.

   An alternative
   mechanism defined in [I-D.ietf-avt-rtp-and-rtcp-mux] specifies
   'muxing' both RTP and RTCP on the same IP/PORT combination.  Using
   this technique eliminates the problem but is still immature.

I don't understand how RTP/RTCP multiplexing 'eliminates the problem' -- both
SIP UAs have to support RTP/RTCP (a=rtcp-mux).  RTP/RTCP might have been
immature when the 'still immature' clause was written but it's in RFC editor's
queue now and several I-Ds are referenced which have not progressed that far.
I also wouldn't quite consider RTP/RTCP multiplexing an 'alternative' to
RFC3605 -- rather words like 'further enhancement' or 'an additional
optimization is available with [rtcp-mux]'.  At least it isn't an
'alternative' until there are a lot of implementations of rtcp-mux.  For quite
awhile we will need both (as RFC3605 is what is deployed today).  Fortunately,
there is good backwards compatibility with RFC3605 and RTP/RTCP multiplexing.

Section 4.2.3.1,

   The IP address/port
   combination deduced for the STUN server would be blocked for incoming
   packets from an alterative SIP entity.
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   too vague.  Suggest replacing with "RTP packets from the 
                                       remote SIP user agent."

Section 4.2.3.2,

   TURN provides an external address
   (globally routable) at a STUN server that will act as a media relay
                            ^^^^
                            TURN
   which attempts to allow traffic to reach the associated internal
   address. 

(I think we decided to just stick with "TURN server" for a TURN server, rather
than "A STUN server following the TURN usage".)

Section 4.2.3.3,

   Interactive Connectivity Establishment (ICE) is the RECOMMENDED
   method for traversal of existing NATs if Symmetric RTP is not
   appropriate.
   ^^^^^^^^^^^
   replace with "sufficient (e.g., there isn't an SBC 
   performing 'latching')."

Section 4.2.3.3,

   (*note - an ICE endpoint can also use
   non-IETF mechanisms (e.g., NAT-PMP, UPnP IGD) to learn public IP
   ^^^^^^^^
   replace "non-IETF" with "other".  (NAT-PMP is arguably an "IETF 
   mechanism", even though it is an individual I-D.)

Section 5.1.1.2,

It could just be me, but I'm confused when the section is titled
"Connection Oriented Transport" and then goes to discuss "reliable
transport".  The advent of DCCP, which is connection oriented but
unreliable makes me wonder "but what of DCCP".  Of course, we all
know that DCCP does not enjoy much support in NATs today so it
is probably reasonable to declare it out of scope for this document
but it makes me wonder if we should be more clear and just say
"UDP" (rather than "unreliable") in the entire document and
"TCP" (rather than "reliable" or "connection-oriented" or
"reliable, connection-oriented" -- all three seem to be used).  

Section 5.1.2,

In Figure 7, I believe the 'outbound connection tuple' is 
created after the Edge Proxy receives the REGISTER?  As
currently depicted, it appears that the tuple is remembered
only after the REGISTER message is received at the Registrar.

Section 5.1.3.1,

"funcationality" -> "functionality"

Section 5.1.4.1,

   The proxy then examines the request
   URI of the INVITE and compares with its list of 
   current open flows.
           ^^^^^^^^^^

This the first use of the term "open flows".  Media "flows", but this sentence
is talking about signaling.  How about "with its list of connection tuples" or
"its list of bindings", either of which is more congruent with the text in
previous sections.

   Once matched, the proxy checks to see if the
   unique instance identifier (+sip.instance) associated with the
   binding equals the same instance identifier associated with the flow.
                                                               ^^^^^^^^
I suggest "with that connection tuple"

   The request is then dispatched on the appropriate flow.
                                                     ^^^^
                                                  "binding" might be better.

5.2.1,

The section title and body mention "Endpoint Independent NAT".  However,
RFC4787 is more specific and includes 'filtering' or 'mapping'; that is, it
defines "Endpoint independent filtering NAT' and 'endpoint independent mapping
NAT'.  I realize the terms are long and awkward, but if you want to use
something shorter you might consider saying something like "The use of
'Endpoint Independent NAT' in this document [section?] means a NAT that is
both 'Endpoint Independent Filtering NAT' and 'Endpoint Independent Mapping
NAT' per RFC4787's definition", or perhaps use an acronym such as "EIF".  (It
is true that endpoint independent filtering requires endpoint independent
mapping, and that might be another way of keeping the wording shorter).

In the top of 5.2.1, I suggest pointing out there is no reliable test to
determine if you are behind an 'endpoint independent filtering' or 'endpoint
independent mapping' NAT.  Citing draft-ietf-behave-nat-behavior-discovery
would be useful.  Something like:

  At this time there is no reliable test to determine if a host is
  behind an 'endpoint independent filtering' NAT or an 
  'endpoint independent mapping' NAT 
  [I-D.draft-ietf-behave-nat-behavior-discovery], and the sort of
  failure that occurs in this situation is described in Section 
  5.2.2.1.  For this reason, ICE is RECOMMENDED over the mechanism 
  described in this section.

Section 5.2.1.1.1,

   The following example demonstrates media traversal through a NAT with
   'Address-Independent' properties using the STUN 'Binding Discovery'
   usage.

"'Address-Independent' properties" are not defined in this document, nor
in RFC4787.  I *believe* that "Endpoint-Independent Mapping" is what
is wanted here, but I'm not completely sure; please consult RFC4787
for the terminology that you wanted here.

Section 5.2.1.2,

5.2.1.2. ICE Solution

   The preferred solution for media traversal of NAT is using ICE, as
   described in Section 4.2.3.3, regardless of the NAT type.  The
   following examples illustrate the traversal of an 'Endpoint
   Independent' NAT when initiating the session.  The example only
   covers ICE in association with the 'Binding Discovery' and TURN.

I would point out the TURN server provides both STUN functions (to learn your
public mapping) and TURN functions (media relaying).

I would also point out that while the example shows both "L" and "R"
contacting the same TURN server [sic, see my comment regarding 5.2.1.2.1],
this is not necessary for ICE, STUN, or TURN to function; all that is
necessary is that the STUN server and TURN server(s) be in the same addressing
domain -- that is, accessible on the Internet.

5.2.1.2.1, 

This example is for an 'Endpoint independent' NAT, which doesn't utilize the
TURN server.  The signaling shown also does not allocate a port from the TURN
server.  So, I think the device in the middle of Figure 13 is really a plain
old STUN server.

      The client would be free to gather any number of
      external representations using any UNSAF[RFC3424] compliant
      protocol.

That statement is too restrictive; just say "The client can also gather IP
addresses and ports via other mechanisms (e.g., NAT-PMP, UPnP IGD)." or
similar.

Section 5.2.2.2, "TURN Solution"

The term defined in RFC4787 is "Address and Port-Dependent Mapping".
Abbreviating it slightly to use "/" instead of "and" is fine but I would
maintain the same word order (that is, use "Address/Port-Dependent").

   As identified in Section Section 5.2.2.1, STUN provides a useful tool
   for the traversal of the majority of NATs but fails with Port/Address
   Dependent NAT.  The TURN extensions [I-D.ietf-behave-turn] address
   this scenario.  TURN extends STUN to allow a client to request a
   relayed address at the TURN server rather than a reflexive
   representation.  This then introduces a media relay in the path for
   NAT traversal (as described in Section 4.2.3.2).  The following
   example explains how TURN solves the previous failure when using STUN
   to traverse a 'Port/ Address Dependent' type NAT.

It should be noted that TURN works best in conjuncation with ICE. 
Without ICE, all media is relayed through the TURN server.

The figure here, Figure 19, shows a STUN server but should show a TURN server.

Section 5.2.2.3,

   ICE makes use of core STUN, TURN and any other
   UNSAF[RFC3424] compliant protocol to provide a list of prioritized
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   replace with "mechanism (e.g., NAT-PMP, UPnP IGD)"

Section 6,

6. IPv4-IPv6 Transition

   This section describes how IPv6-only SIP user agents can communicate
   with IPv4-only SIP user agents.  While the techniques discussed in
   this draft primarily contain examples of traversing NATs to allow
   communications between hosts in private and public networks, they are
   by no means limited to such scenarios.  The same NAT traversal
   techniques can also be used to establish communication in a
   heterogeneous network environment -- e.g., communication between an
   IPv4 host and an IPv6 host.

Figure 21 shows a "SIP phone" at the top and an "IPv6 SIP UA" at the 
bottom; is there a significance to using different terminology?

The NAT in Figure 21 is "not your father's NAT" -- it translates
from IPv6 to IPv4.  This should be highlighted in the text; this
is I guess a NAT-PT device?  Or the NAT64 device that BEHAVE is
standardizing?  I am surprised the document shows such an 
address family translator as the Best Current Practice.  Afterall, 
we do have IPv4 and IPv6 support in TURN and TURN-v6, and I would 
like to see another scenario where TURN is used to interwork 
between v4 and v6.

**end of dwing's review**