Review of draft-williams-exp-tcp-host-id-opt-07
S Moonesamy <sm+ietf@elandsys.com> Sat, 30 January 2016 20:52 UTC
Return-Path: <sm@elandsys.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCAD71A90A9 for <ietf@ietfa.amsl.com>; Sat, 30 Jan 2016 12:52:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.909
X-Spam-Level:
X-Spam-Status: No, score=0.909 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.001, T_DKIM_INVALID=0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ayNVIJDVzrY for <ietf@ietfa.amsl.com>; Sat, 30 Jan 2016 12:52:04 -0800 (PST)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id B23F31A9089 for <ietf@ietf.org>; Sat, 30 Jan 2016 12:52:04 -0800 (PST)
Received: from SUBMAN.elandsys.com ([197.227.87.42]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id u0UKpIOQ023717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 30 Jan 2016 12:51:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1454187114; x=1454273514; bh=bY7Lg7vDMN47TVWylTspJAAf754ECzy0yJW+OIKvHi0=; h=Date:To:From:Subject:Cc; b=MReHCULZFakWY2Lgv8v/ki/yRQoXDQPBojS9YAzVCvqOtlJkE3AC9wobUgoSPwHGT 9/eSBHXVcrNe/vj8He4yjYYbFtT1bYPaXwtoYrtukKozCLP8ksf5pRzOZiel+6NCt6 ADcchZKw8ap4bHaOW4kCW62D4D+cVbmzY5BYiois=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1454187114; x=1454273514; i=@elandsys.com; bh=bY7Lg7vDMN47TVWylTspJAAf754ECzy0yJW+OIKvHi0=; h=Date:To:From:Subject:Cc; b=S1hPySoZcR3cua7oLvczn8YCWBmmjWzY/QigxYZSC1/LER8HTlNwJsrdOozhG0Osk QQ/JKZSDuvKYaqAyRCXF3JP4GyGX1qFB6dTLiBlxzoo66qko9rgRZncEsL1L0SFoW3 TS4BZOwLFq7d5horTLeqTMc8eOQp8AORDJI9qeAU=
Message-Id: <6.2.5.6.2.20160129225434.06db0028@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Sat, 30 Jan 2016 12:47:33 -0800
To: Brandon Williams <brandon.williams@akamai.com>, Mohamed Boucadair <mohamed.boucadair@orange.com>, Dan Wing <dwing@cisco.com>
From: S Moonesamy <sm+ietf@elandsys.com>
Subject: Review of draft-williams-exp-tcp-host-id-opt-07
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/TjS7DP3AJ3N_ZdRJbyxho0HrodM>
Cc: ietf@ietf.org, rfc-ise@rfc-editor.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 30 Jan 2016 20:52:06 -0000
Hello, I am reviewing draft-williams-exp-tcp-host-id-opt-07 for the Independent Stream. Overall, the document is well-written. I suggest reviewing the usage of the RFC 2119 key words as it makes the document look like a document about compliance. The intended status of the document is "Experimental". How long will this experiment last? The Abstract states that "proposals discussed in the IETF [which] have identified benefits to more distinctly identifying the hosts that are hidden behind a shared address/prefix sharing device or application-layer proxy". Is the sentence: (i) misleading (ii) one-sided (iii) any other alternative I'll choose (ii) as the sentence mentions benefits only. I did not see any mention of "IETF" in Section 1. Why is "IETF" mentioned in the Abstract? I looked at the proposals referenced in draft-williams-exp-tcp-host-id-opt-07 and they are from one of the authors of this draft and from the same companies. Isn't that self-citation? From Section 1 of the draft: "The purpose of this document is to describe a TCP HOST_ID option that is currently deployed on the Internet using the TCP experimental option codepoint including discussion of related design, deployment, and privacy considerations." I suggest focusing on the above if that is the purpose of the document. Could the authors please explain which of the bullet points in Section 2 of RFC 4846 is applicable to this document? "Specification of multiple option formats to serve the purpose of host identification increases the burden for potential implementers and presents interoperability challenges as well. This document defines a common TCP option format that supersedes all three of the above proposals." Does that mean that Akamai, Cisco and France Telecom have agreed on a common TCP option format and have implemented that? "The option defined in this document uses the TCP experimental option codepoint sharing mechanism defined in [RFC6994] and is intended to allow broad deployment of the mechanism on the public Internet." Is it the opinion of the authors of this draft that it isn't worthwhile to get IETF Consensus on a mechanism for broad deployment on the public Internet? In Section 1.2: "In particular, documentation of the mechanism is expected to provide opportunities for engagement with a broader range of both application and middleware implementations in order to develop a more complete picture of how well the option meets the use-case requirements." How does publication in the Independent Stream provide "opportunities for engagement"? In Section 4.1: "The HOST_ID option value MUST correlate to IP addresses and/or TCP port numbers that were changed by the inserting host/device (i.e., some of the IP address and/or port number bits are used to generate the HOST_ID)." The above is a requirement for "fingerprinting". The document then provides examples that satisfy the requirement. I suggest making the requirement clear instead of taking a "requirement by example" approach. In Section 6: "The content of the HOST_ID option SHOULD NOT be used for purposes that require a trust relationship between the sender and the receiver (e.g. billing and/or subscriber policy enforcement)." Why shouldn't the HOST_ID be used for purposes that require trust relationships? The sentence which follows the quoted text (see above) states that the "SHOULD" is a requirement. From what I understand, the paragraph is explaining the difference between "SHOULD" and "MUST". I got lost in reading the Security Considerations Section. Section 7 states that NAT "is sometimes specifically intended to provide anonymity". Are there any references for that? "The HOST_ID option MUST NOT provide client identification information that was not publicly visible in IP packets for the TCP flows processed by the inserting host, such as subscriber information linked to the IP address." Why is the above a RFC 2119 "MUST NOT"? Why is Section 8 relevant? This draft is not intended to be an IETF specification. "Fance" is misspelled. Regards, S. Moonesamy
- Review of draft-williams-exp-tcp-host-id-opt-07 S Moonesamy
- RE: Review of draft-williams-exp-tcp-host-id-opt-… mohamed.boucadair
- RE: Review of draft-williams-exp-tcp-host-id-opt-… Scharf, Michael (Nokia - DE)