[Int-area] AD evaluation: draft-ietf-intarea-nat-reveal-analysis

[Brian Haberman <[e-mail]>]

All,
      I have completed my AD evaluation for the above draft and have 
some feedback for the group.  I will focus on the substantive comments 
for the time being since some of them may result in re-written text in 
places.  I will follow up with the document authors on editorial nits 
and such at a later time.

1. It is obvious from the way certain sections of text are written that 
the original intent was to make a recommendation on which of the 
described approaches should be used to disambiguate between multiple 
hosts behind a NAT/CGN.  Given that the document is now simply a 
characterization of those mechanisms, I would suggest spending some time 
cleaning up the Abstract, Section 1.1, and Section 2 so that they focus 
on the task of describing the mechanisms, rather than mentioning 
abstract requirements for those mechanisms. There are concrete 
suggestions a little later in this note.

2. The mechanisms described in this draft fall into two broad 
categories, deployed and proposed. Those in the former category can be 
characterized based on actual usage scenarios, which would benefit the 
table shown in Figure 3. The latter should be described in terms of what 
they are proposed to do, but cannot be assessed against the same metrics 
as the other groups.

3. The "Requirements Language" section should be removed.  As an 
Informational document describing mechanisms, there is no need to 
leverage 2119 keywords.

4. It would be useful if the third paragraph of Section 1.1 was expanded 
to discuss the risks in more detail.  In fact, it may be clearer to 
understand this draft if the problem statement came before the context 
(Section 2).

5. Section 2

* The Observation text should provide some brief examples of how and why 
special treatment is needed/provided.  Is it sufficient to identify the 
sending host? application? user? It should also note that there may be 
issues with the fact that some IP addresses will be shared and others 
may not.  How does that impact the performance of these mechanisms?

* I would like some text in the Objective text to explain why such 
sorting is needed.  This relates back to the Context description in 
Section 1.1.

* I don't think there needs to be a description of a Requirement in this 
document any more, so that text can be removed.

6. Section 3.1 should be removed.  This is simply an analysis of the 
mechanisms, so there is no new work which needs requirements defined at 
this point.

7. In Section 4.1.2, it would be good to describe any issues that the 
approach has with the original use of the Identification field for 
fragmentation reassembly.  If a middlebox changes the ID field, weird 
things can/will happen if those packets are fragmented somewhere.

8. I don't see a need for a forward reference in Section 4.2.2. I would 
suggest simply stating that the IP Option approach will support any/all 
transport protocols.

9. In Section 4.3.2...

* I would like to see some description of what risk(s) may arise with a 
TCP option, even though they are apparently low probability.

* Additionally, the text contains "0,103%", which I assume should be 
"0.103%" (i.e., 1/10th of 1%).

*The third bullet mentions that having several NATs in the path may 
cause issues for a TCP option.  Isn't this true for other approaches 
discussed in the document?  These should be identified as well.

10. In Section 4.5.1, I would suggest adding some text that describes 
how to interpret Figure 2.

11. Is Section 4.6 theoretical or is there a specific reference that can 
be added for this technique?

12. Section 4.7.2 should clearly state that HIP is an ideal solution for 
this identification problem, even though the document states there is a 
high cost for deployment. I would also like to see some description of 
why HIP does not work if "the address sharing function is required to 
act as a UDP/TCP-HIP relay".

13. Section 4.8.2

* The text says that the ICMP approach is viable for TCP and UDP.  Any 
reason why it may be an issue for other transport protocols (e.g., SCTP 
or RTP)?

* I would also like to see some text describing why the approach is not 
compatible with cascading NATs.

* The last bullet mentions FMC and Open WiFi with no context or 
references.  These should either have references or their mention should 
be removed since they don't add much to the description.  The same goes 
for their mention in Section 4.9.2 (8th bullet).

14. In Section 4.9.2 (3rd bullet), is the solution to publish this info 
in DNS or is that just an example approach?  This should be clarified.

15. Section 5

* Shouldn't there be an additional metric that covers the impact/cost of 
needing client or middlebox code changes?

* Where did the 100% success ratio for IP-ID come from?  There have been 
documented cases of OSes setting the Identification field to zero.  If 
that is true, the success ratio can't be 100% can it?

* Given the goal of this document to describe these identification 
mechanisms, I don't see the need for the last bulleted list.

Regards,
Brian