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

Salvatore Loreto <salvatore.loreto@ericsson.com> Sun, 31 March 2013 11:29 UTC

Return-Path: <salvatore.loreto@ericsson.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 46D0521F86DC; Sun, 31 Mar 2013 04:29:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.248
X-Spam-Status: No, score=-106.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 4yd0TM2JsML8; Sun, 31 Mar 2013 04:29:23 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se []) by ietfa.amsl.com (Postfix) with ESMTP id AE28221F862B; Sun, 31 Mar 2013 04:29:22 -0700 (PDT)
X-AuditID: c1b4fb25-b7f366d000004d10-e6-51581e10ee24
Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain []) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id C4.05.19728.01E18515; Sun, 31 Mar 2013 13:29:21 +0200 (CEST)
Received: from mail.lmf.ericsson.se ( by esessmw0256.eemea.ericsson.se ( with Microsoft SMTP Server id; Sun, 31 Mar 2013 13:29:21 +0200
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se []) by mail.lmf.ericsson.se (Postfix) with ESMTP id 7B55A2508; Sun, 31 Mar 2013 14:29:20 +0300 (EEST)
Received: from nomadiclab.lmf.ericsson.se (localhost []) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id C7AF2548D8; Sun, 31 Mar 2013 14:29:17 +0300 (EEST)
Received: from Salvatore-Loretos-MacBook-Pro.local (localhost []) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 26DC653147; Sun, 31 Mar 2013 14:29:13 +0300 (EEST)
Message-ID: <51581E0A.1000602@ericsson.com>
Date: Sun, 31 Mar 2013 13:29:14 +0200
From: Salvatore Loreto <salvatore.loreto@ericsson.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: The IESG <iesg@ietf.org>, draft-ietf-intarea-nat-reveal-analysis@tools.ietf.org
Content-Type: multipart/alternative; boundary="------------060602000207050608020103"
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrFLMWRmVeSWpSXmKPExsUyM+Jvra6gXESgQdsGNovVL1ewWRx8/I7F YsaficwOzB5Llvxk8vhy+TNbAFMUl01Kak5mWWqRvl0CV8bd4xNZCq55V5zYe4y1gfGQZRcj B4eEgInEzoNxXYycQKaYxIV769m6GLk4hAROMUo0/J/KCpIQEtjAKHFxFyNEYjejxIJp25gh nHWMEvNfP2aFcLYzSry5eZkdpIVXQFviZNtZZpAVLAKqEmc3OoCE2QTMJJ4/3MIMYosKJEtc /f+JBaJcUOLkzCdgtohAmMSMO+fANjMLGEu8+PyaEcQWFnCS2LV2PiNEPEziZsM5Noiz1SSu ntvEDHGplkTv2U6mCYxCs5CMnYWkBcK2lbgw5zpUXF5i+9s5zBC2rsSF/1NQxBcwsq1iZM9N zMxJLzfaxAgM/4NbfqvuYLxzTuQQozQHi5I4b7jrhQAhgfTEktTs1NSC1KL4otKc1OJDjEwc nFINjJl273tevS74Znru0hwuEeFY3ucbGjKeL9JiehnQoxQbtSBqXVdnoqcE778vK7Mmqa28 sMb79qpzZ1fan3izbK7K2l1qDC/vhy6eH2V90c117UKvdwsCvX/9ODHv9o57l/Ovuq+al9HI v052g6JwtrZhgKrA57pDykXbpSTTTQLYxRmqftSF+yixFGckGmoxFxUnAgAS5763TQIAAA==
Cc: "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Subject: [apps-discuss] APPSDIR review: draft-ietf-intarea-nat-reveal-analysis-06
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 31 Mar 2013 11:29:26 -0000

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

- 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 Loreto, PhD