[Gen-art] Gen-ART Last Call review of draft-ietf-dots-architecture-15
Paul Kyzivat <pkyzivat@alum.mit.edu> Thu, 23 January 2020 15:39 UTC
Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEBED12013B; Thu, 23 Jan 2020 07:39:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alum.mit.edu
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 9FhxYq3bA0bD; Thu, 23 Jan 2020 07:39:18 -0800 (PST)
Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10on2086.outbound.protection.outlook.com [40.107.93.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E24612007C; Thu, 23 Jan 2020 07:39:14 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=l7nOAmwX2CsjoHX6dX7ouSeW9ssszvKEnLWHXfZbYiC4foxm8/LabcLXR91Uj2a3AP/AKsoTQH05ikBpCHLcW+ydKgHrnYH6FMdwGXSLcPRZsS2dsPYmlqR2LsmMT9yiYcx06AImQXFDKZ9aVE9d0eMLYq59Zh73shibgEWk92ARt2ER4iFim9JM5GQhG6Ts8LRMC3fQBoTllqVAR4XHaPK1+GATbWYu2q7sUQMlyzMFZl1cqMgbs8Q9c+VzltijtQhhn68w1majZVj/wS1s2c7/i5GLxENWly70xCJ5akJLJ4qADjBhwbBKYu6Gl1NrJf2T+0TqZzd3jHp7hwUw6Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VsuJVZ3UZ+QaQx3g5HEk7ornLakJv44FVnPILnJh0o8=; b=dWxJKEdrWC3u2dSfoJ71VZybbZZzbONLHzGlPqHpF5XHOgxEMdowwy+7CoosDtgdrwDKw8Tfomb0NMfZKEnYb1E98x8Jli9VOHsIr7jRT0senGTwbEriK3xCyod29U+/iZf7B4VMqNYORWIZrsLHSPmkyGnW9oYb2rMuWfcDxc0atw+Mt4vA+dqxinqoCkOEnRYHUsFra1YbhclrJqmPPiB83eucOWKh6A1lqtE+uYsxWHLHwkMskEyfJqkPCnGx8+QDNXUwIrr6W+hfFvbi3aclV+ezRfpaAavUlDdVDMuc3jsXuI2F7Ecy6UcR/p/pHPKRqv2gV5mk9hgbq55g6Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=ietf.org smtp.mailfrom=alum.mit.edu; dmarc=bestguesspass action=none header.from=alum.mit.edu; dkim=none (message not signed); arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alum.mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VsuJVZ3UZ+QaQx3g5HEk7ornLakJv44FVnPILnJh0o8=; b=fCMITKNz2iqoZOzkFDVYAe7D44F4+KMksmeZuIptRtS1bUM1V0X2jIPLukXQvelAzN9qOfdei2UNYI/S3BKLxXz+vCgOjK5IbI/oOExEwt4Els1xNZpxv1xOs/MSwMFZW5TmDO/yd7smqo/1BzrjHbULj26A5GwmKuz3Hs3Cyd4=
Received: from DM3PR12CA0103.namprd12.prod.outlook.com (2603:10b6:0:55::23) by MWHPR12MB1759.namprd12.prod.outlook.com (2603:10b6:300:113::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2665.20; Thu, 23 Jan 2020 15:39:13 +0000
Received: from CY1NAM02FT047.eop-nam02.prod.protection.outlook.com (2a01:111:f400:7e45::204) by DM3PR12CA0103.outlook.office365.com (2603:10b6:0:55::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2665.19 via Frontend Transport; Thu, 23 Jan 2020 15:39:13 +0000
Authentication-Results: spf=pass (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=alum.mit.edu;
Received-SPF: Pass (protection.outlook.com: domain of alum.mit.edu designates 18.7.68.33 as permitted sender) receiver=protection.outlook.com; client-ip=18.7.68.33; helo=outgoing-alum.mit.edu;
Received: from outgoing-alum.mit.edu (18.7.68.33) by CY1NAM02FT047.mail.protection.outlook.com (10.152.74.177) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2665.18 via Frontend Transport; Thu, 23 Jan 2020 15:39:12 +0000
Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id 00NFdApW024226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 23 Jan 2020 10:39:11 -0500
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
To: draft-ietf-dots-architecture.all@ietf.org
Cc: General Area Review Team <gen-art@ietf.org>
Message-ID: <f659494f-a93b-48ab-e67a-3ff803673a1d@alum.mit.edu>
Date: Thu, 23 Jan 2020 10:39:10 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.4.1
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:18.7.68.33; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(396003)(39860400002)(136003)(376002)(346002)(189003)(199004)(7596002)(8676002)(316002)(786003)(336012)(956004)(2616005)(36906005)(186003)(356004)(246002)(478600001)(2906002)(6916009)(75432002)(26005)(26826003)(450100002)(8936002)(4326008)(86362001)(31686004)(5660300002)(70586007)(70206006)(31696002); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR12MB1759; H:outgoing-alum.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-alum.mit.edu; MX:1; A:1;
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: d08adb4f-f78d-4d83-73c0-08d7a01a6555
X-MS-TrafficTypeDiagnostic: MWHPR12MB1759:
X-Microsoft-Antispam-PRVS: <MWHPR12MB175982CE75189407098259D3F90F0@MWHPR12MB1759.namprd12.prod.outlook.com>
X-MS-Oob-TLC-OOBClassifiers: OLM:10000;
X-Forefront-PRVS: 029174C036
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: +9BoZpwmndgJkTVydjCAo2m298mTn60Qv0nwL973drn7JTRhDHC9Edahj1gmz1ZDkJgt6Ah+ZVBm8PBOet4sKFJsVAsbyybdJEi6CWo+VG2KInVKqB4Khia6O641yu/lBM5g26s/pElsppOVfBMs5rPyOwID5BIFi4hE8Im4k3bP62/Vioxo1PTReESiENQQot2kGFX5H5RVdivPQqLBvcwUv6QNbmWIWzYqRN/MfUUxdm1HMVvRSFjatF+MZ7BFKwihIzb/XA4M1v8T61O/brPdXkxrCBtguhcZwmqPR//iRe4MUdAEKHr/963JyazGqI1e/rmvKnbmk5fbbzt2+ki03c30FpkwmOJ1bz8Lg3WxCMScoYauucrgd+UzGVsMPYw/xLuBlZ5HyjKc0BuuiR0JOA+itYCpX+OLh2dBSJPbMg/ZIGEKSSshxjjYuaaESXMEENreIRWf49nd6jaoqgdqVutio4U+7t7/+iAKIU8=
X-OriginatorOrg: alum.mit.edu
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Jan 2020 15:39:12.4055 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: d08adb4f-f78d-4d83-73c0-08d7a01a6555
X-MS-Exchange-CrossTenant-Id: 3326b102-c043-408b-a990-b89e477d582f
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3326b102-c043-408b-a990-b89e477d582f; Ip=[18.7.68.33]; Helo=[outgoing-alum.mit.edu]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR12MB1759
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/XE3IOo3yHYIjcEOnkuXwagHNs2s>
Subject: [Gen-art] Gen-ART Last Call review of draft-ietf-dots-architecture-15
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Jan 2020 15:39:21 -0000
I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-dots-architecture-15 Reviewer: Paul Kyzivat Review Date: 2020-01-23 IETF LC End Date: 2020-01-27 IESG Telechat date: ? Summary: This draft is on the right track but has open issues, described in the review. General: This is a very well written document! Even though I lack any knowledge of the subject domain I was generally able to understand it. I had trouble classifying some of my issues below. I wanted to make them be questions. But in a review such as this it makes more sense to state them as issues of clarity in the text, since the reader should ideally not be left with questions. Issues: Major: 0 Minor: 5 Nits: 0 1) MINOR: Resource Ownership: The 2nd paragraph of section 2.2.2 stresses that it is important for a DOTS Server to verify that the DOTS Client owns the resources over which it is requesting mitigation. There seems to be quite a lot hiding behind that requirement. In particular, how is the server supposed to be in a position to do that verification? This seems to require that the server have access to ownership information. While that may be easy in some cases (e.g., when the server is operated by the ISP that assigned the resources to the client), in other cases it could be hard. I'd like to see more discussion of this. 2) MINOR: Scope and lifetime of sessions: Section 3.1 states that a session can be a signal channel session or a data channel session or both. I'm confused about the relationships here. If a session can consist of both, how are they related? Is there some state that ties them together? Can a channel survive the loss and reestablishment of a TCP connection? Or does the creation of a new connection create a new channel? What is the act that creates a new channel, and what destroys one? I'd like to see some more text explaining this. 3) MINOR: Feedback for recursive mitigation: Section 3.2.3 says: ... To maximize mitigation visibility to the DOTS client, however, the recursing domain SHOULD provide recursed mitigation feedback in signals reporting on mitigation status to the DOTS client. For example, the recursing domain's mitigator should incorporate into mitigation status messages available metrics such as dropped packet or byte counts from the recursed mitigation. This seems to imply that feedback from So to Cn is routed to Mn for merging with Mn's feedback. That seems to violate the architecture. Can the feedback from So be routed by Gn back to Cc? Can this be clarified? 4) MINOR: Security of recursive mitigation: The last paragraph of section 3.2.3 says: Deployment of recursive signaling may result in traffic redirection, examination and mitigation extending beyond the initial bilateral relationship between DOTS client and DOTS server. As such, client control over the network path of mitigated traffic may be reduced. DOTS client operators should be aware of any privacy concerns, and work with DOTS server operators employing recursive signaling to ensure shared sensitive material is suitably protected. This sounds like hand waving. Am I right in thinking this is talking about incorporating the details of recursion in the service level agreement? 5) MINOR: Normative references: I was surprised by the scarcity of normative references. I went looking for MUSTs referencing RFCs and found three: RFC8612 (DOTS Requirements), and RFCs 5389 and 7350 (STUN related). Please consider making these normative references.
- [Gen-art] Gen-ART Last Call review of draft-ietf-… Paul Kyzivat
- Re: [Gen-art] Gen-ART Last Call review of draft-i… tirumal reddy
- Re: [Gen-art] Gen-ART Last Call review of draft-i… tirumal reddy
- Re: [Gen-art] Gen-ART Last Call review of draft-i… Paul Kyzivat