From nobody Fri Mar 3 16:04:13 2017 Return-Path: X-Original-To: dhcwg@ietf.org Delivered-To: dhcwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C30DA1299AC; Fri, 3 Mar 2017 15:55:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.46.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148858534079.15846.12884103406490656991.idtracker@ietfa.amsl.com> Date: Fri, 03 Mar 2017 15:55:40 -0800 Archived-At: Cc: dhcwg@ietf.org Subject: [dhcwg] dhc - Requested session has been scheduled for IETF 98 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 23:55:41 -0000 Dear Tomek Mrugalski, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. dhc Session 1 (1:00:00) Thursday, Afternoon Session III 1740-1840 Room Name: Montreux 3 size: 80 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Dynamic Host Configuration Area Name: Internet Area Session Requester: Tomek Mrugalski Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 50 Conflicts to Avoid: First Priority: v6ops 6man softwire homenet Second Priority: dane sunset4 dnssd dnsop intarea People who must be present: Suresh Krishnan Bernie Volz Tomek Mrugalski Resources Requested: Meetecho support in room Special Requests: We got Friday afternoon slot in Seoul. We'd like to get a different one this time if possible. --------------------------------------------------------- From nobody Tue Mar 7 03:53:51 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9536D1293F0 for ; Tue, 7 Mar 2017 00:13:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 IwRxoluNgRD0 for ; Tue, 7 Mar 2017 00:13:04 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33DD7127A90 for ; Tue, 7 Mar 2017 00:13:04 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 3F9ABB82A93; Tue, 7 Mar 2017 00:13:03 -0800 (PST) To: jouni.nospam@gmail.com, teemu.savolainen@nokia.com, suresh.krishnan@ericsson.com, ot@cisco.com, suresh.krishnan@ericsson.com, terry.manderson@icann.org, volz@cisco.com, tomasz.mrugalski@gmail.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20170307081303.3F9ABB82A93@rfc-editor.org> Date: Tue, 7 Mar 2017 00:13:03 -0800 (PST) Archived-At: X-Mailman-Approved-At: Tue, 07 Mar 2017 03:53:47 -0800 Cc: dhcwg@ietf.org, text/plain@rfc-editor.org, rfc-editor@rfc-editor.orgContent-Type, sander@steffann.nl, charset=UTF-8@rfc-editor.org Subject: [dhcwg] [Editorial Errata Reported] RFC6603 (4958) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 08:13:05 -0000 The following errata report has been submitted for RFC6603, "Prefix Exclude Option for DHCPv6-based Prefix Delegation". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6603&eid=4958 -------------------------------------- Type: Editorial Reported by: Sander Steffann Section: 6.1 Original Text ------------- 6.1. Requesting Router The requesting router behavior regarding the use of the OPTION_PD_EXCLUDE option is mostly identical to the steps described in Section 5.1, with the difference being the use of a DHCPv6 Request instead of an Solicit message. The requesting router SHOULD include the OPTION_PD_EXCLUDE option code in the OPTION_ORO option for DHCPv6 messages as described in Section 22.7 of [RFC3315]. The requesting router SHOULD include the OPTION_PD_EXCLUDE option code in the OPTION_ORO option for DHCPv6 messages as described in Section 22.7 of [RFC3315]. Corrected Text -------------- 6.1. Requesting Router The requesting router behavior regarding the use of the OPTION_PD_EXCLUDE option is mostly identical to the steps described in Section 5.1, with the difference being the use of a DHCPv6 Request instead of an Solicit message. The requesting router SHOULD include the OPTION_PD_EXCLUDE option code in the OPTION_ORO option for DHCPv6 messages as described in Section 22.7 of [RFC3315]. Notes ----- Minor editorial bug: the last sentence of that paragraph was duplicated. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6603 (draft-ietf-dhc-pd-exclude-04) -------------------------------------- Title : Prefix Exclude Option for DHCPv6-based Prefix Delegation Publication Date : May 2012 Author(s) : J. Korhonen, Ed., T. Savolainen, S. Krishnan, O. Troan Category : PROPOSED STANDARD Source : Dynamic Host Configuration Area : Internet Stream : IETF Verifying Party : IESG From nobody Tue Mar 7 20:01:39 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE2CE129418; Tue, 7 Mar 2017 19:58:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.203 X-Spam-Level: X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 6jmxpZbQV3xL; Tue, 7 Mar 2017 19:58:19 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BB0D124281; Tue, 7 Mar 2017 19:58:19 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 86E10B81146; Tue, 7 Mar 2017 19:58:17 -0800 (PST) To: sander@steffann.nl, jouni.nospam@gmail.com, teemu.savolainen@nokia.com, suresh.krishnan@ericsson.com, ot@cisco.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20170308035817.86E10B81146@rfc-editor.org> Date: Tue, 7 Mar 2017 19:58:17 -0800 (PST) Archived-At: X-Mailman-Approved-At: Tue, 07 Mar 2017 20:01:38 -0800 Cc: text/plain@rfc-editor.org, charset=UTF-8@rfc-editor.org, rfc-editor@rfc-editor.orgContent-Type, iesg@ietf.org, dhcwg@ietf.org Subject: [dhcwg] [Errata Verified] RFC6603 (4958) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 03:58:21 -0000 The following errata report has been verified for RFC6603, "Prefix Exclude Option for DHCPv6-based Prefix Delegation". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6603&eid=4958 -------------------------------------- Status: Verified Type: Editorial Reported by: Sander Steffann Date Reported: 2017-03-07 Verified by: Suresh Krishnan (IESG) Section: 6.1 Original Text ------------- 6.1. Requesting Router The requesting router behavior regarding the use of the OPTION_PD_EXCLUDE option is mostly identical to the steps described in Section 5.1, with the difference being the use of a DHCPv6 Request instead of an Solicit message. The requesting router SHOULD include the OPTION_PD_EXCLUDE option code in the OPTION_ORO option for DHCPv6 messages as described in Section 22.7 of [RFC3315]. The requesting router SHOULD include the OPTION_PD_EXCLUDE option code in the OPTION_ORO option for DHCPv6 messages as described in Section 22.7 of [RFC3315]. Corrected Text -------------- 6.1. Requesting Router The requesting router behavior regarding the use of the OPTION_PD_EXCLUDE option is mostly identical to the steps described in Section 5.1, with the difference being the use of a DHCPv6 Request instead of an Solicit message. The requesting router SHOULD include the OPTION_PD_EXCLUDE option code in the OPTION_ORO option for DHCPv6 messages as described in Section 22.7 of [RFC3315]. Notes ----- Minor editorial bug: the last sentence of that paragraph was duplicated. -------------------------------------- RFC6603 (draft-ietf-dhc-pd-exclude-04) -------------------------------------- Title : Prefix Exclude Option for DHCPv6-based Prefix Delegation Publication Date : May 2012 Author(s) : J. Korhonen, Ed., T. Savolainen, S. Krishnan, O. Troan Category : PROPOSED STANDARD Source : Dynamic Host Configuration Area : Internet Stream : IETF Verifying Party : IESG From nobody Wed Mar 8 05:37:07 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C23E3129690; Wed, 8 Mar 2017 05:37:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 MFQXY_WrmYyc; Wed, 8 Mar 2017 05:37:04 -0800 (PST) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D06B712967A; Wed, 8 Mar 2017 05:37:03 -0800 (PST) Received: by mail-lf0-x235.google.com with SMTP id k202so14561310lfe.1; Wed, 08 Mar 2017 05:37:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:cc:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=ODg3Hww1kevWhCEqK1vi+SH1u6hGRWrIicHdUuNBcxM=; b=k3gpulX+z7iLsbEdlXM95tvrcw8rpi2cF+e0+uQN7ZcTYrhOQGDxo1QzPJ+dvK0kC6 HXlg+iocABd4y1CniSSOCpqVASlvr/pndyzyU/VgKuk6b2v0JIfAHRoMSUD1YKX4Vn45 yg4N3crvDTYl1qgo8UpMoOsRHWq8O3zLVBBj98PsE6at5P/jx4/S4XQ71nCTcDiul4hc d0prQdYmBQ7HnN4jJmtGZdVC6KuQeXElaBWKsGeTdGJRQNVieAvB2nkBWECI1il0D5G2 d7YJWVvlffAccEm0+DrXV3CyOGKYyo8EVl8Nysw8BWJJ9E3lyFNWqPIXv7kEfj4qsa2t mVpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=ODg3Hww1kevWhCEqK1vi+SH1u6hGRWrIicHdUuNBcxM=; b=FnjlVInOATRB6kk6mVF9moM3iHxQDbRTrsnB+Lt4pJWRRhBb8GUGF+K6cwh46WM6Wm +p6xky7RAEbvHLgkDXNfG8xyaMNwR0RshaEFJG8MpZs/zDZp/FBGwrtLLi3HUfL/v7IP gJQKSbHfYS1a1PMEin6XdH3CKHgZnLKoqLZEvQix4m89Rfr4Cv5TJKWGjmiZdX1FSUv4 PqFo33XO/6ey9/2GFxQgQNzErMy+3vKwiBUtq8100B0TaAa0DaoiGJugafGM0QQqWxMG 48yVoJr2S/VsTXnQkuV/0BR6897icEoGoJe76h440/edWMuNRKs0BfqE5KU6V2AC+VC5 kJOw== X-Gm-Message-State: AMke39nVpjuk7DMY5PHvMDzwE4ZZ4WpLbzalp4Nup6OyUC6Fwbs41BrEXeCavcomwHlx5A== X-Received: by 10.46.83.92 with SMTP id t28mr2202474ljd.70.1488980221770; Wed, 08 Mar 2017 05:37:01 -0800 (PST) Received: from [192.168.0.6] (109241207033.gdansk.vectranet.pl. [109.241.207.33]) by smtp.googlemail.com with ESMTPSA id a138sm631402lfb.2.2017.03.08.05.37.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Mar 2017 05:37:00 -0800 (PST) From: Tomek Mrugalski To: dhcwg Message-ID: Date: Wed, 8 Mar 2017 14:36:58 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: draft-ietf-dhc-sedhcpv6 authors Subject: [dhcwg] WGLC on draft-ietf-dhc-sedhcpv6-21 - Respond by March 29th X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 13:37:06 -0000 Hi, draft-ietf-dhc-sedhcpv6-21 describes a mechanism for using public key cryptography to provide end-to-end security between DHCPv6 clients and servers. The mechanism provides encryption in all cases, and can be used for authentication based on pre-sharing of authorized certificates. This draft has started in 2013, but the whole DHCPv6 security saga is much longer and begins in 2008. This draft was submitted to IESG in mid-2015. The guidance received was clear that substantial changes are needed. As a result, "encrypt everywhere, authenticate if you can" approach was used. Authors believe this draft to be ready for working group last call. Please send your substantial comments to the mailing list and express your opinion whether this draft is ready for publication. Feel free to send nitpicks and minor corrections to the authors directly. This is a complex draft, so the chairs believe 3 weeks WGLC is in order. Please send your comments no later than March 29th. Bernie and I will determine consensus and will discuss during Chicago meeting as needed. To initiate the discussion, I have two related questions. The chairs would love to hear your opinions on those. 1. The "encrypt everywhere" paradigm means that in deployments that do snooping on relay will break down. To solve this problem, we need a assignment notification mechanism, similar to the one described in draft-ietf-dhc-dhcpv6-agentopt-delegate-04. That draft expired many years ago. This matter was discussed in Seoul and the minutes describe the conclusion as: The discussion gravitated towards not resurrecting until the sedhcpv6 I-D progresses further. We will reevaluate this once sedhcpv6 is done. Do you want the WG to resurrect agentopt-delegate a) now, b) when sedhcpv6 is sent to IESG or c) when sedhcpv6 is published as RFC? d) we need a completely new draft and I'm volunteering to work on it. 2. One of the authors suggested that this protocol is quite complex and having a feedback from an implementation (or ideally two interoperating) would be very important and would likely result in some changes to the draft. It's probably too late for Chicago, but we can organize a sedhcpv6 hackathon in Prague. Two likely implementations would be WIDE and Kea, as those two are open source and have an old version of the draft partially implemented. Do you think such a hackathon would be useful? Are you willing to participate? Title: Secure DHCPv6 Authors: L. Li, S. Jiang, Y.Cui, T.Jinmei, T.Lemon, D.Zhang Filename: draft-ietf-dhc-sedhcpv6-21 Pages: 31 Date: 2017-02-21 Link: https://datatracker.ietf.org/doc/draft-ietf-dhc-sedhcpv6/ Responses by March 29th are appreciated. Thanks, Bernie and Tomek From nobody Wed Mar 8 09:15:17 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB75E129513; Wed, 8 Mar 2017 09:15:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 hiPoaXNiRWGe; Wed, 8 Mar 2017 09:15:15 -0800 (PST) Received: from mail-lf0-x243.google.com (mail-lf0-x243.google.com [IPv6:2a00:1450:4010:c07::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EDC3129440; Wed, 8 Mar 2017 09:15:14 -0800 (PST) Received: by mail-lf0-x243.google.com with SMTP id r36so2844569lfi.0; Wed, 08 Mar 2017 09:15:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=YgTVRvDk4KCvriQhbQzeIKV43AsSMsLMIz5DoE996cw=; b=KKgbGdIuRSE0oki80WD11E6DP1F5PtZm/GB/Of5Gh3ILZjf8PhSGqmBosik0TGWj11 ojHvDXoXL+lp1Q/ZG7rtmc8NXxroh+Sah80GtlyTRBVwsfnksjD5fu3HySoP/1v1H6Yd NynoXuHWDhEUiTztfMxJu8hcJAQ5NvEPDUtbit8HLX2lz3QSgvTwcY5CNhB93ba2sWHU bqmLRu+U6xSc7UqBr9pkwW/m71Mfl/kc9z1slmLMxP1njPubmlzfKl5qVdF6KuDXo7Sf 6UMvBCyuUgz2d9C9s6AjK9S0OUIZQlMB079IuCy7+ECbUNxS1YqkiE1d7nRSHfA+6AGG zybw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=YgTVRvDk4KCvriQhbQzeIKV43AsSMsLMIz5DoE996cw=; b=VFsOgEUAcfC5blZLfAf8Ob6CQ71O1yv38fTwMRE7Uoku33X2cD/z2gnN/5amKj4DoZ crfD4k8nvNt+sZyR/eUQuquSSKKvlFeA24RjqUoNNiRHjax9F1yGHwIMSlH23Wx37PTL yqvtPoYSl3/7bDPq87F8jpHQi+hjWDWyTyWRIc9lmPmMFy5icHB4THngMNQ3/krqG7Jx jqUL/tdOFAFtcuqeVTmB6mZuj8yhGy76HH8A3pJUzdykx9pA3qwy/ZJReLtjIiy1TfVy JRU17MzE+NFf8a3NgsMBnwR5pN+50m9DZfKs1u7iomotSi8WLb+e6PcKBahuVkhB339L YmTg== X-Gm-Message-State: AMke39maKmhTbGvAgte2y1QtQNAc8wsXEOaEo6D/QHRUk328tHzHUS5kRPWma/RCI+SOHA== X-Received: by 10.25.43.8 with SMTP id r8mr1778689lfr.41.1488993313026; Wed, 08 Mar 2017 09:15:13 -0800 (PST) Received: from [192.168.0.6] (109241207033.gdansk.vectranet.pl. [109.241.207.33]) by smtp.googlemail.com with ESMTPSA id h62sm720104lfh.62.2017.03.08.09.15.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Mar 2017 09:15:12 -0800 (PST) To: Ian Farrer References: <305F0B31-467B-4138-882D-8617764499A8@gmx.com> From: Tomek Mrugalski Message-ID: Date: Wed, 8 Mar 2017 18:15:10 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <305F0B31-467B-4138-882D-8617764499A8@gmx.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: Softwires-wg , dhcwg , draft-fsc-softwire-dhcp4o6-saddr-opt@ietf.org Subject: Re: [dhcwg] [Softwires] Adoption call for draft-fsc-softwire-dhcp4o6-saddr-opt-07 - Respond by Mar 8th, 2017 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 17:15:16 -0000 With my dhc chair hat off, I support adoption of this draft in dhc. Tomek From nobody Thu Mar 9 02:07:34 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3699912711D for ; Thu, 9 Mar 2017 02:07:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es 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 RdMRPUAAVW-s for ; Thu, 9 Mar 2017 02:07:31 -0800 (PST) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4176129445 for ; Thu, 9 Mar 2017 02:07:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1489054045; x=1489658845; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:CC:Message-ID: Thread-Topic:References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=7xMkTuVdQTSm8iOZpSYiGhF34 OcHcdWCklqICLyIEHk=; b=OzV3oD0eKz1OsI2FT5mgmxlHADDJTBwCuLE5vOHkN SRfaW8wdm8dfrVn9HlEv3bbZdlf9XV+gyhb/BcO6xingM9cdiLG1wCtQPulEvbap nSunSreoXbrgCN2MY+FmqnhY7nr8tAp1cnioIkGFvkrlNGY3KcyERGLaEmIkQPa7 CM= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=DY9FtXklbs6nA+NZBiMW1HXgWuo+JGnEaC4aUieEZzMl4IQnxUkgCOBVFJzY Xns6tjOdmU6Qd03oFb2YMyLB6TM5sTbbeHanSsmvHk8dKdfTai3eKDlPa fjDIk82FQTD3Nqjdk/E2H0TbYTWQrHRFMeKWYRTSUpFqVcqwbaZQkk=; X-MDAV-Processed: mail.consulintel.es, Thu, 09 Mar 2017 11:07:25 +0100 X-Spam-Processed: mail.consulintel.es, Thu, 09 Mar 2017 11:07:10 +0100 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005381007.msg for ; Thu, 09 Mar 2017 11:07:10 +0100 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170309:md50005381007::pP4c8+EBEYtxLQ+K:00006FAL X-Return-Path: prvs=12416e7968=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: dhcwg@ietf.org User-Agent: Microsoft-MacOutlook/f.1f.0.170216 Date: Thu, 09 Mar 2017 11:07:08 +0100 From: JORDI PALET MARTINEZ To: , Ian Farrer Message-ID: <10E18CD5-9A60-4BAF-ADD2-88231D516B35@consulintel.es> Thread-Topic: [Softwires] Adoption call for draft-fsc-softwire-dhcp4o6-saddr-opt-07 - Respond by Mar 8th, 2017 References: <305F0B31-467B-4138-882D-8617764499A8@gmx.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Cc: Softwires-wg , dhcwg , draft-fsc-softwire-dhcp4o6-saddr-opt@ietf.org Subject: Re: [dhcwg] [Softwires] Adoption call for draft-fsc-softwire-dhcp4o6-saddr-opt-07 - Respond by Mar 8th, 2017 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: jordi.palet@consulintel.es List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 10:07:33 -0000 +1 Saludos, Jordi =20 -----Mensaje original----- De: Softwires en nombre de Tomek Mrugalski Responder a: Fecha: mi=C3=A9rcoles, 8 de marzo de 2017, 18:15 Para: Ian Farrer CC: Softwires-wg , dhcwg , Asunto: Re: [Softwires] Adoption call for draft-fsc-softwire-dhcp4o6-saddr-= opt-07 - Respond by Mar 8th, 2017 With my dhc chair hat off, I support adoption of this draft in dhc. =20 Tomek =20 _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Thu Mar 9 05:15:09 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B646C1295E2; Thu, 9 Mar 2017 05:15:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 xNjrPkeeKQZk; Thu, 9 Mar 2017 05:15:06 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E4CB1295BD; Thu, 9 Mar 2017 05:15:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1603; q=dns/txt; s=iport; t=1489065306; x=1490274906; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=dqz3P8NpkJ2WAhtj6GYThkluTzUDU9wBMqb+w3OdHIM=; b=eTIttB5p+xZ4BgIAPUtHmbkqZLm8Zo4IABsGUBmwoih0DwgEVAb41VqB d3hemn2NAGW+6ieieq6MhKHpwe3nnAGmLEpsj7Vg+O+HwWqLJaSZKxDXt gAwFTWnF4pi+A0OWGs8AtPUZ7827jxZFdoSkGAPyUO9tKqnrgQ/w6Y6Td o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ATAQC5VMFY/5hdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1FhgQoHjWWRTpU4gg4fC4V0AgICgi0/GAECAQEBAQEBAWsohRU?= =?us-ascii?q?BAQEBAwEBGwoTMQMLDAQCAQgRAwEBAR8JBycLFAkIAgQOBQiJeA6yGjqKcAEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAR2LPYE8iH0FnDkBhnWLOYIEU4RQigKTPgEfOD5?= =?us-ascii?q?FVhUYJ4UKgUp1iR6BDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.36,268,1486425600"; d="scan'208";a="395508825" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Mar 2017 13:15:05 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v29DF5fT031754 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 9 Mar 2017 13:15:05 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 9 Mar 2017 07:15:04 -0600 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1210.000; Thu, 9 Mar 2017 07:15:04 -0600 From: "Bernie Volz (volz)" To: dhcwg Thread-Topic: [dhcwg] Adoption call for draft-fsc-softwire-dhcp4o6-saddr-opt-07 - Respond by Mar 8th, 2017 Thread-Index: AQHSjTJgTzD0DDvvFUWkJqPj+VlWC6GMkyHg Date: Thu, 9 Mar 2017 13:15:04 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.241.9] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Softwires-wg , "draft-fsc-softwire-dhcp4o6-saddr-opt@ietf.org" Subject: Re: [dhcwg] Adoption call for draft-fsc-softwire-dhcp4o6-saddr-opt-07 - Respond by Mar 8th, 2017 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 13:15:07 -0000 Hi: The DHC WG will adopt this document. There was good support for it, and no = one opposed the adoption. The authors are requested to published the DHC WG -00 version of the draft = (with the minor fix to reference the correct RFC (RFC7568 -> RFC7598) as po= inted out by Jordi. - Tomek & Bernie -----Original Message----- From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Tomek Mrugalski Sent: Wednesday, February 22, 2017 12:38 PM To: dhcwg Cc: Softwires-wg ; draft-fsc-softwire-dhcp4o6-saddr-opt= @ietf.org Subject: [dhcwg] Adoption call for draft-fsc-softwire-dhcp4o6-saddr-opt-07 = - Respond by Mar 8th, 2017 Hi, This message initiates a two weeks long DHC WG adoption call on: Title: DHCPv4 over DHCPv6 Source Address Option Pages: 9 Date: 2017-02-01 Document: draft-fsc-softwire-dhcp4o6-saddr-opt-07 Link: tools.ietf.org/html/draft-fsc-softwire-dhcp4o6-saddr-opt-07 This document initially started as work intended to be adopted in Softwires= , but after a discussion with chairs, responsible AD (Suresh) and presentin= g this work in DHC, the conclusion is to aim for DHC adoption, not Softwire= s. Therefore this is a DHC adoption call. This message is cross-posted to Softwires to let Softwire experts weigh in = their opinion. Please be sure to post your comments to DHC list, though. Co= mments sent by end of March 8th, 2017 are much appreciated. Bernie & Tomek _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From nobody Thu Mar 9 07:31:58 2017 Return-Path: X-Original-To: dhcwg@ietf.org Delivered-To: dhcwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 964C21294A5; Thu, 9 Mar 2017 07:31:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148907351654.5707.2654707298734710602@ietfa.amsl.com> Date: Thu, 09 Mar 2017 07:31:56 -0800 Archived-At: Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcp4o6-saddr-opt-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 15:31:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration of the IETF. Title : DHCPv4 over DHCPv6 Source Address Option Authors : Ian Farrer Qi Sun Yong Cui Linhui Sun Filename : draft-ietf-dhc-dhcp4o6-saddr-opt-00.txt Pages : 9 Date : 2017-03-09 Abstract: DHCPv4 over DHCPv6 [RFC7341] describes a mechanism for dynamically configuring IPv4 over an IPv6-only network. For DHCPv4 over DHCPv6 to function with some IPv4-over-IPv6 softwire mechanisms and deployment scenarios, the operator must learn the /128 IPv6 address that the client will use as the source of IPv4-in-IPv6 tunnel. This address, in conjunction with the IPv4 address and the Port Set ID allocated to the DHCP 4o6 client are used to create a binding table entry in the softwire tunnel concentrator. This memo defines two DHCPv6 options used to communicate the source tunnel IPv6 address between the DHCP 4o6 client and server. It also describes a method for configuring the client with the IPv6 address of the border router so that the softwire can be established. It is designed to work in conjunction with the IPv4 address allocation process. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcp4o6-saddr-opt/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dhc-dhcp4o6-saddr-opt-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Mar 10 11:48:09 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63BEB1299A8; Fri, 10 Mar 2017 11:48:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 YwL3GjG7Z4a4; Fri, 10 Mar 2017 11:48:04 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2137D129998; Fri, 10 Mar 2017 11:48:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1968; q=dns/txt; s=iport; t=1489175284; x=1490384884; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=gzUWss6CE5URYu4szaCvcIT1Yt/K4iysMScRsb4NDwg=; b=g8MutaxHEmPejWfyr0X/KUHyGs3dmupdROdGS1z1801QW4aFz0sp1+YW TMFt2x6+vHl3ql7pKH8l3uVdmc1wr8hkqaHpw0YgDc0G4JUo1wzMe/Ruy QPQGKWDy+Ft33zM7O7CZTqCh6zpZ29U53OBg4o8IBUHFicx5QoyFAAaT0 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AmAgAUAsNY/4ENJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1FhgQoHg1mKDpExH4gNjSuCDh8LhXgCGoInPxgBAgEBAQEBAQF?= =?us-ascii?q?rKIUVAQEBAQIBAQEhETkBCwULAgEIGAICJgICAh8GCxUQAgQBDQWJaAMNCA6xb?= =?us-ascii?q?YImhzgNgyMBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYELh0gIgmKCUYIDF4JvLoI?= =?us-ascii?q?xAQScAjoBjgyEK4F7iHmGMIpUiGsBHziBA1cVPxEBhkN1AYkMgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.36,142,1486425600"; d="scan'208";a="396474646" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Mar 2017 19:48:03 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v2AJm3LH023328 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 10 Mar 2017 19:48:03 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 10 Mar 2017 13:48:02 -0600 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1210.000; Fri, 10 Mar 2017 13:48:02 -0600 From: "Bernie Volz (volz)" To: Brian E Carpenter , Naveen Kottapalli , "sthaug@nethelp.no" Thread-Topic: [v6ops] DHCPv6 subscriber learning default gateway Thread-Index: AQHSmWR8wotauR0xoEuRbV4A/hR6rqGOCqaA//+mxQiAASoggP//sOMA Date: Fri, 10 Mar 2017 19:48:02 +0000 Message-ID: References: <20170310.080331.41692443.sthaug@nethelp.no> <268482ea-d5c1-ba1c-4c89-e0abdc709c96@gmail.com> In-Reply-To: <268482ea-d5c1-ba1c-4c89-e0abdc709c96@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1f.0.170216 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.1.196] Content-Type: text/plain; charset="utf-8" Content-ID: <867912100F86EC459B6564F51FC5F34C@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "dhcwg@ietf.org" , v6ops list , 6man WG Subject: Re: [dhcwg] [v6ops] DHCPv6 subscriber learning default gateway X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 19:48:05 -0000 PiAgICBZb3UgYXJlIG5vdCB0aGUgb25seSBwZXJzb24gd2hvIHRoaW5rcyB0aGlzIGlzIGEgZ2Fw IGluIERIQ1B2Ni4NCg0KQXMgYSBESEMgV0cgY28tY2hhaXIsIGlmIHY2b3BzIGFuZCA2bWFuIGJl bGlldmUgdGhpcyBJUyBzb21ldGhpbmcgdGhhdCBzaG91bGQgYmUgYWRkcmVzc2VkIGluIHRoZSBE SENQdjYgcHJvdG9jb2wsIHdlIGNhbiBjZXJ0YWluIGRpc2N1c3Mgd2l0aCBvdXIgQUQgdG8gdGFr ZSBpdCBvbi4gSW4gdGhlIHBhc3QsIGl0IHNlZW1lZCB0aGUgdmlldyBmcm9tIHRoZXNlIFdHcyAo cGVyaGFwcyBtb3N0bHkgNm1hbikgd2FzIHRvIGxlYXZlIGl0IGZvciBSQSB0byBjb252ZXkgdGhl IGRlZmF1bHQgZ2F0ZXdheS4NCg0KLSBCZXJuaWUNCg0KT24gMy8xMC8xNywgMjozMSBQTSwgIkJy aWFuIEUgQ2FycGVudGVyIiA8YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tPiB3cm90ZToNCg0K ICAgIE9uIDEwLzAzLzIwMTcgMjA6NDMsIE5hdmVlbiBLb3R0YXBhbGxpIHdyb3RlOg0KICAgID4g K3Y2b3BzLCA2bWFuDQogICAgPiANCiAgICA+IFlvdXJzLA0KICAgID4gTmF2ZWVuLg0KICAgID4g DQogICAgPiBPbiAxMCBNYXJjaCAyMDE3IGF0IDEyOjQxLCBOYXZlZW4gS290dGFwYWxsaSA8bmF2 ZWVuLnNhcm1hQGdtYWlsLmNvbT4gd3JvdGU6DQogICAgPiANCiAgICA+PiBPa2F5LiAgQ2FuIHlv dSB0ZWxsIHdoaWNoIHBhcmFtZXRlcnMgb2YgUkEgd2lsbCBjb252ZXkgdGhlIGRlZmF1bHQgZ2F0 ZXdheQ0KICAgID4+IGFkZHJlc3M/ICANCiAgICANCiAgICBZb3UgbmVlZCB0byByZWFkIFJGQzQ4 NjEgdG8gdW5kZXJzdGFuZCB0aGUgcmVsZXZhbnQgZGV0YWlscyBvZiBSQS4NCiAgICANCiAgICA+ PiBBbHNvLCBjYW4geW91IHBvaW50IG1lIHRvIHRoZSBkb2N1bWVudCB3aGVyZSBpdCBpcyBtZW50 aW9uZWQgdGhhdA0KICAgID4+IGEgREhDUHY2IHN1YnNjcmliZXIgaGFzIHRvIHVzZSBSUy1SQSBm b3IgcmVzb2x2aW5nIGdhdGV3YXkgYWRkcmVzcz8NCiAgICANCiAgICBTZWN0aW9uIDcuMi4yIG9m IFJGQzY0MzQgZXhwbGFpbnMgdGhpcyAoYnV0IHRoZSB3b3JkaW5nIGNvdWxkIGJlIGNsZWFyZXIs IHBlcmhhcHMpLg0KICAgIFRoZSBiYXNpYyBwb2ludCBpcyB0aGF0IFJGQzQ4NjEgaXMgZWZmZWN0 aXZlbHkgbWFuZGF0b3J5IGFuZCBESENQdjYgaXMgb3B0aW9uYWwuDQogICAgDQogICAgWW91IGFy ZSBub3QgdGhlIG9ubHkgcGVyc29uIHdobyB0aGlua3MgdGhpcyBpcyBhIGdhcCBpbiBESENQdjYu DQogICAgDQogICAgICAgQnJpYW4NCiAgICANCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KICAgIHY2b3BzIG1haWxpbmcgbGlzdA0KICAgIHY2b3Bz QGlldGYub3JnDQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9w cw0KICAgIA0KDQo= From nobody Fri Mar 10 13:11:42 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 402BF1293F3; Fri, 10 Mar 2017 13:11:32 -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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org 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 IvTqChB2-6SL; Fri, 10 Mar 2017 13:11:31 -0800 (PST) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id 17F7A120725; Fri, 10 Mar 2017 13:11:31 -0800 (PST) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 10 Mar 2017 21:11:29 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 86A53D788A; Fri, 10 Mar 2017 13:11:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=bAlVRitQbnu/eQ79+C/1laNCg94=; b= N8+xPrz0Ad70jCsNyNGNVOVxLjGHjFh/QOoL3ESIvf/beDVzZdjrYl9ck0+FdxN9 p5vxSR7+DLHV5u0NCNCmNF7fPMTywtk4Yg4cmYxbsmWJbCT1lzd3g8StiDcJ+cVp Xt1wSnv5QGITPtf+Sq24UwlS0yTYOOdr8xmlqvUkXYU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=a8UCjgNnldQGh8mZrnJWX2K gYic/2qIDyfqE7bmemTrWWDvrCMaXKIjAGkw5BarUKGTnhl22+ix4CE42qYmHyNo L5OzYhzE5qGmXyCBlBY9loA5X1tdnUr1jOZk1PzB61kbqxU/XCAQop0Qgp8wpBfl ziwyk0KKqBYiwWhGzCsA= Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 5AF2ED788D; Fri, 10 Mar 2017 13:11:29 -0800 (PST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id E3E669B1928C; Fri, 10 Mar 2017 22:11:27 +0100 (CET) From: otroan@employees.org Message-Id: <3F64E796-5126-4405-8A81-AD9BAB6B7838@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_F94854D2-09AA-43B9-82C0-6A1D6CE5B608"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Fri, 10 Mar 2017 22:11:27 +0100 In-Reply-To: To: "Bernie Volz (volz)" References: <20170310.080331.41692443.sthaug@nethelp.no> <268482ea-d5c1-ba1c-4c89-e0abdc709c96@gmail.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: v6ops list , 6man WG , Naveen Kottapalli , "dhcwg@ietf.org" , Brian E Carpenter Subject: Re: [dhcwg] [v6ops] DHCPv6 subscriber learning default gateway X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 21:11:32 -0000 --Apple-Mail=_F94854D2-09AA-43B9-82C0-6A1D6CE5B608 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >> You are not the only person who thinks this is a gap in DHCPv6. >=20 > As a DHC WG co-chair, if v6ops and 6man believe this IS something that = should be addressed in the DHCPv6 protocol, we can certain discuss with = our AD to take it on. In the past, it seemed the view from these WGs = (perhaps mostly 6man) was to leave it for RA to convey the default = gateway. if the only tool you have is a hammer... stop beating a dead horse. it hurts. Ole --Apple-Mail=_F94854D2-09AA-43B9-82C0-6A1D6CE5B608 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYwxZ/AAoJEL7aWKiYQt9222AP/AqLQWnD2pFlPhc8X/jbE3/E ovYm/QHVvgZNRQUB47IMP1Xj2q1jsVVTrXCO+KpEZ3iyzUpa+cfyphGJ4CDBL3hf 7jzEl+tZu8TqOSJQ7dmjIr29NAlfJxcni/vtZ47qB+NXIEHgsp8RVGXCXHhYdPlW 7bGk//aokbyxE8rSYzdkJD6j5W6EqhZe65/9YQvwiu2P2SZt79BkB79ea7irj0Sa Qhd+xJdjg+geRTEaPAQq8eD7BE31c8/dcrSsDt8g3SZFrBVn+oRz/Jlv0hf+sRLR gPeDtF6pGYjVjkxmWFTIZ2hxtMFtQCUI29gM7wKDc8PwMV+yhIPZmfZ5MYOHgfTJ jfhgeTaApnSGK1V+Ee9zgdtOkJYA5heTbhf73QtK0/L2pI1aWj04AmNLC7yNUuQI k+Fjv0AdjkLVZTibOtI3laBIgUD9swdOnhyc3GbKzSnozp/oVkxgBxkbtmbsXX1J gX9Y+M3YILIaXs27RqXNlWmtgni6KMWNIi09T0K8bp87wjdqIQlmxHpI9IilSOZR 7gJ6bY5wyuf9QBmsdT/ectgBlTrQjZaV0ds2Muqn2Qgjiqb3kuuLfixMeM5kv5Xt WgViSP1K2dFkUwiwjdr1X85kjxrh7fMaXK1+LzVW2RsiblWd0PkTFLgDqB4zsGTg 7bkVd14txlUsl3EY2PJ+ =UTOM -----END PGP SIGNATURE----- --Apple-Mail=_F94854D2-09AA-43B9-82C0-6A1D6CE5B608-- From nobody Sun Mar 12 19:35:38 2017 Return-Path: X-Original-To: dhcwg@ietf.org Delivered-To: dhcwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C88B7129436; Sun, 12 Mar 2017 19:35:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148937253680.24730.31384101453494606@ietfa.amsl.com> Date: Sun, 12 Mar 2017 19:35:36 -0700 Archived-At: Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis-07.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 02:35:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration of the IETF. Title : Dynamic Host Configuration Protocol for IPv6 (DHCPv6) bis Authors : Tomek Mrugalski Marcin Siodelski Bernie Volz Andrew Yourtchenko Michael C. Richardson Sheng Jiang Ted Lemon Timothy Winters Filename : draft-ietf-dhc-rfc3315bis-07.txt Pages : 140 Date : 2017-03-12 Abstract: This document describes the Dynamic Host Configuration Protocol for IPv6 (DHCPv6): an extensible mechanism for configuring nodes with network configuration parameters, IP addresses, and prefixes. Parameters can be provided statelessly, or in combination with stateful assignment of one or more IPv6 addresses and/or IPv6 prefixes. DHCPv6 can operate either in place of or in addition to stateless address autoconfiguration (SLAAC). This document updates the text from RFC3315, the original DHCPv6 specification, and incorporates prefix delegation (RFC3633), stateless DHCPv6 (RFC3736), an option to specify an upper bound for how long a client should wait before refreshing information (RFC4242), a mechanism for throttling DHCPv6 clients when DHCPv6 service is not available (RFC7083), and clarifies the interactions between modes of operation (RFC7550). As such, this document obsoletes RFC3315, RFC3633, RFC3736, RFC4242, RFC7083, and RFC7550. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-rfc3315bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dhc-rfc3315bis-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-rfc3315bis-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Mar 12 19:45:34 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 141671294AA for ; Sun, 12 Mar 2017 19:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 NTxibRKVBNjD for ; Sun, 12 Mar 2017 19:45:31 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 779A51294A1 for ; Sun, 12 Mar 2017 19:45:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4078; q=dns/txt; s=iport; t=1489373131; x=1490582731; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=78lnY9Peo+svYCK1km2ahK4PdSPUYWs5FcB0dSEtXPs=; b=DXFZuotyje4oPhsmSeQ8Wv2T5v37JN9ogOicWN2zzVp6be3XyxYhjGD4 kQPaCh/jKTDIO6r/w+qigwZJeHk093yxw/lgWIcWX64VbK59WzjNF+2iF N2WWOawdKolq+PcXOOtfoGnpKI7asbr7bPnpkblfIlUefb1sDZR1NKQSs U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B7AQARB8ZY/4kNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1FhgQoHg1mKDpFPiA6NLYIOKoV4AhqCJz8YAQIBAQEBAQEBax0?= =?us-ascii?q?LhRUBAQIDIxFDDgQCARkEAQEDAiMDAgICHxEUAQgIAgQTCIlgAxUOsAaCJocsD?= =?us-ascii?q?YMfAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYELijKCUUaBRBAhAoJMgl8Fj1uMLDo?= =?us-ascii?q?BhnWHF4QjggRUhFGKBYpViG0BHziBBFgVGCmEVx2BY3UBiGCBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.36,156,1486425600"; d="scan'208";a="393965611" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Mar 2017 02:44:59 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v2D2iSe0005559 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 13 Mar 2017 02:44:29 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 12 Mar 2017 21:44:28 -0500 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1210.000; Sun, 12 Mar 2017 21:44:28 -0500 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: New Version Notification for draft-ietf-dhc-rfc3315bis-07.txt Thread-Index: AQHSm6KABJ2UGf+n6EyjEwRCamnCmqGSDdlQ Date: Mon, 13 Mar 2017 02:44:28 +0000 Message-ID: References: <148937253697.24730.8260647327870312034.idtracker@ietfa.amsl.com> In-Reply-To: <148937253697.24730.8260647327870312034.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.1.196] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [dhcwg] New Version Notification for draft-ietf-dhc-rfc3315bis-07.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 02:45:33 -0000 VGhlIERIQ1B2NmJpcyB0ZWFtIGhhcyBwdWJsaXNoZWQgYSBuZXcgdmVyc2lvbiBvZiBkcmFmdC1p ZXRmLWRoYy1yZmMzMzE1YmlzLg0KDQpTYWRseSwgd2UgZGlkIG5vdCBmaW5pc2ggQUxMIG9mIHRo ZSBpdGVtcyBpbiB0aGUgbGlzdCBvZiBhcHByb3hpbWF0ZWx5IDMwMCBpc3N1ZXMgcmFpc2VkIGxh c3Qgc3VtbWVyIGR1cmluZyB0aGUgV0dMQyBmb3IgdGhlIC0wNSBkcmFmdC4gVGhlcmUgYXJlIGFi b3V0IGEgZG96ZW4gaXRlbXMgcmVtYWluaW5nIGFuZCB3ZSBob3BlIHRvIHJlc29sdmUgdGhlbSBz b29uLg0KDQpCdXQgcGxlYXNlIHRha2UgYSBsb29rIGF0IHRoZSBjaGFuZ2VzIGFuZCBsZXQgdXMg a25vdyBvZiBhbnkgZXJyb3JzIG9yIGNvbW1lbnRzIHlvdSBtaWdodCBoYXZlIHJlZ2FyZGluZyB0 aGVtLCBzbyB3ZSBjYW4gYWRkcmVzcyB0aGVzZSBpbiB0aGUgbmV4dCByZXZpc2lvbi4NCg0KLSBC ZXJuaWUgKG9uIGJlaGFsZiBvZiB0aGUgREhDUHY2YmlzIHRlYW0pDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogU3VuZGF5LCBNYXJjaCAxMiwgMjAxNyAxMDoz NiBQTQ0KVG86IEFuZHJldyBZb3VydGNoZW5rbyAoYXlvdXJ0Y2gpIDxheW91cnRjaEBjaXNjby5j b20+OyBNYXJjaW4gU2lvZGVsc2tpIDxtc2lvZGVsc2tpQGdtYWlsLmNvbT47IEJlcm5pZSBWb2x6 ICh2b2x6KSA8dm9sekBjaXNjby5jb20+OyBUaW1vdGh5IFdpbnRlcnMgPHR3aW50ZXJzQGlvbC51 bmguZWR1PjsgZGhjLWNoYWlyc0BpZXRmLm9yZzsgTWljaGFlbCBSaWNoYXJkc29uIDxtY3IraWV0 ZkBzYW5kZWxtYW4uY2E+OyBUZWQgTGVtb24gPHRlZC5sZW1vbkBub21pbnVtLmNvbT47IFRvbWVr IE1ydWdhbHNraSA8dG9tYXN6Lm1ydWdhbHNraUBnbWFpbC5jb20+OyBTaGVuZyBKaWFuZyA8amlh bmdzaGVuZ0BodWF3ZWkuY29tPjsgTWljaGFlbCBDLiBSaWNoYXJkc29uIDxtY3IraWV0ZkBzYW5k ZWxtYW4uY2E+OyBUZWQgTGVtb24gPFRlZC5MZW1vbkBub21pbnVtLmNvbT4NClN1YmplY3Q6IE5l dyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi1kaGMtcmZjMzMxNWJpcy0wNy50 eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtaWV0Zi1kaGMtcmZjMzMxNWJpcy0w Ny50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgQmVybmllIFZvbHogYW5k IHBvc3RlZCB0byB0aGUNCklFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0LWlldGYtZGhj LXJmYzMzMTViaXMNClJldmlzaW9uOgkwNw0KVGl0bGU6CQlEeW5hbWljIEhvc3QgQ29uZmlndXJh dGlvbiBQcm90b2NvbCBmb3IgSVB2NiAoREhDUHY2KSBiaXMNCkRvY3VtZW50IGRhdGU6CTIwMTct MDMtMTINCkdyb3VwOgkJZGhjDQpQYWdlczoJCTE0MA0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8v d3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLWRoYy1yZmMzMzE1YmlzLTA3 LnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWlldGYtZGhjLXJmYzMzMTViaXMvDQpIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZGhjLXJmYzMzMTViaXMtMDcNCkRpZmY6ICAgICAgICAg ICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1kaGMtcmZjMzMx NWJpcy0wNw0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIHRoZSBEeW5h bWljIEhvc3QgQ29uZmlndXJhdGlvbiBQcm90b2NvbCBmb3INCiAgIElQdjYgKERIQ1B2Nik6IGFu IGV4dGVuc2libGUgbWVjaGFuaXNtIGZvciBjb25maWd1cmluZyBub2RlcyB3aXRoDQogICBuZXR3 b3JrIGNvbmZpZ3VyYXRpb24gcGFyYW1ldGVycywgSVAgYWRkcmVzc2VzLCBhbmQgcHJlZml4ZXMu DQogICBQYXJhbWV0ZXJzIGNhbiBiZSBwcm92aWRlZCBzdGF0ZWxlc3NseSwgb3IgaW4gY29tYmlu YXRpb24gd2l0aA0KICAgc3RhdGVmdWwgYXNzaWdubWVudCBvZiBvbmUgb3IgbW9yZSBJUHY2IGFk ZHJlc3NlcyBhbmQvb3IgSVB2Ng0KICAgcHJlZml4ZXMuICBESENQdjYgY2FuIG9wZXJhdGUgZWl0 aGVyIGluIHBsYWNlIG9mIG9yIGluIGFkZGl0aW9uIHRvDQogICBzdGF0ZWxlc3MgYWRkcmVzcyBh dXRvY29uZmlndXJhdGlvbiAoU0xBQUMpLg0KDQogICBUaGlzIGRvY3VtZW50IHVwZGF0ZXMgdGhl IHRleHQgZnJvbSBSRkMzMzE1LCB0aGUgb3JpZ2luYWwgREhDUHY2DQogICBzcGVjaWZpY2F0aW9u LCBhbmQgaW5jb3Jwb3JhdGVzIHByZWZpeCBkZWxlZ2F0aW9uIChSRkMzNjMzKSwNCiAgIHN0YXRl bGVzcyBESENQdjYgKFJGQzM3MzYpLCBhbiBvcHRpb24gdG8gc3BlY2lmeSBhbiB1cHBlciBib3Vu ZCBmb3INCiAgIGhvdyBsb25nIGEgY2xpZW50IHNob3VsZCB3YWl0IGJlZm9yZSByZWZyZXNoaW5n IGluZm9ybWF0aW9uDQogICAoUkZDNDI0MiksIGEgbWVjaGFuaXNtIGZvciB0aHJvdHRsaW5nIERI Q1B2NiBjbGllbnRzIHdoZW4gREhDUHY2DQogICBzZXJ2aWNlIGlzIG5vdCBhdmFpbGFibGUgKFJG QzcwODMpLCBhbmQgY2xhcmlmaWVzIHRoZSBpbnRlcmFjdGlvbnMNCiAgIGJldHdlZW4gbW9kZXMg b2Ygb3BlcmF0aW9uIChSRkM3NTUwKS4gIEFzIHN1Y2gsIHRoaXMgZG9jdW1lbnQNCiAgIG9ic29s ZXRlcyBSRkMzMzE1LCBSRkMzNjMzLCBSRkMzNzM2LCBSRkM0MjQyLCBSRkM3MDgzLCBhbmQgUkZD NzU1MC4NCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0 ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lv biBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBT ZWNyZXRhcmlhdA0KDQo= From nobody Mon Mar 13 09:57:06 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC03129509 for ; Mon, 13 Mar 2017 09:57:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 cjn01wdXAJJw for ; Mon, 13 Mar 2017 09:57:02 -0700 (PDT) Received: from tsinghua.edu.cn (smtp36.tsinghua.edu.cn [166.111.204.60]) by ietfa.amsl.com (Postfix) with ESMTP id A726B129499 for ; Mon, 13 Mar 2017 09:57:01 -0700 (PDT) Received: from LAPTOPGK3QU8SR (unknown [61.48.145.242]) by app6 (Coremail) with SMTP id D8xvpgC3FcFaz8ZYjpgRAQ--.50052S2; Tue, 14 Mar 2017 00:56:58 +0800 (CST) From: "rengang" To: Date: Tue, 14 Mar 2017 00:56:50 +0800 Message-ID: <02fb01d29c1a$cf7aa5d0$6e6ff170$@cernet.edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdKcGoL1NUH/gx5nStGPrrFfC+Ao3w== Content-Language: zh-cn X-CM-TRANSID: D8xvpgC3FcFaz8ZYjpgRAQ--.50052S2 X-Coremail-Antispam: 1UD129KBjDUn29KB7ZKAUJUUUUU529EdanIXcx71UUUUU7v73 VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjDUYxBIdaVFxhVjvjDU0xZFpf9x0UUjRNrb1MtD = X-CM-SenderInfo: 5uhqwt1qj6uvhuqh3hxhgxhubq/ Archived-At: Subject: [dhcwg] FW: New Version Notification for draft-ren-dhc-mredhcpv6-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 16:57:04 -0000 Hi, all We've submitted a new draft. This document describes multi-requirement extensions for DHCPv6, which = allow hosts to generate addresses through SLAAC or fetch addresses = assigned from DHCPv6 servers according to the requirements of user or = network. At the same time, the extensions allow DHCP servers to = centrally manage all kinds of addresses including SLAAC-configured = addresses, DHCPv6-configured addresses, and manual-configured addresses. = Moreover, a general extension for address generation is designed to = allow multiple types of external requirements to be introduced into the = DHCPv6 exchanges, such as traceback, transition, and mobility. We hope you could review the draft and give some comments. Thanks a lot. Best Regards, Ren Gang -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: 2017=E5=B9=B43=E6=9C=8813=E6=97=A5 23:51 To: Gang Ren ; Lin He = ; Ren Gang ; Ying = Liu New Version Notification for draft-ren-dhc-mredhcpv6-00.txt A new version of I-D, draft-ren-dhc-mredhcpv6-00.txt has been = successfully submitted by Gang Ren and posted to the IETF repository. Name: draft-ren-dhc-mredhcpv6 Revision: 00 Title: Multi-requirement Extensions for Dynamic Host Configuration = Protocol for IPv6 (DHCPv6) Document date: 2017-03-13 Group: Individual Submission Pages: 22 URL: = https://www.ietf.org/internet-drafts/draft-ren-dhc-mredhcpv6-00.txt Status: = https://datatracker.ietf.org/doc/draft-ren-dhc-mredhcpv6/ Htmlized: https://tools.ietf.org/html/draft-ren-dhc-mredhcpv6-00 Abstract: This memo provides multi-requirement extensions for DHCPv6, which allow hosts to generate or fetch addresses according to the user or network requirements, and DHCP servers to centrally manage all types of addresses including SLAAC-configured addresses, DHCPv6-configured addresses, and manual-configured addresses. Moreover, a general extension for address generation is designed to allow multiple types of requirements to be introduced into the DHCPv6 exchanges. = =20 Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at = tools.ietf.org. The IETF Secretariat From nobody Tue Mar 14 03:30:17 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AEAF128AB0 for ; Tue, 14 Mar 2017 03:30:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es 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 5I9IpoXv4-Kg for ; Tue, 14 Mar 2017 03:30:13 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9C141293DC for ; Tue, 14 Mar 2017 03:30:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1489487410; x=1490092210; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:CC:Message-ID: Thread-Topic:Mime-version:Content-type:Content-transfer-encoding: Reply-To; bh=Jj9K8bkcP0cJsNVAIk+Bu4f9qvND0yr6skQd/FXbdMY=; b=oiF MiPoDxiimbqydR01akW4yuHImNrbN79rA3X0ZxUW+D5dUm1mLR0tujSuc6oPpNwY 0Zus58urrIop9ExnI2VqCo/0F005WKatl1S2d+lO/Zl2xmS8bq4ZLutbhzjCHkqC t2TQu0pboGIk0+BhgkT16/sHTAbYil23T+nYH0ds= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=gk2x8pEEfmc0okFrAcaBSQX37Q9JM2BJIRRi67vDtPwwOpo3b0zJZizv7Epl YLnMD7TfKG19y/NchjQCGkhb8cTXBlRmK1KBUgJVwrtidxISIfCiIIX/Y 9LeLFC8jI90UxKpmGmiM9AcGfrTwhGyDbKxp3PgT4j3JWDi9ZikObM=; X-MDAV-Processed: mail.consulintel.es, Tue, 14 Mar 2017 11:30:10 +0100 X-Spam-Processed: mail.consulintel.es, Tue, 14 Mar 2017 11:30:04 +0100 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005386342.msg for ; Tue, 14 Mar 2017 11:30:04 +0100 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170314:md50005386342::MxBAlxHSd5O7lGtK:000006pO X-Return-Path: prvs=12461710fe=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: dhcwg@ietf.org User-Agent: Microsoft-MacOutlook/f.1f.0.170216 Date: Tue, 14 Mar 2017 11:30:00 +0100 From: JORDI PALET MARTINEZ To: , Message-ID: Thread-Topic: draft-li-intarea-nat64-prefix-dhcp-option-00.txt Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Cc: int-area@ietf.org Subject: [dhcwg] draft-li-intarea-nat64-prefix-dhcp-option-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: jordi.palet@consulintel.es List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 10:30:15 -0000 Hi, We have submitted a new ID, in order to standardize new DHCPv6 options to a= llow the discovery of the IPv6/IPv4 prefixes served by stateful/stateless N= AT64 translators (which can be used by SIIT, Stateful NAT64/464XLAT, EAM-SI= IT, etc.). DHCPv6 Options for Discovery NAT64 Prefixes https://datatracker.ietf.org/doc/draft-li-intarea-nat64-prefix-dhcp-option This is an update of a previous work (https://tools.ietf.org/html/draft-cui= -intarea-464xlat-prefix-dhcp-00), which was considering only the 464XLAT ca= se. There have been similar solutions for DS-LITE/lw4o6/MAP, etc. As v6ops can=E2=80=99t do =E2=80=9Cnew=E2=80=9D protocols, neither DHCP sta= ndardize new options, it has been submitted to int-area, but we believe tha= t is relevant to both v6ops and DHCP, so please, read the document and prov= ide inputs. Thanks! Regards, Jordi ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Wed Mar 22 07:31:47 2017 Return-Path: X-Original-To: dhcwg@ietf.org Delivered-To: dhcwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F3FCB13166A; Wed, 22 Mar 2017 06:40:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.48.1 Auto-Submitted: auto-generated Precedence: bulk Cc: "Bernie Volz" , volz@cisco.com, dhc-chairs@ietf.org, suresh.krishnan@ericsson.com, "The IESG" , dhcwg@ietf.org, rfc-editor@rfc-editor.org, draft-ietf-dhc-dhcpv6-prefix-length-hint-issue@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <149019004497.10640.16984970492564219190.idtracker@ietfa.amsl.com> Date: Wed, 22 Mar 2017 06:40:44 -0700 Archived-At: Subject: [dhcwg] Protocol Action: 'DHCPv6 Prefix Length Hint Issues' to Proposed Standard (draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-05.txt) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 13:40:49 -0000 The IESG has approved the following document: - 'DHCPv6 Prefix Length Hint Issues' (draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-05.txt) as Proposed Standard This document is the product of the Dynamic Host Configuration Working Group. The IESG contact persons are Suresh Krishnan and Terry Manderson. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-prefix-length-hint-issue/ Technical Summary This document specifies information that is useful to DHCPv6 client and server implementers to support allowing clients to specify a prefix length hint when requested delegated prefixes. It clarifies this concept introduced in RFC 3633. Working Group Summary There is a strong consensus behind this document and in particular from very active WG participants. Document Quality This document has had thorough reviews by many interested and knowledgeable folks (beyond those mentioned in the acknowledgements section). There were no significant points of difficulty or controversy with the contents of the document. Personnel Bernie Volz is the document shepherd. Suresh Krishnan is the current responsible AD. From nobody Fri Mar 24 10:25:09 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52BDD129548; Fri, 24 Mar 2017 10:25:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 uLXHR2fyjsXN; Fri, 24 Mar 2017 10:25:05 -0700 (PDT) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (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 0F25712949A; Fri, 24 Mar 2017 10:25:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v2OHP4jS043768; Fri, 24 Mar 2017 10:25:04 -0700 Received: from XCH15-06-09.nw.nos.boeing.com (xch15-06-09.nw.nos.boeing.com [137.136.239.172]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v2OHOvGW043562 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Fri, 24 Mar 2017 10:24:58 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-09.nw.nos.boeing.com (2002:8988:efac::8988:efac) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 24 Mar 2017 10:24:57 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1263.000; Fri, 24 Mar 2017 10:24:56 -0700 From: "Templin, Fred L" To: Tomek Mrugalski , dhcwg CC: draft-ietf-dhc-sedhcpv6 authors Thread-Topic: [dhcwg] WGLC on draft-ietf-dhc-sedhcpv6-21 - Respond by March 29th Thread-Index: AQHSmBEZNN0XaqjWoEec2cWUphDKn6GkVjeg Date: Fri, 24 Mar 2017 17:24:56 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-sedhcpv6-21 - Respond by March 29th X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Mar 2017 17:25:08 -0000 Hi Tomek, With apologies for the delayed response, see below: > -----Original Message----- > From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Tomek Mrugalski > Sent: Wednesday, March 08, 2017 5:37 AM > To: dhcwg > Cc: draft-ietf-dhc-sedhcpv6 authors > Subject: [dhcwg] WGLC on draft-ietf-dhc-sedhcpv6-21 - Respond by March 29= th >=20 > Hi, > draft-ietf-dhc-sedhcpv6-21 describes a mechanism for using public key > cryptography to provide end-to-end security between DHCPv6 clients and > servers. The mechanism provides encryption in all cases, and can be used > for authentication based on pre-sharing of authorized certificates. This > draft has started in 2013, but the whole DHCPv6 security saga is much > longer and begins in 2008. This draft was submitted to IESG in mid-2015. > The guidance received was clear that substantial changes are needed. As > a result, "encrypt everywhere, authenticate if you can" approach was used= . >=20 > Authors believe this draft to be ready for working group last call. >=20 > Please send your substantial comments to the mailing list and express > your opinion whether this draft is ready for publication. Feel free to > send nitpicks and minor corrections to the authors directly. This is a > complex draft, so the chairs believe 3 weeks WGLC is in order. Please > send your comments no later than March 29th. Bernie and I will determine > consensus and will discuss during Chicago meeting as needed. >=20 > To initiate the discussion, I have two related questions. The chairs > would love to hear your opinions on those. >=20 > 1. The "encrypt everywhere" paradigm means that in deployments that do > snooping on relay will break down. To solve this problem, we need a > assignment notification mechanism, similar to the one described in > draft-ietf-dhc-dhcpv6-agentopt-delegate-04. That draft expired many > years ago. This matter was discussed in Seoul and the minutes describe > the conclusion as: >=20 > The discussion gravitated towards not resurrecting until the sedhcpv6 > I-D progresses further. We will reevaluate this once sedhcpv6 is done. >=20 > Do you want the WG to resurrect agentopt-delegate a) now, b) when > sedhcpv6 is sent to IESG or c) when sedhcpv6 is published as RFC? d) we > need a completely new draft and I'm volunteering to work on it. a) now. What would be the reason for any delay? If there is any assistance I could give to the effort I would be willing to help. Thanks - Fred fred.l.templin@boeing.com > 2. One of the authors suggested that this protocol is quite complex and > having a feedback from an implementation (or ideally two interoperating) > would be very important and would likely result in some changes to the > draft. It's probably too late for Chicago, but we can organize a > sedhcpv6 hackathon in Prague. Two likely implementations would be WIDE > and Kea, as those two are open source and have an old version of the > draft partially implemented. Do you think such a hackathon would be > useful? Are you willing to participate? >=20 > Title: Secure DHCPv6 > Authors: L. Li, S. Jiang, Y.Cui, T.Jinmei, T.Lemon, D.Zhang > Filename: draft-ietf-dhc-sedhcpv6-21 > Pages: 31 > Date: 2017-02-21 > Link: https://datatracker.ietf.org/doc/draft-ietf-dhc-sedhcpv6/ >=20 > Responses by March 29th are appreciated. >=20 > Thanks, > Bernie and Tomek >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From nobody Sat Mar 25 19:05:57 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F0751294A5; Sat, 25 Mar 2017 19:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 uM7V8YhZRdfr; Sat, 25 Mar 2017 19:05:54 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F41F126D73; Sat, 25 Mar 2017 19:05:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9290; q=dns/txt; s=iport; t=1490493954; x=1491703554; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=4O14CMkKuXqAZ0k3FjXu48UZNtmHq5ClmjeQyRbq9GI=; b=c8NW7aMTlE4FOzmvhAH+Y6+4osa21WYhAdZhr2dGlZqrL8WfMYOiXVnS gR1kt0G0l3VC8UgUosBMzSBMVDOMJFKjByCx1pHPwT8DBvc7dkzbAgXSz 2hpdk//6+AUCFdjT0WyNpQneiNo0kGYE5Sll61StGe1V/YtWZp6aqJIeB 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ATAQBoIddY/5ldJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1RhgQsHjWqRTZVLgg4fC4V4AoMpPxgBAgEBAQEBAQFrKIUVAQE?= =?us-ascii?q?BAQMBASUTNAsMBAIBCA4DAwEBAR8JBycLFAkIAgQBDQUIiX8OrFI6ijkBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEYBYo0gQmBPIMChXsFhmuCK4gXiy4BhnqDKoMnhHe?= =?us-ascii?q?CBYUqiguTZAEfOEs5WRUYKYRYHYFjdYdfK4EDgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.36,223,1486425600"; d="scan'208";a="402051456" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Mar 2017 02:05:53 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v2Q25rnj031293 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 26 Mar 2017 02:05:53 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sat, 25 Mar 2017 21:05:52 -0500 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1210.000; Sat, 25 Mar 2017 21:05:52 -0500 From: "Bernie Volz (volz)" To: Tomek Mrugalski , dhcwg CC: draft-ietf-dhc-sedhcpv6 authors Thread-Topic: [dhcwg] WGLC on draft-ietf-dhc-sedhcpv6-21 - Respond by March 29th Thread-Index: AQHSmBEofEj8/aGJckKkKaGWH1j71aGmX41w Date: Sun, 26 Mar 2017 02:05:52 +0000 Message-ID: <7db55e6f55e34408a1816887c22e28d3@XCH-ALN-003.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.252.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-sedhcpv6-21 - Respond by March 29th X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Mar 2017 02:05:56 -0000 Hi: I have reviewed the draft and support it moving forward. However, I do have= some issues I think need to be addressed but they are mostly fairly small. I do want to thank the authors for addressing my earlier issues. I think th= e document is in MUCH better shape now!! So here goes ... Section 6: The sentence: "The encryption text SHOULD be formatted as explain in [RFC56= 52]." Isn't clear. RFC5652 doesn't use "text" except to mean actual wording= in the RFC. Could "encryption text" be clarified? Is this the client's mes= sage? Or what exactly is this and which part of RFC 5652 has this "format"?= I am not following what this sentence means and what I should do (if I wer= e implementing this). Note: This same text is also in Section 7 (last paragraph) and needs simila= r attention. Section 7: option. Then, the server checks the Server Identifier option. The DHCPv6 server drops the message that is not for it, thus not paying cost to decrypt messages. If it is the target server, according to I think here you also want the server to proceed if there is NO Server Iden= tifier option? It should only ignore it if there is a Server Identifier opt= ion and it does not match this server's identifier? Section 8 those present in the innermost encapsulated messages from the client or server. I think messages should just be message as there is only one message? Section 9.1: Might be better to split out requirements for a client and server into sepa= rate paragraphs (1st paragraph)? Might also be best to be clear that you ad= dress: 1. What a client must remember about its own increasing number (i.e., what = it sends to the server). 2. What a client must remember about the server's increasing number (i.e., = what it receives from server). 3. What a server must remember about a client's increasing number (i.e., wh= at it receives from client). 4. What a server must remember about its own increasing number (i.e., what = it sends to clients). I assume a server does NOT need to keep a unique incr= easing number set for each client it communicates with - a server can use o= ne set for all clients? Please also be clear about how each of these 4 (2 numbers on client, 2 on s= erver) are handled. The text presently is not very clear -- for example a c= lient can't forget what it sent if the server remembers it. Later, be clear that this is modulo 2^64 math: The Increasing-number option in the received message passes the increasing number check if NUM.REC is more than NUM.STO. And then, the value of NUM.STO is changed into the value of NUM.REC. The increasing number check fails if NUM.REC is equal with or less than NUM.STO. "More" here is in the modulo arithmetic "more" -- perhaps use "more (modulo= 2^64)" and "or less (modulo 2^64)"? Section 9.2: I wonder if you should revise the code to make it more appropriate for this= document? RDATA/RDLENGTH aren't really appropriate?=20 Section 10 There are now only three (not six) status codes. Section 10.2 msg-type Identifier of the message type. It can be either Encrypted-Query (TBA7) or DHCPv6-Response (TBA8). Change DHCPv6-Response to Encrypted-Response. Section 11 There are some mandatory algorithm for encryption algorithm in this Change (first) algorithm to algorithms? Or, change "are some" to "is a" Likewise, since the Encryption-Key-Tag Option isn't protected, an attacker that can intercept the message can forge the value without detection. Isn't this generally useless? As the message is encrypted, the validation w= ill fail? Some even more MINOR comments (these would perhaps improve readability but = would likely be addressed by the RFC editor): Section 6: Perhaps replace "contained" and "contain" with "included" and "include" in = the sentences later in that same paragraph (with the "The encryption text..= ."). For the received Encrypted-Response message, the client MUST drop the Encrypted-Response message if other DHCPv6 option except Encrypted- message option is contained. How about: For the received Encrypted-Response message, the client MUST drop the Encrypted-Response message if it contains any option other than a single Encrypted-message option. Note: There are some other odd uses of contain (when at least I think the t= ext should use include). But it may not be worth trying to change these (th= e usage is tricky - you can google for "english contain vs include" if you = like). We will leave it to the RFC editor to perhaps clean these up if appr= opriate. The client MAY use the AuthenticationFail as a hint and switch to other DHCPv6 server if it has another one. =20 Change to "to another DHCP server if it has one"? Section 7: Upon the receipt of Encrypted-Query message, the server MUST drop the message if the other DHCPv6 option is contained except Server Here "the other" should change to "another". Note: There are several other places where contained/contain would (at leas= t in my mind) be more "standard" if the text used included/include. Same go= es for use of "other" (-> another). Last paragraph of section 7, "then the server set the". Set should be sets. Section 10.1.1 For EA-len, might be good to add "(must be a multiple of 2)" For SHA-len, might be good to add "(must be a multiple of 4)" Also, I think you should change all "2-octets value" to "2-octet value". Section 11 For this security item, It is RECOMMENDED that client certificates could be tied to specific server certificates by configuration. Lower case "It"? General There are uses of "cert" and "certs" and "certificate(s)". Are these one in= the same? Shouldn't we just use "certificate" throughout? Or perhaps you s= hould add "cert(s)" to terminology section? - Bernie -----Original Message----- From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Tomek Mrugalski Sent: Wednesday, March 08, 2017 8:37 AM To: dhcwg Cc: draft-ietf-dhc-sedhcpv6 authors Subject: [dhcwg] WGLC on draft-ietf-dhc-sedhcpv6-21 - Respond by March 29th Hi, draft-ietf-dhc-sedhcpv6-21 describes a mechanism for using public key crypt= ography to provide end-to-end security between DHCPv6 clients and servers. = The mechanism provides encryption in all cases, and can be used for authent= ication based on pre-sharing of authorized certificates. This draft has sta= rted in 2013, but the whole DHCPv6 security saga is much longer and begins = in 2008. This draft was submitted to IESG in mid-2015. The guidance received was clear that substantial changes are needed. As a = result, "encrypt everywhere, authenticate if you can" approach was used. Authors believe this draft to be ready for working group last call. Please send your substantial comments to the mailing list and express your = opinion whether this draft is ready for publication. Feel free to send nitp= icks and minor corrections to the authors directly. This is a complex draft= , so the chairs believe 3 weeks WGLC is in order. Please send your comments= no later than March 29th. Bernie and I will determine consensus and will d= iscuss during Chicago meeting as needed. To initiate the discussion, I have two related questions. The chairs would = love to hear your opinions on those. 1. The "encrypt everywhere" paradigm means that in deployments that do snoo= ping on relay will break down. To solve this problem, we need a assignment = notification mechanism, similar to the one described in draft-ietf-dhc-dhcp= v6-agentopt-delegate-04. That draft expired many years ago. This matter was= discussed in Seoul and the minutes describe the conclusion as: The discussion gravitated towards not resurrecting until the sedhcpv6 I-D progresses further. We will reevaluate this once sedhcpv6 is done. Do you want the WG to resurrect agentopt-delegate a) now, b) when sedhcpv6 is sent to IESG or c) when sedhcpv6 is published as RFC? d) we nee= d a completely new draft and I'm volunteering to work on it. 2. One of the authors suggested that this protocol is quite complex and hav= ing a feedback from an implementation (or ideally two interoperating) would= be very important and would likely result in some changes to the draft. It= 's probably too late for Chicago, but we can organize a sedhcpv6 hackathon in Prague. Two likely implementations would be WIDE and = Kea, as those two are open source and have an old version of the draft part= ially implemented. Do you think such a hackathon would be useful? Are you w= illing to participate? Title: Secure DHCPv6 Authors: L. Li, S. Jiang, Y.Cui, T.Jinmei, T.Lemon, D.Zhang Filename: draft-ietf-dhc-sedhcpv6-21 Pages: 31 Date: 2017-02-21 Link: https://datatracker.ietf.org/doc/draft-ietf-dhc-sedhcpv6/ Responses by March 29th are appreciated. Thanks, Bernie and Tomek _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From nobody Sun Mar 26 07:32:12 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0163D12441E for ; Sun, 26 Mar 2017 07:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.402 X-Spam-Level: X-Spam-Status: No, score=-2.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 QrshtVCvNUSW for ; Sun, 26 Mar 2017 07:32:09 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 243B812940C for ; Sun, 26 Mar 2017 07:32:09 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id p22so21325962qka.3 for ; Sun, 26 Mar 2017 07:32:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=k+w98ndnRx1jsJ4EXcHsXlWAWn/d++DenQGmAVk2vN0=; b=NSEx48BRgr6BDWnnX5FDpOkRs/NoUwWXaTGcL2u7Ss0xpO8JQYlk58vcnRVeujcc5+ 2tMGsb80YRrOocOsYlV3FTgDZgx8h/Ab0LnuvxLOfAxru50upl7PBjaUuffv/FlLSbH+ 8Zzhb9bPAWARhS2auOwUnvbWfmlj3auzNQnZaikvOe9zILaXZqCqNCDVcnQUAy/134He OVWSFWxaVJqQhqwVlY2Jjbb4JjYay3DLeaUIW+y6WyVvYnOonq1PPk/GBTYTeonLlBoU 7+7KbNcFZ2VA+c4FR95/msumPtf9KuDp4UDnGQAgXKphEI+FBQl+HO+M1Jion/0AqkUY 3OAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=k+w98ndnRx1jsJ4EXcHsXlWAWn/d++DenQGmAVk2vN0=; b=Pwo+65JBMqPPXQ04R751C/8wZglS7z00rkkWjpApaIGlZMTfG6r3X9tYkOrkSBJWZW yzpWka4MC2+wNhPMkeljk190/tRf/h8o2tgHXyQ12r+60MLpy4qG++qoFi/3VhwNCL9I 569ysk9Ra9GTFwjWMIdWSf1Ef47cmXLRiYqlTUXrVWe4wV5Rd4+0mPgjzBjmgyIQ6zfL 3GgQACb9XNy3xBhqSIqwcwZB/dxsinXnV0XT8FF3kwYsKb+wIUUMngkCIoILcrSg11CL BE80pvJoeZQWHQWLV7uIpkDMi2SWEf31byqiQLA1Hquea5PG6WYXn0C3NJRiC18ZD5/1 uLJw== X-Gm-Message-State: AFeK/H1+REWAAtNjYPZg7c4voJk2Mabpq9wbM7ImeJlAK7vz89fWcgHjJj6MaXgXs59Q6QBiHCvLihTjIN/+0g== X-Received: by 10.55.146.135 with SMTP id u129mr15734389qkd.219.1490538727916; Sun, 26 Mar 2017 07:32:07 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.61.204 with HTTP; Sun, 26 Mar 2017 07:32:07 -0700 (PDT) From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Sun, 26 Mar 2017 07:32:07 -0700 X-Google-Sender-Auth: vShJIR7Bhlxmd7CEkk-7UWSvYB8 Message-ID: To: "dhcwg@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [dhcwg] whether/how to support Confirm with sedhcpv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Mar 2017 14:32:11 -0000 While reviewing ietf-dhc-sedhcpv6-21, I've realized one thing that probably requires a discussion: whether/how to use sedhcpv6 for Confirm. To avoid distraction I'm raising it separately from the full review I'm planning to submit later. When a client might want to send a Confirm, it should be reasonably possible that the client has moved and would be talking to a different server. In that case it doesn't make sense to encrypt the Confirm message and encapsulate it in an Encryption-query message; the actual server would silently discard it, and the client can't tell whether it's because it has moved or the message is simply lost. So I think we need some special case handling here. A couple of choices I can think of are: - say sedhcpv6 can't support Confirm (I don't like this option) - have the client perform a separate information-request/reply exchange to see if the currently recognized server and its public key are still usable (if not, the client should basically not send the Confirm, following the sense of RFC7844). (There may be other options.) -- JINMEI, Tatuya From nobody Sun Mar 26 07:44:55 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 797BE129444 for ; Sun, 26 Mar 2017 07:44:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 YDIlm8tYGlKC for ; Sun, 26 Mar 2017 07:44:51 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9ED1B129405 for ; Sun, 26 Mar 2017 07:44:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2025; q=dns/txt; s=iport; t=1490539491; x=1491749091; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=gZVP9fYSc+r2A0jeuC7wwehEOtOoLWVQUL4S3qsj6zg=; b=KG/v5ldsZR4nmI+3mWYCOgrDvgwgiFl3/xe/zrSf9vcMjACdERxPXbZa uHaYbbXoYlsSXoAxYknzlxGPt5rQR6t0JYaZVH4qRcNrMYXLelVuD9IC8 1k1CF1z8dLRITLQKPLjXWM1+KEIACcrZ4opnOkSwaJzRsV4784bU4UokU A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BiBQCe0tdY/5BdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1RhgQuDYptcgx2SLoIOHwuFeAKDKUAXAQIBAQEBAQEBayiFFQE?= =?us-ascii?q?BAQECAQEBHwFMCwULAgEIGAEDCxoDAicLJQIEDgWJfwgOjUKdVgGCKoo3AQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBGAWBCIdLgmqEPhaDAzGCMQWcWwGSS5ExgWuReQE?= =?us-ascii?q?hAjSBBFkVQREBhkZ1iXgBAQE?= X-IronPort-AV: E=Sophos;i="5.36,225,1486425600"; d="scan'208";a="401474390" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Mar 2017 14:44:50 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v2QEiomQ027176 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 26 Mar 2017 14:44:50 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 26 Mar 2017 09:44:50 -0500 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1210.000; Sun, 26 Mar 2017 09:44:50 -0500 From: "Bernie Volz (volz)" To: =?iso-2022-jp?B?GyRCP0BMQEMjOkgbKEI=?= CC: "dhcwg@ietf.org" Thread-Topic: [dhcwg] whether/how to support Confirm with sedhcpv6 Thread-Index: AQHSpj3Fn2WlavvNXUqtanr4SSkvDaGnMo+V Date: Sun, 26 Mar 2017 14:44:49 +0000 Message-ID: <3566F64B-D709-4DF3-9A5F-7648DA8FC45E@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [dhcwg] whether/how to support Confirm with sedhcpv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Mar 2017 14:44:53 -0000 Hi: Good point ... I was thinking that encrypted Confirm (or Rebind) would be f= ine - if still on same link (or at least server) it would work just fine. O= therwise, client times out and is left to use other mechanisms (RS/RA)? But using Information-Request is interesting. Wonder if doing both or falli= ng back to Information-Request after short period (note that if client dete= rmined it needed new leases, it would do Information-Request anyway). We can add to discussion at Thursday DHC WG meeting as we hoped to get some= issues regarding draft that could use discussion. - Bernie (from iPhone) > On Mar 26, 2017, at 9:32 AM, =1B$B?@L@C#:H=1B(B wrote= : >=20 > While reviewing ietf-dhc-sedhcpv6-21, I've realized one thing that > probably requires a discussion: whether/how to use sedhcpv6 for > Confirm. To avoid distraction I'm raising it separately from the full > review I'm planning to submit later. >=20 > When a client might want to send a Confirm, it should be reasonably > possible that the client has moved and would be talking to a different > server. In that case it doesn't make sense to encrypt the Confirm > message and encapsulate it in an Encryption-query message; the actual > server would silently discard it, and the client can't tell whether > it's because it has moved or the message is simply lost. So I think > we need some special case handling here. A couple of choices I can > think of are: > - say sedhcpv6 can't support Confirm (I don't like this option) > - have the client perform a separate information-request/reply > exchange to see if the currently recognized server and its public > key are still usable (if not, the client should basically not send > the Confirm, following the sense of RFC7844). >=20 > (There may be other options.) >=20 > -- > JINMEI, Tatuya >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From nobody Sun Mar 26 21:33:09 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE0041293E1; Sun, 26 Mar 2017 21:33:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 IhuyaN5yQgju; Sun, 26 Mar 2017 21:33:04 -0700 (PDT) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3281F127876; Sun, 26 Mar 2017 21:33:04 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id n21so28285561qta.1; Sun, 26 Mar 2017 21:33:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=17LqDiPpj96QnmF53ODUP5O/ffU/bPdGFdJVkigxc4A=; b=qHjYBCNdcg58vTIKnXJZuSIBLpY6BPqid3hXVdk1v3YulRzptAMxp6oPYQ+sSSOyF0 jSNeL0V66yLHfIS0CQbdmQSyFe5taR/dS0WBLcB26USXIvCYl6bGArWtpGPVckhjTUTC bdpRmPsrBC5yyP2U17K+3o0muHUs8nwaK58QhVUcwQCr/7LZEeBndgye8z+hbhvK9r3O gnFq5Kcl6ucweWk/923Ccv86tsqAbuCFv3e6qMDGO41jM40iVIl3xWzG9P/5xcQqBkUj eaBarol2O51vUoQDEWygnMydhL4GdmUg+hRW7UDly/PeJFltCB6T7+XCnbFJmUjVjK9c z7pw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=17LqDiPpj96QnmF53ODUP5O/ffU/bPdGFdJVkigxc4A=; b=mVB98VpgCSzkNppgwJE3jZq5ZRv8T0Nyu0WQ7IBx8mcFjFZanusWakTS1rNdiD8QHR srAbNeEBOquwxgni3Zl1quyfN7iHXAmaxIIechj2ndnQrrpguy2ev3txhYt84ZL9ec2J KJLMZJzvZbD8lBFoGQGuFE1+gwAFVbWwSgeENf08YNeHVe7om5oThMrNVLoT9wakr37u mIaJR182D3GW4+M4GuwGVdIsnFQjwD8nxHdlfsekXQ974xJIRBD2l4jX+MhVzweS5CYl jUM1DZPdGNTHxnSODr4ucHeuc6T4kQjx5i9LdQuEBZ1BJrDPCUv9CGHzaDYViHBoXvhY SgXg== X-Gm-Message-State: AFeK/H2+W9nus0o5zIJh8pOfOqlHwVm68EawqwzsLMo9eI7wO0cgG6pIAwPQXdhSgcOSpxF6a3NVnrScTGcnbQ== X-Received: by 10.200.44.249 with SMTP id 54mr18642963qtx.250.1490589183267; Sun, 26 Mar 2017 21:33:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.46.132 with HTTP; Sun, 26 Mar 2017 21:33:02 -0700 (PDT) In-Reply-To: <7db55e6f55e34408a1816887c22e28d3@XCH-ALN-003.cisco.com> References: <7db55e6f55e34408a1816887c22e28d3@XCH-ALN-003.cisco.com> From: Lishan Li Date: Mon, 27 Mar 2017 12:33:02 +0800 Message-ID: To: "Bernie Volz (volz)" Cc: Tomek Mrugalski , dhcwg , draft-ietf-dhc-sedhcpv6 authors Content-Type: multipart/alternative; boundary=001a114118eac67660054baed6a2 Archived-At: Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-sedhcpv6-21 - Respond by March 29th X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 04:33:08 -0000 --001a114118eac67660054baed6a2 Content-Type: text/plain; charset=UTF-8 Hi, Bernie, Thanks a lot for your valuable comments. For the details, please see inline. Best Regards, Lishan 2017-03-26 10:05 GMT+08:00 Bernie Volz (volz) : > Hi: > > I have reviewed the draft and support it moving forward. However, I do > have some issues I think need to be addressed but they are mostly fairly > small. > > I do want to thank the authors for addressing my earlier issues. I think > the document is in MUCH better shape now!! > > So here goes ... > > Section 6: > The sentence: "The encryption text SHOULD be formatted as explain in > [RFC5652]." Isn't clear. RFC5652 doesn't use "text" except to mean actual > wording in the RFC. Could "encryption text" be clarified? Is this the > client's message? Or what exactly is this and which part of RFC 5652 has > this "format"? I am not following what this sentence means and what I > should do (if I were implementing this). > > Note: This same text is also in Section 7 (last paragraph) and needs > similar attention. > [LS]: Sorry for the unclear expression. How about the following text? The DHCPv6 message sent from the client is encrypted and then encapsulated into the encrypted DHCPv6 message field according to the Encrypted-Data content syntax defined in the RFC5652. > > Section 7: > > option. Then, the server checks the Server Identifier option. The > DHCPv6 server drops the message that is not for it, thus not paying > cost to decrypt messages. If it is the target server, according to > > I think here you also want the server to proceed if there is NO Server > Identifier option? It should only ignore it if there is a Server Identifier > option and it does not match this server's identifier? > [LS]: Yes. Will modify it. > > Section 8 > > those present in the innermost encapsulated messages from the client > or server. > > I think messages should just be message as there is only one message? > [LS]: Agree. Will modify it. > > Section 9.1: > > Might be better to split out requirements for a client and server into > separate paragraphs (1st paragraph)? Might also be best to be clear that > you address: > 1. What a client must remember about its own increasing number (i.e., what > it sends to the server). > 2. What a client must remember about the server's increasing number (i.e., > what it receives from server). > 3. What a server must remember about a client's increasing number (i.e., > what it receives from client). > 4. What a server must remember about its own increasing number (i.e., what > it sends to clients). I assume a server does NOT need to keep a unique > increasing number set for each client it communicates with - a server can > use one set for all clients? > Please also be clear about how each of these 4 (2 numbers on client, 2 on > server) are handled. The text presently is not very clear -- for example a > client can't forget what it sent if the server remembers it. > [LS]: Yes, the server just need to keep one set for all clients. How about the following modified text? For client, it MUST remember about its own increasing number, which is stored in the NUM.STO and sent to the server. And the client also MUST remember about a server's increasing number, which is received from the server and stored in the NUM.REC. And the client keeps a record of the increasing number during the DHCPv6 configuration process with the DHCPv6 server. And the client can forget the increasing number information after the transaction is finished. The client's initial locally stored increasing number is set to zero. For server, it MUST remember about its own increasing number, which is stored in the NUM.STO and sent to the client. And the server also MUST remember about a client's increasing number, which is received from the client and stored in the Num.REC. The server just need to keep one increasing number set for all clients. > > Later, be clear that this is modulo 2^64 math: > > The Increasing-number option in the received message passes the > increasing number check if NUM.REC is more than NUM.STO. And then, > the value of NUM.STO is changed into the value of NUM.REC. > > The increasing number check fails if NUM.REC is equal with or less > than NUM.STO. > > "More" here is in the modulo arithmetic "more" -- perhaps use "more > (modulo 2^64)" and "or less (modulo 2^64)"? > [LS]: Agree, will modify it. > > Section 9.2: > > I wonder if you should revise the code to make it more appropriate for > this document? RDATA/RDLENGTH aren't really appropriate? > [LS]: Got it. Will modify it. > > Section 10 > > There are now only three (not six) status codes. > [LS]: Will correct it. > > Section 10.2 > > msg-type Identifier of the message type. It can be either > Encrypted-Query (TBA7) or DHCPv6-Response (TBA8). > > Change DHCPv6-Response to Encrypted-Response. > [LS]: Will correct it. > > > Section 11 > > There are some mandatory algorithm for encryption algorithm in this > > Change (first) algorithm to algorithms? Or, change "are some" to "is a" > [LS]: Will change it. > > > Likewise, since the Encryption-Key-Tag Option isn't protected, an > attacker that can intercept the message can forge the value without > detection. > > Isn't this generally useless? As the message is encrypted, the validation > will fail? > [LS]: If the encryption-key-tag is forged, then the server may cannot decrypt it and drop the message. > > > Some even more MINOR comments (these would perhaps improve readability but > would likely be addressed by the RFC editor): > [LS]: Sorry for the poor expression. And thanks a lot your throughout check. Will correct it in the next version. > > Section 6: > > Perhaps replace "contained" and "contain" with "included" and "include" in > the sentences later in that same paragraph (with the "The encryption > text..."). > > > For the received Encrypted-Response message, the client MUST drop the > Encrypted-Response message if other DHCPv6 option except Encrypted- > message option is contained. > > How about: > > For the received Encrypted-Response message, the client MUST drop the > Encrypted-Response message if it contains any option other than a single > Encrypted-message option. > > Note: There are some other odd uses of contain (when at least I think the > text should use include). But it may not be worth trying to change these > (the usage is tricky - you can google for "english contain vs include" if > you like). We will leave it to the RFC editor to perhaps clean these up if > appropriate. > > > The client MAY use the AuthenticationFail as a hint and switch > to other DHCPv6 server if it has another one. > > Change to "to another DHCP server if it has one"? > > Section 7: > > Upon the receipt of Encrypted-Query message, the server MUST drop the > message if the other DHCPv6 option is contained except Server > > Here "the other" should change to "another". > > Note: There are several other places where contained/contain would (at > least in my mind) be more "standard" if the text used included/include. > Same goes for use of "other" (-> another). > > Last paragraph of section 7, "then the server set the". Set should be sets. > > Section 10.1.1 > > For EA-len, might be good to add "(must be a multiple of 2)" > For SHA-len, might be good to add "(must be a multiple of 4)" > > Also, I think you should change all "2-octets value" to "2-octet value". > > Section 11 > > For this security item, It is RECOMMENDED that client certificates > could be tied to specific server certificates by configuration. > > Lower case "It"? > > > General > > There are uses of "cert" and "certs" and "certificate(s)". Are these one > in the same? Shouldn't we just use "certificate" throughout? Or perhaps you > should add "cert(s)" to terminology section? > > > - Bernie > > -----Original Message----- > From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Tomek Mrugalski > Sent: Wednesday, March 08, 2017 8:37 AM > To: dhcwg > Cc: draft-ietf-dhc-sedhcpv6 authors > Subject: [dhcwg] WGLC on draft-ietf-dhc-sedhcpv6-21 - Respond by March 29th > > Hi, > draft-ietf-dhc-sedhcpv6-21 describes a mechanism for using public key > cryptography to provide end-to-end security between DHCPv6 clients and > servers. The mechanism provides encryption in all cases, and can be used > for authentication based on pre-sharing of authorized certificates. This > draft has started in 2013, but the whole DHCPv6 security saga is much > longer and begins in 2008. This draft was submitted to IESG in mid-2015. > The guidance received was clear that substantial changes are needed. As a > result, "encrypt everywhere, authenticate if you can" approach was used. > > Authors believe this draft to be ready for working group last call. > > Please send your substantial comments to the mailing list and express your > opinion whether this draft is ready for publication. Feel free to send > nitpicks and minor corrections to the authors directly. This is a complex > draft, so the chairs believe 3 weeks WGLC is in order. Please send your > comments no later than March 29th. Bernie and I will determine consensus > and will discuss during Chicago meeting as needed. > > To initiate the discussion, I have two related questions. The chairs would > love to hear your opinions on those. > > 1. The "encrypt everywhere" paradigm means that in deployments that do > snooping on relay will break down. To solve this problem, we need a > assignment notification mechanism, similar to the one described in > draft-ietf-dhc-dhcpv6-agentopt-delegate-04. That draft expired many years > ago. This matter was discussed in Seoul and the minutes describe the > conclusion as: > > The discussion gravitated towards not resurrecting until the sedhcpv6 > I-D progresses further. We will reevaluate this once sedhcpv6 is done. > > Do you want the WG to resurrect agentopt-delegate a) now, b) when > sedhcpv6 is sent to IESG or c) when sedhcpv6 is published as RFC? d) we > need a completely new draft and I'm volunteering to work on it. > > 2. One of the authors suggested that this protocol is quite complex and > having a feedback from an implementation (or ideally two interoperating) > would be very important and would likely result in some changes to the > draft. It's probably too late for Chicago, but we can organize a > sedhcpv6 hackathon in Prague. Two likely implementations would be WIDE and > Kea, as those two are open source and have an old version of the draft > partially implemented. Do you think such a hackathon would be useful? Are > you willing to participate? > > Title: Secure DHCPv6 > Authors: L. Li, S. Jiang, Y.Cui, T.Jinmei, T.Lemon, D.Zhang > Filename: draft-ietf-dhc-sedhcpv6-21 > Pages: 31 > Date: 2017-02-21 > Link: https://datatracker.ietf.org/doc/draft-ietf-dhc-sedhcpv6/ > > Responses by March 29th are appreciated. > > Thanks, > Bernie and Tomek > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > --001a114118eac67660054baed6a2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Bernie,

Thanks a lot for your valua= ble comments. For the details, please see inline.

= Best Regards,
Lishan

2017-03-26 10:05 GMT+08:00 Bernie Volz (volz) <volz@cisco.co= m>:
Hi:<= br>
I have reviewed the draft and support it moving forward. However, I do have= some issues I think need to be addressed but they are mostly fairly small.=

I do want to thank the authors for addressing my earlier issues. I think th= e document is in MUCH better shape now!!

So here goes ...

Section 6:
The sentence: "The encryption text SHOULD be formatted as explain in [= RFC5652]." Isn't clear. RFC5652 doesn't use "text" e= xcept to mean actual wording in the RFC. Could "encryption text" = be clarified? Is this the client's message? Or what exactly is this and= which part of RFC 5652 has this "format"? I am not following wha= t this sentence means and what I should do (if I were implementing this).
Note: This same text is also in Section 7 (last paragraph) and needs simila= r attention.
[LS]: Sorry for the unclear expression. H= ow about the following text?
The DHCPv6 message sent from the cli= ent is encrypted and then encapsulated into the encrypted DHCPv6 message fi= eld according to the Encrypted-Data content syntax defined in the RFC5652.<= br>
=C2=A0

Section 7:

=C2=A0 =C2=A0option.=C2=A0 Then, the server checks the Server Identifier op= tion.=C2=A0 The
=C2=A0 =C2=A0DHCPv6 server drops the message that is not for it, thus not p= aying
=C2=A0 =C2=A0cost to decrypt messages.=C2=A0 If it is the target server, ac= cording to

I think here you also want the server to proceed if there is NO Server Iden= tifier option? It should only ignore it if there is a Server Identifier opt= ion and it does not match this server's identifier?
[LS]: Yes. Will modify it.=C2=A0

Section 8

=C2=A0 =C2=A0those present in the innermost encapsulated messages from the = client
=C2=A0 =C2=A0or server.

I think messages should just be message as there is only one message?
[LS]: Agree. Will modify it.=C2=A0

Section 9.1:

Might be better to split out requirements for a client and server into sepa= rate paragraphs (1st paragraph)? Might also be best to be clear that you ad= dress:
1. What a client must remember about its own increasing number (i.e., what = it sends to the server).
2. What a client must remember about the server's increasing number (i.= e., what it receives from server).
3. What a server must remember about a client's increasing number (i.e.= , what it receives from client).
4. What a server must remember about its own increasing number (i.e., what = it sends to clients). I assume a server does NOT need to keep a unique incr= easing number set for each client it communicates with - a server can use o= ne set for all clients?
Please also be clear about how each of these 4 (2 numbers on client, 2 on s= erver) are handled. The text presently is not very clear -- for example a c= lient can't forget what it sent if the server remembers it.
[LS]: Yes, the server just need to keep one set for all clients.= =C2=A0
How about the following modified text?
For clien= t, it MUST remember about its own increasing number, which is stored in the= NUM.STO and sent to the server. And the client also MUST remember about a = server's increasing number, which is received from the server and store= d in the NUM.REC. And the client keeps a record of the increasing number du= ring the DHCPv6 configuration process with the DHCPv6 server.=C2=A0 And the= client can forget the increasing number information after the transaction = is finished.=C2=A0 The client's initial locally stored increasing numbe= r is set to zero.

For server, it MUST remember abo= ut its own increasing number, which is stored in the NUM.STO and sent to th= e client. And the server also MUST remember about a client's increasing= number, which is received from the client and stored in the Num.REC. The s= erver just need to keep one increasing number set for all clients.

Later, be clear that this is modulo 2^64 math:

=C2=A0 =C2=A0The Increasing-number option in the received message passes th= e
=C2=A0 =C2=A0increasing number check if NUM.REC is more than NUM.STO.=C2=A0= And then,
=C2=A0 =C2=A0the value of NUM.STO is changed into the value of NUM.REC.

=C2=A0 =C2=A0The increasing number check fails if NUM.REC is equal with or = less
=C2=A0 =C2=A0than NUM.STO.

"More" here is in the modulo arithmetic "more" -- perha= ps use "more (modulo 2^64)" and "or less (modulo 2^64)"= ?
[LS]: Agree, will modify it.=C2=A0

Section 9.2:

I wonder if you should revise the code to make it more appropriate for this= document? RDATA/RDLENGTH aren't really appropriate?
[LS]: Got it. Will modify it.=C2=A0

Section 10

There are now only three (not six) status codes.
[LS]:= Will correct it.=C2=A0

Section 10.2

=C2=A0 =C2=A0msg-type=C2=A0 =C2=A0 =C2=A0 =C2=A0 Identifier of the message = type.=C2=A0 It can be either
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Encryp= ted-Query (TBA7) or DHCPv6-Response (TBA8).

Change DHCPv6-Response to Encrypted-Response.
[LS]: Wi= ll correct it.=C2=A0


Section 11

=C2=A0 =C2=A0There are some mandatory algorithm for encryption algorithm in= this

Change (first) algorithm to algorithms? Or, change "are some" to = "is a"
[LS]: Will change it.=C2=A0


=C2=A0 =C2=A0Likewise, since the Encryption-Key-Tag Option isn't protec= ted, an
=C2=A0 =C2=A0attacker that can intercept the message can forge the value wi= thout
=C2=A0 =C2=A0detection.

Isn't this generally useless? As the message is encrypted, the validati= on will fail?
[LS]: If the encryption-key-tag is forge= d, then the server may cannot decrypt it and drop the message.


Some even more MINOR comments (these would perhaps improve readability but = would likely be addressed by the RFC editor):
[LS]: So= rry for the poor expression. And thanks a lot your throughout check. Will c= orrect it in the next version.=C2=A0

Section 6:

Perhaps replace "contained" and "contain" with "in= cluded" and "include" in the sentences later in that same pa= ragraph (with the "The encryption text...").


=C2=A0 =C2=A0For the received Encrypted-Response message, the client MUST d= rop the
=C2=A0 =C2=A0Encrypted-Response message if other DHCPv6 option except Encry= pted-
=C2=A0 =C2=A0message option is contained.

How about:

=C2=A0 =C2=A0For the received Encrypted-Response message, the client MUST d= rop the
=C2=A0 =C2=A0Encrypted-Response message if it contains any option other tha= n a single
=C2=A0 =C2=A0Encrypted-message option.

Note: There are some other odd uses of contain (when at least I think the t= ext should use include). But it may not be worth trying to change these (th= e usage is tricky - you can google for "english contain vs include&quo= t; if you like). We will leave it to the RFC editor to perhaps clean these = up if appropriate.


=C2=A0 =C2=A0 =C2=A0 The client MAY use the AuthenticationFail as a hint an= d switch
=C2=A0 =C2=A0 =C2=A0 to other DHCPv6 server if it has another one.

Change to "to another DHCP server if it has one"?

Section 7:

=C2=A0 =C2=A0Upon the receipt of Encrypted-Query message, the server MUST d= rop the
=C2=A0 =C2=A0message if the other DHCPv6 option is contained except Server<= br>
Here "the other" should change to "another".

Note: There are several other places where contained/contain would (at leas= t in my mind) be more "standard" if the text used included/includ= e. Same goes for use of "other" (-> another).

Last paragraph of section 7, "then the server set the". Set shoul= d be sets.

Section 10.1.1

For EA-len, might be good to add "(must be a multiple of 2)"
For SHA-len, might be good to add "(must be a multiple of 4)"

Also, I think you should change all "2-octets value" to "2-o= ctet value".

Section 11

=C2=A0 =C2=A0For this security item, It is RECOMMENDED that client certific= ates
=C2=A0 =C2=A0could be tied to specific server certificates by configuration= .

Lower case "It"?


General

There are uses of "cert" and "certs" and "certific= ate(s)". Are these one in the same? Shouldn't we just use "ce= rtificate" throughout? Or perhaps you should add "cert(s)" t= o terminology section?


- Bernie

-----Original Message-----
From: dhcwg [mailto:dhcwg-bounces= @ietf.org] On Behalf Of Tomek Mrugalski
Sent: Wednesday, March 08, 2017 8:37 AM
To: dhcwg <dhcwg@ietf.org>
Cc: draft-ietf-dhc-sedhcpv6 authors <draft-ietf-dhc-sedhcpv6@ietf.org>
Subject: [dhcwg] WGLC on draft-ietf-dhc-sedhcpv6-21 - Respond by March 29th=

Hi,
draft-ietf-dhc-sedhcpv6-21 describes a mechanism for using public key crypt= ography to provide end-to-end security between DHCPv6 clients and servers. = The mechanism provides encryption in all cases, and can be used for authent= ication based on pre-sharing of authorized certificates. This draft has sta= rted in 2013, but the whole DHCPv6 security saga is much longer and begins = in 2008. This draft was submitted to IESG in mid-2015.
The guidance received was clear that=C2=A0 substantial changes are needed. = As a result, "encrypt everywhere, authenticate if you can" approa= ch was used.

Authors believe this draft to be ready for working group last call.

Please send your substantial comments to the mailing list and express your = opinion whether this draft is ready for publication. Feel free to send nitp= icks and minor corrections to the authors directly. This is a complex draft= , so the chairs believe 3 weeks WGLC is in order. Please send your comments= no later than March 29th. Bernie and I will determine consensus and will d= iscuss during Chicago meeting as needed.

To initiate the discussion, I have two related questions. The chairs would = love to hear your opinions on those.

1. The "encrypt everywhere" paradigm means that in deployments th= at do snooping on relay will break down. To solve this problem, we need a a= ssignment notification mechanism, similar to the one described in draft-iet= f-dhc-dhcpv6-agentopt-delegate-04. That draft expired many years ago. = This matter was discussed in Seoul and the minutes describe the conclusion = as:

=C2=A0 The discussion gravitated towards not resurrecting until the sedhcpv= 6
=C2=A0 I-D progresses further. We will reevaluate this once sedhcpv6 is don= e.

Do you want the WG to resurrect agentopt-delegate a) now, b) when
sedhcpv6 is sent to IESG or c) when sedhcpv6 is published as RFC? d) we nee= d a completely new draft and I'm volunteering to work on it.

2. One of the authors suggested that this protocol is quite complex and hav= ing a feedback from an implementation (or ideally two interoperating) would= be very important and would likely result in some changes to the draft. It= 's probably too late for Chicago, but we can organize a
sedhcpv6 hackathon in Prague. Two likely implementations would be WIDE and = Kea, as those two are open source and have an old version of the draft part= ially implemented. Do you think such a hackathon would be useful? Are you w= illing to participate?

Title: Secure DHCPv6
Authors: L. Li, S. Jiang, Y.Cui, T.Jinmei, T.Lemon, D.Zhang
Filename: draft-ietf-dhc-sedhcpv6-21
Pages: 31
Date: 2017-02-21
Link: https://datatracker.ietf.org/doc= /draft-ietf-dhc-sedhcpv6/

Responses by March 29th are appreciated.

Thanks,
Bernie and Tomek

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg

--001a114118eac67660054baed6a2-- From nobody Mon Mar 27 07:07:56 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A848129415; Mon, 27 Mar 2017 07:07:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 U-gE_z4n8vdv; Mon, 27 Mar 2017 07:07:51 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C927D126FDC; Mon, 27 Mar 2017 07:07:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=81032; q=dns/txt; s=iport; t=1490623669; x=1491833269; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=WFxew18TxF2cfK5bLEoE1qHppckaBMb5lCA1ueVW6a8=; b=RC5CwYCRnPHXnFc4ftnWi+KKSUK2tg3V7D2U3mWs5/Sw6Oejr/t1z6/L Ce32CJYR+0Mluuz5v0LLcxC7GSiAdoZ8YNrxObQuTO0TG7t1hRXKieYUS /OtYKCwzX0mJFJrmyOg6CNgn9k0X/7veuwerVNwzIDVVVxK5yhFkXif65 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AFAgCuG9lY/49dJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm47K2GBCweDW4oPkU2IF400ggsDHwEKhXgCGoJ5PxgBAgEBAQE?= =?us-ascii?q?BAQFrKIUVAQEBAQMBARgBCAQGPgMLDAQCAQYCEQMBAQEhAQYDAgICHwYLFAkIA?= =?us-ascii?q?gQOBYlvAxUOjW2dW4FsOiuHAA2DAwEBAQEBAQEBAQEBAQEBAQEBAQEBARgFiFO?= =?us-ascii?q?BYYEJgTyBFYFtAisJDAqCUC6CMQWGa4IriBeEX4YVOgGGeoMqgydKhDaBfIUqi?= =?us-ascii?q?guKbYh3AR84SzlZFRgpEQGEQwMNEIFjdQGGeAEkB4EDgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.36,231,1486425600"; d="scan'208,217";a="225336531" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Mar 2017 14:07:47 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v2RE7ll2007161 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 27 Mar 2017 14:07:47 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 27 Mar 2017 09:07:46 -0500 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1210.000; Mon, 27 Mar 2017 09:07:46 -0500 From: "Bernie Volz (volz)" To: Lishan Li CC: Tomek Mrugalski , dhcwg , draft-ietf-dhc-sedhcpv6 authors Thread-Topic: [dhcwg] WGLC on draft-ietf-dhc-sedhcpv6-21 - Respond by March 29th Thread-Index: AQHSmBEofEj8/aGJckKkKaGWH1j71aGmX41wgAIqkgCAAF2FgA== Date: Mon, 27 Mar 2017 14:07:46 +0000 Message-ID: <369C97B6-B6E7-46CE-B42E-18559BFB1E78@cisco.com> References: <7db55e6f55e34408a1816887c22e28d3@XCH-ALN-003.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1f.0.170216 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.249.7] Content-Type: multipart/alternative; boundary="_000_369C97B6B6E746CEB42E18559BFB1E78ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-sedhcpv6-21 - Respond by March 29th X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 14:07:55 -0000 --_000_369C97B6B6E746CEB42E18559BFB1E78ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGk6DQoNClRoZSBzZW50ZW5jZTogIlRoZSBlbmNyeXB0aW9uIHRleHQgU0hPVUxEIGJlIGZvcm1h dHRlZCBhcyBleHBsYWluIGluIFtSRkM1NjUyXS4iIElzbid0IGNsZWFyLiBSRkM1NjUyIGRvZXNu J3QgdXNlICJ0ZXh0IiBleGNlcHQgdG8gbWVhbiBhY3R1YWwgd29yZGluZyBpbiB0aGUgUkZDLiBD b3VsZCAiZW5jcnlwdGlvbiB0ZXh0IiBiZSBjbGFyaWZpZWQ/IElzIHRoaXMgdGhlIGNsaWVudCdz IG1lc3NhZ2U/IE9yIHdoYXQgZXhhY3RseSBpcyB0aGlzIGFuZCB3aGljaCBwYXJ0IG9mIFJGQyA1 NjUyIGhhcyB0aGlzICJmb3JtYXQiPyBJIGFtIG5vdCBmb2xsb3dpbmcgd2hhdCB0aGlzIHNlbnRl bmNlIG1lYW5zIGFuZCB3aGF0IEkgc2hvdWxkIGRvIChpZiBJIHdlcmUgaW1wbGVtZW50aW5nIHRo aXMpLg0KDQpOb3RlOiBUaGlzIHNhbWUgdGV4dCBpcyBhbHNvIGluIFNlY3Rpb24gNyAobGFzdCBw YXJhZ3JhcGgpIGFuZCBuZWVkcyBzaW1pbGFyIGF0dGVudGlvbi4NCltMU106IFNvcnJ5IGZvciB0 aGUgdW5jbGVhciBleHByZXNzaW9uLiBIb3cgYWJvdXQgdGhlIGZvbGxvd2luZyB0ZXh0Pw0KVGhl IERIQ1B2NiBtZXNzYWdlIHNlbnQgZnJvbSB0aGUgY2xpZW50IGlzIGVuY3J5cHRlZCBhbmQgdGhl biBlbmNhcHN1bGF0ZWQgaW50byB0aGUgZW5jcnlwdGVkIERIQ1B2NiBtZXNzYWdlIGZpZWxkIGFj Y29yZGluZyB0byB0aGUgRW5jcnlwdGVkLURhdGEgY29udGVudCBzeW50YXggZGVmaW5lZCBpbiB0 aGUgUkZDNTY1Mi4NCg0KDQpCVj4gSSBhc3N1bWUgdGhpcyByZWZlcmVuY2UgaXMgdG8gc2VjdGlv biA4IG9mIFJGQyA1NjUyLiBCdXQgbm93IHRoZSBxdWVzdGlvbiBpcyB3aGV0aGVyIGFueXRoaW5n IGZ1cnRoZXIgbmVlZHMgdG8gYmUgZGVmaW5lZCDigJMgZm9yIGV4YW1wbGUsIHdoYXQgKG9wdGlv bmFsKSBhdHRyaWJ1dGVzIHNob3VsZCBiZSBpbmNsdWRlZD8gUGVyaGFwcyBhcyBJ4oCZbSBub3Qg YSBzZWN1cml0eSBleHBlcnQgb3IgaGF2ZSBjYXJlZnVsbHkgcmV2aWV3ZWQgUkZDNTY1MiBhbmQg YW0gdGFraW5nIGEgZmV3IHRoaW5ncyDigJxvdXQgb2YgY29udGVudOKAnSB3aGVuIGxvb2tpbmcg YXQgaXQsIGJ1dCBJIHRoaW5rIHNvbWUgY2xhcml0eSBoZXJlIG1heSBoZWxwIGluIG1ha2Ugc3Vy ZSB0aGlzIGlzIGVhc3kgdG8gaW1wbGVtZW50IChlc3BlY2lhbGx5IGZvciBzb21lIG9mIHVzIHRo YXQgbWF5IG5vdCBiZSBleHBlcnRzIGluIGNyeXB0b2dyYXBoeSkuIFRoaXMgaXMgYSBiaXQgbW9y ZSBjb21wbGV4IHRoYW4ganVzdCB0YWtpbmcgdGhlIGJ5dGVzIG9mIHRoZSBjbGllbnTigJlzIHVu ZW5jcnlwdGVkIG1lc3NhZ2UgYW5kIHRoZSBwcml2YXRlIGtleSB0byBlbmNyeXB0IChhbmQgcGxh Y2luZyB0aGF0IGludG8gdGhlIEVuY3J5cHRlZC1tZXNzYWdlIE9wdGlvbiksIGFuZCB0YWtpbmcg dGhlIGVuY3J5cHRlZCBjbGllbnTigJlzIG1lc3NhZ2UgYnl0ZXMgKGZyb20gYSByZWNlaXZlZCBF bmNyeXB0ZWQtbWVzc2FnZSBPcHRpb24pIGFuZCBkZWNyeXB0aW5nIHdpdGggdGhlIHB1YmxpYyBr ZXk/IFlvdSBtYXkgd2FudCB0byB0aGluayBhYm91dCB3aGV0aGVyIHBlcmhhcHMgc3BlY2lmeWlu ZyB0aGUgZGV0YWlscyBhcHByb3ByaWF0ZSB0byBESENQdjYgdXNhZ2UgaXMgYXBwcm9wcmlhdGUg 4oCTIHBlcmhhcHMgZXZlbiBpbiBhbiBhcHBlbmRpeD8gUkZDNTY1MiB0YWxrcyBhYm91dDoNCg0K QW5kIHRoZXJl4oCZcyBhIGxvdCBhYm91dCBBU04uMSBhbmQgT0lEcyBpbiBSRkM1NjUyLCBzbyBh cmUgeW91IHB1bGxpbmcgaW4gYWxsIG9mIHRoaXM/DQoNCiAgIFRoZSBmb2xsb3dpbmcgb2JqZWN0 IGlkZW50aWZpZXIgaWRlbnRpZmllcyB0aGUgZW5jcnlwdGVkLWRhdGEgY29udGVudA0KICAgdHlw ZToNCg0KICAgICAgaWQtZW5jcnlwdGVkRGF0YSBPQkpFQ1QgSURFTlRJRklFUiA6Oj0geyBpc28o MSkgbWVtYmVyLWJvZHkoMikNCiAgICAgICAgICB1cyg4NDApIHJzYWRzaSgxMTM1NDkpIHBrY3Mo MSkgcGtjczcoNykgNiB9DQoNCiAgIFRoZSBlbmNyeXB0ZWQtZGF0YSBjb250ZW50IHR5cGUgc2hh bGwgaGF2ZSBBU04uMSB0eXBlIEVuY3J5cHRlZERhdGE6DQoNCiAgICAgIEVuY3J5cHRlZERhdGEg Ojo9IFNFUVVFTkNFIHsNCiAgICAgICAgdmVyc2lvbiBDTVNWZXJzaW9uLA0KICAgICAgICBlbmNy eXB0ZWRDb250ZW50SW5mbyBFbmNyeXB0ZWRDb250ZW50SW5mbywNCiAgICAgICAgdW5wcm90ZWN0 ZWRBdHRycyBbMV0gSU1QTElDSVQgVW5wcm90ZWN0ZWRBdHRyaWJ1dGVzIE9QVElPTkFMIH0NCg0K ICAgVGhlIGZpZWxkcyBvZiB0eXBlIEVuY3J5cHRlZERhdGEgaGF2ZSB0aGUgZm9sbG93aW5nIG1l YW5pbmdzOg0KDQogICAgICB2ZXJzaW9uIGlzIHRoZSBzeW50YXggdmVyc2lvbiBudW1iZXIuICBJ ZiB1bnByb3RlY3RlZEF0dHJzIGlzDQogICAgICBwcmVzZW50LCB0aGVuIHRoZSB2ZXJzaW9uIE1V U1QgYmUgMi4gIElmIHVucHJvdGVjdGVkQXR0cnMgaXMNCiAgICAgIGFic2VudCwgdGhlbiB2ZXJz aW9uIE1VU1QgYmUgMC4NCg0KICAgICAgZW5jcnlwdGVkQ29udGVudEluZm8gaXMgdGhlIGVuY3J5 cHRlZCBjb250ZW50IGluZm9ybWF0aW9uLCBhcw0KICAgICAgZGVmaW5lZCBpbiBTZWN0aW9uIDYu MTxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTY1MiNzZWN0aW9uLTYuMT4uDQoNCiAg ICAgIHVucHJvdGVjdGVkQXR0cnMgaXMgYSBjb2xsZWN0aW9uIG9mIGF0dHJpYnV0ZXMgdGhhdCBh cmUgbm90DQogICAgICBlbmNyeXB0ZWQuICBUaGUgZmllbGQgaXMgb3B0aW9uYWwuICBVc2VmdWwg YXR0cmlidXRlIHR5cGVzIGFyZQ0KICAgICAgZGVmaW5lZCBpbiBTZWN0aW9uIDExPGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1NjUyI3NlY3Rpb24tMTE+Lg0KDQpQcm9iYWJseSBzZWN0 aW9uIDYuMSBpcyBtb3N0IGFwcGxpY2FibGUgYW5kIHRoZXJlIHdlIGhhdmUgKGV2ZW50dWFsbHkp Og0KDQoNCiAgICBFbmNyeXB0ZWRDb250ZW50IDo6PSBPQ1RFVCBTVFJJTkcNCg0KV2hpY2ggbWF5 IGJlIGFsbCB3ZSByZWFsbHkgbmVlZD8NCg0KQW5kLCBpZiBzbywgd2hhdCBpcyB0aGUgdmFsdWUg aW4gcmVmZXJlbmNpbmcgdGhpcyBSRkM/DQoNCkFnYWluLCBJ4oCZbSBqdXN0IHRyeWluZyB0byB1 bmRlcnN0YW5kIHRoaXMgbW9yZSBjb21wbGV0ZWx5IOKAkyB3aGF0IGV4YWN0bHkgaXMgaW5zaWRl IHRoZSBFbmNyeXB0ZWQtbWVzc2FnZSBvcHRpb24/DQoNCg0KDQpbTFNdOiBZZXMsIHRoZSBzZXJ2 ZXIganVzdCBuZWVkIHRvIGtlZXAgb25lIHNldCBmb3IgYWxsIGNsaWVudHMuDQpIb3cgYWJvdXQg dGhlIGZvbGxvd2luZyBtb2RpZmllZCB0ZXh0Pw0KRm9yIGNsaWVudCwgaXQgTVVTVCByZW1lbWJl ciBhYm91dCBpdHMgb3duIGluY3JlYXNpbmcgbnVtYmVyLCB3aGljaCBpcyBzdG9yZWQgaW4gdGhl IE5VTS5TVE8gYW5kIHNlbnQgdG8gdGhlIHNlcnZlci4gQW5kIHRoZSBjbGllbnQgYWxzbyBNVVNU IHJlbWVtYmVyIGFib3V0IGEgc2VydmVyJ3MgaW5jcmVhc2luZyBudW1iZXIsIHdoaWNoIGlzIHJl Y2VpdmVkIGZyb20gdGhlIHNlcnZlciBhbmQgc3RvcmVkIGluIHRoZSBOVU0uUkVDLiBBbmQgdGhl IGNsaWVudCBrZWVwcyBhIHJlY29yZCBvZiB0aGUgaW5jcmVhc2luZyBudW1iZXIgZHVyaW5nIHRo ZSBESENQdjYgY29uZmlndXJhdGlvbiBwcm9jZXNzIHdpdGggdGhlIERIQ1B2NiBzZXJ2ZXIuICBB bmQgdGhlIGNsaWVudCBjYW4gZm9yZ2V0IHRoZSBpbmNyZWFzaW5nIG51bWJlciBpbmZvcm1hdGlv biBhZnRlciB0aGUgdHJhbnNhY3Rpb24gaXMgZmluaXNoZWQuICBUaGUgY2xpZW50J3MgaW5pdGlh bCBsb2NhbGx5IHN0b3JlZCBpbmNyZWFzaW5nIG51bWJlciBpcyBzZXQgdG8gemVyby4NCg0KRm9y IHNlcnZlciwgaXQgTVVTVCByZW1lbWJlciBhYm91dCBpdHMgb3duIGluY3JlYXNpbmcgbnVtYmVy LCB3aGljaCBpcyBzdG9yZWQgaW4gdGhlIE5VTS5TVE8gYW5kIHNlbnQgdG8gdGhlIGNsaWVudC4g QW5kIHRoZSBzZXJ2ZXIgYWxzbyBNVVNUIHJlbWVtYmVyIGFib3V0IGEgY2xpZW50J3MgaW5jcmVh c2luZyBudW1iZXIsIHdoaWNoIGlzIHJlY2VpdmVkIGZyb20gdGhlIGNsaWVudCBhbmQgc3RvcmVk IGluIHRoZSBOdW0uUkVDLiBUaGUgc2VydmVyIGp1c3QgbmVlZCB0byBrZWVwIG9uZSBpbmNyZWFz aW5nIG51bWJlciBzZXQgZm9yIGFsbCBjbGllbnRzLg0KDQpCVj4gSGVyZSBhZ2FpbiwgcGxlYXNl IGJlIGNhcmVmdWw6DQoNCjEuICAgICAgIElmIGNsaWVudCBhbHdheXMgc3RhcnRzIGF0IDAsIGhv dyBkb2VzIHRoYXQgaGVscCBpbiBwcmV2ZW50aW5nIHJlcGxheT8gQW5kLCB0aGlzIGlzbuKAmXQg Y29uc2lzdGVudCB3aXRoIHRoZSBzZXJ2ZXLigJlzIGJlaGF2aW9yIGFib3ZlPw0KDQoyLiAgICAg ICBJZiBjbGllbnQgZG9lc27igJl0IHBlcnNpc3QgdGhpcywgd2hhdCBoYXBwZW5zIGlmIHNlcnZl ciBoYXMgYSBsZWFzZSBmb3IgdGhlIGNsaWVudCAoYW5kIGhhcyByZXRhaW5lZCB0aGUgcmVwbGF5 IG51bWJlcnMpIGJ1dCB0aGUgY2xpZW50IHJlbGVhc2VkIChvciBvdGhlcndpc2UgZGVsZXRlZCB0 aGUgbGVhc2UpLiBOb3cgd2hlbiB0aGUgY2xpZW50IFNvbGljaXRzIChlbmNyeXB0ZWQpLCB0aGUg c2VydmVyIHdvdWxkIHJlcG9ydCB0aGF0IHRoaXMgaXMgYSBwb3RlbnRpYWwgcmVwbGF5IGF0dGFj aD8gSSBkb27igJl0IHRoaW5rIGRyb3BwaW5nIHRoaXMgaW5mb3JtYXRpb24g4oCcYWZ0ZXIgdGhl IHRyYW5zYWN0aW9uIGlzIGZpbmlzaGVk4oCdIGlzIHBvc3NpYmxlLg0KDQozLiAgICAgICBGb3Ig 4oCcVGhlIHNlcnZlciBqdXN0IG5lZWQgdG8ga2VlcCBvbmUgaW5jcmVhc2luZyBudW1iZXIgc2V0 IGZvciBhbGwgY2xpZW50c+KAnSDigJMgc2hvdWxkbuKAmXQgdGhhdCBiZSBhZnRlciB0aGUgZmly c3Qgc2VudGVuY2UgYXMgdGhpcyBhcHBsaWVzIHRvIE5VTS5TVE87IG5vdCBOVU0uUkVDPw0KVGh1 cywgSSB0aGluayB0aGUgY2xpZW50IG11c3QgcmV0YWluIHRoZSBudW1iZXIgaXQgbGFzdCB1c2Vk IHdpdGggYSBzZXJ2ZXIuIFRoaXMgc2VlbXMgdG8gYmUgYW4gaXNzdWUgZm9yIGRldmljZXMgd2l0 aG91dCBwZXJzaXN0ZW50IHN0b3JhZ2UsIHNvIG1heSByZXF1aXJlIHNvbWUgZnVydGhlciB0aG91 Z2h0IOKAkyBvciB0aG9zZSBkZXZpY2VzIGNhbm5vdCB1c2UgaW5jcmVhc2luZyBudW1iZXI/DQoN CkFuZCwgSSB0aGluayBib3RoIGhhdmluZyB0byByZXRhaW4gdGhpcyBmb3JldmVyIHdvdWxkIGJl IGEgYmFkIGlkZWEuIEkgdGhpbmsgb25lIGNvdWxkIHByb3ZpZGUgZm9yIGJvdGggY2xpZW50cyBh bmQgc2VydmVycyB0byDigJxmb3JnZXTigJ0gYW55IHN0b3JlZCBpbmZvcm1hdGlvbiBhZnRlciBh IHBlcmlvZCBvZiB0aW1lIChwZXJoYXBzIHRoaXMgY2FuIGJlIGEgZml4ZWQgbnVtYmVyLCAzMCBk YXlzLCBvciBzaG91bGQgYmUgc29tZSBtdWx0aXBsZSBvZiB0aGUgbGVhc2UgbGlmZXRpbWUpPw0K DQoNCiAgIExpa2V3aXNlLCBzaW5jZSB0aGUgRW5jcnlwdGlvbi1LZXktVGFnIE9wdGlvbiBpc24n dCBwcm90ZWN0ZWQsIGFuDQogICBhdHRhY2tlciB0aGF0IGNhbiBpbnRlcmNlcHQgdGhlIG1lc3Nh Z2UgY2FuIGZvcmdlIHRoZSB2YWx1ZSB3aXRob3V0DQogICBkZXRlY3Rpb24uDQoNCklzbid0IHRo aXMgZ2VuZXJhbGx5IHVzZWxlc3M/IEFzIHRoZSBtZXNzYWdlIGlzIGVuY3J5cHRlZCwgdGhlIHZh bGlkYXRpb24gd2lsbCBmYWlsPw0KW0xTXTogSWYgdGhlIGVuY3J5cHRpb24ta2V5LXRhZyBpcyBm b3JnZWQsIHRoZW4gdGhlIHNlcnZlciBtYXkgY2Fubm90IGRlY3J5cHQgaXQgYW5kIGRyb3AgdGhl IG1lc3NhZ2UuDQoNCkJWPiBSaWdodCwgYnV0IGlzbuKAmXQgdGhhdCBleGFjdGx5IHdoYXQgd2Ug d291bGQgd2FudD8gU28sIGhvdyBpcyB0aGlzIGJhZD8NCg0KDQpCVj4gUmUgU2VjdXJpdHkgQ29u c2lkZXJhdGlvbnMgLSBBIG5ldyBjb21tZW50IGZyb20gYSBjb252ZXJzYXRpb24gd2l0aCBUb21l ayAoVG9tZWsgd2lsbCBob3BlZnVsbHkgY29tbWVudCBtb3JlKS4gSSBtZW50aW9uZWQgdGhhdCBJ IHdhcyBjb25jZXJuZWQgd2l0aCB0aGUgcG9zc2liaWxpdHkgb2YgY2xpZW50cyBhbmQgc2VydmVy cyBnZXR0aW5nIOKAnGp1bmvigJ0gaXMgYSBzZWN1cml0eSBjb25jZXJuIGFzIHNvbWVvbmUgY291 bGQgZ2VuZXJhdGUgYmFkIHBhY2tldHMgd2l0aCBlbmNyeXB0ZWQgZGF0YSBhbmQgc2VuZCB0aGVt IHRvIGNsaWVudHMgYW5kIHNlcnZlcnMgaW4gdGhlIGhvcGUgdG8gY3Jhc2ggdGhlIGVpdGhlciB3 aGVuIHRoZXkgdHJ5IHRvIGRlY3J5cHQgYW5kIHRoZW4gcHJvY2VzcyBqdW5rLiBUb21layBzdWdn ZXN0ZWQgd2UgbWlnaHQgd2FudCB0byB0aGluayBhYm91dCB3aGV0aGVyIHRvIGFkZCBzb21lIG1h Z2ljIHZhbHVlIHRvIHRoZSBmaXJzdCBmZXcgYnl0ZXMgb2YgYSBtZXNzYWdlIGJlZm9yZSBlbmNy eXB0aW5nIGl0IGFuZCB0aGVuIHRoZSBkZWNyeXB0ZXIgY2FuIGNoZWNrIHRob3NlIGZpcnN0IGZl dyBieXRlcyB0byBzZWUgaWYgdGhleSBhcmUgdmFsdWUgYW5kIGRpc2NhcmQgdGhlIG1lc3NhZ2Ug aWYgbm90LiBQZXJoYXBzIHRoZSBlbmNvZGluZyBmcm9tIFJGQzU2NTIgd291bGQgYWNjb21wbGlz aCB0aGlzIGlmIHdlIGFyZSB1c2luZyBtb3JlIHRoYW4ganVzdCB0aGUgZW5jcnlwdGVkQ29udGVu dD8gQW55d2F5LCBzb21ldGhpbmcgdG8gdGhpbmsgYWJvdXQuDQoNCg0KQWdhaW4sIHRoYW5rcyBm b3IgeW91ciBjb250aW51ZWQgZWZmb3J0cyBvbiB0aGlzIGRvY3VtZW50IQ0KDQoNCi0gICAgICAg ICAgQmVybmllDQoNCkZyb206IExpc2hhbiBMaSA8bGlsaXNoYW40OEBnbWFpbC5jb20+DQpEYXRl OiBNb25kYXksIE1hcmNoIDI3LCAyMDE3IGF0IDEyOjMzIEFNDQpUbzogQmVybmllIFZvbHogPHZv bHpAY2lzY28uY29tPg0KQ2M6IFRvbWVrIE1ydWdhbHNraSA8dG9tYXN6Lm1ydWdhbHNraUBnbWFp bC5jb20+LCAiZGhjd2dAaWV0Zi5vcmciIDxkaGN3Z0BpZXRmLm9yZz4sIGRyYWZ0LWlldGYtZGhj LXNlZGhjcHY2IGF1dGhvcnMgPGRyYWZ0LWlldGYtZGhjLXNlZGhjcHY2QGlldGYub3JnPg0KU3Vi amVjdDogUmU6IFtkaGN3Z10gV0dMQyBvbiBkcmFmdC1pZXRmLWRoYy1zZWRoY3B2Ni0yMSAtIFJl c3BvbmQgYnkgTWFyY2ggMjl0aA0KDQpIaSwgQmVybmllLA0KDQpUaGFua3MgYSBsb3QgZm9yIHlv dXIgdmFsdWFibGUgY29tbWVudHMuIEZvciB0aGUgZGV0YWlscywgcGxlYXNlIHNlZSBpbmxpbmUu DQoNCkJlc3QgUmVnYXJkcywNCkxpc2hhbg0KDQoyMDE3LTAzLTI2IDEwOjA1IEdNVCswODowMCBC ZXJuaWUgVm9seiAodm9seikgPHZvbHpAY2lzY28uY29tPG1haWx0bzp2b2x6QGNpc2NvLmNvbT4+ Og0KSGk6DQoNCkkgaGF2ZSByZXZpZXdlZCB0aGUgZHJhZnQgYW5kIHN1cHBvcnQgaXQgbW92aW5n IGZvcndhcmQuIEhvd2V2ZXIsIEkgZG8gaGF2ZSBzb21lIGlzc3VlcyBJIHRoaW5rIG5lZWQgdG8g YmUgYWRkcmVzc2VkIGJ1dCB0aGV5IGFyZSBtb3N0bHkgZmFpcmx5IHNtYWxsLg0KDQpJIGRvIHdh bnQgdG8gdGhhbmsgdGhlIGF1dGhvcnMgZm9yIGFkZHJlc3NpbmcgbXkgZWFybGllciBpc3N1ZXMu IEkgdGhpbmsgdGhlIGRvY3VtZW50IGlzIGluIE1VQ0ggYmV0dGVyIHNoYXBlIG5vdyEhDQoNClNv IGhlcmUgZ29lcyAuLi4NCg0KU2VjdGlvbiA2Og0KVGhlIHNlbnRlbmNlOiAiVGhlIGVuY3J5cHRp b24gdGV4dCBTSE9VTEQgYmUgZm9ybWF0dGVkIGFzIGV4cGxhaW4gaW4gW1JGQzU2NTJdLiIgSXNu J3QgY2xlYXIuIFJGQzU2NTIgZG9lc24ndCB1c2UgInRleHQiIGV4Y2VwdCB0byBtZWFuIGFjdHVh bCB3b3JkaW5nIGluIHRoZSBSRkMuIENvdWxkICJlbmNyeXB0aW9uIHRleHQiIGJlIGNsYXJpZmll ZD8gSXMgdGhpcyB0aGUgY2xpZW50J3MgbWVzc2FnZT8gT3Igd2hhdCBleGFjdGx5IGlzIHRoaXMg YW5kIHdoaWNoIHBhcnQgb2YgUkZDIDU2NTIgaGFzIHRoaXMgImZvcm1hdCI/IEkgYW0gbm90IGZv bGxvd2luZyB3aGF0IHRoaXMgc2VudGVuY2UgbWVhbnMgYW5kIHdoYXQgSSBzaG91bGQgZG8gKGlm IEkgd2VyZSBpbXBsZW1lbnRpbmcgdGhpcykuDQoNCk5vdGU6IFRoaXMgc2FtZSB0ZXh0IGlzIGFs c28gaW4gU2VjdGlvbiA3IChsYXN0IHBhcmFncmFwaCkgYW5kIG5lZWRzIHNpbWlsYXIgYXR0ZW50 aW9uLg0KW0xTXTogU29ycnkgZm9yIHRoZSB1bmNsZWFyIGV4cHJlc3Npb24uIEhvdyBhYm91dCB0 aGUgZm9sbG93aW5nIHRleHQ/DQpUaGUgREhDUHY2IG1lc3NhZ2Ugc2VudCBmcm9tIHRoZSBjbGll bnQgaXMgZW5jcnlwdGVkIGFuZCB0aGVuIGVuY2Fwc3VsYXRlZCBpbnRvIHRoZSBlbmNyeXB0ZWQg REhDUHY2IG1lc3NhZ2UgZmllbGQgYWNjb3JkaW5nIHRvIHRoZSBFbmNyeXB0ZWQtRGF0YSBjb250 ZW50IHN5bnRheCBkZWZpbmVkIGluIHRoZSBSRkM1NjUyLg0KDQoNClNlY3Rpb24gNzoNCg0KICAg b3B0aW9uLiAgVGhlbiwgdGhlIHNlcnZlciBjaGVja3MgdGhlIFNlcnZlciBJZGVudGlmaWVyIG9w dGlvbi4gIFRoZQ0KICAgREhDUHY2IHNlcnZlciBkcm9wcyB0aGUgbWVzc2FnZSB0aGF0IGlzIG5v dCBmb3IgaXQsIHRodXMgbm90IHBheWluZw0KICAgY29zdCB0byBkZWNyeXB0IG1lc3NhZ2VzLiAg SWYgaXQgaXMgdGhlIHRhcmdldCBzZXJ2ZXIsIGFjY29yZGluZyB0bw0KDQpJIHRoaW5rIGhlcmUg eW91IGFsc28gd2FudCB0aGUgc2VydmVyIHRvIHByb2NlZWQgaWYgdGhlcmUgaXMgTk8gU2VydmVy IElkZW50aWZpZXIgb3B0aW9uPyBJdCBzaG91bGQgb25seSBpZ25vcmUgaXQgaWYgdGhlcmUgaXMg YSBTZXJ2ZXIgSWRlbnRpZmllciBvcHRpb24gYW5kIGl0IGRvZXMgbm90IG1hdGNoIHRoaXMgc2Vy dmVyJ3MgaWRlbnRpZmllcj8NCltMU106IFllcy4gV2lsbCBtb2RpZnkgaXQuDQoNClNlY3Rpb24g OA0KDQogICB0aG9zZSBwcmVzZW50IGluIHRoZSBpbm5lcm1vc3QgZW5jYXBzdWxhdGVkIG1lc3Nh Z2VzIGZyb20gdGhlIGNsaWVudA0KICAgb3Igc2VydmVyLg0KDQpJIHRoaW5rIG1lc3NhZ2VzIHNo b3VsZCBqdXN0IGJlIG1lc3NhZ2UgYXMgdGhlcmUgaXMgb25seSBvbmUgbWVzc2FnZT8NCltMU106 IEFncmVlLiBXaWxsIG1vZGlmeSBpdC4NCg0KU2VjdGlvbiA5LjE6DQoNCk1pZ2h0IGJlIGJldHRl ciB0byBzcGxpdCBvdXQgcmVxdWlyZW1lbnRzIGZvciBhIGNsaWVudCBhbmQgc2VydmVyIGludG8g c2VwYXJhdGUgcGFyYWdyYXBocyAoMXN0IHBhcmFncmFwaCk/IE1pZ2h0IGFsc28gYmUgYmVzdCB0 byBiZSBjbGVhciB0aGF0IHlvdSBhZGRyZXNzOg0KMS4gV2hhdCBhIGNsaWVudCBtdXN0IHJlbWVt YmVyIGFib3V0IGl0cyBvd24gaW5jcmVhc2luZyBudW1iZXIgKGkuZS4sIHdoYXQgaXQgc2VuZHMg dG8gdGhlIHNlcnZlcikuDQoyLiBXaGF0IGEgY2xpZW50IG11c3QgcmVtZW1iZXIgYWJvdXQgdGhl IHNlcnZlcidzIGluY3JlYXNpbmcgbnVtYmVyIChpLmUuLCB3aGF0IGl0IHJlY2VpdmVzIGZyb20g c2VydmVyKS4NCjMuIFdoYXQgYSBzZXJ2ZXIgbXVzdCByZW1lbWJlciBhYm91dCBhIGNsaWVudCdz IGluY3JlYXNpbmcgbnVtYmVyIChpLmUuLCB3aGF0IGl0IHJlY2VpdmVzIGZyb20gY2xpZW50KS4N CjQuIFdoYXQgYSBzZXJ2ZXIgbXVzdCByZW1lbWJlciBhYm91dCBpdHMgb3duIGluY3JlYXNpbmcg bnVtYmVyIChpLmUuLCB3aGF0IGl0IHNlbmRzIHRvIGNsaWVudHMpLiBJIGFzc3VtZSBhIHNlcnZl ciBkb2VzIE5PVCBuZWVkIHRvIGtlZXAgYSB1bmlxdWUgaW5jcmVhc2luZyBudW1iZXIgc2V0IGZv ciBlYWNoIGNsaWVudCBpdCBjb21tdW5pY2F0ZXMgd2l0aCAtIGEgc2VydmVyIGNhbiB1c2Ugb25l IHNldCBmb3IgYWxsIGNsaWVudHM/DQpQbGVhc2UgYWxzbyBiZSBjbGVhciBhYm91dCBob3cgZWFj aCBvZiB0aGVzZSA0ICgyIG51bWJlcnMgb24gY2xpZW50LCAyIG9uIHNlcnZlcikgYXJlIGhhbmRs ZWQuIFRoZSB0ZXh0IHByZXNlbnRseSBpcyBub3QgdmVyeSBjbGVhciAtLSBmb3IgZXhhbXBsZSBh IGNsaWVudCBjYW4ndCBmb3JnZXQgd2hhdCBpdCBzZW50IGlmIHRoZSBzZXJ2ZXIgcmVtZW1iZXJz IGl0Lg0KW0xTXTogWWVzLCB0aGUgc2VydmVyIGp1c3QgbmVlZCB0byBrZWVwIG9uZSBzZXQgZm9y IGFsbCBjbGllbnRzLg0KSG93IGFib3V0IHRoZSBmb2xsb3dpbmcgbW9kaWZpZWQgdGV4dD8NCkZv ciBjbGllbnQsIGl0IE1VU1QgcmVtZW1iZXIgYWJvdXQgaXRzIG93biBpbmNyZWFzaW5nIG51bWJl ciwgd2hpY2ggaXMgc3RvcmVkIGluIHRoZSBOVU0uU1RPIGFuZCBzZW50IHRvIHRoZSBzZXJ2ZXIu IEFuZCB0aGUgY2xpZW50IGFsc28gTVVTVCByZW1lbWJlciBhYm91dCBhIHNlcnZlcidzIGluY3Jl YXNpbmcgbnVtYmVyLCB3aGljaCBpcyByZWNlaXZlZCBmcm9tIHRoZSBzZXJ2ZXIgYW5kIHN0b3Jl ZCBpbiB0aGUgTlVNLlJFQy4gQW5kIHRoZSBjbGllbnQga2VlcHMgYSByZWNvcmQgb2YgdGhlIGlu Y3JlYXNpbmcgbnVtYmVyIGR1cmluZyB0aGUgREhDUHY2IGNvbmZpZ3VyYXRpb24gcHJvY2VzcyB3 aXRoIHRoZSBESENQdjYgc2VydmVyLiAgQW5kIHRoZSBjbGllbnQgY2FuIGZvcmdldCB0aGUgaW5j cmVhc2luZyBudW1iZXIgaW5mb3JtYXRpb24gYWZ0ZXIgdGhlIHRyYW5zYWN0aW9uIGlzIGZpbmlz aGVkLiAgVGhlIGNsaWVudCdzIGluaXRpYWwgbG9jYWxseSBzdG9yZWQgaW5jcmVhc2luZyBudW1i ZXIgaXMgc2V0IHRvIHplcm8uDQoNCkZvciBzZXJ2ZXIsIGl0IE1VU1QgcmVtZW1iZXIgYWJvdXQg aXRzIG93biBpbmNyZWFzaW5nIG51bWJlciwgd2hpY2ggaXMgc3RvcmVkIGluIHRoZSBOVU0uU1RP IGFuZCBzZW50IHRvIHRoZSBjbGllbnQuIEFuZCB0aGUgc2VydmVyIGFsc28gTVVTVCByZW1lbWJl ciBhYm91dCBhIGNsaWVudCdzIGluY3JlYXNpbmcgbnVtYmVyLCB3aGljaCBpcyByZWNlaXZlZCBm cm9tIHRoZSBjbGllbnQgYW5kIHN0b3JlZCBpbiB0aGUgTnVtLlJFQy4gVGhlIHNlcnZlciBqdXN0 IG5lZWQgdG8ga2VlcCBvbmUgaW5jcmVhc2luZyBudW1iZXIgc2V0IGZvciBhbGwgY2xpZW50cy4N Cg0KTGF0ZXIsIGJlIGNsZWFyIHRoYXQgdGhpcyBpcyBtb2R1bG8gMl42NCBtYXRoOg0KDQogICBU aGUgSW5jcmVhc2luZy1udW1iZXIgb3B0aW9uIGluIHRoZSByZWNlaXZlZCBtZXNzYWdlIHBhc3Nl cyB0aGUNCiAgIGluY3JlYXNpbmcgbnVtYmVyIGNoZWNrIGlmIE5VTS5SRUMgaXMgbW9yZSB0aGFu IE5VTS5TVE8uICBBbmQgdGhlbiwNCiAgIHRoZSB2YWx1ZSBvZiBOVU0uU1RPIGlzIGNoYW5nZWQg aW50byB0aGUgdmFsdWUgb2YgTlVNLlJFQy4NCg0KICAgVGhlIGluY3JlYXNpbmcgbnVtYmVyIGNo ZWNrIGZhaWxzIGlmIE5VTS5SRUMgaXMgZXF1YWwgd2l0aCBvciBsZXNzDQogICB0aGFuIE5VTS5T VE8uDQoNCiJNb3JlIiBoZXJlIGlzIGluIHRoZSBtb2R1bG8gYXJpdGhtZXRpYyAibW9yZSIgLS0g cGVyaGFwcyB1c2UgIm1vcmUgKG1vZHVsbyAyXjY0KSIgYW5kICJvciBsZXNzIChtb2R1bG8gMl42 NCkiPw0KW0xTXTogQWdyZWUsIHdpbGwgbW9kaWZ5IGl0Lg0KDQpTZWN0aW9uIDkuMjoNCg0KSSB3 b25kZXIgaWYgeW91IHNob3VsZCByZXZpc2UgdGhlIGNvZGUgdG8gbWFrZSBpdCBtb3JlIGFwcHJv cHJpYXRlIGZvciB0aGlzIGRvY3VtZW50PyBSREFUQS9SRExFTkdUSCBhcmVuJ3QgcmVhbGx5IGFw cHJvcHJpYXRlPw0KW0xTXTogR290IGl0LiBXaWxsIG1vZGlmeSBpdC4NCg0KU2VjdGlvbiAxMA0K DQpUaGVyZSBhcmUgbm93IG9ubHkgdGhyZWUgKG5vdCBzaXgpIHN0YXR1cyBjb2Rlcy4NCltMU106 IFdpbGwgY29ycmVjdCBpdC4NCg0KU2VjdGlvbiAxMC4yDQoNCiAgIG1zZy10eXBlICAgICAgICBJ ZGVudGlmaWVyIG9mIHRoZSBtZXNzYWdlIHR5cGUuICBJdCBjYW4gYmUgZWl0aGVyDQogICAgICAg ICAgICAgICAgICAgRW5jcnlwdGVkLVF1ZXJ5IChUQkE3KSBvciBESENQdjYtUmVzcG9uc2UgKFRC QTgpLg0KDQpDaGFuZ2UgREhDUHY2LVJlc3BvbnNlIHRvIEVuY3J5cHRlZC1SZXNwb25zZS4NCltM U106IFdpbGwgY29ycmVjdCBpdC4NCg0KDQpTZWN0aW9uIDExDQoNCiAgIFRoZXJlIGFyZSBzb21l IG1hbmRhdG9yeSBhbGdvcml0aG0gZm9yIGVuY3J5cHRpb24gYWxnb3JpdGhtIGluIHRoaXMNCg0K Q2hhbmdlIChmaXJzdCkgYWxnb3JpdGhtIHRvIGFsZ29yaXRobXM/IE9yLCBjaGFuZ2UgImFyZSBz b21lIiB0byAiaXMgYSINCltMU106IFdpbGwgY2hhbmdlIGl0Lg0KDQoNCiAgIExpa2V3aXNlLCBz aW5jZSB0aGUgRW5jcnlwdGlvbi1LZXktVGFnIE9wdGlvbiBpc24ndCBwcm90ZWN0ZWQsIGFuDQog ICBhdHRhY2tlciB0aGF0IGNhbiBpbnRlcmNlcHQgdGhlIG1lc3NhZ2UgY2FuIGZvcmdlIHRoZSB2 YWx1ZSB3aXRob3V0DQogICBkZXRlY3Rpb24uDQoNCklzbid0IHRoaXMgZ2VuZXJhbGx5IHVzZWxl c3M/IEFzIHRoZSBtZXNzYWdlIGlzIGVuY3J5cHRlZCwgdGhlIHZhbGlkYXRpb24gd2lsbCBmYWls Pw0KW0xTXTogSWYgdGhlIGVuY3J5cHRpb24ta2V5LXRhZyBpcyBmb3JnZWQsIHRoZW4gdGhlIHNl cnZlciBtYXkgY2Fubm90IGRlY3J5cHQgaXQgYW5kIGRyb3AgdGhlIG1lc3NhZ2UuDQoNCg0KU29t ZSBldmVuIG1vcmUgTUlOT1IgY29tbWVudHMgKHRoZXNlIHdvdWxkIHBlcmhhcHMgaW1wcm92ZSBy ZWFkYWJpbGl0eSBidXQgd291bGQgbGlrZWx5IGJlIGFkZHJlc3NlZCBieSB0aGUgUkZDIGVkaXRv cik6DQpbTFNdOiBTb3JyeSBmb3IgdGhlIHBvb3IgZXhwcmVzc2lvbi4gQW5kIHRoYW5rcyBhIGxv dCB5b3VyIHRocm91Z2hvdXQgY2hlY2suIFdpbGwgY29ycmVjdCBpdCBpbiB0aGUgbmV4dCB2ZXJz aW9uLg0KDQpTZWN0aW9uIDY6DQoNClBlcmhhcHMgcmVwbGFjZSAiY29udGFpbmVkIiBhbmQgImNv bnRhaW4iIHdpdGggImluY2x1ZGVkIiBhbmQgImluY2x1ZGUiIGluIHRoZSBzZW50ZW5jZXMgbGF0 ZXIgaW4gdGhhdCBzYW1lIHBhcmFncmFwaCAod2l0aCB0aGUgIlRoZSBlbmNyeXB0aW9uIHRleHQu Li4iKS4NCg0KDQogICBGb3IgdGhlIHJlY2VpdmVkIEVuY3J5cHRlZC1SZXNwb25zZSBtZXNzYWdl LCB0aGUgY2xpZW50IE1VU1QgZHJvcCB0aGUNCiAgIEVuY3J5cHRlZC1SZXNwb25zZSBtZXNzYWdl IGlmIG90aGVyIERIQ1B2NiBvcHRpb24gZXhjZXB0IEVuY3J5cHRlZC0NCiAgIG1lc3NhZ2Ugb3B0 aW9uIGlzIGNvbnRhaW5lZC4NCg0KSG93IGFib3V0Og0KDQogICBGb3IgdGhlIHJlY2VpdmVkIEVu Y3J5cHRlZC1SZXNwb25zZSBtZXNzYWdlLCB0aGUgY2xpZW50IE1VU1QgZHJvcCB0aGUNCiAgIEVu Y3J5cHRlZC1SZXNwb25zZSBtZXNzYWdlIGlmIGl0IGNvbnRhaW5zIGFueSBvcHRpb24gb3RoZXIg dGhhbiBhIHNpbmdsZQ0KICAgRW5jcnlwdGVkLW1lc3NhZ2Ugb3B0aW9uLg0KDQpOb3RlOiBUaGVy ZSBhcmUgc29tZSBvdGhlciBvZGQgdXNlcyBvZiBjb250YWluICh3aGVuIGF0IGxlYXN0IEkgdGhp bmsgdGhlIHRleHQgc2hvdWxkIHVzZSBpbmNsdWRlKS4gQnV0IGl0IG1heSBub3QgYmUgd29ydGgg dHJ5aW5nIHRvIGNoYW5nZSB0aGVzZSAodGhlIHVzYWdlIGlzIHRyaWNreSAtIHlvdSBjYW4gZ29v Z2xlIGZvciAiZW5nbGlzaCBjb250YWluIHZzIGluY2x1ZGUiIGlmIHlvdSBsaWtlKS4gV2Ugd2ls bCBsZWF2ZSBpdCB0byB0aGUgUkZDIGVkaXRvciB0byBwZXJoYXBzIGNsZWFuIHRoZXNlIHVwIGlm IGFwcHJvcHJpYXRlLg0KDQoNCiAgICAgIFRoZSBjbGllbnQgTUFZIHVzZSB0aGUgQXV0aGVudGlj YXRpb25GYWlsIGFzIGEgaGludCBhbmQgc3dpdGNoDQogICAgICB0byBvdGhlciBESENQdjYgc2Vy dmVyIGlmIGl0IGhhcyBhbm90aGVyIG9uZS4NCg0KQ2hhbmdlIHRvICJ0byBhbm90aGVyIERIQ1Ag c2VydmVyIGlmIGl0IGhhcyBvbmUiPw0KDQpTZWN0aW9uIDc6DQoNCiAgIFVwb24gdGhlIHJlY2Vp cHQgb2YgRW5jcnlwdGVkLVF1ZXJ5IG1lc3NhZ2UsIHRoZSBzZXJ2ZXIgTVVTVCBkcm9wIHRoZQ0K ICAgbWVzc2FnZSBpZiB0aGUgb3RoZXIgREhDUHY2IG9wdGlvbiBpcyBjb250YWluZWQgZXhjZXB0 IFNlcnZlcg0KDQpIZXJlICJ0aGUgb3RoZXIiIHNob3VsZCBjaGFuZ2UgdG8gImFub3RoZXIiLg0K DQpOb3RlOiBUaGVyZSBhcmUgc2V2ZXJhbCBvdGhlciBwbGFjZXMgd2hlcmUgY29udGFpbmVkL2Nv bnRhaW4gd291bGQgKGF0IGxlYXN0IGluIG15IG1pbmQpIGJlIG1vcmUgInN0YW5kYXJkIiBpZiB0 aGUgdGV4dCB1c2VkIGluY2x1ZGVkL2luY2x1ZGUuIFNhbWUgZ29lcyBmb3IgdXNlIG9mICJvdGhl ciIgKC0+IGFub3RoZXIpLg0KDQpMYXN0IHBhcmFncmFwaCBvZiBzZWN0aW9uIDcsICJ0aGVuIHRo ZSBzZXJ2ZXIgc2V0IHRoZSIuIFNldCBzaG91bGQgYmUgc2V0cy4NCg0KU2VjdGlvbiAxMC4xLjEN Cg0KRm9yIEVBLWxlbiwgbWlnaHQgYmUgZ29vZCB0byBhZGQgIihtdXN0IGJlIGEgbXVsdGlwbGUg b2YgMikiDQpGb3IgU0hBLWxlbiwgbWlnaHQgYmUgZ29vZCB0byBhZGQgIihtdXN0IGJlIGEgbXVs dGlwbGUgb2YgNCkiDQoNCkFsc28sIEkgdGhpbmsgeW91IHNob3VsZCBjaGFuZ2UgYWxsICIyLW9j dGV0cyB2YWx1ZSIgdG8gIjItb2N0ZXQgdmFsdWUiLg0KDQpTZWN0aW9uIDExDQoNCiAgIEZvciB0 aGlzIHNlY3VyaXR5IGl0ZW0sIEl0IGlzIFJFQ09NTUVOREVEIHRoYXQgY2xpZW50IGNlcnRpZmlj YXRlcw0KICAgY291bGQgYmUgdGllZCB0byBzcGVjaWZpYyBzZXJ2ZXIgY2VydGlmaWNhdGVzIGJ5 IGNvbmZpZ3VyYXRpb24uDQoNCkxvd2VyIGNhc2UgIkl0Ij8NCg0KDQpHZW5lcmFsDQoNClRoZXJl IGFyZSB1c2VzIG9mICJjZXJ0IiBhbmQgImNlcnRzIiBhbmQgImNlcnRpZmljYXRlKHMpIi4gQXJl IHRoZXNlIG9uZSBpbiB0aGUgc2FtZT8gU2hvdWxkbid0IHdlIGp1c3QgdXNlICJjZXJ0aWZpY2F0 ZSIgdGhyb3VnaG91dD8gT3IgcGVyaGFwcyB5b3Ugc2hvdWxkIGFkZCAiY2VydChzKSIgdG8gdGVy bWlub2xvZ3kgc2VjdGlvbj8NCg0KDQotIEJlcm5pZQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KRnJvbTogZGhjd2cgW21haWx0bzpkaGN3Zy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpk aGN3Zy1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIFRvbWVrIE1ydWdhbHNraQ0KU2Vu dDogV2VkbmVzZGF5LCBNYXJjaCAwOCwgMjAxNyA4OjM3IEFNDQpUbzogZGhjd2cgPGRoY3dnQGll dGYub3JnPG1haWx0bzpkaGN3Z0BpZXRmLm9yZz4+DQpDYzogZHJhZnQtaWV0Zi1kaGMtc2VkaGNw djYgYXV0aG9ycyA8ZHJhZnQtaWV0Zi1kaGMtc2VkaGNwdjZAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0 LWlldGYtZGhjLXNlZGhjcHY2QGlldGYub3JnPj4NClN1YmplY3Q6IFtkaGN3Z10gV0dMQyBvbiBk cmFmdC1pZXRmLWRoYy1zZWRoY3B2Ni0yMSAtIFJlc3BvbmQgYnkgTWFyY2ggMjl0aA0KSGksDQpk cmFmdC1pZXRmLWRoYy1zZWRoY3B2Ni0yMSBkZXNjcmliZXMgYSBtZWNoYW5pc20gZm9yIHVzaW5n IHB1YmxpYyBrZXkgY3J5cHRvZ3JhcGh5IHRvIHByb3ZpZGUgZW5kLXRvLWVuZCBzZWN1cml0eSBi ZXR3ZWVuIERIQ1B2NiBjbGllbnRzIGFuZCBzZXJ2ZXJzLiBUaGUgbWVjaGFuaXNtIHByb3ZpZGVz IGVuY3J5cHRpb24gaW4gYWxsIGNhc2VzLCBhbmQgY2FuIGJlIHVzZWQgZm9yIGF1dGhlbnRpY2F0 aW9uIGJhc2VkIG9uIHByZS1zaGFyaW5nIG9mIGF1dGhvcml6ZWQgY2VydGlmaWNhdGVzLiBUaGlz IGRyYWZ0IGhhcyBzdGFydGVkIGluIDIwMTMsIGJ1dCB0aGUgd2hvbGUgREhDUHY2IHNlY3VyaXR5 IHNhZ2EgaXMgbXVjaCBsb25nZXIgYW5kIGJlZ2lucyBpbiAyMDA4LiBUaGlzIGRyYWZ0IHdhcyBz dWJtaXR0ZWQgdG8gSUVTRyBpbiBtaWQtMjAxNS4NClRoZSBndWlkYW5jZSByZWNlaXZlZCB3YXMg Y2xlYXIgdGhhdCAgc3Vic3RhbnRpYWwgY2hhbmdlcyBhcmUgbmVlZGVkLiBBcyBhIHJlc3VsdCwg ImVuY3J5cHQgZXZlcnl3aGVyZSwgYXV0aGVudGljYXRlIGlmIHlvdSBjYW4iIGFwcHJvYWNoIHdh cyB1c2VkLg0KDQpBdXRob3JzIGJlbGlldmUgdGhpcyBkcmFmdCB0byBiZSByZWFkeSBmb3Igd29y a2luZyBncm91cCBsYXN0IGNhbGwuDQoNClBsZWFzZSBzZW5kIHlvdXIgc3Vic3RhbnRpYWwgY29t bWVudHMgdG8gdGhlIG1haWxpbmcgbGlzdCBhbmQgZXhwcmVzcyB5b3VyIG9waW5pb24gd2hldGhl ciB0aGlzIGRyYWZ0IGlzIHJlYWR5IGZvciBwdWJsaWNhdGlvbi4gRmVlbCBmcmVlIHRvIHNlbmQg bml0cGlja3MgYW5kIG1pbm9yIGNvcnJlY3Rpb25zIHRvIHRoZSBhdXRob3JzIGRpcmVjdGx5LiBU aGlzIGlzIGEgY29tcGxleCBkcmFmdCwgc28gdGhlIGNoYWlycyBiZWxpZXZlIDMgd2Vla3MgV0dM QyBpcyBpbiBvcmRlci4gUGxlYXNlIHNlbmQgeW91ciBjb21tZW50cyBubyBsYXRlciB0aGFuIE1h cmNoIDI5dGguIEJlcm5pZSBhbmQgSSB3aWxsIGRldGVybWluZSBjb25zZW5zdXMgYW5kIHdpbGwg ZGlzY3VzcyBkdXJpbmcgQ2hpY2FnbyBtZWV0aW5nIGFzIG5lZWRlZC4NCg0KVG8gaW5pdGlhdGUg dGhlIGRpc2N1c3Npb24sIEkgaGF2ZSB0d28gcmVsYXRlZCBxdWVzdGlvbnMuIFRoZSBjaGFpcnMg d291bGQgbG92ZSB0byBoZWFyIHlvdXIgb3BpbmlvbnMgb24gdGhvc2UuDQoNCjEuIFRoZSAiZW5j cnlwdCBldmVyeXdoZXJlIiBwYXJhZGlnbSBtZWFucyB0aGF0IGluIGRlcGxveW1lbnRzIHRoYXQg ZG8gc25vb3Bpbmcgb24gcmVsYXkgd2lsbCBicmVhayBkb3duLiBUbyBzb2x2ZSB0aGlzIHByb2Js ZW0sIHdlIG5lZWQgYSBhc3NpZ25tZW50IG5vdGlmaWNhdGlvbiBtZWNoYW5pc20sIHNpbWlsYXIg dG8gdGhlIG9uZSBkZXNjcmliZWQgaW4gZHJhZnQtaWV0Zi1kaGMtZGhjcHY2LWFnZW50b3B0LWRl bGVnYXRlLTA0LiBUaGF0IGRyYWZ0IGV4cGlyZWQgbWFueSB5ZWFycyBhZ28uIFRoaXMgbWF0dGVy IHdhcyBkaXNjdXNzZWQgaW4gU2VvdWwgYW5kIHRoZSBtaW51dGVzIGRlc2NyaWJlIHRoZSBjb25j bHVzaW9uIGFzOg0KDQogIFRoZSBkaXNjdXNzaW9uIGdyYXZpdGF0ZWQgdG93YXJkcyBub3QgcmVz dXJyZWN0aW5nIHVudGlsIHRoZSBzZWRoY3B2Ng0KICBJLUQgcHJvZ3Jlc3NlcyBmdXJ0aGVyLiBX ZSB3aWxsIHJlZXZhbHVhdGUgdGhpcyBvbmNlIHNlZGhjcHY2IGlzIGRvbmUuDQoNCkRvIHlvdSB3 YW50IHRoZSBXRyB0byByZXN1cnJlY3QgYWdlbnRvcHQtZGVsZWdhdGUgYSkgbm93LCBiKSB3aGVu DQpzZWRoY3B2NiBpcyBzZW50IHRvIElFU0cgb3IgYykgd2hlbiBzZWRoY3B2NiBpcyBwdWJsaXNo ZWQgYXMgUkZDPyBkKSB3ZSBuZWVkIGEgY29tcGxldGVseSBuZXcgZHJhZnQgYW5kIEknbSB2b2x1 bnRlZXJpbmcgdG8gd29yayBvbiBpdC4NCg0KMi4gT25lIG9mIHRoZSBhdXRob3JzIHN1Z2dlc3Rl ZCB0aGF0IHRoaXMgcHJvdG9jb2wgaXMgcXVpdGUgY29tcGxleCBhbmQgaGF2aW5nIGEgZmVlZGJh Y2sgZnJvbSBhbiBpbXBsZW1lbnRhdGlvbiAob3IgaWRlYWxseSB0d28gaW50ZXJvcGVyYXRpbmcp IHdvdWxkIGJlIHZlcnkgaW1wb3J0YW50IGFuZCB3b3VsZCBsaWtlbHkgcmVzdWx0IGluIHNvbWUg Y2hhbmdlcyB0byB0aGUgZHJhZnQuIEl0J3MgcHJvYmFibHkgdG9vIGxhdGUgZm9yIENoaWNhZ28s IGJ1dCB3ZSBjYW4gb3JnYW5pemUgYQ0Kc2VkaGNwdjYgaGFja2F0aG9uIGluIFByYWd1ZS4gVHdv IGxpa2VseSBpbXBsZW1lbnRhdGlvbnMgd291bGQgYmUgV0lERSBhbmQgS2VhLCBhcyB0aG9zZSB0 d28gYXJlIG9wZW4gc291cmNlIGFuZCBoYXZlIGFuIG9sZCB2ZXJzaW9uIG9mIHRoZSBkcmFmdCBw YXJ0aWFsbHkgaW1wbGVtZW50ZWQuIERvIHlvdSB0aGluayBzdWNoIGEgaGFja2F0aG9uIHdvdWxk IGJlIHVzZWZ1bD8gQXJlIHlvdSB3aWxsaW5nIHRvIHBhcnRpY2lwYXRlPw0KDQpUaXRsZTogU2Vj dXJlIERIQ1B2Ng0KQXV0aG9yczogTC4gTGksIFMuIEppYW5nLCBZLkN1aSwgVC5KaW5tZWksIFQu TGVtb24sIEQuWmhhbmcNCkZpbGVuYW1lOiBkcmFmdC1pZXRmLWRoYy1zZWRoY3B2Ni0yMQ0KUGFn ZXM6IDMxDQpEYXRlOiAyMDE3LTAyLTIxDQpMaW5rOiBodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1pZXRmLWRoYy1zZWRoY3B2Ni8NCg0KUmVzcG9uc2VzIGJ5IE1hcmNoIDI5 dGggYXJlIGFwcHJlY2lhdGVkLg0KDQpUaGFua3MsDQpCZXJuaWUgYW5kIFRvbWVrDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KZGhjd2cgbWFpbGluZyBs aXN0DQpkaGN3Z0BpZXRmLm9yZzxtYWlsdG86ZGhjd2dAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RoY3dnDQoNCg== --_000_369C97B6B6E746CEB42E18559BFB1E78ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1h bCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCmE6 bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNv SHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBs ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdp bjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQ YXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsN CgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGlu Ow0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0Kc3Bhbi5nbWFpbC0N Cgl7bXNvLXN0eWxlLW5hbWU6Z21haWwtO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2lu ZG93dGV4dDt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJI VE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXci O30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHls ZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6 MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJn aW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlz dC1pZDoxMDY4ODQxMTc0Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBs YXRlLWlkczo1NzA1Njk0MTQgLTE0ODQ1OTg2NjIgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkg Njc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6 bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDotOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTsNCglt c28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2 ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv bnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxl dmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N CkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjEzMzgxMTc5NTk7DQoJbXNvLWxpc3QtdHlwZTpoeWJy aWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE3MDAyODM5ODAgNjc2OTg3MDMgNjc2OTg3MTMg Njc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2 OTg3MTU7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxp c3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0 IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsNQ0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluO30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21h bi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7 bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlz dCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsN Cgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDINCgl7bXNvLWxpc3QtaWQ6MTg3NDQxNDAz MTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTE4NTQx NTM0MiAxOTU3ODM1NDc2IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4 NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwyOmxldmVsMQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6LTsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWZhcmVhc3QtZm9u dC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Ijt9DQpAbGlzdCBsMjpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eToiQ291cmllciBOZXciO30NCkBsaXN0IGwyOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsNA0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsNQ0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxp c3QgbDI6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0KQGxpc3QgbDI6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMjpsZXZlbDkNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4t Ym90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPg0KPC9o ZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5I aTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgc2VudGVuY2U6ICZxdW90O1Ro ZSBlbmNyeXB0aW9uIHRleHQgU0hPVUxEIGJlIGZvcm1hdHRlZCBhcyBleHBsYWluIGluIFtSRkM1 NjUyXS4mcXVvdDsgSXNuJ3QgY2xlYXIuIFJGQzU2NTIgZG9lc24ndCB1c2UgJnF1b3Q7dGV4dCZx dW90OyBleGNlcHQgdG8gbWVhbiBhY3R1YWwgd29yZGluZyBpbiB0aGUgUkZDLiBDb3VsZCAmcXVv dDtlbmNyeXB0aW9uIHRleHQmcXVvdDsgYmUgY2xhcmlmaWVkPyBJcyB0aGlzIHRoZSBjbGllbnQn cyBtZXNzYWdlPyBPciB3aGF0DQogZXhhY3RseSBpcyB0aGlzIGFuZCB3aGljaCBwYXJ0IG9mIFJG QyA1NjUyIGhhcyB0aGlzICZxdW90O2Zvcm1hdCZxdW90Oz8gSSBhbSBub3QgZm9sbG93aW5nIHdo YXQgdGhpcyBzZW50ZW5jZSBtZWFucyBhbmQgd2hhdCBJIHNob3VsZCBkbyAoaWYgSSB3ZXJlIGlt cGxlbWVudGluZyB0aGlzKS48YnI+DQo8YnI+DQpOb3RlOiBUaGlzIHNhbWUgdGV4dCBpcyBhbHNv IGluIFNlY3Rpb24gNyAobGFzdCBwYXJhZ3JhcGgpIGFuZCBuZWVkcyBzaW1pbGFyIGF0dGVudGlv bi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPltMU106IFNvcnJ5IGZvciB0 aGUgdW5jbGVhciBleHByZXNzaW9uLiBIb3cgYWJvdXQgdGhlIGZvbGxvd2luZyB0ZXh0PzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIERIQ1B2NiBtZXNzYWdlIHNlbnQg ZnJvbSB0aGUgY2xpZW50IGlzIGVuY3J5cHRlZCBhbmQgdGhlbiBlbmNhcHN1bGF0ZWQgaW50byB0 aGUgZW5jcnlwdGVkIERIQ1B2NiBtZXNzYWdlIGZpZWxkIGFjY29yZGluZyB0byB0aGUgRW5jcnlw dGVkLURhdGEgY29udGVudCBzeW50YXggZGVmaW5lZCBpbiB0aGUgUkZDNTY1Mi48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwcmU+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+QlYmZ3Q7 IEkgYXNzdW1lIHRoaXMgcmVmZXJlbmNlIGlzIHRvIHNlY3Rpb24gOCBvZiBSRkMgNTY1Mi4gQnV0 IG5vdyB0aGUgcXVlc3Rpb24gaXMgd2hldGhlciBhbnl0aGluZyBmdXJ0aGVyIG5lZWRzIHRvIGJl IGRlZmluZWQg4oCTIGZvciBleGFtcGxlLCB3aGF0IChvcHRpb25hbCkgYXR0cmlidXRlcyBzaG91 bGQgYmUgaW5jbHVkZWQ/IFBlcmhhcHMgYXMgSeKAmW0gbm90IGEgc2VjdXJpdHkgZXhwZXJ0IG9y IGhhdmUgY2FyZWZ1bGx5IHJldmlld2VkIFJGQzU2NTIgYW5kIGFtIHRha2luZyBhIGZldyB0aGlu Z3Mg4oCcb3V0IG9mIGNvbnRlbnTigJ0gd2hlbiBsb29raW5nIGF0IGl0LCBidXQgSSB0aGluayBz b21lIGNsYXJpdHkgaGVyZSBtYXkgaGVscCBpbiBtYWtlIHN1cmUgdGhpcyBpcyBlYXN5IHRvIGlt cGxlbWVudCAoZXNwZWNpYWxseSBmb3Igc29tZSBvZiB1cyB0aGF0IG1heSBub3QgYmUgZXhwZXJ0 cyBpbiBjcnlwdG9ncmFwaHkpLiBUaGlzIGlzIGEgYml0IG1vcmUgY29tcGxleCB0aGFuIGp1c3Qg dGFraW5nIHRoZSBieXRlcyBvZiB0aGUgY2xpZW504oCZcyB1bmVuY3J5cHRlZCBtZXNzYWdlIGFu ZCB0aGUgcHJpdmF0ZSBrZXkgdG8gZW5jcnlwdCAoYW5kIHBsYWNpbmcgdGhhdCBpbnRvIHRoZSBF bmNyeXB0ZWQtbWVzc2FnZSBPcHRpb24pLCBhbmQgdGFraW5nIHRoZSBlbmNyeXB0ZWQgY2xpZW50 4oCZcyBtZXNzYWdlIGJ5dGVzIChmcm9tIGEgcmVjZWl2ZWQgRW5jcnlwdGVkLW1lc3NhZ2UgT3B0 aW9uKSBhbmQgZGVjcnlwdGluZyB3aXRoIHRoZSBwdWJsaWMga2V5PyBZb3UgbWF5IHdhbnQgdG8g dGhpbmsgYWJvdXQgd2hldGhlciBwZXJoYXBzIHNwZWNpZnlpbmcgdGhlIGRldGFpbHMgYXBwcm9w cmlhdGUgdG8gREhDUHY2IHVzYWdlIGlzIGFwcHJvcHJpYXRlIOKAkyBwZXJoYXBzIGV2ZW4gaW4g YW4gYXBwZW5kaXg/IFJGQzU2NTIgdGFsa3MgYWJvdXQ6PG86cD48L286cD48L3NwYW4+PC9wcmU+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxp YnJpIj5BbmQgdGhlcmXigJlzIGEgbG90IGFib3V0IEFTTi4xIGFuZCBPSURzIGluIFJGQzU2NTIs IHNvIGFyZSB5b3UgcHVsbGluZyBpbiBhbGwgb2YgdGhpcz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IFRoZSBmb2xsb3dp bmcgb2JqZWN0IGlkZW50aWZpZXIgaWRlbnRpZmllcyB0aGUgZW5jcnlwdGVkLWRhdGEgY29udGVu dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgdHlwZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpZC1lbmNyeXB0ZWREYXRhIE9CSkVDVCBJREVO VElGSUVSIDo6PSB7IGlzbygxKSBtZW1iZXItYm9keSgyKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdXMoODQwKSByc2Fkc2ko MTEzNTQ5KSBwa2NzKDEpIHBrY3M3KDcpIDYgfTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5i c3A7Jm5ic3A7IFRoZSBlbmNyeXB0ZWQtZGF0YSBjb250ZW50IHR5cGUgc2hhbGwgaGF2ZSBBU04u MSB0eXBlIEVuY3J5cHRlZERhdGE6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgRW5jcnlwdGVkRGF0YSA6Oj0gU0VRVUVOQ0UgezxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdmVyc2lvbiBDTVNW ZXJzaW9uLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgZW5jcnlwdGVkQ29udGVudEluZm8gRW5jcnlwdGVkQ29udGVudEluZm8sPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB1bnByb3RlY3RlZEF0dHJz IFsxXSBJTVBMSUNJVCBVbnByb3RlY3RlZEF0dHJpYnV0ZXMgT1BUSU9OQUwgfTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IFRoZSBmaWVsZHMgb2YgdHlwZSBFbmNyeXB0ZWRE YXRhIGhhdmUgdGhlIGZvbGxvd2luZyBtZWFuaW5nczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2si PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB2ZXJzaW9uIGlzIHRoZSBzeW50YXggdmVy c2lvbiBudW1iZXIuJm5ic3A7IElmIHVucHJvdGVjdGVkQXR0cnMgaXM8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHByZXNlbnQsIHRoZW4gdGhlIHZlcnNpb24gTVVTVCBi ZSAyLiZuYnNwOyBJZiB1bnByb3RlY3RlZEF0dHJzIGlzPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBhYnNlbnQsIHRoZW4gdmVyc2lvbiBNVVNUIGJlIDAuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2si PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZW5jcnlwdGVk Q29udGVudEluZm8gaXMgdGhlIGVuY3J5cHRlZCBjb250ZW50IGluZm9ybWF0aW9uLCBhczxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJs YWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZGVmaW5lZCBpbg0KPGEgaHJlZj0i aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzU2NTIjc2VjdGlvbi02LjEiPlNlY3Rpb24g Ni4xPC9hPi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyB1bnByb3RlY3RlZEF0dHJzIGlzIGEgY29sbGVjdGlvbiBvZiBhdHRyaWJ1dGVzIHRo YXQgYXJlIG5vdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZW5jcnlw dGVkLiZuYnNwOyBUaGUgZmllbGQgaXMgb3B0aW9uYWwuJm5ic3A7IFVzZWZ1bCBhdHRyaWJ1dGUg dHlwZXMgYXJlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkZWZpbmVk IGluDQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTY1MiNzZWN0aW9u LTExIj5TZWN0aW9uIDExPC9hPi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPlByb2JhYmx5IHNl Y3Rpb24gNi4xIGlzIG1vc3QgYXBwbGljYWJsZSBhbmQgdGhlcmUgd2UgaGF2ZSAoZXZlbnR1YWxs eSk6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNw OyZuYnNwOyBFbmNyeXB0ZWRDb250ZW50IDo6PSBPQ1RFVCBTVFJJTkc8bzpwPjwvbzpwPjwvc3Bh bj48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OkNhbGlicmkiPldoaWNoIG1heSBiZSBhbGwgd2UgcmVhbGx5IG5lZWQ/PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6Q2FsaWJyaSI+QW5kLCBpZiBzbywgd2hhdCBpcyB0aGUgdmFsdWUgaW4gcmVmZXJlbmNp bmcgdGhpcyBSRkM/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+QWdhaW4sIEnigJltIGp1c3Qg dHJ5aW5nIHRvIHVuZGVyc3RhbmQgdGhpcyBtb3JlIGNvbXBsZXRlbHkg4oCTIHdoYXQgZXhhY3Rs eSBpcyBpbnNpZGUgdGhlIEVuY3J5cHRlZC1tZXNzYWdlIG9wdGlvbj88bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bTFNdOiBZ ZXMsIHRoZSBzZXJ2ZXIganVzdCBuZWVkIHRvIGtlZXAgb25lIHNldCBmb3IgYWxsIGNsaWVudHMu Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ib3cgYWJvdXQgdGhl IGZvbGxvd2luZyBtb2RpZmllZCB0ZXh0PzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Rm9yIGNsaWVudCwgaXQgTVVTVCByZW1lbWJlciBhYm91dCBpdHMgb3duIGluY3JlYXNp bmcgbnVtYmVyLCB3aGljaCBpcyBzdG9yZWQgaW4gdGhlIE5VTS5TVE8gYW5kIHNlbnQgdG8gdGhl IHNlcnZlci4gQW5kIHRoZSBjbGllbnQgYWxzbyBNVVNUIHJlbWVtYmVyIGFib3V0IGEgc2VydmVy J3MgaW5jcmVhc2luZyBudW1iZXIsIHdoaWNoIGlzIHJlY2VpdmVkIGZyb20gdGhlIHNlcnZlciBh bmQgc3RvcmVkIGluIHRoZQ0KIE5VTS5SRUMuIEFuZCB0aGUgY2xpZW50IGtlZXBzIGEgcmVjb3Jk IG9mIHRoZSBpbmNyZWFzaW5nIG51bWJlciBkdXJpbmcgdGhlIERIQ1B2NiBjb25maWd1cmF0aW9u IHByb2Nlc3Mgd2l0aCB0aGUgREhDUHY2IHNlcnZlci4mbmJzcDsgQW5kIHRoZSBjbGllbnQgY2Fu IGZvcmdldCB0aGUgaW5jcmVhc2luZyBudW1iZXIgaW5mb3JtYXRpb24gYWZ0ZXIgdGhlIHRyYW5z YWN0aW9uIGlzIGZpbmlzaGVkLiZuYnNwOyBUaGUgY2xpZW50J3MgaW5pdGlhbCBsb2NhbGx5IHN0 b3JlZA0KIGluY3JlYXNpbmcgbnVtYmVyIGlzIHNldCB0byB6ZXJvLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5Gb3Igc2VydmVyLCBpdCBNVVNUIHJlbWVtYmVyIGFib3V0IGl0cyBvd24gaW5jcmVh c2luZyBudW1iZXIsIHdoaWNoIGlzIHN0b3JlZCBpbiB0aGUgTlVNLlNUTyBhbmQgc2VudCB0byB0 aGUgY2xpZW50LiBBbmQgdGhlIHNlcnZlciBhbHNvIE1VU1QgcmVtZW1iZXIgYWJvdXQgYSBjbGll bnQncyBpbmNyZWFzaW5nIG51bWJlciwgd2hpY2ggaXMgcmVjZWl2ZWQgZnJvbSB0aGUgY2xpZW50 IGFuZCBzdG9yZWQgaW4gdGhlDQogTnVtLlJFQy4gVGhlIHNlcnZlciBqdXN0IG5lZWQgdG8ga2Vl cCBvbmUgaW5jcmVhc2luZyBudW1iZXIgc2V0IGZvciBhbGwgY2xpZW50cy48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNh bGlicmkiPkJWJmd0OyBIZXJlIGFnYWluLCBwbGVhc2UgYmUgY2FyZWZ1bDo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50 Oi0uMjVpbjttc28tbGlzdDpsMSBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PHNwYW4gc3R5 bGU9Im1zby1saXN0Oklnbm9yZSI+MS48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0K PC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPklmIGNsaWVudCBhbHdheXMgc3RhcnRzIGF0IDAsIGhv dyBkb2VzIHRoYXQgaGVscCBpbiBwcmV2ZW50aW5nIHJlcGxheT8gQW5kLCB0aGlzIGlzbuKAmXQg Y29uc2lzdGVudCB3aXRoIHRoZSBzZXJ2ZXLigJlzIGJlaGF2aW9yIGFib3ZlPzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRl bnQ6LS4yNWluO21zby1saXN0OmwxIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48c3BhbiBz dHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4yLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+SWYgY2xpZW50IGRvZXNu4oCZdCBwZXJzaXN0IHRo aXMsIHdoYXQgaGFwcGVucyBpZiBzZXJ2ZXIgaGFzIGEgbGVhc2UgZm9yIHRoZSBjbGllbnQgKGFu ZCBoYXMgcmV0YWluZWQgdGhlIHJlcGxheSBudW1iZXJzKSBidXQgdGhlIGNsaWVudCByZWxlYXNl ZCAob3Igb3RoZXJ3aXNlIGRlbGV0ZWQgdGhlIGxlYXNlKS4NCiBOb3cgd2hlbiB0aGUgY2xpZW50 IFNvbGljaXRzIChlbmNyeXB0ZWQpLCB0aGUgc2VydmVyIHdvdWxkIHJlcG9ydCB0aGF0IHRoaXMg aXMgYSBwb3RlbnRpYWwgcmVwbGF5IGF0dGFjaD8gSSBkb27igJl0IHRoaW5rIGRyb3BwaW5nIHRo aXMgaW5mb3JtYXRpb24g4oCcYWZ0ZXIgdGhlIHRyYW5zYWN0aW9uIGlzIGZpbmlzaGVk4oCdIGlz IHBvc3NpYmxlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdy YXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwxIGxldmVsMSBsZm8xIj48 IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTpDYWxpYnJpIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4zLjxzcGFuIHN0eWxl PSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Rm9yIOKAnFRo ZSBzZXJ2ZXIganVzdCBuZWVkIHRvIGtlZXAgb25lIGluY3JlYXNpbmcgbnVtYmVyIHNldCBmb3Ig YWxsIGNsaWVudHPigJ0g4oCTIHNob3VsZG7igJl0IHRoYXQgYmUgYWZ0ZXIgdGhlIGZpcnN0IHNl bnRlbmNlIGFzIHRoaXMgYXBwbGllcyB0byBOVU0uU1RPOyBub3QgTlVNLlJFQz88bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5UaHVzLCBJIHRoaW5rIHRoZSBjbGllbnQgbXVz dCByZXRhaW4gdGhlIG51bWJlciBpdCBsYXN0IHVzZWQgd2l0aCBhIHNlcnZlci4gVGhpcyBzZWVt cyB0byBiZSBhbiBpc3N1ZSBmb3IgZGV2aWNlcyB3aXRob3V0IHBlcnNpc3RlbnQgc3RvcmFnZSwg c28gbWF5IHJlcXVpcmUgc29tZSBmdXJ0aGVyIHRob3VnaHQg4oCTIG9yIHRob3NlDQogZGV2aWNl cyBjYW5ub3QgdXNlIGluY3JlYXNpbmcgbnVtYmVyPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmki PkFuZCwgSSB0aGluayBib3RoIGhhdmluZyB0byByZXRhaW4gdGhpcyBmb3JldmVyIHdvdWxkIGJl IGEgYmFkIGlkZWEuIEkgdGhpbmsgb25lIGNvdWxkIHByb3ZpZGUgZm9yIGJvdGggY2xpZW50cyBh bmQgc2VydmVycyB0byDigJxmb3JnZXTigJ0gYW55IHN0b3JlZCBpbmZvcm1hdGlvbiBhZnRlciBh IHBlcmlvZCBvZiB0aW1lIChwZXJoYXBzDQogdGhpcyBjYW4gYmUgYSBmaXhlZCBudW1iZXIsIDMw IGRheXMsIG9yIHNob3VsZCBiZSBzb21lIG11bHRpcGxlIG9mIHRoZSBsZWFzZSBsaWZldGltZSk/ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO0xpa2V3aXNlLCBzaW5jZSB0aGUgRW5j cnlwdGlvbi1LZXktVGFnIE9wdGlvbiBpc24ndCBwcm90ZWN0ZWQsIGFuPGJyPg0KJm5ic3A7ICZu YnNwO2F0dGFja2VyIHRoYXQgY2FuIGludGVyY2VwdCB0aGUgbWVzc2FnZSBjYW4gZm9yZ2UgdGhl IHZhbHVlIHdpdGhvdXQ8YnI+DQombmJzcDsgJm5ic3A7ZGV0ZWN0aW9uLjxicj4NCjxicj4NCklz bid0IHRoaXMgZ2VuZXJhbGx5IHVzZWxlc3M/IEFzIHRoZSBtZXNzYWdlIGlzIGVuY3J5cHRlZCwg dGhlIHZhbGlkYXRpb24gd2lsbCBmYWlsPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+W0xTXTogSWYgdGhlIGVuY3J5cHRpb24ta2V5LXRhZyBpcyBmb3JnZWQsIHRoZW4gdGhl IHNlcnZlciBtYXkgY2Fubm90IGRlY3J5cHQgaXQgYW5kIGRyb3AgdGhlIG1lc3NhZ2UuPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTpDYWxpYnJpIj5CViZndDsgUmlnaHQsIGJ1dCBpc27igJl0IHRoYXQgZXhhY3RseSB3aGF0 IHdlIHdvdWxkIHdhbnQ/IFNvLCBob3cgaXMgdGhpcyBiYWQ/DQo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpD YWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5CViZn dDsgUmUgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgLSBBIG5ldyBjb21tZW50IGZyb20gYSBjb252 ZXJzYXRpb24gd2l0aCBUb21layAoVG9tZWsgd2lsbCBob3BlZnVsbHkgY29tbWVudCBtb3JlKS4g SSBtZW50aW9uZWQgdGhhdCBJIHdhcyBjb25jZXJuZWQgd2l0aCB0aGUgcG9zc2liaWxpdHkgb2Yg Y2xpZW50cyBhbmQgc2VydmVycw0KIGdldHRpbmcg4oCcanVua+KAnSBpcyBhIHNlY3VyaXR5IGNv bmNlcm4gYXMgc29tZW9uZSBjb3VsZCBnZW5lcmF0ZSBiYWQgcGFja2V0cyB3aXRoIGVuY3J5cHRl ZCBkYXRhIGFuZCBzZW5kIHRoZW0gdG8gY2xpZW50cyBhbmQgc2VydmVycyBpbiB0aGUgaG9wZSB0 byBjcmFzaCB0aGUgZWl0aGVyIHdoZW4gdGhleSB0cnkgdG8gZGVjcnlwdCBhbmQgdGhlbiBwcm9j ZXNzIGp1bmsuIFRvbWVrIHN1Z2dlc3RlZCB3ZSBtaWdodCB3YW50IHRvIHRoaW5rIGFib3V0DQog d2hldGhlciB0byBhZGQgc29tZSBtYWdpYyB2YWx1ZSB0byB0aGUgZmlyc3QgZmV3IGJ5dGVzIG9m IGEgbWVzc2FnZSBiZWZvcmUgZW5jcnlwdGluZyBpdCBhbmQgdGhlbiB0aGUgZGVjcnlwdGVyIGNh biBjaGVjayB0aG9zZSBmaXJzdCBmZXcgYnl0ZXMgdG8gc2VlIGlmIHRoZXkgYXJlIHZhbHVlIGFu ZCBkaXNjYXJkIHRoZSBtZXNzYWdlIGlmIG5vdC4gUGVyaGFwcyB0aGUgZW5jb2RpbmcgZnJvbSBS RkM1NjUyIHdvdWxkIGFjY29tcGxpc2ggdGhpcw0KIGlmIHdlIGFyZSB1c2luZyBtb3JlIHRoYW4g anVzdCB0aGUgZW5jcnlwdGVkQ29udGVudD8gQW55d2F5LCBzb21ldGhpbmcgdG8gdGhpbmsgYWJv dXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6Q2FsaWJyaSI+QWdhaW4sIHRoYW5rcyBmb3IgeW91ciBjb250aW51ZWQgZWZmb3J0 cyBvbiB0aGlzIGRvY3VtZW50ITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmki PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBo IiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8zIj48IVtp ZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTpDYWxpYnJpIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZv bnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFu PjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxp YnJpIj5CZXJuaWU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpi bGFjayI+RnJvbTogPC9zcGFuPg0KPC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJp O2NvbG9yOmJsYWNrIj5MaXNoYW4gTGkgJmx0O2xpbGlzaGFuNDhAZ21haWwuY29tJmd0Ozxicj4N CjxiPkRhdGU6IDwvYj5Nb25kYXksIE1hcmNoIDI3LCAyMDE3IGF0IDEyOjMzIEFNPGJyPg0KPGI+ VG86IDwvYj5CZXJuaWUgVm9seiAmbHQ7dm9sekBjaXNjby5jb20mZ3Q7PGJyPg0KPGI+Q2M6IDwv Yj5Ub21layBNcnVnYWxza2kgJmx0O3RvbWFzei5tcnVnYWxza2lAZ21haWwuY29tJmd0OywgJnF1 b3Q7ZGhjd2dAaWV0Zi5vcmcmcXVvdDsgJmx0O2RoY3dnQGlldGYub3JnJmd0OywgZHJhZnQtaWV0 Zi1kaGMtc2VkaGNwdjYgYXV0aG9ycyAmbHQ7ZHJhZnQtaWV0Zi1kaGMtc2VkaGNwdjZAaWV0Zi5v cmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbZGhjd2ddIFdHTEMgb24gZHJhZnQtaWV0 Zi1kaGMtc2VkaGNwdjYtMjEgLSBSZXNwb25kIGJ5IE1hcmNoIDI5dGg8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpLCBCZXJuaWUs IDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzIGEg bG90IGZvciB5b3VyIHZhbHVhYmxlIGNvbW1lbnRzLiBGb3IgdGhlIGRldGFpbHMsIHBsZWFzZSBz ZWUgaW5saW5lLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5CZXN0IFJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5MaXNoYW48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4yMDE3LTAzLTI2IDEwOjA1IEdNVCYjNDM7MDg6MDAgQmVybmllIFZvbHogKHZvbHopICZs dDs8YSBocmVmPSJtYWlsdG86dm9sekBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj52b2x6QGNp c2NvLmNvbTwvYT4mZ3Q7OjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBp biA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkhpOjxicj4NCjxicj4NCkkgaGF2ZSByZXZpZXdlZCB0aGUgZHJhZnQgYW5kIHN1 cHBvcnQgaXQgbW92aW5nIGZvcndhcmQuIEhvd2V2ZXIsIEkgZG8gaGF2ZSBzb21lIGlzc3VlcyBJ IHRoaW5rIG5lZWQgdG8gYmUgYWRkcmVzc2VkIGJ1dCB0aGV5IGFyZSBtb3N0bHkgZmFpcmx5IHNt YWxsLjxicj4NCjxicj4NCkkgZG8gd2FudCB0byB0aGFuayB0aGUgYXV0aG9ycyBmb3IgYWRkcmVz c2luZyBteSBlYXJsaWVyIGlzc3Vlcy4gSSB0aGluayB0aGUgZG9jdW1lbnQgaXMgaW4gTVVDSCBi ZXR0ZXIgc2hhcGUgbm93ISE8YnI+DQo8YnI+DQpTbyBoZXJlIGdvZXMgLi4uPGJyPg0KPGJyPg0K U2VjdGlvbiA2Ojxicj4NClRoZSBzZW50ZW5jZTogJnF1b3Q7VGhlIGVuY3J5cHRpb24gdGV4dCBT SE9VTEQgYmUgZm9ybWF0dGVkIGFzIGV4cGxhaW4gaW4gW1JGQzU2NTJdLiZxdW90OyBJc24ndCBj bGVhci4gUkZDNTY1MiBkb2Vzbid0IHVzZSAmcXVvdDt0ZXh0JnF1b3Q7IGV4Y2VwdCB0byBtZWFu IGFjdHVhbCB3b3JkaW5nIGluIHRoZSBSRkMuIENvdWxkICZxdW90O2VuY3J5cHRpb24gdGV4dCZx dW90OyBiZSBjbGFyaWZpZWQ/IElzIHRoaXMgdGhlIGNsaWVudCdzIG1lc3NhZ2U/IE9yIHdoYXQg ZXhhY3RseSBpcyB0aGlzIGFuZA0KIHdoaWNoIHBhcnQgb2YgUkZDIDU2NTIgaGFzIHRoaXMgJnF1 b3Q7Zm9ybWF0JnF1b3Q7PyBJIGFtIG5vdCBmb2xsb3dpbmcgd2hhdCB0aGlzIHNlbnRlbmNlIG1l YW5zIGFuZCB3aGF0IEkgc2hvdWxkIGRvIChpZiBJIHdlcmUgaW1wbGVtZW50aW5nIHRoaXMpLjxi cj4NCjxicj4NCk5vdGU6IFRoaXMgc2FtZSB0ZXh0IGlzIGFsc28gaW4gU2VjdGlvbiA3IChsYXN0 IHBhcmFncmFwaCkgYW5kIG5lZWRzIHNpbWlsYXIgYXR0ZW50aW9uLjxvOnA+PC9vOnA+PC9wPg0K PC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPltMU106IFNvcnJ5IGZv ciB0aGUgdW5jbGVhciBleHByZXNzaW9uLiBIb3cgYWJvdXQgdGhlIGZvbGxvd2luZyB0ZXh0Pzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIERI Q1B2NiBtZXNzYWdlIHNlbnQgZnJvbSB0aGUgY2xpZW50IGlzIGVuY3J5cHRlZCBhbmQgdGhlbiBl bmNhcHN1bGF0ZWQgaW50byB0aGUgZW5jcnlwdGVkIERIQ1B2NiBtZXNzYWdlIGZpZWxkIGFjY29y ZGluZyB0byB0aGUgRW5jcnlwdGVkLURhdGEgY29udGVudCBzeW50YXggZGVmaW5lZCBpbiB0aGUg UkZDNTY1Mi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGJyPg0KU2VjdGlvbiA3Ojxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDtvcHRp b24uJm5ic3A7IFRoZW4sIHRoZSBzZXJ2ZXIgY2hlY2tzIHRoZSBTZXJ2ZXIgSWRlbnRpZmllciBv cHRpb24uJm5ic3A7IFRoZTxicj4NCiZuYnNwOyAmbmJzcDtESENQdjYgc2VydmVyIGRyb3BzIHRo ZSBtZXNzYWdlIHRoYXQgaXMgbm90IGZvciBpdCwgdGh1cyBub3QgcGF5aW5nPGJyPg0KJm5ic3A7 ICZuYnNwO2Nvc3QgdG8gZGVjcnlwdCBtZXNzYWdlcy4mbmJzcDsgSWYgaXQgaXMgdGhlIHRhcmdl dCBzZXJ2ZXIsIGFjY29yZGluZyB0bzxicj4NCjxicj4NCkkgdGhpbmsgaGVyZSB5b3UgYWxzbyB3 YW50IHRoZSBzZXJ2ZXIgdG8gcHJvY2VlZCBpZiB0aGVyZSBpcyBOTyBTZXJ2ZXIgSWRlbnRpZmll ciBvcHRpb24/IEl0IHNob3VsZCBvbmx5IGlnbm9yZSBpdCBpZiB0aGVyZSBpcyBhIFNlcnZlciBJ ZGVudGlmaWVyIG9wdGlvbiBhbmQgaXQgZG9lcyBub3QgbWF0Y2ggdGhpcyBzZXJ2ZXIncyBpZGVu dGlmaWVyPzxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPltMU106IFllcy4gV2lsbCBtb2RpZnkgaXQuJm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44 cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpTZWN0aW9u IDg8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7dGhvc2UgcHJlc2VudCBpbiB0aGUgaW5uZXJtb3N0 IGVuY2Fwc3VsYXRlZCBtZXNzYWdlcyBmcm9tIHRoZSBjbGllbnQ8YnI+DQombmJzcDsgJm5ic3A7 b3Igc2VydmVyLjxicj4NCjxicj4NCkkgdGhpbmsgbWVzc2FnZXMgc2hvdWxkIGp1c3QgYmUgbWVz c2FnZSBhcyB0aGVyZSBpcyBvbmx5IG9uZSBtZXNzYWdlPzxvOnA+PC9vOnA+PC9wPg0KPC9ibG9j a3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPltMU106IEFncmVlLiBXaWxsIG1v ZGlmeSBpdC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4g MGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxicj4NClNlY3Rpb24gOS4xOjxicj4NCjxicj4NCk1pZ2h0IGJlIGJl dHRlciB0byBzcGxpdCBvdXQgcmVxdWlyZW1lbnRzIGZvciBhIGNsaWVudCBhbmQgc2VydmVyIGlu dG8gc2VwYXJhdGUgcGFyYWdyYXBocyAoMXN0IHBhcmFncmFwaCk/IE1pZ2h0IGFsc28gYmUgYmVz dCB0byBiZSBjbGVhciB0aGF0IHlvdSBhZGRyZXNzOjxicj4NCjEuIFdoYXQgYSBjbGllbnQgbXVz dCByZW1lbWJlciBhYm91dCBpdHMgb3duIGluY3JlYXNpbmcgbnVtYmVyIChpLmUuLCB3aGF0IGl0 IHNlbmRzIHRvIHRoZSBzZXJ2ZXIpLjxicj4NCjIuIFdoYXQgYSBjbGllbnQgbXVzdCByZW1lbWJl ciBhYm91dCB0aGUgc2VydmVyJ3MgaW5jcmVhc2luZyBudW1iZXIgKGkuZS4sIHdoYXQgaXQgcmVj ZWl2ZXMgZnJvbSBzZXJ2ZXIpLjxicj4NCjMuIFdoYXQgYSBzZXJ2ZXIgbXVzdCByZW1lbWJlciBh Ym91dCBhIGNsaWVudCdzIGluY3JlYXNpbmcgbnVtYmVyIChpLmUuLCB3aGF0IGl0IHJlY2VpdmVz IGZyb20gY2xpZW50KS48YnI+DQo0LiBXaGF0IGEgc2VydmVyIG11c3QgcmVtZW1iZXIgYWJvdXQg aXRzIG93biBpbmNyZWFzaW5nIG51bWJlciAoaS5lLiwgd2hhdCBpdCBzZW5kcyB0byBjbGllbnRz KS4gSSBhc3N1bWUgYSBzZXJ2ZXIgZG9lcyBOT1QgbmVlZCB0byBrZWVwIGEgdW5pcXVlIGluY3Jl YXNpbmcgbnVtYmVyIHNldCBmb3IgZWFjaCBjbGllbnQgaXQgY29tbXVuaWNhdGVzIHdpdGggLSBh IHNlcnZlciBjYW4gdXNlIG9uZSBzZXQgZm9yIGFsbCBjbGllbnRzPzxicj4NClBsZWFzZSBhbHNv IGJlIGNsZWFyIGFib3V0IGhvdyBlYWNoIG9mIHRoZXNlIDQgKDIgbnVtYmVycyBvbiBjbGllbnQs IDIgb24gc2VydmVyKSBhcmUgaGFuZGxlZC4gVGhlIHRleHQgcHJlc2VudGx5IGlzIG5vdCB2ZXJ5 IGNsZWFyIC0tIGZvciBleGFtcGxlIGEgY2xpZW50IGNhbid0IGZvcmdldCB3aGF0IGl0IHNlbnQg aWYgdGhlIHNlcnZlciByZW1lbWJlcnMgaXQuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+W0xTXTogWWVzLCB0aGUgc2VydmVyIGp1c3Qg bmVlZCB0byBrZWVwIG9uZSBzZXQgZm9yIGFsbCBjbGllbnRzLiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SG93IGFib3V0IHRoZSBmb2xs b3dpbmcgbW9kaWZpZWQgdGV4dD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkZvciBjbGllbnQsIGl0IE1VU1QgcmVtZW1iZXIgYWJvdXQgaXRzIG93 biBpbmNyZWFzaW5nIG51bWJlciwgd2hpY2ggaXMgc3RvcmVkIGluIHRoZSBOVU0uU1RPIGFuZCBz ZW50IHRvIHRoZSBzZXJ2ZXIuIEFuZCB0aGUgY2xpZW50IGFsc28gTVVTVCByZW1lbWJlciBhYm91 dCBhIHNlcnZlcidzIGluY3JlYXNpbmcgbnVtYmVyLCB3aGljaCBpcyByZWNlaXZlZCBmcm9tIHRo ZSBzZXJ2ZXIgYW5kIHN0b3JlZCBpbiB0aGUNCiBOVU0uUkVDLiBBbmQgdGhlIGNsaWVudCBrZWVw cyBhIHJlY29yZCBvZiB0aGUgaW5jcmVhc2luZyBudW1iZXIgZHVyaW5nIHRoZSBESENQdjYgY29u ZmlndXJhdGlvbiBwcm9jZXNzIHdpdGggdGhlIERIQ1B2NiBzZXJ2ZXIuJm5ic3A7IEFuZCB0aGUg Y2xpZW50IGNhbiBmb3JnZXQgdGhlIGluY3JlYXNpbmcgbnVtYmVyIGluZm9ybWF0aW9uIGFmdGVy IHRoZSB0cmFuc2FjdGlvbiBpcyBmaW5pc2hlZC4mbmJzcDsgVGhlIGNsaWVudCdzIGluaXRpYWwg bG9jYWxseSBzdG9yZWQNCiBpbmNyZWFzaW5nIG51bWJlciBpcyBzZXQgdG8gemVyby48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Rm9yIHNlcnZl ciwgaXQgTVVTVCByZW1lbWJlciBhYm91dCBpdHMgb3duIGluY3JlYXNpbmcgbnVtYmVyLCB3aGlj aCBpcyBzdG9yZWQgaW4gdGhlIE5VTS5TVE8gYW5kIHNlbnQgdG8gdGhlIGNsaWVudC4gQW5kIHRo ZSBzZXJ2ZXIgYWxzbyBNVVNUIHJlbWVtYmVyIGFib3V0IGEgY2xpZW50J3MgaW5jcmVhc2luZyBu dW1iZXIsIHdoaWNoIGlzIHJlY2VpdmVkIGZyb20gdGhlIGNsaWVudCBhbmQgc3RvcmVkIGluIHRo ZQ0KIE51bS5SRUMuIFRoZSBzZXJ2ZXIganVzdCBuZWVkIHRvIGtlZXAgb25lIGluY3JlYXNpbmcg bnVtYmVyIHNldCBmb3IgYWxsIGNsaWVudHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0 OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpMYXRlciwgYmUgY2xlYXIgdGhhdCB0 aGlzIGlzIG1vZHVsbyAyXjY0IG1hdGg6PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwO1RoZSBJbmNy ZWFzaW5nLW51bWJlciBvcHRpb24gaW4gdGhlIHJlY2VpdmVkIG1lc3NhZ2UgcGFzc2VzIHRoZTxi cj4NCiZuYnNwOyAmbmJzcDtpbmNyZWFzaW5nIG51bWJlciBjaGVjayBpZiBOVU0uUkVDIGlzIG1v cmUgdGhhbiBOVU0uU1RPLiZuYnNwOyBBbmQgdGhlbiw8YnI+DQombmJzcDsgJm5ic3A7dGhlIHZh bHVlIG9mIE5VTS5TVE8gaXMgY2hhbmdlZCBpbnRvIHRoZSB2YWx1ZSBvZiBOVU0uUkVDLjxicj4N Cjxicj4NCiZuYnNwOyAmbmJzcDtUaGUgaW5jcmVhc2luZyBudW1iZXIgY2hlY2sgZmFpbHMgaWYg TlVNLlJFQyBpcyBlcXVhbCB3aXRoIG9yIGxlc3M8YnI+DQombmJzcDsgJm5ic3A7dGhhbiBOVU0u U1RPLjxicj4NCjxicj4NCiZxdW90O01vcmUmcXVvdDsgaGVyZSBpcyBpbiB0aGUgbW9kdWxvIGFy aXRobWV0aWMgJnF1b3Q7bW9yZSZxdW90OyAtLSBwZXJoYXBzIHVzZSAmcXVvdDttb3JlIChtb2R1 bG8gMl42NCkmcXVvdDsgYW5kICZxdW90O29yIGxlc3MgKG1vZHVsbyAyXjY0KSZxdW90Oz88bzpw PjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5b TFNdOiBBZ3JlZSwgd2lsbCBtb2RpZnkgaXQuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpTZWN0aW9uIDkuMjo8YnI+ DQo8YnI+DQpJIHdvbmRlciBpZiB5b3Ugc2hvdWxkIHJldmlzZSB0aGUgY29kZSB0byBtYWtlIGl0 IG1vcmUgYXBwcm9wcmlhdGUgZm9yIHRoaXMgZG9jdW1lbnQ/IFJEQVRBL1JETEVOR1RIIGFyZW4n dCByZWFsbHkgYXBwcm9wcmlhdGU/PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+W0xTXTogR290IGl0LiBXaWxsIG1vZGlmeSBpdC4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxicj4NClNlY3Rpb24gMTA8YnI+DQo8YnI+DQpUaGVyZSBhcmUgbm93IG9ubHkgdGhyZWUg KG5vdCBzaXgpIHN0YXR1cyBjb2Rlcy48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bTFNdOiBXaWxsIGNvcnJlY3QgaXQuJm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 YnI+DQpTZWN0aW9uIDEwLjI8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7bXNnLXR5cGUmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgSWRlbnRpZmllciBvZiB0aGUgbWVzc2FnZSB0eXBlLiZuYnNw OyBJdCBjYW4gYmUgZWl0aGVyPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7RW5jcnlwdGVkLVF1ZXJ5IChUQkE3 KSBvciBESENQdjYtUmVzcG9uc2UgKFRCQTgpLjxicj4NCjxicj4NCkNoYW5nZSBESENQdjYtUmVz cG9uc2UgdG8gRW5jcnlwdGVkLVJlc3BvbnNlLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3Rl Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPltMU106IFdpbGwgY29ycmVjdCBpdC4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxicj4NCjxicj4NClNlY3Rpb24gMTE8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7VGhlcmUg YXJlIHNvbWUgbWFuZGF0b3J5IGFsZ29yaXRobSBmb3IgZW5jcnlwdGlvbiBhbGdvcml0aG0gaW4g dGhpczxicj4NCjxicj4NCkNoYW5nZSAoZmlyc3QpIGFsZ29yaXRobSB0byBhbGdvcml0aG1zPyBP ciwgY2hhbmdlICZxdW90O2FyZSBzb21lJnF1b3Q7IHRvICZxdW90O2lzIGEmcXVvdDs8bzpwPjwv bzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bTFNd OiBXaWxsIGNoYW5nZSBpdC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDtMaWtld2lz ZSwgc2luY2UgdGhlIEVuY3J5cHRpb24tS2V5LVRhZyBPcHRpb24gaXNuJ3QgcHJvdGVjdGVkLCBh bjxicj4NCiZuYnNwOyAmbmJzcDthdHRhY2tlciB0aGF0IGNhbiBpbnRlcmNlcHQgdGhlIG1lc3Nh Z2UgY2FuIGZvcmdlIHRoZSB2YWx1ZSB3aXRob3V0PGJyPg0KJm5ic3A7ICZuYnNwO2RldGVjdGlv bi48YnI+DQo8YnI+DQpJc24ndCB0aGlzIGdlbmVyYWxseSB1c2VsZXNzPyBBcyB0aGUgbWVzc2Fn ZSBpcyBlbmNyeXB0ZWQsIHRoZSB2YWxpZGF0aW9uIHdpbGwgZmFpbD88bzpwPjwvbzpwPjwvcD4N CjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bTFNdOiBJZiB0aGUg ZW5jcnlwdGlvbi1rZXktdGFnIGlzIGZvcmdlZCwgdGhlbiB0aGUgc2VydmVyIG1heSBjYW5ub3Qg ZGVjcnlwdCBpdCBhbmQgZHJvcCB0aGUgbWVzc2FnZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t cmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NClNvbWUgZXZlbiBt b3JlIE1JTk9SIGNvbW1lbnRzICh0aGVzZSB3b3VsZCBwZXJoYXBzIGltcHJvdmUgcmVhZGFiaWxp dHkgYnV0IHdvdWxkIGxpa2VseSBiZSBhZGRyZXNzZWQgYnkgdGhlIFJGQyBlZGl0b3IpOjxvOnA+ PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPltM U106IFNvcnJ5IGZvciB0aGUgcG9vciBleHByZXNzaW9uLiBBbmQgdGhhbmtzIGEgbG90IHlvdXIg dGhyb3VnaG91dCBjaGVjay4gV2lsbCBjb3JyZWN0IGl0IGluIHRoZSBuZXh0IHZlcnNpb24uJm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NClNlY3Rpb24gNjo8YnI+DQo8 YnI+DQpQZXJoYXBzIHJlcGxhY2UgJnF1b3Q7Y29udGFpbmVkJnF1b3Q7IGFuZCAmcXVvdDtjb250 YWluJnF1b3Q7IHdpdGggJnF1b3Q7aW5jbHVkZWQmcXVvdDsgYW5kICZxdW90O2luY2x1ZGUmcXVv dDsgaW4gdGhlIHNlbnRlbmNlcyBsYXRlciBpbiB0aGF0IHNhbWUgcGFyYWdyYXBoICh3aXRoIHRo ZSAmcXVvdDtUaGUgZW5jcnlwdGlvbiB0ZXh0Li4uJnF1b3Q7KS48YnI+DQo8YnI+DQo8YnI+DQom bmJzcDsgJm5ic3A7Rm9yIHRoZSByZWNlaXZlZCBFbmNyeXB0ZWQtUmVzcG9uc2UgbWVzc2FnZSwg dGhlIGNsaWVudCBNVVNUIGRyb3AgdGhlPGJyPg0KJm5ic3A7ICZuYnNwO0VuY3J5cHRlZC1SZXNw b25zZSBtZXNzYWdlIGlmIG90aGVyIERIQ1B2NiBvcHRpb24gZXhjZXB0IEVuY3J5cHRlZC08YnI+ DQombmJzcDsgJm5ic3A7bWVzc2FnZSBvcHRpb24gaXMgY29udGFpbmVkLjxicj4NCjxicj4NCkhv dyBhYm91dDo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7Rm9yIHRoZSByZWNlaXZlZCBFbmNyeXB0 ZWQtUmVzcG9uc2UgbWVzc2FnZSwgdGhlIGNsaWVudCBNVVNUIGRyb3AgdGhlPGJyPg0KJm5ic3A7 ICZuYnNwO0VuY3J5cHRlZC1SZXNwb25zZSBtZXNzYWdlIGlmIGl0IGNvbnRhaW5zIGFueSBvcHRp b24gb3RoZXIgdGhhbiBhIHNpbmdsZTxicj4NCiZuYnNwOyAmbmJzcDtFbmNyeXB0ZWQtbWVzc2Fn ZSBvcHRpb24uPGJyPg0KPGJyPg0KTm90ZTogVGhlcmUgYXJlIHNvbWUgb3RoZXIgb2RkIHVzZXMg b2YgY29udGFpbiAod2hlbiBhdCBsZWFzdCBJIHRoaW5rIHRoZSB0ZXh0IHNob3VsZCB1c2UgaW5j bHVkZSkuIEJ1dCBpdCBtYXkgbm90IGJlIHdvcnRoIHRyeWluZyB0byBjaGFuZ2UgdGhlc2UgKHRo ZSB1c2FnZSBpcyB0cmlja3kgLSB5b3UgY2FuIGdvb2dsZSBmb3IgJnF1b3Q7ZW5nbGlzaCBjb250 YWluIHZzIGluY2x1ZGUmcXVvdDsgaWYgeW91IGxpa2UpLiBXZSB3aWxsIGxlYXZlIGl0IHRvIHRo ZSBSRkMNCiBlZGl0b3IgdG8gcGVyaGFwcyBjbGVhbiB0aGVzZSB1cCBpZiBhcHByb3ByaWF0ZS48 YnI+DQo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBUaGUgY2xpZW50IE1BWSB1c2Ug dGhlIEF1dGhlbnRpY2F0aW9uRmFpbCBhcyBhIGhpbnQgYW5kIHN3aXRjaDxicj4NCiZuYnNwOyAm bmJzcDsgJm5ic3A7IHRvIG90aGVyIERIQ1B2NiBzZXJ2ZXIgaWYgaXQgaGFzIGFub3RoZXIgb25l Ljxicj4NCjxicj4NCkNoYW5nZSB0byAmcXVvdDt0byBhbm90aGVyIERIQ1Agc2VydmVyIGlmIGl0 IGhhcyBvbmUmcXVvdDs/PGJyPg0KPGJyPg0KU2VjdGlvbiA3Ojxicj4NCjxicj4NCiZuYnNwOyAm bmJzcDtVcG9uIHRoZSByZWNlaXB0IG9mIEVuY3J5cHRlZC1RdWVyeSBtZXNzYWdlLCB0aGUgc2Vy dmVyIE1VU1QgZHJvcCB0aGU8YnI+DQombmJzcDsgJm5ic3A7bWVzc2FnZSBpZiB0aGUgb3RoZXIg REhDUHY2IG9wdGlvbiBpcyBjb250YWluZWQgZXhjZXB0IFNlcnZlcjxicj4NCjxicj4NCkhlcmUg JnF1b3Q7dGhlIG90aGVyJnF1b3Q7IHNob3VsZCBjaGFuZ2UgdG8gJnF1b3Q7YW5vdGhlciZxdW90 Oy48YnI+DQo8YnI+DQpOb3RlOiBUaGVyZSBhcmUgc2V2ZXJhbCBvdGhlciBwbGFjZXMgd2hlcmUg Y29udGFpbmVkL2NvbnRhaW4gd291bGQgKGF0IGxlYXN0IGluIG15IG1pbmQpIGJlIG1vcmUgJnF1 b3Q7c3RhbmRhcmQmcXVvdDsgaWYgdGhlIHRleHQgdXNlZCBpbmNsdWRlZC9pbmNsdWRlLiBTYW1l IGdvZXMgZm9yIHVzZSBvZiAmcXVvdDtvdGhlciZxdW90OyAoLSZndDsgYW5vdGhlcikuPGJyPg0K PGJyPg0KTGFzdCBwYXJhZ3JhcGggb2Ygc2VjdGlvbiA3LCAmcXVvdDt0aGVuIHRoZSBzZXJ2ZXIg c2V0IHRoZSZxdW90Oy4gU2V0IHNob3VsZCBiZSBzZXRzLjxicj4NCjxicj4NClNlY3Rpb24gMTAu MS4xPGJyPg0KPGJyPg0KRm9yIEVBLWxlbiwgbWlnaHQgYmUgZ29vZCB0byBhZGQgJnF1b3Q7KG11 c3QgYmUgYSBtdWx0aXBsZSBvZiAyKSZxdW90Ozxicj4NCkZvciBTSEEtbGVuLCBtaWdodCBiZSBn b29kIHRvIGFkZCAmcXVvdDsobXVzdCBiZSBhIG11bHRpcGxlIG9mIDQpJnF1b3Q7PGJyPg0KPGJy Pg0KQWxzbywgSSB0aGluayB5b3Ugc2hvdWxkIGNoYW5nZSBhbGwgJnF1b3Q7Mi1vY3RldHMgdmFs dWUmcXVvdDsgdG8gJnF1b3Q7Mi1vY3RldCB2YWx1ZSZxdW90Oy48YnI+DQo8YnI+DQpTZWN0aW9u IDExPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwO0ZvciB0aGlzIHNlY3VyaXR5IGl0ZW0sIEl0IGlz IFJFQ09NTUVOREVEIHRoYXQgY2xpZW50IGNlcnRpZmljYXRlczxicj4NCiZuYnNwOyAmbmJzcDtj b3VsZCBiZSB0aWVkIHRvIHNwZWNpZmljIHNlcnZlciBjZXJ0aWZpY2F0ZXMgYnkgY29uZmlndXJh dGlvbi48YnI+DQo8YnI+DQpMb3dlciBjYXNlICZxdW90O0l0JnF1b3Q7Pzxicj4NCjxicj4NCjxi cj4NCkdlbmVyYWw8YnI+DQo8YnI+DQpUaGVyZSBhcmUgdXNlcyBvZiAmcXVvdDtjZXJ0JnF1b3Q7 IGFuZCAmcXVvdDtjZXJ0cyZxdW90OyBhbmQgJnF1b3Q7Y2VydGlmaWNhdGUocykmcXVvdDsuIEFy ZSB0aGVzZSBvbmUgaW4gdGhlIHNhbWU/IFNob3VsZG4ndCB3ZSBqdXN0IHVzZSAmcXVvdDtjZXJ0 aWZpY2F0ZSZxdW90OyB0aHJvdWdob3V0PyBPciBwZXJoYXBzIHlvdSBzaG91bGQgYWRkICZxdW90 O2NlcnQocykmcXVvdDsgdG8gdGVybWlub2xvZ3kgc2VjdGlvbj88YnI+DQo8YnI+DQo8YnI+DQot IEJlcm5pZTxicj4NCjxicj4NCjxzcGFuIGNsYXNzPSJnbWFpbC0iPi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tPC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJnbWFpbC0iPkZyb206IGRoY3dnIFtt YWlsdG86PGEgaHJlZj0ibWFpbHRvOmRoY3dnLWJvdW5jZXNAaWV0Zi5vcmciPmRoY3dnLWJvdW5j ZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgVG9tZWsgTXJ1Z2Fsc2tpPC9zcGFuPjxicj4N CjxzcGFuIGNsYXNzPSJnbWFpbC0iPlNlbnQ6IFdlZG5lc2RheSwgTWFyY2ggMDgsIDIwMTcgODoz NyBBTTwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iZ21haWwtIj5UbzogZGhjd2cgJmx0OzxhIGhy ZWY9Im1haWx0bzpkaGN3Z0BpZXRmLm9yZyI+ZGhjd2dAaWV0Zi5vcmc8L2E+Jmd0Ozwvc3Bhbj48 YnI+DQo8c3BhbiBjbGFzcz0iZ21haWwtIj5DYzogZHJhZnQtaWV0Zi1kaGMtc2VkaGNwdjYgYXV0 aG9ycyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtZGhjLXNlZGhjcHY2QGlldGYub3Jn Ij5kcmFmdC1pZXRmLWRoYy1zZWRoY3B2NkBpZXRmLm9yZzwvYT4mZ3Q7PC9zcGFuPjxicj4NCjxz cGFuIGNsYXNzPSJnbWFpbC0iPlN1YmplY3Q6IFtkaGN3Z10gV0dMQyBvbiBkcmFmdC1pZXRmLWRo Yy1zZWRoY3B2Ni0yMSAtIFJlc3BvbmQgYnkgTWFyY2ggMjl0aDwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206MTIuMHB0Ij5IaSw8YnI+DQpkcmFmdC1pZXRmLWRoYy1zZWRoY3B2Ni0yMSBkZXNjcmliZXMg YSBtZWNoYW5pc20gZm9yIHVzaW5nIHB1YmxpYyBrZXkgY3J5cHRvZ3JhcGh5IHRvIHByb3ZpZGUg ZW5kLXRvLWVuZCBzZWN1cml0eSBiZXR3ZWVuIERIQ1B2NiBjbGllbnRzIGFuZCBzZXJ2ZXJzLiBU aGUgbWVjaGFuaXNtIHByb3ZpZGVzIGVuY3J5cHRpb24gaW4gYWxsIGNhc2VzLCBhbmQgY2FuIGJl IHVzZWQgZm9yIGF1dGhlbnRpY2F0aW9uIGJhc2VkIG9uIHByZS1zaGFyaW5nIG9mDQogYXV0aG9y aXplZCBjZXJ0aWZpY2F0ZXMuIFRoaXMgZHJhZnQgaGFzIHN0YXJ0ZWQgaW4gMjAxMywgYnV0IHRo ZSB3aG9sZSBESENQdjYgc2VjdXJpdHkgc2FnYSBpcyBtdWNoIGxvbmdlciBhbmQgYmVnaW5zIGlu IDIwMDguIFRoaXMgZHJhZnQgd2FzIHN1Ym1pdHRlZCB0byBJRVNHIGluIG1pZC0yMDE1Ljxicj4N ClRoZSBndWlkYW5jZSByZWNlaXZlZCB3YXMgY2xlYXIgdGhhdCZuYnNwOyBzdWJzdGFudGlhbCBj aGFuZ2VzIGFyZSBuZWVkZWQuIEFzIGEgcmVzdWx0LCAmcXVvdDtlbmNyeXB0IGV2ZXJ5d2hlcmUs IGF1dGhlbnRpY2F0ZSBpZiB5b3UgY2FuJnF1b3Q7IGFwcHJvYWNoIHdhcyB1c2VkLjxicj4NCjxi cj4NCkF1dGhvcnMgYmVsaWV2ZSB0aGlzIGRyYWZ0IHRvIGJlIHJlYWR5IGZvciB3b3JraW5nIGdy b3VwIGxhc3QgY2FsbC48YnI+DQo8YnI+DQpQbGVhc2Ugc2VuZCB5b3VyIHN1YnN0YW50aWFsIGNv bW1lbnRzIHRvIHRoZSBtYWlsaW5nIGxpc3QgYW5kIGV4cHJlc3MgeW91ciBvcGluaW9uIHdoZXRo ZXIgdGhpcyBkcmFmdCBpcyByZWFkeSBmb3IgcHVibGljYXRpb24uIEZlZWwgZnJlZSB0byBzZW5k IG5pdHBpY2tzIGFuZCBtaW5vciBjb3JyZWN0aW9ucyB0byB0aGUgYXV0aG9ycyBkaXJlY3RseS4g VGhpcyBpcyBhIGNvbXBsZXggZHJhZnQsIHNvIHRoZSBjaGFpcnMgYmVsaWV2ZSAzIHdlZWtzDQog V0dMQyBpcyBpbiBvcmRlci4gUGxlYXNlIHNlbmQgeW91ciBjb21tZW50cyBubyBsYXRlciB0aGFu IE1hcmNoIDI5dGguIEJlcm5pZSBhbmQgSSB3aWxsIGRldGVybWluZSBjb25zZW5zdXMgYW5kIHdp bGwgZGlzY3VzcyBkdXJpbmcgQ2hpY2FnbyBtZWV0aW5nIGFzIG5lZWRlZC48YnI+DQo8YnI+DQpU byBpbml0aWF0ZSB0aGUgZGlzY3Vzc2lvbiwgSSBoYXZlIHR3byByZWxhdGVkIHF1ZXN0aW9ucy4g VGhlIGNoYWlycyB3b3VsZCBsb3ZlIHRvIGhlYXIgeW91ciBvcGluaW9ucyBvbiB0aG9zZS48YnI+ DQo8YnI+DQoxLiBUaGUgJnF1b3Q7ZW5jcnlwdCBldmVyeXdoZXJlJnF1b3Q7IHBhcmFkaWdtIG1l YW5zIHRoYXQgaW4gZGVwbG95bWVudHMgdGhhdCBkbyBzbm9vcGluZyBvbiByZWxheSB3aWxsIGJy ZWFrIGRvd24uIFRvIHNvbHZlIHRoaXMgcHJvYmxlbSwgd2UgbmVlZCBhIGFzc2lnbm1lbnQgbm90 aWZpY2F0aW9uIG1lY2hhbmlzbSwgc2ltaWxhciB0byB0aGUgb25lIGRlc2NyaWJlZCBpbiBkcmFm dC1pZXRmLWRoYy1kaGNwdjYtYWdlbnRvcHQtZGVsZWdhdGUtMDQuIFRoYXQgZHJhZnQNCiBleHBp cmVkIG1hbnkgeWVhcnMgYWdvLiBUaGlzIG1hdHRlciB3YXMgZGlzY3Vzc2VkIGluIFNlb3VsIGFu ZCB0aGUgbWludXRlcyBkZXNjcmliZSB0aGUgY29uY2x1c2lvbiBhczo8YnI+DQo8YnI+DQombmJz cDsgVGhlIGRpc2N1c3Npb24gZ3Jhdml0YXRlZCB0b3dhcmRzIG5vdCByZXN1cnJlY3RpbmcgdW50 aWwgdGhlIHNlZGhjcHY2PGJyPg0KJm5ic3A7IEktRCBwcm9ncmVzc2VzIGZ1cnRoZXIuIFdlIHdp bGwgcmVldmFsdWF0ZSB0aGlzIG9uY2Ugc2VkaGNwdjYgaXMgZG9uZS48YnI+DQo8YnI+DQpEbyB5 b3Ugd2FudCB0aGUgV0cgdG8gcmVzdXJyZWN0IGFnZW50b3B0LWRlbGVnYXRlIGEpIG5vdywgYikg d2hlbjxicj4NCnNlZGhjcHY2IGlzIHNlbnQgdG8gSUVTRyBvciBjKSB3aGVuIHNlZGhjcHY2IGlz IHB1Ymxpc2hlZCBhcyBSRkM/IGQpIHdlIG5lZWQgYSBjb21wbGV0ZWx5IG5ldyBkcmFmdCBhbmQg SSdtIHZvbHVudGVlcmluZyB0byB3b3JrIG9uIGl0Ljxicj4NCjxicj4NCjIuIE9uZSBvZiB0aGUg YXV0aG9ycyBzdWdnZXN0ZWQgdGhhdCB0aGlzIHByb3RvY29sIGlzIHF1aXRlIGNvbXBsZXggYW5k IGhhdmluZyBhIGZlZWRiYWNrIGZyb20gYW4gaW1wbGVtZW50YXRpb24gKG9yIGlkZWFsbHkgdHdv IGludGVyb3BlcmF0aW5nKSB3b3VsZCBiZSB2ZXJ5IGltcG9ydGFudCBhbmQgd291bGQgbGlrZWx5 IHJlc3VsdCBpbiBzb21lIGNoYW5nZXMgdG8gdGhlIGRyYWZ0LiBJdCdzIHByb2JhYmx5IHRvbyBs YXRlIGZvciBDaGljYWdvLA0KIGJ1dCB3ZSBjYW4gb3JnYW5pemUgYTxicj4NCnNlZGhjcHY2IGhh Y2thdGhvbiBpbiBQcmFndWUuIFR3byBsaWtlbHkgaW1wbGVtZW50YXRpb25zIHdvdWxkIGJlIFdJ REUgYW5kIEtlYSwgYXMgdGhvc2UgdHdvIGFyZSBvcGVuIHNvdXJjZSBhbmQgaGF2ZSBhbiBvbGQg dmVyc2lvbiBvZiB0aGUgZHJhZnQgcGFydGlhbGx5IGltcGxlbWVudGVkLiBEbyB5b3UgdGhpbmsg c3VjaCBhIGhhY2thdGhvbiB3b3VsZCBiZSB1c2VmdWw/IEFyZSB5b3Ugd2lsbGluZyB0byBwYXJ0 aWNpcGF0ZT88YnI+DQo8YnI+DQpUaXRsZTogU2VjdXJlIERIQ1B2Njxicj4NCkF1dGhvcnM6IEwu IExpLCBTLiBKaWFuZywgWS5DdWksIFQuSmlubWVpLCBULkxlbW9uLCBELlpoYW5nPGJyPg0KRmls ZW5hbWU6IGRyYWZ0LWlldGYtZGhjLXNlZGhjcHY2LTIxPGJyPg0KUGFnZXM6IDMxPGJyPg0KRGF0 ZTogMjAxNy0wMi0yMTxicj4NCkxpbms6IDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWlldGYtZGhjLXNlZGhjcHY2LyIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1kaGMtc2VkaGNwdjYvPC9h Pjxicj4NCjxicj4NClJlc3BvbnNlcyBieSBNYXJjaCAyOXRoIGFyZSBhcHByZWNpYXRlZC48YnI+ DQo8YnI+DQpUaGFua3MsPGJyPg0KQmVybmllIGFuZCBUb21lazxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KZGhjd2cgbWFpbGluZyBsaXN0PGJyPg0KPGEg aHJlZj0ibWFpbHRvOmRoY3dnQGlldGYub3JnIj5kaGN3Z0BpZXRmLm9yZzwvYT48YnI+DQo8YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RoY3dnIiB0YXJnZXQ9 Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaGN3ZzwvYT48 bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_369C97B6B6E746CEB42E18559BFB1E78ciscocom_-- From nobody Mon Mar 27 21:06:29 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 969F812922E; Mon, 27 Mar 2017 21:06:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.402 X-Spam-Level: X-Spam-Status: No, score=-2.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 JaXQdHKkuoMd; Mon, 27 Mar 2017 21:06:25 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64B3C12025C; Mon, 27 Mar 2017 21:06:25 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id p22so55977306qka.3; Mon, 27 Mar 2017 21:06:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=rVExIxcer1fZvA/9SXTy4xKS086cFvDXP3KOWNAZM6w=; b=rVNshmjrn6hqN0XC5nvMosPuAxFucPpLTV2ttVwwr1H6Reroyvbphyz+JQwohmMonq 9g8+9wK/9w1I521SMhSabktsGGVICBnsj0obn5bjt8YIy9uRazMebwDvkKvRULBfj06b 7tc5l3eFNr/5uMRhzpFh+xZLCswKXDcy0+7s5iL3gRDP/UPh4Q8QgLr4as5ecw1+8l2U aC29CrwCkzklEbFB/vHuWvYK9hPnwzwHt11LOgBawqeBa6EbQePWUAKb+5jZ7mm5uhsa CvHLFv5d2f0OXLyDrLJnvXx3WnNW+1dpszihYovtqXJfSJH5M/y95KfA1FG+jxZCQSSJ a/1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=rVExIxcer1fZvA/9SXTy4xKS086cFvDXP3KOWNAZM6w=; b=ssxemuu/wpEr7LhWqQfrB4CApA32OuHD62c43uThq0xHdPW7WgzFysifCfi0k+tNmZ sD+MzaTwwSAbeGPTkgE77i5LtXd2Pds7Nla64wKvNSfNRqTVbITgBFO/cPlnPf9xix1M gDgmat0MHbzMsc0sM04ns0EZc/G4HjHzaxqndre7Kj7lepIDrmVTQGN6KcrSZmyh8R++ orNrZVQB6FD2cLHwYGSqSVBK6w01zJLnKe7jPxRpCCby9xYEnY3OHZgTykTGwJ+qcyUv oFRWZI/fjxEgw4XKs1Imi+j3PgVnGdC9Q47KhRtYLRLo2O3bqOeN+7xSD5vBpLioEFZw llyg== X-Gm-Message-State: AFeK/H2AhDEYmDASWCRkqQnIXusWrMTEHjOUF2sCdl7ebB0iPIXFQhQjbqzIz6lUI3mNXVPwZTy6f2KPHJAciA== X-Received: by 10.55.158.132 with SMTP id h126mr17299228qke.86.1490673984251; Mon, 27 Mar 2017 21:06:24 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.61.204 with HTTP; Mon, 27 Mar 2017 21:06:23 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Mon, 27 Mar 2017 21:06:23 -0700 X-Google-Sender-Auth: 8HnorShxun4X9k74-HOcGD8SLj8 Message-ID: To: Tomek Mrugalski Cc: dhcwg , draft-ietf-dhc-sedhcpv6 authors Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-sedhcpv6-21 - Respond by March 29th X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 04:06:27 -0000 On Wed, Mar 8, 2017 at 5:36 AM, Tomek Mrugalski wrote: > Authors believe this draft to be ready for working group last call. > > Please send your substantial comments to the mailing list and express > your opinion whether this draft is ready for publication. See below. > 2. One of the authors suggested that this protocol is quite complex and > having a feedback from an implementation (or ideally two interoperating) > would be very important and would likely result in some changes to the > draft. It's probably too late for Chicago, but we can organize a > sedhcpv6 hackathon in Prague. Two likely implementations would be WIDE > and Kea, as those two are open source and have an old version of the > draft partially implemented. Do you think such a hackathon would be > useful? Are you willing to participate? I think a hackathon for this is useful. I'm not sure if I attend the Prague meeting at all, but if I do I'm willing to participate in the hackathon. The rest is my response to the last call and comments on ietf-dhc-sedhcpv6-21. Personally I won't support publishing it until I see at least one implementation of this spec (I know it's only me and I know it's not a formal prerequisite for passing a WGLC). I also think the issue about Confirm (for which I've sent a separate message) should be resolved first. Another high level concern is that we've had very few reviews on this document so far. I have some feeling that the wg as a whole actually is not interested in this topic. If that's the reality we may even have to consider abandoning it. That said, I'm providing my own review comments on the draft. I believe most of them are straightforward to address, but there's at least one non-trivial proposal: regarding the use of transaction-id value of 0 for Reconfigure. - Section 1 This document provides a brief summary of the security vulnerabilities of the DHCPv6 protocol and then [...] On a fresh read I've realized it doesn't really talk about general "security vulnerabilities of the DHCPv6 protocol". I suggest revising it as follows: This document provides a brief summary of the issues of current security mechanisms for the DHCPv6 protocol and then [...] - Section 6 [...] In some scenario where non-authenticated encryption can be accepted, such as coffee shop, then authentication is optional and can be skipped. I don't think non-authenticated encryption is *acceptable* in the coffee shop scenario. We use it in that case since it's just better than nothing. I suggest: [...] In some scenarios, such as for coffee shops, full authentication is hard to deploy but opportunistic security (i.e., encryption without authentication) may be still helpful. In such cases authentication is optional and can be skipped. - Section 6 [...] If the transaction-id is 0, the client also try to decrypt it. Then, the client extracts the Encrypted- message option and decrypts it using its private key to obtain the original DHCPv6 message. In this document, it is assumed that the client will not have multiple DHCPv6 sessions with different DHCPv6 servers using different key pairs and only one key pair is used for the encrypted DHCPv6 configuration process. [...] This is not very readable. I know it talks about key identification and the rationale for the case of tid=0. But I suspect it's difficult to understand for those without background discussion. I also wonder whether we really need to impose the assumption of "only one key pair". This is only necessary for a rare case of Redirect; for other normal cases the client should be able to identify the key from the transaction id. I'd rather suggest removing the assumption and having the client try all possible keys in case of tid=0 (but in practice the number of possible keys to be tried should be very small, and quite likely to be one). For these reasons I suggest revising the whole paragraph as follows: For the received Encrypted-Response message, the client MUST drop the Encrypted-Response message if other DHCPv6 option except Encrypted- message option is contained. The client then identifies the public key to decrypt the message encapsulated in the Encrypted-message option. If the transaction-id of the Encrypted-Response message is not 0, there should be a corresponding Encryption-Query message for a particular DHCPv6 session. In this case the client uses the private key of the key pair used in that session. If the transaction-id of the Encrypted-Response message is 0, this means it encapsulates a Reconfigure message (see Section 7). In this case the client MUST try the private keys of all DHCPv6 sessions in use at that point. Note that the number of such sessions should be very small, most likely just one, in practice. After the decryption, it handles the message as per [RFC3315]. If the decrypted DHCPv6 message contains the Increasing-number option, the DHCPv6 client checks it according to the rule defined in Section 9.1. - Section 6 (and as part of general design): related to the previous point, I think it's better to prohibit the transaction ID of 0 for Encryption-query messages (the client must re-generate the ID when its implementation generates 0). Otherwise it's possible for the client to see a 0 transaction ID in Encryption-response messages for normal cases other than Reconfigure. - Section 7 [...] The server selects one hash, signature, encryption algorithm from the acknowledged algorithms sets for the future communication. And then, the server replies with a Reply message to the client. The Reply message MUST contain the requested Certificate option, which MUST be constructed as explained in Section 10.1.2, and Server Identifier option. This could read as if there's exactly one (and only one) Certificate option in the Reply, but there can be actually two, one for signature and one for encryption, right? Then above text should be revised to make it clearer. - Section 7 Once the client has been authenticated, the DHCPv6 server sends the Encrypted-response message to the DHCPv6 client. If the DHCPv6 message is Reconfigure message, then the server set the transaction- id of the Encrypted-Response message to 0. This is awkward. The first sentence seems to assume a normal exchange (client sends some message and the server responds to it), but that's not the case for Reconfigure. I suggest revising it as follows: Once the client has been authenticated, the DHCPv6 server sends the Encrypted-response message to the DHCPv6 client. The server may also generate a Reconfigure message encapsulated in an Encrypted-response message to a client with which a secure DHCPv6 session has been established. In the latter case the server sets the transaction-id of the Encrypted-Response message to 0. - Section 9.1 I still don't understand how exactly this works. From a quick read of his comments I guess Bernie already made the same question in more detail, so I just point out that it's not clear to me either. - Section 9.2 I don't think we need to paste the reference C implementation; a reference to appendix B of RFC4034 should be enough. Besides, the code comment is incorrect: unsigned char key[], /* the RDATA part of the DNSKEY RR */ unsigned int keysize /* the RDLENGTH */ - Section 10.1.1 [...] This design is adopted in order to provide encryption algorithm agility. I suggest removing this sentence (for EA-id, SA-id, and HA-id). We already know it's for algorithm agility at this point of the document; I don't see the need for repeating it again and again. - Section 10.1.1: in my understanding EA-id in the algorithm option must not be 0. Is that correct? If so, I think it's better to be described explicitly. Same for SA-id. On the other hand, I guess HA-id can be 0, in which case signature algorithm also identifies the hash algorithm. This should also be explicitly documented. - Section 10.1.2: in my understanding it's possible that EA-id and SA-id are both non-0. In fact, it's probably the typical case for the current mandatory algorithms (both are RSA-based). I think it should be noted explicitly. - Section 10.1.3 The Certificate option carries the certificate of the client/server, which is contained in the Reply message. I believe it's also included in other messages from the client. - Section 10.1.3 o SA-id: Signature Algorithm id. The signature algorithm is used for computing the signature result. This design is adopted in order to provide signature algorithm agility. [...] o HA-id: Hash Algorithm id. The hash algorithm is used for computing the signature result. This design is adopted in order to provide hash algorithm agility. [...] "This design is adopted in order to provide signature algorithm agility" should better be removed (see above). - Section 10.1.3: I don't think the current description is sufficient to understand how to calculate the signature. IIRC older versions of sedhcpv6 (pre-encryption versions) explain it in more detail. We should provide the same level of details. - Section 10.2 transaction-id The transaction ID for this message exchange. I propose transaction-id value of 0 must be prohibited for Encryption-Query message (see above). If we agree, this description should note that. - Section 10.2 options The Encrypted-Query message MUST contain the Encrypted-message option, Encryption-Key-Tag option and Server Identifier option if the message in the Encrypted-message option has a Server Identifier option. [...] This is a bit ambiguous to me. Suggestion: options The Encrypted-Query message MUST contain the Encrypted-message option and Encryption-Key-Tag option. If the message in the Encrypted-message option has a Server Identifier option, the Encrypted-Query message MUST also contain a Server Identifier option. [...] - Section 11 If the client tries more than one cert for client authentication, the server can easily get a client that implements this to enumerate its entire cert list and probably learn a lot about a client that way. For this security item, It is RECOMMENDED that client certificates could be tied to specific server certificates by configuration. The second sentence is hard to understand and awkward anyway. It's not clear what "this security item" means, and the combination of RECOMMENDED and "could be" sounds awkward. - Section 12 Hash Algorithm for Secure DHCPv6. [...] Name | Value | RFCs -------------------+---------+-------------- SHA-256 | 0x01 | this document SHA-512 | 0x02 | this document I believe we should also add a value 0x00. Signature Algorithm for Secure DHCPv6. [...] Name | Value | RFCs -------------------+---------+-------------- Non-SigAlg | 0x00 | this document I'd add an internal reference to this document (also, the term "Non-SigAlg" should be explicitly defined). I'd also note that, though maybe not here, this value can't be used in the algorithm option. Same for Encryption algorithm and Non-EncryAlg. -- JINMEI, Tatuya From nobody Mon Mar 27 21:16:33 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF6901275C5 for ; Mon, 27 Mar 2017 21:16:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.702 X-Spam-Level: X-Spam-Status: No, score=-1.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Mo8K03-V_vB3 for ; Mon, 27 Mar 2017 21:16:31 -0700 (PDT) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76A64126DED for ; Mon, 27 Mar 2017 21:16:31 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id n21so54806795qta.1 for ; Mon, 27 Mar 2017 21:16:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=MHMyDPNY2afAGE5EIWEWgOZ5heEFwsQ+A1FMHo0qIko=; b=ooV8uX/3vkmXXAHCikVCcNvVi8AWqFyjIgOj9CUC3PYUxcS8SQJbP2NT+IBFnaQJh4 s+bdEhHdZaDaTfRJ46641IWk+Xy3ZW4Ff9tvvGjN81uF2lR+/4iGOcoeUILZPIb6KaH0 qSQBi4SZnmIQgB0KkkP47weJTI0Mi+RVikqTWhY8ZBObVBZ5dhERUTyeqhQ57jCU+Uu/ UoQnWnmWjlqTQBrJZpQWEjvKI6n4lQEJLVg9HzdJZCjpV6NkaM5e/sZXJoOfas/apClM a/V9CZrY3IyufvoVVssnWkPwQccxx08i8zbUupVCQwAZIU1h3HT+tsQSyBR+9k8LJai+ JCDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=MHMyDPNY2afAGE5EIWEWgOZ5heEFwsQ+A1FMHo0qIko=; b=Og4rKaa7M0eBAPoNPU+BQAgZj7Yw3fWNmXhYGeYyIMFz0T6tBjcfg7wU4taheDq0P9 8uvMwXJyX26Bevr8PTU0qdUhYZDrHRx/3S/EE4F69/Tpkhl9GitOQnTOE2zRW9UNaLMF afhCK/kd1wumK1A9OCWHihrcgrq2GGlYTq03Xn8/+CFCXsqvh0rQUzHdKbEeY+TgkppR 1gbK5zFuF6Pi5t/31O7uqw4H5B6LfMWxnTpfPwNEjQz2Ouwk8SFe3M/TuUvv3e4U2x41 +ga8KwSMmvBVT0sL9QE0Nq1lJULJuUKRZ3fcrJv+eHmTiUMcaxJC+xsb8KVWUq91ahyz n1SA== X-Gm-Message-State: AFeK/H2tH2JhPo4dQl80N4tvIhClBgv8rf29ysfhibFCzOH8gzLlcPfSYVqQtrLkXLKT8bz2l4VbPIuKmwXMiw== X-Received: by 10.200.56.48 with SMTP id q45mr24632974qtb.220.1490674590583; Mon, 27 Mar 2017 21:16:30 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.61.204 with HTTP; Mon, 27 Mar 2017 21:16:30 -0700 (PDT) In-Reply-To: <3566F64B-D709-4DF3-9A5F-7648DA8FC45E@cisco.com> References: <3566F64B-D709-4DF3-9A5F-7648DA8FC45E@cisco.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Mon, 27 Mar 2017 21:16:30 -0700 X-Google-Sender-Auth: JRM_GETPBkRB9gNOAecJAZmUik0 Message-ID: To: "Bernie Volz (volz)" Cc: "dhcwg@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [dhcwg] whether/how to support Confirm with sedhcpv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 04:16:33 -0000 At Sun, 26 Mar 2017 14:44:49 +0000, "Bernie Volz (volz)" wrote: > Good point ... I was thinking that encrypted Confirm (or Rebind) > would be fine - if still on same link (or at least server) it would > work just fine. Otherwise, client times out and is left to use other > mechanisms (RS/RA)? I think that's find in the case of Rebind: if the current server dies but there are other available servers, and if the admin chooses to deploy sedhcpv6 in that network, other servers hopefully share the same server key pair and can decrypt the encrypted Rebind. (But even if so, it may be a good idea to discuss this point explicitly). But, in the case of Confirm and when the client has actually moved, this approach will involve some longer time until the client falls back to other mechanisms including a restart of DHCPv6. This is worse than the current Confirm without sedhcpv6, and I think it's generally better to eliminate such regression. -- JINMEI, Tatuya From nobody Tue Mar 28 08:28:40 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AEAF1289C3 for ; Tue, 28 Mar 2017 08:28:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 suE1ceED1y_E for ; Tue, 28 Mar 2017 08:28:37 -0700 (PDT) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71186127010 for ; Tue, 28 Mar 2017 08:28:37 -0700 (PDT) Received: by mail-pg0-x22f.google.com with SMTP id 81so61406134pgh.2 for ; Tue, 28 Mar 2017 08:28:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mKe+qB607f3Rms0OeztPSyziwIl1DW7nZkq7T5L6+94=; b=tKAlgLYtA+EsyB2NyUuFM25rLmzsGk+j4a4o379CAehQYwWUQ/RnYFGulgLf0ZDXNb n1wJIHAOh2uk6K6b+ylP7zL3eTtuSuYba06qmip7gk72BwO1P77gr5VUu/8P9W9GlgHL bL3OgRencKrXjuoojSzWJM1S4ZIpepCCEn0ASZtAQ0Clwzz+WF/aA5XEDKHGrLyFihfJ gvwZO1MEsOnD1sZ7dTVaZYRAvLg3HE3/G6PnDcYkjD4UB1xjxE0OPzyhg85vYNC8UUju 6XWJt6N8srBw98MEh+b+g1dxrWHqxLBuZOO9btnXeDO8WNlK2FRXGgDF4F0mcF6zx+dJ z8AQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mKe+qB607f3Rms0OeztPSyziwIl1DW7nZkq7T5L6+94=; b=aetPFAjSLy9RbXp5HIhb17Wn7DC5mSL5e+CRGiON76fS6PKQBolZbT3udyr0kBKSOn F/cWjaZk8vqok7idZgcarK4PsTRfead26umlvWXf5VwMqnV9mYEhqN4HfCRD2off+2kT RjE6BHc7S977qfg4/C7HVWyqwdxZNthDc/HxScnoSckRqax6V2R73cozLoHAw6yv8Ici JoPr94FkenoaFKrLK4gGUbMIF46ZrkVEZK5BHYnvD1OOFTGm8+wKgQacVQaVMkvl5hFW W4wmGR9C311871/+MdH5oml7nGK1PInsVP8vl5hhZXKHl5VHXBmh2sXU81lsWjGswZV2 T4Ag== X-Gm-Message-State: AFeK/H1h0aCuuA7DIeTkskELJCUhVc8VCZsOZkJ1ym06I6e2DxIBt0bQMa4w4bfyf5QUjA== X-Received: by 10.84.142.133 with SMTP id 5mr37539073plx.129.1490714917058; Tue, 28 Mar 2017 08:28:37 -0700 (PDT) Received: from [172.16.3.182] (99-138-101-145.lightspeed.cicril.sbcglobal.net. [99.138.101.145]) by smtp.gmail.com with ESMTPSA id v16sm8205574pgo.29.2017.03.28.08.28.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Mar 2017 08:28:36 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ted Lemon In-Reply-To: Date: Tue, 28 Mar 2017 10:28:34 -0500 Cc: "Bernie Volz (volz)" , "dhcwg@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <4512A1F7-A480-4250-BE57-FCE822EAC890@fugue.com> References: <3566F64B-D709-4DF3-9A5F-7648DA8FC45E@cisco.com> To: =?utf-8?B?56We5piO6YGU5ZOJ?= X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [dhcwg] whether/how to support Confirm with sedhcpv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 15:28:39 -0000 Probably the most expedient way to handle this would be to create a = confirm, sign and encrypt it, and then wrap it the same way we wrap = relay messages, including it in an information-request as in the regular = IR/Solicit/Confirm process for secure DHCP. The server on the local wire either supports the wrapping and can = decrypt, supports it but cannot decrypt, or doesn't support it and hence = ignores it. This allows the client to send a single packet that will = always elicit a response, either an answer to the question asked in the = Information request, or else a confirmation that it's okay to continue = using the address. The hard question is, what do you do if you get an answer to the = information request, rather than to the Confirm? But I think that's = straightforward: you wait a (short) while to see if you get an answer to = the confirm; if you do, you take that; otherwise you take the answer = from the Information-Request. From nobody Tue Mar 28 08:44:40 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04AAB12945C for ; Tue, 28 Mar 2017 08:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 c1fk77YP42_r for ; Tue, 28 Mar 2017 08:44:37 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25CF5127010 for ; Tue, 28 Mar 2017 08:44:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2986; q=dns/txt; s=iport; t=1490715877; x=1491925477; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=V9PC4J2Kbwk5G5ZvS7MoeZMC2eVCvINtA01fFHe7Z4E=; b=KXw1PANu4fKbUwY2BiRZMRvRDIjAeE7kkH5m1e6ydCkv0xb5e3OfZKXP jOwbz+cWk9xnphjdjCX+v0wkt2q3kxkKWfd2hcn9Hyt5K3LvS2o5rN2Vo lF+5+nEhQP9rg9fzv+UCFbvNPrR3YScHdllEFCWu8PVa/VoAEcxmJXc4j w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C0AQDgg9pY/5pdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1SBbAeDW4oPpx2CDoYiAhqDBz8YAQIBAQEBAQEBayiFFgYjEUU?= =?us-ascii?q?QAgEIDgwCJgICAjAVEAIEAQ0FigesfoImik8BAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEdgQuHSIJqhD4WgwYugjEBBIkjkz0Bkk6RM4FskX0BHziBBFkVUgGERh2BY3W?= =?us-ascii?q?HMAeBKYENAQEB?= X-IronPort-AV: E=Sophos;i="5.36,237,1486425600"; d="scan'208";a="7862868" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Mar 2017 15:44:36 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v2SFiax1010367 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 28 Mar 2017 15:44:36 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 28 Mar 2017 10:44:35 -0500 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1210.000; Tue, 28 Mar 2017 10:44:35 -0500 From: "Bernie Volz (volz)" To: Ted Lemon , =?utf-8?B?56We5piO6YGU5ZOJ?= CC: "dhcwg@ietf.org" Thread-Topic: [dhcwg] whether/how to support Confirm with sedhcpv6 Thread-Index: AQHSpj3Fn2WlavvNXUqtanr4SSkvDaGnMo+VgALI7QCAALvGAP//wWsA Date: Tue, 28 Mar 2017 15:44:35 +0000 Message-ID: <80C62C74-BB9D-4F43-9C2F-A5EC02A63918@cisco.com> References: <3566F64B-D709-4DF3-9A5F-7648DA8FC45E@cisco.com> <4512A1F7-A480-4250-BE57-FCE822EAC890@fugue.com> In-Reply-To: <4512A1F7-A480-4250-BE57-FCE822EAC890@fugue.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1f.0.170216 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.242.245] Content-Type: text/plain; charset="utf-8" Content-ID: <03B0E94D60A8384BBA8BF89A6B2B5211@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [dhcwg] whether/how to support Confirm with sedhcpv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 15:44:39 -0000 SW50ZXJlc3RpbmcgaWRlYSDigKYNCg0KQnV0LCB3b3VsZG7igJl0IGp1c3Qgc2VuZGluZyB0aGUg aW5pdGlhbCBJbmZvcm1hdGlvbi1SZXF1ZXN0IHBlciBzZURIQ1B2NiB3aGljaCDigJxzb2xpY2l0 c+KAnSBzZXJ2ZXLigJlzIGNlcnRpZmljYXRlcyB3aXRoIHRoZSBFbmNyeXB0ZWQtTWVzc2FnZSBP cHRpb24gd2hpY2ggY29udGFpbmVkIHRoZSBDb25maXJtIChhbmQgYW4gRW5jcnlwdGlvbiBLZXkg VGFnIE9wdGlvbikgYmUgYmVzdD8gTm90IGV4YWN0bHkgc3VyZSB3aGF0IHRoZSByZWZlcmVuY2Ug dG8g4oCcd3JhcCByZWxheSBtZXNzYWdlc+KAnS4NCg0KV2UgbWlnaHQgYWxzbyBjb25zaWRlciB3 aGV0aGVyIHRoaXMgY291bGQgYmUgdXNlZnVsIGZvciB0aGUgUmViaW5kIChwcmVmaXggZGVsZWdh dGlvbiB2ZXJzaW9uIG9mIENvbmZpcm0pLg0KDQpBbmQsIHRoZW4gdGhlcmXigJlzIHRoZSBxdWVz dGlvbiBvZiB3aGF0IHRoZSBzZXJ2ZXLigJlzIHJlc3BvbnNlIGlzIOKApiBmb3IgdGhlIHNlcnZl ciB0aGF0IGNhbiBkZWNyeXB0LCBpdCB3b3VsZCBzZW5kIGEgUmVwbHkgZm9yIHRoZSBDb25maXJt KC9SZWJpbmQpIGFuZCBub3QgYW5zd2VyIHRoZSBJbmZvcm1hdGlvbi1SZXF1ZXN0Pw0KDQpCVFc6 IFJGQyA3ODQ0IChESENQIEFub255bWl0eSBQcm9maWxlcykgc2VjdGlvbiA0LjIgc2F5cyBub3Qg dG8gc2VuZCBDb25maXJtcy4gUGVyaGFwcyBmb3Igc2VESENQdjYsIHN0YXJ0aW5nIHdpdGggdGhl IHNlREhDUHY2IEluZm9ybWF0aW9uLVJlcXVlc3QgaXMgdGh1cyBPSyBhbmQgaWYgY2xpZW50IGRl dGVybWluZXMgc2FtZSBzZXJ2ZXIgZXhpc3RzIChiYXNlZCBvbiBjZXJ0aWZpY2F0ZSkgaXQgY291 bGQgdGhlbiBpc3N1ZSBDb25maXJtIChvciBqdXN0IFJlbmV3L1JlYmluZCkuIFJGQzc4NDQgNC4y IGFsc28gc3VnZ2VzdHMgdGhhdCBpZiBvdGhlciBpbmZvcm1hdGlvbiBhYm91dCB0aGUgbGluayBp cyBhdmFpbGFibGUgKHN1Y2ggYXMgU1NJRCksIHRoZSBDb25maXJtIG1pZ2h0IGJlIHNlbnQgZGly ZWN0bHkuDQoNClRoZSBtYWluIHF1ZXN0aW9uIGlzIGhvdyBtdWNoIHNwZWNpYWwgbWVjaGFuaXNt IHRvIGFkZD8gQmUgbmljZSB0byBub3QgbWFrZSBpdCB0b28gY29tcGxleC4NCg0KLSBCZXJuaWUN Cg0KT24gMy8yOC8xNywgMTE6MjggQU0sICJUZWQgTGVtb24iIDxtZWxsb25AZnVndWUuY29tPiB3 cm90ZToNCg0KICAgIFByb2JhYmx5IHRoZSBtb3N0IGV4cGVkaWVudCB3YXkgdG8gaGFuZGxlIHRo aXMgd291bGQgYmUgdG8gY3JlYXRlIGEgY29uZmlybSwgc2lnbiBhbmQgZW5jcnlwdCBpdCwgYW5k IHRoZW4gd3JhcCBpdCB0aGUgc2FtZSB3YXkgd2Ugd3JhcCByZWxheSBtZXNzYWdlcywgaW5jbHVk aW5nIGl0IGluIGFuIGluZm9ybWF0aW9uLXJlcXVlc3QgYXMgaW4gdGhlIHJlZ3VsYXIgSVIvU29s aWNpdC9Db25maXJtIHByb2Nlc3MgZm9yIHNlY3VyZSBESENQLg0KICAgIA0KICAgIFRoZSBzZXJ2 ZXIgb24gdGhlIGxvY2FsIHdpcmUgZWl0aGVyIHN1cHBvcnRzIHRoZSB3cmFwcGluZyBhbmQgY2Fu IGRlY3J5cHQsIHN1cHBvcnRzIGl0IGJ1dCBjYW5ub3QgZGVjcnlwdCwgb3IgZG9lc24ndCBzdXBw b3J0IGl0IGFuZCBoZW5jZSBpZ25vcmVzIGl0LiAgIFRoaXMgYWxsb3dzIHRoZSBjbGllbnQgdG8g c2VuZCBhIHNpbmdsZSBwYWNrZXQgdGhhdCB3aWxsIGFsd2F5cyBlbGljaXQgYSByZXNwb25zZSwg ZWl0aGVyIGFuIGFuc3dlciB0byB0aGUgcXVlc3Rpb24gYXNrZWQgaW4gdGhlIEluZm9ybWF0aW9u IHJlcXVlc3QsIG9yIGVsc2UgYSBjb25maXJtYXRpb24gdGhhdCBpdCdzIG9rYXkgdG8gY29udGlu dWUgdXNpbmcgdGhlIGFkZHJlc3MuDQogICAgDQogICAgVGhlIGhhcmQgcXVlc3Rpb24gaXMsIHdo YXQgZG8geW91IGRvIGlmIHlvdSBnZXQgYW4gYW5zd2VyIHRvIHRoZSBpbmZvcm1hdGlvbiByZXF1 ZXN0LCByYXRoZXIgdGhhbiB0byB0aGUgQ29uZmlybT8gICBCdXQgSSB0aGluayB0aGF0J3Mgc3Ry YWlnaHRmb3J3YXJkOiB5b3Ugd2FpdCBhIChzaG9ydCkgd2hpbGUgdG8gc2VlIGlmIHlvdSBnZXQg YW4gYW5zd2VyIHRvIHRoZSBjb25maXJtOyBpZiB5b3UgZG8sIHlvdSB0YWtlIHRoYXQ7IG90aGVy d2lzZSB5b3UgdGFrZSB0aGUgYW5zd2VyIGZyb20gdGhlIEluZm9ybWF0aW9uLVJlcXVlc3QuDQog ICAgDQogICAgDQoNCg== From nobody Tue Mar 28 11:48:48 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08098129445 for ; Tue, 28 Mar 2017 11:48:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 y1qx2b-dUVkI for ; Tue, 28 Mar 2017 11:48:43 -0700 (PDT) Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BAC1129A02 for ; Tue, 28 Mar 2017 11:48:41 -0700 (PDT) Received: by mail-pg0-x233.google.com with SMTP id 81so66235309pgh.2 for ; Tue, 28 Mar 2017 11:48:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=S7p1KNsSLDS6SewJ5qkAJbgme0R5dojc6QRZtYDH9b4=; b=pvkIxuaXWjQUxB8JwWrf91KjMYIPhYo/UZyF+2aEPhnVGWKXfc2E4voclwfT/iJZMg AK548vgpr1vRbQQvXuuSab6WlIQTogrWSOYPLoL4Mi5PAMqFuk5lacv8GOM5UFysC/O0 oUWUEBCYW/PO7XHVsB+4EJJSEtfF5zTgE8xV8mPg5qLRBtXC6cJpeDLdEiCrSoTMOD3I iFxF3WsAO9LfIJ2BbO2+NReONvsFnPwZ5lrxFiAxe4Z+M32+N2C+4ebAmOJYzFjsMc4L /rCkKqvFcO0/7imQIhZu2cQ2LCe6QZKML6/TWr38SSsIzfYEfgM4w0xcJTQKrQ6pq2+E iH3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=S7p1KNsSLDS6SewJ5qkAJbgme0R5dojc6QRZtYDH9b4=; b=BUcbSV4cBxM9wPzZ3+k+eEDsSWX/ZWhlZaYOlSCfJ7tNiUY2sKzKGtZBMpAldI3Rzm 6Hae291CtKqMkBRlfKuHLgz/82a9kEvys1E8hh3bUrW41eca2cR4lJve6TXoK2/i78+O WGCPdlbA8MS9hPjhxmiNrypG1iq7ZKn54E82BYqx26C/yMcZ8GiU2jLawCLQpxOACFgR XlstfduJte4YBgs/DaixNV5YOHlgbpYWVFbfgrdLB+raWrwCm91JSxBi7U9acXgpWCbs /pMAkODOwZVv8qSZ5ItugnCF6BsuZEulzzeSy65dB7Z5ZGIMsqmT/Oac3Z3wMpGbK9eu DoyA== X-Gm-Message-State: AFeK/H2cSkaedU6cqEWDgrCzY5iBZ9qDEiUCSNNmLV5QUZa7uVRtCpwPhI/k0AtF5BkjXIBgdnHo7UXrqIlZ3g== X-Received: by 10.84.229.13 with SMTP id b13mr25612243plk.72.1490726920861; Tue, 28 Mar 2017 11:48:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.179.203 with HTTP; Tue, 28 Mar 2017 11:48:40 -0700 (PDT) Received: by 10.100.179.203 with HTTP; Tue, 28 Mar 2017 11:48:40 -0700 (PDT) In-Reply-To: <80C62C74-BB9D-4F43-9C2F-A5EC02A63918@cisco.com> References: <3566F64B-D709-4DF3-9A5F-7648DA8FC45E@cisco.com> <4512A1F7-A480-4250-BE57-FCE822EAC890@fugue.com> <80C62C74-BB9D-4F43-9C2F-A5EC02A63918@cisco.com> From: Ted Lemon Date: Tue, 28 Mar 2017 14:48:40 -0400 Message-ID: To: "Bernie Volz (volz)" Cc: dhcwg , =?UTF-8?B?56We5piO6YGU5ZOJ?= Content-Type: multipart/alternative; boundary=94eb2c1a3e26934ff0054bcee810 Archived-At: Subject: Re: [dhcwg] whether/how to support Confirm with sedhcpv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 18:48:47 -0000 --94eb2c1a3e26934ff0054bcee810 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think these are easy problems to solve and do not add significant complexity. Encryption of the confirm I think addresses the privacy problem. On Mar 28, 2017 10:44 AM, "Bernie Volz (volz)" wrote: > Interesting idea =E2=80=A6 > > But, wouldn=E2=80=99t just sending the initial Information-Request per se= DHCPv6 > which =E2=80=9Csolicits=E2=80=9D server=E2=80=99s certificates with the E= ncrypted-Message Option > which contained the Confirm (and an Encryption Key Tag Option) be best? N= ot > exactly sure what the reference to =E2=80=9Cwrap relay messages=E2=80=9D. > > We might also consider whether this could be useful for the Rebind (prefi= x > delegation version of Confirm). > > And, then there=E2=80=99s the question of what the server=E2=80=99s respo= nse is =E2=80=A6 for the > server that can decrypt, it would send a Reply for the Confirm(/Rebind) a= nd > not answer the Information-Request? > > BTW: RFC 7844 (DHCP Anonymity Profiles) section 4.2 says not to send > Confirms. Perhaps for seDHCPv6, starting with the seDHCPv6 > Information-Request is thus OK and if client determines same server exist= s > (based on certificate) it could then issue Confirm (or just Renew/Rebind)= . > RFC7844 4.2 also suggests that if other information about the link is > available (such as SSID), the Confirm might be sent directly. > > The main question is how much special mechanism to add? Be nice to not > make it too complex. > > - Bernie > > On 3/28/17, 11:28 AM, "Ted Lemon" wrote: > > Probably the most expedient way to handle this would be to create a > confirm, sign and encrypt it, and then wrap it the same way we wrap relay > messages, including it in an information-request as in the regular > IR/Solicit/Confirm process for secure DHCP. > > The server on the local wire either supports the wrapping and can > decrypt, supports it but cannot decrypt, or doesn't support it and hence > ignores it. This allows the client to send a single packet that will > always elicit a response, either an answer to the question asked in the > Information request, or else a confirmation that it's okay to continue > using the address. > > The hard question is, what do you do if you get an answer to the > information request, rather than to the Confirm? But I think that's > straightforward: you wait a (short) while to see if you get an answer to > the confirm; if you do, you take that; otherwise you take the answer from > the Information-Request. > > > > --94eb2c1a3e26934ff0054bcee810 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think these are easy problems to solve and do not add s= ignificant complexity. =C2=A0 Encryption of the confirm I think addresses t= he privacy problem.=C2=A0

On Mar 28, 2017 10:44 AM, "Bernie Volz (volz)" <= volz@cisco.com> wrote:
Interesting idea =E2=80=A6

But, wouldn=E2=80=99t just sending the initial Information-Request per seDH= CPv6 which =E2=80=9Csolicits=E2=80=9D server=E2=80=99s certificates with th= e Encrypted-Message Option which contained the Confirm (and an Encryption K= ey Tag Option) be best? Not exactly sure what the reference to =E2=80=9Cwra= p relay messages=E2=80=9D.

We might also consider whether this could be useful for the Rebind (prefix = delegation version of Confirm).

And, then there=E2=80=99s the question of what the server=E2=80=99s respons= e is =E2=80=A6 for the server that can decrypt, it would send a Reply for t= he Confirm(/Rebind) and not answer the Information-Request?

BTW: RFC 7844 (DHCP Anonymity Profiles) section 4.2 says not to send Confir= ms. Perhaps for seDHCPv6, starting with the seDHCPv6 Information-Request is= thus OK and if client determines same server exists (based on certificate)= it could then issue Confirm (or just Renew/Rebind). RFC7844 4.2 also sugge= sts that if other information about the link is available (such as SSID), t= he Confirm might be sent directly.

The main question is how much special mechanism to add? Be nice to not make= it too complex.

- Bernie

On 3/28/17, 11:28 AM, "Ted Lemon" <mellon@fugue.com> wrote:

=C2=A0 =C2=A0 Probably the most expedient way to handle this would be to cr= eate a confirm, sign and encrypt it, and then wrap it the same way we wrap = relay messages, including it in an information-request as in the regular IR= /Solicit/Confirm process for secure DHCP.

=C2=A0 =C2=A0 The server on the local wire either supports the wrapping and= can decrypt, supports it but cannot decrypt, or doesn't support it and= hence ignores it.=C2=A0 =C2=A0This allows the client to send a single pack= et that will always elicit a response, either an answer to the question ask= ed in the Information request, or else a confirmation that it's okay to= continue using the address.

=C2=A0 =C2=A0 The hard question is, what do you do if you get an answer to = the information request, rather than to the Confirm?=C2=A0 =C2=A0But I thin= k that's straightforward: you wait a (short) while to see if you get an= answer to the confirm; if you do, you take that; otherwise you take the an= swer from the Information-Request.



--94eb2c1a3e26934ff0054bcee810-- From nobody Wed Mar 29 08:19:16 2017 Return-Path: X-Original-To: dhcwg@ietf.org Delivered-To: dhcwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BBEC5126C3D; Wed, 29 Mar 2017 08:19:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dhcwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.48.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149080074870.26806.14272866206701818101@ietfa.amsl.com> Date: Wed, 29 Mar 2017 08:19:08 -0700 Archived-At: Subject: [dhcwg] I-D Action: draft-ietf-dhc-relay-server-security-04.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 15:19:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration of the IETF. Title : Security of Messages Exchanged Between Servers and Relay Agents Authors : Bernie Volz Yogendra Pal Filename : draft-ietf-dhc-relay-server-security-04.txt Pages : 8 Date : 2017-03-29 Abstract: The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) has no guidance for how to secure messages exchanged between servers and relay agents. The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) states that IPsec should be used to secure messages exchanged between servers and relay agents, but does not require encryption. And, with recent concerns about pervasive monitoring and other attacks, it is appropriate to require securing relay to relay and relay to server communication for DHCPv6 and relay to server communication for DHCPv4. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-relay-server-security/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dhc-relay-server-security-04 https://datatracker.ietf.org/doc/html/draft-ietf-dhc-relay-server-security-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-relay-server-security-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Mar 29 10:25:12 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2119129458 for ; Wed, 29 Mar 2017 10:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 DOflWqZDjhU7 for ; Wed, 29 Mar 2017 10:25:09 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 010D712944F for ; Wed, 29 Mar 2017 10:25:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6910; q=dns/txt; s=iport; t=1490808308; x=1492017908; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=kD4oRGUw+XgyHOZctU9IIuV203xTs6ZthLzka+P6igE=; b=GD835dcbrIrjrPonIN9CmB1unrIZETp62ErqxQ8UGTMxdzllRsvp64pU CifyrkS/28mK+oVowk9LKsbfAhppjYzxjiYNwk5GYOtO6MpRTymhbss18 Mm5fsrrsGmpt1o+a0jfYDiCKv//ktyQfb0Z0/tIvExL47W3uIPLYhdoue 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AXAQAS7dtY/5tdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1VhgQuFaIgLkVGQHYUxgg4shByBWgKDQz8YAQIBAQEBAQEBax0?= =?us-ascii?q?LhRUBAwN3EgIBGAEDAQIoBzIUBwIIAgQTigoOsBKKUgEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAR2IU4JqgxeBJzYWgn6CMQWPYYx/AYZ8i1OBfFSEVooNk2kBDxA4gQR?= =?us-ascii?q?ZFRg6AYQNgjl1AYk1AQEB?= X-IronPort-AV: E=Sophos;i="5.36,242,1486425600"; d="scan'208,217";a="400868918" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Mar 2017 17:25:07 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v2THP72R013264 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 29 Mar 2017 17:25:07 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 29 Mar 2017 12:25:07 -0500 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1210.000; Wed, 29 Mar 2017 12:25:06 -0500 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: New Version Notification for draft-ietf-dhc-relay-server-security-04.txt Thread-Index: AQHSqJ/RFGeys8i9JkG7rqmVyJYmPKGsEZLe Date: Wed, 29 Mar 2017 17:25:06 +0000 Message-ID: <7F37BF6A-0AA9-4E83-B66A-63EB1603D606@cisco.com> References: <149080074897.26806.14718163560330127333.idtracker@ietfa.amsl.com> In-Reply-To: <149080074897.26806.14718163560330127333.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_7F37BF6A0AA94E83B66A63EB1603D606ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [dhcwg] Fwd: New Version Notification for draft-ietf-dhc-relay-server-security-04.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 17:25:11 -0000 --_000_7F37BF6A0AA94E83B66A63EB1603D606ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This addresses review comnents from Francis Dupont's GENART review. https://datatracker.ietf.org/doc/review-ietf-dhc-relay-server-security-03-g= enart-lc-dupont-2017-03-10/ - Bernie (from iPhone) Begin forwarded message: From: > Date: March 29, 2017 at 10:19:08 AM CDT To: Yogendra Pal >, Bernie Volz <= volz@cisco.com> Subject: New Version Notification for draft-ietf-dhc-relay-server-security-= 04.txt A new version of I-D, draft-ietf-dhc-relay-server-security-04.txt has been successfully submitted by Bernie Volz and posted to the IETF repository. Name: draft-ietf-dhc-relay-server-security Revision: 04 Title: Security of Messages Exchanged Between Servers and Relay Agen= ts Document date: 2017-03-29 Group: dhc Pages: 8 URL: https://www.ietf.org/internet-drafts/draft-ietf-dhc-relay-s= erver-security-04.txt Status: https://datatracker.ietf.org/doc/draft-ietf-dhc-relay-serve= r-security/ Htmlized: https://tools.ietf.org/html/draft-ietf-dhc-relay-server-sec= urity-04 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-dhc-relay-= server-security-04 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-relay-se= rver-security-04 Abstract: The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) has no guidance for how to secure messages exchanged between servers and relay agents. The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) states that IPsec should be used to secure messages exchanged between servers and relay agents, but does not require encryption. And, with recent concerns about pervasive monitoring and other attacks, it is appropriate to require securing relay to relay and relay to server communication for DHCPv6 and relay to server communication for DHCPv4. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --_000_7F37BF6A0AA94E83B66A63EB1603D606ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
This addresses review comnents from Francis Dupont's GENART review.


Begin forwarded message:

From: <internet-= drafts@ietf.org>
Date: March 29, 2017 at 10:19:08 AM CDT
To: Yogendra Pal <yogpal@cisc= o.com>, Bernie Volz <volz@cisco= .com>
Subject: New Version Notification for draft-ietf-dhc-relay-server= -security-04.txt


A new version of I-D, draft-ietf-dhc-relay-server-security-04.txt
has been successfully submitted by Bernie Volz and posted to the
IETF repository.

Name:        draft-ietf-dhc-relay-server-security=
Revision:    04
Title:        Security of Messages Exchanged Betw= een Servers and Relay Agents
Document date:    2017-03-29
Group:        dhc
Pages:        8
URL:           &nbs= p;https://www.ietf.org/internet-drafts/draft-ietf-dhc-rel= ay-server-security-04.txt
Status:         https= ://datatracker.ietf.org/doc/draft-ietf-dhc-relay-server-security/
Htmlized:       https://tools.ietf= .org/html/draft-ietf-dhc-relay-server-security-04
Htmlized:       https://= datatracker.ietf.org/doc/html/draft-ietf-dhc-relay-server-security-04
Diff:           https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-relay-server-s= ecurity-04

Abstract:
  The Dynamic Host Configuration Protocol for IPv4 (DHCPv4)= has no
  guidance for how to secure messages exchanged between ser= vers and
  relay agents.  The Dynamic Host Configuration Protoc= ol for IPv6
  (DHCPv6) states that IPsec should be used to secure messa= ges
  exchanged between servers and relay agents, but does not = require
  encryption.  And, with recent concerns about pervasi= ve monitoring and
  other attacks, it is appropriate to require securing rela= y to relay
  and relay to server communication for DHCPv6 and relay to= server
  communication for DHCPv4.




Please note that it may take a couple of minutes from the time of sub= mission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

--_000_7F37BF6A0AA94E83B66A63EB1603D606ciscocom_-- From nobody Thu Mar 30 01:49:21 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 181EC12922E; Thu, 30 Mar 2017 01:49:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 9fkrzDeFvEGE; Thu, 30 Mar 2017 01:49:15 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65B62128DE5; Thu, 30 Mar 2017 01:49:15 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id p22so33863391qka.3; Thu, 30 Mar 2017 01:49:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+JALwB30HjA1RCPrbLnYI/4cjZ99yATFXTPt5kpiQZA=; b=lqnK/lfOcMdEd9riU0/dSLGtunPCcldzGfVEYR2n57dNm6+zzDx8dt/c3UgGVbUuXi zDlcXyIbdX32Hmb+9G2Y0sWSPs73MW2xeCUuXtLykX0sq+xv9Xj5oqGdELNwcBBFTHTq MmgrPebJkaVBP2ZhhVIixLHXj8zOiVD8815/uP7EZVEYWy193QSDdWc7BreR6WE6nzmh xKJBRoobvdzICgcHoy5WJK8eA545RRSaoEKSCvuniaFNsX3Q7MZ+NIkRlpc8PNWDIxOX 5JhMoVlNoZfQW54/pGStu3vZ541+qFcQZlKYAr0O4MqY47UDOkj24yxe5MIC/IeFI8Po wnQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+JALwB30HjA1RCPrbLnYI/4cjZ99yATFXTPt5kpiQZA=; b=dC72SzCxjhNGOI5Q+SJmP5RYJewa4Ld5OkKvKcb0BXy276Mp0V/L2WmPEHbCCGk4wU nfTJeNs+DosnPfRYd3YHj55yk534m71PqMYqZNvZe9E7igLYIGMFUNbOGYY73I3+fxF7 uDtQ//JpETAEI23e6PLGLCHbNp4SnVS2ux/oQWrQXMg3TbZmwB7mL8PeThcz9AFnrPRZ qCvmKx2SUqWjMPXKaMLhmTOqhqyrRN+yYA1pI8NdxOme1u02qLqEXYJmKO5PcEQVzksl ob+Q3IewY0htzcKmZxr3vVGX2R+WVpQnPtIfbbPMMhSUecd3u71BjbXVsjBs4dEZ0+Bo D5nw== X-Gm-Message-State: AFeK/H1LO56prSXQnoVZjke1pLDrtiXzzpO88llhIxNNUL1QrXQala/5zvIAry8VGfKzdoaOqRsZ+5ciqtgbxQ== X-Received: by 10.55.167.72 with SMTP id q69mr5157836qke.320.1490863754309; Thu, 30 Mar 2017 01:49:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.46.132 with HTTP; Thu, 30 Mar 2017 01:49:13 -0700 (PDT) In-Reply-To: <369C97B6-B6E7-46CE-B42E-18559BFB1E78@cisco.com> References: <7db55e6f55e34408a1816887c22e28d3@XCH-ALN-003.cisco.com> <369C97B6-B6E7-46CE-B42E-18559BFB1E78@cisco.com> From: Lishan Li Date: Thu, 30 Mar 2017 16:49:13 +0800 Message-ID: To: "Bernie Volz (volz)" Cc: Tomek Mrugalski , dhcwg , draft-ietf-dhc-sedhcpv6 authors Content-Type: multipart/alternative; boundary=001a114feb687c12b4054beec49c Archived-At: Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-sedhcpv6-21 - Respond by March 29th X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 08:49:20 -0000 --001a114feb687c12b4054beec49c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 2017-03-27 22:07 GMT+08:00 Bernie Volz (volz) : > Hi: > > > > The sentence: "The encryption text SHOULD be formatted as explain in > [RFC5652]." Isn't clear. RFC5652 doesn't use "text" except to mean actual > wording in the RFC. Could "encryption text" be clarified? Is this the > client's message? Or what exactly is this and which part of RFC 5652 has > this "format"? I am not following what this sentence means and what I > should do (if I were implementing this). > > Note: This same text is also in Section 7 (last paragraph) and needs > similar attention. > > [LS]: Sorry for the unclear expression. How about the following text? > > The DHCPv6 message sent from the client is encrypted and then encapsulate= d > into the encrypted DHCPv6 message field according to the Encrypted-Data > content syntax defined in the RFC5652. > > > > BV> I assume this reference is to section 8 of RFC 5652. But now the ques= tion is whether anything further needs to be defined =E2=80=93 for example,= what (optional) attributes should be included? Perhaps as I=E2=80=99m not = a security expert or have carefully reviewed RFC5652 and am taking a few th= ings =E2=80=9Cout of content=E2=80=9D when looking at it, but I think some = clarity here may help in make sure this is easy to implement (especially fo= r some of us that may not be experts in cryptography). This is a bit more c= omplex than just taking the bytes of the client=E2=80=99s unencrypted messa= ge and the private key to encrypt (and placing that into the Encrypted-mess= age Option), and taking the encrypted client=E2=80=99s message bytes (from = a received Encrypted-message Option) and decrypting with the public key? Yo= u may want to think about whether perhaps specifying the details appropriat= e to DHCPv6 usage is appropriate =E2=80=93 perhaps even in an appendix? RFC= 5652 talks about: > > > > And there=E2=80=99s a lot about ASN.1 and OIDs in RFC5652, so are you pul= ling in > all of this? > > > > The following object identifier identifies the encrypted-data content > > type: > > > > id-encryptedData OBJECT IDENTIFIER ::=3D { iso(1) member-body(2) > > us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6 } > > > > The encrypted-data content type shall have ASN.1 type EncryptedData: > > > > EncryptedData ::=3D SEQUENCE { > > version CMSVersion, > > encryptedContentInfo EncryptedContentInfo, > > unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL } > > > > The fields of type EncryptedData have the following meanings: > > > > version is the syntax version number. If unprotectedAttrs is > > present, then the version MUST be 2. If unprotectedAttrs is > > absent, then version MUST be 0. > > > > encryptedContentInfo is the encrypted content information, as > > defined in Section 6.1 > . > > > > unprotectedAttrs is a collection of attributes that are not > > encrypted. The field is optional. Useful attribute types are > > defined in Section 11 > . > > > > Probably section 6.1 is most applicable and there we have (eventually): > > > > EncryptedContent ::=3D OCTET STRING > > > > Which may be all we really need? > > > > And, if so, what is the value in referencing this RFC? > > > > Again, I=E2=80=99m just trying to understand this more completely =E2=80= =93 what exactly > is inside the Encrypted-message option? > > > > > [LS]: Yes, the reference is section 8 of RFC5652. In the before version, Stephen suggested us to illustrate the format of the encrypted message data. He suggested to add the reference of RFC5652 for it. But in fact, I don't know much about details of the draft. > > > [LS]: Yes, the server just need to keep one set for all clients. > > How about the following modified text? > > For client, it MUST remember about its own increasing number, which is > stored in the NUM.STO and sent to the server. And the client also MUST > remember about a server's increasing number, which is received from the > server and stored in the NUM.REC. And the client keeps a record of the > increasing number during the DHCPv6 configuration process with the DHCPv6 > server. And the client can forget the increasing number information afte= r > the transaction is finished. The client's initial locally stored > increasing number is set to zero. > > > > For server, it MUST remember about its own increasing number, which is > stored in the NUM.STO and sent to the client. And the server also MUST > remember about a client's increasing number, which is received from the > client and stored in the Num.REC. The server just need to keep one > increasing number set for all clients. > > > > BV> Here again, please be careful: > > 1. If client always starts at 0, how does that help in preventing > replay? And, this isn=E2=80=99t consistent with the server=E2=80=99s beha= vior above? > [LS]: For the first time that the client receives the increasing number, the client cannot compare it with the local number, and just to store it. > 2. If client doesn=E2=80=99t persist this, what happens if server h= as a > lease for the client (and has retained the replay numbers) but the client > released (or otherwise deleted the lease). Now when the client Solicits > (encrypted), the server would report that this is a potential replay > attach? I don=E2=80=99t think dropping this information =E2=80=9Cafter th= e transaction is > finished=E2=80=9D is possible. > [LS]: Yes, it is better for the client to retain the number it last used with a server. For the devices without the persistent storage, the initial value of the increasing number is zero. After checking the increasing number in the Reply message, the NUM.STO is set to the NUM.REC. When sending the Solicit message, the increasing number is larger than the NUM.STO. So, the server will not report that this is a potential replay attack. > 3. For =E2=80=9CThe server just need to keep one increasing number = set for > all clients=E2=80=9D =E2=80=93 shouldn=E2=80=99t that be after the first = sentence as this applies > to NUM.STO; not NUM.REC? > > Thus, I think the client must retain the number it last used with a > server. This seems to be an issue for devices without persistent storage, > so may require some further thought =E2=80=93 or those devices cannot use > increasing number? > [LS]: Agree, the client MUST retain the increasing number it last used with a server. > > > And, I think both having to retain this forever would be a bad idea. I > think one could provide for both clients and servers to =E2=80=9Cforget= =E2=80=9D any stored > information after a period of time (perhaps this can be a fixed number, 3= 0 > days, or should be some multiple of the lease lifetime)? > [LS]: So we can recommend a lifetime of the increasing number for the client and server, such as 30 days. Could you please check my understanding correct? > > > > > Likewise, since the Encryption-Key-Tag Option isn't protected, an > attacker that can intercept the message can forge the value without > detection. > > Isn't this generally useless? As the message is encrypted, the validation > will fail? > > [LS]: If the encryption-key-tag is forged, then the server may cannot > decrypt it and drop the message. > > > > BV> Right, but isn=E2=80=99t that exactly what we would want? So, how is = this bad? > > > > > BV> Re Security Considerations - A new comment from a conversation with > Tomek (Tomek will hopefully comment more). I mentioned that I was concern= ed > with the possibility of clients and servers getting =E2=80=9Cjunk=E2=80= =9D is a security > concern as someone could generate bad packets with encrypted data and sen= d > them to clients and servers in the hope to crash the either when they try > to decrypt and then process junk. Tomek suggested we might want to think > about whether to add some magic value to the first few bytes of a message > before encrypting it and then the decrypter can check those first few byt= es > to see if they are value and discard the message if not. Perhaps the > encoding from RFC5652 would accomplish this if we are using more than jus= t > the encryptedContent? Anyway, something to think about. > [LS]: Agree. Perhaps the encoding from RFC5652 solves this problem. I think that it may be a general problem for all encryption protocol. > > > > > Again, thanks for your continued efforts on this document! > > > [LS]: As the author of the draft, I have the responsibility to work on it. Thanks a lot for your continued guidance on this. Best Regards, Lishan > *From: *Lishan Li > *Date: *Monday, March 27, 2017 at 12:33 AM > *To: *Bernie Volz > *Cc: *Tomek Mrugalski , "dhcwg@ietf.org" < > dhcwg@ietf.org>, draft-ietf-dhc-sedhcpv6 authors < > draft-ietf-dhc-sedhcpv6@ietf.org> > *Subject: *Re: [dhcwg] WGLC on draft-ietf-dhc-sedhcpv6-21 - Respond by > March 29th > > > > Hi, Bernie, > > > > Thanks a lot for your valuable comments. For the details, please see > inline. > > > > Best Regards, > > Lishan > > > > 2017-03-26 10:05 GMT+08:00 Bernie Volz (volz) : > > Hi: > > I have reviewed the draft and support it moving forward. However, I do > have some issues I think need to be addressed but they are mostly fairly > small. > > I do want to thank the authors for addressing my earlier issues. I think > the document is in MUCH better shape now!! > > So here goes ... > > Section 6: > The sentence: "The encryption text SHOULD be formatted as explain in > [RFC5652]." Isn't clear. RFC5652 doesn't use "text" except to mean actual > wording in the RFC. Could "encryption text" be clarified? Is this the > client's message? Or what exactly is this and which part of RFC 5652 has > this "format"? I am not following what this sentence means and what I > should do (if I were implementing this). > > Note: This same text is also in Section 7 (last paragraph) and needs > similar attention. > > [LS]: Sorry for the unclear expression. How about the following text? > > The DHCPv6 message sent from the client is encrypted and then encapsulate= d > into the encrypted DHCPv6 message field according to the Encrypted-Data > content syntax defined in the RFC5652. > > > > > Section 7: > > option. Then, the server checks the Server Identifier option. The > DHCPv6 server drops the message that is not for it, thus not paying > cost to decrypt messages. If it is the target server, according to > > I think here you also want the server to proceed if there is NO Server > Identifier option? It should only ignore it if there is a Server Identifi= er > option and it does not match this server's identifier? > > [LS]: Yes. Will modify it. > > > Section 8 > > those present in the innermost encapsulated messages from the client > or server. > > I think messages should just be message as there is only one message? > > [LS]: Agree. Will modify it. > > > Section 9.1: > > Might be better to split out requirements for a client and server into > separate paragraphs (1st paragraph)? Might also be best to be clear that > you address: > 1. What a client must remember about its own increasing number (i.e., wha= t > it sends to the server). > 2. What a client must remember about the server's increasing number (i.e.= , > what it receives from server). > 3. What a server must remember about a client's increasing number (i.e., > what it receives from client). > 4. What a server must remember about its own increasing number (i.e., wha= t > it sends to clients). I assume a server does NOT need to keep a unique > increasing number set for each client it communicates with - a server can > use one set for all clients? > Please also be clear about how each of these 4 (2 numbers on client, 2 on > server) are handled. The text presently is not very clear -- for example = a > client can't forget what it sent if the server remembers it. > > [LS]: Yes, the server just need to keep one set for all clients. > > How about the following modified text? > > For client, it MUST remember about its own increasing number, which is > stored in the NUM.STO and sent to the server. And the client also MUST > remember about a server's increasing number, which is received from the > server and stored in the NUM.REC. And the client keeps a record of the > increasing number during the DHCPv6 configuration process with the DHCPv6 > server. And the client can forget the increasing number information afte= r > the transaction is finished. The client's initial locally stored > increasing number is set to zero. > > > > For server, it MUST remember about its own increasing number, which is > stored in the NUM.STO and sent to the client. And the server also MUST > remember about a client's increasing number, which is received from the > client and stored in the Num.REC. The server just need to keep one > increasing number set for all clients. > > > Later, be clear that this is modulo 2^64 math: > > The Increasing-number option in the received message passes the > increasing number check if NUM.REC is more than NUM.STO. And then, > the value of NUM.STO is changed into the value of NUM.REC. > > The increasing number check fails if NUM.REC is equal with or less > than NUM.STO. > > "More" here is in the modulo arithmetic "more" -- perhaps use "more > (modulo 2^64)" and "or less (modulo 2^64)"? > > [LS]: Agree, will modify it. > > > Section 9.2: > > I wonder if you should revise the code to make it more appropriate for > this document? RDATA/RDLENGTH aren't really appropriate? > > [LS]: Got it. Will modify it. > > > Section 10 > > There are now only three (not six) status codes. > > [LS]: Will correct it. > > > Section 10.2 > > msg-type Identifier of the message type. It can be either > Encrypted-Query (TBA7) or DHCPv6-Response (TBA8). > > Change DHCPv6-Response to Encrypted-Response. > > [LS]: Will correct it. > > > > Section 11 > > There are some mandatory algorithm for encryption algorithm in this > > Change (first) algorithm to algorithms? Or, change "are some" to "is a" > > [LS]: Will change it. > > > > Likewise, since the Encryption-Key-Tag Option isn't protected, an > attacker that can intercept the message can forge the value without > detection. > > Isn't this generally useless? As the message is encrypted, the validation > will fail? > > [LS]: If the encryption-key-tag is forged, then the server may cannot > decrypt it and drop the message. > > > > Some even more MINOR comments (these would perhaps improve readability bu= t > would likely be addressed by the RFC editor): > > [LS]: Sorry for the poor expression. And thanks a lot your throughout > check. Will correct it in the next version. > > > Section 6: > > Perhaps replace "contained" and "contain" with "included" and "include" i= n > the sentences later in that same paragraph (with the "The encryption > text..."). > > > For the received Encrypted-Response message, the client MUST drop the > Encrypted-Response message if other DHCPv6 option except Encrypted- > message option is contained. > > How about: > > For the received Encrypted-Response message, the client MUST drop the > Encrypted-Response message if it contains any option other than a sing= le > Encrypted-message option. > > Note: There are some other odd uses of contain (when at least I think the > text should use include). But it may not be worth trying to change these > (the usage is tricky - you can google for "english contain vs include" if > you like). We will leave it to the RFC editor to perhaps clean these up i= f > appropriate. > > > The client MAY use the AuthenticationFail as a hint and switch > to other DHCPv6 server if it has another one. > > Change to "to another DHCP server if it has one"? > > Section 7: > > Upon the receipt of Encrypted-Query message, the server MUST drop the > message if the other DHCPv6 option is contained except Server > > Here "the other" should change to "another". > > Note: There are several other places where contained/contain would (at > least in my mind) be more "standard" if the text used included/include. > Same goes for use of "other" (-> another). > > Last paragraph of section 7, "then the server set the". Set should be set= s. > > Section 10.1.1 > > For EA-len, might be good to add "(must be a multiple of 2)" > For SHA-len, might be good to add "(must be a multiple of 4)" > > Also, I think you should change all "2-octets value" to "2-octet value". > > Section 11 > > For this security item, It is RECOMMENDED that client certificates > could be tied to specific server certificates by configuration. > > Lower case "It"? > > > General > > There are uses of "cert" and "certs" and "certificate(s)". Are these one > in the same? Shouldn't we just use "certificate" throughout? Or perhaps y= ou > should add "cert(s)" to terminology section? > > > - Bernie > > -----Original Message----- > From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Tomek Mrugalski > Sent: Wednesday, March 08, 2017 8:37 AM > To: dhcwg > Cc: draft-ietf-dhc-sedhcpv6 authors > Subject: [dhcwg] WGLC on draft-ietf-dhc-sedhcpv6-21 - Respond by March 29= th > > Hi, > draft-ietf-dhc-sedhcpv6-21 describes a mechanism for using public key > cryptography to provide end-to-end security between DHCPv6 clients and > servers. The mechanism provides encryption in all cases, and can be used > for authentication based on pre-sharing of authorized certificates. This > draft has started in 2013, but the whole DHCPv6 security saga is much > longer and begins in 2008. This draft was submitted to IESG in mid-2015. > The guidance received was clear that substantial changes are needed. As = a > result, "encrypt everywhere, authenticate if you can" approach was used. > > Authors believe this draft to be ready for working group last call. > > Please send your substantial comments to the mailing list and express you= r > opinion whether this draft is ready for publication. Feel free to send > nitpicks and minor corrections to the authors directly. This is a complex > draft, so the chairs believe 3 weeks WGLC is in order. Please send your > comments no later than March 29th. Bernie and I will determine consensus > and will discuss during Chicago meeting as needed. > > To initiate the discussion, I have two related questions. The chairs woul= d > love to hear your opinions on those. > > 1. The "encrypt everywhere" paradigm means that in deployments that do > snooping on relay will break down. To solve this problem, we need a > assignment notification mechanism, similar to the one described in > draft-ietf-dhc-dhcpv6-agentopt-delegate-04. That draft expired many years > ago. This matter was discussed in Seoul and the minutes describe the > conclusion as: > > The discussion gravitated towards not resurrecting until the sedhcpv6 > I-D progresses further. We will reevaluate this once sedhcpv6 is done. > > Do you want the WG to resurrect agentopt-delegate a) now, b) when > sedhcpv6 is sent to IESG or c) when sedhcpv6 is published as RFC? d) we > need a completely new draft and I'm volunteering to work on it. > > 2. One of the authors suggested that this protocol is quite complex and > having a feedback from an implementation (or ideally two interoperating) > would be very important and would likely result in some changes to the > draft. It's probably too late for Chicago, but we can organize a > sedhcpv6 hackathon in Prague. Two likely implementations would be WIDE an= d > Kea, as those two are open source and have an old version of the draft > partially implemented. Do you think such a hackathon would be useful? Are > you willing to participate? > > Title: Secure DHCPv6 > Authors: L. Li, S. Jiang, Y.Cui, T.Jinmei, T.Lemon, D.Zhang > Filename: draft-ietf-dhc-sedhcpv6-21 > Pages: 31 > Date: 2017-02-21 > Link: https://datatracker.ietf.org/doc/draft-ietf-dhc-sedhcpv6/ > > Responses by March 29th are appreciated. > > Thanks, > Bernie and Tomek > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > > > --001a114feb687c12b4054beec49c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
2017= -03-27 22:07 GMT+08:00 Bernie Volz (volz) <volz@cisco.com>:
=

Hi:

=C2=A0

The sentence: "The encryption text SHOULD be fo= rmatted as explain in [RFC5652]." Isn't clear. RFC5652 doesn't= use "text" except to mean actual wording in the RFC. Could "= ;encryption text" be clarified? Is this the client's message? Or w= hat exactly is this and which part of RFC 5652 has this "format"? I = am not following what this sentence means and what I should do (if I were i= mplementing this).

Note: This same text is also in Section 7 (last paragraph) and needs simila= r attention.

[LS]: Sorry for the unclear expression. How about th= e following text?

The DHCPv6 message sent from the client is encrypted= and then encapsulated into the encrypted DHCPv6 message field according to= the Encrypted-Data content syntax defined in the RFC5652.

=C2=A0

BV> I a=
ssume this reference is to section 8 of RFC 5652. But now the question is w=
hether anything further needs to be defined =E2=80=93 for example, what (op=
tional) attributes should be included? Perhaps as I=E2=80=99m not a securit=
y expert or have carefully reviewed RFC5652 and am taking a few things =E2=
=80=9Cout of content=E2=80=9D when looking at it, but I think some clarity =
here may help in make sure this is easy to implement (especially for some o=
f us that may not be experts in cryptography). This is a bit more complex t=
han just taking the bytes of the client=E2=80=99s unencrypted message and t=
he private key to encrypt (and placing that into the Encrypted-message Opti=
on), and taking the encrypted client=E2=80=99s message bytes (from a receiv=
ed Encrypted-message Option) and decrypting with the public key? You may wa=
nt to think about whether perhaps specifying the details appropriate to DHC=
Pv6 usage is appropriate =E2=80=93 perhaps even in an appendix? RFC5652 tal=
ks about:

=C2=A0

And there=E2=80=99s a lot about ASN.1 and OIDs in RFC5652, so are you pull= ing in all of this?

=C2=A0

=C2=A0=C2=A0 The following object identifier i= dentifies the encrypted-data content

=C2=A0=C2=A0 type:

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 id-encryptedDat= a OBJECT IDENTIFIER ::=3D { iso(1) member-body(2)

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6 }<= /p>

=C2=A0

=C2=A0=C2=A0 The encrypted-data content type s= hall have ASN.1 type EncryptedData:

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 EncryptedData := :=3D SEQUENCE {

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ver= sion CMSVersion,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 enc= ryptedContentInfo EncryptedContentInfo,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 unp= rotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL }

=C2=A0

=C2=A0=C2=A0 The fields of type EncryptedData = have the following meanings:

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 version is the = syntax version number.=C2=A0 If unprotectedAttrs is

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 present, then t= he version MUST be 2.=C2=A0 If unprotectedAttrs is

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 absent, then ve= rsion MUST be 0.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 encryptedConten= tInfo is the encrypted content information, as

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 defined in Section 6.1.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 unprotectedAttr= s is a collection of attributes that are not

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 encrypted.=C2= =A0 The field is optional.=C2=A0 Useful attribute types are

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 defined in Section 11.

=C2=A0

Probably section 6.1 is most applicable and there we have (eventually):=

=C2=A0

=C2=A0=C2=A0=C2=A0 EncryptedContent ::=3D =
OCTET STRING

=C2=A0

Which may be all we really need?

=C2=A0

And, if so, what is the value in referencing this RFC?

=C2=A0

Again, I=E2=80=99m just trying to understand this more completely =E2=80= =93 what exactly is inside the Encrypted-message option?

=C2=A0

=C2=A0

[LS]: Yes, th= e reference is section 8 of RFC5652.
In the before version, Steph= en suggested us to illustrate the format of the encrypted message data. He = suggested to add the reference of RFC5652 for it.=C2=A0
But in fa= ct, I don't know much about details of the draft.
=

=C2=A0

[LS]: Yes, the server just need to keep one set for = all clients.=C2=A0

How about the following modified text?=

For client, it MUST remember about its own increasin= g number, which is stored in the NUM.STO and sent to the server. And the cl= ient also MUST remember about a server's increasing number, which is re= ceived from the server and stored in the NUM.REC. And the client keeps a record of the increasing number during the= DHCPv6 configuration process with the DHCPv6 server.=C2=A0 And the client = can forget the increasing number information after the transaction is finis= hed.=C2=A0 The client's initial locally stored increasing number is set to zero.

=C2=A0

For server, it MUST remember about its own increasin= g number, which is stored in the NUM.STO and sent to the client. And the se= rver also MUST remember about a client's increasing number, which is re= ceived from the client and stored in the Num.REC. The server just need to keep one increasing number set for all cl= ients.

=C2=A0

BV> Here again, please be careful:

1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If client always starts at 0, how does that help in preventing replay= ? And, this isn=E2=80=99t consistent with the server=E2=80=99s behavior abo= ve?

[LS]: For the first time that t= he client receives the increasing number, the client cannot compare it with= the local number, and just to store it.

<= u>

2.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If client doesn=E2=80=99t persist this, what happens if server has a = lease for the client (and has retained the replay numbers) but the client r= eleased (or otherwise deleted the lease). Now when the client Solicits (encrypted), the server would report that thi= s is a potential replay attach? I don=E2=80=99t think dropping this informa= tion =E2=80=9Cafter the transaction is finished=E2=80=9D is possible.

[LS]: Yes, it is better for the client t= o retain the number it last used with a server. For the devices without the= persistent storage, the initial value of the increasing number is zero. Af= ter checking the increasing number in the Reply message, the NUM.STO is set= to the NUM.REC. When sending the Solicit message, the increasing number is= larger than the NUM.STO. So, the server will not report that this is a pot= ential replay attack.=C2=A0

=

3.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 For =E2=80=9CThe server just need to keep one increasing number set f= or all clients=E2=80=9D =E2=80=93 shouldn=E2=80=99t that be after the first= sentence as this applies to NUM.STO; not NUM.REC?

Thus, I think the client must retain the number it last used with a server= . This seems to be an issue for devices without persistent storage, so may = require some further thought =E2=80=93 or those devices cannot use increasing number?

<= div>[LS]: Agree, the client MUST retain the increasing number it last used = with a server.=C2=A0

=C2=A0

And, I think both having to retain this forever would be a bad idea. I thi= nk one could provide for both clients and servers to =E2=80=9Cforget=E2=80= =9D any stored information after a period of time (perhaps this can be a fixed number, 30 days, or should be some multiple of the lea= se lifetime)?

[LS]: So we can recom= mend a lifetime of the increasing number for the client and server, such as= 30 days. Could you please check my understanding correct?=C2=A0

=C2=A0

=C2=A0

=C2=A0 =C2=A0Likewise, since the Encryption-Key-Tag = Option isn't protected, an
=C2=A0 =C2=A0attacker that can intercept the message can forge the value wi= thout
=C2=A0 =C2=A0detection.

Isn't this generally useless? As the message is encrypted, the validati= on will fail?

[LS]: If the encryption-key-tag is forged, then the = server may cannot decrypt it and drop the message.

=C2=A0

BV> Right, but isn=E2=80=99t that exactly what we would want? So= , how is this bad?

=C2=A0=C2=A0

=C2=A0

BV> Re Security Considerations - A new comment from a conversation with= Tomek (Tomek will hopefully comment more). I mentioned that I was concerne= d with the possibility of clients and servers getting =E2=80=9Cjunk=E2=80=9D is a security concern as someone could gene= rate bad packets with encrypted data and send them to clients and servers i= n the hope to crash the either when they try to decrypt and then process ju= nk. Tomek suggested we might want to think about whether to add some magic value to the first few bytes of a message before= encrypting it and then the decrypter can check those first few bytes to se= e if they are value and discard the message if not. Perhaps the encoding fr= om RFC5652 would accomplish this if we are using more than just the encryptedContent? Anyway, something to = think about.

[LS]: Agree. Perhaps t= he encoding from RFC5652 solves this problem.=C2=A0
I think that = it may be a general problem for all encryption protocol.=C2=A0

=

=C2=A0

=C2=A0

Again, thanks for your continued efforts on this document!

=C2=A0

[LS]: As the author = of the draft, I have the responsibility to work on it. Thanks a lot for you= r continued guidance on this.=C2=A0

Best Regards,<= /div>
Lishan

F= rom: Lishan Li <lilishan48@gmail.com= >
Date: Monday, March 27, 2017 at 12:33 AM
To: Bernie Volz <volz@cisco.com>
Cc: Tomek Mrugalski <tomasz.mrugalski@gmail.com>, "dhcwg@ietf.org" <dhcwg@ietf.org>, draft-= ietf-dhc-sedhcpv6 authors <draft-ietf-dhc-sedhcpv6@ietf.org>
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-sedhcpv6-21 - Respond by= March 29th

=C2=A0

Hi, Bernie,

=C2=A0

Thanks a lot for your valuable comments. For the det= ails, please see inline.

=C2=A0

Best Regards,

Lishan

=C2=A0

2017-03-26 10:05 GMT+08:00 Bernie Volz (volz) <volz@cisco.com>:

Hi:

I have reviewed the draft and support it moving forward. However, I do have= some issues I think need to be addressed but they are mostly fairly small.=

I do want to thank the authors for addressing my earlier issues. I think th= e document is in MUCH better shape now!!

So here goes ...

Section 6:
The sentence: "The encryption text SHOULD be formatted as explain in [= RFC5652]." Isn't clear. RFC5652 doesn't use "text" e= xcept to mean actual wording in the RFC. Could "encryption text" = be clarified? Is this the client's message? Or what exactly is this and which part of RFC 5652 has this "format"? I am not following wha= t this sentence means and what I should do (if I were implementing this).
Note: This same text is also in Section 7 (last paragraph) and needs simila= r attention.

[LS]: Sorry for the unclear expression. How about th= e following text?

The DHCPv6 message sent from the client is encrypted= and then encapsulated into the encrypted DHCPv6 message field according to= the Encrypted-Data content syntax defined in the RFC5652.

=C2=A0


Section 7:

=C2=A0 =C2=A0option.=C2=A0 Then, the server checks the Server Identifier op= tion.=C2=A0 The
=C2=A0 =C2=A0DHCPv6 server drops the message that is not for it, thus not p= aying
=C2=A0 =C2=A0cost to decrypt messages.=C2=A0 If it is the target server, ac= cording to

I think here you also want the server to proceed if there is NO Server Iden= tifier option? It should only ignore it if there is a Server Identifier opt= ion and it does not match this server's identifier?

[LS]: Yes. Will modify it.=C2=A0


Section 8

=C2=A0 =C2=A0those present in the innermost encapsulated messages from the = client
=C2=A0 =C2=A0or server.

I think messages should just be message as there is only one message?

[LS]: Agree. Will modify it.=C2=A0


Section 9.1:

Might be better to split out requirements for a client and server into sepa= rate paragraphs (1st paragraph)? Might also be best to be clear that you ad= dress:
1. What a client must remember about its own increasing number (i.e., what = it sends to the server).
2. What a client must remember about the server's increasing number (i.= e., what it receives from server).
3. What a server must remember about a client's increasing number (i.e.= , what it receives from client).
4. What a server must remember about its own increasing number (i.e., what = it sends to clients). I assume a server does NOT need to keep a unique incr= easing number set for each client it communicates with - a server can use o= ne set for all clients?
Please also be clear about how each of these 4 (2 numbers on client, 2 on s= erver) are handled. The text presently is not very clear -- for example a c= lient can't forget what it sent if the server remembers it.

[LS]: Yes, the server just need to keep one set for = all clients.=C2=A0

How about the following modified text?=

For client, it MUST remember about its own increasin= g number, which is stored in the NUM.STO and sent to the server. And the cl= ient also MUST remember about a server's increasing number, which is re= ceived from the server and stored in the NUM.REC. And the client keeps a record of the increasing number during the= DHCPv6 configuration process with the DHCPv6 server.=C2=A0 And the client = can forget the increasing number information after the transaction is finis= hed.=C2=A0 The client's initial locally stored increasing number is set to zero.

=C2=A0

For server, it MUST remember about its own increasin= g number, which is stored in the NUM.STO and sent to the client. And the se= rver also MUST remember about a client's increasing number, which is re= ceived from the client and stored in the Num.REC. The server just need to keep one increasing number set for all cl= ients.


Later, be clear that this is modulo 2^64 math:

=C2=A0 =C2=A0The Increasing-number option in the received message passes th= e
=C2=A0 =C2=A0increasing number check if NUM.REC is more than NUM.STO.=C2=A0= And then,
=C2=A0 =C2=A0the value of NUM.STO is changed into the value of NUM.REC.

=C2=A0 =C2=A0The increasing number check fails if NUM.REC is equal with or = less
=C2=A0 =C2=A0than NUM.STO.

"More" here is in the modulo arithmetic "more" -- perha= ps use "more (modulo 2^64)" and "or less (modulo 2^64)"= ?

[LS]: Agree, will modify it.=C2=A0


Section 9.2:

I wonder if you should revise the code to make it more appropriate for this= document? RDATA/RDLENGTH aren't really appropriate?

[LS]: Got it. Will modify it.=C2=A0


Section 10

There are now only three (not six) status codes.

[LS]: Will correct it.=C2=A0


Section 10.2

=C2=A0 =C2=A0msg-type=C2=A0 =C2=A0 =C2=A0 =C2=A0 Identifier of the message = type.=C2=A0 It can be either
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Encryp= ted-Query (TBA7) or DHCPv6-Response (TBA8).

Change DHCPv6-Response to Encrypted-Response.

[LS]: Will correct it.=C2=A0



Section 11

=C2=A0 =C2=A0There are some mandatory algorithm for encryption algorithm in= this

Change (first) algorithm to algorithms? Or, change "are some" to = "is a"

[LS]: Will change it.=C2=A0



=C2=A0 =C2=A0Likewise, since the Encryption-Key-Tag Option isn't protec= ted, an
=C2=A0 =C2=A0attacker that can intercept the message can forge the value wi= thout
=C2=A0 =C2=A0detection.

Isn't this generally useless? As the message is encrypted, the validati= on will fail?

[LS]: If the encryption-key-tag is forged, then the = server may cannot decrypt it and drop the message.



Some even more MINOR comments (these would perhaps improve readability but = would likely be addressed by the RFC editor):

[LS]: Sorry for the poor expression. And thanks a lo= t your throughout check. Will correct it in the next version.=C2=A0<= u>


Section 6:

Perhaps replace "contained" and "contain" with "in= cluded" and "include" in the sentences later in that same pa= ragraph (with the "The encryption text...").


=C2=A0 =C2=A0For the received Encrypted-Response message, the client MUST d= rop the
=C2=A0 =C2=A0Encrypted-Response message if other DHCPv6 option except Encry= pted-
=C2=A0 =C2=A0message option is contained.

How about:

=C2=A0 =C2=A0For the received Encrypted-Response message, the client MUST d= rop the
=C2=A0 =C2=A0Encrypted-Response message if it contains any option other tha= n a single
=C2=A0 =C2=A0Encrypted-message option.

Note: There are some other odd uses of contain (when at least I think the t= ext should use include). But it may not be worth trying to change these (th= e usage is tricky - you can google for "english contain vs include&quo= t; if you like). We will leave it to the RFC editor to perhaps clean these up if appropriate.


=C2=A0 =C2=A0 =C2=A0 The client MAY use the AuthenticationFail as a hint an= d switch
=C2=A0 =C2=A0 =C2=A0 to other DHCPv6 server if it has another one.

Change to "to another DHCP server if it has one"?

Section 7:

=C2=A0 =C2=A0Upon the receipt of Encrypted-Query message, the server MUST d= rop the
=C2=A0 =C2=A0message if the other DHCPv6 option is contained except Server<= br>
Here "the other" should change to "another".

Note: There are several other places where contained/contain would (at leas= t in my mind) be more "standard" if the text used included/includ= e. Same goes for use of "other" (-> another).

Last paragraph of section 7, "then the server set the". Set shoul= d be sets.

Section 10.1.1

For EA-len, might be good to add "(must be a multiple of 2)"
For SHA-len, might be good to add "(must be a multiple of 4)"

Also, I think you should change all "2-octets value" to "2-o= ctet value".

Section 11

=C2=A0 =C2=A0For this security item, It is RECOMMENDED that client certific= ates
=C2=A0 =C2=A0could be tied to specific server certificates by configuration= .

Lower case "It"?


General

There are uses of "cert" and "certs" and "certific= ate(s)". Are these one in the same? Shouldn't we just use "ce= rtificate" throughout? Or perhaps you should add "cert(s)" t= o terminology section?


- Bernie

-----Original Message-----
From: dhcwg [mailto:dhcwg-bounces@ietf.org= ] On Behalf Of Tomek Mrugalski
Sent: Wednesday, March 08, 2017= 8:37 AM
To: dhcwg <dhcwg@ietf.org>
Cc: draft-ietf-dhc-sedhcpv6 aut= hors <draft-ietf-dhc-sedhcpv6@ietf.org>
Subject: [dhcwg] WGLC on draft-= ietf-dhc-sedhcpv6-21 - Respond by March 29th

Hi,
draft-ietf-dhc-sedhcpv6-21 describes a mechanism for using public key crypt= ography to provide end-to-end security between DHCPv6 clients and servers. = The mechanism provides encryption in all cases, and can be used for authent= ication based on pre-sharing of authorized certificates. This draft has started in 2013, but the whole DHC= Pv6 security saga is much longer and begins in 2008. This draft was submitt= ed to IESG in mid-2015.
The guidance received was clear that=C2=A0 substantial changes are needed. = As a result, "encrypt everywhere, authenticate if you can" approa= ch was used.

Authors believe this draft to be ready for working group last call.

Please send your substantial comments to the mailing list and express your = opinion whether this draft is ready for publication. Feel free to send nitp= icks and minor corrections to the authors directly. This is a complex draft= , so the chairs believe 3 weeks WGLC is in order. Please send your comments no later than March 29th. Bern= ie and I will determine consensus and will discuss during Chicago meeting a= s needed.

To initiate the discussion, I have two related questions. The chairs would = love to hear your opinions on those.

1. The "encrypt everywhere" paradigm means that in deployments th= at do snooping on relay will break down. To solve this problem, we need a a= ssignment notification mechanism, similar to the one described in draft-iet= f-dhc-dhcpv6-agentopt-delegate-04. That draft expired many years ago. This matter was discussed in Seoul and the minutes= describe the conclusion as:

=C2=A0 The discussion gravitated towards not resurrecting until the sedhcpv= 6
=C2=A0 I-D progresses further. We will reevaluate this once sedhcpv6 is don= e.

Do you want the WG to resurrect agentopt-delegate a) now, b) when
sedhcpv6 is sent to IESG or c) when sedhcpv6 is published as RFC? d) we nee= d a completely new draft and I'm volunteering to work on it.

2. One of the authors suggested that this protocol is quite complex and hav= ing a feedback from an implementation (or ideally two interoperating) would= be very important and would likely result in some changes to the draft. It= 's probably too late for Chicago, but we can organize a
sedhcpv6 hackathon in Prague. Two likely implementations would be WIDE and = Kea, as those two are open source and have an old version of the draft part= ially implemented. Do you think such a hackathon would be useful? Are you w= illing to participate?

Title: Secure DHCPv6
Authors: L. Li, S. Jiang, Y.Cui, T.Jinmei, T.Lemon, D.Zhang
Filename: draft-ietf-dhc-sedhcpv6-21
Pages: 31
Date: 2017-02-21
Link: https://datatracker.ietf.org/doc/draft-ietf-dhc-sedhcpv6/

Responses by March 29th are appreciated.

Thanks,
Bernie and Tomek

_______________________________________________=
dhcwg mailing list
dhcwg@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dhcwg

=C2=A0


--001a114feb687c12b4054beec49c-- From nobody Thu Mar 30 07:35:05 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47C0F129463; Thu, 30 Mar 2017 07:34:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 U8ZGHc9N1G67; Thu, 30 Mar 2017 07:34:50 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04BC5129501; Thu, 30 Mar 2017 07:34:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=61760; q=dns/txt; s=iport; t=1490884483; x=1492094083; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=zsGBLElbfJO8a7/P4UiHuNRTnjS6fXbB9xqNyr7A3Mk=; b=XaWIk8pgrT/76eP5U+s5GgiwmJKpwbHFPbcO6NLgOjzXpDygzCERnrV3 dUrAWARwv+7gde4XNawQC3PeiEPHDaE/MheMUAclEbdIhOb0qgON1Y3Ox aCmMulRQgZq0i5UArJB0YVdlXGDCoi9sv7KQ3QfCILMVr+5jPgdfLLTqa A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AWAQDtFt1Y/4MNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm49K2GBC41zkVGIGY03ggsDHwEKhXgCgzM/GAECAQEBAQEBAWs?= =?us-ascii?q?ohRUBAQEBAwEBGAEMRAMLDAQCAQgRAwEBASEBBgchBgsUCQgCBA4FiXMDFQ6va?= =?us-ascii?q?Dorhn0Ngx8BAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYhTgWGBCYE8gRWBbQI0DAq?= =?us-ascii?q?CfoIxBYZvgiuIGYRlhhc7AYZ8gyqDJ0qEOIF8hSqKEYpyiHoBHzhLOlsVGCkRA?= =?us-ascii?q?YQONgMNEIFjdQGGVwEkB4IQAQEB?= X-IronPort-AV: E=Sophos;i="5.36,246,1486425600"; d="scan'208,217";a="405194317" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Mar 2017 14:34:42 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v2UEYghq001443 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 30 Mar 2017 14:34:42 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 30 Mar 2017 09:34:41 -0500 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1210.000; Thu, 30 Mar 2017 09:34:41 -0500 From: "Bernie Volz (volz)" To: Lishan Li CC: Tomek Mrugalski , dhcwg , draft-ietf-dhc-sedhcpv6 authors Thread-Topic: [dhcwg] WGLC on draft-ietf-dhc-sedhcpv6-21 - Respond by March 29th Thread-Index: AQHSmBEofEj8/aGJckKkKaGWH1j71aGmX41wgAIqkgCAAF2FgIAEoQ2AgAAMtaI= Date: Thu, 30 Mar 2017 14:34:41 +0000 Message-ID: References: <7db55e6f55e34408a1816887c22e28d3@XCH-ALN-003.cisco.com> <369C97B6-B6E7-46CE-B42E-18559BFB1E78@cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_F2E48544A2354AB9AF4BF20DFB8E1532ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-sedhcpv6-21 - Respond by March 29th X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 14:34:57 -0000 --_000_F2E48544A2354AB9AF4BF20DFB8E1532ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Another issue to consider from speaking with Eric Vyncke last evening: - What about verifying the certificate's time? A client might not have curr= ent time and so may not be able to determine if certificate has expired? - Bernie (from iPhone) On Mar 30, 2017, at 3:49 AM, Lishan Li > wrote: 2017-03-27 22:07 GMT+08:00 Bernie Volz (volz) >: Hi: The sentence: "The encryption text SHOULD be formatted as explain in [RFC56= 52]." Isn't clear. RFC5652 doesn't use "text" except to mean actual wording= in the RFC. Could "encryption text" be clarified? Is this the client's mes= sage? Or what exactly is this and which part of RFC 5652 has this "format"?= I am not following what this sentence means and what I should do (if I wer= e implementing this). Note: This same text is also in Section 7 (last paragraph) and needs simila= r attention. [LS]: Sorry for the unclear expression. How about the following text? The DHCPv6 message sent from the client is encrypted and then encapsulated = into the encrypted DHCPv6 message field according to the Encrypted-Data con= tent syntax defined in the RFC5652. BV> I assume this reference is to section 8 of RFC 5652. But now the questi= on is whether anything further needs to be defined =96 for example, what (o= ptional) attributes should be included? Perhaps as I=92m not a security exp= ert or have carefully reviewed RFC5652 and am taking a few things =93out of= content=94 when looking at it, but I think some clarity here may help in m= ake sure this is easy to implement (especially for some of us that may not = be experts in cryptography). This is a bit more complex than just taking th= e bytes of the client=92s unencrypted message and the private key to encryp= t (and placing that into the Encrypted-message Option), and taking the encr= ypted client=92s message bytes (from a received Encrypted-message Option) a= nd decrypting with the public key? You may want to think about whether perh= aps specifying the details appropriate to DHCPv6 usage is appropriate =96 p= erhaps even in an appendix? RFC5652 talks about: And there=92s a lot about ASN.1 and OIDs in RFC5652, so are you pulling in = all of this? The following object identifier identifies the encrypted-data content type: id-encryptedData OBJECT IDENTIFIER ::=3D { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6 } The encrypted-data content type shall have ASN.1 type EncryptedData: EncryptedData ::=3D SEQUENCE { version CMSVersion, encryptedContentInfo EncryptedContentInfo, unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL } The fields of type EncryptedData have the following meanings: version is the syntax version number. If unprotectedAttrs is present, then the version MUST be 2. If unprotectedAttrs is absent, then version MUST be 0. encryptedContentInfo is the encrypted content information, as defined in Section 6.1. unprotectedAttrs is a collection of attributes that are not encrypted. The field is optional. Useful attribute types are defined in Section 11= . Probably section 6.1 is most applicable and there we have (eventually): EncryptedContent ::=3D OCTET STRING Which may be all we really need? And, if so, what is the value in referencing this RFC? Again, I=92m just trying to understand this more completely =96 what exactl= y is inside the Encrypted-message option? [LS]: Yes, the reference is section 8 of RFC5652. In the before version, Stephen suggested us to illustrate the format of the= encrypted message data. He suggested to add the reference of RFC5652 for i= t. But in fact, I don't know much about details of the draft. [LS]: Yes, the server just need to keep one set for all clients. How about the following modified text? For client, it MUST remember about its own increasing number, which is stor= ed in the NUM.STO and sent to the server. And the client also MUST remember= about a server's increasing number, which is received from the server and = stored in the NUM.REC. And the client keeps a record of the increasing numb= er during the DHCPv6 configuration process with the DHCPv6 server. And the= client can forget the increasing number information after the transaction = is finished. The client's initial locally stored increasing number is set = to zero. For server, it MUST remember about its own increasing number, which is stor= ed in the NUM.STO and sent to the client. And the server also MUST remember= about a client's increasing number, which is received from the client and = stored in the Num.REC. The server just need to keep one increasing number s= et for all clients. BV> Here again, please be careful: 1. If client always starts at 0, how does that help in preventing rep= lay? And, this isn=92t consistent with the server=92s behavior above? [LS]: For the first time that the client receives the increasing number, th= e client cannot compare it with the local number, and just to store it. 2. If client doesn=92t persist this, what happens if server has a lea= se for the client (and has retained the replay numbers) but the client rele= ased (or otherwise deleted the lease). Now when the client Solicits (encryp= ted), the server would report that this is a potential replay attach? I don= =92t think dropping this information =93after the transaction is finished= =94 is possible. [LS]: Yes, it is better for the client to retain the number it last used wi= th a server. For the devices without the persistent storage, the initial va= lue of the increasing number is zero. After checking the increasing number = in the Reply message, the NUM.STO is set to the NUM.REC. When sending the S= olicit message, the increasing number is larger than the NUM.STO. So, the s= erver will not report that this is a potential replay attack. 3. For =93The server just need to keep one increasing number set for = all clients=94 =96 shouldn=92t that be after the first sentence as this app= lies to NUM.STO; not NUM.REC? Thus, I think the client must retain the number it last used with a server.= This seems to be an issue for devices without persistent storage, so may r= equire some further thought =96 or those devices cannot use increasing numb= er? [LS]: Agree, the client MUST retain the increasing number it last used with= a server. And, I think both having to retain this forever would be a bad idea. I thin= k one could provide for both clients and servers to =93forget=94 any stored= information after a period of time (perhaps this can be a fixed number, 30= days, or should be some multiple of the lease lifetime)? [LS]: So we can recommend a lifetime of the increasing number for the clien= t and server, such as 30 days. Could you please check my understanding corr= ect? Likewise, since the Encryption-Key-Tag Option isn't protected, an attacker that can intercept the message can forge the value without detection. Isn't this generally useless? As the message is encrypted, the validation w= ill fail? [LS]: If the encryption-key-tag is forged, then the server may cannot decry= pt it and drop the message. BV> Right, but isn=92t that exactly what we would want? So, how is this bad= ? BV> Re Security Considerations - A new comment from a conversation with Tom= ek (Tomek will hopefully comment more). I mentioned that I was concerned wi= th the possibility of clients and servers getting =93junk=94 is a security = concern as someone could generate bad packets with encrypted data and send = them to clients and servers in the hope to crash the either when they try t= o decrypt and then process junk. Tomek suggested we might want to think abo= ut whether to add some magic value to the first few bytes of a message befo= re encrypting it and then the decrypter can check those first few bytes to = see if they are value and discard the message if not. Perhaps the encoding = from RFC5652 would accomplish this if we are using more than just the encry= ptedContent? Anyway, something to think about. [LS]: Agree. Perhaps the encoding from RFC5652 solves this problem. I think that it may be a general problem for all encryption protocol. Again, thanks for your continued efforts on this document! [LS]: As the author of the draft, I have the responsibility to work on it. = Thanks a lot for your continued guidance on this. Best Regards, Lishan From: Lishan Li > Date: Monday, March 27, 2017 at 12:33 AM To: Bernie Volz > Cc: Tomek Mrugalski >, "dhcwg@ietf.org" >, draft-ietf-dhc-sedhcpv6 authors > Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-sedhcpv6-21 - Respond by March = 29th Hi, Bernie, Thanks a lot for your valuable comments. For the details, please see inline= . Best Regards, Lishan 2017-03-26 10:05 GMT+08:00 Bernie Volz (volz) >: Hi: I have reviewed the draft and support it moving forward. However, I do have= some issues I think need to be addressed but they are mostly fairly small. I do want to thank the authors for addressing my earlier issues. I think th= e document is in MUCH better shape now!! So here goes ... Section 6: The sentence: "The encryption text SHOULD be formatted as explain in [RFC56= 52]." Isn't clear. RFC5652 doesn't use "text" except to mean actual wording= in the RFC. Could "encryption text" be clarified? Is this the client's mes= sage? Or what exactly is this and which part of RFC 5652 has this "format"?= I am not following what this sentence means and what I should do (if I wer= e implementing this). Note: This same text is also in Section 7 (last paragraph) and needs simila= r attention. [LS]: Sorry for the unclear expression. How about the following text? The DHCPv6 message sent from the client is encrypted and then encapsulated = into the encrypted DHCPv6 message field according to the Encrypted-Data con= tent syntax defined in the RFC5652. Section 7: option. Then, the server checks the Server Identifier option. The DHCPv6 server drops the message that is not for it, thus not paying cost to decrypt messages. If it is the target server, according to I think here you also want the server to proceed if there is NO Server Iden= tifier option? It should only ignore it if there is a Server Identifier opt= ion and it does not match this server's identifier? [LS]: Yes. Will modify it. Section 8 those present in the innermost encapsulated messages from the client or server. I think messages should just be message as there is only one message? [LS]: Agree. Will modify it. Section 9.1: Might be better to split out requirements for a client and server into sepa= rate paragraphs (1st paragraph)? Might also be best to be clear that you ad= dress: 1. What a client must remember about its own increasing number (i.e., what = it sends to the server). 2. What a client must remember about the server's increasing number (i.e., = what it receives from server). 3. What a server must remember about a client's increasing number (i.e., wh= at it receives from client). 4. What a server must remember about its own increasing number (i.e., what = it sends to clients). I assume a server does NOT need to keep a unique incr= easing number set for each client it communicates with - a server can use o= ne set for all clients? Please also be clear about how each of these 4 (2 numbers on client, 2 on s= erver) are handled. The text presently is not very clear -- for example a c= lient can't forget what it sent if the server remembers it. [LS]: Yes, the server just need to keep one set for all clients. How about the following modified text? For client, it MUST remember about its own increasing number, which is stor= ed in the NUM.STO and sent to the server. And the client also MUST remember= about a server's increasing number, which is received from the server and = stored in the NUM.REC. And the client keeps a record of the increasing numb= er during the DHCPv6 configuration process with the DHCPv6 server. And the= client can forget the increasing number information after the transaction = is finished. The client's initial locally stored increasing number is set = to zero. For server, it MUST remember about its own increasing number, which is stor= ed in the NUM.STO and sent to the client. And the server also MUST remember= about a client's increasing number, which is received from the client and = stored in the Num.REC. The server just need to keep one increasing number s= et for all clients. Later, be clear that this is modulo 2^64 math: The Increasing-number option in the received message passes the increasing number check if NUM.REC is more than NUM.STO. And then, the value of NUM.STO is changed into the value of NUM.REC. The increasing number check fails if NUM.REC is equal with or less than NUM.STO. "More" here is in the modulo arithmetic "more" -- perhaps use "more (modulo= 2^64)" and "or less (modulo 2^64)"? [LS]: Agree, will modify it. Section 9.2: I wonder if you should revise the code to make it more appropriate for this= document? RDATA/RDLENGTH aren't really appropriate? [LS]: Got it. Will modify it. Section 10 There are now only three (not six) status codes. [LS]: Will correct it. Section 10.2 msg-type Identifier of the message type. It can be either Encrypted-Query (TBA7) or DHCPv6-Response (TBA8). Change DHCPv6-Response to Encrypted-Response. [LS]: Will correct it. Section 11 There are some mandatory algorithm for encryption algorithm in this Change (first) algorithm to algorithms? Or, change "are some" to "is a" [LS]: Will change it. Likewise, since the Encryption-Key-Tag Option isn't protected, an attacker that can intercept the message can forge the value without detection. Isn't this generally useless? As the message is encrypted, the validation w= ill fail? [LS]: If the encryption-key-tag is forged, then the server may cannot decry= pt it and drop the message. Some even more MINOR comments (these would perhaps improve readability but = would likely be addressed by the RFC editor): [LS]: Sorry for the poor expression. And thanks a lot your throughout check= . Will correct it in the next version. Section 6: Perhaps replace "contained" and "contain" with "included" and "include" in = the sentences later in that same paragraph (with the "The encryption text..= ."). For the received Encrypted-Response message, the client MUST drop the Encrypted-Response message if other DHCPv6 option except Encrypted- message option is contained. How about: For the received Encrypted-Response message, the client MUST drop the Encrypted-Response message if it contains any option other than a single Encrypted-message option. Note: There are some other odd uses of contain (when at least I think the t= ext should use include). But it may not be worth trying to change these (th= e usage is tricky - you can google for "english contain vs include" if you = like). We will leave it to the RFC editor to perhaps clean these up if appr= opriate. The client MAY use the AuthenticationFail as a hint and switch to other DHCPv6 server if it has another one. Change to "to another DHCP server if it has one"? Section 7: Upon the receipt of Encrypted-Query message, the server MUST drop the message if the other DHCPv6 option is contained except Server Here "the other" should change to "another". Note: There are several other places where contained/contain would (at leas= t in my mind) be more "standard" if the text used included/include. Same go= es for use of "other" (-> another). Last paragraph of section 7, "then the server set the". Set should be sets. Section 10.1.1 For EA-len, might be good to add "(must be a multiple of 2)" For SHA-len, might be good to add "(must be a multiple of 4)" Also, I think you should change all "2-octets value" to "2-octet value". Section 11 For this security item, It is RECOMMENDED that client certificates could be tied to specific server certificates by configuration. Lower case "It"? General There are uses of "cert" and "certs" and "certificate(s)". Are these one in= the same? Shouldn't we just use "certificate" throughout? Or perhaps you s= hould add "cert(s)" to terminology section? - Bernie -----Original Message----- From: dhcwg [mailto:dhcwg-bounces@ietf.org] = On Behalf Of Tomek Mrugalski Sent: Wednesday, March 08, 2017 8:37 AM To: dhcwg > Cc: draft-ietf-dhc-sedhcpv6 authors > Subject: [dhcwg] WGLC on draft-ietf-dhc-sedhcpv6-21 - Respond by March 29th Hi, draft-ietf-dhc-sedhcpv6-21 describes a mechanism for using public key crypt= ography to provide end-to-end security between DHCPv6 clients and servers. = The mechanism provides encryption in all cases, and can be used for authent= ication based on pre-sharing of authorized certificates. This draft has sta= rted in 2013, but the whole DHCPv6 security saga is much longer and begins = in 2008. This draft was submitted to IESG in mid-2015. The guidance received was clear that substantial changes are needed. As a = result, "encrypt everywhere, authenticate if you can" approach was used. Authors believe this draft to be ready for working group last call. Please send your substantial comments to the mailing list and express your = opinion whether this draft is ready for publication. Feel free to send nitp= icks and minor corrections to the authors directly. This is a complex draft= , so the chairs believe 3 weeks WGLC is in order. Please send your comments= no later than March 29th. Bernie and I will determine consensus and will d= iscuss during Chicago meeting as needed. To initiate the discussion, I have two related questions. The chairs would = love to hear your opinions on those. 1. The "encrypt everywhere" paradigm means that in deployments that do snoo= ping on relay will break down. To solve this problem, we need a assignment = notification mechanism, similar to the one described in draft-ietf-dhc-dhcp= v6-agentopt-delegate-04. That draft expired many years ago. This matter was= discussed in Seoul and the minutes describe the conclusion as: The discussion gravitated towards not resurrecting until the sedhcpv6 I-D progresses further. We will reevaluate this once sedhcpv6 is done. Do you want the WG to resurrect agentopt-delegate a) now, b) when sedhcpv6 is sent to IESG or c) when sedhcpv6 is published as RFC? d) we nee= d a completely new draft and I'm volunteering to work on it. 2. One of the authors suggested that this protocol is quite complex and hav= ing a feedback from an implementation (or ideally two interoperating) would= be very important and would likely result in some changes to the draft. It= 's probably too late for Chicago, but we can organize a sedhcpv6 hackathon in Prague. Two likely implementations would be WIDE and = Kea, as those two are open source and have an old version of the draft part= ially implemented. Do you think such a hackathon would be useful? Are you w= illing to participate? Title: Secure DHCPv6 Authors: L. Li, S. Jiang, Y.Cui, T.Jinmei, T.Lemon, D.Zhang Filename: draft-ietf-dhc-sedhcpv6-21 Pages: 31 Date: 2017-02-21 Link: https://datatracker.ietf.org/doc/draft-ietf-dhc-sedhcpv6/ Responses by March 29th are appreciated. Thanks, Bernie and Tomek _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg --_000_F2E48544A2354AB9AF4BF20DFB8E1532ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Another issue to consider from speaking with Eric Vyncke last evening:=

- What about verifying the certificate's tim= e? A client might not have current time and so may not be able to determine= if certificate has expired? 

- Bernie (from iPhone)

On Mar 30, 2017, at 3:49 AM, Lishan Li <lilishan48@gmail.com> wrote:

2017-03-27 22:07 GMT+08:00 Bernie Volz (volz= ) <volz@cisco.com&= gt;:

Hi:

 

The sentence: "The encryption text SHOULD be fo= rmatted as explain in [RFC5652]." Isn't clear. RFC5652 doesn't use &qu= ot;text" except to mean actual wording in the RFC. Could "encrypt= ion text" be clarified? Is this the client's message? Or what exactly is this and which part of RFC 5652 has this "format"? I = am not following what this sentence means and what I should do (if I were i= mplementing this).

Note: This same text is also in Section 7 (last paragraph) and needs simila= r attention.

[LS]: Sorry for the unclear expression. How about th= e following text?

The DHCPv6 message sent from the client is encrypted= and then encapsulated into the encrypted DHCPv6 message field according to= the Encrypted-Data content syntax defined in the RFC5652.

 

 
BV> I assume t=
his reference is to section 8 of RFC 5652. But now the question is whether =
anything further needs to be defined =96 for example, what (optional) attri=
butes should be included? Perhaps as I=92m not a security expert or have ca=
refully reviewed RFC5652 and am taking a few things =93out of content=94 wh=
en looking at it, but I think some clarity here may help in make sure this =
is easy to implement (especially for some of us that may not be experts in =
cryptography). This is a bit more complex than just taking the bytes of the=
 client=92s unencrypted message and the private key to encrypt (and placing=
 that into the Encrypted-message Option), and taking the encrypted client=
=92s message bytes (from a received Encrypted-message Option) and decryptin=
g with the public key? You may want to think about whether perhaps specifyi=
ng the details appropriate to DHCPv6 usage is appropriate =96 perhaps even =
in an appendix? RFC5652 talks about:

 

And there=92s a lot about ASN.1 and OIDs in RFC5652, so are you pulling in= all of this?

 

   The following object identifier i= dentifies the encrypted-data content

   type:

 

      id-encryptedDat= a OBJECT IDENTIFIER ::=3D { iso(1) member-body(2)

       &nbs= p;  us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6 }

 

   The encrypted-data content type s= hall have ASN.1 type EncryptedData:

 

      EncryptedData := :=3D SEQUENCE {

        ver= sion CMSVersion,

        enc= ryptedContentInfo EncryptedContentInfo,

        unp= rotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL }

 

   The fields of type EncryptedData = have the following meanings:

 

      version is the = syntax version number.  If unprotectedAttrs is

      present, then t= he version MUST be 2.  If unprotectedAttrs is

      absent, then ve= rsion MUST be 0.

 

      encryptedConten= tInfo is the encrypted content information, as

      defined in Section 6.1.

 

      unprotectedAttr= s is a collection of attributes that are not

      encrypted. = ; The field is optional.  Useful attribute types are

      defined in Section 11.

 

Probably section 6.1 is most applicable and there we have (eventually):=

 

    EncryptedContent ::=3D =
OCTET STRING

 

Which may be all we really need?

 

And, if so, what is the value in referencing this RFC?

 

Again, I=92m just trying to understand this more completely =96 what exact= ly is inside the Encrypted-message option?

 

 

[LS]: Yes, the reference is section 8 of RFC5652.
In the before version, Stephen suggested us to illustrate the format o= f the encrypted message data. He suggested to add the reference of RFC5652 = for it. 
But in fact, I don't know much about details of the draft.

 

[LS]: Yes, the server just need to keep one set for = all clients. 

How about the following modified text?=

For client, it MUST remember about its own increasin= g number, which is stored in the NUM.STO and sent to the server. And the cl= ient also MUST remember about a server's increasing number, which is receiv= ed from the server and stored in the NUM.REC. And the client keeps a record of the increasing number during the= DHCPv6 configuration process with the DHCPv6 server.  And the client = can forget the increasing number information after the transaction is finis= hed.  The client's initial locally stored increasing number is set to zero.

 

For server, it MUST remember about its own increasin= g number, which is stored in the NUM.STO and sent to the client. And the se= rver also MUST remember about a client's increasing number, which is receiv= ed from the client and stored in the Num.REC. The server just need to keep one increasing number set for all cl= ients.

 

BV> Here again, please be careful:

1.       If client always starts at 0, how does that help in preventing replay= ? And, this isn=92t consistent with the server=92s behavior above?

[LS]: For the first time that the client receives the increasing numbe= r, the client cannot compare it with the local number, and just to store it= .

2.       If client doesn=92t persist this, what happens if server has a lease = for the client (and has retained the replay numbers) but the client release= d (or otherwise deleted the lease). Now when the client Solicits (encrypted), the server would report that thi= s is a potential replay attach? I don=92t think dropping this information = =93after the transaction is finished=94 is possible.

[LS]: Yes, it is better for the client to retain the number it last us= ed with a server. For the devices without the persistent storage, the initi= al value of the increasing number is zero. After checking the increasing nu= mber in the Reply message, the NUM.STO is set to the NUM.REC. When sending the Solicit message, the increasing nu= mber is larger than the NUM.STO. So, the server will not report that this i= s a potential replay attack. 

3.       For =93The server just need to keep one increasing number set for all= clients=94 =96 shouldn=92t that be after the first sentence as this applie= s to NUM.STO; not NUM.REC?

Thus, I think the client must retain the number it last used with a server= . This seems to be an issue for devices without persistent storage, so may = require some further thought =96 or those devices cannot use increasing number?

[LS]: Agree, the client MUST retain the increasing number it last used= with a server. 

 

And, I think both having to retain this forever would be a bad idea. I thi= nk one could provide for both clients and servers to =93forget=94 any store= d information after a period of time (perhaps this can be a fixed number, 30 days, or should be some multiple of the lea= se lifetime)?

[LS]: So we can recommend a lifetime of the increasing number for the = client and server, such as 30 days. Could you please check my understanding= correct? 

 

 

   Likewise, since the Encryption-Key-Tag = Option isn't protected, an
   attacker that can intercept the message can forge the value wi= thout
   detection.

Isn't this generally useless? As the message is encrypted, the validation w= ill fail?

[LS]: If the encryption-key-tag is forged, then the = server may cannot decrypt it and drop the message.

 

BV> Right, but isn=92t that exactly what we would want? So, how is this= bad?

  

 

BV> Re Security Considerations - A new comment from a conversation with= Tomek (Tomek will hopefully comment more). I mentioned that I was concerne= d with the possibility of clients and servers getting =93junk=94 is a security concern as someone could generate bad pac= kets with encrypted data and send them to clients and servers in the hope t= o crash the either when they try to decrypt and then process junk. Tomek su= ggested we might want to think about whether to add some magic value to the first few bytes of a message before= encrypting it and then the decrypter can check those first few bytes to se= e if they are value and discard the message if not. Perhaps the encoding fr= om RFC5652 would accomplish this if we are using more than just the encryptedContent? Anyway, something to = think about.

[LS]: Agree. Perhaps the encoding from RFC5652 solves this problem.&nb= sp;
I think that it may be a general problem for all encryption protocol.&= nbsp;

 

 

Again, thanks for your continued efforts on this document!

 

[LS]: As the author of the draft, I have the responsibility to work on= it. Thanks a lot for your continued guidance on this. 

Best Regards,
Lishan

F= rom: Lishan Li <lilishan48@gmail.com= >
Date: Monday, March 27, 2017 at 12:33 AM
To: Bernie Volz <volz@cisco.com>
Cc: Tomek Mrugalski <tomasz.mrugalski@gmail.com>, "dhcwg@ietf.org" <dhcwg@ietf.org>, draft-ietf-dhc-sedhcpv6 authors <draft-ietf-dhc-sedhcpv6@ietf.org&g= t;
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-sedhcpv6-21 - Respond by= March 29th

 

Hi, Bernie,

 

Thanks a lot for your valuable comments. For the det= ails, please see inline.

 

Best Regards,

Lishan

 

2017-03-26 10:05 GMT+08:00 Bernie Volz (volz) &l= t;volz@cisco.com>= ;:

Hi:

I have reviewed the draft and support it moving forward. However, I do have= some issues I think need to be addressed but they are mostly fairly small.=

I do want to thank the authors for addressing my earlier issues. I think th= e document is in MUCH better shape now!!

So here goes ...

Section 6:
The sentence: "The encryption text SHOULD be formatted as explain in [= RFC5652]." Isn't clear. RFC5652 doesn't use "text" except to= mean actual wording in the RFC. Could "encryption text" be clari= fied? Is this the client's message? Or what exactly is this and which part of RFC 5652 has this "format"? I am not following wha= t this sentence means and what I should do (if I were implementing this).
Note: This same text is also in Section 7 (last paragraph) and needs simila= r attention.

[LS]: Sorry for the unclear expression. How about th= e following text?

The DHCPv6 message sent from the client is encrypted= and then encapsulated into the encrypted DHCPv6 message field according to= the Encrypted-Data content syntax defined in the RFC5652.

 


Section 7:

   option.  Then, the server checks the Server Identifier op= tion.  The
   DHCPv6 server drops the message that is not for it, thus not p= aying
   cost to decrypt messages.  If it is the target server, ac= cording to

I think here you also want the server to proceed if there is NO Server Iden= tifier option? It should only ignore it if there is a Server Identifier opt= ion and it does not match this server's identifier?

[LS]: Yes. Will modify it. 


Section 8

   those present in the innermost encapsulated messages from the = client
   or server.

I think messages should just be message as there is only one message?

[LS]: Agree. Will modify it. 


Section 9.1:

Might be better to split out requirements for a client and server into sepa= rate paragraphs (1st paragraph)? Might also be best to be clear that you ad= dress:
1. What a client must remember about its own increasing number (i.e., what = it sends to the server).
2. What a client must remember about the server's increasing number (i.e., = what it receives from server).
3. What a server must remember about a client's increasing number (i.e., wh= at it receives from client).
4. What a server must remember about its own increasing number (i.e., what = it sends to clients). I assume a server does NOT need to keep a unique incr= easing number set for each client it communicates with - a server can use o= ne set for all clients?
Please also be clear about how each of these 4 (2 numbers on client, 2 on s= erver) are handled. The text presently is not very clear -- for example a c= lient can't forget what it sent if the server remembers it.

[LS]: Yes, the server just need to keep one set for = all clients. 

How about the following modified text?=

For client, it MUST remember about its own increasin= g number, which is stored in the NUM.STO and sent to the server. And the cl= ient also MUST remember about a server's increasing number, which is receiv= ed from the server and stored in the NUM.REC. And the client keeps a record of the increasing number during the= DHCPv6 configuration process with the DHCPv6 server.  And the client = can forget the increasing number information after the transaction is finis= hed.  The client's initial locally stored increasing number is set to zero.

 

For server, it MUST remember about its own increasin= g number, which is stored in the NUM.STO and sent to the client. And the se= rver also MUST remember about a client's increasing number, which is receiv= ed from the client and stored in the Num.REC. The server just need to keep one increasing number set for all cl= ients.


Later, be clear that this is modulo 2^64 math:

   The Increasing-number option in the received message passes th= e
   increasing number check if NUM.REC is more than NUM.STO. = And then,
   the value of NUM.STO is changed into the value of NUM.REC.

   The increasing number check fails if NUM.REC is equal with or = less
   than NUM.STO.

"More" here is in the modulo arithmetic "more" -- perha= ps use "more (modulo 2^64)" and "or less (modulo 2^64)"= ?

[LS]: Agree, will modify it. 


Section 9.2:

I wonder if you should revise the code to make it more appropriate for this= document? RDATA/RDLENGTH aren't really appropriate?

[LS]: Got it. Will modify it. 


Section 10

There are now only three (not six) status codes.

[LS]: Will correct it. 


Section 10.2

   msg-type        Identifier of the message = type.  It can be either
                   Encryp= ted-Query (TBA7) or DHCPv6-Response (TBA8).

Change DHCPv6-Response to Encrypted-Response.

[LS]: Will correct it. 



Section 11

   There are some mandatory algorithm for encryption algorithm in= this

Change (first) algorithm to algorithms? Or, change "are some" to = "is a"

[LS]: Will change it. 



   Likewise, since the Encryption-Key-Tag Option isn't protected,= an
   attacker that can intercept the message can forge the value wi= thout
   detection.

Isn't this generally useless? As the message is encrypted, the validation w= ill fail?

[LS]: If the encryption-key-tag is forged, then the = server may cannot decrypt it and drop the message.



Some even more MINOR comments (these would perhaps improve readability but = would likely be addressed by the RFC editor):

[LS]: Sorry for the poor expression. And thanks a lo= t your throughout check. Will correct it in the next version. <= u>


Section 6:

Perhaps replace "contained" and "contain" with "in= cluded" and "include" in the sentences later in that same pa= ragraph (with the "The encryption text...").


   For the received Encrypted-Response message, the client MUST d= rop the
   Encrypted-Response message if other DHCPv6 option except Encry= pted-
   message option is contained.

How about:

   For the received Encrypted-Response message, the client MUST d= rop the
   Encrypted-Response message if it contains any option other tha= n a single
   Encrypted-message option.

Note: There are some other odd uses of contain (when at least I think the t= ext should use include). But it may not be worth trying to change these (th= e usage is tricky - you can google for "english contain vs include&quo= t; if you like). We will leave it to the RFC editor to perhaps clean these up if appropriate.


      The client MAY use the AuthenticationFail as a hint an= d switch
      to other DHCPv6 server if it has another one.

Change to "to another DHCP server if it has one"?

Section 7:

   Upon the receipt of Encrypted-Query message, the server MUST d= rop the
   message if the other DHCPv6 option is contained except Server<= br>
Here "the other" should change to "another".

Note: There are several other places where contained/contain would (at leas= t in my mind) be more "standard" if the text used included/includ= e. Same goes for use of "other" (-> another).

Last paragraph of section 7, "then the server set the". Set shoul= d be sets.

Section 10.1.1

For EA-len, might be good to add "(must be a multiple of 2)"
For SHA-len, might be good to add "(must be a multiple of 4)"

Also, I think you should change all "2-octets value" to "2-o= ctet value".

Section 11

   For this security item, It is RECOMMENDED that client certific= ates
   could be tied to specific server certificates by configuration= .

Lower case "It"?


General

There are uses of "cert" and "certs" and "certific= ate(s)". Are these one in the same? Shouldn't we just use "certif= icate" throughout? Or perhaps you should add "cert(s)" to te= rminology section?


- Bernie

-----Original Message-----
From: dhcwg [mailto:dhcwg-bounces@ietf.org= ] On Behalf Of Tomek Mrugalski
Sent: Wednesday, March 08, 2017= 8:37 AM
To: dhcwg <dhcwg@ietf.org>
Cc: draft-ietf-dhc-sedhcpv6 aut= hors <draft-ietf-dhc-sedhcpv6@ietf.org>
Subject: [dhcwg] WGLC on draft-= ietf-dhc-sedhcpv6-21 - Respond by March 29th

Hi,
draft-ietf-dhc-sedhcpv6-21 describes a mechanism for using public key crypt= ography to provide end-to-end security between DHCPv6 clients and servers. = The mechanism provides encryption in all cases, and can be used for authent= ication based on pre-sharing of authorized certificates. This draft has started in 2013, but the whole DHC= Pv6 security saga is much longer and begins in 2008. This draft was submitt= ed to IESG in mid-2015.
The guidance received was clear that  substantial changes are needed. = As a result, "encrypt everywhere, authenticate if you can" approa= ch was used.

Authors believe this draft to be ready for working group last call.

Please send your substantial comments to the mailing list and express your = opinion whether this draft is ready for publication. Feel free to send nitp= icks and minor corrections to the authors directly. This is a complex draft= , so the chairs believe 3 weeks WGLC is in order. Please send your comments no later than March 29th. Bern= ie and I will determine consensus and will discuss during Chicago meeting a= s needed.

To initiate the discussion, I have two related questions. The chairs would = love to hear your opinions on those.

1. The "encrypt everywhere" paradigm means that in deployments th= at do snooping on relay will break down. To solve this problem, we need a a= ssignment notification mechanism, similar to the one described in draft-iet= f-dhc-dhcpv6-agentopt-delegate-04. That draft expired many years ago. This matter was discussed in Seoul and the m= inutes describe the conclusion as:

  The discussion gravitated towards not resurrecting until the sedhcpv= 6
  I-D progresses further. We will reevaluate this once sedhcpv6 is don= e.

Do you want the WG to resurrect agentopt-delegate a) now, b) when
sedhcpv6 is sent to IESG or c) when sedhcpv6 is published as RFC? d) we nee= d a completely new draft and I'm volunteering to work on it.

2. One of the authors suggested that this protocol is quite complex and hav= ing a feedback from an implementation (or ideally two interoperating) would= be very important and would likely result in some changes to the draft. It= 's probably too late for Chicago, but we can organize a
sedhcpv6 hackathon in Prague. Two likely implementations would be WIDE and = Kea, as those two are open source and have an old version of the draft part= ially implemented. Do you think such a hackathon would be useful? Are you w= illing to participate?

Title: Secure DHCPv6
Authors: L. Li, S. Jiang, Y.Cui, T.Jinmei, T.Lemon, D.Zhang
Filename: draft-ietf-dhc-sedhcpv6-21
Pages: 31
Date: 2017-02-21
Link: https://datatracker.ietf.org/doc/draft-ietf-dhc-sedhcpv6/

Responses by March 29th are appreciated.

Thanks,
Bernie and Tomek

_______________________________________________=
dhcwg mailing list
dhcwg@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dhcwg

 


--_000_F2E48544A2354AB9AF4BF20DFB8E1532ciscocom_-- From nobody Thu Mar 30 07:38:00 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7B1412950B; Thu, 30 Mar 2017 07:37:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 A3km9uOFtWTc; Thu, 30 Mar 2017 07:37:47 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E691129501; Thu, 30 Mar 2017 07:37:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=61642; q=dns/txt; s=iport; t=1490884667; x=1492094267; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=TMMqdPcAo9K7zKI5MVW232FTZ20OfNtXm8aeJgYL/ME=; b=lr+7j9D360aV2ZhsF+SFVLqcsv101D3r/JLpeRhxj2os4Jl3v1RFkYMX wJ77nenUDJE/p+0Yx9wh5HnKoTxRDj9xcwgMbrSob9urTp/2nM7zy8tSw 5IN9/lpwnbEC1k5QI0eMv8up5+IBSlVN71TLCFYPE3fVeeb8dshQWNNnD U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AbAQDtFt1Y/5xdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm49K2GBC41zkTIfiBmNN4ILAx8BCoV4AoMzPxgBAgEBAQEBAQF?= =?us-ascii?q?rKIUVAQEBAQMBARgBDEQDCwwEAgEIEAEDAQEBIQEGByEGCxQJCAIEDgWJcwMVD?= =?us-ascii?q?q9oOiuGfQ2DHwEBAQEBAQEBAQEBAQEBAQEBAQEBARgFiFMIgVmBCYE8gRWBbQI?= =?us-ascii?q?0DAqCfoIxBYZvgiuIGYRlhhc7AYZ8gyqDJ0qEOIF8hSqKEYpyiHoBHzhLOlsVG?= =?us-ascii?q?CkRAYQONgMNEIFjdQGGVwEkB4IQAQEB?= X-IronPort-AV: E=Sophos;i="5.36,246,1486425600"; d="scan'208,217";a="401311146" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Mar 2017 14:37:45 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v2UEbjld010571 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 30 Mar 2017 14:37:45 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 30 Mar 2017 09:37:44 -0500 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1210.000; Thu, 30 Mar 2017 09:37:44 -0500 From: "Bernie Volz (volz)" To: Lishan Li CC: Tomek Mrugalski , dhcwg , draft-ietf-dhc-sedhcpv6 authors Thread-Topic: [dhcwg] WGLC on draft-ietf-dhc-sedhcpv6-21 - Respond by March 29th Thread-Index: AQHSmBEofEj8/aGJckKkKaGWH1j71aGmX41wgAIqkgCAAF2FgIAEoQ2AgAANjyw= Date: Thu, 30 Mar 2017 14:37:44 +0000 Message-ID: References: <7db55e6f55e34408a1816887c22e28d3@XCH-ALN-003.cisco.com> <369C97B6-B6E7-46CE-B42E-18559BFB1E78@cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_FBDB0F6800874488863FE5F0D45281BFciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-sedhcpv6-21 - Respond by March 29th X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 14:37:59 -0000 --_000_FBDB0F6800874488863FE5F0D45281BFciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Regarding RFC5652, you will need to work with others to determine what piec= es are applicable - perhaps check in with Stephen to get more clarity on wh= at he intended? Perhaps Jinmei or Francis Dupont has some suggestions? - Bernie (from iPhone) On Mar 30, 2017, at 3:49 AM, Lishan Li > wrote: 2017-03-27 22:07 GMT+08:00 Bernie Volz (volz) >: Hi: The sentence: "The encryption text SHOULD be formatted as explain in [RFC56= 52]." Isn't clear. RFC5652 doesn't use "text" except to mean actual wording= in the RFC. Could "encryption text" be clarified? Is this the client's mes= sage? Or what exactly is this and which part of RFC 5652 has this "format"?= I am not following what this sentence means and what I should do (if I wer= e implementing this). Note: This same text is also in Section 7 (last paragraph) and needs simila= r attention. [LS]: Sorry for the unclear expression. How about the following text? The DHCPv6 message sent from the client is encrypted and then encapsulated = into the encrypted DHCPv6 message field according to the Encrypted-Data con= tent syntax defined in the RFC5652. BV> I assume this reference is to section 8 of RFC 5652. But now the questi= on is whether anything further needs to be defined =96 for example, what (o= ptional) attributes should be included? Perhaps as I=92m not a security exp= ert or have carefully reviewed RFC5652 and am taking a few things =93out of= content=94 when looking at it, but I think some clarity here may help in m= ake sure this is easy to implement (especially for some of us that may not = be experts in cryptography). This is a bit more complex than just taking th= e bytes of the client=92s unencrypted message and the private key to encryp= t (and placing that into the Encrypted-message Option), and taking the encr= ypted client=92s message bytes (from a received Encrypted-message Option) a= nd decrypting with the public key? You may want to think about whether perh= aps specifying the details appropriate to DHCPv6 usage is appropriate =96 p= erhaps even in an appendix? RFC5652 talks about: And there=92s a lot about ASN.1 and OIDs in RFC5652, so are you pulling in = all of this? The following object identifier identifies the encrypted-data content type: id-encryptedData OBJECT IDENTIFIER ::=3D { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6 } The encrypted-data content type shall have ASN.1 type EncryptedData: EncryptedData ::=3D SEQUENCE { version CMSVersion, encryptedContentInfo EncryptedContentInfo, unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL } The fields of type EncryptedData have the following meanings: version is the syntax version number. If unprotectedAttrs is present, then the version MUST be 2. If unprotectedAttrs is absent, then version MUST be 0. encryptedContentInfo is the encrypted content information, as defined in Section 6.1. unprotectedAttrs is a collection of attributes that are not encrypted. The field is optional. Useful attribute types are defined in Section 11= . Probably section 6.1 is most applicable and there we have (eventually): EncryptedContent ::=3D OCTET STRING Which may be all we really need? And, if so, what is the value in referencing this RFC? Again, I=92m just trying to understand this more completely =96 what exactl= y is inside the Encrypted-message option? [LS]: Yes, the reference is section 8 of RFC5652. In the before version, Stephen suggested us to illustrate the format of the= encrypted message data. He suggested to add the reference of RFC5652 for i= t. But in fact, I don't know much about details of the draft. [LS]: Yes, the server just need to keep one set for all clients. How about the following modified text? For client, it MUST remember about its own increasing number, which is stor= ed in the NUM.STO and sent to the server. And the client also MUST remember= about a server's increasing number, which is received from the server and = stored in the NUM.REC. And the client keeps a record of the increasing numb= er during the DHCPv6 configuration process with the DHCPv6 server. And the= client can forget the increasing number information after the transaction = is finished. The client's initial locally stored increasing number is set = to zero. For server, it MUST remember about its own increasing number, which is stor= ed in the NUM.STO and sent to the client. And the server also MUST remember= about a client's increasing number, which is received from the client and = stored in the Num.REC. The server just need to keep one increasing number s= et for all clients. BV> Here again, please be careful: 1. If client always starts at 0, how does that help in preventing rep= lay? And, this isn=92t consistent with the server=92s behavior above? [LS]: For the first time that the client receives the increasing number, th= e client cannot compare it with the local number, and just to store it. 2. If client doesn=92t persist this, what happens if server has a lea= se for the client (and has retained the replay numbers) but the client rele= ased (or otherwise deleted the lease). Now when the client Solicits (encryp= ted), the server would report that this is a potential replay attach? I don= =92t think dropping this information =93after the transaction is finished= =94 is possible. [LS]: Yes, it is better for the client to retain the number it last used wi= th a server. For the devices without the persistent storage, the initial va= lue of the increasing number is zero. After checking the increasing number = in the Reply message, the NUM.STO is set to the NUM.REC. When sending the S= olicit message, the increasing number is larger than the NUM.STO. So, the s= erver will not report that this is a potential replay attack. 3. For =93The server just need to keep one increasing number set for = all clients=94 =96 shouldn=92t that be after the first sentence as this app= lies to NUM.STO; not NUM.REC? Thus, I think the client must retain the number it last used with a server.= This seems to be an issue for devices without persistent storage, so may r= equire some further thought =96 or those devices cannot use increasing numb= er? [LS]: Agree, the client MUST retain the increasing number it last used with= a server. And, I think both having to retain this forever would be a bad idea. I thin= k one could provide for both clients and servers to =93forget=94 any stored= information after a period of time (perhaps this can be a fixed number, 30= days, or should be some multiple of the lease lifetime)? [LS]: So we can recommend a lifetime of the increasing number for the clien= t and server, such as 30 days. Could you please check my understanding corr= ect? Likewise, since the Encryption-Key-Tag Option isn't protected, an attacker that can intercept the message can forge the value without detection. Isn't this generally useless? As the message is encrypted, the validation w= ill fail? [LS]: If the encryption-key-tag is forged, then the server may cannot decry= pt it and drop the message. BV> Right, but isn=92t that exactly what we would want? So, how is this bad= ? BV> Re Security Considerations - A new comment from a conversation with Tom= ek (Tomek will hopefully comment more). I mentioned that I was concerned wi= th the possibility of clients and servers getting =93junk=94 is a security = concern as someone could generate bad packets with encrypted data and send = them to clients and servers in the hope to crash the either when they try t= o decrypt and then process junk. Tomek suggested we might want to think abo= ut whether to add some magic value to the first few bytes of a message befo= re encrypting it and then the decrypter can check those first few bytes to = see if they are value and discard the message if not. Perhaps the encoding = from RFC5652 would accomplish this if we are using more than just the encry= ptedContent? Anyway, something to think about. [LS]: Agree. Perhaps the encoding from RFC5652 solves this problem. I think that it may be a general problem for all encryption protocol. Again, thanks for your continued efforts on this document! [LS]: As the author of the draft, I have the responsibility to work on it. = Thanks a lot for your continued guidance on this. Best Regards, Lishan From: Lishan Li > Date: Monday, March 27, 2017 at 12:33 AM To: Bernie Volz > Cc: Tomek Mrugalski >, "dhcwg@ietf.org" >, draft-ietf-dhc-sedhcpv6 authors > Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-sedhcpv6-21 - Respond by March = 29th Hi, Bernie, Thanks a lot for your valuable comments. For the details, please see inline= . Best Regards, Lishan 2017-03-26 10:05 GMT+08:00 Bernie Volz (volz) >: Hi: I have reviewed the draft and support it moving forward. However, I do have= some issues I think need to be addressed but they are mostly fairly small. I do want to thank the authors for addressing my earlier issues. I think th= e document is in MUCH better shape now!! So here goes ... Section 6: The sentence: "The encryption text SHOULD be formatted as explain in [RFC56= 52]." Isn't clear. RFC5652 doesn't use "text" except to mean actual wording= in the RFC. Could "encryption text" be clarified? Is this the client's mes= sage? Or what exactly is this and which part of RFC 5652 has this "format"?= I am not following what this sentence means and what I should do (if I wer= e implementing this). Note: This same text is also in Section 7 (last paragraph) and needs simila= r attention. [LS]: Sorry for the unclear expression. How about the following text? The DHCPv6 message sent from the client is encrypted and then encapsulated = into the encrypted DHCPv6 message field according to the Encrypted-Data con= tent syntax defined in the RFC5652. Section 7: option. Then, the server checks the Server Identifier option. The DHCPv6 server drops the message that is not for it, thus not paying cost to decrypt messages. If it is the target server, according to I think here you also want the server to proceed if there is NO Server Iden= tifier option? It should only ignore it if there is a Server Identifier opt= ion and it does not match this server's identifier? [LS]: Yes. Will modify it. Section 8 those present in the innermost encapsulated messages from the client or server. I think messages should just be message as there is only one message? [LS]: Agree. Will modify it. Section 9.1: Might be better to split out requirements for a client and server into sepa= rate paragraphs (1st paragraph)? Might also be best to be clear that you ad= dress: 1. What a client must remember about its own increasing number (i.e., what = it sends to the server). 2. What a client must remember about the server's increasing number (i.e., = what it receives from server). 3. What a server must remember about a client's increasing number (i.e., wh= at it receives from client). 4. What a server must remember about its own increasing number (i.e., what = it sends to clients). I assume a server does NOT need to keep a unique incr= easing number set for each client it communicates with - a server can use o= ne set for all clients? Please also be clear about how each of these 4 (2 numbers on client, 2 on s= erver) are handled. The text presently is not very clear -- for example a c= lient can't forget what it sent if the server remembers it. [LS]: Yes, the server just need to keep one set for all clients. How about the following modified text? For client, it MUST remember about its own increasing number, which is stor= ed in the NUM.STO and sent to the server. And the client also MUST remember= about a server's increasing number, which is received from the server and = stored in the NUM.REC. And the client keeps a record of the increasing numb= er during the DHCPv6 configuration process with the DHCPv6 server. And the= client can forget the increasing number information after the transaction = is finished. The client's initial locally stored increasing number is set = to zero. For server, it MUST remember about its own increasing number, which is stor= ed in the NUM.STO and sent to the client. And the server also MUST remember= about a client's increasing number, which is received from the client and = stored in the Num.REC. The server just need to keep one increasing number s= et for all clients. Later, be clear that this is modulo 2^64 math: The Increasing-number option in the received message passes the increasing number check if NUM.REC is more than NUM.STO. And then, the value of NUM.STO is changed into the value of NUM.REC. The increasing number check fails if NUM.REC is equal with or less than NUM.STO. "More" here is in the modulo arithmetic "more" -- perhaps use "more (modulo= 2^64)" and "or less (modulo 2^64)"? [LS]: Agree, will modify it. Section 9.2: I wonder if you should revise the code to make it more appropriate for this= document? RDATA/RDLENGTH aren't really appropriate? [LS]: Got it. Will modify it. Section 10 There are now only three (not six) status codes. [LS]: Will correct it. Section 10.2 msg-type Identifier of the message type. It can be either Encrypted-Query (TBA7) or DHCPv6-Response (TBA8). Change DHCPv6-Response to Encrypted-Response. [LS]: Will correct it. Section 11 There are some mandatory algorithm for encryption algorithm in this Change (first) algorithm to algorithms? Or, change "are some" to "is a" [LS]: Will change it. Likewise, since the Encryption-Key-Tag Option isn't protected, an attacker that can intercept the message can forge the value without detection. Isn't this generally useless? As the message is encrypted, the validation w= ill fail? [LS]: If the encryption-key-tag is forged, then the server may cannot decry= pt it and drop the message. Some even more MINOR comments (these would perhaps improve readability but = would likely be addressed by the RFC editor): [LS]: Sorry for the poor expression. And thanks a lot your throughout check= . Will correct it in the next version. Section 6: Perhaps replace "contained" and "contain" with "included" and "include" in = the sentences later in that same paragraph (with the "The encryption text..= ."). For the received Encrypted-Response message, the client MUST drop the Encrypted-Response message if other DHCPv6 option except Encrypted- message option is contained. How about: For the received Encrypted-Response message, the client MUST drop the Encrypted-Response message if it contains any option other than a single Encrypted-message option. Note: There are some other odd uses of contain (when at least I think the t= ext should use include). But it may not be worth trying to change these (th= e usage is tricky - you can google for "english contain vs include" if you = like). We will leave it to the RFC editor to perhaps clean these up if appr= opriate. The client MAY use the AuthenticationFail as a hint and switch to other DHCPv6 server if it has another one. Change to "to another DHCP server if it has one"? Section 7: Upon the receipt of Encrypted-Query message, the server MUST drop the message if the other DHCPv6 option is contained except Server Here "the other" should change to "another". Note: There are several other places where contained/contain would (at leas= t in my mind) be more "standard" if the text used included/include. Same go= es for use of "other" (-> another). Last paragraph of section 7, "then the server set the". Set should be sets. Section 10.1.1 For EA-len, might be good to add "(must be a multiple of 2)" For SHA-len, might be good to add "(must be a multiple of 4)" Also, I think you should change all "2-octets value" to "2-octet value". Section 11 For this security item, It is RECOMMENDED that client certificates could be tied to specific server certificates by configuration. Lower case "It"? General There are uses of "cert" and "certs" and "certificate(s)". Are these one in= the same? Shouldn't we just use "certificate" throughout? Or perhaps you s= hould add "cert(s)" to terminology section? - Bernie -----Original Message----- From: dhcwg [mailto:dhcwg-bounces@ietf.org] = On Behalf Of Tomek Mrugalski Sent: Wednesday, March 08, 2017 8:37 AM To: dhcwg > Cc: draft-ietf-dhc-sedhcpv6 authors > Subject: [dhcwg] WGLC on draft-ietf-dhc-sedhcpv6-21 - Respond by March 29th Hi, draft-ietf-dhc-sedhcpv6-21 describes a mechanism for using public key crypt= ography to provide end-to-end security between DHCPv6 clients and servers. = The mechanism provides encryption in all cases, and can be used for authent= ication based on pre-sharing of authorized certificates. This draft has sta= rted in 2013, but the whole DHCPv6 security saga is much longer and begins = in 2008. This draft was submitted to IESG in mid-2015. The guidance received was clear that substantial changes are needed. As a = result, "encrypt everywhere, authenticate if you can" approach was used. Authors believe this draft to be ready for working group last call. Please send your substantial comments to the mailing list and express your = opinion whether this draft is ready for publication. Feel free to send nitp= icks and minor corrections to the authors directly. This is a complex draft= , so the chairs believe 3 weeks WGLC is in order. Please send your comments= no later than March 29th. Bernie and I will determine consensus and will d= iscuss during Chicago meeting as needed. To initiate the discussion, I have two related questions. The chairs would = love to hear your opinions on those. 1. The "encrypt everywhere" paradigm means that in deployments that do snoo= ping on relay will break down. To solve this problem, we need a assignment = notification mechanism, similar to the one described in draft-ietf-dhc-dhcp= v6-agentopt-delegate-04. That draft expired many years ago. This matter was= discussed in Seoul and the minutes describe the conclusion as: The discussion gravitated towards not resurrecting until the sedhcpv6 I-D progresses further. We will reevaluate this once sedhcpv6 is done. Do you want the WG to resurrect agentopt-delegate a) now, b) when sedhcpv6 is sent to IESG or c) when sedhcpv6 is published as RFC? d) we nee= d a completely new draft and I'm volunteering to work on it. 2. One of the authors suggested that this protocol is quite complex and hav= ing a feedback from an implementation (or ideally two interoperating) would= be very important and would likely result in some changes to the draft. It= 's probably too late for Chicago, but we can organize a sedhcpv6 hackathon in Prague. Two likely implementations would be WIDE and = Kea, as those two are open source and have an old version of the draft part= ially implemented. Do you think such a hackathon would be useful? Are you w= illing to participate? Title: Secure DHCPv6 Authors: L. Li, S. Jiang, Y.Cui, T.Jinmei, T.Lemon, D.Zhang Filename: draft-ietf-dhc-sedhcpv6-21 Pages: 31 Date: 2017-02-21 Link: https://datatracker.ietf.org/doc/draft-ietf-dhc-sedhcpv6/ Responses by March 29th are appreciated. Thanks, Bernie and Tomek _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg --_000_FBDB0F6800874488863FE5F0D45281BFciscocom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Regarding RFC5652, you will need to work with others to determine what= pieces are applicable - perhaps check in with Stephen to get more clarity = on what he intended? Perhaps Jinmei or Francis Dupont has some suggestions?=

- Bernie (from iPhone)

On Mar 30, 2017, at 3:49 AM, Lishan Li <lilishan48@gmail.com> wrote:

2017-03-27 22:07 GMT+08:00 Bernie Volz (volz= ) <volz@cisco.com&= gt;:

Hi:

 

The sentence: "The encryption text SHOULD be fo= rmatted as explain in [RFC5652]." Isn't clear. RFC5652 doesn't use &qu= ot;text" except to mean actual wording in the RFC. Could "encrypt= ion text" be clarified? Is this the client's message? Or what exactly is this and which part of RFC 5652 has this "format"? I = am not following what this sentence means and what I should do (if I were i= mplementing this).

Note: This same text is also in Section 7 (last paragraph) and needs simila= r attention.

[LS]: Sorry for the unclear expression. How about th= e following text?

The DHCPv6 message sent from the client is encrypted= and then encapsulated into the encrypted DHCPv6 message field according to= the Encrypted-Data content syntax defined in the RFC5652.

 

 
BV> I assume t=
his reference is to section 8 of RFC 5652. But now the question is whether =
anything further needs to be defined =96 for example, what (optional) attri=
butes should be included? Perhaps as I=92m not a security expert or have ca=
refully reviewed RFC5652 and am taking a few things =93out of content=94 wh=
en looking at it, but I think some clarity here may help in make sure this =
is easy to implement (especially for some of us that may not be experts in =
cryptography). This is a bit more complex than just taking the bytes of the=
 client=92s unencrypted message and the private key to encrypt (and placing=
 that into the Encrypted-message Option), and taking the encrypted client=
=92s message bytes (from a received Encrypted-message Option) and decryptin=
g with the public key? You may want to think about whether perhaps specifyi=
ng the details appropriate to DHCPv6 usage is appropriate =96 perhaps even =
in an appendix? RFC5652 talks about:

 

And there=92s a lot about ASN.1 and OIDs in RFC5652, so are you pulling in= all of this?

 

   The following object identifier i= dentifies the encrypted-data content

   type:

 

      id-encryptedDat= a OBJECT IDENTIFIER ::=3D { iso(1) member-body(2)

       &nbs= p;  us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6 }

 

   The encrypted-data content type s= hall have ASN.1 type EncryptedData:

 

      EncryptedData := :=3D SEQUENCE {

        ver= sion CMSVersion,

        enc= ryptedContentInfo EncryptedContentInfo,

        unp= rotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL }

 

   The fields of type EncryptedData = have the following meanings:

 

      version is the = syntax version number.  If unprotectedAttrs is

      present, then t= he version MUST be 2.  If unprotectedAttrs is

      absent, then ve= rsion MUST be 0.

 

      encryptedConten= tInfo is the encrypted content information, as

      defined in Section 6.1.

 

      unprotectedAttr= s is a collection of attributes that are not

      encrypted. = ; The field is optional.  Useful attribute types are

      defined in Section 11.

 

Probably section 6.1 is most applicable and there we have (eventually):=

 

    EncryptedContent ::=3D =
OCTET STRING

 

Which may be all we really need?

 

And, if so, what is the value in referencing this RFC?

 

Again, I=92m just trying to understand this more completely =96 what exact= ly is inside the Encrypted-message option?

 

 

[LS]: Yes, the reference is section 8 of RFC5652.
In the before version, Stephen suggested us to illustrate the format o= f the encrypted message data. He suggested to add the reference of RFC5652 = for it. 
But in fact, I don't know much about details of the draft.

 

[LS]: Yes, the server just need to keep one set for = all clients. 

How about the following modified text?=

For client, it MUST remember about its own increasin= g number, which is stored in the NUM.STO and sent to the server. And the cl= ient also MUST remember about a server's increasing number, which is receiv= ed from the server and stored in the NUM.REC. And the client keeps a record of the increasing number during the= DHCPv6 configuration process with the DHCPv6 server.  And the client = can forget the increasing number information after the transaction is finis= hed.  The client's initial locally stored increasing number is set to zero.

 

For server, it MUST remember about its own increasin= g number, which is stored in the NUM.STO and sent to the client. And the se= rver also MUST remember about a client's increasing number, which is receiv= ed from the client and stored in the Num.REC. The server just need to keep one increasing number set for all cl= ients.

 

BV> Here again, please be careful:

1.       If client always starts at 0, how does that help in preventing replay= ? And, this isn=92t consistent with the server=92s behavior above?

[LS]: For the first time that the client receives the increasing numbe= r, the client cannot compare it with the local number, and just to store it= .

2.       If client doesn=92t persist this, what happens if server has a lease = for the client (and has retained the replay numbers) but the client release= d (or otherwise deleted the lease). Now when the client Solicits (encrypted), the server would report that thi= s is a potential replay attach? I don=92t think dropping this information = =93after the transaction is finished=94 is possible.

[LS]: Yes, it is better for the client to retain the number it last us= ed with a server. For the devices without the persistent storage, the initi= al value of the increasing number is zero. After checking the increasing nu= mber in the Reply message, the NUM.STO is set to the NUM.REC. When sending the Solicit message, the increasing nu= mber is larger than the NUM.STO. So, the server will not report that this i= s a potential replay attack. 

3.       For =93The server just need to keep one increasing number set for all= clients=94 =96 shouldn=92t that be after the first sentence as this applie= s to NUM.STO; not NUM.REC?

Thus, I think the client must retain the number it last used with a server= . This seems to be an issue for devices without persistent storage, so may = require some further thought =96 or those devices cannot use increasing number?

[LS]: Agree, the client MUST retain the increasing number it last used= with a server. 

 

And, I think both having to retain this forever would be a bad idea. I thi= nk one could provide for both clients and servers to =93forget=94 any store= d information after a period of time (perhaps this can be a fixed number, 30 days, or should be some multiple of the lea= se lifetime)?

[LS]: So we can recommend a lifetime of the increasing number for the = client and server, such as 30 days. Could you please check my understanding= correct? 

 

 

   Likewise, since the Encryption-Key-Tag = Option isn't protected, an
   attacker that can intercept the message can forge the value wi= thout
   detection.

Isn't this generally useless? As the message is encrypted, the validation w= ill fail?

[LS]: If the encryption-key-tag is forged, then the = server may cannot decrypt it and drop the message.

 

BV> Right, but isn=92t that exactly what we would want? So, how is this= bad?

  

 

BV> Re Security Considerations - A new comment from a conversation with= Tomek (Tomek will hopefully comment more). I mentioned that I was concerne= d with the possibility of clients and servers getting =93junk=94 is a security concern as someone could generate bad pac= kets with encrypted data and send them to clients and servers in the hope t= o crash the either when they try to decrypt and then process junk. Tomek su= ggested we might want to think about whether to add some magic value to the first few bytes of a message before= encrypting it and then the decrypter can check those first few bytes to se= e if they are value and discard the message if not. Perhaps the encoding fr= om RFC5652 would accomplish this if we are using more than just the encryptedContent? Anyway, something to = think about.

[LS]: Agree. Perhaps the encoding from RFC5652 solves this problem.&nb= sp;
I think that it may be a general problem for all encryption protocol.&= nbsp;

 

 

Again, thanks for your continued efforts on this document!

 

[LS]: As the author of the draft, I have the responsibility to work on= it. Thanks a lot for your continued guidance on this. 

Best Regards,
Lishan

F= rom: Lishan Li <lilishan48@gmail.com= >
Date: Monday, March 27, 2017 at 12:33 AM
To: Bernie Volz <volz@cisco.com>
Cc: Tomek Mrugalski <tomasz.mrugalski@gmail.com>, "dhcwg@ietf.org" <dhcwg@ietf.org>, draft-ietf-dhc-sedhcpv6 authors <draft-ietf-dhc-sedhcpv6@ietf.org&g= t;
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-sedhcpv6-21 - Respond by= March 29th

 

Hi, Bernie,

 

Thanks a lot for your valuable comments. For the det= ails, please see inline.

 

Best Regards,

Lishan

 

2017-03-26 10:05 GMT+08:00 Bernie Volz (volz) &l= t;volz@cisco.com>= ;:

Hi:

I have reviewed the draft and support it moving forward. However, I do have= some issues I think need to be addressed but they are mostly fairly small.=

I do want to thank the authors for addressing my earlier issues. I think th= e document is in MUCH better shape now!!

So here goes ...

Section 6:
The sentence: "The encryption text SHOULD be formatted as explain in [= RFC5652]." Isn't clear. RFC5652 doesn't use "text" except to= mean actual wording in the RFC. Could "encryption text" be clari= fied? Is this the client's message? Or what exactly is this and which part of RFC 5652 has this "format"? I am not following wha= t this sentence means and what I should do (if I were implementing this).
Note: This same text is also in Section 7 (last paragraph) and needs simila= r attention.

[LS]: Sorry for the unclear expression. How about th= e following text?

The DHCPv6 message sent from the client is encrypted= and then encapsulated into the encrypted DHCPv6 message field according to= the Encrypted-Data content syntax defined in the RFC5652.

 


Section 7:

   option.  Then, the server checks the Server Identifier op= tion.  The
   DHCPv6 server drops the message that is not for it, thus not p= aying
   cost to decrypt messages.  If it is the target server, ac= cording to

I think here you also want the server to proceed if there is NO Server Iden= tifier option? It should only ignore it if there is a Server Identifier opt= ion and it does not match this server's identifier?

[LS]: Yes. Will modify it. 


Section 8

   those present in the innermost encapsulated messages from the = client
   or server.

I think messages should just be message as there is only one message?

[LS]: Agree. Will modify it. 


Section 9.1:

Might be better to split out requirements for a client and server into sepa= rate paragraphs (1st paragraph)? Might also be best to be clear that you ad= dress:
1. What a client must remember about its own increasing number (i.e., what = it sends to the server).
2. What a client must remember about the server's increasing number (i.e., = what it receives from server).
3. What a server must remember about a client's increasing number (i.e., wh= at it receives from client).
4. What a server must remember about its own increasing number (i.e., what = it sends to clients). I assume a server does NOT need to keep a unique incr= easing number set for each client it communicates with - a server can use o= ne set for all clients?
Please also be clear about how each of these 4 (2 numbers on client, 2 on s= erver) are handled. The text presently is not very clear -- for example a c= lient can't forget what it sent if the server remembers it.

[LS]: Yes, the server just need to keep one set for = all clients. 

How about the following modified text?=

For client, it MUST remember about its own increasin= g number, which is stored in the NUM.STO and sent to the server. And the cl= ient also MUST remember about a server's increasing number, which is receiv= ed from the server and stored in the NUM.REC. And the client keeps a record of the increasing number during the= DHCPv6 configuration process with the DHCPv6 server.  And the client = can forget the increasing number information after the transaction is finis= hed.  The client's initial locally stored increasing number is set to zero.

 

For server, it MUST remember about its own increasin= g number, which is stored in the NUM.STO and sent to the client. And the se= rver also MUST remember about a client's increasing number, which is receiv= ed from the client and stored in the Num.REC. The server just need to keep one increasing number set for all cl= ients.


Later, be clear that this is modulo 2^64 math:

   The Increasing-number option in the received message passes th= e
   increasing number check if NUM.REC is more than NUM.STO. = And then,
   the value of NUM.STO is changed into the value of NUM.REC.

   The increasing number check fails if NUM.REC is equal with or = less
   than NUM.STO.

"More" here is in the modulo arithmetic "more" -- perha= ps use "more (modulo 2^64)" and "or less (modulo 2^64)"= ?

[LS]: Agree, will modify it. 


Section 9.2:

I wonder if you should revise the code to make it more appropriate for this= document? RDATA/RDLENGTH aren't really appropriate?

[LS]: Got it. Will modify it. 


Section 10

There are now only three (not six) status codes.

[LS]: Will correct it. 


Section 10.2

   msg-type        Identifier of the message = type.  It can be either
                   Encryp= ted-Query (TBA7) or DHCPv6-Response (TBA8).

Change DHCPv6-Response to Encrypted-Response.

[LS]: Will correct it. 



Section 11

   There are some mandatory algorithm for encryption algorithm in= this

Change (first) algorithm to algorithms? Or, change "are some" to = "is a"

[LS]: Will change it. 



   Likewise, since the Encryption-Key-Tag Option isn't protected,= an
   attacker that can intercept the message can forge the value wi= thout
   detection.

Isn't this generally useless? As the message is encrypted, the validation w= ill fail?

[LS]: If the encryption-key-tag is forged, then the = server may cannot decrypt it and drop the message.



Some even more MINOR comments (these would perhaps improve readability but = would likely be addressed by the RFC editor):

[LS]: Sorry for the poor expression. And thanks a lo= t your throughout check. Will correct it in the next version. <= u>


Section 6:

Perhaps replace "contained" and "contain" with "in= cluded" and "include" in the sentences later in that same pa= ragraph (with the "The encryption text...").


   For the received Encrypted-Response message, the client MUST d= rop the
   Encrypted-Response message if other DHCPv6 option except Encry= pted-
   message option is contained.

How about:

   For the received Encrypted-Response message, the client MUST d= rop the
   Encrypted-Response message if it contains any option other tha= n a single
   Encrypted-message option.

Note: There are some other odd uses of contain (when at least I think the t= ext should use include). But it may not be worth trying to change these (th= e usage is tricky - you can google for "english contain vs include&quo= t; if you like). We will leave it to the RFC editor to perhaps clean these up if appropriate.


      The client MAY use the AuthenticationFail as a hint an= d switch
      to other DHCPv6 server if it has another one.

Change to "to another DHCP server if it has one"?

Section 7:

   Upon the receipt of Encrypted-Query message, the server MUST d= rop the
   message if the other DHCPv6 option is contained except Server<= br>
Here "the other" should change to "another".

Note: There are several other places where contained/contain would (at leas= t in my mind) be more "standard" if the text used included/includ= e. Same goes for use of "other" (-> another).

Last paragraph of section 7, "then the server set the". Set shoul= d be sets.

Section 10.1.1

For EA-len, might be good to add "(must be a multiple of 2)"
For SHA-len, might be good to add "(must be a multiple of 4)"

Also, I think you should change all "2-octets value" to "2-o= ctet value".

Section 11

   For this security item, It is RECOMMENDED that client certific= ates
   could be tied to specific server certificates by configuration= .

Lower case "It"?


General

There are uses of "cert" and "certs" and "certific= ate(s)". Are these one in the same? Shouldn't we just use "certif= icate" throughout? Or perhaps you should add "cert(s)" to te= rminology section?


- Bernie

-----Original Message-----
From: dhcwg [mailto:dhcwg-bounces@ietf.org= ] On Behalf Of Tomek Mrugalski
Sent: Wednesday, March 08, 2017= 8:37 AM
To: dhcwg <dhcwg@ietf.org>
Cc: draft-ietf-dhc-sedhcpv6 aut= hors <draft-ietf-dhc-sedhcpv6@ietf.org>
Subject: [dhcwg] WGLC on draft-= ietf-dhc-sedhcpv6-21 - Respond by March 29th

Hi,
draft-ietf-dhc-sedhcpv6-21 describes a mechanism for using public key crypt= ography to provide end-to-end security between DHCPv6 clients and servers. = The mechanism provides encryption in all cases, and can be used for authent= ication based on pre-sharing of authorized certificates. This draft has started in 2013, but the whole DHC= Pv6 security saga is much longer and begins in 2008. This draft was submitt= ed to IESG in mid-2015.
The guidance received was clear that  substantial changes are needed. = As a result, "encrypt everywhere, authenticate if you can" approa= ch was used.

Authors believe this draft to be ready for working group last call.

Please send your substantial comments to the mailing list and express your = opinion whether this draft is ready for publication. Feel free to send nitp= icks and minor corrections to the authors directly. This is a complex draft= , so the chairs believe 3 weeks WGLC is in order. Please send your comments no later than March 29th. Bern= ie and I will determine consensus and will discuss during Chicago meeting a= s needed.

To initiate the discussion, I have two related questions. The chairs would = love to hear your opinions on those.

1. The "encrypt everywhere" paradigm means that in deployments th= at do snooping on relay will break down. To solve this problem, we need a a= ssignment notification mechanism, similar to the one described in draft-iet= f-dhc-dhcpv6-agentopt-delegate-04. That draft expired many years ago. This matter was discussed in Seoul and the m= inutes describe the conclusion as:

  The discussion gravitated towards not resurrecting until the sedhcpv= 6
  I-D progresses further. We will reevaluate this once sedhcpv6 is don= e.

Do you want the WG to resurrect agentopt-delegate a) now, b) when
sedhcpv6 is sent to IESG or c) when sedhcpv6 is published as RFC? d) we nee= d a completely new draft and I'm volunteering to work on it.

2. One of the authors suggested that this protocol is quite complex and hav= ing a feedback from an implementation (or ideally two interoperating) would= be very important and would likely result in some changes to the draft. It= 's probably too late for Chicago, but we can organize a
sedhcpv6 hackathon in Prague. Two likely implementations would be WIDE and = Kea, as those two are open source and have an old version of the draft part= ially implemented. Do you think such a hackathon would be useful? Are you w= illing to participate?

Title: Secure DHCPv6
Authors: L. Li, S. Jiang, Y.Cui, T.Jinmei, T.Lemon, D.Zhang
Filename: draft-ietf-dhc-sedhcpv6-21
Pages: 31
Date: 2017-02-21
Link: https://datatracker.ietf.org/doc/draft-ietf-dhc-sedhcpv6/

Responses by March 29th are appreciated.

Thanks,
Bernie and Tomek

_______________________________________________=
dhcwg mailing list
dhcwg@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dhcwg

 


--_000_FBDB0F6800874488863FE5F0D45281BFciscocom_-- From nobody Thu Mar 30 08:00:47 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE6712952F for ; Thu, 30 Mar 2017 08:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 tkntmA3OsqTH for ; Thu, 30 Mar 2017 08:00:41 -0700 (PDT) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F08A129512 for ; Thu, 30 Mar 2017 08:00:39 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id y18so77859668itc.1 for ; Thu, 30 Mar 2017 08:00:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=1TaDDhiqtE8SeRrOzUbr1fF9pPMmIwS7AwGSK6AmdGQ=; b=MHhAEMuLyeeQLDsrAlG3wj6VUd9jM2ELxaLzsgM/KjVyY+LZM6Li4NQn1b0o17d1N2 ZePDrfg3ogopAokFBMU6zhx2L9wPAkOcfQ5x78IHLS1bBGG+iloJlSN7CU1vjMFAHr9N /KoB3RTBlTNV2z1dN2sJK3eX/+tQaguVgYPFaAf+QFL7dRRRBitYOOupWqx2+79+0+d8 5CM2EZ8477vONCXUh6XLgin9jMe9aUVIFQgHxAzpY+LsceFMhtSSDxNq5LMBFsek4nMf btF49yAFQBttHm+et4d9cUDCkhZhTbHNAUdSALkYJB5ERpOtfle1zmm/MiaTW5VzVHWk NwPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=1TaDDhiqtE8SeRrOzUbr1fF9pPMmIwS7AwGSK6AmdGQ=; b=dfhaikisy8ZWj2LrP3FyqJxaXoNa87wOp8l6FZkgL2a3USWkHAnQZH49garj0apxNg Mx1wwOzZO0qZpCkTCt7g9QZ/FoCHFR0w/xIzTG0D/TGB0xY73m9eD8Q5gaTS5nJ6EQvU 3d9nAi/RYJUPFVgq5VfDt386ptlzkQf3n45rjciTqpJPDskZkhODNQRYwjfWLwWMapsc GDk8lxtU3IHAeTSBI/aBDbCV+3qXWQiEHbMVMT4MAjLwkhmd/7I6qAk9b3W0lGXWYL0l Bm91PX/OAom0q+1tV7bZvkUFLSuZvtfvLo+WZD1TKfKVdP8ItWNyYDK/+aTVZzE4+GFO ycQg== X-Gm-Message-State: AFeK/H2MtygfY0hS9jTHd5Phvz8UvpCnovOR6JmZeE/9V1x560QFd3nXy0XOuRZ4E7trIA== X-Received: by 10.36.200.8 with SMTP id w8mr887568itf.112.1490886038617; Thu, 30 Mar 2017 08:00:38 -0700 (PDT) Received: from t2001067c0370199861d1a9fa7f011c21.v6.meeting.ietf.org (t2001067c0370199861d1a9fa7f011c21.v6.meeting.ietf.org. [2001:67c:370:1998:61d1:a9fa:7f01:1c21]) by smtp.gmail.com with ESMTPSA id 89sm1460323ioj.17.2017.03.30.08.00.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Mar 2017 08:00:37 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_786A39B7-7DD1-406C-8D13-EDEE63E130A9" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 30 Mar 2017 10:00:36 -0500 In-Reply-To: Cc: Lishan Li , dhcwg , draft-ietf-dhc-sedhcpv6 authors To: "Bernie Volz (volz)" References: <7db55e6f55e34408a1816887c22e28d3@XCH-ALN-003.cisco.com> <369C97B6-B6E7-46CE-B42E-18559BFB1E78@cisco.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-sedhcpv6-21 - Respond by March 29th X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 15:00:44 -0000 --Apple-Mail=_786A39B7-7DD1-406C-8D13-EDEE63E130A9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Mar 30, 2017, at 9:34 AM, Bernie Volz (volz) wrote: > - What about verifying the certificate's time? A client might not have = current time and so may not be able to determine if certificate has = expired?=20 Clients that don't have the current time don't get very good security. = I don't know of a way to fix this. At a minimum, a client with no = clock and stable store should at least remember its last boot time every = so often (maybe not every boot, to avoid flash wear, but maybe at least = once a month). This will make it difficult to replay really old certs. = But it's pretty thin. --Apple-Mail=_786A39B7-7DD1-406C-8D13-EDEE63E130A9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Mar 30, 2017, at 9:34 AM, Bernie Volz (volz) <volz@cisco.com> = wrote:
- = What about verifying the certificate's time? A client might not have = current time and so may not be able to determine if certificate has = expired? 

Clients = that don't have the current time don't get very good security.   I = don't know of a way to fix this.   At a minimum, a client with no = clock and stable store should at least remember its last boot time every = so often (maybe not every boot, to avoid flash wear, but maybe at least = once a month).   This will make it difficult to replay really old = certs.   But it's pretty thin.


= --Apple-Mail=_786A39B7-7DD1-406C-8D13-EDEE63E130A9-- From nobody Thu Mar 30 08:21:16 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3F88127419 for ; Thu, 30 Mar 2017 08:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=s-carlsen.dk 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 Vw81eudKu1Sw for ; Thu, 30 Mar 2017 08:21:11 -0700 (PDT) Received: from mail2.s-carlsen.dk (xd93ddd80.cust.hiper.dk [217.61.221.128]) by ietfa.amsl.com (Postfix) with ESMTP id E0EBA1242EA for ; Thu, 30 Mar 2017 08:21:10 -0700 (PDT) Received: from mail3.s-carlsen.dk (think.s-carlsen.dk [192.168.16.20]) by mail2.s-carlsen.dk (Postfix) with ESMTP id 30CC4400BC for ; Thu, 30 Mar 2017 17:20:57 +0200 (CEST) Received: from silver4.local (unknown [192.168.16.241]) by mail3.s-carlsen.dk (Postfix) with ESMTPA id 042CBC1FE097 for ; Thu, 30 Mar 2017 17:21:07 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 mail3.s-carlsen.dk 042CBC1FE097 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=s-carlsen.dk; s=20170103-s-dk; t=1490887268; bh=Rmvermdvahf8wVvDB1gzTfifmWcODuovshyco4lyYyQ=; h=Subject:To:References:From:Date:In-Reply-To:From; b=ktOvDIwQM024RkGhYMORmpRxrNUniSeauK5zn384FyTtDmJRnZw3W+zRpibzD0xKA WnuprbO4u9eFIfa+p1cEd1P40ZlddHAYFqXzxwblCsbFJPm+j3c18zRGiPL0SVDLf0 e8As/FzXK+yI4FA9yolOfDPVMKUaTcSbUa5oeEYQ= To: dhcwg@ietf.org References: <7db55e6f55e34408a1816887c22e28d3@XCH-ALN-003.cisco.com> <369C97B6-B6E7-46CE-B42E-18559BFB1E78@cisco.com> From: Sten Carlsen Message-ID: <6c0c02df-209a-bdd2-fa45-0e9f448821e4@s-carlsen.dk> Date: Thu, 30 Mar 2017 17:21:30 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------357134120EE4D8B32128C965" Archived-At: Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-sedhcpv6-21 - Respond by March 29th X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 15:21:14 -0000 This is a multi-part message in MIME format. --------------357134120EE4D8B32128C965 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Sorry for late comment but this just caught my attention. >> BV> Re Security Considerations - A new comment from a >> conversation with Tomek (Tomek will hopefully comment more). I >> mentioned that I was concerned with the possibility of clients >> and servers getting “junk” is a security concern as someone could >> generate bad packets with encrypted data and send them to clients >> and servers in the hope to crash the either when they try to >> decrypt and then process junk. Tomek suggested we might want to >> think about whether to add some magic value to the first few >> bytes of a message before encrypting it and then the decrypter >> can check those first few bytes to see if they are value and >> discard the message if not. Perhaps the encoding from RFC5652 >> would accomplish this if we are using more than just the >> encryptedContent? Anyway, something to think about. >> >> [LS]: Agree. Perhaps the encoding from RFC5652 solves this problem. >> I think that it may be a general problem for all encryption protocol. If someone deliberately wants to make bad packets with the purpose of causing problems, they would be smart enough to add the same magic number? Knowing the encryption algorithms would allow more deliberate attempts to cause overflow etc. I don't see any other method than careful programming and careful testing with deliberate intent to find weak spots. If we talk about noise or other non-intentional bad/random packet, then a magic number will help. -- Best regards Sten Carlsen No improvements come from shouting: "MALE BOVINE MANURE!!!" --------------357134120EE4D8B32128C965 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Sorry for late comment but this just caught my attention.

BV> Re Security Considerations - A new comment from a conversation with Tomek (Tomek will hopefully comment more). I mentioned that I was concerned with the possibility of clients and servers getting “junk” is a security concern as someone could generate bad packets with encrypted data and send them to clients and servers in the hope to crash the either when they try to decrypt and then process junk. Tomek suggested we might want to think about whether to add some magic value to the first few bytes of a message before encrypting it and then the decrypter can check those first few bytes to see if they are value and discard the message if not. Perhaps the encoding from RFC5652 would accomplish this if we are using more than just the encryptedContent? Anyway, something to think about.

[LS]: Agree. Perhaps the encoding from RFC5652 solves this problem. 
I think that it may be a general problem for all encryption protocol. 
If someone deliberately wants to make bad packets with the purpose of causing problems, they would be smart enough to add the same magic number? Knowing the encryption algorithms would allow more deliberate attempts to cause overflow etc.

I don't see any other method than careful programming and careful testing with deliberate intent to find weak spots.

If we talk about noise or other non-intentional bad/random packet, then a magic number will help.

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

       "MALE BOVINE MANURE!!!"
--------------357134120EE4D8B32128C965-- From nobody Thu Mar 30 11:00:25 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26062129420; Thu, 30 Mar 2017 11:00:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 z2uelE8YZ68n; Thu, 30 Mar 2017 11:00:20 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14D38128D19; Thu, 30 Mar 2017 11:00:20 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id e75so117746389itd.1; Thu, 30 Mar 2017 11:00:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=tio7J7p31Rqs9DzDXRe+pz4KWQEMw1YsK+uWb3FlS/0=; b=tyeQzUomxSoXbsSwee4GYzFC0xcuOmCVUa85TgBzn+VwfBg6sg1F1ocPUyMVLTFGZc QRC6BSQ2KCrrzOH3j7EHGaN4dEZsSrxCpnPBma+wBbtutwMtHjN4NRG8jI4KDrDTxyAL jqrvMhijWiGfO9jG2ufY9uSIaEnvKZvIZ2kIwZiAP9Ie6eQjx7EEVUeLHiD+ccr0JeSZ cZwQTwVzg4UyT8KGju4+QoA+VIoy/U3jiaU2RoVyuONuyr69e2rWRGvaZlyVWVA7qQz4 T8DTsoKoWzcQoVMz7Fh4gXlewcvhM5IbBfs+2ivX1V7233HA8dxfZqapyGKVIY3omyeN 7jhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=tio7J7p31Rqs9DzDXRe+pz4KWQEMw1YsK+uWb3FlS/0=; b=FCGrkSKa69o2tCCQ3ZIJiUh28JpraWjmOTBw9V3RPtg6hi7yuiXJONSk08Y1w67ux6 m75+/dRK8LSdYY9o4xHxVlGvw1BEl8c4Bm0w4AoycVVkCEOKPaBN09jOTi9MFnKmIVnz GhEHh2+WQ4hgLSaE9ZnC+sJH48tnzGfy3zlG3Suy+j4BrAuKFRw2nd4Fxu4dvv15NHlD M68W/CQVzFvAptx62aiFNA3a1lItDq8bQZ7q9tMQgWtFRO/08qI0o6eMHy44tFmDUolc uKp/vULsBqQ14anoGa2OCZnMfZYPclGbEWuAWiOi3+25fXskurhm38gjWXkFp1nIO+BZ V7lw== X-Gm-Message-State: AFeK/H0fgmBuJs4XbTFIvRZ5WjMe4em2NVccJNzEvFS+kFc6zhXiLtIhEl37R82wgeIRxw== X-Received: by 10.36.67.209 with SMTP id s200mr1918125itb.37.1490896819018; Thu, 30 Mar 2017 11:00:19 -0700 (PDT) Received: from voyager2.local (107-1-12-170-ip-static.hfc.comcastbusiness.net. [107.1.12.170]) by smtp.googlemail.com with ESMTPSA id l198sm1734913ita.10.2017.03.30.11.00.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Mar 2017 11:00:18 -0700 (PDT) To: "Templin, Fred L" , dhcwg References: Cc: draft-ietf-dhc-sedhcpv6 authors From: Tomek Mrugalski Message-ID: Date: Thu, 30 Mar 2017 13:00:33 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-sedhcpv6-21 - Respond by March 29th X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 18:00:23 -0000 I have reviewed the draft and in my opinion -21 is in great overall shape. The text reads so much better, the concept is clearly explained early and the whole text fits together well. I do have many comments, but great majority of them are clarifications and editorial corrections. Good work, authors! Ok, let's start with easy ones. idnits. There are a number of idnits errors and warnings: 3 errors (**), 0 flaws (~~), 8 warnings (==), 5 comments (--).. Please fix them. Ping me off the list if you need a little help with idnits tool. This draft defines a set of recommendations for secure environment. It is not expected to be used by all DHCP implementations is every deployment, just those who are interested in improved security. In certain way it is very similar to anonymity profile. Anonymity profile defined set or rules that are not expected to be used by all DHCP implementations in every deployment, just those who are interested in improved privacy. So maybe it should be called Security Profile for DHCPv6? I think this approach does not change anything from technical perspective, but simply frames the solution better. Described that way it may also be easier to accept to people who may afraid we want to force everyone to encrypt everything everywhere. It's just a suggestion to consider, I don't insist on it if authors or the WG disagree. I like section 5, especially 5.1 and 5.2 a lot. It's a great two-page intro to the concept. Section 5.3 nit: mainly a algorithm => mainly an algorithm Section 5.4 should also discuss the problem with Confirm message mentioned earlier by Jinmei. Section 5.5 nit: In some scenario => In some scenarios Section 6 nit: is a Increasing-number option => is an Increasing-number option Section 6: Is Advertise protected as well? I think it definitely should be to the maximum extent possible. Once the initial info-request/reply is completed, the next step for the client is to send Solicit wrapped in Encryption-Query. The server will reply with Advertise wrapped in Encryption-Response. At this stage the received Advertise can be validated. Maybe not all of the checks are possible yet for Advertise, because of not all necessary information is available yet (e.g. there's not possible to do the increasing number check as this is the first packet coming back and the client doesn't have previous value to check it against), but some checks are definitely applicable (e.g. drop because signature is missing, multiple signatures or certificate missing). Unless there's a good reason to not do it, the rules described in on page 9 should apply to both Advertise and Reply. "beat out a busy "real" server" => "beat out a busy legitimate server" There is this text: "The Certificate option MUST be constructed as explained in Section 10.1.2.", but I don't see any "client MUST send Certificate option". It's also not shown on Figure 1. Yet, the server section says that incoming messages without Certificate option are to be dropped. This should be clarified. It's a matter of preference, but I think Section 6 is too long and should be split into several sub-sections. When someone references it ("see Section 6"), it's difficult to find what specific parts of the text is being pointed out to. "the subsequent encrypted DHCPv6 message sent from the client can also contain the Increasing-number option to defend against replay attack.". Is there a reason why "can" is used, not SHOULD or even MUST? "If the transaction-id is 0, the client also try to decrypt it." Two comments about this. First, what is the client supposed to decrypt - the transaction-id field or the whole message? Second, what should the client do if it's not 0? "In this document, it is assumed that the client will not have multiple DHCPv6 sessions with different DHCPv6 servers using different key pairs and only one key pair is used for the encrypted DHCPv6 configuration process." That's a good text, but it doesn't belong in the place where it is now. It should be moved to separate paragraph or even separate section. You may also consider adding something like "Secure DHCPv6 can maintain multiple DHCPv6 sessions, but such scenario is not considered here for clarity reasons." "The encryption text SHOULD...". What is encryption text? Did you mean encrypted message or the message to be encrypted? nit: "as explain in [RFC5652]" => "as explained in [RFC5652]" "After the decryption, it handles the message as per 3315". I'm not a security expert by any stretch of that word, so excuse my naive question. Anyway, can you always detect that the decryption was a success or failure? Some decryption techniques will produce output, even when the key is incorrect, but the output will be an almost random garbage. Can the mechanism defined in RFC5652 always reliably conclude the decoding operation was success/failure? If not, I'm afraid that asking clients and server to decode random garbage will break some implementations. If the decryption algorithm cannot give definite success/fail answer, there's a solution I have in mind. You may add a magic cookie (a well known value of perhaps 4 bytes) at the beginning before encrypting the actual message and encrypt (cookie,message) tuple. Then the first check after decryption the receiver would do is to check if the first 4 bytes match the cookie value. If not, then throw away the whole packet without trying to parse any of it. I discussed the concept with Bernie and he's in favour of it. Also discussed with Jinmei and he's against it. Sten posted his comment against it, but I'm not sure if Bernie's description of the concept was accurate enough. Any other thoughts on this? "switch to other DHCPv6 server if it has another one." => "switch to other DHCPv6 server if available." The text uses "one and only one" several times. You may consider replacing it with "exactly one". It reads easier that way, but I admit it's a matter of preference, so it's just a suggestion. "The DHCPv6 server drops the message that is not for it, thus not paying cost to decrypt messages." => "The DHCPv6 server drops the message if the value of Server Identifier option does not match its own, thus not paying the cost of message decryption." "If the server cannot find the corresponding private key of the key tag or the corresponding private key of the key tag is invalid for decryption, then the server drops the received message." Shouldn't the server send back AuthenticationFail status? The benefit is that the client could try again and use a different certificate. "For the signature failure, the server SHOULD send an encrypted Reply message with an UnspecFail (value 1, [RFC3315]) error status code to the client." Why use UnspecFail, if there's SingatureFail code for it? General comment: "cert" should be replaced with "certificate". Even though everyone understands this jargon, it should be avoided in formal documents. Section 9.1: nit: "The server should keep a record of the increasing number forever." Nothing is eternal, so I don't like the word forever. It would be better to say the server must be able to retain the increasing number across restarts. Remove "And " at the beginning of two sentences in first paragraph. Section 9.2: Thanks a lot for including the code. It's very helpful. However, please update the comments that mention RDATA, DNSKEY RR and RDLENGTH. That way fewer people will realized where it was borrowed from :) Nit: some of the values to be assigned by IANA are boilerplated as TBD[number] and some as TBA[number]. Typically it's TBD[number]. Section 10.1.1 The text describing EA-id List could use an update. First, it's not clear what EA stands for (it is explained further down, but requires a bit of hopping around the text). I would replace "EA-id: The format of the EA-id List field is shown in Figure 3." with "EA-id List: Contains a list of supported Encryption Algorithm identifiers. The format of the EA-id List field is shown in Figure 3." Similar text should be added for SHA-id List ("Contains a list of supported Signature/Hash Algorithm pairs."). Nit: I'm not sure, but it looks like you put the whole description of EA-id into the Figure 3. It's better to have it as text outside of Figure. That's probably also one of the reasons why idnits is unhappy. 10.1.2 "The Certificate option carries the certificate of the client/server, which is contained in the Reply message." This is confusing. I could easily misinterpret this as "server is supposed to send client certificate in Reply message" or even "Client can send Reply message with a certificate". It would be better to say "The Certificate option carries the certificate of the sender. It can be included by the client (see Section 6) and by the server (see Section 7)." Also, see my earlier comment about Section 6 not explicitly saying if/when the Certificate option is to be sent. Sections 10.1.* As a convenience to the reader, I would add a text similar to "The Algorithm option is sent by the client, as described in Section 6.". Similar texts should be added in other sections that describe the options. It can be confusing to understand who sends what, so such pointers are useful in my opinion. This applies to all sections that describe options. Section 10.2 "share the following format:" => "share the standard format of DHCPv6 messages:". Section 11 "There are some mandatory algorithm for encryption algorithm in this document. It may be at some point that the mandatory algorithm is no longer safe to use." => "There are some mandatory algorithms specified in this document. It may be at some point that the mandatory algorithm is no longer safe to use. To mitigate this problem, an extension mechanism was defined that allows usage of new encryption, signing and hash algorithms." Another problem that should be mentioned is that secure traffic cannot be snooped by the relay agents. This is of crucial importance for networks that use PD and use relay snooping. It would be even more appropriate to create separate section called Deployment Considerations for it. If the RAAN draft is resurrected before sedhcpv6 reaches IESG (it should), adding text similar to "This issue will be addressed in future IETF work and add reference to draft-ietf-dhc-dhcpv6-agentopt-delegate). Another possible topic for discussion in deployment considerations would be how to do Rebind. My understanding is that it would work as long as both servers would use the same certificates. This explanation is buried deep in section 5.4, but it's probably useful to mention it explicitly (or have a pointer to 5.4) if you decide to create deployment considerations section. Section 12 Do you (that's a broad question to the WG, not just authors) think it would be useful to add extra column to the new registries, specifying whether the protocol is mandatory, optional or deprecated? We would start with one mandatory in each registry and all other entries being optional. When new protocols are defined in the future and flaws in existing ones are discovered, we could publish short documents to easily update the current state of affairs. It would also correlate well with the text you have in section 11. I agree with Jinmei-san that the Confirm message problem is something that should be tackled. I don't have any ready to use solution for you, but going in the direction that Jinmei suggested (doing separate inf-request/reply to discover available servers) seems the best way. Finally, to answer my own question I think dhc-dhcpv6-agentopt-delegate should be resurrected right now, so sedhcpv6 could reference to it, when it discusses the issue with snooping. This is something I hope to discuss in couple hours during meeting. Ok, that's it. Tomek From nobody Fri Mar 31 23:10:31 2017 Return-Path: X-Original-To: dhcwg@ietf.org Delivered-To: dhcwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DBDF124BFA; Fri, 31 Mar 2017 23:10:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dhcwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149102702327.4301.11902881693182642324@ietfa.amsl.com> Date: Fri, 31 Mar 2017 23:10:23 -0700 Archived-At: Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-06.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Apr 2017 06:10:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration of the IETF. Title : DHCPv6 Prefix Length Hint Issues Authors : Tianxiang Li Cong Liu Yong Cui Filename : draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-06.txt Pages : 9 Date : 2017-03-31 Abstract: DHCPv6 Prefix Delegation (RFC3633) allows a client to include a prefix-length hint value in the IA_PD option to indicate a preference for the size of the prefix to be delegated, but is unclear about how the client and server should act in different situations involving the prefix-length hint. This document provides a summary of the existing problems with the prefix-length hint and guidance on what the client and server could do in different situations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-prefix-length-hint-issue/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-06 https://datatracker.ietf.org/doc/html/draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Mar 31 23:18:41 2017 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B347127977 for ; Fri, 31 Mar 2017 23:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 T5lqX9QX-e_v for ; Fri, 31 Mar 2017 23:18:37 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7B70126DC2 for ; Fri, 31 Mar 2017 23:18:36 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id f193so82032964oib.2 for ; Fri, 31 Mar 2017 23:18:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=aWkYiEdll4JxZJqzSlBcrJEj4fwbctI8CgjgQeKz6kg=; b=Sx/ZpuoeRZ7zjVTfQzdbXL3PUtU9ALQjmjjL0kfsEf66OVJkh17nWSYXwwUXnHMS1j 9ir1HRhHNTgz5DEVcul0Jza9Yzn1+EBJzTQjIG4mP73OR/239MI9RjgTSxP/OPnNh+2U Y2jTQJrTM+Bq5RgGyOdj2VpP/ZnyNf+4Q3mxQRLUDAnP6p088vj9UAypNztzGrW9CwGf 3YE6GYOyU30o6sf1wnKBguOAUdIy6HZu6YGkXVHxorOSo/VEHcAITMQkLMofCZ8S/KK6 lWTwEVHf2Bnhr4srH1jGbkejY/pNyky6nwGCSyUuar+VP5fRE2svewBLWES3BKdTwEMh a4IQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=aWkYiEdll4JxZJqzSlBcrJEj4fwbctI8CgjgQeKz6kg=; b=K6ffSK6nnXGb9WPFvYjFPLuQWTQGDT7YlZw7wzXAM/RMJUDBdf+3gaVAwEmk7/NqSF Jb3d9zhcPJuaqD1cueS0c2SnKyZtDSqrCIB+aINgsrh/Ajwq8lgH7RyPwsZST8N35TuY 95ywJUn7PJ4EazyRth4MlNO4QMkZdmciRB2ZeY/RxrOdWR9LeNA3YRz2wYYIoXLUOF5O ut6tdBdzwUc87Nn5Vlu5NSKl4wTone1Q53qEXjOuJLrFWlvUWrvjuGx1sx8aIZICm9gN Uu2CvRxyEf9XmZzjOKsDjd/jby29DPgufzHbiuqPh7+TXY6MiTyJmNgAURU2aX0Nnzyj DX6w== X-Gm-Message-State: AFeK/H0+AFgDghONaUoArGbzXyHnoUUI7uAFa8mvAsNx2QbB4N/vwDMO1lCC5E3+yxeyPIk7bY3rkMPTklxekA== X-Received: by 10.202.253.5 with SMTP id b5mr4143638oii.156.1491027516155; Fri, 31 Mar 2017 23:18:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.172.151 with HTTP; Fri, 31 Mar 2017 23:17:55 -0700 (PDT) In-Reply-To: <149102702351.4301.3823975686585382508.idtracker@ietfa.amsl.com> References: <149102702351.4301.3823975686585382508.idtracker@ietfa.amsl.com> From: tianxiang li Date: Sat, 1 Apr 2017 14:17:55 +0800 Message-ID: To: dhcwg Content-Type: multipart/alternative; boundary=001a113d2362736c0e054c14e516 Archived-At: Subject: [dhcwg] Fwd: New Version Notification for draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-06.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Apr 2017 06:18:40 -0000 --001a113d2362736c0e054c14e516 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi all, We've updated a new version of draft-ietf-dhc-dhcpv6-prefix-length-hint-iss= ue (version 06) according to the comments received during IESG Last Call. Main changes include: 1. Changed text at the end of the first and second paragraph of the =E2=80=9CSolution=E2=80=9D part of section 3.2. OLD: If the server does not have a prefix with length matching the prefix-length hint value, then the server SHOULD provide the prefix with the shortest length possible which is closest to the prefix-length hint value. NEW: If the server does not have a prefix with length matching the prefix-length hint value, then the server SHOULD provide the prefix whose length is shorter and closest to the prefix-length hint value. 2. Added text at the last paragraph of the =E2=80=9CSolution=E2=80=9D part = of section 3.2, to describe what the server should do if it cannot provide any prefixes to the client. 3. Changed option 4 of the =E2=80=9CSolution=E2=80=9D part of section 3.5: OLD: Assign the original delegated prefix with 0 preferred-lifetime, a short non-zero valid-lifetime... NEW: Assign the original delegated prefix with 0 preferred-lifetime, a specific non-zero valid-lifetime depending on actual requirement... 4. Added reference to RFC3315 in section 4 for security considerations in DHCP 5. Added a sentence at the end of section 3.1 to explain that there is no requirement for the order of the two IAPREFIX options. 6. Expanded the words =E2=80=9CIAID=E2=80=9D and =E2=80=9CIA_PD=E2=80=9D on= first use in the second paragraph of the =E2=80=9CProblem=E2=80=9D part of section 3.1: IAID (Identity Association IDentifier) IA_PD (Identity Association for Prefix Delegation) 7. Throughout the draft, changed =E2=80=9Cthe prefix which length is=E2=80= =9D to =E2=80=9Cthe prefix whose length is=E2=80=9D. Thank you, Tianxiang ---------- Forwarded message ---------- From: Date: 2017-04-01 14:10 GMT+08:00 Subject: New Version Notification for draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-06.txt To: Cong Liu , Yong Cui = , Tianxiang Li A new version of I-D, draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-06.txt has been successfully submitted by Tianxiang Li and posted to the IETF repository. Name: draft-ietf-dhc-dhcpv6-prefix-length-hint-issue Revision: 06 Title: DHCPv6 Prefix Length Hint Issues Document date: 2017-03-31 Group: dhc Pages: 9 URL: https://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6- prefix-length-hint-issue-06.txt Status: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6- prefix-length-hint-issue/ Htmlized: https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-prefix- length-hint-issue-06 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-dhc- dhcpv6-prefix-length-hint-issue-06 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-dhcpv6- prefix-length-hint-issue-06 Abstract: DHCPv6 Prefix Delegation (RFC3633) allows a client to include a prefix-length hint value in the IA_PD option to indicate a preference for the size of the prefix to be delegated, but is unclear about how the client and server should act in different situations involving the prefix-length hint. This document provides a summary of the existing problems with the prefix-length hint and guidance on what the client and server could do in different situations. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --001a113d2362736c0e054c14e516 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

We've updated a new version= of draft-ietf-dhc-dhcpv6-prefix-length-hint-issue (version 06) accord= ing to the comments received during IESG Last Call. Main changes include:

1. Changed text at the end of the first and second = paragraph of the =E2=80=9CSolution=E2=80=9D part of section 3.2.
=
OLD: If the server does not have a prefix with length matchi= ng the prefix-length hint value, then the server SHOULD provide the prefix = with the shortest length possible which is closest to the prefix-length hin= t value.

NEW: If the server does not have a prefix= with length matching the prefix-length hint value, then the server SHOULD = provide the prefix whose length is shorter and closest to the prefix-length= hint value.

2. Added text at the last paragraph o= f the =E2=80=9CSolution=E2=80=9D part of section 3.2, to describe what the = server should do if it cannot provide any prefixes to the client.

3. Changed option 4 of the =E2=80=9CSolution=E2=80=9D part = of section 3.5:=C2=A0

OLD: Assign the original del= egated prefix with 0 preferred-lifetime, a short non-zero valid-lifetime...= =C2=A0

NEW: Assign the original delegated prefix w= ith 0 preferred-lifetime, a specific non-zero valid-lifetime depending on a= ctual requirement...

4. Added reference to RFC3315= in section 4 for security considerations in DHCP=C2=A0

5. Added a sentence at the end of section 3.1 to explain that there i= s no requirement for the order of the two IAPREFIX options.=C2=A0

6. Expanded the words =E2=80=9CIAID=E2=80=9D and =E2=80=9CI= A_PD=E2=80=9D on first use in the second paragraph of the =E2=80=9CProblem= =E2=80=9D part of section 3.1:=C2=A0

IAID (Identit= y Association IDentifier)=C2=A0
IA_PD (Identity Association f= or Prefix Delegation)=C2=A0

7. Throughout the = draft, changed =E2=80=9Cthe prefix which length is=E2=80=9D to =E2=80=9Cthe= prefix whose length is=E2=80=9D.

Thank you,
Tianxiang

---------- Forw= arded message ----------
From: <internet-drafts= @ietf.org>
Date: 2017-04-01 14:10 GMT+08:00
Subject: Ne= w Version Notification for draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-0= 6.txt
To: Cong Liu <gnocuil@gmai= l.com>, Yong Cui <yong@csnet1.cs.tsinghua.edu.cn>, Tianxiang Li <peter416733@gmail.com>



A new version of I-D, draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-0= 6.txt
has been successfully submitted by Tianxiang Li and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-dhc-dhcpv6-prefix-= length-hint-issue
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A006
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 DHCPv6 Prefix Length Hint Issues Document date:=C2=A0 2017-03-31
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 dhc
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 9
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-draf= ts/draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-06.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-ietf-dhc-d= hcpv6-prefix-length-hint-issue/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-prefix-= length-hint-issue-06
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-iet= f-dhc-dhcpv6-prefix-length-hint-issue-06
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddra= ft-ietf-dhc-dhcpv6-prefix-length-hint-issue-06

Abstract:
=C2=A0 =C2=A0DHCPv6 Prefix Delegation (RFC3633) allows a client to include = a
=C2=A0 =C2=A0prefix-length hint value in the IA_PD option to indicate a pre= ference
=C2=A0 =C2=A0for the size of the prefix to be delegated, but is unclear abo= ut how
=C2=A0 =C2=A0the client and server should act in different situations invol= ving
=C2=A0 =C2=A0the prefix-length hint.=C2=A0 This document provides a summary= of the
=C2=A0 =C2=A0existing problems with the prefix-length hint and guidance on = what
=C2=A0 =C2=A0the client and server could do in different situations.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--001a113d2362736c0e054c14e516--