Subject: [apps-discuss] APPSDIR review: draft-ietf-intarea-nat-reveal-analysis-06

From: Salvatore Loreto <[email-masked]>
Date: Sun, 31 Mar 2013 13:29:14 +0200

I have been selected as the Applications Area Directorate reviewer for
this draft (for background on appsdir, please see
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ). 

Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-intarea-nat-reveal-analysis-06
Title: Analysis of Solution Candidates to Reveal a Host Identifier 
(HOST_ID) in Shared Address Deployments
Reviewer: Salvatore Loreto
Review Date: March-31-2013
IETF Last Call Date:
IESG Telechat Date: placed on agenda for telechat - 2013-04-11

Summary: This draft is ready for publication as Informational.
It is a useful collection of solutions to reveal a host identifier 
(denoted as HOST_ID) when a Carrier Grade NAT (CGN)
or application proxies are involved in the path.
Few minor issues needs to be addressed in order to clarify and/or make 
more consistent the information provided by
the draft.

Major Issues: 0
Minor Issues: 5
Nits: 0

Minor:
-----
- Section 2. On HOST_ID

the following paragraph talks about TCP but does not say anything about 
the other transport protocols,
especially UDP that is the most common transport protocol used by NATs:

    If the HOST_ID is conveyed at the IP level, all packets will have to
    bear the identifier.
    If it is conveyed at a higher connection- oriented level, the
    identifier is only needed once in the session establishment phase
    (for instance TCP three-way-handshake), then, all packets received
    in this session will be attributed to the HOST_ID
    designated during the session opening.

- Information consistency among the different listed solutions:

    The Analysis subsections of the different solutions listed in the
    Section "4. Detailed Solutions Analysis"
    does not contain the same information, for example someone
    explicitly state
    "This proposal can apply to any transport protocol." while others
    don't say anything about that
    (of course that is true for the solution at IP field level, if an
    option is for a specific transport protocol that is
    an implicit info)
    To be useful a comparison the section should list a set of
    comparable information (even if they are summarized in the table
    in Section 5), and among those
    - if a solution can be applied to any transport protocol or not is a
    relevant one
    - how a solution would be advertised (e.g. out of band using a
    special DNS record) and why this would be the best way to adv.

- Section 4.4. Inject Application Protocol Message Headers

    about the possibility insert the info in a 'subset' of application
    protocols (e.g., HTTP) the section describes exclusively the HTTP
    however it does talk about how the possibility to insert the HOST_ID
    info in an HTTP header would interwork with the possibility
    for HTTP to set the "Do Not Track" option.
    The analysis subsection should discuss this aspect and provide some
    guidance and/or conclusion about.

- Section 4.5. PROXY Protocol

    the section should be clarified explaining that it is referring to
    TCP proxies that can or can not be combined/bundled to HTTP proxies.
    Moreover it is not completely clear that the solution only works if
    both the ends are aware of the presence of such proxy in between.

- Section 5. Solutions Analysis: Synthesis

    - Table 1 should include a row indicating the advertisement
    mechanism required if any

    - The row "Success Ratio" is quite cryptic as it does not explain
    how the Ratio is calculated, neither this information is present in the
    different sub-sections analysis listed in Section 4 where I would
    suggest to add those explanations.

best regards
Salvatore

-- 
Salvatore Loreto, PhD
www.sloreto.com