From wwwrun@rfc-editor.org Fri Feb 8 17:48:26 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69C1A21F8BF8; Fri, 8 Feb 2013 17:48:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.086 X-Spam-Level: X-Spam-Status: No, score=-102.086 tagged_above=-999 required=5 tests=[AWL=-0.086, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3XskYcByhs5y; Fri, 8 Feb 2013 17:48:25 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id DBCFD21F8BBA; Fri, 8 Feb 2013 17:48:25 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 0B0C6B1E004; Fri, 8 Feb 2013 17:48:17 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20130209014817.0B0C6B1E004@rfc-editor.org> Date: Fri, 8 Feb 2013 17:48:17 -0800 (PST) Cc: int-area@ietf.org, rfc-editor@rfc-editor.org Subject: [Int-area] RFC 6864 on Updated Specification of the IPv4 ID Field X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Feb 2013 01:48:26 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6864 Title: Updated Specification of the IPv4 ID Field Author: J. Touch Status: Standards Track Stream: IETF Date: February 2013 Mailbox: touch@isi.edu Pages: 19 Characters: 44418 Updates: RFC791, RFC1122, RFC2003 I-D Tag: draft-ietf-intarea-ipv4-id-update-07.txt URL: http://www.rfc-editor.org/rfc/rfc6864.txt The IPv4 Identification (ID) field enables fragmentation and reassembly and, as currently specified, is required to be unique within the maximum lifetime for all datagrams with a given source address/destination address/protocol tuple. If enforced, this uniqueness requirement would limit all connections to 6.4 Mbps for typical datagram sizes. Because individual connections commonly exceed this speed, it is clear that existing systems violate the current specification. This document updates the specification of the IPv4 ID field in RFCs 791, 1122, and 2003 to more closely reflect current practice and to more closely match IPv6 so that the field's value is defined only when a datagram is actually fragmented. It also discusses the impact of these changes on how datagrams are used. [STANDARDS-TRACK] This document is a product of the Internet Area Working Group Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From brian@innovationslab.net Mon Feb 11 13:11:54 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4303D21F8972 for ; Mon, 11 Feb 2013 13:11:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3i3gL1YXFKsp for ; Mon, 11 Feb 2013 13:11:52 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id ECD3B21F8A80 for ; Mon, 11 Feb 2013 13:11:51 -0800 (PST) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 1E00E88186; Mon, 11 Feb 2013 13:11:50 -0800 (PST) Received: from 102529252.rudm1.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id B9E1F13000C; Mon, 11 Feb 2013 13:11:49 -0800 (PST) Message-ID: <51195E93.4090103@innovationslab.net> Date: Mon, 11 Feb 2013 16:11:47 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: int-area@ietf.org, draft-ietf-intarea-nat-reveal-analysis@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Int-area] AD evaluation: draft-ietf-intarea-nat-reveal-analysis X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 21:11:54 -0000 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 From suresh.krishnan@ericsson.com Mon Feb 11 16:11:21 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E850121F8A66 for ; Mon, 11 Feb 2013 16:11:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.925 X-Spam-Level: X-Spam-Status: No, score=-101.925 tagged_above=-999 required=5 tests=[AWL=0.674, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9d9JXZWmCS4T for ; Mon, 11 Feb 2013 16:11:21 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5883C21F8A61 for ; Mon, 11 Feb 2013 16:11:21 -0800 (PST) X-AuditID: c618062d-b7fcb6d000007ada-d5-511988a88b87 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 15.36.31450.8A889115; Tue, 12 Feb 2013 01:11:20 +0100 (CET) Received: from eusaamw0706.eamcs.ericsson.se (147.117.20.31) by EUSAAHC004.ericsson.se (147.117.188.84) with Microsoft SMTP Server (TLS) id 14.2.318.4; Mon, 11 Feb 2013 19:11:20 -0500 Received: from [142.133.112.63] (147.117.20.214) by smtps-am.internal.ericsson.com (147.117.20.31) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 11 Feb 2013 19:11:19 -0500 Message-ID: <51198814.1060809@ericsson.com> Date: Mon, 11 Feb 2013 19:08:52 -0500 From: Suresh Krishnan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Brian Haberman References: <51195E93.4090103@innovationslab.net> In-Reply-To: <51195E93.4090103@innovationslab.net> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBLMWRmVeSWpSXmKPExsUyuXRPiO6KDslAg1XLFCxm9vxjtDj4+B2L xY1ZN1kcmD2WLPnJ5DHz+BcWjy+XP7MFMEdx2aSk5mSWpRbp2yVwZZw4cJSt4CJXxfM/T5ka GDdzdDFyckgImEj8n7GZFcIWk7hwbz1bFyMXh5DAEUaJx7cb2CGc3YwSh9s3QTlbGSVW/1jI BNLCK6At0dB2CcxmEVCV2HT/MguIzQY0dsPOz2BxUYEwid7X5xgh6gUlTs58AlYjIqAr0dix AsxmFgiSeLuvAaxeWMBXYv2bbrCThAQMJf40/WUGsTkFjCRerjsPVM8BdKq4xJo3HBCtehJT rrYwQtjyEtvfzmGGaNWU2LrmO+sERuFZSDbPQtIyC0nLAkbmVYwcpcWpZbnpRgabGIGhfUyC TXcH456XlocYpTlYlMR5g1wvBAgJpCeWpGanphakFsUXleakFh9iZOLglGpgbCm9crfwboCp vq+x7ILlvx9OnX1UotfJwejrns7un8pnJT4kLFXicTnestHJ++n7W6pHSs7nSYSbl578V7Kc 0fOc1dFXV2avLp0VKnPqBJtQ5uc61mc+nxNW/2AMWBihwnNQWenRjYjJmzK///6drRozi9/t b3s8+2Lh7oWK+gc5l3w4s1JykhJLcUaioRZzUXEiAOl2E1A7AgAA Cc: draft-ietf-intarea-nat-reveal-analysis@tools.ietf.org, int-area@ietf.org Subject: Re: [Int-area] AD evaluation: draft-ietf-intarea-nat-reveal-analysis X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 00:11:22 -0000 Hi Brian, Thanks for the review. I wanted to clarify three points that you raised and I will ask the authors take care of the rest. On 02/11/2013 04:11 PM, Brian Haberman wrote: > 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. Agree. I think this is precisely the reason that the mechanism for putting the HOST_ID in the IP-ID is a non-starter. > 11. Is Section 4.6 theoretical or is there a specific reference that can > be added for this technique? There are several mechanisms that use port sets for IPv4 address sharing. A+P (RFC6346) is one such mechanism. > 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? This technique involves the translator (and not the sender) setting the IP-ID field. That is why it can still work with OSes on senders setting the IP-ID to zero. Thanks Suresh From brian@innovationslab.net Mon Feb 11 16:44:20 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53A9921F8713 for ; Mon, 11 Feb 2013 16:44:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WlAJSseCJPU2 for ; Mon, 11 Feb 2013 16:44:19 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id C4BA821F86FF for ; Mon, 11 Feb 2013 16:44:19 -0800 (PST) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id B5AB18815A; Mon, 11 Feb 2013 16:44:19 -0800 (PST) Received: from clemson.local (c-69-140-213-249.hsd1.md.comcast.net [69.140.213.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 4D07213000C; Mon, 11 Feb 2013 16:44:19 -0800 (PST) Message-ID: <51199062.4080505@innovationslab.net> Date: Mon, 11 Feb 2013 19:44:18 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Suresh Krishnan References: <51195E93.4090103@innovationslab.net> <51198814.1060809@ericsson.com> In-Reply-To: <51198814.1060809@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-intarea-nat-reveal-analysis@tools.ietf.org, int-area@ietf.org Subject: Re: [Int-area] AD evaluation: draft-ietf-intarea-nat-reveal-analysis X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 00:44:20 -0000 Hi Suresh, On 2/11/13 7:08 PM, Suresh Krishnan wrote: > Hi Brian, > Thanks for the review. I wanted to clarify three points that you > raised and I will ask the authors take care of the rest. > > On 02/11/2013 04:11 PM, Brian Haberman wrote: >> 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. > > Agree. I think this is precisely the reason that the mechanism for > putting the HOST_ID in the IP-ID is a non-starter. I agree. But that rationale should be in the draft. > >> 11. Is Section 4.6 theoretical or is there a specific reference that can >> be added for this technique? > > There are several mechanisms that use port sets for IPv4 address > sharing. A+P (RFC6346) is one such mechanism. Then I would ask that a reference be put in to give readers an example. > >> 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? > > This technique involves the translator (and not the sender) setting the > IP-ID field. That is why it can still work with OSes on senders setting > the IP-ID to zero. You still have the issue of the middlebox setting that ID to something that potentially impacts fragmentation reassembly. So, I would still like to know how that 100% success ratio was collected. Regards, Brian From mohamed.boucadair@orange.com Tue Feb 12 02:34:20 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 415EC21F8BDE for ; Tue, 12 Feb 2013 02:34:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.067 X-Spam-Level: X-Spam-Status: No, score=-2.067 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Pu1uz3z+99u for ; Tue, 12 Feb 2013 02:34:19 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id B479921F8BC9 for ; Tue, 12 Feb 2013 02:34:18 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 2B39626498B; Tue, 12 Feb 2013 11:34:17 +0100 (CET) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 03C1C35C065; Tue, 12 Feb 2013 11:34:17 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Tue, 12 Feb 2013 11:34:16 +0100 From: To: Brian Haberman , "int-area@ietf.org" , "draft-ietf-intarea-nat-reveal-analysis@tools.ietf.org" Date: Tue, 12 Feb 2013 11:34:15 +0100 Thread-Topic: [Int-area] AD evaluation: draft-ietf-intarea-nat-reveal-analysis Thread-Index: Ac4InG1wLPHxSSaES8SryKKau3sWtgAU+TtA Message-ID: <94C682931C08B048B7A8645303FDC9F36EAEE11CD9@PUEXCB1B.nanterre.francetelecom.fr> References: <51195E93.4090103@innovationslab.net> In-Reply-To: <51195E93.4090103@innovationslab.net> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.12.31.121227 Subject: Re: [Int-area] AD evaluation: draft-ietf-intarea-nat-reveal-analysis X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 10:34:20 -0000 Dear Brian, Many thanks for the detailed review. Please see inline. Cheers, Med >-----Message d'origine----- >De : int-area-bounces@ietf.org >[mailto:int-area-bounces@ietf.org] De la part de Brian Haberman >Envoy=E9 : lundi 11 f=E9vrier 2013 22:12 >=C0 : int-area@ietf.org; >draft-ietf-intarea-nat-reveal-analysis@tools.ietf.org >Objet : [Int-area] AD evaluation: >draft-ietf-intarea-nat-reveal-analysis > >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. Med: It is true there was a version of the document which includes a recomm= endation but the initial intent of the document was to analyze candidate so= lution. I updated the text to make it explicit: I changed the text in the s= ections you mentioned. In particular, the change in the abstract is: OLD: This document analyzes a set of solution candidates to mitigate some of the issues encountered when address sharing is used. In particular, this document focuses on means to reveal a host identifier (HOST_ID) when a Carrier Grade NAT (CGN) or application proxies are involved in the path. This host identifier must be unique to each host under the same shared IP address. NEW: This document is a 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. This host identifier is used by a remote server to sort out the packets by sending host. The host identifier must be unique to each host under the same shared IP address. This document analyzes a set of solution candidates to reveal a host identifier; no recommendation is sketched in the document. > >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. Med: Figure 3 includes this note: (2) This solution is widely deployed. Can you explicit what change you want to be added? Thanks. > >3. The "Requirements Language" section should be removed. As an >Informational document describing mechanisms, there is no need to >leverage 2119 keywords. Med: Done. > >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). Med: I changed the text as follows: OLD: The sole use of the IPv4 address is not sufficient to uniquely distinguish a host. As a mitigation, it is tempting to investigate means which would help in disclosing an information to be used by the remote server as a means to uniquely disambiguate packets of hosts using the same IPv4 address. NEW: In particular, some servers use the source IPv4 address as an identifier to treat some incoming connections differently. Due to the deployment of CGNs (e.g., NAT44 [RFC3022], NAT64 [RFC6146]), that address will be shared. In particular, when a server receives packets from the same source address, because this address is shared, the server does not know which host is the sending host [RFC6269]. The sole use of the IPv4 address is not sufficient to uniquely distinguish a host. As a mitigation, it is tempting to investigate means which would help in disclosing an information to be used by the remote server as a means to uniquely disambiguate packets of hosts using the same IPv4 address. > >5. Section 2 > >* The Observation text should provide some brief examples of >how and why >special treatment is needed/provided. Med: I updated the text with an example: Policies relying on source IP address which are enforced by some servers will be applied to all hosts sharing the same IP address. For example, blacklisting the IP address of a spammer host will result in all other hosts sharing that address having their access to the requested service restricted. [RFC6269] describes the issues in detail. Therefore, due to address sharing, servers need an extra information than the source IP address to differentiate the sending host. We call HOST_ID this information. Is it sufficient to >identify the >sending host? application? user? Med: I added this sentence: HOST_ID does not reveal the identity of a user, a subscriber or an application. 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? Med: The document assumes the address sharing function injects the host ide= ntifier. BTW, there is already a performance criterion listed in Figure 3. > >* 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. Med: The new text is: Policies relying on source IP address which are enforced by some servers will be applied to all hosts sharing the same IP address. For example, blacklisting the IP address of a spammer host will result in all other hosts sharing that address having their access to the requested service restricted. [RFC6269] describes the issues in detail. Therefore, due to address sharing, servers need an extra information than the source IP address to differentiate the sending host. We call HOST_ID this information. > >* I don't think there needs to be a description of a >Requirement in this >document any more, so that text can be removed. Med: Done. > >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. Med: Section 3.1 was added as a result of a review from privacy people. I d= o think it is useful to maintain it. Perhaps, move the text to the security= considerations? > >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. Med: We thought having a reference to draft-ietf-intarea-ipv4-id-update (no= w RFC6864) is sufficient. The impact of Middleboxes is already discussed in= that document (see section 5.3). > >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. Med: Done. > >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. Med: The main risk we had in mind is session failure due to handling an unk= nown TCP option. Are you suggesting this text should be expanded? The risk related to handling a new TCP Option is low as measured in [Options]. > >* Additionally, the text contains "0,103%", which I assume should be >"0.103%" (i.e., 1/10th of 1%). Med: Fixed. Thanks. > >*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. Med: There are some proposals (e.g., XFF, Forward-For) which allow to prepe= nd several host-ids. This is already mentioned in the text: When several address sharing devices are crossed, XFF/Forwarded-For header can convey the list of IP addresses (e.g., Figure 1). The origin HOST_ID can be exposed to the target server. For some proposals (e.g., IP Option), this point is not mentioned as the an= alysis shows these proposals are a no starter. For the TCP option, the loss of the original host_id may not be a problem a= s the target usage is between proxies of a CGN and server. Only the informa= tion leaked in the last leg is likely to be useful. > >10. In Section 4.5.1, I would suggest adding some text that describes >how to interpret Figure 2. Med: Done. > >11. Is Section 4.6 theoretical or is there a specific >reference that can >be added for this technique? Med: Added a ref to RFC6346. > >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". Med: The current text says: "If the address sharing function is required to act as a UDP/TCP-HIP relay,= this is not a viable option." This require ALL servers in the Internet are HIP-enabled. It is obvious thi= s is not a viable option for a deployable solution. > >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)? Med: The ICMP approach can work for any transport protocol making use of a = port number. We mentioned TCP and UDP as these are the widely deployed tran= sport protocol. I updated the text as follows: OLD: o This ICMP proposal is valid for both UDP and TCP. Address sharing function may be configurable with the transport protocol which is allowed to trigger those ICMP messages. NEW: o This ICMP proposal is valid for any transport protocol that uses a port number. Address sharing function may be configurable with the transport protocol which is allowed to trigger those ICMP messages. > >* I would also like to see some text describing why the >approach is not >compatible with cascading NATs. Med: The main reason is that each NAT in the path will generate an ICMP mes= sage. These messages will be translated by the downstream NATs. The remote = server will receive multiple ICMP messages and will need to decide which ho= st identifier to use. > >* 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). Med: I updated the text with a reference to a document where the problem is= described in detail: OLD: o In some scenarios (e.g., Fixed-Mobile Convergence, Open WiFi, etc.), HOST_ID should be interpreted by intermediate devices which embed Policy Enforcement Points (PEP, [RFC2753]) responsible for granting access to some services. These PEPs need to inspect all received packets in order to find the companion (traffic) messages to be correlated with ICMP messages conveying HOST_IDs. This induces more complexity to these intermediate devices. NEW: o In some scenarios (e.g., Section 3 of [I-D.boucadair-pcp-nat-reveal]), HOST_ID should be interpreted by intermediate devices which embed Policy Enforcement Points (PEP, [RFC2753]) responsible for granting access to some services. These PEPs need to inspect all received packets in order to find the companion (traffic) messages to be correlated with ICMP messages conveying HOST_IDs. This induces more complexity to these intermediate devices. I updated also the text in Section 4.9.2. > >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. Med: DNS is mentioned as an example. I updated the text as follows; OLD: o A hint should be provided to the ultimate server (or intermediate nodes) the address sharing function implements IDENT protocol. This can be achieved by publishing this capability using DNS. NEW: o A hint should be provided to the ultimate server (or intermediate nodes) the address sharing function implements IDENT protocol. A solution example is to publish this capability using DNS; other solutions can be envisaged. > >15. Section 5 > >* Shouldn't there be an additional metric that covers the >impact/cost of >needing client or middlebox code changes? Med: For almost all solutions, the host identifier is not injected by the c= lient. Host_id injection is done by an address sharing function. The cost of the change in the address sharing will depend on the capabiliti= es supported by that device: a NAT device re-writing packets can inject (in= theory) L3/4 information without extra cost but inspecting packets to inje= ct application-related header would require new features. We focused on the= expected performance impact rather than the expect induced cost. > >* 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? Med: the IP-ID tweaking is implemented in the address sharing function not = the host/OS. In theory, if the address sharing functions follows the rule f= or IP-ID field, failure is unlikely. > >* Given the goal of this document to describe these identification >mechanisms, I don't see the need for the last bulleted list. Med: The intent of that text is to provide a kind of conclusion. No problem= to remove it if you think so. > >Regards, >Brian >_______________________________________________ >Int-area mailing list >Int-area@ietf.org >https://www.ietf.org/mailman/listinfo/int-area > From brian.e.carpenter@gmail.com Tue Feb 12 03:08:46 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E476721F8CF9 for ; Tue, 12 Feb 2013 03:08:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.237 X-Spam-Level: X-Spam-Status: No, score=-102.237 tagged_above=-999 required=5 tests=[AWL=-0.758, BAYES_00=-2.599, HELO_EQ_IP_ADDR=1.119, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BJEb9kqo4gFj for ; Tue, 12 Feb 2013 03:08:46 -0800 (PST) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 4AAA221F8CF8 for ; Tue, 12 Feb 2013 03:08:46 -0800 (PST) Received: by mail-we0-f170.google.com with SMTP id z53so5783701wey.29 for ; Tue, 12 Feb 2013 03:08:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:subject:content-type:content-transfer-encoding; bh=E4N6T6Q3EKruHsIxtoZ5VhYusRlCxJ45a0DJXvjCxIM=; b=QcVekfFdTaNQLhBO204FMXIRkgN5mFjagvOxJPKIKr2jME3T566vN/T4yke4bYqnWv dHx+Q6UtZohj51xAXULo1zstLDNoO+V/KNIWhI2HruMavjGbO93mCPnx85eZCSJNO2mU FYoA0I/ip8UxmsIpeqhz2+9WxzCL6gJBLtQNm/CkREp0vZncIye3B+LFoBM3F1oCevou tzQHgnJeZZEBqED+PwzcHrnKgIEJdeciaHTTsZWOsbWQzf1ccrQrA1HgpbOiVZaL9BG7 QFMhHLf7cNCx1PfEB0mz9wV8V0WMCGHA+jLPCe9K1zjtepq7/aHqKC4njOHJzXlB9Lla ytiw== X-Received: by 10.194.122.98 with SMTP id lr2mr30441025wjb.7.1360667316623; Tue, 12 Feb 2013 03:08:36 -0800 (PST) Received: from [128.232.110.102] (c102.al.cl.cam.ac.uk. [128.232.110.102]) by mx.google.com with ESMTPS id fg6sm19267742wib.10.2013.02.12.03.08.34 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Feb 2013 03:08:35 -0800 (PST) Message-ID: <511A22B8.7030405@gmail.com> Date: Tue, 12 Feb 2013 11:08:40 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Internet Area Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [Int-area] draft-ietf-intarea-flow-label-balancing X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 11:08:47 -0000 We posted this as a new WG draft a few weeks ago: https://datatracker.ietf.org/doc/draft-ietf-intarea-flow-label-balancing/ All comments to date have been incorporated, so are there any further issues or suggestions? Regards Brian From sarikaya2012@gmail.com Tue Feb 12 14:57:27 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD75D21F877A for ; Tue, 12 Feb 2013 14:57:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.568 X-Spam-Level: X-Spam-Status: No, score=-3.568 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RQ8EmMlpgJ0K for ; Tue, 12 Feb 2013 14:57:27 -0800 (PST) Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com [209.85.217.171]) by ietfa.amsl.com (Postfix) with ESMTP id E11B121F85BD for ; Tue, 12 Feb 2013 14:57:26 -0800 (PST) Received: by mail-lb0-f171.google.com with SMTP id gg13so509910lbb.30 for ; Tue, 12 Feb 2013 14:57:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:reply-to:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=BMMNei6//4Ejllj5KJFrkc20IbL7Av35d32rnwqjygo=; b=fnaMZ/0+ujzHxyk/6183m0MwUgAhWhZrqlIjHnHG+WkgTu6ea/fEJkgDH2IkfrQ+ru TpQUpjVqIr7lggxEwtCPmAorSz8LXKcmGWOXCfx3uRZQclb1VY/53anavt01lo5FnTqk 8rvyHjPbKU6f3mGyM6Z/0sczOAA9+uGqfwmXzEFJIbDTc2EwmPKCeIIpn19v+Lgz4w2z eUL/NRKlLxHF/vJw7iDffvop+UN1wRiyaGxXYg2sDuyeJYfyf8nw1TrM4vk6GwbC+mvO dwQ+inYVTm+wKUFqBCmE03gvZGN5u6TpDIuz0YJNKxZ6HvQ8MNCkBVDqZhewK26DVuE9 RD5w== MIME-Version: 1.0 X-Received: by 10.152.45.140 with SMTP id n12mr18193802lam.36.1360709845654; Tue, 12 Feb 2013 14:57:25 -0800 (PST) Received: by 10.114.28.168 with HTTP; Tue, 12 Feb 2013 14:57:25 -0800 (PST) In-Reply-To: <51198814.1060809@ericsson.com> References: <51195E93.4090103@innovationslab.net> <51198814.1060809@ericsson.com> Date: Tue, 12 Feb 2013 16:57:25 -0600 Message-ID: From: Behcet Sarikaya To: Suresh Krishnan Content-Type: multipart/alternative; boundary=bcaec5524516fe1bcd04d58ef28e Cc: int-area@ietf.org, draft-ietf-intarea-nat-reveal-analysis@tools.ietf.org Subject: Re: [Int-area] AD evaluation: draft-ietf-intarea-nat-reveal-analysis X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 22:57:27 -0000 --bcaec5524516fe1bcd04d58ef28e Content-Type: text/plain; charset=ISO-8859-1 Hi Suresh, On Mon, Feb 11, 2013 at 6:08 PM, Suresh Krishnan < suresh.krishnan@ericsson.com> wrote: > Hi Brian, > Thanks for the review. I wanted to clarify three points that you > raised and I will ask the authors take care of the rest. > > On 02/11/2013 04:11 PM, Brian Haberman wrote: > > 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. > > Agree. I think this is precisely the reason that the mechanism for > putting the HOST_ID in the IP-ID is a non-starter. > > > 11. Is Section 4.6 theoretical or is there a specific reference that can > > be added for this technique? > > There are several mechanisms that use port sets for IPv4 address > sharing. A+P (RFC6346) is one such mechanism. > > Section 4.6 is not about about A+P. In A+P there is also the use of a shared public IPv4 address. I think that Section 4.6 refers to the port range solution for an RG with NAT once suggested in BBF. Regards, Behcet --bcaec5524516fe1bcd04d58ef28e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Suresh,

On Mon, Feb 11, 2013 at 6:08 P= M, Suresh Krishnan <suresh.krishnan@ericsson.com>= wrote:
Hi Brian,
=A0 Thanks for the review. I wanted to clarify three points that you
raised and I will ask the authors take care of the rest.

On 02/11/2013 04:11 PM, Brian Haberman wrote:
> 7. In Section 4.1.2, it would be good to describe any issues that the<= br> > approach has with the original use of the Identification field for
> fragmentation reassembly. =A0If a middlebox changes the ID field, weir= d
> things can/will happen if those packets are fragmented somewhere.

Agree. I think this is precisely the reason that the mechanism for putting the HOST_ID in the IP-ID is a non-starter.

> 11. Is Section 4.6 theoretical or is there a specific reference that c= an
> be added for this technique?

There are several mechanisms that use port sets for IPv4 address
sharing. A+P (RFC6346) is one such mechanism.

Section 4.6 is not about abou= t A+P. In A+P there is also the use of a shared public IPv4 address.
I t= hink that Section 4.6 refers to the port range solution for an RG with NAT = once suggested in BBF.


Regards,

Behcet

--bcaec5524516fe1bcd04d58ef28e-- From suresh.krishnan@ericsson.com Tue Feb 12 22:19:09 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C5B121F8992 for ; Tue, 12 Feb 2013 22:19:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.021 X-Spam-Level: X-Spam-Status: No, score=-102.021 tagged_above=-999 required=5 tests=[AWL=0.578, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AzLvPRn-4t3g for ; Tue, 12 Feb 2013 22:19:08 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id DACE121F8675 for ; Tue, 12 Feb 2013 22:19:07 -0800 (PST) X-AuditID: c6180641-b7f926d000000e79-18-511b305a3012 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 4E.85.03705.A503B115; Wed, 13 Feb 2013 07:19:06 +0100 (CET) Received: from eusaamw0706.eamcs.ericsson.se (147.117.20.31) by EUSAAHC008.ericsson.se (147.117.188.96) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 13 Feb 2013 01:19:05 -0500 Received: from [164.48.125.43] (147.117.20.214) by smtps-am.internal.ericsson.com (147.117.20.31) with Microsoft SMTP Server (TLS) id 8.3.279.1; Wed, 13 Feb 2013 01:19:05 -0500 Message-ID: <511B2FC0.1060209@ericsson.com> Date: Wed, 13 Feb 2013 01:16:32 -0500 From: Suresh Krishnan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Brian Haberman References: <51195E93.4090103@innovationslab.net> <51198814.1060809@ericsson.com> <51199062.4080505@innovationslab.net> In-Reply-To: <51199062.4080505@innovationslab.net> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBLMWRmVeSWpSXmKPExsUyuXRPgm6UgXSgwbt9FhYze/4xWhx8/I7F 4sasmywOzB5Llvxk8ph5/AuLx5fLn9kCmKO4bFJSczLLUov07RK4Mo7O+85cMFmw4sHSHywN jPt4uxg5OSQETCS2/pnEBGGLSVy4t56ti5GLQ0jgCKPEpXfTmSCc3YwSj3rXQGW2MEq0NU1j AWnhFdCW2HjsKTOIzSKgKvHn5wt2EJsNaOyGnZ/BxooKhEn0vj7HCFEvKHFy5hOwXhEBXYnG jhVgNrNAkMTbfQ1g9cICvhLr33SzgthCAuUSX9YfZQOxOQWMJFrv/wayOYBOFZdY84YDolVP YsrVFkYIW15i+9s5zBCtmhJb13xnncAoPAvJ5llIWmYhaVnAyLyKkaO0OLUsN93IcBMjMLSP SbA57mBc8MnyEKM0B4uSOG+o64UAIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYzruHWFC++b X+5pPekUbfjrvE15QlTlld4d93isI1Z5tkuInnwVyflfkGuVnhZbWdnTsp7GCSy/31vJXuq/ nfLzRMTjeQLLok4ZyhrLngnv2LDpS5Dvika+iwf75nDkXFMp3D89Z3v6vsORkx+fEVOttCmY /L2Ke42/SM3RjU5KbOfNRfm2JSqxFGckGmoxFxUnAgBQr4ejOwIAAA== Cc: draft-ietf-intarea-nat-reveal-analysis@tools.ietf.org, int-area@ietf.org Subject: Re: [Int-area] AD evaluation: draft-ietf-intarea-nat-reveal-analysis X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 06:19:09 -0000 Hi Brian, On 02/11/2013 07:44 PM, Brian Haberman wrote: > Hi Suresh, > > On 2/11/13 7:08 PM, Suresh Krishnan wrote: >> Hi Brian, >> Thanks for the review. I wanted to clarify three points that you >> raised and I will ask the authors take care of the rest. >> >> On 02/11/2013 04:11 PM, Brian Haberman wrote: >>> 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. >> >> Agree. I think this is precisely the reason that the mechanism for >> putting the HOST_ID in the IP-ID is a non-starter. > > I agree. But that rationale should be in the draft. Ack. Med proposed a reference to RFC6864 Section 5.3. Is that sufficient? > >> >>> 11. Is Section 4.6 theoretical or is there a specific reference that can >>> be added for this technique? >> >> There are several mechanisms that use port sets for IPv4 address >> sharing. A+P (RFC6346) is one such mechanism. > > Then I would ask that a reference be put in to give readers an example. OK. > >> >>> 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? >> >> This technique involves the translator (and not the sender) setting the >> IP-ID field. That is why it can still work with OSes on senders setting >> the IP-ID to zero. > > You still have the issue of the middlebox setting that ID to something > that potentially impacts fragmentation reassembly. So, I would still > like to know how that 100% success ratio was collected. Makes sense. I read the test result % to mean successful connection establishment and identification. Med, can you elaborate a bit on what exactly was tested and what the success % means. Thanks Suresh From suresh.krishnan@ericsson.com Tue Feb 12 22:59:35 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8645421F8AB4 for ; Tue, 12 Feb 2013 22:59:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.093 X-Spam-Level: X-Spam-Status: No, score=-102.093 tagged_above=-999 required=5 tests=[AWL=0.506, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UhtfgXfIUOTT for ; Tue, 12 Feb 2013 22:59:35 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id EDF6721F8A71 for ; Tue, 12 Feb 2013 22:59:34 -0800 (PST) X-AuditID: c6180641-b7f926d000000e79-5a-511b39d6c076 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 59.E5.03705.6D93B115; Wed, 13 Feb 2013 07:59:34 +0100 (CET) Received: from eusaamw0712.eamcs.ericsson.se (147.117.20.181) by EUSAAHC006.ericsson.se (147.117.188.90) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 13 Feb 2013 01:59:33 -0500 Received: from [164.48.125.43] (147.117.20.214) by smtps-am.internal.ericsson.com (147.117.20.181) with Microsoft SMTP Server (TLS) id 8.3.279.1; Wed, 13 Feb 2013 01:59:32 -0500 Message-ID: <511B393A.7080709@ericsson.com> Date: Wed, 13 Feb 2013 01:56:58 -0500 From: Suresh Krishnan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: References: <51195E93.4090103@innovationslab.net> <51198814.1060809@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHLMWRmVeSWpSXmKPExsUyuXRPlO41S+lAgxmvpC1m9vxjtDj4+B2L xY1ZN1kslvctZ7WY3XuaxYHVY+esu+weTyccZPJYsuQnk8fM419YPL5c/swWwBrFZZOSmpNZ llqkb5fAldE88S9LwSSeim/7X7A0ME7m7GLk5JAQMJFom9zGCmGLSVy4t56ti5GLQ0jgCKPE nWXvoJw9jBIzVr1hhnC2MkqsuTOXDaSFV0BbovFWFzuIzSKgKtG7fj6YzQY0dsPOz0wgtqhA mETv63OMEPWCEidnPmEBsUUExCXmPZ4PtoFZYCWjxI3795hBEsICvhLr33SzQmybxihxc04r 2DZOgUCJuRuXA3VzAB0rLrHmDQdImFlAT2LK1RZGCFteYvvbOWBzhAQ0Jbau+c46gVF4FpLd s5C0zELSsoCReRUjR2lxalluupHhJkZgHByTYHPcwbjgk+UhRmkOFiVx3lDXCwFCAumJJanZ qakFqUXxRaU5qcWHGJk4OKUaGN3X31semPRv9vfvzSftt7eX7xR5L2e9I2Nt/us/B0/+m8/s ZCe16Eeu/QRTGaXATZsr26YLGXKG8AvPYkiu4W72XMI1Vdwt1YbP3o/RTP+zYFoAd6UrT/bC t3NVJVgMJj96lhHBf2fKjH3XpHkd8w1/2Dr9luAQOvPu6ilNkR9Xyu4KzDeyVmIpzkg01GIu Kk4EAFFKvbhRAgAA Cc: int-area@ietf.org, draft-ietf-intarea-nat-reveal-analysis@tools.ietf.org, Behcet Sarikaya Subject: Re: [Int-area] AD evaluation: draft-ietf-intarea-nat-reveal-analysis X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 06:59:35 -0000 Hi Behcet, On 02/12/2013 05:57 PM, Behcet Sarikaya wrote: > Hi Suresh, > > On Mon, Feb 11, 2013 at 6:08 PM, Suresh Krishnan > > wrote: > > Hi Brian, > Thanks for the review. I wanted to clarify three points that you > raised and I will ask the authors take care of the rest. > > On 02/11/2013 04:11 PM, Brian Haberman wrote: > > 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. > > Agree. I think this is precisely the reason that the mechanism for > putting the HOST_ID in the IP-ID is a non-starter. > > > 11. Is Section 4.6 theoretical or is there a specific reference > that can > > be added for this technique? > > There are several mechanisms that use port sets for IPv4 address > sharing. A+P (RFC6346) is one such mechanism. > > Section 4.6 is not about about A+P. In A+P there is also the use of a > shared public IPv4 address. Right. But section 4.6 is about assigning port sets and Brian asked if that was any specific mechanisms that assigned port sets. A+P does so. Not sure about what you mean by "In A+P there is also the use of a shared public IPv4 address". This is the reason why we need a HOST_ID at all. Thanks Suresh From mohamed.boucadair@orange.com Tue Feb 12 23:17:19 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B2C221F8920 for ; Tue, 12 Feb 2013 23:17:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.116 X-Spam-Level: X-Spam-Status: No, score=-2.116 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oUW6lM2sCXF7 for ; Tue, 12 Feb 2013 23:17:18 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 78C4A21F891C for ; Tue, 12 Feb 2013 23:17:18 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 1CD93324259; Wed, 13 Feb 2013 08:17:17 +0100 (CET) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 0046B27C05B; Wed, 13 Feb 2013 08:17:17 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Wed, 13 Feb 2013 08:17:16 +0100 From: To: Suresh Krishnan , Brian Haberman Date: Wed, 13 Feb 2013 08:17:15 +0100 Thread-Topic: [Int-area] AD evaluation: draft-ietf-intarea-nat-reveal-analysis Thread-Index: Ac4JsmNA2GKdZix5TfWW6v7PW8faaAAB04oA Message-ID: <94C682931C08B048B7A8645303FDC9F36EAFB5605D@PUEXCB1B.nanterre.francetelecom.fr> References: <51195E93.4090103@innovationslab.net> <51198814.1060809@ericsson.com> <51199062.4080505@innovationslab.net> <511B2FC0.1060209@ericsson.com> In-Reply-To: <511B2FC0.1060209@ericsson.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.2.13.61522 Cc: "draft-ietf-intarea-nat-reveal-analysis@tools.ietf.org" , "int-area@ietf.org" Subject: Re: [Int-area] AD evaluation: draft-ietf-intarea-nat-reveal-analysis X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 07:17:19 -0000 Hi Suresh, Please see inline. Cheers, Med =20 >-----Message d'origine----- >De : Suresh Krishnan [mailto:suresh.krishnan@ericsson.com]=20 >Envoy=E9 : mercredi 13 f=E9vrier 2013 07:17 >=C0 : Brian Haberman >Cc : int-area@ietf.org;=20 >draft-ietf-intarea-nat-reveal-analysis@tools.ietf.org >Objet : Re: [Int-area] AD evaluation:=20 >draft-ietf-intarea-nat-reveal-analysis > >>>> >>>> * Shouldn't there be an additional metric that covers the=20 >impact/cost of >>>> needing client or middlebox code changes? >>>> >>>> * Where did the 100% success ratio for IP-ID come from? =20 >There have been >>>> documented cases of OSes setting the Identification field=20 >to zero. If >>>> that is true, the success ratio can't be 100% can it? >>> >>> This technique involves the translator (and not the sender)=20 >setting the >>> IP-ID field. That is why it can still work with OSes on=20 >senders setting >>> the IP-ID to zero. >>=20 >> You still have the issue of the middlebox setting that ID to=20 >something >> that potentially impacts fragmentation reassembly. So, I would still >> like to know how that 100% success ratio was collected. > >Makes sense. I read the test result % to mean successful connection >establishment and identification. Med, can you elaborate a bit on what >exactly was tested and what the success % means. > Med: I made the following changes:=20 OLD:=20 o "Success ratio" indicates the ratio of successful communications when the option is used. Provided figures are inspired from the results documented in [Options]. NEW: o "Success ratio" indicates the ratio of successful communications with remote servers when the HOST_ID is injected using a candidate solution. And added this NEW text: Provided success ratio figures for TCP and IP options are inspired from the results documented in [Options] [I-D.abdo-hostid-tcpopt-implementation][ExtendTCP]. The provided success ratio for IP-ID is theoretical; it assumes the address sharing function follows the rules in [RFC6864] to re-write the IP Identification field. Since PROXY and HIP are not widely deployed, the success ratio to establish a communication with remote servers using these protocols is low. The success ratio for ICMP-based solution is implementation-specific but it is likely to be close to 100%. A remote server which does not support the ICMP-based solution will ignore received companion ICMP messages. An upgraded server will need to hold accepting a session until receiving the companion ICMP message. The success ratio depends on how efficient the solution is implemented at the server side. The success ratio for IDENT solution is implementation-specific but it is likely to be close to 100%. A remote server which does not support IDENT will accept a session establishment request following its normal operation. An upgraded server will need to hold accepting a session until receiving the response to IDENT request it will send to the host. The success ratio depends on how efficient the solution is implemented at the server side. Cheers; Med From brian@innovationslab.net Wed Feb 13 07:03:58 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D965521F87A6 for ; Wed, 13 Feb 2013 07:03:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JtxckrwdMqC0 for ; Wed, 13 Feb 2013 07:03:57 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 09DC721F8718 for ; Wed, 13 Feb 2013 07:03:57 -0800 (PST) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 6553D88130; Wed, 13 Feb 2013 07:03:54 -0800 (PST) Received: from 102526165.rudm1.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id D767A13000C; Wed, 13 Feb 2013 07:03:53 -0800 (PST) Message-ID: <511BAB5B.8010702@innovationslab.net> Date: Wed, 13 Feb 2013 10:03:55 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: mohamed.boucadair@orange.com References: <51195E93.4090103@innovationslab.net> <94C682931C08B048B7A8645303FDC9F36EAEE11CD9@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EAEE11CD9@PUEXCB1B.nanterre.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "draft-ietf-intarea-nat-reveal-analysis@tools.ietf.org" , "int-area@ietf.org" Subject: Re: [Int-area] AD evaluation: draft-ietf-intarea-nat-reveal-analysis X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 15:03:59 -0000 On 2/12/13 5:34 AM, mohamed.boucadair@orange.com wrote: > Dear Brian, > > Many thanks for the detailed review. > > Please see inline. > > Cheers, Med > >> -----Message d'origine----- De : int-area-bounces@ietf.org >> [mailto:int-area-bounces@ietf.org] De la part de Brian Haberman >> Envoyé : lundi 11 février 2013 22:12 À : int-area@ietf.org; >> draft-ietf-intarea-nat-reveal-analysis@tools.ietf.org Objet : >> [Int-area] AD evaluation: draft-ietf-intarea-nat-reveal-analysis >> >> 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. > > Med: It is true there was a version of the document which includes a > recommendation but the initial intent of the document was to analyze > candidate solution. I updated the text to make it explicit: I changed > the text in the sections you mentioned. In particular, the change in > the abstract is: > > OLD: > > This document analyzes a set of solution candidates to mitigate some > of the issues encountered when address sharing is used. In > particular, this document focuses on means to reveal a host > identifier (HOST_ID) when a Carrier Grade NAT (CGN) or application > proxies are involved in the path. This host identifier must be > unique to each host under the same shared IP address. > > NEW: > > This document is a 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. This host identifier > is used by a remote server to sort out the packets by sending host. > The host identifier must be unique to each host under the same > shared IP address. > > This document analyzes a set of solution candidates to reveal a host > identifier; no recommendation is sketched in the document. > The above text is a good addition to the document. >> >> 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. > > Med: Figure 3 includes this note: > > (2) This solution is widely deployed. > > Can you explicit what change you want to be added? Thanks. > Isn't the IP-ID approach also used in some deployments? I would suggest re-ordering the table so that deployed approaches are collected together (and labeling them as deployed). If the HTTP Forwarded header is the only deployed approach, I would simply add a note for the others stating whether they are a documented proposal or a theoretical construct. >> >> 3. The "Requirements Language" section should be removed. As an >> Informational document describing mechanisms, there is no need to >> leverage 2119 keywords. > > Med: Done. > Ok. >> >> 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). > > Med: I changed the text as follows: > > OLD: > > The sole use of the IPv4 address is not sufficient to uniquely > distinguish a host. As a mitigation, it is tempting to investigate > means which would help in disclosing an information to be used by > the remote server as a means to uniquely disambiguate packets of > hosts using the same IPv4 address. > > NEW: > > In particular, some servers use the source IPv4 address as an > identifier to treat some incoming connections differently. Due to > the deployment of CGNs (e.g., NAT44 [RFC3022], NAT64 [RFC6146]), > that address will be shared. In particular, when a server receives > packets from the same source address, because this address is > shared, the server does not know which host is the sending host > [RFC6269]. The sole use of the IPv4 address is not sufficient to > uniquely distinguish a host. As a mitigation, it is tempting to > investigate means which would help in disclosing an information to be > used by the remote server as a means to uniquely disambiguate packets > of hosts using the same IPv4 address. > That sounds better. >> >> 5. Section 2 >> >> * The Observation text should provide some brief examples of how >> and why special treatment is needed/provided. > > Med: I updated the text with an example: > > Policies relying on source IP address which are enforced by some > servers will be applied to all hosts sharing the same IP address. For > example, blacklisting the IP address of a spammer host will result in > all other hosts sharing that address having their access to the > requested service restricted. [RFC6269] describes the issues in > detail. Therefore, due to address sharing, servers need an extra > information than the source IP address to differentiate the sending > host. We call HOST_ID this information. > Ok. > > Is it sufficient to >> identify the sending host? application? user? > > Med: I added this sentence: > > HOST_ID does not reveal the identity of a user, a subscriber or an > application. > That should suffice. > > 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? > > Med: The document assumes the address sharing function injects the > host identifier. BTW, there is already a performance criterion listed > in Figure 3. > I was thinking more generically than the performance criterion. Suppose a server employs the IP-ID approach. If several packets arrive with the same source IP address and the same value in the IP-ID field, there is no way to know if the IP-ID value was injected by a NAT/CGN box. Or is your response saying that scenario is covered by the metrics used in Figure 3? If so, which metric? None of the descriptive text in Section 5 talks about this type of issue. >> >> * 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. > > Med: The new text is: > > Policies relying on source IP address which are enforced by some > servers will be applied to all hosts sharing the same IP address. For > example, blacklisting the IP address of a spammer host will result in > all other hosts sharing that address having their access to the > requested service restricted. [RFC6269] describes the issues in > detail. Therefore, due to address sharing, servers need an extra > information than the source IP address to differentiate the sending > host. We call HOST_ID this information. > Ok. >> >> * I don't think there needs to be a description of a Requirement in >> this document any more, so that text can be removed. > > Med: Done. > Ok. >> >> 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. > > Med: Section 3.1 was added as a result of a review from privacy > people. I do think it is useful to maintain it. Perhaps, move the > text to the security considerations? > If anything, these are privacy considerations that may be impacted by these types of functions. They can't be requirements at this point. Keeping the text is a good idea in that light, but don't call them Requirements. Moving them to the Security Considerations section would work. >> >> 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. > > Med: We thought having a reference to > draft-ietf-intarea-ipv4-id-update (now RFC6864) is sufficient. The > impact of Middleboxes is already discussed in that document (see > section 5.3). > So maybe the way to clarify this is to re-word the text in 4.1.2. How about: OLD: This usage is not compliant with what is recommended in [I-D.ietf-intarea-ipv4-id-update]. NEW: This usage is not consistent with the fragment reassembly use of the Identification field [RFC791] or the updated handling rules for the Identification field [I-D.ietf-intarea-ipv4-id-update]. >> >> 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. > > Med: Done. > Ok. > >> >> 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. > > Med: The main risk we had in mind is session failure due to handling > an unknown TCP option. Are you suggesting this text should be > expanded? > > The risk related to handling a new TCP Option is low as measured in > [Options]. > It would be good to mention at least one risk, like session failure, in the text to give the readers some clue as to the type of risks being considered. >> >> * Additionally, the text contains "0,103%", which I assume should >> be "0.103%" (i.e., 1/10th of 1%). > > Med: Fixed. Thanks. > Ok. >> >> *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. > > Med: There are some proposals (e.g., XFF, Forward-For) which allow to > prepend several host-ids. This is already mentioned in the text: > > When several address sharing devices are crossed, XFF/Forwarded-For > header can convey the list of IP addresses (e.g., Figure 1). The > origin HOST_ID can be exposed to the target server. > > For some proposals (e.g., IP Option), this point is not mentioned as > the analysis shows these proposals are a no starter. > > For the TCP option, the loss of the original host_id may not be a > problem as the target usage is between proxies of a CGN and server. > Only the information leaked in the last leg is likely to be useful. > Ok. I can see how this is covered. >> >> 10. In Section 4.5.1, I would suggest adding some text that >> describes how to interpret Figure 2. > > Med: Done. > Ok. >> >> 11. Is Section 4.6 theoretical or is there a specific reference >> that can be added for this technique? > > Med: Added a ref to RFC6346. > Ok. >> >> 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". > > Med: The current text says: > > "If the address sharing function is required to act as a UDP/TCP-HIP > relay, this is not a viable option." > > This require ALL servers in the Internet are HIP-enabled. It is > obvious this is not a viable option for a deployable solution. > That is understood. It is not clear why the "UDP/TCP-HIP relay" aspect is mentioned. Is there something special about that deployment model that has additional issues (other than needing all servers to understand HIP)? >> >> 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)? > > Med: The ICMP approach can work for any transport protocol making use > of a port number. We mentioned TCP and UDP as these are the widely > deployed transport protocol. I updated the text as follows: > > OLD: > > o This ICMP proposal is valid for both UDP and TCP. Address > sharing function may be configurable with the transport protocol > which is allowed to trigger those ICMP messages. > > NEW: > > o This ICMP proposal is valid for any transport protocol that uses > a port number. Address sharing function may be configurable with the > transport protocol which is allowed to trigger those ICMP messages. > That works. > >> >> * I would also like to see some text describing why the approach is >> not compatible with cascading NATs. > > Med: The main reason is that each NAT in the path will generate an > ICMP message. These messages will be translated by the downstream > NATs. The remote server will receive multiple ICMP messages and will > need to decide which host identifier to use. > The above text, or something similar, should be added to that bullet. >> >> * 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). > > Med: I updated the text with a reference to a document where the > problem is described in detail: > > OLD: > > o In some scenarios (e.g., Fixed-Mobile Convergence, Open WiFi, > etc.), HOST_ID should be interpreted by intermediate devices which > embed Policy Enforcement Points (PEP, [RFC2753]) responsible for > granting access to some services. These PEPs need to inspect all > received packets in order to find the companion (traffic) messages to > be correlated with ICMP messages conveying HOST_IDs. This induces > more complexity to these intermediate devices. > > NEW: > > o In some scenarios (e.g., Section 3 of > [I-D.boucadair-pcp-nat-reveal]), HOST_ID should be interpreted by > intermediate devices which embed Policy Enforcement Points (PEP, > [RFC2753]) responsible for granting access to some services. These > PEPs need to inspect all received packets in order to find the > companion (traffic) messages to be correlated with ICMP messages > conveying HOST_IDs. This induces more complexity to these > intermediate devices. > > I updated also the text in Section 4.9.2. > Ok. >> >> 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. > > Med: DNS is mentioned as an example. I updated the text as follows; > > OLD: > > o A hint should be provided to the ultimate server (or intermediate > nodes) the address sharing function implements IDENT protocol. This > can be achieved by publishing this capability using DNS. > > NEW: > > o A hint should be provided to the ultimate server (or intermediate > nodes) the address sharing function implements IDENT protocol. A > solution example is to publish this capability using DNS; other > solutions can be envisaged. > Ok. > >> >> 15. Section 5 >> >> * Shouldn't there be an additional metric that covers the >> impact/cost of needing client or middlebox code changes? > > Med: For almost all solutions, the host identifier is not injected by > the client. Host_id injection is done by an address sharing > function. The cost of the change in the address sharing will depend > on the capabilities supported by that device: a NAT device re-writing > packets can inject (in theory) L3/4 information without extra cost > but inspecting packets to inject application-related header would > require new features. We focused on the expected performance impact > rather than the expect induced cost. > Ok. >> >> * 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? > > Med: the IP-ID tweaking is implemented in the address sharing > function not the host/OS. In theory, if the address sharing functions > follows the rule for IP-ID field, failure is unlikely. > Even in the case where packets are fragmented after the middlebox sets the IP-ID? It seems that the success ratio ignores those types of errors. Are those errors counted in the "Possible Perf Impact" metric? >> >> * Given the goal of this document to describe these identification >> mechanisms, I don't see the need for the last bulleted list. > > Med: The intent of that text is to provide a kind of conclusion. No > problem to remove it if you think so. I would prefer that type of discussion be done as prose, rather than a list. I will not object if the authors want to leave it as a list. I do have one other issue... The discussion in 4.4.1 inter-mixes two different HTTP headers. The XFF header is now obsolete (RFC 6648). It has been replaced by the Forwarded: header defined in the referenced draft. Figure 1 uses the correct header name, but the supporting text references XFF in several places. All uses of XFF should be replaced by Forwarded: to be consistent with the current specs. Regards, Brian From brian@innovationslab.net Wed Feb 13 07:04:47 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B218C21F87BB for ; Wed, 13 Feb 2013 07:04:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zPHBJBLupXqe for ; Wed, 13 Feb 2013 07:04:47 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 469EF21F87BA for ; Wed, 13 Feb 2013 07:04:47 -0800 (PST) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 3EE0688130; Wed, 13 Feb 2013 07:04:47 -0800 (PST) Received: from 102526165.rudm1.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id DBB4813000C; Wed, 13 Feb 2013 07:04:46 -0800 (PST) Message-ID: <511BAB90.2020300@innovationslab.net> Date: Wed, 13 Feb 2013 10:04:48 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Suresh Krishnan References: <51195E93.4090103@innovationslab.net> <51198814.1060809@ericsson.com> <51199062.4080505@innovationslab.net> <511B2FC0.1060209@ericsson.com> In-Reply-To: <511B2FC0.1060209@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-intarea-nat-reveal-analysis@tools.ietf.org, int-area@ietf.org Subject: Re: [Int-area] AD evaluation: draft-ietf-intarea-nat-reveal-analysis X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 15:04:47 -0000 On 2/13/13 1:16 AM, Suresh Krishnan wrote: > Hi Brian, > > On 02/11/2013 07:44 PM, Brian Haberman wrote: >> Hi Suresh, >> >> On 2/11/13 7:08 PM, Suresh Krishnan wrote: >>> Hi Brian, >>> Thanks for the review. I wanted to clarify three points that you >>> raised and I will ask the authors take care of the rest. >>> >>> On 02/11/2013 04:11 PM, Brian Haberman wrote: >>>> 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. >>> >>> Agree. I think this is precisely the reason that the mechanism for >>> putting the HOST_ID in the IP-ID is a non-starter. >> >> I agree. But that rationale should be in the draft. > > Ack. Med proposed a reference to RFC6864 Section 5.3. Is that sufficient? > That reference should be fine. >> >>> >>>> 11. Is Section 4.6 theoretical or is there a specific reference that can >>>> be added for this technique? >>> >>> There are several mechanisms that use port sets for IPv4 address >>> sharing. A+P (RFC6346) is one such mechanism. >> >> Then I would ask that a reference be put in to give readers an example. > > OK. > >> >>> >>>> 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? >>> >>> This technique involves the translator (and not the sender) setting the >>> IP-ID field. That is why it can still work with OSes on senders setting >>> the IP-ID to zero. >> >> You still have the issue of the middlebox setting that ID to something >> that potentially impacts fragmentation reassembly. So, I would still >> like to know how that 100% success ratio was collected. > > Makes sense. I read the test result % to mean successful connection > establishment and identification. Med, can you elaborate a bit on what > exactly was tested and what the success % means. > > Thanks > Suresh > From mohamed.boucadair@orange.com Wed Feb 13 08:12:19 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95F0221F86E7 for ; Wed, 13 Feb 2013 08:12:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.136 X-Spam-Level: X-Spam-Status: No, score=-2.136 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y05pZdOY7iHH for ; Wed, 13 Feb 2013 08:12:18 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 7C69621F85DF for ; Wed, 13 Feb 2013 08:12:14 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 6CFC0264A71; Wed, 13 Feb 2013 17:12:08 +0100 (CET) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 4E05D35C055; Wed, 13 Feb 2013 17:12:08 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Wed, 13 Feb 2013 17:12:08 +0100 From: To: Brian Haberman Date: Wed, 13 Feb 2013 17:12:06 +0100 Thread-Topic: [Int-area] AD evaluation: draft-ietf-intarea-nat-reveal-analysis Thread-Index: Ac4J+1nHUqvbZhL6QzOVUGMHuon3+AAAXlWQ Message-ID: <94C682931C08B048B7A8645303FDC9F36EAFB563F6@PUEXCB1B.nanterre.francetelecom.fr> References: <51195E93.4090103@innovationslab.net> <94C682931C08B048B7A8645303FDC9F36EAEE11CD9@PUEXCB1B.nanterre.francetelecom.fr> <511BAB5B.8010702@innovationslab.net> In-Reply-To: <511BAB5B.8010702@innovationslab.net> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.2.13.61522 Cc: "draft-ietf-intarea-nat-reveal-analysis@tools.ietf.org" , "int-area@ietf.org" Subject: Re: [Int-area] AD evaluation: draft-ietf-intarea-nat-reveal-analysis X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 16:12:19 -0000 Re-, Please see inline. Cheers, Med >-----Message d'origine----- >De : Brian Haberman [mailto:brian@innovationslab.net] >Envoy=E9 : mercredi 13 f=E9vrier 2013 16:04 >=C0 : BOUCADAIR Mohamed OLNC/OLN >Cc : int-area@ietf.org; >draft-ietf-intarea-nat-reveal-analysis@tools.ietf.org >Objet : Re: [Int-area] AD evaluation: >draft-ietf-intarea-nat-reveal-analysis > >On 2/12/13 5:34 AM, mohamed.boucadair@orange.com wrote: >> Dear Brian, >> >> Many thanks for the detailed review. >> >> Please see inline. >> >> Cheers, Med >> >>> -----Message d'origine----- De : int-area-bounces@ietf.org >>> [mailto:int-area-bounces@ietf.org] De la part de Brian Haberman >>> Envoy=E9 : lundi 11 f=E9vrier 2013 22:12 =C0 : int-area@ietf.org; >>> draft-ietf-intarea-nat-reveal-analysis@tools.ietf.org Objet : >>> [Int-area] AD evaluation: draft-ietf-intarea-nat-reveal-analysis >>> >>> 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. >> >> Med: It is true there was a version of the document which includes a >> recommendation but the initial intent of the document was to analyze >> candidate solution. I updated the text to make it explicit: I changed >> the text in the sections you mentioned. In particular, the change in >> the abstract is: >> >> OLD: >> >> This document analyzes a set of solution candidates to mitigate some >> of the issues encountered when address sharing is used. In >> particular, this document focuses on means to reveal a host >> identifier (HOST_ID) when a Carrier Grade NAT (CGN) or application >> proxies are involved in the path. This host identifier must be >> unique to each host under the same shared IP address. >> >> NEW: >> >> This document is a 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. This host identifier >> is used by a remote server to sort out the packets by sending host. >> The host identifier must be unique to each host under the same >> shared IP address. >> >> This document analyzes a set of solution candidates to reveal a host >> identifier; no recommendation is sketched in the document. >> > >The above text is a good addition to the document. > >>> >>> 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. >> >> Med: Figure 3 includes this note: >> >> (2) This solution is widely deployed. >> >> Can you explicit what change you want to be added? Thanks. >> > >Isn't the IP-ID approach also used in some deployments? > >I would suggest re-ordering the table so that deployed approaches are >collected together (and labeling them as deployed). If the HTTP >Forwarded header is the only deployed approach, I would simply add a >note for the others stating whether they are a documented >proposal or a >theoretical construct. Med: I added these two notes: (7) The solution is a theoretical construct. (8) The solution is a documented proposal. And updated the table accordingly. > >>> >>> 3. The "Requirements Language" section should be removed. As an >>> Informational document describing mechanisms, there is no need to >>> leverage 2119 keywords. >> >> Med: Done. >> > >Ok. > >>> >>> 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). >> >> Med: I changed the text as follows: >> >> OLD: >> >> The sole use of the IPv4 address is not sufficient to uniquely >> distinguish a host. As a mitigation, it is tempting to investigate >> means which would help in disclosing an information to be used by >> the remote server as a means to uniquely disambiguate packets of >> hosts using the same IPv4 address. >> >> NEW: >> >> In particular, some servers use the source IPv4 address as an >> identifier to treat some incoming connections differently. Due to >> the deployment of CGNs (e.g., NAT44 [RFC3022], NAT64 [RFC6146]), >> that address will be shared. In particular, when a server receives >> packets from the same source address, because this address is >> shared, the server does not know which host is the sending host >> [RFC6269]. The sole use of the IPv4 address is not sufficient to >> uniquely distinguish a host. As a mitigation, it is tempting to >> investigate means which would help in disclosing an information to be >> used by the remote server as a means to uniquely disambiguate packets >> of hosts using the same IPv4 address. >> > >That sounds better. > >>> >>> 5. Section 2 >>> >>> * The Observation text should provide some brief examples of how >>> and why special treatment is needed/provided. >> >> Med: I updated the text with an example: >> >> Policies relying on source IP address which are enforced by some >> servers will be applied to all hosts sharing the same IP address. For >> example, blacklisting the IP address of a spammer host will result in >> all other hosts sharing that address having their access to the >> requested service restricted. [RFC6269] describes the issues in >> detail. Therefore, due to address sharing, servers need an extra >> information than the source IP address to differentiate the sending >> host. We call HOST_ID this information. >> > >Ok. > >> >> Is it sufficient to >>> identify the sending host? application? user? >> >> Med: I added this sentence: >> >> HOST_ID does not reveal the identity of a user, a subscriber or an >> application. >> > >That should suffice. > >> >> 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? >> >> Med: The document assumes the address sharing function injects the >> host identifier. BTW, there is already a performance criterion listed >> in Figure 3. >> > >I was thinking more generically than the performance >criterion. Suppose >a server employs the IP-ID approach. If several packets >arrive with the >same source IP address and the same value in the IP-ID field, there is >no way to know if the IP-ID value was injected by a NAT/CGN >box. Or is >your response saying that scenario is covered by the metrics used in >Figure 3? If so, which metric? None of the descriptive text >in Section >5 talks about this type of issue. Med: For the particular case of IP-ID, we assume the address sharing functi= on does not assign the same ID under the same IP address during a given int= erval time. The following note: (1) Requires mechanism to advertise NAT is participating in this scheme (e.g., DNS PTR record). Is here to precise another mechanism is needed to inform the server IP-ID i= s carrying a host identifier. > >>> >>> * 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. >> >> Med: The new text is: >> >> Policies relying on source IP address which are enforced by some >> servers will be applied to all hosts sharing the same IP address. For >> example, blacklisting the IP address of a spammer host will result in >> all other hosts sharing that address having their access to the >> requested service restricted. [RFC6269] describes the issues in >> detail. Therefore, due to address sharing, servers need an extra >> information than the source IP address to differentiate the sending >> host. We call HOST_ID this information. >> > >Ok. > >>> >>> * I don't think there needs to be a description of a Requirement in >>> this document any more, so that text can be removed. >> >> Med: Done. >> > >Ok. > >>> >>> 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. >> >> Med: Section 3.1 was added as a result of a review from privacy >> people. I do think it is useful to maintain it. Perhaps, move the >> text to the security considerations? >> > >If anything, these are privacy considerations that may be impacted by >these types of functions. They can't be requirements at this point. >Keeping the text is a good idea in that light, but don't call them >Requirements. Moving them to the Security Considerations >section would >work. Med: Section 3.1 is now entitled "Privacy-related Considerations". The text= is cleared to not use "requirement" term. > >>> >>> 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. >> >> Med: We thought having a reference to >> draft-ietf-intarea-ipv4-id-update (now RFC6864) is sufficient. The >> impact of Middleboxes is already discussed in that document (see >> section 5.3). >> > >So maybe the way to clarify this is to re-word the text in 4.1.2. How >about: > >OLD: >This usage is not compliant with what is recommended in > [I-D.ietf-intarea-ipv4-id-update]. > >NEW: >This usage is not consistent with the fragment reassembly use of the >Identification field [RFC791] or the updated handling rules for the >Identification field [I-D.ietf-intarea-ipv4-id-update]. Med: Works for me. I updated the text. Thanks. > >>> >>> 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. >> >> Med: Done. >> > >Ok. > >> >>> >>> 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. >> >> Med: The main risk we had in mind is session failure due to handling >> an unknown TCP option. Are you suggesting this text should be >> expanded? >> >> The risk related to handling a new TCP Option is low as measured in >> [Options]. >> > >It would be good to mention at least one risk, like session >failure, in >the text to give the readers some clue as to the type of risks being >considered. Med: The text reads now: "The risk to experience session failures due to handling a new TCP Option i= s low as measured...". > >>> >>> * Additionally, the text contains "0,103%", which I assume should >>> be "0.103%" (i.e., 1/10th of 1%). >> >> Med: Fixed. Thanks. >> > >Ok. > >>> >>> *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. >> >> Med: There are some proposals (e.g., XFF, Forward-For) which allow to >> prepend several host-ids. This is already mentioned in the text: >> >> When several address sharing devices are crossed, XFF/Forwarded-For >> header can convey the list of IP addresses (e.g., Figure 1). The >> origin HOST_ID can be exposed to the target server. >> >> For some proposals (e.g., IP Option), this point is not mentioned as >> the analysis shows these proposals are a no starter. >> >> For the TCP option, the loss of the original host_id may not be a >> problem as the target usage is between proxies of a CGN and server. >> Only the information leaked in the last leg is likely to be useful. >> > >Ok. I can see how this is covered. > >>> >>> 10. In Section 4.5.1, I would suggest adding some text that >>> describes how to interpret Figure 2. >> >> Med: Done. >> > >Ok. > >>> >>> 11. Is Section 4.6 theoretical or is there a specific reference >>> that can be added for this technique? >> >> Med: Added a ref to RFC6346. >> > >Ok. > >>> >>> 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". >> >> Med: The current text says: >> >> "If the address sharing function is required to act as a UDP/TCP-HIP >> relay, this is not a viable option." >> >> This require ALL servers in the Internet are HIP-enabled. It is >> obvious this is not a viable option for a deployable solution. >> > >That is understood. It is not clear why the "UDP/TCP-HIP >relay" aspect >is mentioned. Is there something special about that deployment model >that has additional issues (other than needing all servers to >understand >HIP)? Med: That model is mentioned because it does not require the host to be HIP= -enabled. I updated the text to make it more explicit: "An alternative deployment model, which does not require the client to be H= IP-enabled, is the address sharing function behave as a UDP/TCP-HIP relay. = This model is also not viable as it assumes all servers are ported to be HI= P-enabled." > >>> >>> 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)? >> >> Med: The ICMP approach can work for any transport protocol making use >> of a port number. We mentioned TCP and UDP as these are the widely >> deployed transport protocol. I updated the text as follows: >> >> OLD: >> >> o This ICMP proposal is valid for both UDP and TCP. Address >> sharing function may be configurable with the transport protocol >> which is allowed to trigger those ICMP messages. >> >> NEW: >> >> o This ICMP proposal is valid for any transport protocol that uses >> a port number. Address sharing function may be configurable with the >> transport protocol which is allowed to trigger those ICMP messages. >> > >That works. > >> >>> >>> * I would also like to see some text describing why the approach is >>> not compatible with cascading NATs. >> >> Med: The main reason is that each NAT in the path will generate an >> ICMP message. These messages will be translated by the downstream >> NATs. The remote server will receive multiple ICMP messages and will >> need to decide which host identifier to use. >> > >The above text, or something similar, should be added to that bullet. Med: Done. > >>> >>> * 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). >> >> Med: I updated the text with a reference to a document where the >> problem is described in detail: >> >> OLD: >> >> o In some scenarios (e.g., Fixed-Mobile Convergence, Open WiFi, >> etc.), HOST_ID should be interpreted by intermediate devices which >> embed Policy Enforcement Points (PEP, [RFC2753]) responsible for >> granting access to some services. These PEPs need to inspect all >> received packets in order to find the companion (traffic) messages to >> be correlated with ICMP messages conveying HOST_IDs. This induces >> more complexity to these intermediate devices. >> >> NEW: >> >> o In some scenarios (e.g., Section 3 of >> [I-D.boucadair-pcp-nat-reveal]), HOST_ID should be interpreted by >> intermediate devices which embed Policy Enforcement Points (PEP, >> [RFC2753]) responsible for granting access to some services. These >> PEPs need to inspect all received packets in order to find the >> companion (traffic) messages to be correlated with ICMP messages >> conveying HOST_IDs. This induces more complexity to these >> intermediate devices. >> >> I updated also the text in Section 4.9.2. >> > >Ok. > >>> >>> 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. >> >> Med: DNS is mentioned as an example. I updated the text as follows; >> >> OLD: >> >> o A hint should be provided to the ultimate server (or intermediate >> nodes) the address sharing function implements IDENT protocol. This >> can be achieved by publishing this capability using DNS. >> >> NEW: >> >> o A hint should be provided to the ultimate server (or intermediate >> nodes) the address sharing function implements IDENT protocol. A >> solution example is to publish this capability using DNS; other >> solutions can be envisaged. >> > >Ok. > >> >>> >>> 15. Section 5 >>> >>> * Shouldn't there be an additional metric that covers the >>> impact/cost of needing client or middlebox code changes? >> >> Med: For almost all solutions, the host identifier is not injected by >> the client. Host_id injection is done by an address sharing >> function. The cost of the change in the address sharing will depend >> on the capabilities supported by that device: a NAT device re-writing >> packets can inject (in theory) L3/4 information without extra cost >> but inspecting packets to inject application-related header would >> require new features. We focused on the expected performance impact >> rather than the expect induced cost. >> > >Ok. > >>> >>> * 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? >> >> Med: the IP-ID tweaking is implemented in the address sharing >> function not the host/OS. In theory, if the address sharing functions >> follows the rule for IP-ID field, failure is unlikely. >> > >Even in the case where packets are fragmented after the middlebox sets >the IP-ID? Med: if the middlbox follows the rules in rfc6864 and the same ID is not re= -assigned to another host sharing the same ip address during a given time i= nterval, why downstream fragmentation will be an issue? It seems that the success ratio ignores those types of >errors. Are those errors counted in the "Possible Perf Impact" metric? Med: No. > >>> >>> * Given the goal of this document to describe these identification >>> mechanisms, I don't see the need for the last bulleted list. >> >> Med: The intent of that text is to provide a kind of conclusion. No >> problem to remove it if you think so. > >I would prefer that type of discussion be done as prose, rather than a >list. I will not object if the authors want to leave it as a list. Med: I removed the list to avoid mis-interpreting that text is promoting a = particular solution. > >I do have one other issue... > >The discussion in 4.4.1 inter-mixes two different HTTP >headers. The XFF >header is now obsolete (RFC 6648). It has been replaced by the >Forwarded: header defined in the referenced draft. Figure 1 uses the >correct header name, but the supporting text references XFF in several >places. All uses of XFF should be replaced by Forwarded: to be >consistent with the current specs. Med: I cleared the text when it makes sense. > >Regards, >Brian > From sarikaya2012@gmail.com Wed Feb 13 08:36:14 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3523621F89D5 for ; Wed, 13 Feb 2013 08:36:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.573 X-Spam-Level: X-Spam-Status: No, score=-3.573 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N2SX5mKvOSi3 for ; Wed, 13 Feb 2013 08:36:13 -0800 (PST) Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) by ietfa.amsl.com (Postfix) with ESMTP id 1DA8721F895B for ; Wed, 13 Feb 2013 08:36:09 -0800 (PST) Received: by mail-lb0-f173.google.com with SMTP id gf7so1092962lbb.18 for ; Wed, 13 Feb 2013 08:36:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:reply-to:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=30KrXezCLXyULG9bhUulgyfhDUYIv/NErfvLGNgWZ0Y=; b=nDbGmwgfOLzERNshXZ2tWwXO0vugL0xgbys4Capy5UnRRdV3HTNBLlDGTYCiS0EAEX GEVASDuPCDW+bAehi/3NHlMT9TRD4KPHafV7H1g2r7N6ngdUZe06rjlULYbekTeQGK98 3ozaJYHE9YgYYSjwX1AdNS080MeYyD2/izS9IKaSdUY2EZo6A+lEK3bZCB+MzRU6uueh gRDKwOxH3XkJHGOnsDZcNBXPSpA/d9tLx9hWBTrbYeN2+RW+8TRYZQvUkOr/L8JCARdN AsnTSqcrzGg+xFuRfd4wgHPCN6xD/bvDxmiZkYFGLZlK8IE8mXsuSMBA81lbzVQrvhs/ 9pwA== MIME-Version: 1.0 X-Received: by 10.152.45.140 with SMTP id n12mr20801791lam.36.1360773369006; Wed, 13 Feb 2013 08:36:09 -0800 (PST) Received: by 10.114.28.168 with HTTP; Wed, 13 Feb 2013 08:36:08 -0800 (PST) In-Reply-To: <511B393A.7080709@ericsson.com> References: <51195E93.4090103@innovationslab.net> <51198814.1060809@ericsson.com> <511B393A.7080709@ericsson.com> Date: Wed, 13 Feb 2013 10:36:08 -0600 Message-ID: From: Behcet Sarikaya To: Suresh Krishnan Content-Type: multipart/alternative; boundary=bcaec5524516478b5604d59dbd22 Cc: int-area@ietf.org, draft-ietf-intarea-nat-reveal-analysis@tools.ietf.org Subject: Re: [Int-area] AD evaluation: draft-ietf-intarea-nat-reveal-analysis X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 16:36:14 -0000 --bcaec5524516478b5604d59dbd22 Content-Type: text/plain; charset=ISO-8859-1 Hi Suresh, On Wed, Feb 13, 2013 at 12:56 AM, Suresh Krishnan < suresh.krishnan@ericsson.com> wrote: > Hi Behcet, > > On 02/12/2013 05:57 PM, Behcet Sarikaya wrote: > > Hi Suresh, > > > > On Mon, Feb 11, 2013 at 6:08 PM, Suresh Krishnan > > > > wrote: > > > > Hi Brian, > > Thanks for the review. I wanted to clarify three points that you > > raised and I will ask the authors take care of the rest. > > > > On 02/11/2013 04:11 PM, Brian Haberman wrote: > > > 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. > > > > Agree. I think this is precisely the reason that the mechanism for > > putting the HOST_ID in the IP-ID is a non-starter. > > > > > 11. Is Section 4.6 theoretical or is there a specific reference > > that can > > > be added for this technique? > > > > There are several mechanisms that use port sets for IPv4 address > > sharing. A+P (RFC6346) is one such mechanism. > > > > Section 4.6 is not about about A+P. In A+P there is also the use of a > > shared public IPv4 address. > > Right. But section 4.6 is about assigning port sets and Brian asked if > that was any specific mechanisms that assigned port sets. A+P does so. > Not sure about what you mean by "In A+P there is also the use of a > shared public IPv4 address". This is the reason why we need a HOST_ID at > all. > > I think that this draft is not about A+P (don't ask me why, ask Med :-) ). The correct reference for Section 4.6 would be BBF document WT-146 on Subscriber Sessions Regards, Behcet > Thanks > Suresh > > --bcaec5524516478b5604d59dbd22 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Suresh,

On Wed, Feb 13, 2013 at 12:56 = AM, Suresh Krishnan <suresh.krishnan@ericsson.com> wrote:
Hi Behcet,

On 02/12/2013 05:57 PM, Behcet Sarikaya wrote:
> Hi Suresh,
>
> On Mon, Feb 11, 2013 at 6:08 PM, Suresh Krishnan
> <suresh.krishnan@ericsson.com <mailto:suresh.krishnan@ericsson.com>> wrote:
>
> =A0 =A0 Hi Brian,
> =A0 =A0 =A0 Thanks for the review. I wanted to clarify three points th= at you
> =A0 =A0 raised and I will ask the authors take care of the rest.
>
> =A0 =A0 On 02/11/2013 04:11 PM, Brian Haberman wrote:
> =A0 =A0 > 7. In Section 4.1.2, it would be good to describe any iss= ues that the
> =A0 =A0 > approach has with the original use of the Identification = field for
> =A0 =A0 > fragmentation reassembly. =A0If a middlebox changes the I= D field, weird
> =A0 =A0 > things can/will happen if those packets are fragmented so= mewhere.
>
> =A0 =A0 Agree. I think this is precisely the reason that the mechanism= for
> =A0 =A0 putting the HOST_ID in the IP-ID is a non-starter.
>
> =A0 =A0 > 11. Is Section 4.6 theoretical or is there a specific ref= erence
> =A0 =A0 that can
> =A0 =A0 > be added for this technique?
>
> =A0 =A0 There are several mechanisms that use port sets for IPv4 addre= ss
> =A0 =A0 sharing. A+P (RFC6346) is one such mechanism.
>
> Section 4.6 is not about about A+P. In A+P there is also the use of a<= br> > shared public IPv4 address.

Right. But section 4.6 is about assigning port sets and Brian asked i= f
that was any specific mechanisms that assigned port sets. A+P does so.
Not sure about what you mean by "In A+P there is also the use of a
shared public IPv4 address". This is the reason why we need a HOST_ID = at
all.


I think that this draft is not about A+P (don'= ;t ask me why, ask Med :-) ).
The correct reference for Section 4.6 woul= d be BBF document WT-146 on Subscriber Sessions


Regards,

Behcet
Thanks
Suresh


--bcaec5524516478b5604d59dbd22-- From mohamed.boucadair@orange.com Wed Feb 13 08:43:54 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22CC121F8945 for ; Wed, 13 Feb 2013 08:43:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.144 X-Spam-Level: X-Spam-Status: No, score=-2.144 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7mne29LnW7vi for ; Wed, 13 Feb 2013 08:43:53 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 05D8921F891D for ; Wed, 13 Feb 2013 08:43:53 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 262CC264BA2; Wed, 13 Feb 2013 17:43:52 +0100 (CET) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 036C74C024; Wed, 13 Feb 2013 17:43:52 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Wed, 13 Feb 2013 17:43:51 +0100 From: To: "sarikaya@ieee.org" , Suresh Krishnan Date: Wed, 13 Feb 2013 17:43:50 +0100 Thread-Topic: [Int-area] AD evaluation: draft-ietf-intarea-nat-reveal-analysis Thread-Index: Ac4KCD9wQ3AKoTanR+WAzZ8W+ckaXAAADapg Message-ID: <94C682931C08B048B7A8645303FDC9F36EAFB56426@PUEXCB1B.nanterre.francetelecom.fr> References: <51195E93.4090103@innovationslab.net> <51198814.1060809@ericsson.com> <511B393A.7080709@ericsson.com> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36EAFB56426PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.24.110314 Cc: "int-area@ietf.org" , "draft-ietf-intarea-nat-reveal-analysis@tools.ietf.org" Subject: Re: [Int-area] AD evaluation: draft-ietf-intarea-nat-reveal-analysis X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 16:43:54 -0000 --_000_94C682931C08B048B7A8645303FDC9F36EAFB56426PUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Behcet, I have two comments: * Host identification issue is valid for any address sharing mechanism. Thi= s is why the introduction mentions already the following: As reported in [RFC6269], several i= ssues are encountered when an IP address is shared among several subscribers. These issues are encountered in various deployment contexts: e.g., Carrier Grade NAT (CGN), application proxies or A+P [RFC6346]. * RFC6346 is provided as an example of a solution making use of port sets. = You are right, other solutions (than a+p) can be considered but having one = pointer to a solution example is just fair. No need to be exhaustive here. Cheers, Med ________________________________ De : Behcet Sarikaya [mailto:sarikaya2012@gmail.com] Envoy=E9 : mercredi 13 f=E9vrier 2013 17:36 =C0 : Suresh Krishnan Cc : Brian Haberman; draft-ietf-intarea-nat-reveal-analysis@tools.ietf.org;= int-area@ietf.org Objet : Re: [Int-area] AD evaluation: draft-ietf-intarea-nat-reveal-analysi= s Hi Suresh, On Wed, Feb 13, 2013 at 12:56 AM, Suresh Krishnan > wrote: Hi Behcet, On 02/12/2013 05:57 PM, Behcet Sarikaya wrote: > Hi Suresh, > > On Mon, Feb 11, 2013 at 6:08 PM, Suresh Krishnan > >> wrote= : > > Hi Brian, > Thanks for the review. I wanted to clarify three points that you > raised and I will ask the authors take care of the rest. > > On 02/11/2013 04:11 PM, Brian Haberman wrote: > > 7. In Section 4.1.2, it would be good to describe any issues that t= he > > approach has with the original use of the Identification field for > > fragmentation reassembly. If a middlebox changes the ID field, wei= rd > > things can/will happen if those packets are fragmented somewhere. > > Agree. I think this is precisely the reason that the mechanism for > putting the HOST_ID in the IP-ID is a non-starter. > > > 11. Is Section 4.6 theoretical or is there a specific reference > that can > > be added for this technique? > > There are several mechanisms that use port sets for IPv4 address > sharing. A+P (RFC6346) is one such mechanism. > > Section 4.6 is not about about A+P. In A+P there is also the use of a > shared public IPv4 address. Right. But section 4.6 is about assigning port sets and Brian asked if that was any specific mechanisms that assigned port sets. A+P does so. Not sure about what you mean by "In A+P there is also the use of a shared public IPv4 address". This is the reason why we need a HOST_ID at all. I think that this draft is not about A+P (don't ask me why, ask Med :-) ). The correct reference for Section 4.6 would be BBF document WT-146 on Subsc= riber Sessions Regards, Behcet Thanks Suresh --_000_94C682931C08B048B7A8645303FDC9F36EAFB56426PUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Behcet,
 
I have two comments:
 
* Host identification issue is valid for any = address=20 sharing mechanism. This is why the introduction mentions already the=20 following:
   As reported in [RFC6269], sev=
eral issues are encountered when an IP
   address is shared among several subscribers.  These issues are
   encountered in various deployment contexts: e.g., Carrier Grade NAT
   (CGN), application proxies or A+P [RFC6346].
* RFC6346 is provided as an example of a solution making use of port sets=
. You are right, other solutions (tha=
n a+p) can be considered but having one pointer to a solution example is ju=
st fair. No need to be exhaustive here.
Cheers,
Med
De : Behcet Sarikaya=20 [mailto:sarikaya2012@gmail.com]
Envoy=E9 : mercredi 13 f= =E9vrier=20 2013 17:36
=C0 : Suresh Krishnan
Cc : Brian= =20 Haberman; draft-ietf-intarea-nat-reveal-analysis@tools.ietf.org;=20 int-area@ietf.org
Objet : Re: [Int-area] AD evaluation:=20 draft-ietf-intarea-nat-reveal-analysis

Hi Suresh,

On Wed, Feb 13, 2013 at 12:56 AM, Suresh Krishna= n <suresh.krishnan@ericsson.com> wrote:
Hi Behcet,

On 02/12/2013 05:57 PM, Behcet Sarikaya wrote:
&= gt; Hi=20 Suresh,
>
> On Mon, Feb 11, 2013 at 6:08 PM, Suresh=20 Krishnan
> <suresh.krishnan@ericsson.c= om=20 <mailto:suresh.krishnan@ericsson.c= om>>=20 wrote:
>
>     Hi Brian,
>     &n= bsp;=20 Thanks for the review. I wanted to clarify three points that you
>= ;=20     raised and I will ask the authors take care of the=20 rest.
>
>     On 02/11/2013 04:11 PM, Brian Haber= man=20 wrote:
>     > 7. In Section 4.1.2, it would be good= to=20 describe any issues that the
>     > approach has wi= th=20 the original use of the Identification field for
>     = >=20 fragmentation reassembly.  If a middlebox changes the ID field,=20 weird
>     > things can/will happen if those packet= s are=20 fragmented somewhere.
>
>     Agree. I think this= is=20 precisely the reason that the mechanism for
>     putti= ng=20 the HOST_ID in the IP-ID is a non-starter.
>
>    = ;=20 > 11. Is Section 4.6 theoretical or is there a specific reference>=20     that can
>     > be added for this=20 technique?
>
>     There are several mechanisms t= hat=20 use port sets for IPv4 address
>     sharing. A+P (RFC6= 346)=20 is one such mechanism.
>
> Section 4.6 is not about about A= +P.=20 In A+P there is also the use of a
> shared public IPv4=20 address.

Right. But section 4.6 is about assigning port se= ts=20 and Brian asked if
that was any specific mechanisms that assigned po= rt=20 sets. A+P does so.
Not sure about what you mean by "In A+P there is = also=20 the use of a
shared public IPv4 address". This is the reason why we = need=20 a HOST_ID at
all.


I think that this draft is not about A+P (don't ask me why, ask = Med=20 :-) ).
The correct reference for Section 4.6 would be BBF document WT-= 146=20 on Subscriber= =20 Sessions


Regards,

Behcet
Thanks
Suresh


--_000_94C682931C08B048B7A8645303FDC9F36EAFB56426PUEXCB1Bnante_-- From brian@innovationslab.net Wed Feb 13 08:51:12 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26F5921F8A77 for ; Wed, 13 Feb 2013 08:51:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZOlRCbe3WqaT for ; Wed, 13 Feb 2013 08:51:10 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id C84D221F8A7E for ; Wed, 13 Feb 2013 08:51:10 -0800 (PST) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 0A8A888155; Wed, 13 Feb 2013 08:51:06 -0800 (PST) Received: from 102526165.rudm1.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 8C95D13000C; Wed, 13 Feb 2013 08:51:05 -0800 (PST) Message-ID: <511BC47A.9050208@innovationslab.net> Date: Wed, 13 Feb 2013 11:51:06 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: mohamed.boucadair@orange.com References: <51195E93.4090103@innovationslab.net> <94C682931C08B048B7A8645303FDC9F36EAEE11CD9@PUEXCB1B.nanterre.francetelecom.fr> <511BAB5B.8010702@innovationslab.net> <94C682931C08B048B7A8645303FDC9F36EAFB563F6@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EAFB563F6@PUEXCB1B.nanterre.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "draft-ietf-intarea-nat-reveal-analysis@tools.ietf.org" , "int-area@ietf.org" Subject: Re: [Int-area] AD evaluation: draft-ietf-intarea-nat-reveal-analysis X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 16:51:12 -0000 On 2/13/13 11:12 AM, mohamed.boucadair@orange.com wrote: >> I would suggest re-ordering the table so that deployed approaches are >> collected together (and labeling them as deployed). If the HTTP >> Forwarded header is the only deployed approach, I would simply add a >> note for the others stating whether they are a documented >> proposal or a >> theoretical construct. > > Med: I added these two notes: > > (7) The solution is a theoretical construct. > (8) The solution is a documented proposal. > > And updated the table accordingly. That should work. >>> 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? >>> >>> Med: The document assumes the address sharing function injects the >>> host identifier. BTW, there is already a performance criterion listed >>> in Figure 3. >>> >> >> I was thinking more generically than the performance >> criterion. Suppose >> a server employs the IP-ID approach. If several packets >> arrive with the >> same source IP address and the same value in the IP-ID field, there is >> no way to know if the IP-ID value was injected by a NAT/CGN >> box. Or is >> your response saying that scenario is covered by the metrics used in >> Figure 3? If so, which metric? None of the descriptive text >> in Section >> 5 talks about this type of issue. > > Med: For the particular case of IP-ID, we assume the address sharing function does not assign the same ID under the same IP address during a given interval time. The following note: > > (1) Requires mechanism to advertise NAT is participating in this > scheme (e.g., DNS PTR record). > > Is here to precise another mechanism is needed to inform the server IP-ID is carrying a host identifier. > Ok. >>>> 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. >>> >>> Med: Section 3.1 was added as a result of a review from privacy >>> people. I do think it is useful to maintain it. Perhaps, move the >>> text to the security considerations? >>> >> >> If anything, these are privacy considerations that may be impacted by >> these types of functions. They can't be requirements at this point. >> Keeping the text is a good idea in that light, but don't call them >> Requirements. Moving them to the Security Considerations >> section would >> work. > > Med: Section 3.1 is now entitled "Privacy-related Considerations". The text is cleared to not use "requirement" term. > Ok. >> >>>> >>>> 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. >>> >>> Med: We thought having a reference to >>> draft-ietf-intarea-ipv4-id-update (now RFC6864) is sufficient. The >>> impact of Middleboxes is already discussed in that document (see >>> section 5.3). >>> >> >> So maybe the way to clarify this is to re-word the text in 4.1.2. How >> about: >> >> OLD: >> This usage is not compliant with what is recommended in >> [I-D.ietf-intarea-ipv4-id-update]. >> >> NEW: >> This usage is not consistent with the fragment reassembly use of the >> Identification field [RFC791] or the updated handling rules for the >> Identification field [I-D.ietf-intarea-ipv4-id-update]. > > Med: Works for me. I updated the text. Thanks. > Ok. >>>> 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. >>> >>> Med: The main risk we had in mind is session failure due to handling >>> an unknown TCP option. Are you suggesting this text should be >>> expanded? >>> >>> The risk related to handling a new TCP Option is low as measured in >>> [Options]. >>> >> >> It would be good to mention at least one risk, like session >> failure, in >> the text to give the readers some clue as to the type of risks being >> considered. > > Med: The text reads now: > > "The risk to experience session failures due to handling a new TCP Option is low as measured...". Ok. >>>> 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". >>> >>> Med: The current text says: >>> >>> "If the address sharing function is required to act as a UDP/TCP-HIP >>> relay, this is not a viable option." >>> >>> This require ALL servers in the Internet are HIP-enabled. It is >>> obvious this is not a viable option for a deployable solution. >>> >> >> That is understood. It is not clear why the "UDP/TCP-HIP >> relay" aspect >> is mentioned. Is there something special about that deployment model >> that has additional issues (other than needing all servers to >> understand >> HIP)? > > Med: That model is mentioned because it does not require the host to be HIP-enabled. I updated the text to make it more explicit: > > "An alternative deployment model, which does not require the client to be HIP-enabled, is the address sharing function behave as a UDP/TCP-HIP relay. This model is also not viable as it assumes all servers are ported to be HIP-enabled." > Ok. >>>> * I would also like to see some text describing why the approach is >>>> not compatible with cascading NATs. >>> >>> Med: The main reason is that each NAT in the path will generate an >>> ICMP message. These messages will be translated by the downstream >>> NATs. The remote server will receive multiple ICMP messages and will >>> need to decide which host identifier to use. >>> >> >> The above text, or something similar, should be added to that bullet. > > Med: Done. > Ok. >>>> >>>> * 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? >>> >>> Med: the IP-ID tweaking is implemented in the address sharing >>> function not the host/OS. In theory, if the address sharing functions >>> follows the rule for IP-ID field, failure is unlikely. >>> >> >> Even in the case where packets are fragmented after the middlebox sets >> the IP-ID? > > Med: if the middlbox follows the rules in rfc6864 and the same ID is not re-assigned to another host sharing the same ip address during a given time interval, why downstream fragmentation will be an issue? That is the piece that is missing. The text in Section 4.1 (or its child sections) does not mention the dependency on RFC 6864. > > It seems that the success ratio ignores those types of >> errors. Are those errors counted in the "Possible Perf Impact" metric? > > Med: No. > >> >>>> >>>> * Given the goal of this document to describe these identification >>>> mechanisms, I don't see the need for the last bulleted list. >>> >>> Med: The intent of that text is to provide a kind of conclusion. No >>> problem to remove it if you think so. >> >> I would prefer that type of discussion be done as prose, rather than a >> list. I will not object if the authors want to leave it as a list. > > Med: I removed the list to avoid mis-interpreting that text is promoting a particular solution. > Ok. >> >> I do have one other issue... >> >> The discussion in 4.4.1 inter-mixes two different HTTP >> headers. The XFF >> header is now obsolete (RFC 6648). It has been replaced by the >> Forwarded: header defined in the referenced draft. Figure 1 uses the >> correct header name, but the supporting text references XFF in several >> places. All uses of XFF should be replaced by Forwarded: to be >> consistent with the current specs. > > Med: I cleared the text when it makes sense. > Ok. Regards, Brian From sarikaya2012@gmail.com Wed Feb 13 09:00:41 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22AA121F886E for ; Wed, 13 Feb 2013 09:00:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.577 X-Spam-Level: X-Spam-Status: No, score=-3.577 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VfG0rfk225Bx for ; Wed, 13 Feb 2013 09:00:39 -0800 (PST) Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com [209.85.217.180]) by ietfa.amsl.com (Postfix) with ESMTP id 04E0A21F8888 for ; Wed, 13 Feb 2013 09:00:34 -0800 (PST) Received: by mail-lb0-f180.google.com with SMTP id q12so1089637lbc.39 for ; Wed, 13 Feb 2013 09:00:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:reply-to:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=K5CcV982Jx2bQzTV7bIJ1wt0yxdRtvZtmUsv6vEZY54=; b=oXXJ7CO0tUoIqGjM2YIUPi0nonCwSAdR9aAo3/WRGJBgQZokBdEil1D0PGAb/ixLI/ uM+4X5pgOBUnGQ75OeQ+v9nnIHymKhzkdkBIHCVmfsAzUfH9z5s4KmJZMHwRvQboj5w5 wxWl21uAN01EQfg+wo/rAfNOQDilJY/oETVGavz9I1gfGZ+lATX0TLq4J6tTf5UyaUe/ Doki9GJLHx1GOG1HeEtU1B/mXfEETjKYIhaYILOQotO7/DBmZWzzewnwvPJFPnMISur0 /pdD/62DSDg/daAVqrtxNgRkLGWkRofZlgBGIQtCZ2XC/LQyKnmrQmhO9v8GdOav5fvy NIug== MIME-Version: 1.0 X-Received: by 10.112.16.102 with SMTP id f6mr9104119lbd.3.1360774830340; Wed, 13 Feb 2013 09:00:30 -0800 (PST) Received: by 10.114.28.168 with HTTP; Wed, 13 Feb 2013 09:00:30 -0800 (PST) In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EAFB56426@PUEXCB1B.nanterre.francetelecom.fr> References: <51195E93.4090103@innovationslab.net> <51198814.1060809@ericsson.com> <511B393A.7080709@ericsson.com> <94C682931C08B048B7A8645303FDC9F36EAFB56426@PUEXCB1B.nanterre.francetelecom.fr> Date: Wed, 13 Feb 2013 11:00:30 -0600 Message-ID: From: Behcet Sarikaya To: mohamed.boucadair@orange.com Content-Type: multipart/alternative; boundary=f46d0401fd0f61ba5704d59e1411 Cc: "draft-ietf-intarea-nat-reveal-analysis@tools.ietf.org" , "int-area@ietf.org" Subject: Re: [Int-area] AD evaluation: draft-ietf-intarea-nat-reveal-analysis X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 17:00:41 -0000 --f46d0401fd0f61ba5704d59e1411 Content-Type: text/plain; charset=ISO-8859-1 Hi Med, On Wed, Feb 13, 2013 at 10:43 AM, wrote: > ** > Hi Behcet, > > I have two comments: > > * Host identification issue is valid for any address sharing mechanism. > I am not sure on A+P? A+P requires point-to-point link, right? > This is why the introduction mentions already the following: > > As reported in [RFC6269 ], several issues are encountered when an IP > address is shared among several subscribers. These issues are > encountered in various deployment contexts: e.g., Carrier Grade NAT > (CGN), application proxies or A+P [RFC6346 ]. > > * RFC6346 is provided as an example of a solution making use of port sets. You are right, other solutions (than a+p) can be considered but having one pointer to a solution example is just fair. No need to be exhaustive here. > > Again, I am not sure if Section 4.6 describes what A+P says? Regards, Behcet > >> > --f46d0401fd0f61ba5704d59e1411 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Med,

On Wed, Feb 13, 2013 at 10:43 AM,= <mohamed.boucadair@orange.com> wrote:
Hi Behcet,
=A0
I have two comments:
=A0
* Host identification issue is valid for any address=20 sharing mechanism.

I am not= sure on A+P?
A+P requires point-to-point link, right?
=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
This is why the introduction mentions already the=20 following:
   As re=
ported in [RFC6269=
], several issues are encountered when a=
n IP
   address is shared among several subscribers.  These issues are
   encountered in various deployment contexts: e.g., Carrier Grade NAT
   (CGN), application proxies or A+P [RFC6346].
* RFC6346 is provided as an example of a solut=
ion making use of port sets. You are right, =
other solutions (than a+p) can be considered but having one pointer to a so=
lution example is just fair. No need to be exhaustive here.

Again, I am not sure if Section 4.6 describes = what A+P says?

Regards,

Behcet



--f46d0401fd0f61ba5704d59e1411-- From mohamed.boucadair@orange.com Wed Feb 13 09:16:35 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6F8721F8AA3 for ; Wed, 13 Feb 2013 09:16:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qqL+--LbPTrR for ; Wed, 13 Feb 2013 09:16:35 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id B88FA21F8A7E for ; Wed, 13 Feb 2013 09:16:33 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id B5F00324D5E; Wed, 13 Feb 2013 18:16:32 +0100 (CET) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 9212B4C06C; Wed, 13 Feb 2013 18:16:32 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Wed, 13 Feb 2013 18:16:31 +0100 From: To: "sarikaya@ieee.org" Date: Wed, 13 Feb 2013 18:16:31 +0100 Thread-Topic: [Int-area] AD evaluation: draft-ietf-intarea-nat-reveal-analysis Thread-Index: Ac4KC6JHHdDbHE/CTxyMPqt3Nio/qwAARC9w Message-ID: <94C682931C08B048B7A8645303FDC9F36EAFB56457@PUEXCB1B.nanterre.francetelecom.fr> References: <51195E93.4090103@innovationslab.net> <51198814.1060809@ericsson.com> <511B393A.7080709@ericsson.com> <94C682931C08B048B7A8645303FDC9F36EAFB56426@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36EAFB56457PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.2.13.163616 Cc: "draft-ietf-intarea-nat-reveal-analysis@tools.ietf.org" , "int-area@ietf.org" Subject: Re: [Int-area] AD evaluation: draft-ietf-intarea-nat-reveal-analysis X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 17:16:36 -0000 --_000_94C682931C08B048B7A8645303FDC9F36EAFB56457PUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re-, Please see inline. Cheers, Med ________________________________ De : Behcet Sarikaya [mailto:sarikaya2012@gmail.com] Envoy=E9 : mercredi 13 f=E9vrier 2013 18:01 =C0 : BOUCADAIR Mohamed OLNC/OLN Cc : Suresh Krishnan; Brian Haberman; draft-ietf-intarea-nat-reveal-analysi= s@tools.ietf.org; int-area@ietf.org Objet : Re: [Int-area] AD evaluation: draft-ietf-intarea-nat-reveal-analysi= s Hi Med, On Wed, Feb 13, 2013 at 10:43 AM, > wrote: Hi Behcet, I have two comments: * Host identification issue is valid for any address sharing mechanism. I am not sure on A+P? [Med] both A+P and NAT-based address sharing solutions are covered by rfc62= 69. host identifier is just a means to distinguish hosts under the same IP = address. It does not matter how address sharing is implemented. A+P requires point-to-point link, right? This is why the introduction mentions already the following: As reported in [RFC6269], several i= ssues are encountered when an IP address is shared among several subscribers. These issues are encountered in various deployment contexts: e.g., Carrier Grade NAT (CGN), application proxies or A+P [RFC6346]. * RFC6346 is provided as an example of a solution making use of port sets. = You are right, other solutions (than a+p) can be considered but having one = pointer to a solution example is just fair. No need to be exhaustive here. Again, I am not sure if Section 4.6 describes what A+P says? [Med] That section says non overlapping port sets are assigned to hosts sha= ring the same IP address. The text does not describe if the shared address = is also configured to those hosts or if there is a NAT in the host, etc. Th= ese are implementation variants. There is no value to provide such details = in that section. Adding a ref to A+P is just fair. This does not preclude o= ther contexts. Regards, Behcet --_000_94C682931C08B048B7A8645303FDC9F36EAFB56457PUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Re-,
 
Please see inline.
 
Cheers,
Med

De : Behcet Sarikaya=20 [mailto:sarikaya2012@gmail.com]
Envoy=E9 : mercredi 13 f= =E9vrier=20 2013 18:01
=C0 : BOUCADAIR Mohamed OLNC/OLN
Cc = :=20 Suresh Krishnan; Brian Haberman;=20 draft-ietf-intarea-nat-reveal-analysis@tools.ietf.org;=20 int-area@ietf.org
Objet : Re: [Int-area] AD evaluation:=20 draft-ietf-intarea-nat-reveal-analysis

Hi Med,

On Wed, Feb 13, 2013 at 10:43 AM, <mohamed.boucadair@orange.com> wrote:
Hi=20 Behcet,
 
I have=20 two comments:
 
* Host=20 identification issue is valid for any address sharing mechanism.=20

I am not sure on A+P?
[Med] both A+P and NAT= -based=20 address sharing solutions are covered by rfc6269. host identifier is just= a=20 means to distinguish hosts under the same IP address. It does not matter = how=20 address sharing is implemented.
 
A+P requires=20 point-to-point link, right?  
This is=20 why the introduction mentions already the following: 
   As repo=
rted in [RFC6269], several issues are encountered when an IP
   address is shared among several subscribers.  These issues are
   encountered in various deployment contexts: e.g., Carrier Grade NAT
   (CGN), application proxies or A+P [RFC6346].
* RFC6346 is pr=
ovided as an example of a solution making use of port sets. You are right, other solutions (than a+p) can be considered b=
ut having one pointer to a solution example is just fair. No need to be exh=
austive here.

Again, I am not sure if Section 4.6 describes what A+P says?
=
[Med] That section says non overlapping port se= ts are=20 assigned to hosts sharing the same IP address. The text does not describe= if=20 the shared address is also configured to those hosts or if there is a NAT= in=20 the host, etc. These are implementation variants. There is no value to pr= ovide=20 such details in that section. Adding a ref to A+P is just fair. This does= not=20 preclude other contexts.

Regards,

Behcet
<= /DIV>


=

--_000_94C682931C08B048B7A8645303FDC9F36EAFB56457PUEXCB1Bnante_-- From sarikaya2012@gmail.com Wed Feb 13 11:09:04 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3030C1F0D0A for ; Wed, 13 Feb 2013 11:09:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.346 X-Spam-Level: X-Spam-Status: No, score=-2.346 tagged_above=-999 required=5 tests=[AWL=0.253, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yUqIePJ8e2a1 for ; Wed, 13 Feb 2013 11:09:03 -0800 (PST) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 016501F0CB7 for ; Wed, 13 Feb 2013 11:09:02 -0800 (PST) Received: by mail-la0-f42.google.com with SMTP id fe20so1527897lab.15 for ; Wed, 13 Feb 2013 11:09:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:reply-to:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=GmyU5QBUEH9sD44NWsM34/f+flGP1uUKgESS0uA7Cas=; b=VkRaYe0siq3F+GG8fWkA3XIuoYIQFtd+b4Ag3Y0PuwFnZgCgfNBFIk3MPvhbM+iACY XMn+vE7CTsGepqZa91QTHDw27/kyrU9Kc+blLKJOnAxZMv09SpfWRADKOpEoxYeukYvu mojMM3g/VPgOatv0ehEdAbFPU+WfrnV0QVISfXalSf/+HYZIhJHuHVxtpMZOf/41FD7+ iHL3rMQjZQIDvfYoL3vUnL/oLSpLvPrO0+Lenil7cusjf9Doe3XwLUnjc5a16I63kyAH yMMH+yD2jjEP3GnnR+RaBtjv9f7dWrYdvlMzEgmowQEK0OE1c3Z0IlbaBU15n2TVh0bK MHbw== MIME-Version: 1.0 X-Received: by 10.152.122.100 with SMTP id lr4mr21246268lab.28.1360782541935; Wed, 13 Feb 2013 11:09:01 -0800 (PST) Received: by 10.114.28.168 with HTTP; Wed, 13 Feb 2013 11:09:01 -0800 (PST) In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EAFB56457@PUEXCB1B.nanterre.francetelecom.fr> References: <51195E93.4090103@innovationslab.net> <51198814.1060809@ericsson.com> <511B393A.7080709@ericsson.com> <94C682931C08B048B7A8645303FDC9F36EAFB56426@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EAFB56457@PUEXCB1B.nanterre.francetelecom.fr> Date: Wed, 13 Feb 2013 13:09:01 -0600 Message-ID: From: Behcet Sarikaya To: mohamed.boucadair@orange.com Content-Type: multipart/alternative; boundary=f46d042ef6610754d104d59fe072 Cc: "draft-ietf-intarea-nat-reveal-analysis@tools.ietf.org" , "int-area@ietf.org" Subject: Re: [Int-area] AD evaluation: draft-ietf-intarea-nat-reveal-analysis X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 19:09:04 -0000 --f46d042ef6610754d104d59fe072 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Med, I think that email discussions we had on this issue in fmc list last year will provide good context in these discussions, please remember them. See inline: On Wed, Feb 13, 2013 at 11:16 AM, wrote: > ** > Re-, > > Please see inline. > > Cheers, > Med > > ------------------------------ > *De :* Behcet Sarikaya [mailto:sarikaya2012@gmail.com] > *Envoy=E9 :* mercredi 13 f=E9vrier 2013 18:01 > *=C0 :* BOUCADAIR Mohamed OLNC/OLN > *Cc :* Suresh Krishnan; Brian Haberman; > draft-ietf-intarea-nat-reveal-analysis@tools.ietf.org; int-area@ietf.org > > *Objet :* Re: [Int-area] AD evaluation: > draft-ietf-intarea-nat-reveal-analysis > > Hi Med, > > On Wed, Feb 13, 2013 at 10:43 AM, wrote: > >> ** >> Hi Behcet, >> >> I have two comments: >> >> * Host identification issue is valid for any address sharing mechanism. >> > > I am not sure on A+P? > [Med] both A+P and NAT-based address sharing solutions are covered by > rfc6269. host identifier is just a means to distinguish hosts under the > same IP address. It does not matter how address sharing is implemented. > > A+P requires point-to-point link, right? > >> This is why the introduction mentions already the following: >> >> As reported in [RFC6269 ], sever= al issues are encountered when an IP >> address is shared among several subscribers. These issues are >> encountered in various deployment contexts: e.g., Carrier Grade NAT >> (CGN), application proxies or A+P [RFC6346 ]. >> >> * RFC6346 is provided as an example of a solution making use of port set= s. You are right, other solutions (than a+p) can be considered but having o= ne pointer to a solution example is just fair. No need to be exhaustive her= e. >> >> > Again, I am not sure if Section 4.6 describes what A+P says? > [Med] That section says non overlapping port sets are assigned to hosts > sharing the same IP address. The text does not describe if the shared > address is also configured to those hosts or if there is a NAT in the hos= t, > etc. These are implementation variants. There is no value to provide such > details in that section. Adding a ref to A+P is just fair. This does not > preclude other contexts. > > If Section 4.6 applies to A+P, there is no need for such a text, just say Use A+P and give the reference, right? Regards, Behcet --f46d042ef6610754d104d59fe072 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Med,

I think that email discussions we had on this issue in fmc l= ist last year will provide good context in these discussions, please rememb= er them.

See inline:

On Wed, Feb 1= 3, 2013 at 11:16 AM, <mohamed.boucadair@orange.com> wrote:
Re-,
=A0
Please see inline.
=A0
Cheers,
Med

De=A0: Behcet Sarikaya=20 [mailto:sarik= aya2012@gmail.com]
Envoy=E9=A0: mercredi 13 f=E9vrier= =20 2013 18:01
=C0=A0: BOUCADAIR Mohamed OLNC/OLN
Cc=A0:= =20 Suresh Krishnan; Brian Haberman;=20 draft-ietf-intarea-nat-reveal-analysis@tools.ietf.org= ;=20 int-area@ietf.org<= /a>

Objet=A0: Re: [Int-area] AD evaluation:=20 draft-ietf-intarea-nat-reveal-analysis

Hi Med,

On Wed, Feb 13, 2013 at 10:4= 3 AM, <mohamed.boucadair@orange.com> wrote:
Hi=20 Behcet,
=A0
I have=20 two comments:
=A0
* Host=20 identification issue is valid for any address sharing mechanism.=20

I am not sure on A+P?
[Med]=A0both A+P and NAT-based=20 address sharing solutions are covered by rfc6269. host identifier is just= a=20 means to distinguish hosts under the same IP address. It does not matter = how=20 address sharing is implemented.
=A0
A+P requires=20 point-to-point link, right?=A0=A0
This is=20 why the introduction mentions already the following: 
   A=
s reported in [RFC6269], several issues are en=
countered when an IP
   address is shared among several subscribers.  These issues are
   encountered in various deployment contexts: e.g., Carrier Grade NAT
   (CGN), application proxies or A+P [RFC6346<=
/font>].
* RFC6346 is provided as an example of a solut=
ion making use of port sets. You are right, =
other solutions (than a+p) can be considered but having one pointer to a so=
lution example is just fair. No need to be exhaustive here.
<= /div>

Again, I am not sure if Section 4.6 describes what A+P says?
=
[Med]=A0Tha= t section says non overlapping port sets are=20 assigned to hosts sharing the same IP address. The text does not describe= if=20 the shared address is also configured to those hosts or if there is a NAT= in=20 the host, etc. These are implementation variants. There is no value to pr= ovide=20 such details in that section. Adding a ref to A+P is just fair. This does= not=20 preclude other contexts.


If Section 4.6 applies to A+P, there is no need f= or such a text, just say Use A+P and give the reference, right?

Regards,

Behcet
--f46d042ef6610754d104d59fe072-- From suresh.krishnan@ericsson.com Wed Feb 13 13:33:27 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08E6C21F8552 for ; Wed, 13 Feb 2013 13:33:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.194 X-Spam-Level: X-Spam-Status: No, score=-102.194 tagged_above=-999 required=5 tests=[AWL=0.405, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Hf3HPlnq54T for ; Wed, 13 Feb 2013 13:33:26 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 848AD21F854F for ; Wed, 13 Feb 2013 13:33:26 -0800 (PST) X-AuditID: c618062d-b7fcb6d000007ada-93-511c06a531ca Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 5C.E6.31450.5A60C115; Wed, 13 Feb 2013 22:33:26 +0100 (CET) Received: from eusaamw0706.eamcs.ericsson.se (147.117.20.31) by EUSAAHC005.ericsson.se (147.117.188.87) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 13 Feb 2013 16:33:25 -0500 Received: from [142.133.112.63] (147.117.20.214) by smtps-am.internal.ericsson.com (147.117.20.31) with Microsoft SMTP Server (TLS) id 8.3.279.1; Wed, 13 Feb 2013 16:33:18 -0500 Message-ID: <511C060B.5090703@ericsson.com> Date: Wed, 13 Feb 2013 16:30:51 -0500 From: Suresh Krishnan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: "int-area@ietf.org" X-Enigmail-Version: 1.5 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPJMWRmVeSWpSXmKPExsUyuXRPuO4yNplAg5YPjBY3Zt1kcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxpHrpQXHmCv2z3rD3MB4i6mLkZNDQsBE4vi8jYwQtpjEhXvr 2boYuTiEBI4wShzdMQXK2c0ocWPmZBYIZyujxKSjK1hBWngFtCUmzN4C1s4ioCpx9/JbNhCb DWjshp2fwVaICoRJ9L4+xwhRLyhxcuYTFhBbBKh3/5MDYLawgIbE954/zF2MHEBniEusecMB EmYW0JOYcrWFEcKWl9j+dg4ziC0koCmxdc131gmMArOQTJ2FpGUWkpYFjMyrGDlKi1PLctON DDYxAgPtmASb7g7GPS8tDzFKc7AoifMGuV4IEBJITyxJzU5NLUgtii8qzUktPsTIxMEp1cDY WOz1rFDk5qHDkUsNrZUyZGyWMEkxlAjs2va5Kc6/bHHFisbqVStOxPpcnf+azU1oevCWH38b +ef/tgu7flL6cNfLxnWnIyzjn/Fu/flFZ6nJ2WCtT0rs1pPEmnVCvOfL3FNeP79D7eXLwpt7 r3y7kHN0XnDR5zkXXx2uaP0/6QrDxo07i4zPKbEUZyQaajEXFScCAPj2dRcCAgAA Subject: [Int-area] Call for agenda items at IETF86 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 21:33:27 -0000 Hi all, The intarea WG will be meeting at the Orlando IETF (we have been allocated a 2 hour 20 min slot) and we are in the process of setting the agenda. Please send us your request for slots detailing * Name of the draft * Short description of why you think the item needs to be discussed in the intarea meeting * Whether the draft has already been presented or will be presented in some other wg/bof. Thanks Suresh and Julien From touch@isi.edu Wed Feb 13 14:25:20 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6F9821E803D for ; Wed, 13 Feb 2013 14:25:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.82 X-Spam-Level: X-Spam-Status: No, score=-102.82 tagged_above=-999 required=5 tests=[AWL=-0.221, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x0VKVTSq8kfm for ; Wed, 13 Feb 2013 14:25:20 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 8E15411E80A3 for ; Wed, 13 Feb 2013 14:25:17 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r1DMOxit017429 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 13 Feb 2013 14:24:59 -0800 (PST) Message-ID: <511C12B5.5080001@isi.edu> Date: Wed, 13 Feb 2013 14:24:53 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Suresh Krishnan References: <51195E93.4090103@innovationslab.net> <51198814.1060809@ericsson.com> In-Reply-To: <51198814.1060809@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: int-area@ietf.org, draft-ietf-intarea-nat-reveal-analysis@tools.ietf.org Subject: Re: [Int-area] AD evaluation: draft-ietf-intarea-nat-reveal-analysis X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 22:25:20 -0000 On 2/11/2013 4:08 PM, Suresh Krishnan wrote: > Hi Brian, > Thanks for the review. I wanted to clarify three points that you > raised and I will ask the authors take care of the rest. > > On 02/11/2013 04:11 PM, Brian Haberman wrote: >> 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. > > Agree. I think this is precisely the reason that the mechanism for > putting the HOST_ID in the IP-ID is a non-starter. It happens if the packet is fragmented before the middlebox (reusing the HOST_ID will destroy the reassembly if any fragment groups are interleaved), or after (if there are multiple paths and not all fragments go through the middlebox. It also violates RFC6864 if the packets are already fragmented when they go through the middlebox translation. Joe From mohamed.boucadair@orange.com Wed Feb 13 22:51:35 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E40621F88B4 for ; Wed, 13 Feb 2013 22:51:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.132 X-Spam-Level: X-Spam-Status: No, score=-2.132 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dz+mkOVox5iI for ; Wed, 13 Feb 2013 22:51:34 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 9B95D21F86F2 for ; Wed, 13 Feb 2013 22:51:32 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 74508264216; Thu, 14 Feb 2013 07:51:31 +0100 (CET) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 53B4A4C024; Thu, 14 Feb 2013 07:51:31 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Thu, 14 Feb 2013 07:51:31 +0100 From: To: "sarikaya@ieee.org" Date: Thu, 14 Feb 2013 07:51:29 +0100 Thread-Topic: [Int-area] AD evaluation: draft-ietf-intarea-nat-reveal-analysis Thread-Index: Ac4KHZZ8NqCwoT7RTNm7AubnrgjggAAYbOIA Message-ID: <94C682931C08B048B7A8645303FDC9F36EAFB564BB@PUEXCB1B.nanterre.francetelecom.fr> References: <51195E93.4090103@innovationslab.net> <51198814.1060809@ericsson.com> <511B393A.7080709@ericsson.com> <94C682931C08B048B7A8645303FDC9F36EAFB56426@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EAFB56457@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36EAFB564BBPUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.2.14.54223 Cc: "draft-ietf-intarea-nat-reveal-analysis@tools.ietf.org" , "int-area@ietf.org" Subject: Re: [Int-area] AD evaluation: draft-ietf-intarea-nat-reveal-analysis X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 06:51:35 -0000 --_000_94C682931C08B048B7A8645303FDC9F36EAFB564BBPUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Behcet, I'm aware of that context but the problem is that I don't have a good refer= ence to cite for it. http://tools.ietf.org/id/draft-schott-fmc-requirements= -02.txt would be a good reference to cite but unfortunately the port set se= ction was removed in the last version http://tools.ietf.org/html/draft-scho= tt-fmc-requirements-04. Saying that, I really think having one example to cite is sufficient. No ne= ed to have an exhaustive reference list. Thanks. Cheers, Med ________________________________ De : Behcet Sarikaya [mailto:sarikaya2012@gmail.com] Envoy=E9 : mercredi 13 f=E9vrier 2013 20:09 =C0 : BOUCADAIR Mohamed OLNC/OLN Cc : Suresh Krishnan; Brian Haberman; draft-ietf-intarea-nat-reveal-analysi= s@tools.ietf.org; int-area@ietf.org Objet : Re: [Int-area] AD evaluation: draft-ietf-intarea-nat-reveal-analysi= s Hi Med, I think that email discussions we had on this issue in fmc list last year w= ill provide good context in these discussions, please remember them. See inline: On Wed, Feb 13, 2013 at 11:16 AM, > wrote: Re-, Please see inline. Cheers, Med ________________________________ De : Behcet Sarikaya [mailto:sarikaya2012@gmail.com] Envoy=E9 : mercredi 13 f=E9vrier 2013 18:01 =C0 : BOUCADAIR Mohamed OLNC/OLN Cc : Suresh Krishnan; Brian Haberman; draft-ietf-intarea-nat-reveal-analysi= s@tools.ietf.org; int-area@ietf.org Objet : Re: [Int-area] AD evaluation: draft-ietf-intarea-nat-reveal-analysi= s Hi Med, On Wed, Feb 13, 2013 at 10:43 AM, > wrote: Hi Behcet, I have two comments: * Host identification issue is valid for any address sharing mechanism. I am not sure on A+P? [Med] both A+P and NAT-based address sharing solutions are covered by rfc62= 69. host identifier is just a means to distinguish hosts under the same IP = address. It does not matter how address sharing is implemented. A+P requires point-to-point link, right? This is why the introduction mentions already the following: As reported in [RFC6269], several i= ssues are encountered when an IP address is shared among several subscribers. These issues are encountered in various deployment contexts: e.g., Carrier Grade NAT (CGN), application proxies or A+P [RFC6346]. * RFC6346 is provided as an example of a solution making use of port sets. = You are right, other solutions (than a+p) can be considered but having one = pointer to a solution example is just fair. No need to be exhaustive here. Again, I am not sure if Section 4.6 describes what A+P says? [Med] That section says non overlapping port sets are assigned to hosts sha= ring the same IP address. The text does not describe if the shared address = is also configured to those hosts or if there is a NAT in the host, etc. Th= ese are implementation variants. There is no value to provide such details = in that section. Adding a ref to A+P is just fair. This does not preclude o= ther contexts. If Section 4.6 applies to A+P, there is no need for such a text, just say U= se A+P and give the reference, right? Regards, Behcet --_000_94C682931C08B048B7A8645303FDC9F36EAFB564BBPUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Behcet,
 
I'm aware of that context but the problem is = that I=20 don't have a good reference to cite for it. http= ://tools.ietf.org/id/draft-schott-fmc-requirements-02.txt would=20 be a good reference to cite but unfortunately the port set section was remo= ved=20 in the last version http:/= /tools.ietf.org/html/draft-schott-fmc-requirements-04.
 
Saying that, I really think having one exampl= e to cite=20 is sufficient. No need to have an exhaustive reference list.<= /DIV>
 
Thanks.
 
Cheers,
Med

De : Behcet Sarikaya=20 [mailto:sarikaya2012@gmail.com]
Envoy=E9 : mercredi 13 f= =E9vrier=20 2013 20:09
=C0 : BOUCADAIR Mohamed OLNC/OLN
Cc = :=20 Suresh Krishnan; Brian Haberman;=20 draft-ietf-intarea-nat-reveal-analysis@tools.ietf.org;=20 int-area@ietf.org
Objet : Re: [Int-area] AD evaluation:=20 draft-ietf-intarea-nat-reveal-analysis

Hi Med,

I think that email discussions we had on this i= ssue=20 in fmc list last year will provide good context in these discussions, ple= ase=20 remember them.

See inline:

On Wed, Feb 13, 2013 at 11:16 AM, <mohamed.boucadair@orange.com> wrote:
Re-,
 
Please=20 see inline.
 
Cheers,
Med

De : Behcet Sarikaya [mailto:sarikaya2012@gmail.com]
Envoy=E9&nbs= p;:=20 mercredi 13 f=E9vrier 2013 18:01
=C0 : BOUCADAIR Moham= ed=20 OLNC/OLN
Cc : Suresh Krishnan; Brian Haberman; draft-ietf-intarea-nat-reveal-analysis@tools.ietf.org= ;=20 int-area@ietf.or= g

Objet : Re: [Int-area] AD evaluation:= =20 draft-ietf-intarea-nat-reveal-analysis

Hi Med,

On Wed, Feb 13, 2013 at 10:43 AM, <= ;mohamed.boucadair@orange.com> wrote:
Hi=20 Behcet,
 
I=20 have two comments:
 
*=20 Host identification issue is valid for any address sharing mechanis= m.=20

I am not sure on A+P?
[Med] both A+P and NAT-based address sharin= g=20 solutions are covered by rfc6269. host identifier is just a means to= =20 distinguish hosts under the same IP address. It does not matter how=20 address sharing is implemented.

A+P requires point-to-point link, right?<= FONT=20 color=3D#0000ff face=3D"Courier New">  
This is why the introduction mentions already = the=20 following:
   As =
reported in [RFC6269=
], several issues are encountered when an =
IP
   address is shared among several subscribers.  These issues are
   encountered in various deployment contexts: e.g., Carrier Grade NAT
   (CGN), application proxies or A+P [RFC6346].
* RFC6346 is pr=
ovided as an example of a solution making use of port sets. You are right, other solutions (than a+p) can be considered b=
ut having one pointer to a solution example is just fair. No need to be exh=
austive here.

Again, I am not sure if Section 4.6 describes what A+P=20 says?
[Med] That= section=20 says non overlapping port sets are assigned to hosts sharing the same= IP=20 address. The text does not describe if the shared address is also=20 configured to those hosts or if there is a NAT in the host, etc. Thes= e are=20 implementation variants. There is no value to provide such details in= that=20 section. Adding a ref to A+P is just fair. This does not preclude oth= er=20 contexts.


If Section 4.6 applies to A+P, there is no need for such a text,= just=20 say Use A+P and give the reference,=20 right?

Regards,

Behcet
<= /HTML> --_000_94C682931C08B048B7A8645303FDC9F36EAFB564BBPUEXCB1Bnante_-- From internet-drafts@ietf.org Wed Feb 13 22:55:30 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E234621F87A4; Wed, 13 Feb 2013 22:55:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xeK-aRslX1TJ; Wed, 13 Feb 2013 22:55:30 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0458A21F87B1; Wed, 13 Feb 2013 22:55:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130214065530.9910.2075.idtracker@ietfa.amsl.com> Date: Wed, 13 Feb 2013 22:55:30 -0800 Cc: int-area@ietf.org Subject: [Int-area] I-D Action: draft-ietf-intarea-nat-reveal-analysis-05.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 06:55:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Internet Area Working Group Working Group= of the IETF. Title : Analysis of Solution Candidates to Reveal a Host Identif= ier (HOST_ID) in Shared Address Deployments Author(s) : Mohamed Boucadair Joe Touch Pierre Levis Reinaldo Penno Filename : draft-ietf-intarea-nat-reveal-analysis-05.txt Pages : 22 Date : 2013-02-13 Abstract: This document is a 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. This host identifier is used by a remote server to sort out the packets by sending host. The host identifier must be unique to each host under the same shared IP address. This document analyzes a set of solution candidates to reveal a host identifier; no recommendation is sketched in the document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-intarea-nat-reveal-analysis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analysis-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-intarea-nat-reveal-analysis-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From sarikaya2012@gmail.com Thu Feb 14 09:36:44 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF4A21F87A4 for ; Thu, 14 Feb 2013 09:36:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.431 X-Spam-Level: X-Spam-Status: No, score=-2.431 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PPEfrOXHhDRm for ; Thu, 14 Feb 2013 09:36:43 -0800 (PST) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 81E9221F87FE for ; Thu, 14 Feb 2013 09:36:42 -0800 (PST) Received: by mail-la0-f41.google.com with SMTP id fo12so2583756lab.0 for ; Thu, 14 Feb 2013 09:36:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:reply-to:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=n2Dw7J5m4r3+6/mS+FbrV/2eAjyxQsRRBnIv3nyEPZM=; b=BvE0iLapNWIjLeFWzdExx3wpZGy7QQ5L4bbOQyl+QXWVhKgxpL+eobl385hnjKBRej TXAIYDOhbzXBlNo/h0ywvFQLoIOVjomZB8pCvktIfRj21Z65S90pOW/LqRTVpZsShmQp ouX7fUdGb6RToAsLdM25dyYFOh2U7akBa7GLT/Jn8spAYw2bis7apvMml60uIr84YTPD nn8qEw91UQgKD8n6Dy0/QjIHddk4GTTMuggk1el8F+08iry5Nq0nab9FWBjJSUFVW9jQ FqaaB0yCZm4LBKFd9Gl+APRB+npPlXSp07wn62gOCum663KQvhwhneOY5WvUyPxkoV4i JLcA== MIME-Version: 1.0 X-Received: by 10.112.28.102 with SMTP id a6mr919035lbh.109.1360863401449; Thu, 14 Feb 2013 09:36:41 -0800 (PST) Received: by 10.114.28.168 with HTTP; Thu, 14 Feb 2013 09:36:41 -0800 (PST) In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EAFB564BB@PUEXCB1B.nanterre.francetelecom.fr> References: <51195E93.4090103@innovationslab.net> <51198814.1060809@ericsson.com> <511B393A.7080709@ericsson.com> <94C682931C08B048B7A8645303FDC9F36EAFB56426@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EAFB56457@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EAFB564BB@PUEXCB1B.nanterre.francetelecom.fr> Date: Thu, 14 Feb 2013 11:36:41 -0600 Message-ID: From: Behcet Sarikaya To: mohamed.boucadair@orange.com Content-Type: multipart/alternative; boundary=f46d040168b3a1981504d5b2b366 Cc: "draft-ietf-intarea-nat-reveal-analysis@tools.ietf.org" , "int-area@ietf.org" Subject: Re: [Int-area] AD evaluation: draft-ietf-intarea-nat-reveal-analysis X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 17:36:45 -0000 --f46d040168b3a1981504d5b2b366 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Med, I realize that you published a revision with the A+P reference. However, I believe A+P is a problem for address sharing with its own solution, i.e. the port range is the host id. I would favor removing Sec. 4.6. Anyway you have not been exhaustive on the solution space. Regards, Behcet On Thu, Feb 14, 2013 at 12:51 AM, wrote: > ** > Hi Behcet, > > I'm aware of that context but the problem is that I don't have a good > reference to cite for it. > http://tools.ietf.org/id/draft-schott-fmc-requirements-02.txt would be a > good reference to cite but unfortunately the port set section was removed > in the last version > http://tools.ietf.org/html/draft-schott-fmc-requirements-04. > > Saying that, I really think having one example to cite is sufficient. No > need to have an exhaustive reference list. > > Thanks. > > Cheers, > Med > > ------------------------------ > *De :* Behcet Sarikaya [mailto:sarikaya2012@gmail.com] > *Envoy=E9 :* mercredi 13 f=E9vrier 2013 20:09 > > *=C0 :* BOUCADAIR Mohamed OLNC/OLN > *Cc :* Suresh Krishnan; Brian Haberman; > draft-ietf-intarea-nat-reveal-analysis@tools.ietf.org; int-area@ietf.org > *Objet :* Re: [Int-area] AD evaluation: > draft-ietf-intarea-nat-reveal-analysis > > Hi Med, > > I think that email discussions we had on this issue in fmc list last year > will provide good context in these discussions, please remember them. > > See inline: > > On Wed, Feb 13, 2013 at 11:16 AM, wrote: > >> ** >> Re-, >> >> Please see inline. >> >> Cheers, >> Med >> >> ------------------------------ >> *De :* Behcet Sarikaya [mailto:sarikaya2012@gmail.com] >> *Envoy=E9 :* mercredi 13 f=E9vrier 2013 18:01 >> *=C0 :* BOUCADAIR Mohamed OLNC/OLN >> *Cc :* Suresh Krishnan; Brian Haberman; >> draft-ietf-intarea-nat-reveal-analysis@tools.ietf.org; int-area@ietf.org >> >> *Objet :* Re: [Int-area] AD evaluation: >> draft-ietf-intarea-nat-reveal-analysis >> >> Hi Med, >> >> On Wed, Feb 13, 2013 at 10:43 AM, wrote: >> >>> ** >>> Hi Behcet, >>> >>> I have two comments: >>> >>> * Host identification issue is valid for any address sharing mechanism. >>> >> >> I am not sure on A+P? >> [Med] both A+P and NAT-based address sharing solutions are covered by >> rfc6269. host identifier is just a means to distinguish hosts under the >> same IP address. It does not matter how address sharing is implemented. >> >> A+P requires point-to-point link, right? >> >>> This is why the introduction mentions already the following: >>> >>> As reported in [RFC6269 ], seve= ral issues are encountered when an IP >>> address is shared among several subscribers. These issues are >>> encountered in various deployment contexts: e.g., Carrier Grade NAT >>> (CGN), application proxies or A+P [RFC6346 ]. >>> >>> * RFC6346 is provided as an example of a solution making use of port se= ts. You are right, other solutions (than a+p) can be considered but having = one pointer to a solution example is just fair. No need to be exhaustive he= re. >>> >>> >> Again, I am not sure if Section 4.6 describes what A+P says? >> [Med] That section says non overlapping port sets are assigned to hosts >> sharing the same IP address. The text does not describe if the shared >> address is also configured to those hosts or if there is a NAT in the ho= st, >> etc. These are implementation variants. There is no value to provide suc= h >> details in that section. Adding a ref to A+P is just fair. This does not >> preclude other contexts. >> >> > If Section 4.6 applies to A+P, there is no need for such a text, just say > Use A+P and give the reference, right? > > Regards, > > Behcet > > --f46d040168b3a1981504d5b2b366 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Med,

I realize that you published a revision with the A+P referen= ce. However, I believe A+P is a problem for address sharing with its own so= lution, i.e. the port range is the host id.

I would favor removing S= ec. 4.6. Anyway you have not been exhaustive on the solution space.

Regards,

Behcet

On Thu, Feb 14= , 2013 at 12:51 AM, <mohamed.boucadair@orange.com> wrote:
Hi Behcet,
=A0
I'm aware of that context but the problem is that I=20 don't have a good reference to cite for it. http://too= ls.ietf.org/id/draft-schott-fmc-requirements-02.txt=A0would=20 be a good reference to cite but unfortunately the port set section was remo= ved=20 in the last version http://tools.ietf.org/html/draft-schott-= fmc-requirements-04.
=A0
Saying that, I really think having one example to cite=20 is sufficient. No need to have an exhaustive reference list.<= /div>
=A0
Thanks.
=A0
Cheers,
Med

De=A0: Behcet Sarikaya=20 [mailto:sarik= aya2012@gmail.com]
Envoy=E9=A0: mercredi 13 f=E9vrier= =20 2013 20:09
Hi Med,

I think that email discussions we had on this i= ssue=20 in fmc list last year will provide good context in these discussions, ple= ase=20 remember them.

See inline:

On Wed, Feb 13, 2013 at 11:16 AM, <mohamed.boucadair@orange.com> wrote:
Re-,
=A0
Please=20 see inline.
=A0
Cheers,
Med

De=A0: Behcet Sarikaya [mailto:sarikaya2012@gmail.com]
= Envoy=E9=A0:=20 mercredi 13 f=E9vrier 2013 18:01
=C0=A0: BOUCADAIR Mohamed= =20 OLNC/OLN
Cc=A0: Suresh Krishnan; Brian Haberman; draft-ietf-intarea-nat-reveal-analysis@tools.ietf.org;=20 int-area@ietf.= org

Objet=A0: Re: [Int-area] AD evaluation:=20 draft-ietf-intarea-nat-reveal-analysis

Hi Med,

On Wed, Feb 13, 2013 at 10:43 AM, <mohamed.boucadai= r@orange.com> wrote:
Hi=20 Behcet,
=A0
I=20 have two comments:
=A0
*=20 Host identification issue is valid for any address sharing mechanis= m.=20

I am not sure on A+P?
[Med]=A0both A+P and NAT-based address sharing=20 solutions are covered by rfc6269. host identifier is just a means to= =20 distinguish hosts under the same IP address. It does not matter how= =20 address sharing is implemented.

A+P requires point-to-point link, right?<= font color=3D"#0000ff" face=3D"Courier New">=A0=A0
This is why the introduction mentions already the=20 following:
=
   As reported in [RFC6269], several issues ar=
e encountered when an IP
   address is shared among several subscribers.  These issues are
   encountered in various deployment contexts: e.g., Carrier Grade NAT
   (CGN), application proxies or A+P [RFC6346<=
/font>].
* RFC6346 is provided as an example of a solut=
ion making use of port sets. You are right, =
other solutions (than a+p) can be considered but having one pointer to a so=
lution example is just fair. No need to be exhaustive here.

Again, I am not sure if Section 4.6 describes what A+P=20 says?
[Med]=A0That = section=20 says non overlapping port sets are assigned to hosts sharing the same= IP=20 address. The text does not describe if the shared address is also=20 configured to those hosts or if there is a NAT in the host, etc. Thes= e are=20 implementation variants. There is no value to provide such details in= that=20 section. Adding a ref to A+P is just fair. This does not preclude oth= er=20 contexts.


If Section 4.6 applies to A+P, there is no need for such a text,= just=20 say Use A+P and give the reference,=20 right?

Regards,

Behcet

--f46d040168b3a1981504d5b2b366-- From dwing@cisco.com Thu Feb 14 14:06:22 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB5AB21F844E for ; Thu, 14 Feb 2013 14:06:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.128 X-Spam-Level: X-Spam-Status: No, score=-110.128 tagged_above=-999 required=5 tests=[AWL=0.471, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Et-0Bl+C1oRx for ; Thu, 14 Feb 2013 14:06:16 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id C178E21F845A for ; Thu, 14 Feb 2013 14:06:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5028; q=dns/txt; s=iport; t=1360879576; x=1362089176; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=BEee64UoOcA68J7Nk8IeqwLYAJPYUzRv3008LuBZXhg=; b=Dc6/oEZBqfBKAoOyKrUVZydDaeoAEBBNCW6l0SHwS0DEKUriGXWMb7Vs UBJjhEPgmYF4CZSAzKTl0eQZ+Og+YmILP45TuoMS0ophwqyLtSAN/mdAn UHCyN2TUwGkL2Aj+0KPHqhsrfmQZIIrCEMQ75rJv35tesQ1jAiTLiP65m A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAApeHVGrRDoJ/2dsb2JhbABEwGsWc4IfAQEBAwEIAl0SBQcBAwIJEQQBAQEnBxkIJQkIAgQBEgsFC4dlAwkFDbM0DYlajDaBBIRKA4gwNoUhhkSBWYEdiiOFE4MogVE X-IronPort-AV: E=Sophos;i="4.84,666,1355097600"; d="scan'208";a="72191321" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 14 Feb 2013 22:06:16 +0000 Received: from DWINGWS01 ([10.154.36.85]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r1EM6Gbp004725; Thu, 14 Feb 2013 22:06:16 GMT From: "Dan Wing" To: , References: <51195E93.4090103@innovationslab.net> <51198814.1060809@ericsson.com> <511B393A.7080709@ericsson.com> <94C682931C08B048B7A8645303FDC9F36EAFB56426@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EAFB56457@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EAFB564BB@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Date: Thu, 14 Feb 2013 14:06:15 -0800 Message-ID: <080201ce0aff$82722520$87566f60$@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLZR+Xvji6rjU60kLkAtATIrjdb8gKjIFyWAjdQPCwCqEQ25AJ0twZnAh/s4ZoCtS1+9AEs/CXyAXAioZ8Cj1UU6gGdnkJClba4sHA= Content-Language: en-us Cc: draft-ietf-intarea-nat-reveal-analysis@tools.ietf.org, int-area@ietf.org Subject: Re: [Int-area] AD evaluation: draft-ietf-intarea-nat-reveal-analysis X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 22:06:22 -0000 > -----Original Message----- > From: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] On > Behalf Of Behcet Sarikaya > Sent: Thursday, February 14, 2013 9:37 AM > To: mohamed.boucadair@orange.com > Cc: draft-ietf-intarea-nat-reveal-analysis@tools.ietf.org; int- > area@ietf.org > Subject: Re: [Int-area] AD evaluation: draft-ietf-intarea-nat-reveal- > analysis >=20 > Hi Med, >=20 > I realize that you published a revision with the A+P reference. = However, > I believe A+P is a problem for address sharing with its own solution, > i.e. the port range is the host id. Except a remote server does not know the address is shared, nor what port range is assigned to a user. Lacking that, it does not have=20 a solution. With that, I would hesitate to rely on the system too much, because changing number of ports per user would need to somehow be coordinated with server logs -- which seems unlikely/impossible. -d > I would favor removing Sec. 4.6. Anyway you have not been exhaustive = on > the solution space. >=20 > Regards, >=20 > Behcet >=20 >=20 > On Thu, Feb 14, 2013 at 12:51 AM, = wrote: >=20 >=20 >=20 > Hi Behcet, >=20 > I'm aware of that context but the problem is that I don't have a > good reference to cite for it. http://tools.ietf.org/id/draft-schott- > fmc-requirements-02.txt would be a good reference to cite but > unfortunately the port set section was removed in the last version > http://tools.ietf.org/html/draft-schott-fmc-requirements-04. >=20 > Saying that, I really think having one example to cite is > sufficient. No need to have an exhaustive reference list. >=20 > Thanks. >=20 > Cheers, > Med >=20 >=20 > ________________________________ >=20 >=20 > De : Behcet Sarikaya [mailto:sarikaya2012@gmail.com] >=20 > Envoy=E9 : mercredi 13 f=E9vrier 2013 20:09 >=20 > =C0 : BOUCADAIR Mohamed OLNC/OLN > Cc : Suresh Krishnan; Brian Haberman; draft-ietf-intarea-nat- > reveal-analysis@tools.ietf.org; int-area@ietf.org > Objet : Re: [Int-area] AD evaluation: draft-ietf-intarea-nat- > reveal-analysis >=20 >=20 > Hi Med, >=20 > I think that email discussions we had on this issue in fmc > list last year will provide good context in these discussions, please > remember them. >=20 > See inline: >=20 >=20 > On Wed, Feb 13, 2013 at 11:16 AM, > wrote: >=20 >=20 >=20 > Re-, >=20 > Please see inline. >=20 > Cheers, > Med >=20 >=20 > ________________________________ >=20 >=20 > De : Behcet Sarikaya > [mailto:sarikaya2012@gmail.com] >=20 > Envoy=E9 : mercredi 13 f=E9vrier 2013 18:01 > =C0 : BOUCADAIR Mohamed OLNC/OLN > Cc : Suresh Krishnan; Brian Haberman; draft-ietf- > intarea-nat-reveal-analysis@tools.ietf.org; int-area@ietf.org >=20 > Objet : Re: [Int-area] AD evaluation: draft-ietf- > intarea-nat-reveal-analysis >=20 >=20 > Hi Med, >=20 >=20 > On Wed, Feb 13, 2013 at 10:43 AM, > wrote: >=20 >=20 >=20 > Hi Behcet, >=20 > I have two comments: >=20 > * Host identification issue is valid for any > address sharing mechanism. >=20 >=20 > I am not sure on A+P? >=20 > [Med] both A+P and NAT-based address sharing > solutions are covered by rfc6269. host identifier is just a means to > distinguish hosts under the same IP address. It does not matter how > address sharing is implemented. >=20 > A+P requires point-to-point link, right? >=20 >=20 > This is why the introduction mentions already > the following: >=20 > As reported in [RFC6269 > ], several issues are = encountered > when an IP > address is shared among several > subscribers. These issues are > encountered in various deployment > contexts: e.g., Carrier Grade NAT > (CGN), application proxies or A+P [RFC6346 > ]. > * RFC6346 is provided as an example of a > solution making use of port sets. You are right, other solutions (than > a+p) can be considered but having one pointer to a solution example is > just fair. No need to be exhaustive here. >=20 >=20 >=20 > Again, I am not sure if Section 4.6 describes what > A+P says? >=20 > [Med] That section says non overlapping port sets > are assigned to hosts sharing the same IP address. The text does not > describe if the shared address is also configured to those hosts or if > there is a NAT in the host, etc. These are implementation variants. > There is no value to provide such details in that section. Adding a = ref > to A+P is just fair. This does not preclude other contexts. >=20 >=20 >=20 >=20 > If Section 4.6 applies to A+P, there is no need for such a > text, just say Use A+P and give the reference, right? >=20 > Regards, >=20 > Behcet >=20 >=20 From ccie15672@yahoo.com Sat Feb 16 09:12:30 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81B8221F8988 for ; Sat, 16 Feb 2013 09:12:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.982 X-Spam-Level: **** X-Spam-Status: No, score=4.982 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_80=2, HTML_MESSAGE=0.001, MISSING_SUBJECT=1.762, TVD_SPACE_RATIO=2.219] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HY-gsJw1e++4 for ; Sat, 16 Feb 2013 09:12:29 -0800 (PST) Received: from nm21.bullet.mail.ne1.yahoo.com (nm21.bullet.mail.ne1.yahoo.com [98.138.90.84]) by ietfa.amsl.com (Postfix) with ESMTP id 8C56421F895F for ; Sat, 16 Feb 2013 09:12:29 -0800 (PST) Received: from [98.138.226.176] by nm21.bullet.mail.ne1.yahoo.com with NNFMP; 16 Feb 2013 17:12:29 -0000 Received: from [98.138.226.169] by tm11.bullet.mail.ne1.yahoo.com with NNFMP; 16 Feb 2013 17:12:29 -0000 Received: from [127.0.0.1] by omp1070.mail.ne1.yahoo.com with NNFMP; 16 Feb 2013 17:12:29 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 90548.95572.bm@omp1070.mail.ne1.yahoo.com Received: (qmail 68694 invoked by uid 60001); 16 Feb 2013 17:12:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1361034748; bh=nvGRdx6T7ogv+d8fTPu+Qpz5xLfDY+VDLoGZa4+784k=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:To:MIME-Version:Content-Type; b=KOZVAGO0D/Rb3/gG41rWbbxIwXTsExutM+SlL30zh5k2p3ujuDi2/4fkO4XeuDk1Q/eQoPiW5CA/IVJ7qyuS6SDEM/awprJA79ih/c6bfBzHl1JIqU3afk9UWM3lFkvY54Y5jOgrCdXsKJdmT5UYj4W8ElqytR2twWiIu7Y7wJM= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:To:MIME-Version:Content-Type; b=bxVdM/A8DMW6npogDY7AV9jpqAi7sY71DiOH3iV1klL7suGB/pHtlGBbnw8UCxY9frFaTqs1LPbG1sqSybiSIMyFXENmeolmKukSbKqWUscUsJU611IIEENcl2l0sB2kh1C6ZqEWZU7QPhhbuOtLA3uDRxvM70r8/TkKZQKAsPM=; X-YMail-OSG: G6aPBC8VM1lm4vSWT4EktqezBwJi6.joPHMuIRyE6rbqxvw zYRKjfuV13aOCUrkT1d8kbLP120maPC2kOGHFx3y8X6INwlvUfLlJznH2QpS 0v.bEdK7gZ46LMJnG15l.G6itx8UtDY0N1xkRb.bozQ5B3r4bxg4KK7ebx0S yivEGPfIDdwzikKzbCl6hY.rQWBfBhBE1LTDyuQqiXddEwzBNcrMw6ss9jxI mA1clXWSskSOuPwacsB5vVv8UsrgGOzrRK3ozuo3CmW8VRIhHTEepCOWqxvS 83hMS_pVzIT4XHVMZcSPTPlKRKCj5xAUVRYCA9uNWGsRLsOc9K3bWRQxfPTh vJ0BSmyihzGurHaf1IPlhQfDMlScZzrGFSbjvPO35ndKtFGjy1wf.9zk3HOt mTC3z1XD_dAnT4Wtgn1A0Qqf4_4cLFM9tg3AozVast8dNGKn0xGMGkTbblnp loJadkTbw.x0d.uk1HUJtuK0LvYwOKtsHzyjFz_uXWJwc2gjxHWdfmmaSoFD DJR8PgcAaWmcGIGBPGrFK.6NhFI3PERINurwjntTMKkw3h_1fSmD.GnJ2ni_ GlkMHBhx2dvjSKF07e2U9LgHzy9cHmYYwLHT8DsInHddvkGGiI_X.lBp1fh7 ONuhcGTPkw7uPndPPMwCXA9ntD1g- Received: from [173.25.161.253] by web125402.mail.ne1.yahoo.com via HTTP; Sat, 16 Feb 2013 09:12:28 PST X-Rocket-MIMEInfo: 001.001, aHR0cDovL3d3dy5uYXRyb2NoZW1pbnRlcm5hdGlvbmFsLmNvbS9uYW16bGZlLzVxeTVwdzRudDJ0bGdkLjhhMHN4MWxzeXpoNDJxeTB5enIyY3UBMAEBAQE- X-Mailer: YahooMailWebService/0.8.133.508 Message-ID: <1361034748.68093.YahooMailNeo@web125402.mail.ne1.yahoo.com> Date: Sat, 16 Feb 2013 09:12:28 -0800 (PST) From: Derick Winkworth To: craig , rtischer , takaratiki , pppext , int-area@ietf.org, yssim666 , kip.kaplan@metavante.com, kip.kaplan@yahoo.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-108205657-475022523-1361034748=:68093" Subject: [Int-area] (no subject) X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Derick Winkworth List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2013 17:12:30 -0000 ---108205657-475022523-1361034748=:68093 Content-Type: text/plain; charset=us-ascii http://www.natrocheminternational.com/namzlfe/5qy5pw4nt2tlgd.8a0sx1lsyzh42qy0yzr2cu ---108205657-475022523-1361034748=:68093 Content-Type: text/html; charset=us-ascii ---108205657-475022523-1361034748=:68093-- From brian@innovationslab.net Mon Feb 18 09:17:59 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E54DD21F8C3C for ; Mon, 18 Feb 2013 09:17:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.637 X-Spam-Level: X-Spam-Status: No, score=-102.637 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NNlL0JTYRljL for ; Mon, 18 Feb 2013 09:17:59 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 4DF9121F8C2F for ; Mon, 18 Feb 2013 09:17:59 -0800 (PST) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 8279388173 for ; Mon, 18 Feb 2013 09:17:54 -0800 (PST) Received: from 10252342.rudm1.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 4962A16017E for ; Mon, 18 Feb 2013 09:17:54 -0800 (PST) Message-ID: <5122623E.3050104@innovationslab.net> Date: Mon, 18 Feb 2013 12:17:50 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "int-area@ietf.org" References: <5122376F.8060305@cisco.com> In-Reply-To: <5122376F.8060305@cisco.com> X-Forwarded-Message-Id: <5122376F.8060305@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Int-area] Fwd: I-D Action: draft-ieee-rac-oui-restructuring-00.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 17:18:00 -0000 Internet Area citizens, In case you are interested in the IEEE OUI registry... Regards, Brian -------- Original Message -------- Subject: Re: [ieee-ietf-coord] FW: I-D Action: draft-ieee-rac-oui-restructuring-00.txt Date: Mon, 18 Feb 2013 15:15:11 +0100 From: Benoit Claise To: Romascanu, Dan (Dan) CC: ieee-ietf-coord@ietf.org Note that a 10-15 minutes slot has been assigned to present this during the OPSAREA meeting. Regards, Benoit > > > > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > Sent: Monday, February 18, 2013 6:41 AM > To: i-d-announce@ietf.org > Subject: I-D Action: draft-ieee-rac-oui-restructuring-00.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : OUI Registry Restructuring > Author(s) : Glenn Parsons > Filename : draft-ieee-rac-oui-restructuring-00.txt > Pages : 18 > Date : 2013-02-17 > > Abstract: > The IEEE Registration Authority Committee, which has oversight > for the OUI based registries, is seeking IETF community input on > its proposal to restructure the OUI registries. This document > provides background on the RAC as well as explaining the proposed > restructuring and the rationale. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ieee-rac-oui-restructuring > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ieee-rac-oui-restructuring-00 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > _______________________________________________ > ieee-ietf-coord mailing list > ieee-ietf-coord@ietf.org > https://www.ietf.org/mailman/listinfo/ieee-ietf-coord > > _______________________________________________ ieee-ietf-coord mailing list ieee-ietf-coord@ietf.org https://www.ietf.org/mailman/listinfo/ieee-ietf-coord From iesg-secretary@ietf.org Fri Feb 22 11:06:43 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BEBD21F8ADF; Fri, 22 Feb 2013 11:06:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SM-hrCsiFNj7; Fri, 22 Feb 2013 11:06:42 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A72E21F86F6; Fri, 22 Feb 2013 11:06:42 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130222190642.19027.84724.idtracker@ietfa.amsl.com> Date: Fri, 22 Feb 2013 11:06:42 -0800 Cc: int-area@ietf.org Subject: [Int-area] Last Call: (Analysis of Solution Candidates to Reveal a Host Identifier (HOST_ID) in Shared Address Deployments) to Informational RFC X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 19:06:43 -0000 The IESG has received a request from the Internet Area Working Group WG (intarea) to consider the following document: - 'Analysis of Solution Candidates to Reveal a Host Identifier (HOST_ID) in Shared Address Deployments' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-03-08. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document is a 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. This host identifier is used by a remote server to sort out the packets by sending host. The host identifier must be unique to each host under the same shared IP address. This document analyzes a set of solution candidates to reveal a host identifier; no recommendation is sketched in the document. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-intarea-nat-reveal-analysis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-intarea-nat-reveal-analysis/ballot/ No IPR declarations have been submitted directly on this I-D. From iesg-secretary@ietf.org Fri Feb 22 11:06:43 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B3F821F8B60 for ; Fri, 22 Feb 2013 11:06:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hms8K-g1U4gd; Fri, 22 Feb 2013 11:06:42 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B378121F89B9; Fri, 22 Feb 2013 11:06:42 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IANA X-Test-IDTracker: no X-IETF-IDTracker: 4.40 X-IETF-Draft-string: draft-ietf-intarea-nat-reveal-analysis X-IETF-Draft-revision: 05 Message-ID: <20130222190642.19027.97687.idtracker@ietfa.amsl.com> Date: Fri, 22 Feb 2013 11:06:42 -0800 Cc: int-area@ietf.org Subject: [Int-area] Last Call: (Analysis of Solution Candidates to Reveal a Host Identifier (HOST_ID) in Shared Address Deployments) to Informational RFC X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: noreply@ietf.org List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 19:06:43 -0000 The IESG has received a request from the Internet Area Working Group WG (intarea) to consider the following document: - 'Analysis of Solution Candidates to Reveal a Host Identifier (HOST_ID) in Shared Address Deployments' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-03-08. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document is a 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. This host identifier is used by a remote server to sort out the packets by sending host. The host identifier must be unique to each host under the same shared IP address. This document analyzes a set of solution candidates to reveal a host identifier; no recommendation is sketched in the document. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-intarea-nat-reveal-analysis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-intarea-nat-reveal-analysis/ballot/ No IPR declarations have been submitted directly on this I-D. From phdgang@gmail.com Mon Feb 25 01:49:57 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8DE421F9294 for ; Mon, 25 Feb 2013 01:49:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.522 X-Spam-Level: X-Spam-Status: No, score=-3.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jg5KkVi82+GE for ; Mon, 25 Feb 2013 01:49:57 -0800 (PST) Received: from mail-qc0-f179.google.com (mail-qc0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 27BBA21F9293 for ; Mon, 25 Feb 2013 01:49:57 -0800 (PST) Received: by mail-qc0-f179.google.com with SMTP id b40so1242435qcq.10 for ; Mon, 25 Feb 2013 01:49:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=jyrxkk/AJouowmzU7Y0lVAF0Cukh5Lkfj/FwgkUw1GA=; b=OMrQvMsnnaxYniyI8SgrKlJtf2MljAB2guivX6qqB/qJyw2AXITQwAph49qj/GLyfp 6stRknDXPwFPFxb5ue1Mlow+1xYkwSgLjReR8UKistdREhwoqTU17nJSe67eUkPaZC/x 9P0NsK5n5gaZmfjH/09REA0UyVi+fXnfrKKtRz73yR2ckVbjS8Oxjv0dQnPGx+1rWYik wGaAzCyl4sxyD9sa/YgWHnqyfUR8mAJEvMZCfGFPRV4xb5BdPT6As4ACd7eoBVH4dNDz n7SUPyoVoWUrcRVWoy37W1KfUOMtYmFtIheap6cjy/YwNvQgZ+cOGOGkK7N8SknEqGXT A+wA== MIME-Version: 1.0 X-Received: by 10.49.96.201 with SMTP id du9mr5589658qeb.47.1361785796526; Mon, 25 Feb 2013 01:49:56 -0800 (PST) Received: by 10.49.48.12 with HTTP; Mon, 25 Feb 2013 01:49:56 -0800 (PST) In-Reply-To: <511C060B.5090703@ericsson.com> References: <511C060B.5090703@ericsson.com> Date: Mon, 25 Feb 2013 17:49:56 +0800 Message-ID: From: GangChen To: Suresh Krishnan Content-Type: text/plain; charset=ISO-8859-1 Cc: "int-area@ietf.org" Subject: Re: [Int-area] Call for agenda items at IETF86 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 09:49:57 -0000 Hello Suresh, May I reserve a time slot for http://datatracker.ietf.org/doc/draft-chen-pcp-mobile-deployment/ The name of the draft is "Analysis of Port Control Protocol in Mobile Network" I think that is a value to discuss in int-area because the draft talks about more generic issues about the applicability of PCP in mobile networks. As you may know 3GPP treats NAT going beyond their architecture. We need a place to encourage PCP deployments in mobile networks. The draft has been presented in PCP WG before. PCP chairs encourage me to present the topic in int-area to receive feedback cause there are many experts from generic areas. Many thanks Gang 2013/2/14, Suresh Krishnan : > Hi all, > The intarea WG will be meeting at the Orlando IETF (we have been > allocated a 2 hour 20 min slot) and we are in the process of setting the > agenda. Please send us your request for slots detailing > > * Name of the draft > * Short description of why you think the item needs to be discussed in > the intarea meeting > * Whether the draft has already been presented or will be presented in > some other wg/bof. > > Thanks > Suresh and Julien > > > > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > From linda.dunbar@huawei.com Mon Feb 25 12:13:53 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 989A721F901E for ; Mon, 25 Feb 2013 12:13:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.626 X-Spam-Level: X-Spam-Status: No, score=-6.626 tagged_above=-999 required=5 tests=[AWL=-0.026, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CsFdOMy3gWPf for ; Mon, 25 Feb 2013 12:13:52 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 614B121F9374 for ; Mon, 25 Feb 2013 12:13:33 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AOU10492; Mon, 25 Feb 2013 20:13:31 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 25 Feb 2013 20:12:39 +0000 Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 25 Feb 2013 20:13:30 +0000 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.01.0323.007; Mon, 25 Feb 2013 12:13:26 -0800 From: Linda Dunbar To: "int-area@ietf.org" Thread-Topic: Updated draft-nachum-sarp to address comments regarding to IPv6 ND applicability Thread-Index: AQHOE5SQ1rSdO/++6UmIE7zfvF99rw== Date: Mon, 25 Feb 2013 20:13:24 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F64512C1E6@dfweml505-mbx> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.137.1] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "julien.ietf@gmail.com" Subject: [Int-area] Updated draft-nachum-sarp to address comments regarding to IPv6 ND applicability X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 20:13:53 -0000 VGhhbmtzIHRvIG1hbnkgcGVvcGxlJ3MgcmVzcG9uc2UgYW5kIGNvbW1lbnRzIHRvIGRyYWZ0LW5h Y2h1bS1zYXJwLTAzLiANCkkgc2VudCBhbiBlbWFpbCBjbGFyaWZ5aW5nIHNvbWUgaXNzdWVzIG9m IHRoaXMgZHJhZnQgYmFjayBpbiBlYXJseSBKYW4uIA0KTm93IHdlIGhhdmUgdXBkYXRlZCB0aGUg ZHJhZnQgdG8gaW5jbHVkZSB0aGUgY2xhcmlmaWNhdGlvbi4gDQoNCkluIGEgbnV0c2hlbGw6DQoN Cg0KUGVvcGxlIGFyZSB1bmRlciB0aGUgaW1wcmVzc2lvbiB0aGF0IHRoZSBkcmFmdCBpcyB0byBz Y2FsZSB0aGUgZmxvb2Rpbmcgb2YgTkQgbWVzc2FnZXMgb24gYWxsIGxpbmtzLiBNTEQgd2FzIGJy b3VnaHQgdXAgdG8gc2F5IHRoYXQgTkQgbWVzc2FnZXMgYXJlIGFjdHVhbGx5IHN1cHByZXNzZWQg ZnJvbSBmbG9vZGluZyB0byBsaW5rcyB3aGljaCBkb24ndCBoYXZlIHRoZSB0YXJnZXQgaG9zdHMu IEJ1dCB0aGF0IGlzIHRoZSBub3QgdGhlIG1haW4gaW50ZW50IG9mIHRoaXMgZHJhZnQuIA0KDQoN ClRoZSByZWFsIGltcGFjdCBvZiBBUlAvTkQgaW4gREMgd2l0aCBtYXNzaXZlIG51bWJlciBvZiBo b3N0cyAob3IgVk1zKSBpcyBvbiB0aGUgTDIvTDMgYm91bmRhcnkgcm91dGVyIChvciBEZWZhdWx0 IEdXKS4gV2hlbiBob3N0cyBpbiBzdWJuZXQgQSBuZWVkcyB0byBzZW5kIGRhdGEgZnJhbWVzIHRv IFN1Ym5ldCBCLCB0aGUgcm91dGVyIGhhcyB0byAxKSByZXNwb25kIHRoZSBBUlAvTkQgcmVxdWVz dHMgZnJvbSBob3N0cyBpbiBTdWJuZXQtQSBhbmQgMikgcmVzb2x2ZSB0YXJnZXQgTUFDIGZvciBo b3N0cyBpbiBzdWJuZXQtQi4gDQoNClRoZSBzZWNvbmQgc3RlcCBpcyBub3Qgb25seSBDUFUgaW50 ZW5zaXZlIGJ1dCBhbHNvIGJ1ZmZlciBpbnRlbnNpdmUuIFRoZXJlIGFyZSBzb21lIHByYWN0aWNl cyB0byBhbGxldmlhdGUgdGhlIHBhaW4gb2YgU3RlcCAxKSBmb3IgSVB2NCwgYnV0IG5vdCBmb3Ig SVB2NiAoaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZHVuYmFyLWFybWQt YXJwLW5kLXNjYWxpbmctcHJhY3RpY2VzLykuDQoNCkluIG9yZGVyIHRvIHByb3RlY3Qgcm91dGVy cyBDUFUgYmVpbmcgb3ZlcmJ1cmRlbmVkIGJ5IHRhcmdldCByZXNvbHV0aW9uIHJlcXVlc3RzLCAg c29tZSByb3V0ZXJzIGhhcyB0byByYXRlIGxpbWl0IHRoZSBUYXJnZXQgTUFDIHJlc29sdXRpb24g cmVxdWVzdHMgdG8gQ1BVIChHbGVhbiBUaHJvdHRsaW5nIHJhdGUgaW4gdGhpcyBtYW51YWwpLiBo dHRwOi8vd3d3LmNpc2NvLmNvbS9lbi9VUy9kb2NzL3N3aXRjaGVzL2RhdGFjZW50ZXIvc3cvNV94 L254LW9zL3VuaWNhc3QvY29uZmlndXJhdGlvbi9ndWlkZS9sM19pcC5wZGYgLCBzZWFyY2hpbmcg Zm9yICJHbGVhbiBUaHJvdHRsaW5nIi4gDQoNCldoZW4gdGhlIEdsZWFuIFRocm90dGxpbmcgcmF0 ZSBpcyBleGNlZWRlZCwgdGhlIGluY29taW5nIGRhdGEgZnJhbWVzIGFyZSBkcm9wcGVkLiANCg0K SW4gdHJhZGl0aW9uYWwgRGF0YSBDZW50ZXIsIGl0IGlzIGxlc3Mgb2YgYW4gaXNzdWUgYmVjYXVz ZSB0aGUgbnVtYmVyIG9mIGhvc3RzIGF0dGFjaGVkIHRvIG9uZSBMMi9MMyBib3VuZGFyeSByb3V0 ZXIgaXMgbGltaXRlZCBieSBwaHlzaWNhbCBwb3J0cyBvZiBzd2l0Y2hlcy9yb3V0ZXJzLiBXaGVu IFNlcnZlcnMgYXJlIHZpcnR1YWxpemVkIHRvIHN1cHBvcnQgMzAgcGx1cyBWTXMsIHRoZSBudW1i ZXIgb2YgaG9zdHMgdW5kZXIgb25lIHJvdXRlciBjYW4gZ3JvdyAzMCBwbHVzIHRpbWVzLiANCg0K VGhlIHNvbHV0aW9uIHByb3Bvc2VkIGluIHRoaXMgZHJhZnQgY2FuIGVsaW1pbmF0ZSAob3IgcmVk dWNlIHRoZSBsaWtlbGlob29kIG9mKSBpbnRlci1zdWJuZXQgZGF0YSBmcmFtZXMgYmVpbmcgZHJv cHBlZC4gIA0KDQpJbiBhZGRpdGlvbiwgdGhlIHRyYWRpdGlvbmFsIERDIGhhcyBlYWNoIHN1Ym5l dCBuaWNlbHkgcGxhY2VkIGluIGxpbWl0ZWQgbnVtYmVyIG9mIHNlcnZlciByYWNrcywgaS5lLiBz d2l0Y2hlcyB1bmRlciByb3V0ZXIgb25seSBuZWVkIHRvIGRlYWwgd2l0aCBNQUMgYWRkcmVzc2Vz IG9mIHRob3NlIGxpbWl0ZWQgc3VibmV0cy4gV2l0aCBzdWJuZXRzIGJlaW5nIHNwcmVhZCBhY3Jv c3MgbWFueSBzZXJ2ZXIgcmFja3MsIHRoZSBzd2l0Y2hlcyBhcmUgZXhwb3NlZCB0byBWTEFOL01B QyBvZiBtYW55IHN1Ym5ldHMsIGdyZWF0bHkgaW5jcmVhc2luZyB0aGUgRkRCLiANCg0KVGhpcyBk cmFmdCBhbHNvIGFkZHJlc3NlcyB0aGUgRkRCIGVudHJpZXMgZXhwbG9zaW9uIGlzc3VlLg0KDQoN CldlIGFyZSBsb29raW5nIGZvcndhcmQgdG8geW91ciBjb21tZW50cyBhbmQgZmVlZGJhY2sgdG8g dGhpcyB1cGRhdGUuIA0KDQpUaGFuayB5b3UgdmVyeSBtdWNoLiANCg0KTGluZGEgDQoNCi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21h aWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogU3VuZGF5LCBGZWJydWFyeSAy NCwgMjAxMyA5OjAxIEFNDQpUbzogdGFsbWlAbWFydmVsbC5jb20NCkNjOiBMaW5kYSBEdW5iYXI7 IHlpbGFuQG1hcnZlbGwuY29tOyB5b3V2YWwubmFjaHVtQGdtYWlsLmNvbQ0KU3ViamVjdDogTmV3 IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1uYWNodW0tc2FycC0wNC50eHQNCg0KDQpB IG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtbmFjaHVtLXNhcnAtMDQudHh0DQpoYXMgYmVlbiBz dWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFRhbCBNaXpyYWhpIGFuZCBwb3N0ZWQgdG8gdGhlDQpJ RVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQtbmFjaHVtLXNhcnANClJldmlzaW9u OgkgMDQNClRpdGxlOgkJIFNjYWxpbmcgdGhlIEFkZHJlc3MgUmVzb2x1dGlvbiBQcm90b2NvbCBm b3IgTGFyZ2UgRGF0YSBDZW50ZXJzIChTQVJQKQ0KQ3JlYXRpb24gZGF0ZToJIDIwMTMtMDItMjQN Ckdyb3VwOgkJIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiAxOQ0KVVJM OiAgICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1u YWNodW0tc2FycC0wNC50eHQNClN0YXR1czogICAgICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1uYWNodW0tc2FycA0KSHRtbGl6ZWQ6ICAgICAgICBodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1uYWNodW0tc2FycC0wNA0KRGlmZjogICAgICAgICAgICBo dHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1uYWNodW0tc2FycC0wNA0KDQpB YnN0cmFjdDoNCiAgIFRoaXMgIGRvY3VtZW50ICBwcm92aWRlcyAgYSAgcmVjb21tZW5kZWQgIGFy Y2hpdGVjdHVyZSAgYW5kICBuZXR3b3JrDQogICBvcGVyYXRpb24gIG5hbWVkICBTQVJQLiAgU0FS UCAgaXMgIGJhc2VkICBvbiAgZmFzdCAgcHJveGllcyAgdGhhdA0KICAgc2lnbmlmaWNhbnRseSAg cmVkdWNlICBicm9hZGNhc3QgIGRvbWFpbnMgIGFuZCAgQVJQL05EICBicm9hZGNhc3QNCiAgIHRy YW5zbWlzc2lvbnMuIFNBUlAgc3VwcG9ydHMgc21vb3RoIGFuZCBmYXN0IHZpcnR1YWwgbWFjaGlu ZSAoVk0pDQogICBtb2JpbGl0eSB3aXRob3V0IGFueSBtb2RpZmljYXRpb24gdG8gdGhlIFZNLCB3 aGlsZSBrZWVwaW5nIHRoZQ0KICAgY29ubmVjdGlvbiB1cCBhbmQgcnVubmluZyBlZmZpY2llbnRs eS4gIFNBUlAgaXMgdGFyZ2V0ZWQgZm9yIG1hc3NpdmUNCiAgIHNjYWxpbmcgZGF0YSBjZW50ZXJz IHdpdGggYSBzaWduaWZpY2FudCBudW1iZXIgb2YgVk1zIHVzaW5nIEFSUCBhbmQNCiAgIE5EIHBy b3RvY29scy4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClRoZSBJRVRGIFNlY3Jl dGFyaWF0DQoNCg== From brian@innovationslab.net Thu Feb 28 07:34:38 2013 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F39521F8B96 for ; Thu, 28 Feb 2013 07:34:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uylN4giNpmqR for ; Thu, 28 Feb 2013 07:34:37 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id D151621F8B70 for ; Thu, 28 Feb 2013 07:34:37 -0800 (PST) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id AA55588116 for ; Thu, 28 Feb 2013 07:34:37 -0800 (PST) Received: from clemson.mtw.jhu.edu (unknown [128.220.159.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 7C16914000C for ; Thu, 28 Feb 2013 07:34:37 -0800 (PST) Message-ID: <512F7914.1010907@innovationslab.net> Date: Thu, 28 Feb 2013 10:34:44 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: "int-area@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Int-area] INT ADs' office hours X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 15:34:38 -0000 All, Since the concept was well-received in Atlanta, we will be repeating the AD office hours in Orlando. We will be available on Monday from 1300 to 1500 in the yet-to-be-identified IESG breakout room. Feel free to stop by and ask questions or chat about any concerns/ideas you have about an INT WG or the area as a whole. Regards, Brian, Ralph, & Ted