Subject: [Sipping] Review: draft-ietf-sipping-nat-scenarios-08

From: Ari Keränen <[email-masked]>
Date: Mon, 12 May 2008 14:54:44 +0300

Hi,

Here's my review of the draft. Overall, I think it's a nice and useful 
document. Many of the comments are just nits but I suppose they're also 
welcome at WGLC stage. The indented text is from the draft, non-indented 
are my comments.

Section 1.
    large number of potential deployment scenarios.  Detail of different
s/Detail/Details/

Throughout the text you seem to be using ("traversal of", "getting
signaling across", etc.) "NAT" and "NATs" interchangeably -- sometimes
even in the very same sentence. I'd always use the latter one in this
context (e.g., "traversal of NATs" instead of "traversal of NAT").

2. (very end)
    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.
What "single approach" you mean here?

3.1.2.
    The second problem with sip signaling, as defined in Section 2 and
s/sip/SIP/

    Guidelines for devices such as User Agents that can only generate
    outbound connections through a NAT are documented in 'SIP Conventions
    for UAs with Outbound Only Connections'[I-D.ietf-sip-outbound].
That draft is actually called "Managing Client Initiated Connections in
the Session Initiation Protocol". Also, at least I would use a space
between the reference and the text (they're quite often stuck together).

    keep NAT bindings alive.  This is achieved by multiplexing a relative
    ping/pong mechanism over the SIP signaling connection (STUN for UDP
    and CRLF/operating system keepalive for reliable transports like
What do you mean by a "relative" mechanism?

3.2.
    forward and provide a simple, universal solution for varying types of
    NAT deployment.
s/deployment/deployments/

3.2.1
    used.  This involves an SIP endpoint both sending and receiving RTP/
s/an/a/

This section also contains unnecessary repetition. I would change the part

    overcome this problem, a technique called 'Symmetric' RTP/RTCP can be
    used.  This involves an SIP endpoint both sending and receiving RTP/
    RTCP traffic from the same IP Address/Port combination.  This
    technique is known as 'Symmetric RTP/RTCP' and is documented in RFC
    4961 [RFC4961].  'Symmetric RTP/RTCP' SHOULD only solely be used for
    traversal of RTP through NAT when one of the participants in a media
    session definitively knows that it is on the public network.

to something like

    overcome this problem, a technique called 'Symmetric RTP/RTCP'
[RFC4961] can be used.  This involves a SIP endpoint both sending and
receiving RTP/RTCP traffic from the same IP address/port combination.
'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.

3.2.1.1.
    Normal practice when selecting a port for defining Real Time Control
    Protocol(RTCP) [RFC3550] is for consecutive order numbering (i.e
Put a space between "Protocol" and "(RTCP)"

3.2.2.
    Simple Traversal of Underneath Network Address Translators(NAT) or
You're using the old name of the draft here. It should be "Session
Traversal Utilities for NAT".

Also, I think some parts of this section should be rephrased. IMHO, what
STUN does is described in an unnecessarily complex way. For example,
instead of "[STUN] provides details of the external IP address/port
combination used by the NAT device to represent the internal entity on
the public facing side of a NAT" one could say something like "[STUN]
enables a host behind a NAT to discover the address and port that the
NAT allocated for it".

3.2.3.
    'Obtaining Relay Addresses from Simple Traversal of UDP Through NAT
    (known as TURN)' is a usage of the STUN protocol for deriving (from a
    STUN server) an address that will be used to relay packet towards a
    client.
The TURN usage is nowadays called "Traversal Using Relays around NAT".
Also, you should talk about a TURN (not STUN) server in this section.
Also: s/packet/packets/.
And also, TURN server will relay the packets to the other direction too,
not just "towards a client".

    STUN server that will act as a media relay which guarantees traffic
    will reach the associated internal address.  The full details of the
"guarantees traffic will reach" is quite strong wording here. Relay does
relay the packets but does not guarantee reachability by any means (AFAIK).

    it is RECOMMENDED that this method only be used as a last resort and
add a "would" between "method" and "only"?

3.2.4.
    appropriate.  ICE is a methodology for using existing technologies
    such as STUN, TURN and any other UNSAF[RFC3424] compliant protocol to
What "any other UNSAF" protocols are you referring to here? ICE can also
use, e.g., VPN addresses and, AFAIK, they're not "UNSAF compliant".

    technologies such as STUN/TURN etc.  Once the addresses are
No need for the "etc" here since you already use "such as", right?

    has detailed connection information including a media addresses,
    priority, transport.
s/addresses/address/
s/, transport/and transport protocol/

    are used in the correct order depending on the specified priority.  A
    client compliant to the ICE specification will then locally run
    instances of STUN servers on all addresses being advertised using
The "correct order" wording is a bit strange here; better would be
something like "ordered by their priorities". And the "[multiple]
instances of STUN servers" gives, IMHO, a wrong impression:
normally there's just a single process, the ICE thing, that happens to
be listening to many ports for STUN traffic. Same issue is repeated at
least in the bullets after the Figure 10.

3.2.5.2.
    an Address Dependant or Address and Port Dependant NAT, although it
Instead of "dependant", I would use "dependent" since that's the form
used in, e.g., RFC4787. Also, you're mixing the old terminology
(symmetric NAT) with the new one. Maybe it's better to use only the new
terminology?

4.2.1.1.1.

        |<-----------------|                  |                  |
        |Src=STUN-PUB      |                  |                  |
        |Dest=L-PRIV-1     |                  |                  |
        |XOR=NAT-PUB-1     |                  |                  |
s/XOR/Map/

4.2.1.2.1.

    L               NAT             STUN              NAT               R
                                    Server
s/STUN/TURN/

    |                |(2) Alloc Req   |                |                |
    |                |Src=L-NAT-PUB-1 |                |                |
    |                |Des=STUN-PUB-1  |                |                |
s/Des/Dest/

    |(5) STUN Req    |                |                |                |
s/STUN/Alloc/

    |===================================================================|
    |>>>>>>>>>>>>>>>>>>>>>Outgoing RTP sent from >>>>>>>>>>>>>>>>>>>>>>>|
    |===================================================================|
s/from/from L-PRIV-1/
(also for RTCP)

    |===================================================================|
    |<<<<<<<<<<<<<<<<<<<<<Outgoing RTP sent from <<<<<<<<<<<<<<<<<<<<<<<|
    |===================================================================|
s/from/from R-PRIV-1/
(also for RTCP)

Also: s/STUN-PUB/TURN-PUB/g

       starts a local STUN client.  The STUN client generates a standard
       Allocate request as indicated in (1) from Figure 9 which also
You may want to change "standard Allocate request" to a "TURN Allocate
request", since I suppose that's the one you mean here?

I also find the term "highlighting an address" in this context a bit
strange, but then again, I'm not a native English speaker, so it could
be just me. For example in:
       Allocate request as indicated in (1) from Figure 9 which also
       highlights the source address and port combination for which the
       client device wishes to obtain a mapping.

    o  The STUN server receives the Allocate request and processes
       appropriately
s/processes/processes it/
s/STUN/TURN/

       check.  Client 'L' is now free to steam media to the candidate
       pair.  Client 'R' also carries out the same set of binding
s/steam/stream/
Also, at least I would use something like "send media to the peer using
the candidate pair" instead of "streaming media to the candidate pair".

4.2.2.3.
    information as presented in the SDP offer.  The request arrives at
    client L's Port/Address dependent NAT and fails to traverse as there
    is no security association.  This would then move the connectivity
s/security association/NAT binding/

Cheers,
Ari
_______________________________________________
Sipping mailing list  https://www.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

---

From: Colin Perkins <[email-masked]>
Date: Tue, 13 May 2008 08:18:55 +0100

On 12 May 2008, at 12:54, Ari Keränen wrote:
...
> Put a space between "Protocol" and "(RTCP)"

The correct expansion of RTCP is "RTP Control Protocol".

Colin