[Sipping] Minor and editorial comments on draft-iab-nat-traversal-considerations-00

[Philip Matthews <[e-mail]>]

http://www.ietf.org/internet-drafts/draft-iab-nat-traversal-considerations-00.txt

Jonathan:

Here are some minor and editorial comments on this document.
In a separate e-mail message, I will post my one major comment.

- Philip


MINOR COMMENTS

*) The terminology and discussion in this document is mostly oriented towards
    client-server applications. However, on close reading, it seems that much
    of the discussion is also applicable to peer-to-peer applications.
    (For example, Figure 1 does show a line between clients, so reading "peer"
    for "client" makes it applicable to peer-to-peer work).
    It would be nice if the terminology and discussion could be changed slightly
    to make this wider applicability more obvious.

*) In a number of places, this document uses the term "Service Provider".
    To me the term "Service Provider" in an IETF document is a synonym for
    "Internet Service Provider", and in the context of this draft I automatically
    think of the ISP that is providing a client with access to the Internet.
    However, the document seems to use the term "Service Provider" to mean
    the organization that controls the servers shown in Figure 1.
    I suggest the document just say "the organization controlling the servers"
    and shorten this to "server manager" where necessary.

*) Mostly the document says "the NAT" or "a NAT" to mean a box, but at times
    it says just "NAT" to mean the technology. I suggest the document uses "NAT"
    to mean the box, and "Network Address Translation" to refer to the technology.

*) [Section 3.2] The long discussion of TURN in comparison to the very short
    discussion of STUN and Teredo seems odd and out-of-place. A one-sentence
    description of TURN with a reference would seem more appropriate.

*) [Section 3.3] In the description of an SBC, you may wish to clarify
    that an SBC looks at addresses and ports in the received IP/TCP/UDP header
    rather than the addresses and ports in the SIP message headers.

*) [Section 3.3] The document says "... making the SIP network look more like a
    pure client/server network". Rather than what?
    I believe you mean "... rather than a pure peer-to-peer SIP network".
    If so, I suggest you should either explain why this is interested or important,
    or just drop the entire comment altogether.

*) [Section 3.6] Could you give examples of protocols engineered to traverse NATs?

*) [Section 4.1.1] "... IP addresses or domain names ... are exactly the parts of
    the message that are the most critical to protect."
    I don't agree that these are the most critical to protect in every case.
    For example, if I am worried about protecting my SIP call, personally I would
    first encrypt the media stream, and only then would I try to ensure the media
    stream went to the right place. And similarly with e-mail.
    I suggest you simply delete the words "... the most ...".

*) [Section 4.1.1] You may wish to mention the problem of a message being delivered
    to the wrong host. For example, section 2.4 of draft-ford-behave-app-00 gives
    an example of this, and I suspect that examples of how NATs can misroute packets
    in certain race conditions can also be constructed. These are not really attacks,
    but they have a similar effect.

*) [Section 4.1.1] It would be nice to see a justification for the statements
    in the last paragraph of this section.

*) [Section 4.1.2] I found the discussion in paragraphs 3 onward difficult to
    follow. First of all, it took me a while to understand that the references
    to "... these attacks ..." in various paragraphs are all referring back to
    the attacks documented in RFC 3489. Second, since I had not read this RFC,
    the discussion was very cryptic. To make this document more self-contained,
    I suggest you give a brief summary of these attacks.

*) [Section 4.3] This section talks about the visibility that a service provider
    has into problems. But users and the administrator of the network behind the
    NAT also want visibility into problems! This is especially true for
    peer-to-peer applications, but is also true for client-server applications.
    (I suspect that simply removing references to "service provider" would make
    much of the discussion in this section more general.)


EDITORIAL COMMENTS

*) [Section 1, 3rd PP] "... selection of general technique ...".     Missing "a".

*) [Section 1, 4th PP] "... a matching outbound communications ...".
    Remove the "s".

*) [Section 2, first PP after Figure 1]
    "... is shown in Figure 1 In this model, ...".      Missing ".".

*) [Section 3.1, first PP]
    "RFC ... defines an Application Layer Gateway as ... translation agents ...".
    Singular/plural mismatch.

*) [Section 4.1.1, 1st PP] "... assumes uniquess ...".   Misspelled "uniqueness".

*) [Section 4.1.1, Eavesdropping PP]
    "the attacker can modify ... to point to themselves".
    Singular/plural mismatch.

*) [Section 4.1.1, Service Disruption PP]
    "... this will likely disrupt operation of the protocol, ...".
    Suggest inserting "the" before "operation".

*) [Section 4.1.1, Service Disruption PP] "... the client receives no service.".
    Suggest rewording as "... the client does not receive any service".

*) [Section 4.1.1, 2nd PP on page 10] "... as opposed to in the clients ...".
    Suggest inserting the word "residing" between "to" and "in".

*) [Section 4.1.2, 1st PP]
    "... another class of attacks are possible depending on the
     way in which the traversal technique ...".
    Suggest replacing with
    "... another class of attacks depend on the way the traversal technique ..."

*) [Section 4.4, 3rd PP] "... less brittle. service providers ...".
    Missing initial capital letter.



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