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

[Philip Matthews <[e-mail]>]

[I originally CC'ed this to the SIPPING list by mistake.
My apologies to those who see it twice.]
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.