Subject: [Sipping] Pre-WGLC Review of draft-ietf-sipping-nat-scenarios-07

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 04 Sep 2007 10:08:52 -0500

This draft is a great survey paper on NAT traversal techniques.  It
discusses the various traversal techniques for both media and
signaling to provide a complete overview to the reader.  There has
been some concern that we want to make sure that the draft is in the
right direction.  I believe it is.

A couple of  general comments first:

1) S5 talks about IPv4-IPv6 transition.  I would suggest adding a
    sentence at the beginning of the text allowing the reader to
    appreciate that this draft is more than NAT traversal techniques
    in the context of public and private networks (which is what
    the draft's current focus is on.)  Some text that tells the
    reader of other uses can be added at the beginning:

     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.  Example of such a case is depicted in
     Section Section 5.

2) S5.2 discusses ANAT in the context of grouping IPv4 and IPv6
    addresses.  We decided to deprecate ANAT in the Prague IETF.
    So discussions related to ANAT should now reflect ICE instead.

3) Some figure have titles and others don't.  Would suggest
    consistency by providing titles on all figures.

The rest of the comments are in section-order.  First are
the comments on contents of the draft, followed by editorial
comments on the text and nits.

- S2, Figure 1: I would suggest that you renumber the port 5650
       in the figure to something more ephemeral, like 10923, for
       instance.  5650 visually is very close to the default SIP port
       (5060) and it took me a while to appreciate that you had 5650
       written on the right-hand side of the figure and not 5060!

- S2: the discussion around Figure 2 could refer to connect-reuse.
       Especially in the paragraph right under Figure 2 where it says
         "While this problem has been discussed in the context of
         connection-oriented protocols such as TCP, the problem exists
         of SIP signaling using any transport protocols."
       I would suggest adding the following sentence immediately after:
         "The impact of connection reuse of connection oriented
         transports (TCP, TLS, etc.) is discussed in more detail
         in connect-reuse [ref]."

- S2, page 5, first paragraph (under Figure 2), last sentence:
       Section 3 of this document contains many approaches.  Which
       specific one did you have in mind?
       Also, it may be better to reword the sentence to say that "the
       approach" instead of "the solution".  This draft is a BCP draft,
       as such it demonstrates which one of the existing approaches (or
       solutions) is better; it does not propose a new solution.

- S2, page 5, second paragraph, third sentence: it is stated
       that SIP signaling cannot be relied on to keep the NAT bindings
       open for a "number of reasons."  And then, two reasons are
       given.  Are there more?  If not, I would suggest simply
       s/a number of reasons/the following two reasons:/

- S2, page 6, last paragraph of the section: I would suggest
       replacing the entire paragraph with the following text:
        "The connection addresses of the clients behind the NATs will
        nominally contain a private IPv4 or IPv6 address that is not
        routable across the public Internet.  Exacerbating matters
        even more would be the tendency of Client A to send media to
        a destination address it received in the signaling confirmation
        message -- an address that may actually correspond to a host
        within the private network who is suddenly faced with incoming
        RTP packets (likewise, Client B may send media to a host within
        its private network who did not solicit these packets.)  And
        finally, to complicate the problem even further, a number of
        different NAT topologies with different default behaviors
        increases the difficulty of arriving at a single approach."

- S2, third paragraph: UDP expands to "User Datagram Protocol"
      not "Unicast Datagram Protocol"

- S3.1.1, Figure 4: I do not believe that Figure 4 contributes much to
      the text.  One way to make it more relevant would be to take the
      IP addresses and ports of the example in rfc3581 (S6 of that RFC)
      and turn those into Figure 4.

- S3.1.2, last paragraph: If SIP outbound is not being used, people
      should be pointed out to connect-reuse as an alternative at least
      between proxies.  Also, reusing the same TCP connection is not
      recommended by that document, and as such, should not be mentioned
      as a solution by nat-scenarios.

- S3.1.2, Reference [13] points to a very old version of
      outbound (circa 2005]; suggest using the latest version.

- S3.2.1, Reference [15] is now rfc4961, bcp131.  Please update.

- S3.2.1.1, Reference [6] points to rfc3581, not rfc3605, as appears
      to be the intent in line seven of that section.

- S3.2.2, Reference [11] is now rfc4787.

- S3.2.2: Those not familiar with rfc4787 will not have any idea of
      the terms "Endpoint independent mapping" and "Address dependent
      mapping."  As a survey paper (or RFC), nat-scenarios could
      either provide a quick blurb on what these are, or can simply state
      that:
        However, STUN does not work with certain NATs prevelant in the
        marketplace; for more information on the characteristics of such
        NATs, please see RFC4787 [11].

- S3.2.5.1: Reference [6] points to rfc3581, not rfc3605, as appears
      to be the intent in line two of that section.

- S3.2.5.2: Reference [6] points to rfc3581, not rfc3605, as appears
      to be the intent in line two of that section.

- S3.2.5, at the end of that section, I would suggest adding a table
      like this (double-check my rows and columns):

                  | Primary  | Consumer | Minimal |
                  | Profile  | Profile  | Profile |
         ---------+----------+----------+---------+
         ICE      |   Yes    |    No    |   No    |
         ---------+----------+----------+---------+
         STUN     |   Yes    |    Yes   |   No    |
         ---------+----------+----------+---------+
         TURN Use |   Yes    |    No    |   No    |
         ---------+----------+----------+---------+
         RFC3605  |   Yes    |    Yes   |   No    |
         ---------+----------+----------+---------+
         Symm. RTP|   Yes    |    No    |   Yes   |
         (RFC4961)|          |          |         |
         ---------+----------+----------+---------+

- S4.1.1.2, towards the end of the section:
      s/Connection Re-use draft [13]/outbound draft [13]

- S4.1.2, page 17, last sentence of the topmost paragraph:
     s/REGISTER message (5) would look as follows:/The REGISTER
     message of (5), when proxied in (6) looks as follows:/

- S4.1.4.1, page 22: In message (2), shouldn't the R-URI be
     re-written with the address registered earlier?
     Also, there are two "sip" schemes in the R-URI for message
     (2); i.e., "sip:sip:[email-masked]"

- S4.1.4.2 is empty.

- S4.2.1.1.1, on page 27, in the discussion around message flows
     (5)-(8), you may want to explain that the second local address
     requested for STUN is for the RTCP port.

- S4.2.1.1.2, page 30, in the discussion around message flows
     (7)-(10), you may want to explain that the second local address
     requested for STUN is for the RTCP port.

- The next figure after Figure 20 is Figure 22.  There isn't a
    Figure 21 as far as I can see.

- S4.2.1.2.1, Figure 23, page 39: Continuation in the SDP is
    denoted by a new convention -- using the bigram /*.  I have not
    seen this new convention in any SIP-related drafts yet.  Instead
    of using a new convention, maybe we should continue to use the
    existing convention of <allOneLine> markup.  Alternatively, off-hand,
    I do not recall what SDP's ABNF says about line continuation, but
    if it requires a LWS, the continuation character could be a normal
    space.  I lean towards using already established conventions for
    the sake of the reader who may be familiar with these from reading
    previous SIP-related RFCs/I-Ds.

- S4.2.1.2.1, the SDP at the bottom of page 40: two comments on
    this.  First comment echoes the above use of the bigram for
    continuation.  Second comment is that you should consider
    numbering this ICE SDP answer for the sake of consistency since
    the ICE SDP offer was numbered as Figure 23.

- S4.2.1.2.1, page 41, first bullet item: I don't know what is the
    expected depth of understanding of the reader with respect to ICE
    when reading this paragraph.  For instance, once ICE has frozen the
    candidates in L, does the connectivity check proceed in parallel
    or in sequence?  That is, is foundation $L1 tried first, and if
    connectivity checks fail, then foundation $L2 is tried?  Or do
    they proceed in parallel?  Maybe inserting a quick statement right
    after the sentence "At this stage, all .... 'Frozen' state." (at
    about midway down the bullet item.)

    Second comment is more editorial, but I will include it here since
    we are discussing this sub-section anyway: consider adding para-
    graphs for readability.  There is a lot of information in this
    bullet item, so re-organizing this in a few paragraphs would help
    tremendously.

- S4.2.1.2.1, Figure 22, page 34: At about half-way down the page,
    there is a depiction of media flowing from L to R.  However,
    there isn't any noun for the "from" preposition.  I think the
    "from" should be followed by the foundation $L-NAT-PUB-1, but
    please double-check.

    In fact, in the rest of the figure, all of the "from" prepositions
    do not have a noun associated with them.  May want to consider
    putting the right foundation after the "from".

- S4.2.1.2.1, Figures 25 and 26: Same comment as the one in
    "S4.2.1.2.1, Figure 23, page 39" above: Continuation in the SDP is
    denoted by a new convention -- using the bigram /*...

- S4.2.2.1, Figure 27: Since you are using the foundation "L-PRIV-1",
    you may want to consider re-labeling the "Client" vertical line
    with "L".

- S4.2.2.2, first paragraph, page 45: "STUN toolkit" or "STUN
    profile"?

Editorial comments, including nits:
=====================================

- S1, first sentence: s/large/complex/

- S1, second sentence: s/further confused/made worse/
      or "exacerbated" works as well.

- S1, second paragraph, first sentence: You may want to reconsider
      the word "produced"; not all of the protocols mentioned are RFCs
      yet.

- S1, second paragraph, first sentence: You may want to provide a
      reference to each of the protocol you mention.

- S1, third paragraph, first sentence:
      s/attempts to provide/provides

- S1, last paragraph: s/will be split/is split
        or "is organized" works as well.

- S2, first paragraph can be tightened considerably.  Something
       like:
        Normal SIP response routing over UDP causes the response to be
        delivered to source IP address specified in the topmost Via
        header, or the "received" parameter of the topmost Via header.
        The port is extracted ...

- S2, page 5, second paragraph, second sentence:
      s/This period of inactivity can range drastically from/This
      period of inactivity may vary from/

- S2, page 5, second paragraph, third sentence: suggest taking
      the word "Pure" out; doesn't contribute much.

- S2, page 5, last paragraph: s/RTP [2]]/RTP [2]/

- S2, page 6, last paragraph of the section:
      s/are not available/is not available
      alternatively, you can make "address" plural, and then leave it
      as "are not available"

- S3, first two sentences: consider rewording as follows:
        As mentioned previously, the traversal of SIP through existing
        NATs can be divided into two discrete problem areas: getting
        the core signaling across the NAT, and enabling media as
        specified by SDP in a SIP offer/answer exchange to flow between
        endpoints.

- S3.2.1, s/NAT(as illustrated/NAT (as illustrated/

- S3.2.1, towards the end of the section, you have a sentence: "This
      technique is known as 'Symmetric RTP' and is documented in [15]."
      Consider:
       a) Removing that sentence;
       b) Putting reference [15] nine lines above, where you first
        mention 'Symmetric' RTP.

- S3.2.5.2: s/in the unfortunate situation of being//
      (i.e., delete that phrase.)

- S4.1.2, page 17, last paragraph: s/new Registration/new registration

- S4.1.3.1, Figure 8: In reality, you can compress the figure by
     only including the following messages: 3 and 4 and abstract the
     rest using "...".  The discussion that follows the figure focuses
     on the contents of the INV request; the challenge shown in message
     2, and the ringing in message 5 and 6 and everything below that
     is inconsequential.

- S4.2, towards the end of page 23: For the sake of completeness
     it may be good to provide a reference to the ICE specification
     in the sentence "Detailed information on individual ... the
     core ICE specification."

- S4.2.1.1.2, Figure 20: You may want to consider beginning the
    vertical line under the heading "STUN Server" after the horizontal
    line of the SIP INVITE (1).  As the drawing is depicted now, it
    appears that the SIP INVITE request is going through the STUN
    server, which is not the case.

- S4.2.1.2, the partial sentence on top of page 31:
    s/when initiating./when initiating the session./

- S4.2.1.2.1, page 41, first bullet item:
    s/work there way/work their way/

- S4.2.2.2, page 48: The second bullet sign on the page appears to
    be superfluous.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP