From nobody Sat Apr 1 14:14:37 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 05521126C26; Sat, 1 Apr 2017 14:14:31 -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: <149108127096.4405.10596374717418025038@ietfa.amsl.com> Date: Sat, 01 Apr 2017 14:14:31 -0700 Archived-At: Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-agentopt-delegate-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: Sat, 01 Apr 2017 21:14:31 -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 Relay Agent Assignment Notification (RAAN) Option Authors : Ralph Droms Bernie Volz Ole Troan Filename : draft-ietf-dhc-dhcpv6-agentopt-delegate-05.txt Pages : 9 Date : 2017-04-01 Abstract: The DHCP Relay Agent Assignment Notification (RAAN) option is sent from a DHCP server to a DHCP relay agent to inform the relay agent of IPv6 addresses that have been assigned or IPv6 prefixes that have been delegated to DHCP clients. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-agentopt-delegate/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-agentopt-delegate-05 https://datatracker.ietf.org/doc/html/draft-ietf-dhc-dhcpv6-agentopt-delegate-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-dhcpv6-agentopt-delegate-05 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 Sat Apr 1 14:21: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 B47211294F8 for ; Sat, 1 Apr 2017 14:21:54 -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 y_kIosmY64EM for ; Sat, 1 Apr 2017 14:21:52 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B791912947B for ; Sat, 1 Apr 2017 14:21:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2464; q=dns/txt; s=iport; t=1491081712; x=1492291312; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=p1ZyctGpXH45mvNfLu8jEFCULpcgmIuTrYKzNhqqr68=; b=XL4El2NS4Wcr1T73pu1qODfnU2Jttl8cbfXzJwMiyATfpUveMVhAX/vj ZAIVUueUhEDZ32Vu0jTzJcXhQ3VIryPUNuVkmLRAPtrAHbsg6LHhi/U2D mVrlIzQPJZvHBktFnhmxmnm7mfFdh/9FvN4qZiQYTLXEwKD6E/0Og1Low U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAQDeGOBY/5FdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgykrYYELB41tkVKVUoIOHw2FdgKDST8YAQIBAQEBAQEBax0LhRU?= =?us-ascii?q?BAQEBAQIBATg0FwQCAQgRBAEBHwkHJwsUCQgCBBMIigUOrQqKVQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAR2LPYMXgSeFewWJG4gZizkBhnx+ikyCBlWEWYoRk3QBHzi?= =?us-ascii?q?BBVsVGCmEWR2BY3UBiTCBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.36,259,1486425600"; d="scan'208";a="225831844" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Apr 2017 21:21:51 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v31LLowF019152 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Sat, 1 Apr 2017 21:21:50 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; Sat, 1 Apr 2017 16:21:49 -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, 1 Apr 2017 16:21:49 -0500 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-agentopt-delegate-05.txt Thread-Index: AQHSqy0IYYLrztOO+U6mszhVvrwqaaGxBCqQ Date: Sat, 1 Apr 2017 21:21:49 +0000 Message-ID: <8c93f39bdc0943f6b5e7d1fcd9f98268@XCH-ALN-003.cisco.com> References: <149108127096.4405.10596374717418025038@ietfa.amsl.com> In-Reply-To: <149108127096.4405.10596374717418025038@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.197] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-agentopt-delegate-05.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 21:21:55 -0000 Hi: While I did not confirm consensus on the mailing list, the consensus for th= ose in the room for the DHC WG session at IETF-98 was to restart work on th= is document and publish the "updated" version (with motivation for this wor= k because of draft-ietf-dhc-sedhcpv6) as the next WG version (the WG docume= nt had expired in 2010). For more details, see https://www.ietf.org/proceed= ings/98/slides/slides-98-dhc-discussion-of-sedhcpv6-and-raan-00.pdf. As I had the document ready, I've published it. FYI - No this is not an April fool's joke. - Bernie -----Original Message----- From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of internet-drafts@ie= tf.org Sent: Saturday, April 01, 2017 5:15 PM To: i-d-announce@ietf.org Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-agentopt-delegate-05.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Dynamic Host Configuration of the IETF. Title : DHCPv6 Relay Agent Assignment Notification (RAAN)= Option Authors : Ralph Droms Bernie Volz Ole Troan Filename : draft-ietf-dhc-dhcpv6-agentopt-delegate-05.txt Pages : 9 Date : 2017-04-01 Abstract: The DHCP Relay Agent Assignment Notification (RAAN) option is sent from a DHCP server to a DHCP relay agent to inform the relay agent of IPv6 addresses that have been assigned or IPv6 prefixes that have been delegated to DHCP clients. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-agentopt-delegate/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-agentopt-delegate-05 https://datatracker.ietf.org/doc/html/draft-ietf-dhc-dhcpv6-agentopt-delega= te-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-dhcpv6-agentopt-delegate= -05 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From nobody Wed Apr 5 09:53: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 AF28B1293DB; Wed, 5 Apr 2017 09:53:14 -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 8mZscyfIGHE0; Wed, 5 Apr 2017 09:53:12 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::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 AA26D1270A0; Wed, 5 Apr 2017 09:53:12 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id g195so16294178qke.2; Wed, 05 Apr 2017 09:53:12 -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=DzhD1lhGRkvYl51kWXDcvYlFzloQ7nnTODz5r55xhvw=; b=hMBFTTorLys8Drus7cKIhiBgDxSmBw/k9grSZ4TqxShUMbWbPfKJ0YT8LYm6IN10Gx QIbY7FgEaGVHJNup7ShSMOFzEFfbWCIQ3Z0cDVSlYS4eKWbplX0PEI7Qn4Rc2Gt4pAcR vn+5F0httY7KDWSMR/1jhhUELSecuIYxKANFCdcfDePjt/E0tlj4VOIiH52BGgYFn2Ll 4SJ527/v9V6mlp2m+x4Wnzb8WJ64YGmyorouQVIn92oVHBNa5mb4j548P+908bAKJnrp amaYr3RcUTilKW41n+asc4zq8Wv8G89AtXH3+0j8+ecsU2N8kldWNg7sjg5nldhUGmV1 LRkg== 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=DzhD1lhGRkvYl51kWXDcvYlFzloQ7nnTODz5r55xhvw=; b=ilCLMJRibxp5rzMmpgnCVSdjQrG8r6K3+nOGd7mTfJqsjdmI5v319rkOiow3xiB52T cU11G1eOkp5c5+FRpJMfndnLi2/nb8Hw1j7Hjvuj74I/eTmAIk4OVX1g8ZDEJefMGVTc OFo3FOVXiZH4/geoI/X6LujKz7UtkZpqwgwQ1Wzjl2rm3jrL7cLCdIaswIpSqmBQlFG1 U4ObFKQEhbamRFHSG/X9RTHaJnqCLBZi9b0tQ/P1KP9auX9+QgwDWfa7jtwQMmKDUEwA ZgV2zRi79d9LJYnc7D7CsX9FhVivyb+Bh9I4I9IkiXx38USsSQWD+Z2M3ICj627uPhn9 kdkQ== X-Gm-Message-State: AN3rC/7SiaV/7u6e48ISwtx8ts0K8pSJ047txRDkHVNm9Oe9r+YCSFuAziIGdupMYixzEbLXt0qULfyXS7z/CQ== X-Received: by 10.233.235.14 with SMTP id b14mr1732830qkg.86.1491411191798; Wed, 05 Apr 2017 09:53:11 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.61.204 with HTTP; Wed, 5 Apr 2017 09:53:11 -0700 (PDT) In-Reply-To: References: <7db55e6f55e34408a1816887c22e28d3@XCH-ALN-003.cisco.com> <369C97B6-B6E7-46CE-B42E-18559BFB1E78@cisco.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Wed, 5 Apr 2017 09:53:11 -0700 X-Google-Sender-Auth: qcLesk0LoAA6xdpxtjnnqWg1LrE Message-ID: To: "Bernie Volz (volz)" Cc: Lishan Li , 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: Wed, 05 Apr 2017 16:53:15 -0000 At Thu, 30 Mar 2017 14:37:44 +0000, "Bernie Volz (volz)" wrote: > 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? I have no clue on this. BTW, I guess this echoes my high-level concern: I suspect the current spec still has some points that are critically unclear, which you would immediately notice once you tried to implement it. If we're lucky some reviewers may be able to identify these points, but it's much less reliable than findings from actual attempts of implementing it. IMO we shouldn't try to publish a spec for which even none of the coauthors ever tried to write a prototype implementation (and I know I'm also guilty in that sense). -- JINMEI, Tatuya From nobody Wed Apr 5 10:14:28 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 4E8E412949A for ; Wed, 5 Apr 2017 10:14:26 -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, 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 (1024-bit key) header.d=iol.unh.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id deEFp4N_ge3M for ; Wed, 5 Apr 2017 10:14:20 -0700 (PDT) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (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 434A1127775 for ; Wed, 5 Apr 2017 10:14:20 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id s68so12991366vke.3 for ; Wed, 05 Apr 2017 10:14:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UG4A5ZPx60kq8OZ+Ws9iArkJtA+pHaQawCGNFnyU6HM=; b=FNdRDs0yxusnIJ80XL5rvKD7LR7dFmCOlwx5CrNv+1pzI0OwqIsBC/c6dCwxzMpUfJ I1xSXPIhbFfPcQRLjScyn1gTWZtd85IAK/ey6LMob2i3rWDvMy5RnNdWWDTSXQgg7hm4 gUpzbUaJOJZA8OhdaVASCRWMnvb4F6MrWR8y4= 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=UG4A5ZPx60kq8OZ+Ws9iArkJtA+pHaQawCGNFnyU6HM=; b=B27ACqaT1QOD9qg1ieJ5XBYrS0TA0GJV3QUhWU4iCkuvAJ+Vfs2rc+yO1udmR48/lj RXQt0D8Xe1ipqyuVmSbxjN30l2kB3UGfBSHt3D0SHkYT0umZsryDThBY/cfLmD1wXwQS QR00ng7jMGO0Gq8e4lTLiEQvXRakJiaf1o1a79JCmywdmtG2QkK3JE4sH9O1g9Kkxkz9 8affR5FjiaxSZgiJlnxgF8wFiARwILyvZolA7RtiuarXKlMNZDfYz5yc02W/7zYliacv T7JxvNKS66ducKKJ2mflwZSXw3abh+V5KJ0+hxXaygD8bh1gzGVXQbnFDEHcrODzRaqH PV0Q== X-Gm-Message-State: AFeK/H1cjGdJRzX+nJw0TKRiDEIFl19r5mzt/9/gwwZVmtbJkY3O+kH6WsBX7Kdg5BahJfjCrJyX/xbZ6EUGfRU3 X-Received: by 10.31.58.143 with SMTP id h137mr8363099vka.90.1491412459046; Wed, 05 Apr 2017 10:14:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.23.31 with HTTP; Wed, 5 Apr 2017 10:13:38 -0700 (PDT) In-Reply-To: References: From: Timothy Carlin Date: Wed, 5 Apr 2017 13:13:38 -0400 Message-ID: To: dhcwg Cc: draft-ietf-dhc-sedhcpv6 authors Content-Type: multipart/alternative; boundary=001a1143ecaad610cb054c6e859a 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: Wed, 05 Apr 2017 17:14:26 -0000 --001a1143ecaad610cb054c6e859a Content-Type: text/plain; charset=UTF-8 I apologize for the late email, I have read the document and have some thoughts. It's not completely clear which part of the messages are encrypted and integrity protected, or if there are parts that are only integrity protected. The Increasing-number Option is contained in the encrypted DHCPv6 messages, which may be a concern. An attacker can transmit replayed packets and the server must attempt to decrypt the packet to determine if it is a replayed (or otherwise invalid) packet and an attack. The decryption process is an expensive one, so this could be a denial-of-service vector. I have two possible suggestions. The first is to move the Increasing-number Option to an integrity protected (but not encrypted) portion of the packet. This allows for a preliminary check of the sequence number, prior to any decryption or integrity processing. This is similar to ESP's sequence number check (https://tools.ietf.org/html/ rfc4303#section-3.4.3). The second option is to document the potential attack in the Security Considerations. Additionally, including text to limit the rate at which encrypted messages may be sent by a client and subsequently processed. I'm also wondering about using RSA for encryption, as the data size (and thus message size) is limited to the key size that the client or server provides. This could cause problems with large DHCP messages. Could a symmetric key algorithm (e.g. AES) be used? The keys for this would have to be negotiated during the initial Information-request/Reply. Tim Carlin UNH-IOL On Thu, Mar 30, 2017 at 2:00 PM, Tomek Mrugalski wrote: > 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 > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > --001a1143ecaad610cb054c6e859a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I apologize for the late email, I have read the document a= nd have some thoughts.

It's not completely clear whi= ch part of the messages are encrypted and integrity protected, or if there = are parts that are only integrity protected.=C2=A0 The Increasing-number Op= tion is contained in the encrypted DHCPv6 messages, which may be a concern.=

An attacker can transmit replayed packets and the= server must attempt to decrypt the packet to determine if it is a replayed= (or otherwise invalid) packet and an attack.=C2=A0 The decryption process = is an expensive one, so this could be a denial-of-service vector.

I have two possible suggestions.=C2=A0 The first is to move= the Increasing-number Option to an integrity protected (but not encrypted)= portion of the packet.=C2=A0 This allows for a preliminary check of the se= quence number, prior to any decryption or integrity processing.=C2=A0 This = is similar to ESP's sequence number check (https://tools.ietf.org/= html/rfc4303#section-3.4.3).

The second o= ption is to document the potential attack in the Security Considerations.= =C2=A0 Additionally, including text to limit the rate at which encrypted me= ssages may be sent by a client and subsequently processed.

I'm also wondering about using RSA for encryption, as the data= size (and thus message size) is limited to the key size that the client or= server provides.=C2=A0 This could cause problems with large DHCP messages.= =C2=A0 Could a symmetric key algorithm (e.g. AES) be used?=C2=A0 The keys f= or this would have to be negotiated during the initial Information-request/= Reply.

Tim Carlin
UNH-IOL

On Thu, Mar 30, 2017= at 2:00 PM, Tomek Mrugalski <tomasz.mrugalski@gmail.com><= /span> wrote:
I have reviewed the draft a= nd 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 (=3D=3D), 5 comments (--).. Please fix them. Ping<= br> 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 =3D> 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 =3D> In some scenarios

Section 6
nit: is a Increasing-number option =3D> 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<= br> it against), but some checks are definitely applicable (e.g. drop
because signature is missing, multiple signatures or certificate missing).<= br>
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" =3D> "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 MU= ST send
Certificate option". It's also not shown on Figure 1. Yet, the ser= ver
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 multipl= e
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 ca= n
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]" =3D> "as explained in [RFC= 5652]"

"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 descrip= tion
of the concept was accurate enough. Any other thoughts on this?

"switch to other DHCPv6 server if it has another one." =3D> &q= uot;switch to
other DHCPv6 server if available."

The text uses "one and only one" several times. You may consider<= br> 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 payi= ng
cost to decrypt messages."
=3D> "The DHCPv6 server drops the message if the value of Se= rver
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 ta= g
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<= br> 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 bette= r
to say the server must be able to retain the increasing number across
restarts.

Remove "And " at the beginning of two sentences in first paragrap= h.

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: Con= tains 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 f= or
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.<= br>
10.1.2
"The Certificate option carries the certificate of th= e 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 mess= age
with a certificate". It would be better to say "The Certificate o= ption
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 earli= er
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:" =3D> "share the standard fo= rmat of DHCPv6
messages:".

Section 11
"There are some mandatory algorithm for encryption algorithm in this document.=C2=A0 It may be at some point that the mandatory algorithm= is no
longer safe to use." =3D> "There are some mandatory algorithms= specified
in this document.=C2=A0 It may be at some point that the mandatory algorith= m
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<= br> (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

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

--001a1143ecaad610cb054c6e859a-- From nobody Wed Apr 5 12:06:46 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 2DA4F12947A; Wed, 5 Apr 2017 12:06:44 -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 Gc1iuKYckDqC; Wed, 5 Apr 2017 12:06:42 -0700 (PDT) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (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 0C46F12706D; Wed, 5 Apr 2017 12:06:42 -0700 (PDT) Received: by mail-lf0-x231.google.com with SMTP id x137so15030270lff.3; Wed, 05 Apr 2017 12:06:41 -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=qoqN1SrW8DRF2PZnqgxH4XXdrGOW/B8SA0QvHeEZinM=; b=fDw8u6tCFhLKFMzQ2hjWggNCzqbh2WbxrPPFHXLha1g8Mn6G0aQtFnMSFi9JNnPGwa CpAkEi0+kuX3UZUh3L1dLagASho6IxcRc65Jhz2rUfqGjG/VgzKveKt/DhWwuKnpFi5z iHTMXGBd6etZRGEHYV63evGsTihHqcQTZ47J0vRhM72213ISRNX8PD7xvoMz96H9wVpH D1OKCuu/C1Z0UWSvst2QIwsH8bT+MW6FYEi5xAWpios8vMD/jTpiomXn5pG+fbh8xNcm tyHJY0sBJszGsHeATYWNE1JNSkEqQMY3TkFsg1mWLkRM76IsxR6uzMRqq+Ygg4zYEJJL h7CQ== 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=qoqN1SrW8DRF2PZnqgxH4XXdrGOW/B8SA0QvHeEZinM=; b=gkkBgu47SLl+azCMi/kFwC3+Db0O3xJdiB50dOwCdsZcKnT86KbiaYcHnAOHbkKiFp C1ru0u98wu8eDWrGFSw99auc8qyg/+MCC3atrKEzMCudf2ENh5Tb9A2mjR34w3XTvDKv NtqlGEzhAUXybdCPdyPrYbBcCx+wF2/6ykMDDnWwHwNQi19tfhLqOlpxlY8EYEuIs/F+ BMy1fCu6c1RMFnRHBAmmgVhZul/U3SR+4dDA4EKzZqasLlygaB+TmHmiDipKIgSx7m9S TYgdMXpv1ylGb1SH14ywPeS9reUKAL93z4Z4B+7FUfsX+wPHd2U2UkigMvYz6GhhaxdJ 2Z3w== X-Gm-Message-State: AFeK/H3Ar7CinOlJDxwozJcgJQLQ0ln1snX0eqwVnLN0AeBGSZIci8+9Gw5CkdyBIN3Oqg== X-Received: by 10.46.84.22 with SMTP id i22mr8654974ljb.132.1491419199880; Wed, 05 Apr 2017 12:06:39 -0700 (PDT) Received: from [192.168.0.5] (109241207033.gdansk.vectranet.pl. [109.241.207.33]) by smtp.googlemail.com with ESMTPSA id a16sm3943330lfk.24.2017.04.05.12.06.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Apr 2017 12:06:39 -0700 (PDT) To: dhcwg References: Cc: draft-ietf-dhc-sedhcpv6 authors From: Tomek Mrugalski Message-ID: <1380758a-b7d0-bb73-bf58-4e318e88a6d0@gmail.com> Date: Wed, 5 Apr 2017 21:06:36 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [dhcwg] WGLC on draft-ietf-dhc-sedhcpv6-21 - summary 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, 05 Apr 2017 19:06:44 -0000 It took a little bit more than planned, but the extra time gave us a couple more comments. We did receive a number of in depth reviews with technical comments. In general, several people praised the significantly improved quality and clarity of the document. Nobody said that is opposed to this work. So from that perspective this last call is a success. However, both chair and at least one co-author feel that an important concern has not been addressed yet. There currently are no known implementations or prototypes of this draft. For a typical DHCP draft that adds an option or two that would probably be fine, but for this particular draft it is not. For two reasons: First, we feel that this is an essential piece of the whole DHCPv6 ecosystem and as such require much more scrutiny then an average draft. Second, security is a complex matter and any unclear aspects would gravely damage the interoperability. Jinmei had put it well: "I suspect the current spec still has some points that are critically unclear, which you would immediately notice once you tried to implement it." Given that, we declare that more effort is needed before this work is deemed ready for IESG. At the same time, chairs would like to strongly applaud authors' efforts to improve this work. This version is significantly better than its predecessors. Thank you for your hard work. You are doing excellent work. Please continue. Also, to address the concern of missing implementations, chairs would like to announce a DHCP hackathon in Prague. Details are TBD, but the primary goal will be to have at least two independent implementations of that draft. The hackathon will take place the weekend before IETF meeting (that's July 15-16). A separate announcement will be sent soon. That is well over 3 months away. Authors and supporters of this work, please seriously consider dedicating some of your time implementing prototypes and attending the hackathon, if you can. If you can't we will organize some means for participating remotely. Thank you to the authors and to everyone who commented. Bernie & Tomek From nobody Wed Apr 5 12:25:59 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 CC66B12941D for ; Wed, 5 Apr 2017 12:25:58 -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 1QbF87BKuvWS for ; Wed, 5 Apr 2017 12:25:57 -0700 (PDT) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (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 A4C1F12948B for ; Wed, 5 Apr 2017 12:25:54 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id z15so15286173lfd.1 for ; Wed, 05 Apr 2017 12:25:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=LQCoiXiCmns+1fevy43uFS322ohBlaz8F1H/qxFTMIE=; b=S3ltg2RrJrfj1npgwuISCG12gphopF82Jfqrge2PXnjCAJrDMUk8lfCT8vKxNp/lvl wCc1g+oHQGQd9SPV7uyEtmkVc2GXoTYyZkQqpE4PIiFXrIq3H8aYjo4frKvgkTFoP0gE gLRWzUzqWrzZFvmTMA3ejNh/U9uiqERsejLEXKd+nB8r/WKARwvEM+VJgGL9c355Y2S4 Hxd+MUaInySaCuCkn1wr1y2erJ/T0BAwkDsaFQn58VzTderw3gZeLpyhmrz8iw1qF5af wNx3yE4ne19LnwOXOdDfUOAqFubtImokffZ762drrFQ8L49Gedi4zsuVyHjGj/ik8U1o Wybw== 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:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=LQCoiXiCmns+1fevy43uFS322ohBlaz8F1H/qxFTMIE=; b=VduLnB/3amudXDCyMm0dXtJ2dK4mj2ODM3Th+/L9GMNBWTXA7H/Zt4qj0GM+l5npQS +Ut1iWYII7de1YupweyoJqXOzhFt3nIv0M7CcD8DnKxApH6LUIRgBCarC61WTFJNB3Hq FXC6tIAUH+qSRhesAW62rVZM+LocSJlvw6uAO79iGBRY4gqzi1Ee5Uy3AckAYET+Sd/n QLCGxT6qBKDlbCSAo0tcrWlAyj6RT9XtPsSbfVXS623oa4fRdlMlpqKZdB+pmN1pUKSc CjT/xkqcXgNadxxzkRdaRoiaGHdEJBITTpp78NtmkZ7N+cMpkVBz6OnRqQjWTgE+036h R+zQ== X-Gm-Message-State: AFeK/H1ROsznq8RDBnpFytJPe2oZ+zyNWfCt7PChWTz0XtwvZ05dCrBDdwo5cNR5So3+dA== X-Received: by 10.46.88.7 with SMTP id m7mr9610341ljb.131.1491420352608; Wed, 05 Apr 2017 12:25:52 -0700 (PDT) Received: from [192.168.0.5] (109241207033.gdansk.vectranet.pl. [109.241.207.33]) by smtp.googlemail.com with ESMTPSA id e91sm3981598lji.40.2017.04.05.12.25.51 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Apr 2017 12:25:51 -0700 (PDT) From: Tomek Mrugalski To: dhcwg Message-ID: <4cb9bdab-f3a2-a9d0-1056-302b5ecdeae7@gmail.com> Date: Wed, 5 Apr 2017 21:25:49 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [dhcwg] WGLC on draft-ietf-dhc-relay-port-02 - respond by Apr 26 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, 05 Apr 2017 19:25:59 -0000 Hi, draft-ietf-dhc-relay-port-02 defines a small extension to the DHCPv4 and DHCPv6 protocols that allows usage of other UDP source ports to be used by relay agents. Authors believe this document is ready. The discussions so far on the mailing list were a bit modest, but the concept is simple, the draft was presented twice (in Buenos Aires and Berlin) and enjoyed a favourable reception in the room. As such, we announce a working group last call on this document. Please review and comment. This is a very short document. It has around 6 pages of actual text. Many WG participants may celebrate upcoming Easter and take some days off, therefore this WGLC is a bit longer than typical two weeks. Title: Generalized UDP Source Port for DHCP Relay Authors: N. Shen, E. Chen Filename: draft-ietf-dhc-relay-port-02 Pages: 10 (around 6 of actual technical text) Date: 2017-02-28 Link: https://tools.ietf.org/html/draft-ietf-dhc-relay-port-02 Responses by April 26th are appreciated. Thanks, Bernie and Tomek From nobody Thu Apr 6 09:24:18 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 E7D5D129541 for ; Thu, 6 Apr 2017 09:24:15 -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 km6-eVhM1ceI for ; Thu, 6 Apr 2017 09:24:14 -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 E884D1270B4 for ; Thu, 6 Apr 2017 09:24:11 -0700 (PDT) Received: by mail-pg0-x233.google.com with SMTP id g2so40274138pge.3 for ; Thu, 06 Apr 2017 09:24:11 -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=hBFLBLYQD/DaGVJZqgVsVuq22pF0jwWKPM2T5YRJdBk=; b=CnCW5gpjjPO2/8AT7LYMhgsVGZp/tpMMoHV1LOuLUtwICjKWfz5U9XMSYS+E54cpNP fLpZDqQj8ovUW8gf/wyqL9N0Dw2Qd94LOTlLEjNOTNWVMEdpzNRg7QdjmGjB0rD7yeaw Mz6KXKEFNKZ74wrkr9OH3V/mkozDmrggzaVs/4lju017AHLnmGlmmUx3nsTlbLPok3mK tuJXWf07UyrshUR80MXlTK4BK/OpteawTeAnzKNCNTkadvv6TpnKJAzScg74XlJJcGmr 2eSVfRGs37WaUl7WbS4VKNkaGL56HyvkLLdH3xbxQU7K9gm+a2RCRIaMx266nmqT1QOD aSyg== 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=hBFLBLYQD/DaGVJZqgVsVuq22pF0jwWKPM2T5YRJdBk=; b=MbIlKdwQ446KBKNFns4pu5fIxsxa9XgfS7mYWsVdPv7F3aJS5E8y/ar8dNTj5EOrTi he6M34oRYrsGbYr8RdHoaRZKlTuG9wT6t7+LfoiavfVMz47T+le0h8v/qP7QXjhxgMDS 96h7bk1Q7hj577ZGm80pbU3nxgefuoWCzlljBuk8NSCr9UcqbHfqonCjNH67nk/cPJU4 W2m8mYNrk4+qbATC19nVX+R1nSq2bLYbXojoq96t0Mj8N3lpv9aVpdwWq4Z6N/wAIily 3mjb+fQxYPHUdR7zzpHrXMiHTk6Nfy5Q8ljca13YWgZDC3uvG3qJvQ5w51iGzbGFMILV 4xWA== X-Gm-Message-State: AFeK/H00yxEHsESkoAYsM9VHQWqsxWmNA9nKgNhIHTFKcwIOSVHqOpVS5N9QG9Lbzq6jcQ== X-Received: by 10.99.232.21 with SMTP id s21mr37745411pgh.67.1491495851456; Thu, 06 Apr 2017 09:24:11 -0700 (PDT) Received: from ?IPv6:2620::b60:17:65a5:9972:9ffc:5799? ([2620:0:b60:17:65a5:9972:9ffc:5799]) by smtp.gmail.com with ESMTPSA id l126sm4777621pfl.56.2017.04.06.09.24.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Apr 2017 09:24:10 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ted Lemon In-Reply-To: <149148149013.22052.16147601984501430625@ietfa.amsl.com> Date: Thu, 6 Apr 2017 09:24:06 -0700 Cc: dhcwg Content-Transfer-Encoding: quoted-printable Message-Id: <13F93C63-D6E3-4AB5-9254-D4DBCA6754D4@fugue.com> References: <149148149013.22052.16147601984501430625@ietfa.amsl.com> To: mohamed.boucadair@orange.com X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [dhcwg] I-D Action: draft-boucadair-dots-dhcp-00.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: Thu, 06 Apr 2017 16:24:16 -0000 Med, can you talk about why you've put the requirement in this document = for IPv4-mapped IPv6 addresses? This is an example of a requirement = that requires special treatment for this option, since it would = generally be an error for a DHCPv6 server to return the result of A = record queries in DHCP options. Why is this option special? From nobody Thu Apr 6 13:54:15 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 3DCF7129671 for ; Thu, 6 Apr 2017 13:54:14 -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 154AQPl406xf for ; Thu, 6 Apr 2017 13:54:12 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E5E312965E for ; Thu, 6 Apr 2017 13:54:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1391; q=dns/txt; s=iport; t=1491512050; x=1492721650; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=XOcmRqJJzhumb7ynO92bacpPGvWDmYyQkJlKWozaVnE=; b=gGyUqymBPbpUTWTkwzYuACvM2GfJSX6YI8UYFxUXsNQ+KN4EHjLZk+FU /aVvr5on3rqeql6Arr2DE4uJWWPnT78oVFXl839qdkfcZXcbJ41VpQnB2 al2W7cke3/Sy4fJIUrit5KR0vprD1nRQBluRZTfzuOmN0Jk1Tibwg7Qb/ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AgAQDSqeZY/5BdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1RhgQsHAY1tkT+IGo07gg8fC4V4AoNGPxgBAgEBAQEBAQFrKIU?= =?us-ascii?q?VAQEBAQIBAQE4NAsFCwIBCA4GBB4QIQYLJQIEDgWJdgMNCA6sFocwDYM0AQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBGAWIU4JrgTyBFYIFgzSCMQWcODsBhn2HHIQ5gX6?= =?us-ascii?q?FLohXgTqKe4h8AR84gQVbFRgpEQGEVoFzdYhSAYEMAQEB?= X-IronPort-AV: E=Sophos;i="5.37,161,1488844800"; d="scan'208";a="407983890" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Apr 2017 20:54:09 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v36Ks9Um006564 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 6 Apr 2017 20:54:09 GMT Received: from xch-rcd-004.cisco.com (173.37.102.14) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 6 Apr 2017 15:54:08 -0500 Received: from xch-rcd-004.cisco.com ([173.37.102.14]) by XCH-RCD-004.cisco.com ([173.37.102.14]) with mapi id 15.00.1210.000; Thu, 6 Apr 2017 15:54:08 -0500 From: "Naiming Shen (naiming)" To: Tomek Mrugalski CC: dhcwg Thread-Topic: [dhcwg] WGLC on draft-ietf-dhc-relay-port-02 - respond by Apr 26 Thread-Index: AQHSrkJ4H/Lr+ZM5zE2RbI5PHueQ0qG5JysA Date: Thu, 6 Apr 2017 20:54:08 +0000 Message-ID: <181B93F3-EC05-405B-A8F2-E0C1564A2BBD@cisco.com> References: <4cb9bdab-f3a2-a9d0-1056-302b5ecdeae7@gmail.com> In-Reply-To: <4cb9bdab-f3a2-a9d0-1056-302b5ecdeae7@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [128.107.155.135] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-relay-port-02 - respond by Apr 26 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, 06 Apr 2017 20:54:14 -0000 I support as a co-author. Best Regards, - Naiming > On Apr 5, 2017, at 12:25 PM, Tomek Mrugalski = wrote: >=20 > Hi, > draft-ietf-dhc-relay-port-02 defines a small extension to the DHCPv4 and > DHCPv6 protocols that allows usage of other UDP source ports to be used > by relay agents. Authors believe this document is ready. The discussions > so far on the mailing list were a bit modest, but the concept is simple, > the draft was presented twice (in Buenos Aires and Berlin) and enjoyed a > favourable reception in the room. As such, we announce a working group > last call on this document. Please review and comment. >=20 > This is a very short document. It has around 6 pages of actual text. >=20 > Many WG participants may celebrate upcoming Easter and take some days > off, therefore this WGLC is a bit longer than typical two weeks. >=20 > Title: Generalized UDP Source Port for DHCP Relay > Authors: N. Shen, E. Chen > Filename: draft-ietf-dhc-relay-port-02 > Pages: 10 (around 6 of actual technical text) > Date: 2017-02-28 > Link: https://tools.ietf.org/html/draft-ietf-dhc-relay-port-02 >=20 > Responses by April 26th are appreciated. >=20 > Thanks, > Bernie and Tomek >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From nobody Thu Apr 6 16:06:08 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 EF2A21294B1 for ; Thu, 6 Apr 2017 16:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -22.501 X-Spam-Level: X-Spam-Status: No, score=-22.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=fail (1024-bit key) reason="fail (message has been altered)" header.from=lufang@ebay.com header.d=ebay.com; dkim=pass (1024-bit key) header.d=ebay.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 XFIs8dqessfU for ; Thu, 6 Apr 2017 16:06:04 -0700 (PDT) Received: from den-mipot-002.corp.ebay.com (den-mipot-002.corp.ebay.com [216.113.175.153]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98ED6124C27 for ; Thu, 6 Apr 2017 16:06:03 -0700 (PDT) DomainKey-Signature: s=ebaycorp; d=ebay.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:Received: Received:Received:From:To:CC:Subject:Thread-Topic: Thread-Index:Date:Message-ID:References:In-Reply-To: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:authentication-results: x-ms-exchange-messagesentrepresentingtype: x-originating-ip:x-microsoft-exchange-diagnostics: x-ms-office365-filtering-correlation-id: x-ms-office365-filtering-ht:x-microsoft-antispam: x-microsoft-antispam-prvs:x-exchange-antispam-report-test: x-exchange-antispam-report-cfa-test:x-forefront-prvs: x-forefront-antispam-report:spamdiagnosticoutput: spamdiagnosticmetadata:Content-Type:Content-ID: Content-Transfer-Encoding:MIME-Version: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id: X-MS-Exchange-Transport-CrossTenantHeadersStamped: Return-Path:X-OriginatorOrg:X-CFilter-Loop; b=r++Upky6L1+slfo+1t3lsKpzX8Ydi6dmy4mUi01eudQJl516sgZSXqtM xaExzB+hJtRf/cZyLVIvnMFMpxq9lKjSmO2/qEoohl+yya30zMcZ23jQ6 ut078sMvqNaVNPXCebDKel8HjPFNOEsvGk4vqym+u9SPL3nrPK2dRxGEf g=; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ebay.com; i=@ebay.com; q=dns/txt; s=ebaycorp; t=1491519963; x=1523055963; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=bcpPlelUsKJaqgmVg/AgxidKZNQSmURlCbcZUkOEWC8=; b=p3Z7lj44XJHlsERl2PmmutOALydlAlYOGu5Bxs0KeaYBkgsuswtXhVVF b0H2k9bjH1RdArOhxC6X001scrB0jhxPO11gSM+WCwEhvmsmXMr30iiYe vJGqW3JKmr3u7/R1t0SvNQHcYmcnmmURjV/dsPP432vBVEUn6oB+xtgm4 Q=; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="5.37,161,1488870000"; d="scan'208";a="225502697" Received: from den-vteml-004.corp.ebay.com (HELO DEN-EXMHT-001.corp.ebay.com) ([10.101.112.120]) by den-mipot-002.corp.ebay.com with ESMTP; 06 Apr 2017 17:06:02 -0600 Received: from DEN-365HT-003.corp.ebay.com (10.101.47.5) by DEN-EXMHT-001.corp.ebay.com (10.241.17.148) with Microsoft SMTP Server (TLS) id 14.3.266.1; Thu, 6 Apr 2017 17:06:02 -0600 Received: from NAM03-CO1-obe.outbound.protection.outlook.com (216.32.181.24) by o365.corp.ebay.com (10.101.47.5) with Microsoft SMTP Server (TLS) id 14.3.266.1; Thu, 6 Apr 2017 17:06:01 -0600 Received: from BY1PR0701MB1642.namprd07.prod.outlook.com (10.162.110.16) by BY1PR0701MB1641.namprd07.prod.outlook.com (10.162.110.158) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1019.17; Thu, 6 Apr 2017 23:06:01 +0000 Received: from BY1PR0701MB1642.namprd07.prod.outlook.com ([10.162.110.16]) by BY1PR0701MB1642.namprd07.prod.outlook.com ([10.162.110.16]) with mapi id 15.01.1019.021; Thu, 6 Apr 2017 23:06:00 +0000 From: "Fang, Luyuan" To: "Naiming Shen (naiming)" , Tomek Mrugalski CC: dhcwg Thread-Topic: [dhcwg] WGLC on draft-ietf-dhc-relay-port-02 - respond by Apr 26 Thread-Index: AQHSrkKR0GVSzQTwNUWkBeuLQMtcCqG401kA//+vfwA= Date: Thu, 6 Apr 2017 23:06:00 +0000 Message-ID: <214624CA-BD9D-4B74-9F52-073C3E2E41B4@ebay.com> References: <4cb9bdab-f3a2-a9d0-1056-302b5ecdeae7@gmail.com> <181B93F3-EC05-405B-A8F2-E0C1564A2BBD@cisco.com> In-Reply-To: <181B93F3-EC05-405B-A8F2-E0C1564A2BBD@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=ebay.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [216.113.160.71] x-microsoft-exchange-diagnostics: 1; BY1PR0701MB1641; 7://YsFxy8p87cnPI05r3vKgEPjq376JNzhMJqf8pnbCHgDLIKWw3fs85xZeeWYKJvUErmrOoKCnkSHelJLP1KVunyCRMrBkqHK2Igel3UN6MJ2WnchLNx+fKd4JLcLWTfRceHZwi0J2wMyYPp2NCOItoPrctM5nDmeY52socA53h2zsA+1HQ5n7SAXUcYShMaNcWejYr/OnxL2oe6jNwB3RUKnu0W93nm1i+nC+yKqe90FF4alwjfneAY5fKSWpR0I2+R1kJ7P2IOUbKg7OHN1RUrBaRk3y+oIfHj2eh48I3ZxXkqkZdyRxe44ERyUSa7boT8vhPGDhzdvE3ls5lj/w== x-ms-office365-filtering-correlation-id: 77cb4d08-4414-41c6-4a0d-08d47d417e16 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:BY1PR0701MB1641; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(20161123560025)(20161123564025)(20161123555025)(20161123562025)(6072148); SRVR:BY1PR0701MB1641; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0701MB1641; x-forefront-prvs: 02698DF457 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39850400002)(39400400002)(39410400002)(39840400002)(39860400002)(377424004)(24454002)(377454003)(5660300001)(25786009)(230783001)(81166006)(53546009)(99286003)(2950100002)(8936002)(122556002)(305945005)(6436002)(66066001)(6246003)(10290500002)(4326008)(7736002)(50986999)(76176999)(54356999)(83716003)(6512007)(189998001)(6306002)(53936002)(82746002)(229853002)(38730400002)(3660700001)(3846002)(77096006)(39060400002)(36756003)(86362001)(8676002)(2906002)(3280700002)(6486002)(6116002)(6506006)(33656002)(102836003)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0701MB1641; H:BY1PR0701MB1642.namprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <85A971F02333424C995ED2F7AFF37ADB@namprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Apr 2017 23:06:00.6724 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46326bff-9928-41a0-baca-17c16c94ea99 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0701MB1641 X-OriginatorOrg: ebay.com X-CFilter-Loop: Reflected Archived-At: Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-relay-port-02 - respond by Apr 26 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, 06 Apr 2017 23:06:07 -0000 SSBzdXBwb3J0Lg0KTHV5dWFuDQoNCk9uIDQvNi8xNywgMTo1NCBQTSwgImRoY3dnIG9uIGJlaGFs ZiBvZiBOYWltaW5nIFNoZW4gKG5haW1pbmcpIiA8ZGhjd2ctYm91bmNlc0BpZXRmLm9yZyBvbiBi ZWhhbGYgb2YgbmFpbWluZ0BjaXNjby5jb20+IHdyb3RlOg0KDQogICAgDQogICAgSSBzdXBwb3J0 IGFzIGEgY28tYXV0aG9yLg0KICAgIA0KICAgIEJlc3QgUmVnYXJkcywNCiAgICAtIE5haW1pbmcN CiAgICANCiAgICA+IE9uIEFwciA1LCAyMDE3LCBhdCAxMjoyNSBQTSwgVG9tZWsgTXJ1Z2Fsc2tp IDx0b21hc3oubXJ1Z2Fsc2tpQGdtYWlsLmNvbT4gd3JvdGU6DQogICAgPiANCiAgICA+IEhpLA0K ICAgID4gZHJhZnQtaWV0Zi1kaGMtcmVsYXktcG9ydC0wMiBkZWZpbmVzIGEgc21hbGwgZXh0ZW5z aW9uIHRvIHRoZSBESENQdjQgYW5kDQogICAgPiBESENQdjYgcHJvdG9jb2xzIHRoYXQgYWxsb3dz IHVzYWdlIG9mIG90aGVyIFVEUCBzb3VyY2UgcG9ydHMgdG8gYmUgdXNlZA0KICAgID4gYnkgcmVs YXkgYWdlbnRzLiBBdXRob3JzIGJlbGlldmUgdGhpcyBkb2N1bWVudCBpcyByZWFkeS4gVGhlIGRp c2N1c3Npb25zDQogICAgPiBzbyBmYXIgb24gdGhlIG1haWxpbmcgbGlzdCB3ZXJlIGEgYml0IG1v ZGVzdCwgYnV0IHRoZSBjb25jZXB0IGlzIHNpbXBsZSwNCiAgICA+IHRoZSBkcmFmdCB3YXMgcHJl c2VudGVkIHR3aWNlIChpbiBCdWVub3MgQWlyZXMgYW5kIEJlcmxpbikgYW5kIGVuam95ZWQgYQ0K ICAgID4gZmF2b3VyYWJsZSByZWNlcHRpb24gaW4gdGhlIHJvb20uIEFzIHN1Y2gsIHdlIGFubm91 bmNlIGEgd29ya2luZyBncm91cA0KICAgID4gbGFzdCBjYWxsIG9uIHRoaXMgZG9jdW1lbnQuIFBs ZWFzZSByZXZpZXcgYW5kIGNvbW1lbnQuDQogICAgPiANCiAgICA+IFRoaXMgaXMgYSB2ZXJ5IHNo b3J0IGRvY3VtZW50LiBJdCBoYXMgYXJvdW5kIDYgcGFnZXMgb2YgYWN0dWFsIHRleHQuDQogICAg PiANCiAgICA+IE1hbnkgV0cgcGFydGljaXBhbnRzIG1heSBjZWxlYnJhdGUgdXBjb21pbmcgRWFz dGVyIGFuZCB0YWtlIHNvbWUgZGF5cw0KICAgID4gb2ZmLCB0aGVyZWZvcmUgdGhpcyBXR0xDIGlz IGEgYml0IGxvbmdlciB0aGFuIHR5cGljYWwgdHdvIHdlZWtzLg0KICAgID4gDQogICAgPiBUaXRs ZTogR2VuZXJhbGl6ZWQgVURQIFNvdXJjZSBQb3J0IGZvciBESENQIFJlbGF5DQogICAgPiBBdXRo b3JzOiBOLiBTaGVuLCBFLiBDaGVuDQogICAgPiBGaWxlbmFtZTogZHJhZnQtaWV0Zi1kaGMtcmVs YXktcG9ydC0wMg0KICAgID4gUGFnZXM6IDEwIChhcm91bmQgNiBvZiBhY3R1YWwgdGVjaG5pY2Fs IHRleHQpDQogICAgPiBEYXRlOiAyMDE3LTAyLTI4DQogICAgPiBMaW5rOiBodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1kaGMtcmVsYXktcG9ydC0wMg0KICAgID4gDQogICAg PiBSZXNwb25zZXMgYnkgQXByaWwgMjZ0aCBhcmUgYXBwcmVjaWF0ZWQuDQogICAgPiANCiAgICA+ IFRoYW5rcywNCiAgICA+IEJlcm5pZSBhbmQgVG9tZWsNCiAgICA+IA0KICAgID4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICA+IGRoY3dnIG1haWxp bmcgbGlzdA0KICAgID4gZGhjd2dAaWV0Zi5vcmcNCiAgICA+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vZGhjd2cNCiAgICANCiAgICBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgIGRoY3dnIG1haWxpbmcgbGlzdA0KICAgIGRo Y3dnQGlldGYub3JnDQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9k aGN3Zw0KICAgIA0KDQo= From nobody Thu Apr 6 16:15:18 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 CBD4F128990 for ; Thu, 6 Apr 2017 16:15:17 -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 0pZQCii85788 for ; Thu, 6 Apr 2017 16:15:15 -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 DEAA5129542 for ; Thu, 6 Apr 2017 16:15:14 -0700 (PDT) Received: by mail-pg0-x22f.google.com with SMTP id 21so48810083pgg.1 for ; Thu, 06 Apr 2017 16:15:14 -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=MGZYuc6yFLb2+azgPl3lB4QRuY5gwFlni/GHk6IUaGA=; b=J7/8osM70pddbNoCZwmElxduJ4FROJNPjs5dudSdXJcFNTkdcVv+pTGgd5dWoDeRxI vA8i/ZxA2YOHtxIq6sMDFtwN64sIjFk7r5iFK3oQL+O/eaA/a+vs8q8YQYccRzBAECT1 VPC9J+FNmAsy2yoLmD9yEunmIPEnYybzzX1x3TEU6T43wF8Qw+ukJe2dQSwbmnSH56Yb OBssPul1hs/LSdYq8zCA6+76vhmhWbjHUWt+GLyhKpRThaE5qFgUiYwoHzvpK0bZZTnJ 6IlKjBtl/6UJaEYyjzOgSuRS7QCVNqIU1haJYcXtcjMRJg1hBZmGifVw+jDLLHHeHcNu 8KdA== 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=MGZYuc6yFLb2+azgPl3lB4QRuY5gwFlni/GHk6IUaGA=; b=uoEA+9vAIBmx4O62MeVYCEiDs/kSoIJKV9/0UAnWcDPpS+REq10nktpiMiC9ji3RTz oU85dLZ4TxKp1pqVXUKiJtUFftzm+ZNo8pkOsUmUpP6+iNjAzOyvATUAm33Pd32ArfGN xtJfvyER/JQYjX2ahTKeVWKDhWtlaBr7GHzYAiYi9Zetxg9cmzaplHx80vD+nHqKY3G4 zu8z7hEwhjhb1KaK8sG5fdpzb063E0jkIIezce4GxqF9jIDNxNFQtzlEYQmduTMW3qlo 6SPiV0ZzCsVBr3xIpavFD/ybQc04r5fLjkholWEvWq1MwQvK2exH5eyEp5dBsA4e2bPI rx5g== X-Gm-Message-State: AFeK/H3hLcfIT3rnyl2HV1ArMdfZ89pZOLeIQMvwa2egImZW4N7QZ/B+unhKQoQNd6MQAA== X-Received: by 10.84.210.44 with SMTP id z41mr7210826plh.133.1491520514559; Thu, 06 Apr 2017 16:15:14 -0700 (PDT) Received: from ?IPv6:2620::b60:3:f8fb:5edf:a67e:46e5? ([2620:0:b60:3:f8fb:5edf:a67e:46e5]) by smtp.gmail.com with ESMTPSA id a5sm5570486pfh.124.2017.04.06.16.15.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Apr 2017 16:15:13 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ted Lemon In-Reply-To: <4cb9bdab-f3a2-a9d0-1056-302b5ecdeae7@gmail.com> Date: Thu, 6 Apr 2017 16:15:13 -0700 Cc: dhcwg Content-Transfer-Encoding: quoted-printable Message-Id: <6815847B-EEB6-4824-959E-F8D845A14994@fugue.com> References: <4cb9bdab-f3a2-a9d0-1056-302b5ecdeae7@gmail.com> To: Tomek Mrugalski X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-relay-port-02 - respond by Apr 26 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, 06 Apr 2017 23:15:18 -0000 I support advancing this work. However, there is an issue: right now = the document assumes that if the relay agent sends a message from a = different source port, the DHCP server will reply to that port. This = should be stated explicitly. Right now the document does not place = requirements on DHCP servers as far as I can see, and those are needed = for interoperability. From nobody Thu Apr 6 17:02:38 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 9918C129631 for ; Thu, 6 Apr 2017 17:02:35 -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 mxKUd0KVl73r for ; Thu, 6 Apr 2017 17:02:34 -0700 (PDT) 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 D62DF1292C5 for ; Thu, 6 Apr 2017 17:02:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1384; q=dns/txt; s=iport; t=1491523353; x=1492732953; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=NraipCh8fKHUGNzF88RZiqP5fAbtbupmRlIMUh3In9A=; b=ARaBd7GjIaOL2WEba36bEB2UwiBqnufSUsWN/T5qpT1SSCenF/Dm63Cz 542SS/qb3M3rQRVaggY7zSj9Z7pLSJXYk1dbwdLGXUGYc0opcIcn1vwK3 BT1paJYUOh7JEUek+MLPyMfsxSE9y1OX7/cLLFlv8grEaVVH5Zv+LRYGh A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AhAQCF1uZY/49dJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1RhgQsHAY1tkUCVVYIPHwuFeAIagy4/GAECAQEBAQEBAWsohRU?= =?us-ascii?q?BAQEBAgEBASEROgsFCwIBCA4KAgImAgICJQsVEAIEDgWKBggOqTmCJopyAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBGAWBC4dIgmuBPIMECYMTLoIxBZxzAZJSkT2TdwE?= =?us-ascii?q?fOIEFWxVBEQGEVoFzdYckgS4BgQwBAQE?= X-IronPort-AV: E=Sophos;i="5.37,161,1488844800"; d="scan'208";a="408746355" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Apr 2017 00:02:33 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v3702WUO022733 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 7 Apr 2017 00:02:33 GMT Received: from xch-rcd-004.cisco.com (173.37.102.14) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 6 Apr 2017 19:02:32 -0500 Received: from xch-rcd-004.cisco.com ([173.37.102.14]) by XCH-RCD-004.cisco.com ([173.37.102.14]) with mapi id 15.00.1210.000; Thu, 6 Apr 2017 19:02:32 -0500 From: "Naiming Shen (naiming)" To: Ted Lemon CC: Tomek Mrugalski , dhcwg Thread-Topic: [dhcwg] WGLC on draft-ietf-dhc-relay-port-02 - respond by Apr 26 Thread-Index: AQHSrkJ4H/Lr+ZM5zE2RbI5PHueQ0qG5TpaAgAANOAA= Date: Fri, 7 Apr 2017 00:02:32 +0000 Message-ID: References: <4cb9bdab-f3a2-a9d0-1056-302b5ecdeae7@gmail.com> <6815847B-EEB6-4824-959E-F8D845A14994@fugue.com> In-Reply-To: <6815847B-EEB6-4824-959E-F8D845A14994@fugue.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [128.107.155.135] Content-Type: text/plain; charset="utf-8" Content-ID: <0F75FD7A57840F419BF6B8B1F7EAFDC4@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-relay-port-02 - respond by Apr 26 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, 07 Apr 2017 00:02:36 -0000 DQpIaSBUZWQsDQoNClRoYW5rcyBmb3IgdGhlIHN1Z2dlc3Rpb24uIEN1cnJlbnRseSBpbiBzZWN0 aW9uIDYg4oCcQ29tcGF0aWJpbGl0eeKAnSwgaXQgc2F5czoNCg0KICAgICBJdCBpcyByZWNvbW1l bmRlZCB0byB1cGdyYWRlIHRoZSBzZXJ2ZXIgc2lkZSBmaXJzdCBiZWZvcmUgdXNpbmcgYSBub24t REhDUA0KICAgICBVRFAgcG9ydCBmb3IgYSByZWxheSBhZ2VudC4NCg0KSG93IGFib3V0IGNoYW5n aW5nIHRvIHRoaXM6DQoNCiAgICBUaGUgREhDUCBzZXJ2ZXIgTVVTVCBiZSB1cGdyYWRlZCB0byBz dXBwb3J0IHRoZSBleHRlbnNpb24gc3BlY2lmaWVkDQogICAgaW4gdGhpcyBkb2N1bWVudCBiZWZv cmUgdGhlIGV4dGVuc2lvbiBpcyB1c2VkIGJ5IGEgcmVsYXkgYWdlbnQuDQoNCg0KDQoNCkJlc3Qg UmVnYXJkcywNCi0gTmFpbWluZw0KDQo+IE9uIEFwciA2LCAyMDE3LCBhdCA0OjE1IFBNLCBUZWQg TGVtb24gPG1lbGxvbkBmdWd1ZS5jb20+IHdyb3RlOg0KPiANCj4gSSBzdXBwb3J0IGFkdmFuY2lu ZyB0aGlzIHdvcmsuICAgSG93ZXZlciwgdGhlcmUgaXMgYW4gaXNzdWU6IHJpZ2h0IG5vdyB0aGUg ZG9jdW1lbnQgYXNzdW1lcyB0aGF0IGlmIHRoZSByZWxheSBhZ2VudCBzZW5kcyBhIG1lc3NhZ2Ug ZnJvbSBhIGRpZmZlcmVudCBzb3VyY2UgcG9ydCwgdGhlIERIQ1Agc2VydmVyIHdpbGwgcmVwbHkg dG8gdGhhdCBwb3J0LiAgIFRoaXMgc2hvdWxkIGJlIHN0YXRlZCBleHBsaWNpdGx5LiAgUmlnaHQg bm93IHRoZSBkb2N1bWVudCBkb2VzIG5vdCBwbGFjZSByZXF1aXJlbWVudHMgb24gREhDUCBzZXJ2 ZXJzIGFzIGZhciBhcyBJIGNhbiBzZWUsIGFuZCB0aG9zZSBhcmUgbmVlZGVkIGZvciBpbnRlcm9w ZXJhYmlsaXR5Lg0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gZGhjd2cgbWFpbGluZyBsaXN0DQo+IGRoY3dnQGlldGYub3JnDQo+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGhjd2cNCg0K From nobody Thu Apr 6 17:05:01 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 29AEA126B71 for ; Thu, 6 Apr 2017 17:05:00 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 BMcvlTqYlGeI for ; Thu, 6 Apr 2017 17:04:57 -0700 (PDT) Received: from mail-pg0-x229.google.com (mail-pg0-x229.google.com [IPv6:2607:f8b0:400e:c05::229]) (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 C36EA129631 for ; Thu, 6 Apr 2017 17:04:57 -0700 (PDT) Received: by mail-pg0-x229.google.com with SMTP id g2so48828345pge.3 for ; Thu, 06 Apr 2017 17:04:57 -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=Tuql3L4g+k7ODaxU8yxJ8D+kVR81TuqTm9Of4SIHd5o=; b=mf+GRjOWyMHb4Jr6Rlumr+mA5cPYMqjgt522DBTgSehqUHOhaxErlQJOYxIKbv99w6 M2dEoM9lwp0f5y+sUyp5f47bBQgp6KDg3P1Y1na6z0y8b9AtIHB0M/DlPYIVTV9EcZ49 kaefizGKqrKQiGFNxJQ8KecZeWxPV3Tvlexu7tLejM/5ez3pV+xijOBNUnRJZvKxbbwu AYBGveJPvn/p1ztlx4h6aS0CjFoUm7Y2+j5xD7BkZAxVdtrLiJOTRZqidQIrlZ76Dewi 5zCGJsWa4XbzdbXihLyglL5S8NXEs3n+7pnfwBF8RsPF8bRRuwqqr5OsJvyM2sYwefgb 2SAA== 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=Tuql3L4g+k7ODaxU8yxJ8D+kVR81TuqTm9Of4SIHd5o=; b=hy5xKvIrV7Z2uJx+2UstgDxaENk6niCUbZy5cq/FD6v6+Ee9DiDV/5dznTpUlqdUXl L2TtWNB2iOCe6fnLas6cqx3+OvxtagG0c+PuyxJYW1ohoWJcHE79v/lo1i4JaFARiX6Z TfGgKU5zqjH0Moy3lgHxtOaWf3OdvRcIYJe/gmvCUHXIwMEIt/884Tt8zCKSdgx7m1p4 HCHZuxfoUWCk7C2d/6KoGFED/tkRARHlBXxYpiw8DtdJAIexvhlaTAUmRW/k1Qxs2x+b iZHnoVmA7xGBuF0F1PiYLw1fal9NqGRxicP/KHxGdYfTr5YyiyqwW0JceIZP5ifd21QW ZZjg== X-Gm-Message-State: AFeK/H3ULRbiMl1GIHt/1uH5pT+FbuNhwGAJxhx5tavbWR1s6eFRLOZc6Pqxmx86ZW0HMQ== X-Received: by 10.98.24.9 with SMTP id 9mr16932530pfy.73.1491523497421; Thu, 06 Apr 2017 17:04:57 -0700 (PDT) Received: from ?IPv6:2620::b60:17:bd93:844f:7473:6719? ([2620:0:b60:17:bd93:844f:7473:6719]) by smtp.gmail.com with ESMTPSA id d1sm5683122pfa.5.2017.04.06.17.04.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Apr 2017 17:04:56 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ted Lemon In-Reply-To: Date: Thu, 6 Apr 2017 17:03:36 -0700 Cc: Tomek Mrugalski , dhcwg Content-Transfer-Encoding: quoted-printable Message-Id: <51E35331-9AFA-4C75-851D-129AF3E3F5A8@fugue.com> References: <4cb9bdab-f3a2-a9d0-1056-302b5ecdeae7@gmail.com> <6815847B-EEB6-4824-959E-F8D845A14994@fugue.com> To: "Naiming Shen (naiming)" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-relay-port-02 - respond by Apr 26 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, 07 Apr 2017 00:05:00 -0000 No, that's not quite what I mean. What I mean is that you have to = explicitly say what the DHCP server does. Right now I'm not seeing = that. Maybe I missed it=E2=80=94I read the document pretty quickly. > On Apr 6, 2017, at 5:02 PM, Naiming Shen (naiming) = wrote: >=20 >=20 > Hi Ted, >=20 > Thanks for the suggestion. Currently in section 6 =E2=80=9CCompatibility= =E2=80=9D, it says: >=20 > It is recommended to upgrade the server side first before using a = non-DHCP > UDP port for a relay agent. >=20 > How about changing to this: >=20 > The DHCP server MUST be upgraded to support the extension specified > in this document before the extension is used by a relay agent. From nobody Thu Apr 6 17:15:32 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 E7DBE129631 for ; Thu, 6 Apr 2017 17:15:30 -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 AzT10CbJDEId for ; Thu, 6 Apr 2017 17:15:29 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2DCB1296C9 for ; Thu, 6 Apr 2017 17:15:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2424; q=dns/txt; s=iport; t=1491524123; x=1492733723; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=L22EXdqjQYucgKgaWHvA6YpBdnZ5e4MVAtG66APYfoM=; b=dJ93YR34Ow3b94yaEkNxWYDcNkhGR2WHdW0iC7roSrTCFPBtJXi1zbJ/ ZDDPzv9Hp0VQMs/aT6GwPLA1otwA7dygqae6WmkdMM9JREhEpcVLZtpGE F4mL7e5dhTSAL7e5BJtlHjYiad+WWhvprFKqo0WFcFwlIQm780HxZK0fx M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CLAQAS2eZY/5tdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1SBbAcBjW2RIR+VVYIPhiICGoMuPxgBAgEBAQEBAQFrKIUVAQE?= =?us-ascii?q?BAQIBIxFFBQsCAQgOCgICJgICAjAVEAIEDgWKBgipRoIminMBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEdgQuHSAmCYoE8gwQJgxMugjEBBJxzAZJSgX6JB4Y4k3cBHzi?= =?us-ascii?q?BBVsVUgGEVoFzdYckgS4BgQwBAQE?= X-IronPort-AV: E=Sophos;i="5.37,161,1488844800"; d="scan'208";a="405796851" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Apr 2017 00:15:23 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v370FN6E003940 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 7 Apr 2017 00:15:23 GMT Received: from xch-rcd-004.cisco.com (173.37.102.14) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 6 Apr 2017 19:15:22 -0500 Received: from xch-rcd-004.cisco.com ([173.37.102.14]) by XCH-RCD-004.cisco.com ([173.37.102.14]) with mapi id 15.00.1210.000; Thu, 6 Apr 2017 19:15:22 -0500 From: "Naiming Shen (naiming)" To: Ted Lemon CC: Tomek Mrugalski , dhcwg Thread-Topic: [dhcwg] WGLC on draft-ietf-dhc-relay-port-02 - respond by Apr 26 Thread-Index: AQHSrkJ4H/Lr+ZM5zE2RbI5PHueQ0qG5TpaAgAANOACAAABMAIAAA0oA Date: Fri, 7 Apr 2017 00:15:22 +0000 Message-ID: References: <4cb9bdab-f3a2-a9d0-1056-302b5ecdeae7@gmail.com> <6815847B-EEB6-4824-959E-F8D845A14994@fugue.com> <51E35331-9AFA-4C75-851D-129AF3E3F5A8@fugue.com> In-Reply-To: <51E35331-9AFA-4C75-851D-129AF3E3F5A8@fugue.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [128.107.155.135] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-relay-port-02 - respond by Apr 26 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, 07 Apr 2017 00:15:31 -0000 DQpIaSBUZWQsDQoNCkluIHNlY3Rpb24gNC4xIOKAnFNvdXJjZSBQb3J0IFN1Yi1vcHRpb24gZm9y IERIQ1B2NCIsIGl0IHNheXM6DQoNCiAgIFdoZW4gYSBESENQIHNlcnZlciByZWNlaXZlcyBhIG1l c3NhZ2UgZnJvbSBhIHJlbGF5IGFnZW50IHdpdGggdGhlDQogICAiU291cmNlIFBvcnQgU3ViLW9w dGlvbiIsIGl0IE1VU1QgcmVtZW1iZXIgdGhlIFVEUCBzb3VyY2UgcG9ydCBvZiB0aGUNCiAgIG1l c3NhZ2UgYW5kIHVzZSB0aGF0IHBvcnQgbnVtYmVyIGFzIHRoZSBVRFAgZGVzdGluYXRpb24gcG9y dCB3aGVuDQogICBzZW5kaW5nIHRoZSByZXBseSBtZXNzYWdlIHRvIHRoZSBzYW1lIHJlbGF5IGFn ZW50Lg0KDQpJbiBzZWN0aW9uIDQuMiDigJxTb3VyY2UgUG9ydCBTdWItb3B0aW9uIGZvciBESENQ djYiLCBpdCBzYXlzOg0KDQogICBXaGVuIGEgREhDUHY2IHNlcnZlciByZWNlaXZlcyBhIFJlbGF5 LWZvcndhcmQgbWVzc2FnZSB3aXRoIHRoZSAiUmVsYXkNCiAgIFNvdXJjZSBQb3J0IE9wdGlvbiIs IGl0IE1VU1QgY29weSB0aGUgb3B0aW9uIHdoZW4gY29uc3RydWN0aW5nIHRoZQ0KICAgUmVsYXkt cmVwbHkgY2hhaW4gaW4gcmVzcG9uc2UgdG8gdGhlIFJlbGF5LWZvcndhcmQgbWVzc2FnZS4gIFRo aXMNCiAgIG9wdGlvbiBNVVNUIE5PVCBhcHBlYXIgaW4gYW55IG1lc3NhZ2Ugb3RoZXIgdGhhbiBh IFJlbGF5LWZvcndhcmQgb3INCiAgIFJlbGF5LXJlcGx5IG1lc3NhZ2UuICBBZGRpdGlvbmFsbHks IHRoZSBESENQdjYgc2VydmVyIE1VU1QgY2hlY2sgYW5kDQogICB1c2UgdGhlIFVEUCBzb3VyY2Ug cG9ydCBmcm9tIHRoZSBVRFAgcGFja2V0IG9mIHRoZSBSZWxheS1mb3J3YXJkDQogICBtZXNzYWdl IGluIHJlcGx5aW5nIHRvIHRoZSByZWxheSBhZ2VudC4NCg0KdGh1cyB0aGUgZGhjcCBzZXJ2ZXIg YmVoYXZpb3IgZm9yIGJvdGggdjQgYW5kIHY2IGlzIGRlZmluZWQuDQoNCkJlc3QgUmVnYXJkcywN Ci0gTmFpbWluZw0KDQo+IE9uIEFwciA2LCAyMDE3LCBhdCA1OjAzIFBNLCBUZWQgTGVtb24gPG1l bGxvbkBmdWd1ZS5jb20+IHdyb3RlOg0KPiANCj4gTm8sIHRoYXQncyBub3QgcXVpdGUgd2hhdCBJ IG1lYW4uICAgV2hhdCBJIG1lYW4gaXMgdGhhdCB5b3UgaGF2ZSB0byBleHBsaWNpdGx5IHNheSB3 aGF0IHRoZSBESENQIHNlcnZlciBkb2VzLiAgIFJpZ2h0IG5vdyBJJ20gbm90IHNlZWluZyB0aGF0 LiAgICBNYXliZSBJIG1pc3NlZCBpdOKAlEkgcmVhZCB0aGUgZG9jdW1lbnQgcHJldHR5IHF1aWNr bHkuDQo+IA0KPj4gT24gQXByIDYsIDIwMTcsIGF0IDU6MDIgUE0sIE5haW1pbmcgU2hlbiAobmFp bWluZykgPG5haW1pbmdAY2lzY28uY29tPiB3cm90ZToNCj4+IA0KPj4gDQo+PiBIaSBUZWQsDQo+ PiANCj4+IFRoYW5rcyBmb3IgdGhlIHN1Z2dlc3Rpb24uIEN1cnJlbnRseSBpbiBzZWN0aW9uIDYg 4oCcQ29tcGF0aWJpbGl0eeKAnSwgaXQgc2F5czoNCj4+IA0KPj4gICAgSXQgaXMgcmVjb21tZW5k ZWQgdG8gdXBncmFkZSB0aGUgc2VydmVyIHNpZGUgZmlyc3QgYmVmb3JlIHVzaW5nIGEgbm9uLURI Q1ANCj4+ICAgIFVEUCBwb3J0IGZvciBhIHJlbGF5IGFnZW50Lg0KPj4gDQo+PiBIb3cgYWJvdXQg Y2hhbmdpbmcgdG8gdGhpczoNCj4+IA0KPj4gICBUaGUgREhDUCBzZXJ2ZXIgTVVTVCBiZSB1cGdy YWRlZCB0byBzdXBwb3J0IHRoZSBleHRlbnNpb24gc3BlY2lmaWVkDQo+PiAgIGluIHRoaXMgZG9j dW1lbnQgYmVmb3JlIHRoZSBleHRlbnNpb24gaXMgdXNlZCBieSBhIHJlbGF5IGFnZW50Lg0KPiAN Cg0K From nobody Thu Apr 6 17:26: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 E38881286CA for ; Thu, 6 Apr 2017 17:26:45 -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 LVbbcSiN4gty for ; Thu, 6 Apr 2017 17:26:43 -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 98205127275 for ; Thu, 6 Apr 2017 17:26:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11268; q=dns/txt; s=iport; t=1491524802; x=1492734402; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=J34VoMd5QdlzeQxRjeEx5pNFLOLmJMvYh/gKNK3wsO8=; b=J/yjRzCh8vIZ8iayHNH7WoPzba9wK6IJUSxqCpw802TBpoGzCkM0mHqJ 6D7OdB6Sm8ODIlvaGl/pa3CS3ADXB4ZlHWICbJMC4bdvqQ7DVsOuqms7X 9PZkiVFyyKKH4KK//8orkaYGjcvPuXjKdWh+FH7AALXTfXcPz25iA4lr9 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CdAQCp2+ZY/4MNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1RhgQsHAY1tkSGQQIU0gg8mhXwCGoMuPxgBAgEBAQEBAQFrKIU?= =?us-ascii?q?WBiNWEAIBCA4xAwICAjAUEQIEDgWKDg6pP4IminMBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEYBYhTCYJigTyDBAmDEy6CMQWccwGGfYtVgX6JB4Y4k3cBHziBBVsVUgG?= =?us-ascii?q?EVoFzdYckgS4BgQwBAQE?= X-IronPort-AV: E=Sophos;i="5.37,161,1488844800"; d="scan'208,217";a="406940038" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Apr 2017 00:26:41 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v370Qf1P027965 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 7 Apr 2017 00:26:41 GMT Received: from xch-rcd-004.cisco.com (173.37.102.14) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 6 Apr 2017 19:26:40 -0500 Received: from xch-rcd-004.cisco.com ([173.37.102.14]) by XCH-RCD-004.cisco.com ([173.37.102.14]) with mapi id 15.00.1210.000; Thu, 6 Apr 2017 19:26:40 -0500 From: "Naiming Shen (naiming)" To: Ted Lemon CC: dhcwg Thread-Topic: [dhcwg] WGLC on draft-ietf-dhc-relay-port-02 - respond by Apr 26 Thread-Index: AQHSrkJ4H/Lr+ZM5zE2RbI5PHueQ0qG5TpaAgAANOACAAABMAIAAA0oAgAAAoACAAAKIAA== Date: Fri, 7 Apr 2017 00:26:40 +0000 Message-ID: <2AD20D47-6D22-404E-9796-662C7CBB4630@cisco.com> References: <4cb9bdab-f3a2-a9d0-1056-302b5ecdeae7@gmail.com> <6815847B-EEB6-4824-959E-F8D845A14994@fugue.com> <51E35331-9AFA-4C75-851D-129AF3E3F5A8@fugue.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [128.107.155.135] Content-Type: multipart/alternative; boundary="_000_2AD20D476D22404E9796662C7CBB4630ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-relay-port-02 - respond by Apr 26 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, 07 Apr 2017 00:26:46 -0000 --_000_2AD20D476D22404E9796662C7CBB4630ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpPaywgY3VycmVudGx5IHRoZSB0ZXh0IGlzIHRoaXM6DQoNCiAgIFRoZSBSZWxheSBBZ2VudCAi U291cmNlIFBvcnQgU3ViLW9wdGlvbiIgaXMgYSBuZXcgb3B0aW9uLCBhbmQgaXQgaXMNCiAgIHBh cnQgb2YgdGhlIHJlbGF5LWFnZW50LWluZm9ybWF0aW9uIG9wdGlvbiBmb3IgREhDUHY0IFtSRkMz MDQ2PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMzMDQ2Pl0uICBJdA0KICAgU0hPVUxE IGJlIHVzZWQgYnkgYSByZWxheSBhZ2VudCB0aGF0IHVzZXMgYSBub24tREhDUCBVRFAgcG9ydA0K ICAgY29tbXVuaWNhdGluZyB3aXRoIHRoZSBESENQIHNlcnZlci4NCg0KSSBjYW4gY2hhbmdlIGl0 IHRvOg0KDQoNCiAgIFRoZSBSZWxheSBBZ2VudCAiU291cmNlIFBvcnQgU3ViLW9wdGlvbiIgaXMg YSBuZXcgb3B0aW9uLCBhbmQgaXQgaXMNCiAgIHBhcnQgb2YgdGhlIHJlbGF5LWFnZW50LWluZm9y bWF0aW9uIG9wdGlvbiBmb3IgREhDUHY0IFtSRkMzMDQ2PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9yZmMzMDQ2Pl0uICBJdA0KICAgTVVTVCBiZSB1c2VkIGJ5IGEgcmVsYXkgYWdlbnQgdGhh dCB1c2VzIGEgbm9uLURIQ1AgVURQIHBvcnQNCiAgIGNvbW11bmljYXRpbmcgd2l0aCB0aGUgREhD UCBzZXJ2ZXIuDQoNCg0KYW5kIGRvIHRoZSBzYW1lIGZvciBESENQdjYgcGFydCBhbHNvLg0KDQpC ZXN0IFJlZ2FyZHMsDQotIE5haW1pbmcNCg0KT24gQXByIDYsIDIwMTcsIGF0IDU6MTcgUE0sIFRl ZCBMZW1vbiA8bWVsbG9uQGZ1Z3VlLmNvbTxtYWlsdG86bWVsbG9uQGZ1Z3VlLmNvbT4+IHdyb3Rl Og0KDQpIbSwgb2theSwgYnV0IGVhcmxpZXIgeW91IGFsc28gc3BlY2lmeSB0aGF0IHRoZSByb3V0 ZXIgY2FuIGp1c3QgdXNlIGEgZGlmZmVyZW50IHNvdXJjZSBwb3J0IHdpdGhvdXQgdXNpbmcgdGhl IG9wdGlvbi4gICBJZiB0aGlzIGlzbid0IHBlcm1pdHRlZCwgdGhlbiB5b3UgbmVlZCB0byBtYWtl IHRoYXQgdGV4dCBtb3JlIGV4cGxpY2l0OiBpZiBhbmQgb25seSBpZiB0aGUgcmVsYXkgc2VuZHMg dGhlIHN1Ym9wdGlvbiBjYW4gaXQgdXNlIGEgZGlmZmVyZW50IHNvdXJjZSBwb3J0Lg0KDQpPbiBB cHIgNiwgMjAxNywgYXQgNToxNSBQTSwgTmFpbWluZyBTaGVuIChuYWltaW5nKSA8bmFpbWluZ0Bj aXNjby5jb208bWFpbHRvOm5haW1pbmdAY2lzY28uY29tPj4gd3JvdGU6DQoNCg0KSGkgVGVkLA0K DQpJbiBzZWN0aW9uIDQuMSDigJxTb3VyY2UgUG9ydCBTdWItb3B0aW9uIGZvciBESENQdjQiLCBp dCBzYXlzOg0KDQogV2hlbiBhIERIQ1Agc2VydmVyIHJlY2VpdmVzIGEgbWVzc2FnZSBmcm9tIGEg cmVsYXkgYWdlbnQgd2l0aCB0aGUNCiAiU291cmNlIFBvcnQgU3ViLW9wdGlvbiIsIGl0IE1VU1Qg cmVtZW1iZXIgdGhlIFVEUCBzb3VyY2UgcG9ydCBvZiB0aGUNCiBtZXNzYWdlIGFuZCB1c2UgdGhh dCBwb3J0IG51bWJlciBhcyB0aGUgVURQIGRlc3RpbmF0aW9uIHBvcnQgd2hlbg0KIHNlbmRpbmcg dGhlIHJlcGx5IG1lc3NhZ2UgdG8gdGhlIHNhbWUgcmVsYXkgYWdlbnQuDQoNCkluIHNlY3Rpb24g NC4yIOKAnFNvdXJjZSBQb3J0IFN1Yi1vcHRpb24gZm9yIERIQ1B2NiIsIGl0IHNheXM6DQoNCiBX aGVuIGEgREhDUHY2IHNlcnZlciByZWNlaXZlcyBhIFJlbGF5LWZvcndhcmQgbWVzc2FnZSB3aXRo IHRoZSAiUmVsYXkNCiBTb3VyY2UgUG9ydCBPcHRpb24iLCBpdCBNVVNUIGNvcHkgdGhlIG9wdGlv biB3aGVuIGNvbnN0cnVjdGluZyB0aGUNCiBSZWxheS1yZXBseSBjaGFpbiBpbiByZXNwb25zZSB0 byB0aGUgUmVsYXktZm9yd2FyZCBtZXNzYWdlLiAgVGhpcw0KIG9wdGlvbiBNVVNUIE5PVCBhcHBl YXIgaW4gYW55IG1lc3NhZ2Ugb3RoZXIgdGhhbiBhIFJlbGF5LWZvcndhcmQgb3INCiBSZWxheS1y ZXBseSBtZXNzYWdlLiAgQWRkaXRpb25hbGx5LCB0aGUgREhDUHY2IHNlcnZlciBNVVNUIGNoZWNr IGFuZA0KIHVzZSB0aGUgVURQIHNvdXJjZSBwb3J0IGZyb20gdGhlIFVEUCBwYWNrZXQgb2YgdGhl IFJlbGF5LWZvcndhcmQNCiBtZXNzYWdlIGluIHJlcGx5aW5nIHRvIHRoZSByZWxheSBhZ2VudC4N Cg0KdGh1cyB0aGUgZGhjcCBzZXJ2ZXIgYmVoYXZpb3IgZm9yIGJvdGggdjQgYW5kIHY2IGlzIGRl ZmluZWQuDQoNCkJlc3QgUmVnYXJkcywNCi0gTmFpbWluZw0KDQpPbiBBcHIgNiwgMjAxNywgYXQg NTowMyBQTSwgVGVkIExlbW9uIDxtZWxsb25AZnVndWUuY29tPG1haWx0bzptZWxsb25AZnVndWUu Y29tPj4gd3JvdGU6DQoNCk5vLCB0aGF0J3Mgbm90IHF1aXRlIHdoYXQgSSBtZWFuLiAgIFdoYXQg SSBtZWFuIGlzIHRoYXQgeW91IGhhdmUgdG8gZXhwbGljaXRseSBzYXkgd2hhdCB0aGUgREhDUCBz ZXJ2ZXIgZG9lcy4gICBSaWdodCBub3cgSSdtIG5vdCBzZWVpbmcgdGhhdC4gICAgTWF5YmUgSSBt aXNzZWQgaXTigJRJIHJlYWQgdGhlIGRvY3VtZW50IHByZXR0eSBxdWlja2x5Lg0KDQpPbiBBcHIg NiwgMjAxNywgYXQgNTowMiBQTSwgTmFpbWluZyBTaGVuIChuYWltaW5nKSA8bmFpbWluZ0BjaXNj by5jb208bWFpbHRvOm5haW1pbmdAY2lzY28uY29tPj4gd3JvdGU6DQoNCg0KSGkgVGVkLA0KDQpU aGFua3MgZm9yIHRoZSBzdWdnZXN0aW9uLiBDdXJyZW50bHkgaW4gc2VjdGlvbiA2IOKAnENvbXBh dGliaWxpdHnigJ0sIGl0IHNheXM6DQoNCiBJdCBpcyByZWNvbW1lbmRlZCB0byB1cGdyYWRlIHRo ZSBzZXJ2ZXIgc2lkZSBmaXJzdCBiZWZvcmUgdXNpbmcgYSBub24tREhDUA0KIFVEUCBwb3J0IGZv ciBhIHJlbGF5IGFnZW50Lg0KDQpIb3cgYWJvdXQgY2hhbmdpbmcgdG8gdGhpczoNCg0KVGhlIERI Q1Agc2VydmVyIE1VU1QgYmUgdXBncmFkZWQgdG8gc3VwcG9ydCB0aGUgZXh0ZW5zaW9uIHNwZWNp ZmllZA0KaW4gdGhpcyBkb2N1bWVudCBiZWZvcmUgdGhlIGV4dGVuc2lvbiBpcyB1c2VkIGJ5IGEg cmVsYXkgYWdlbnQuDQoNCg0KDQoNCg== --_000_2AD20D476D22404E9796662C7CBB4630ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCk9rLCBjdXJyZW50bHkgdGhlIHRleHQgaXMgdGhpczoNCjxkaXYgY2xh c3M9IiI+DQo8cHJlIGNsYXNzPSJuZXdwYWdlIj48cHJlIGNsYXNzPSJuZXdwYWdlIj4gICBUaGUg UmVsYXkgQWdlbnQgJnF1b3Q7U291cmNlIFBvcnQgU3ViLW9wdGlvbiZxdW90OyBpcyBhIG5ldyBv cHRpb24sIGFuZCBpdCBpcw0KICAgcGFydCBvZiB0aGUgcmVsYXktYWdlbnQtaW5mb3JtYXRpb24g b3B0aW9uIGZvciBESENQdjQgWzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9y ZmMzMDQ2IiB0aXRsZT0iJnF1b3Q7REhDUCBSZWxheSBBZ2VudCBJbmZvcm1hdGlvbiBPcHRpb24m cXVvdDsiIGNsYXNzPSIiPlJGQzMwNDY8L2E+XS4gIEl0DQogICA8Zm9udCBjb2xvcj0iI2ZmMDAw MyIgY2xhc3M9IiI+U0hPVUxEPC9mb250PiBiZSB1c2VkIGJ5IGEgcmVsYXkgYWdlbnQgdGhhdCB1 c2VzIGEgbm9uLURIQ1AgVURQIHBvcnQNCiAgIGNvbW11bmljYXRpbmcgd2l0aCB0aGUgREhDUCBz ZXJ2ZXIuPC9wcmU+PC9wcmU+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SSBjYW4gY2hhbmdlIGl0 IHRvOjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+DQo8cHJlIGNsYXNzPSJuZXdwYWdlIj4gICBUaGUgUmVsYXkgQWdlbnQgJnF1b3Q7U291 cmNlIFBvcnQgU3ViLW9wdGlvbiZxdW90OyBpcyBhIG5ldyBvcHRpb24sIGFuZCBpdCBpcw0KICAg cGFydCBvZiB0aGUgcmVsYXktYWdlbnQtaW5mb3JtYXRpb24gb3B0aW9uIGZvciBESENQdjQgWzxh IGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMzMDQ2IiB0aXRsZT0iJnF1b3Q7 REhDUCBSZWxheSBBZ2VudCBJbmZvcm1hdGlvbiBPcHRpb24mcXVvdDsiIGNsYXNzPSIiPlJGQzMw NDY8L2E+XS4gIEl0DQogICA8Zm9udCBjb2xvcj0iI2ZmMDAwMCIgY2xhc3M9IiI+TVVTVDwvZm9u dD4gYmUgdXNlZCBieSBhIHJlbGF5IGFnZW50IHRoYXQgdXNlcyBhIG5vbi1ESENQIFVEUCBwb3J0 DQogICBjb21tdW5pY2F0aW5nIHdpdGggdGhlIERIQ1Agc2VydmVyLg0KPC9wcmU+DQo8ZGl2IGNs YXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5hbmQgZG8gdGhlIHNh bWUgZm9yIERIQ1B2NiBwYXJ0IGFsc28uPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5CZXN0IFJlZ2FyZHMsPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPi0gTmFpbWluZzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxkaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+ T24gQXByIDYsIDIwMTcsIGF0IDU6MTcgUE0sIFRlZCBMZW1vbiAmbHQ7PGEgaHJlZj0ibWFpbHRv Om1lbGxvbkBmdWd1ZS5jb20iIGNsYXNzPSIiPm1lbGxvbkBmdWd1ZS5jb208L2E+Jmd0OyB3cm90 ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNs YXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5IbSwgb2theSwgYnV0IGVhcmxpZXIgeW91IGFsc28gc3Bl Y2lmeSB0aGF0IHRoZSByb3V0ZXIgY2FuIGp1c3QgdXNlIGEgZGlmZmVyZW50IHNvdXJjZSBwb3J0 IHdpdGhvdXQgdXNpbmcgdGhlIG9wdGlvbi4gJm5ic3A7Jm5ic3A7SWYgdGhpcyBpc24ndCBwZXJt aXR0ZWQsIHRoZW4geW91IG5lZWQgdG8gbWFrZSB0aGF0IHRleHQgbW9yZSBleHBsaWNpdDogaWYg YW5kIG9ubHkgaWYgdGhlIHJlbGF5IHNlbmRzIHRoZSBzdWJvcHRpb24gY2FuIGl0DQogdXNlIGEg ZGlmZmVyZW50IHNvdXJjZSBwb3J0LjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPk9uIEFwciA2LCAyMDE3LCBhdCA1OjE1IFBNLCBO YWltaW5nIFNoZW4gKG5haW1pbmcpICZsdDs8YSBocmVmPSJtYWlsdG86bmFpbWluZ0BjaXNjby5j b20iIGNsYXNzPSIiPm5haW1pbmdAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PGJyIGNsYXNzPSIi Pg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSGkgVGVkLDxiciBjbGFzcz0iIj4NCjxi ciBjbGFzcz0iIj4NCkluIHNlY3Rpb24gNC4xIOKAnFNvdXJjZSBQb3J0IFN1Yi1vcHRpb24gZm9y IERIQ1B2NCZxdW90OywgaXQgc2F5czo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQombmJz cDtXaGVuIGEgREhDUCBzZXJ2ZXIgcmVjZWl2ZXMgYSBtZXNzYWdlIGZyb20gYSByZWxheSBhZ2Vu dCB3aXRoIHRoZTxiciBjbGFzcz0iIj4NCiZuYnNwOyZxdW90O1NvdXJjZSBQb3J0IFN1Yi1vcHRp b24mcXVvdDssIGl0IE1VU1QgcmVtZW1iZXIgdGhlIFVEUCBzb3VyY2UgcG9ydCBvZiB0aGU8YnIg Y2xhc3M9IiI+DQombmJzcDttZXNzYWdlIGFuZCB1c2UgdGhhdCBwb3J0IG51bWJlciBhcyB0aGUg VURQIGRlc3RpbmF0aW9uIHBvcnQgd2hlbjxiciBjbGFzcz0iIj4NCiZuYnNwO3NlbmRpbmcgdGhl IHJlcGx5IG1lc3NhZ2UgdG8gdGhlIHNhbWUgcmVsYXkgYWdlbnQuPGJyIGNsYXNzPSIiPg0KPGJy IGNsYXNzPSIiPg0KSW4gc2VjdGlvbiA0LjIg4oCcU291cmNlIFBvcnQgU3ViLW9wdGlvbiBmb3Ig REhDUHY2JnF1b3Q7LCBpdCBzYXlzOjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCiZuYnNw O1doZW4gYSBESENQdjYgc2VydmVyIHJlY2VpdmVzIGEgUmVsYXktZm9yd2FyZCBtZXNzYWdlIHdp dGggdGhlICZxdW90O1JlbGF5PGJyIGNsYXNzPSIiPg0KJm5ic3A7U291cmNlIFBvcnQgT3B0aW9u JnF1b3Q7LCBpdCBNVVNUIGNvcHkgdGhlIG9wdGlvbiB3aGVuIGNvbnN0cnVjdGluZyB0aGU8YnIg Y2xhc3M9IiI+DQombmJzcDtSZWxheS1yZXBseSBjaGFpbiBpbiByZXNwb25zZSB0byB0aGUgUmVs YXktZm9yd2FyZCBtZXNzYWdlLiAmbmJzcDtUaGlzPGJyIGNsYXNzPSIiPg0KJm5ic3A7b3B0aW9u IE1VU1QgTk9UIGFwcGVhciBpbiBhbnkgbWVzc2FnZSBvdGhlciB0aGFuIGEgUmVsYXktZm9yd2Fy ZCBvcjxiciBjbGFzcz0iIj4NCiZuYnNwO1JlbGF5LXJlcGx5IG1lc3NhZ2UuICZuYnNwO0FkZGl0 aW9uYWxseSwgdGhlIERIQ1B2NiBzZXJ2ZXIgTVVTVCBjaGVjayBhbmQ8YnIgY2xhc3M9IiI+DQom bmJzcDt1c2UgdGhlIFVEUCBzb3VyY2UgcG9ydCBmcm9tIHRoZSBVRFAgcGFja2V0IG9mIHRoZSBS ZWxheS1mb3J3YXJkPGJyIGNsYXNzPSIiPg0KJm5ic3A7bWVzc2FnZSBpbiByZXBseWluZyB0byB0 aGUgcmVsYXkgYWdlbnQuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KdGh1cyB0aGUgZGhj cCBzZXJ2ZXIgYmVoYXZpb3IgZm9yIGJvdGggdjQgYW5kIHY2IGlzIGRlZmluZWQuPGJyIGNsYXNz PSIiPg0KPGJyIGNsYXNzPSIiPg0KQmVzdCBSZWdhcmRzLDxiciBjbGFzcz0iIj4NCi0gTmFpbWlu ZzxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNs YXNzPSIiPk9uIEFwciA2LCAyMDE3LCBhdCA1OjAzIFBNLCBUZWQgTGVtb24gJmx0OzxhIGhyZWY9 Im1haWx0bzptZWxsb25AZnVndWUuY29tIiBjbGFzcz0iIj5tZWxsb25AZnVndWUuY29tPC9hPiZn dDsgd3JvdGU6PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KTm8sIHRoYXQncyBub3QgcXVp dGUgd2hhdCBJIG1lYW4uICZuYnNwOyZuYnNwO1doYXQgSSBtZWFuIGlzIHRoYXQgeW91IGhhdmUg dG8gZXhwbGljaXRseSBzYXkgd2hhdCB0aGUgREhDUCBzZXJ2ZXIgZG9lcy4gJm5ic3A7Jm5ic3A7 UmlnaHQgbm93IEknbSBub3Qgc2VlaW5nIHRoYXQuICZuYnNwOyZuYnNwOyZuYnNwO01heWJlIEkg bWlzc2VkIGl04oCUSSByZWFkIHRoZSBkb2N1bWVudCBwcmV0dHkgcXVpY2tseS48YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5PbiBB cHIgNiwgMjAxNywgYXQgNTowMiBQTSwgTmFpbWluZyBTaGVuIChuYWltaW5nKSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOm5haW1pbmdAY2lzY28uY29tIiBjbGFzcz0iIj5uYWltaW5nQGNpc2NvLmNvbTwv YT4mZ3Q7IHdyb3RlOjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N CkhpIFRlZCw8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGFua3MgZm9yIHRoZSBzdWdn ZXN0aW9uLiBDdXJyZW50bHkgaW4gc2VjdGlvbiA2IOKAnENvbXBhdGliaWxpdHnigJ0sIGl0IHNh eXM6PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7SXQgaXMgcmVjb21tZW5kZWQg dG8gdXBncmFkZSB0aGUgc2VydmVyIHNpZGUgZmlyc3QgYmVmb3JlIHVzaW5nIGEgbm9uLURIQ1A8 YnIgY2xhc3M9IiI+DQombmJzcDtVRFAgcG9ydCBmb3IgYSByZWxheSBhZ2VudC48YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQpIb3cgYWJvdXQgY2hhbmdpbmcgdG8gdGhpczo8YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGUgREhDUCBzZXJ2ZXIgTVVTVCBiZSB1cGdyYWRlZCB0byBz dXBwb3J0IHRoZSBleHRlbnNpb24gc3BlY2lmaWVkPGJyIGNsYXNzPSIiPg0KaW4gdGhpcyBkb2N1 bWVudCBiZWZvcmUgdGhlIGV4dGVuc2lvbiBpcyB1c2VkIGJ5IGEgcmVsYXkgYWdlbnQuPGJyIGNs YXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJy IGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_2AD20D476D22404E9796662C7CBB4630ciscocom_-- From nobody Fri Apr 7 01:04:13 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 3EA0B12948F for ; Fri, 7 Apr 2017 01:04:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=arberg-dk.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 yzBplT3V7rxe for ; Fri, 7 Apr 2017 01:04:08 -0700 (PDT) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::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 724A41295D0 for ; Fri, 7 Apr 2017 01:04:05 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id z15so38144073lfd.1 for ; Fri, 07 Apr 2017 01:04:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arberg-dk.20150623.gappssmtp.com; s=20150623; h=reply-to:from:to:cc:references:in-reply-to:subject:date :organization:message-id:mime-version:content-transfer-encoding :thread-index:content-language; bh=/b6Octfvjcd3olxC0IuvdG+VUc0KRzScwAC73Eojcz8=; b=s6R+GmkK+DCpAx8PB8x3YLtd3UFUmdbR1xee0X7gJjt1dtRIn2Kcl4sDqGOGnL6WcO yFXnOH4nQ/85Kv+AAxdTRwLYDf0vrj5UCTglkD78dUxy4go97sXK3iVIIxxNhef/VHZu rnG7g+JfvQbs9XwQX6apFyg0QkL0G4TCTtIkcNBOJ1T29xEMYVkDolekLvdg28ZOwp2n JXCtIPOZ+G4OD4uGg04aM8gy+3VS93j9ckSu4r2KAytjS+7lboXjEAoZETI8NihUltd4 jfRNPdsnKI56qE8XmZVBl0IcJzmwZscr+HTBIBGHdy9rrQwcduEV7bYRSgZFxKTIsJaZ nL6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:reply-to:from:to:cc:references:in-reply-to :subject:date:organization:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=/b6Octfvjcd3olxC0IuvdG+VUc0KRzScwAC73Eojcz8=; b=a5UmkbLnTKi8aH7KMtZE+4mEIyJQIfb9H8wO663646EeXXqj0SCFqcdOwiJS42c9aT GVR213TIX0ilkP/5912VKeu1goOZOUxjupXNu1qDxbaIZKWSYMc6NcFFfCsWuI89SifO JVyBOgL47SoK1wr65batk7xr+L4ZE2QSzuX/5KaHQJKfdL0xcEIFhcd+LD9U70HXeOSy v2RFqDdHL6x6NzitC+pZuUhd49vs7i/DKyjPlWoOSmijDOqvFA7OEHToz0oYo7yghGHO pWIVzybgw3Elk60Bu1Z3AnD1/zPLDEp2QGMzqoLQDf/v5AlCjWElXpHc5fzgUmMmNjuo o3NA== X-Gm-Message-State: AFeK/H2l1LOqMa95RMwDFeNan1q5iWRXwl75MrAOk8kAu/9iTEyXEZ8f9xKZd8t5kMIsEw== X-Received: by 10.46.82.2 with SMTP id g2mr11659752ljb.95.1491552243282; Fri, 07 Apr 2017 01:04:03 -0700 (PDT) Received: from PAT450s ([2a07:1483:1:0:1529:a672:afc:4b07]) by smtp.gmail.com with ESMTPSA id h128sm804736lfg.56.2017.04.07.01.04.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Apr 2017 01:04:02 -0700 (PDT) Reply-To: From: "Peter Arberg" To: "'Fang, Luyuan'" , "'Naiming Shen \(naiming\)'" , "'Tomek Mrugalski'" Cc: "'dhcwg'" References: <4cb9bdab-f3a2-a9d0-1056-302b5ecdeae7@gmail.com> <181B93F3-EC05-405B-A8F2-E0C1564A2BBD@cisco.com> <214624CA-BD9D-4B74-9F52-073C3E2E41B4@ebay.com> In-Reply-To: <214624CA-BD9D-4B74-9F52-073C3E2E41B4@ebay.com> Date: Fri, 7 Apr 2017 10:04:01 +0200 Organization: Home Message-ID: <000001d2af75$8500eaf0$8f02c0d0$@arberg.dk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIrhRSVehQrj2wc58OCwhScaLqYLQFOqnIGAegZUbeg7iqzYA== Content-Language: da Archived-At: Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-relay-port-02 - respond by Apr 26 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, 07 Apr 2017 08:04:11 -0000 I support, Peter -----Original Message----- From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Fang, Luyuan Sent: 7. april 2017 01:06 To: Naiming Shen (naiming) ; Tomek Mrugalski Cc: dhcwg Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-relay-port-02 - respond by Apr 26 I support. Luyuan On 4/6/17, 1:54 PM, "dhcwg on behalf of Naiming Shen (naiming)" wrote: I support as a co-author. Best Regards, - Naiming > On Apr 5, 2017, at 12:25 PM, Tomek Mrugalski wrote: > > Hi, > draft-ietf-dhc-relay-port-02 defines a small extension to the DHCPv4 and > DHCPv6 protocols that allows usage of other UDP source ports to be used > by relay agents. Authors believe this document is ready. The discussions > so far on the mailing list were a bit modest, but the concept is simple, > the draft was presented twice (in Buenos Aires and Berlin) and enjoyed a > favourable reception in the room. As such, we announce a working group > last call on this document. Please review and comment. > > This is a very short document. It has around 6 pages of actual text. > > Many WG participants may celebrate upcoming Easter and take some days > off, therefore this WGLC is a bit longer than typical two weeks. > > Title: Generalized UDP Source Port for DHCP Relay > Authors: N. Shen, E. Chen > Filename: draft-ietf-dhc-relay-port-02 > Pages: 10 (around 6 of actual technical text) > Date: 2017-02-28 > Link: https://tools.ietf.org/html/draft-ietf-dhc-relay-port-02 > > Responses by April 26th are appreciated. > > Thanks, > Bernie and Tomek > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From nobody Sat Apr 8 13:26: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 28378129474 for ; Sat, 8 Apr 2017 13:26:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.622 X-Spam-Level: X-Spam-Status: No, score=-12.622 tagged_above=-999 required=5 tests=[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 8l-O05hdAgxy for ; Sat, 8 Apr 2017 13:26:02 -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 A49CC129470 for ; Sat, 8 Apr 2017 13:26:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5866; q=dns/txt; s=iport; t=1491683162; x=1492892762; h=from:to:subject:date:message-id:mime-version; bh=uPuJd6U+H16+6LOkymi4LVLOTz4QyUYkV2zrFWBDlrk=; b=bOtcvam7bxDL8x/lG3N/kMfoG1ZdFOoBBaOW/t8elwQDZba5a4WpDljR 7XgI4WwssXn+2ZEFaWF0yUCEUEkPjmOfytm4Jbs9B+6XAPTN6FNsVWQxY 1wXF/5e9RLKGLvU2jxQgfaHzY/4y8ZxEJ+ycFu5KCrS7U4XYhnc0+HwzA 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B5AQC4RulY/4UNJK1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgm5lYYESjXKhY4U0gg8siVg/GAECAQEBAQEBAWsdC4VJXgGBACYBBBu?= =?us-ascii?q?KBw6YU5IuilwBAQEBAQEEAQEBAQEBARwFlXsFnHsBkk+CCIUuihSTfwEfOIEFW?= =?us-ascii?q?xWHG4kVgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.37,174,1488844800"; d="scan'208,217";a="405595506" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Apr 2017 20:26:01 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v38KQ1aC023924 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Sat, 8 Apr 2017 20:26:01 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sat, 8 Apr 2017 15:26:01 -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, 8 Apr 2017 15:26:01 -0500 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: IETF-98 DHC WG Draft Minutes Thread-Index: AdKwphEOOmgR1VYdTluu++LsCamT1g== Date: Sat, 8 Apr 2017 20:26:01 +0000 Message-ID: <7ed7d736b6e44a209e7ca2a0f9a8d1a7@XCH-ALN-003.cisco.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.195] Content-Type: multipart/alternative; boundary="_000_7ed7d736b6e44a209e7ca2a0f9a8d1a7XCHALN003ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [dhcwg] IETF-98 DHC WG Draft Minutes 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, 08 Apr 2017 20:26:04 -0000 --_000_7ed7d736b6e44a209e7ca2a0f9a8d1a7XCHALN003ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi: I've uploaded draft minutes of the DHC WG session at IETF-98 - see https://= www.ietf.org/proceedings/98/minutes/minutes-98-dhc-00. Please comment if you find anything that needs to be corrected, added, or d= eleted. Also, thanks to Ian Farrer for taking the Etherpad minutes (and any others = that may have assisted). - Bernie Volz --_000_7ed7d736b6e44a209e7ca2a0f9a8d1a7XCHALN003ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi:

 

I’ve uploaded draft minutes of the DHC WG sess= ion at IETF-98 – see h= ttps://www.ietf.org/proceedings/98/minutes/minutes-98-dhc-00.

 

Please comment if you find anything that needs to be= corrected, added, or deleted.

 

Also, thanks to Ian Farrer for taking the Etherpad m= inutes (and any others that may have assisted).

 

-     &= nbsp;    Bernie Volz

--_000_7ed7d736b6e44a209e7ca2a0f9a8d1a7XCHALN003ciscocom_-- From nobody Sun Apr 9 19:47: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 633611287A7; Sun, 9 Apr 2017 19:47:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Spencer Dawkins To: "The IESG" Cc: draft-ietf-dhc-relay-server-security@ietf.org, Tomek Mrugalski , dhc-chairs@ietf.org, tomasz.mrugalski@gmail.com, dhcwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149179242439.3102.12679687798772952270.idtracker@ietfa.amsl.com> Date: Sun, 09 Apr 2017 19:47:04 -0700 Archived-At: Subject: [dhcwg] Spencer Dawkins' No Objection on draft-ietf-dhc-relay-server-security-04: (with COMMENT) 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: Mon, 10 Apr 2017 02:47:04 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-dhc-relay-server-security-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dhc-relay-server-security/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for producing this document, when the DISCUSSes clear :-) From nobody Tue Apr 11 05:41:05 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 32F82129B4C; Tue, 11 Apr 2017 05:40:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-dhc-relay-server-security@ietf.org, Tomek Mrugalski , dhc-chairs@ietf.org, tomasz.mrugalski@gmail.com, dhcwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149191445619.15674.3447547103500441176.idtracker@ietfa.amsl.com> Date: Tue, 11 Apr 2017 05:40:56 -0700 Archived-At: Subject: [dhcwg] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-dhc-relay-server-security-04=3A_=28with_COMMENT=29?= 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: Tue, 11 Apr 2017 12:40:56 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-dhc-relay-server-security-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dhc-relay-server-security/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I strongly agre with Warren's discuss. This document is an update of RFC3315 and therefore MUST carry the update tag. If someone decides not to implement this new specification, they will still only confirm to RFC3315 and not this new document. As Warren said, somesome who wants this encryption needs to require conformance to this new RFC anyway. However I think the IETF should give a clear recommendation here that encryption must be used. If the working group really believes there are cases where encryption is not needed, this document must be rewritten to allow for these cases (by using SHOULD/RECOMMANDED instead of MUST/REQUIRED) and give a clear recomendation when it is acceptable to not use encryption. Further, I'm also wondering why this is not just incorporated in rfc3315bis? From nobody Tue Apr 11 13:46:27 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 99BD7128D6F; Tue, 11 Apr 2017 13:46:25 -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 1evWksPSDwIm; Tue, 11 Apr 2017 13:46:24 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B28BE127876; Tue, 11 Apr 2017 13:46:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7402; q=dns/txt; s=iport; t=1491943582; x=1493153182; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=mp0PEOkwFJhCQXqO5jg094+Ebny9FP0IHUKeixgyPnE=; b=llb+sRoNiH+T7VeUgQpfIaaiMlpl78XCtp5YWMsH10OiLcn/mDJw7lFv 299y5jHZEfSB49PqbypN5rKoz09wJ6r/+SpprVNpINZb73KZDKVrJoSe2 EcCsRj/03ZLKWU2KkuP485+OhkdNvEbxVa8CjhhnNdaXhHWCI1/uNeCXa s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ChAwAUQO1Y/4sNJK1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBg1OBc4NfihORMJV3gg+GJByDST8YAQIBAQEBAQEBayiFFgYjET4HEgE?= =?us-ascii?q?GAhoCJgIEMBUSBA6KFYtFnV2CJop5AQEBAQEBAQEBAQEBAQEBAQEhgQuHSgmCY?= =?us-ascii?q?oRAFoMGLoIxBZx/AZJdgX+JC4Y6iGSLHAEfOIEFWxVSAYRJHIFjiRWBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.37,187,1488844800"; d="scan'208";a="229913171" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Apr 2017 20:46:21 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v3BKkLtm023710 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 11 Apr 2017 20:46:21 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; Tue, 11 Apr 2017 15:46:21 -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, 11 Apr 2017 15:46:20 -0500 From: "Bernie Volz (volz)" To: The IESG CC: "draft-ietf-dhc-relay-server-security@ietf.org" , Tomek Mrugalski , "dhc-chairs@ietf.org" , "dhcwg@ietf.org" Thread-Topic: Discusses on draft-ietf-dhc-relay-server-security-04 Thread-Index: AQHSswSs71iIwTeLpU2y2ac6ttYMYA== Date: Tue, 11 Apr 2017 20:46:20 +0000 Message-ID: <5320BC41-545C-4510-89AC-9C62460E80CA@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.131.33.12] Content-Type: text/plain; charset="utf-8" Content-ID: <20B6EB33314F4A4E9084F929FE5845DD@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [dhcwg] Discusses on draft-ietf-dhc-relay-server-security-04 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, 11 Apr 2017 20:46:26 -0000 SGk6DQoNClJlZ2FyZGluZyB0aGUgZGlzY3Vzc2VzOg0KDQoxLiBFcmljIFJlc2NvcmxhIERpc2N1 c3MgKDIwMTctMDQtMDcpDQpXaGF0J3Mgbm90IGNsZWFyIHRvIG1lIGZyb20gcmVhZGluZyB0aGlz IGRvY3VtZW50IGlzIHdoZXRoZXIgYW55b25lDQphY3R1YWxseSBkb2VzIElQc2VjIGZvciBESENQ IHJlbGF5aW5nLiBJZiBzbywgd2hhdCBjb25maWd1cmF0aW9ucyBkbw0KdGhleSBydW4gaXQgaW4/ IElmIG5vdCwgd2lsbCB0aGV5IGRvIHNvIGFzIHRoZSByZXN1bHQgb2YgdGhpcw0KZG9jdW1lbnQ/ DQogDQpBbnN3ZXI6IEkgZG8gbm90IGtub3cgaWYgYW55b25lIGFjdHVhbGx5IHVzZXMgSVBzZWMu IFRoZSBSRkMzMzE1IG1lY2hhbmlzbSB3YXMgb3B0aW9uYWwgYW5kIGRpZCBub3QgcHJvdmlkZSBl bmNyeXB0aW9uIHNvIGl0IG1heSBub3QgaGF2ZSBldmVyIGJlZW4gdXNlZC4gVGhlcmVmb3JlLCBJ IGRvIG5vdCBrbm93IHdoYXQgYW55b25lIGFjdHVhbGx5IGRvZXMgdG9kYXkgKGlmIGFueXRoaW5n KS4gVGhvc2UgdXNpbmcgREhDUCB0aGF0IEkgYW0gYXdhcmUgb2Ygd2l0aCByZWxheXMgZG8gbm90 Lg0KDQpUaGUgaG9wZSBpcyB0aGF0IG1vcmUgd291bGQgdXNlIHRoaXMgbW9yZSByb2J1c3QgdmVy c2lvbiwgYW5kIHRob3NlIG9wZXJhdG9ycyB0aGF0IGZpbmQgaXQgaW1wb3J0YW50IHRvIGRvIHNv IHdpbGwgcmVxdWlyZSBpdCBvZiB0aGVpciByZWxheSBhbmQgc2VydmVyIHZlbmRvcnMgYnkgcHVy Y2hhc2luZyBpbXBsZW1lbnRhdGlvbnMgdGhhdCBzdXBwb3J0IHRoaXMgdG8tYmUtUkZDLg0KDQoy LiBXYXJyZW4gS3VtYXJpIERpc2N1c3MgKDIwMTctMDQtMDgpDQpUaGlzIGRvY3VtZW50IHNheXMg dGhhdCBpdCAicmVwbGFjZXMgdGhlIHRleHQgaW4gUkZDMzMxNSBTZWN0aW9uIDIxLjEuIiwgYnV0 IGl0IGRvZXMgbm90IGhhdmUgYW4gVXBkYXRlcyB0YWcuIEl0IGlzIGFsc28gY29udGFpbnMgYSBs YXJnZSBibG9iIG9mIFJGQzMzMTUsIHdpdGggY2xlYXIgZXhwbGFuYXRpb24gb2Ygd2hhdCBleGFj dGx5IGNoYW5nZWQuDQoNCkFOU1dFUjogSWYgd2Ugc2FpZCBVcGRhdGVzLCB0aGF0IHdvdWxkIG1l YW4gaXQgd291bGQgbGlrZWx5IGJlY29tZSBhIG5ldyByZXF1aXJlZCBzdGFuZGFyZCBmb3IgdGhv c2UgaW1wbGVtZW50aW5nIFJGQyAzMzE1LiBGb3IgbWFueSBESENQIGl0ZW1zLCB3ZSBvbmx5IHVz ZSB0aGUgVXBkYXRlcyB0YWcgd2hlbiB0aGVyZSBpcyBhIOKAnHJlcXVpcmVk4oCdIGNoYW5nZSBp biBlYXJsaWVyIGRvY3VtZW50cy4gVGhpcyBpcyBub3Qg4oCccmVxdWlyZWTigJ0g4oCTIGl0IGlz IGFuIG9wdGlvbmFsIGZlYXR1cmUgdGhhdCB2ZW5kb3JzIGNhbiBjaG9zZSB0byBpbXBsZW1lbnQg YW5kIG9wZXJhdG9ycyBjYW4gY2hvb3NlIHRvIHVzZS9yZXF1aXJlIG9mIHRoZWlyIHZlbmRvcnMg dG8gaW1wbGVtZW50LiBSZWdhcmRpbmcgdGhlIHRleHQsIG11Y2ggb2YgaXQgaXMgc2ltaWxhciB0 byB3aGF0IHdhcyBpbiBSRkMgMzMxNSBiZWNhdXNlIGl0IGlzIHNwZWNpZnlpbmcgdGhlIGZ1bGwg SVBzZWMgc3BlY2lmaWNhdGlvbi4gVGhlIG1haW4gdGhpbmdzIHRoYXQgY2hhbmdlZCBhcmUgdGhh dCBpdCBpcyByZXF1aXJlZCAoaWYgeW91IHdhbnQgdG8gY2xhaW0gY29uZm9ybWFuY2UgdG8gdGhp cyB0by1iZS1SRkMsIHdoZXJlYXMgaWYgeW91IHNheSB5b3UgY29tcGx5IHdpdGggMzMxNSB0aGVy ZSBpcyBubyByZXF1aXJlbWVudCB0byBpbXBsZW1lbnQgSVBzZWMpIGFuZCB0aGUgdXNlIG9mIGVu Y3J5cHRpb24uDQoNCg0KVGhlIHdyaXRldXAgc2F5cyAiRXZlbiB0aG91Z2ggdGhpcyBJLUQgaW50 cm9kdWNlcyBjaGFuZ2VzIHRvIFJGQzMzMTUsIHRoZSBXRyBkb2Vzbid0IHdhbnQgdG8gZW5mb3Jj ZSBJUHNlYyBlbmNyeXB0aW9uIG9uIGV2ZXJ5IERIQ1B2NiBzZXJ2ZXIuIFRoZXJlZm9yZSwgaXQg ZG9lcyBub3QgdXBkYXRlIFJGQzMzMTUuIiAtLSBzbywgaWYgSSdtIHdyaXRpbmcgYSBuZXcgREhD UHY2IGltcGxlbWVudGF0aW9uLCBkbyBJIG5lZWQgdG8gc3VwcG9ydCB0aGlzPyBUaGUgZG9jdW1l bnQgcmVhZHMgbGlrZSBpdCB0cmllcyB0byB1cGRhdGUgMzMxNSwgYnV0IHRoZSB3cml0ZXVwIHNh eXMgb3RoZXJ3aXNlIC0tIG9uY2UgcHVibGlzaGVkLCBuby1vbmUgd2lsbCByZWFkIHRoZSBzaGVw aGVyZCB3cml0ZXVwLiBJIHRoaW5rIHRoYXQgdGhlIGRvY3VtZW50IGl0c2VsZiBuZWVkcyB0byBi ZSBjbGVhcmVyIHRoYXQgdGhpcyBpcyBhbiBvcHRpb25hbCBleHRlbnNpb24gKHNvIGlmIEkgd2Fu dCB0byBidXkgYW4gaW1wbGVtZW50YXRpb24gd2hpY2ggZG9lcyB0aGlzLCBJIGFzayBmb3IgUkZD MzMxNSBhbmQgUkZDeHh4eCkuDQoNCkFOU1dFUjogV2hldGhlciB5b3UgaW1wbGVtZW50IHRoaXMg SVBzZWMgcmVxdWlyZW1lbnQgaW4gdGhlIHRvLWJlLVJGQyBpcyBhbiBpbXBsZW1lbnRhdGlvbiBj aG9pY2UuIFRoZXJlIGlzIG5vIHJlcXVpcmVtZW50IHRvIGltcGxlbWVudCB0aGlzIHRvLWJlLVJG Qy4gQW5kIG9wZXJhdG9ycyB0aGF0IHdpc2ggdG8gdXNlIElQc2VjIG11c3QgcmVxdWlyZSB0aGVp ciB2ZW5kb3JzIHRvIGltcGxlbWVudCB0aGlzIHRvLWJlLVJGQy4gU28gdGhlcmUgd291bGQgYmUg aW1wbGVtZW50YXRpb24gdGhhdCBjb21wbHkgd2l0aCBSRkMgMzMxNSBhbmQgdGhpcy10by1iZS1S RkMuIFRoaXMgd2lsbCBtYWtlIGl0IGNsZWFyIHRvIGFueW9uZSBkZXNpcmluZyByZWxheXMgb3Ig c2VydmVycyB3aGV0aGVyIHRoZXkgY2FuIHVzZSBJUHNlYyBiYXNlZCBvbiB3aGV0aGVyIHRoZXkg aW1wbGVtZW50IHRoaXMtdG8tYmUtUkZDLiBUaGlzIGlzIG5vdCBtdWNoIGRpZmZlcmVudCB0aGFu IG90aGVyIERIQ1AgZXh0ZW5zaW9ucyDigJMgc3VjaCBhcyBCdWxrIG9yIEFjdGl2ZSBMZWFzZXVx dWVyeSDigJMgdGhlc2UgYXJlIG5vdCBwYXJ0IG9mIHRoZSBiYXNlIHNwZWNpZmljYXRpb24gYnV0 IE9QVElPTkFMIGZlYXR1cmVzIGRvY3VtZW50ZWQgaW4gb3RoZXIgUkZDcy4NCg0KDQpJIGFsc28g ZG8gbm90IHVuZGVyc3RhbmQgdGhlIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHRoaXMgZG9jdW1lbnQg KHdoaWNoIHRhbGtzIGFib3V0IHRleHQgUkZDMzMxNSksIGFuZCBkcmFmdC1pZXRmLWRoYy1yZmMz MzE1YmlzICh3aGljaCBpcyBjdXJyZW50bHkgaW4gV0dMQykgLS0gaWYgcmZjMzMxNWJpcyBpcyBh bG1vc3QgZG9uZSwgc2hvdWxkIHRoaXMgcmVmZXJlbmNlIHRoYXQgaW5zdGVhZD8gT3Igc2hvdWxk IHJmYzMzMTViaXMgc2ltcGx5IGluY29ycG9yYXRlIHRoaXM/DQoNCkFOU1dFUjogMzMxNWJpcyBo YXMgdGhpcyBleGFjdCBzYW1lIHRleHQgRVhDRVBUIGl0IGlzIG9wdGlvbmFsLiBXaGVuIHdvcmtp bmcgb24gMzMxNWJpcyB3ZSBkaWQgbm90IGZlZWwgdGhhdCBpdCB3YXMgd29ydGggZG9jdW1lbnRp bmcgdGhlIG9sZCBJUHNlYyDigJxydWxlc+KAnSBmcm9tIDMzMTUgYXMgdGhleSB3ZXJlIHdlYWsg YW5kIG5vdCB2ZXJ5IHVzZWZ1bC4gQnV0IGFnYWluLCB3ZSBkaWQgbm90IHdhbnQgdG8gbWFrZSBJ UHNlYyByZXF1aXJlZCBhcyBwYXJ0IG9mIDMzMTViaXMuIEFsc28sIHdlIHdhbnRlZCB0aGlzIHRv LWJlLVJGQyB0byBiZSBhdmFpbGFibGUgc29vbmVyIHRoYW4gMzMxNWJpcyBtaWdodCBiZS4gV2Ug Y291bGQgY2VydGFpbmx5IGRpc2N1c3MgUkVNT1ZJTkcgSVBzZWMgdGV4dCBmcm9tIDMzMTViaXMg YW5kIGp1c3QgcmVmZXJyaW5nIHRvIHRoaXMgdG8tYmUtUkZDLiBUaGF0IGluIHRoZSBlbmQgbWF5 IGJlIGNsZWFuZXIuDQoNCg0KQ29tbWVudCAoMjAxNy0wNC0wOCkNCkkgZm91bmQgdGhlIGRvY3Vt ZW50IGNvbmZ1c2luZyAtLSBpdCBzYXlzIHRoYXQgaXQgUkVRVUlSRVMgSVBzZWMgZm9yIERIQ1B2 NCBhbmQgREhDUHY2LCBidXQgaXQgcmVhZHMgbGlrZSBpdCBpcyByZXF1aXJpbmcgdGhhdCBvcGVy YXRvcnMgZW5hYmxlIHRoaXMsIG5vdCB0aGF0IGltcGxlbWVudGF0aW9ucyBoYXZlIHRvIHN1cHBv cnQgdGhpczsgd2hhdCBleGFjdGx5IGlzIGlzIHRyeWluZyB0byBkbz8gDQpJIHRoaW5rIHRoYXQg aXQgd291bGQgYmUgbXVjaCBjbGVhcmVyIGlmIGl0IHNhaWQgdGhhdCBpbXBsZW1lbnRhdGlvbnMg b2YgdGhpcyBkb2N1bWVudCBtdXN0IHN1cHBvcnQgSVBzZWMgYW5kIHRoYXQgb3BlcmF0b3JzIGFy ZSByZWNvbW1lbmRlZCB0byBlbmFibGUgaXQgKGFzc3VtaW5nIHRoYXQgaXQgd2hhdCBpdCBtZWFu cykuDQoNCkFOU1dFUjogSXMgaXQgYm90aCDigJMgZm9yIHZlbmRvcnMgdG8gaW1wbGVtZW50IGFu ZCBmb3Igb3BlcmF0b3JzIHRvIHVzZS4gSXQgcmVxdWlyZXMgYm90aCBiZWNhdXNlIG9mIGtleSBt YW5hZ2VtZW50LiBJZiB5b3UgcHJlZmVyIHdlIGNhbiBjZXJ0YWlubHkgYWRkIGEgc2VudGVuY2Ug b3IgcmV3b3JkIHNvbWUgZXhpc3RpbmcgdGV4dCB0byBzYXlzIOKAnGltcGxlbWVudGF0aW9ucyBv ZiB0aGlzIGRvY3VtZW50IG11c3Qgc3VwcG9ydCBJUHNlYyBhbmQgdGhhdCBvcGVyYXRvcnMgYXJl IHJlY29tbWVuZGVkIHRvIGVuYWJsZSBpdOKAnS4gUGVyaGFwcyByZXBsYWNlOg0KDQogICBGb3Ig REhDUHY2IFtSRkMzMzE1XSwgdGhpcyBzcGVjaWZpY2F0aW9uIFJFUVVJUkVTIElQc2VjIGVuY3J5 cHRpb24gb2YNCiAgIHJlbGF5IHRvIHJlbGF5IGFuZCByZWxheSB0byBzZXJ2ZXIgY29tbXVuaWNh dGlvbiBhbmQgcmVwbGFjZXMgdGhlDQogICB0ZXh0IGluIFJGQzMzMTUgU2VjdGlvbiAyMS4xLg0K DQogICBGb3IgREhDUHY0IFtSRkMyMTMxXSwgdGhpcyBzcGVjaWZpY2F0aW9uIFJFUVVJUkVTIElQ c2VjIGVuY3J5cHRpb24gb2YNCiAgIHJlbGF5IHRvIHNlcnZlciBjb21tdW5pY2F0aW9uLg0KDQpX aXRoIHNvbWV0aGluZyBsaWtlOg0KDQogICBGb3IgREhDUHY2IFtSRkMzMzE1XSwgdGhpcyBzcGVj aWZpY2F0aW9uIFJFUVVJUkVTIHJlbGF5IGFuZCBzZXJ2ZXINCiAgIGltcGxlbWVudGF0aW9ucyB0 byBzdXBwb3J0IElQc2VjIGVuY3J5cHRpb24gb2YgcmVsYXkgdG8gcmVsYXkgYW5kDQogICByZWxh eSB0byBzZXJ2ZXIgY29tbXVuaWNhdGlvbiBhcyBkb2N1bWVudGVkIGJlbG93ICh0aGlzIHJlcGxh Y2VzDQogICB0aGUgdGV4dCBpbiBSRkMzMzE1IFNlY3Rpb24gMjEuMSkuDQoNCiAgIEZvciBESENQ djQgW1JGQzIxMzFdLCB0aGlzIHNwZWNpZmljYXRpb24gUkVRVUlSRVMgcmVsYXkgYW5kIHNlcnZl cg0KICAgaW1wbGVtZW50YXRpb25zIHRvIHN1cHBvcnQgSVBzZWMgZW5jcnlwdGlvbiBvZiByZWxh eSB0byBzZXJ2ZXINCiAgIGNvbW11bmljYXRpb24gYXMgZG9jdW1lbnRlZCBiZWxvdy4NCg0KICAg VGhpcyBzcGVjaWZpY2F0aW9uIFJFQ09NTUVORFMgdGhhdCBvcGVyYXRvcnMgZW5hYmxlIElQc2Vj IGZvciB0aGlzIA0KICAgY29tbXVuaWNhdGlvbi4NCg0KLSBCZXJuaWUgVm9seg0KDQo= From nobody Tue Apr 11 14:17: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 7A0701201F8 for ; Tue, 11 Apr 2017 14:17:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 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, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 qEvelWAgHr_M for ; Tue, 11 Apr 2017 14:17:02 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::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 73FF1126D73 for ; Tue, 11 Apr 2017 14:17:00 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id l189so4362743ywb.0 for ; Tue, 11 Apr 2017 14:17:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tr4E5WgFssxuU3vYBBJACRzfVlfKjLzJy4JrOlyOw8w=; b=ipGSROXTOj7cA+bhFrHVnZChxd3H0SFtW7zSPi0gvWEfGmBjxVyFeOZOXSJ4YgCPT5 ukz/Gw5N/FodhZAJW0VN/nMgl9C7VS0rlg41wSkgMjNfgPqdtfk1y/kTDgtV+G6QMZFJ QSTyzPT6hCbZsgjdR4IfFio6tsWC9ERdSuzFSwrDTcnOZzfhUJIlB6kLwlvel/zCjnd6 N7sfT7H7xJzpCJ5zkQi2MHvFa7S4w7C9zg9dVzVhkWHk+cdn8bvhBgNFcptFWx2UpwkD Fg3dC1FsFfmnrFtz74vasuFoDer4NhJayokX1OWPQuZWGQOrlBgA8fiOsLFNIasxe1mJ pE9Q== 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=tr4E5WgFssxuU3vYBBJACRzfVlfKjLzJy4JrOlyOw8w=; b=eHAOGBon7edsjqRnTzceXU7JXyDrZOX4bZqM28BZg93ow+RcS6nrvuwZoQLk9+qF/d K40oUYHFEqIzFWlszVZJhVbhI21POAFPsry6kJc8cTDMRv1WMSXJTgNIGaOx94YDotUd KrODKC/Gk7i4uNKuEE5/gs575IQWo7tXXHOPjr8wu7ZEPc5KCyCioS5zHmuKGBaA7kWa z+SeocdLHMeBgoKOMzWnQak+So2M2GcKEQC4EKTwYpsFAU7OXdjRibxgZdwwhxeB9FG3 2dVPYtasgKFEHCaq56H05s3CS7d90Z0G3LO0N2Rz8XqJY2quODJdf2YT8wGMlTL15woa aLWA== X-Gm-Message-State: AFeK/H0Bp9sJxEb0S15PqEi6mK2SHGpldCMr7aY/rYSgDfotuBdjHxBtxgUDrVIPpEYJHZnnKEUjpGwLemn2XQ== X-Received: by 10.129.125.5 with SMTP id y5mr40368899ywc.120.1491945419617; Tue, 11 Apr 2017 14:16:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.113.7 with HTTP; Tue, 11 Apr 2017 14:16:19 -0700 (PDT) In-Reply-To: <5320BC41-545C-4510-89AC-9C62460E80CA@cisco.com> References: <5320BC41-545C-4510-89AC-9C62460E80CA@cisco.com> From: Eric Rescorla Date: Tue, 11 Apr 2017 14:16:19 -0700 Message-ID: To: "Bernie Volz (volz)" Cc: The IESG , Tomek Mrugalski , "dhc-chairs@ietf.org" , "draft-ietf-dhc-relay-server-security@ietf.org" , "dhcwg@ietf.org" Content-Type: multipart/alternative; boundary=001a11493644c35b9c054cea9c5a Archived-At: Subject: Re: [dhcwg] Discusses on draft-ietf-dhc-relay-server-security-04 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, 11 Apr 2017 21:17:04 -0000 --001a11493644c35b9c054cea9c5a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Apr 11, 2017 at 1:46 PM, Bernie Volz (volz) wrote: > Hi: > > Regarding the discusses: > > 1. Eric Rescorla Discuss (2017-04-07) > What's not clear to me from reading this document is whether anyone > actually does IPsec for DHCP relaying. If so, what configurations do > they run it in? If not, will they do so as the result of this > document? > > Answer: I do not know if anyone actually uses IPsec. The RFC3315 mechanis= m > was optional and did not provide encryption so it may not have ever been > used. Therefore, I do not know what anyone actually does today (if > anything). Those using DHCP that I am aware of with relays do not. > This seems like a fairly strong argument against mandating it. -Ekr > > The hope is that more would use this more robust version, and those > operators that find it important to do so will require it of their relay > and server vendors by purchasing implementations that support this > to-be-RFC. > > 2. Warren Kumari Discuss (2017-04-08) > This document says that it "replaces the text in RFC3315 Section 21.1.", > but it does not have an Updates tag. It is also contains a large blob of > RFC3315, with clear explanation of what exactly changed. > > ANSWER: If we said Updates, that would mean it would likely become a new > required standard for those implementing RFC 3315. For many DHCP items, w= e > only use the Updates tag when there is a =E2=80=9Crequired=E2=80=9D chang= e in earlier > documents. This is not =E2=80=9Crequired=E2=80=9D =E2=80=93 it is an opti= onal feature that vendors > can chose to implement and operators can choose to use/require of their > vendors to implement. Regarding the text, much of it is similar to what w= as > in RFC 3315 because it is specifying the full IPsec specification. The ma= in > things that changed are that it is required (if you want to claim > conformance to this to-be-RFC, whereas if you say you comply with 3315 > there is no requirement to implement IPsec) and the use of encryption. > > > The writeup says "Even though this I-D introduces changes to RFC3315, the > WG doesn't want to enforce IPsec encryption on every DHCPv6 server. > Therefore, it does not update RFC3315." -- so, if I'm writing a new DHCPv= 6 > implementation, do I need to support this? The document reads like it tri= es > to update 3315, but the writeup says otherwise -- once published, no-one > will read the shepherd writeup. I think that the document itself needs to > be clearer that this is an optional extension (so if I want to buy an > implementation which does this, I ask for RFC3315 and RFCxxxx). > > ANSWER: Whether you implement this IPsec requirement in the to-be-RFC is > an implementation choice. There is no requirement to implement this > to-be-RFC. And operators that wish to use IPsec must require their vendor= s > to implement this to-be-RFC. So there would be implementation that comply > with RFC 3315 and this-to-be-RFC. This will make it clear to anyone > desiring relays or servers whether they can use IPsec based on whether th= ey > implement this-to-be-RFC. This is not much different than other DHCP > extensions =E2=80=93 such as Bulk or Active Leaseuquery =E2=80=93 these a= re not part of the > base specification but OPTIONAL features documented in other RFCs. > > > I also do not understand the relationship between this document (which > talks about text RFC3315), and draft-ietf-dhc-rfc3315bis (which is > currently in WGLC) -- if rfc3315bis is almost done, should this reference > that instead? Or should rfc3315bis simply incorporate this? > > ANSWER: 3315bis has this exact same text EXCEPT it is optional. When > working on 3315bis we did not feel that it was worth documenting the old > IPsec =E2=80=9Crules=E2=80=9D from 3315 as they were weak and not very us= eful. But again, > we did not want to make IPsec required as part of 3315bis. Also, we wante= d > this to-be-RFC to be available sooner than 3315bis might be. We could > certainly discuss REMOVING IPsec text from 3315bis and just referring to > this to-be-RFC. That in the end may be cleaner. > > > Comment (2017-04-08) > I found the document confusing -- it says that it REQUIRES IPsec for > DHCPv4 and DHCPv6, but it reads like it is requiring that operators enabl= e > this, not that implementations have to support this; what exactly is is > trying to do? > I think that it would be much clearer if it said that implementations of > this document must support IPsec and that operators are recommended to > enable it (assuming that it what it means). > > ANSWER: Is it both =E2=80=93 for vendors to implement and for operators t= o use. It > requires both because of key management. If you prefer we can certainly a= dd > a sentence or reword some existing text to says =E2=80=9Cimplementations = of this > document must support IPsec and that operators are recommended to enable > it=E2=80=9D. Perhaps replace: > > For DHCPv6 [RFC3315], this specification REQUIRES IPsec encryption of > relay to relay and relay to server communication and replaces the > text in RFC3315 Section 21.1. > > For DHCPv4 [RFC2131], this specification REQUIRES IPsec encryption of > relay to server communication. > > With something like: > > For DHCPv6 [RFC3315], this specification REQUIRES relay and server > implementations to support IPsec encryption of relay to relay and > relay to server communication as documented below (this replaces > the text in RFC3315 Section 21.1). > > For DHCPv4 [RFC2131], this specification REQUIRES relay and server > implementations to support IPsec encryption of relay to server > communication as documented below. > > This specification RECOMMENDS that operators enable IPsec for this > communication. > > - Bernie Volz > > --001a11493644c35b9c054cea9c5a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Apr 11, 2017 at 1:46 PM, Bernie Volz (volz) &= lt;volz@cisco.com&g= t; wrote:
Hi:

Regarding the discusses:

1. Eric Rescorla Discuss (2017-04-07)
What's not clear to me from reading this document is whether anyone
actually does IPsec for DHCP relaying. If so, what configurations do
they run it in? If not, will they do so as the result of this
document?

Answer: I do not know if anyone actually uses IPsec. The RFC3315 mechanism = was optional and did not provide encryption so it may not have ever been us= ed. Therefore, I do not know what anyone actually does today (if anything).= Those using DHCP that I am aware of with relays do not.

This seems like a fairly strong argument against mandatin= g it.

-Ekr
=C2=A0

The hope is that more would use this more robust version, and those operato= rs that find it important to do so will require it of their relay and serve= r vendors by purchasing implementations that support this to-be-RFC.

2. Warren Kumari Discuss (2017-04-08)
This document says that it "replaces the text in RFC3315 Section 21.1.= ", but it does not have an Updates tag. It is also contains a large bl= ob of RFC3315, with clear explanation of what exactly changed.

ANSWER: If we said Updates, that would mean it would likely become a new re= quired standard for those implementing RFC 3315. For many DHCP items, we on= ly use the Updates tag when there is a =E2=80=9Crequired=E2=80=9D change in= earlier documents. This is not =E2=80=9Crequired=E2=80=9D =E2=80=93 it is = an optional feature that vendors can chose to implement and operators can c= hoose to use/require of their vendors to implement. Regarding the text, muc= h of it is similar to what was in RFC 3315 because it is specifying the ful= l IPsec specification. The main things that changed are that it is required= (if you want to claim conformance to this to-be-RFC, whereas if you say yo= u comply with 3315 there is no requirement to implement IPsec) and the use = of encryption.


The writeup says "Even though this I-D introduces changes to RFC3315, = the WG doesn't want to enforce IPsec encryption on every DHCPv6 server.= Therefore, it does not update RFC3315." -- so, if I'm writing a n= ew DHCPv6 implementation, do I need to support this? The document reads lik= e it tries to update 3315, but the writeup says otherwise -- once published= , no-one will read the shepherd writeup. I think that the document itself n= eeds to be clearer that this is an optional extension (so if I want to buy = an implementation which does this, I ask for RFC3315 and RFCxxxx).

ANSWER: Whether you implement this IPsec requirement in the to-be-RFC is an= implementation choice. There is no requirement to implement this to-be-RFC= . And operators that wish to use IPsec must require their vendors to implem= ent this to-be-RFC. So there would be implementation that comply with RFC 3= 315 and this-to-be-RFC. This will make it clear to anyone desiring relays o= r servers whether they can use IPsec based on whether they implement this-t= o-be-RFC. This is not much different than other DHCP extensions =E2=80=93 s= uch as Bulk or Active Leaseuquery =E2=80=93 these are not part of the base = specification but OPTIONAL features documented in other RFCs.


I also do not understand the relationship between this document (which talk= s about text RFC3315), and draft-ietf-dhc-rfc3315bis (which is currently in= WGLC) -- if rfc3315bis is almost done, should this reference that instead?= Or should rfc3315bis simply incorporate this?

ANSWER: 3315bis has this exact same text EXCEPT it is optional. When workin= g on 3315bis we did not feel that it was worth documenting the old IPsec = =E2=80=9Crules=E2=80=9D from 3315 as they were weak and not very useful. Bu= t again, we did not want to make IPsec required as part of 3315bis. Also, w= e wanted this to-be-RFC to be available sooner than 3315bis might be. We co= uld certainly discuss REMOVING IPsec text from 3315bis and just referring t= o this to-be-RFC. That in the end may be cleaner.


Comment (2017-04-08)
I found the document confusing -- it says that it REQUIRES IPsec for DHCPv4= and DHCPv6, but it reads like it is requiring that operators enable this, = not that implementations have to support this; what exactly is is trying to= do?
I think that it would be much clearer if it said that implementations of th= is document must support IPsec and that operators are recommended to enable= it (assuming that it what it means).

ANSWER: Is it both =E2=80=93 for vendors to implement and for operators to = use. It requires both because of key management. If you prefer we can certa= inly add a sentence or reword some existing text to says =E2=80=9Cimplement= ations of this document must support IPsec and that operators are recommend= ed to enable it=E2=80=9D. Perhaps replace:

=C2=A0 =C2=A0For DHCPv6 [RFC3315], this specification REQUIRES IPsec encryp= tion of
=C2=A0 =C2=A0relay to relay and relay to server communication and replaces = the
=C2=A0 =C2=A0text in RFC3315 Section 21.1.

=C2=A0 =C2=A0For DHCPv4 [RFC2131], this specification REQUIRES IPsec encryp= tion of
=C2=A0 =C2=A0relay to server communication.

With something like:

=C2=A0 =C2=A0For DHCPv6 [RFC3315], this specification REQUIRES relay and se= rver
=C2=A0 =C2=A0implementations to support IPsec encryption of relay to relay = and
=C2=A0 =C2=A0relay to server communication as documented below (this replac= es
=C2=A0 =C2=A0the text in RFC3315 Section 21.1).

=C2=A0 =C2=A0For DHCPv4 [RFC2131], this specification REQUIRES relay and se= rver
=C2=A0 =C2=A0implementations to support IPsec encryption of relay to server=
=C2=A0 =C2=A0communication as documented below.

=C2=A0 =C2=A0This specification RECOMMENDS that operators enable IPsec for = this
=C2=A0 =C2=A0communication.

- Bernie Volz


--001a11493644c35b9c054cea9c5a-- From nobody Tue Apr 11 14:21:10 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 6FCCF129AC5; Tue, 11 Apr 2017 14:20:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Kathleen Moriarty To: "The IESG" Cc: draft-ietf-dhc-relay-server-security@ietf.org, Tomek Mrugalski , dhc-chairs@ietf.org, tomasz.mrugalski@gmail.com, dhcwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149194565444.15645.8956016947252770577.idtracker@ietfa.amsl.com> Date: Tue, 11 Apr 2017 14:20:54 -0700 Archived-At: Subject: [dhcwg] Kathleen Moriarty's Yes on draft-ietf-dhc-relay-server-security-04: (with COMMENT) 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: Tue, 11 Apr 2017 21:20:54 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-dhc-relay-server-security-04: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dhc-relay-server-security/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you very much for your work on this document. Once Warren's discuss has been cleared with adequate clarifications and 'updates' text, which I support, this will be a helpful document. It will be very nice to no longer have the discussion as to why encryption is not required for DHCP, this is a welcome and overdue change. From nobody Tue Apr 11 14:28:08 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 936D7126DC2; Tue, 11 Apr 2017 14:28:05 -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: <149194608556.15690.4054762439570171581@ietfa.amsl.com> Date: Tue, 11 Apr 2017 14:28:05 -0700 Archived-At: Subject: [dhcwg] I-D Action: draft-ietf-dhc-relay-port-03.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: Tue, 11 Apr 2017 21:28:06 -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 : Generalized UDP Source Port for DHCP Relay Authors : Naiming Shen Enke Chen Filename : draft-ietf-dhc-relay-port-03.txt Pages : 10 Date : 2017-04-11 Abstract: This document proposes an extension to the DHCP and DHCPv6 protocols that allows any valid number to be used as the relay agent's UDP source port for DHCP packets. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-relay-port/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dhc-relay-port-03 https://datatracker.ietf.org/doc/html/draft-ietf-dhc-relay-port-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-relay-port-03 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 Tue Apr 11 14:35: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 5C95A129AD0 for ; Tue, 11 Apr 2017 14:35:11 -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 JpRuZcODbaBY for ; Tue, 11 Apr 2017 14:35:09 -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 A3C8E1200C5 for ; Tue, 11 Apr 2017 14:35:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11194; q=dns/txt; s=iport; t=1491946509; x=1493156109; h=from:to:subject:date:message-id:references:mime-version; bh=kvskTEVmd8hG+GnaZ7aaDEM4o0tMlm/JUsfuB+R27yk=; b=Hx3i1hKa4AJy49Pepz6d4jASWPSM1ekP/nF/iX1Gte07WN9MiJkc2npx iq3kPbk61jwFKetHoudN50hWpMtqangU5+HZi7Z+6WiE0CiY9D2bstFfQ bpGb6YKdYqR/FQxz0DwtUfWv2l7ykrDqfkExsImAEbPVLut5mk9p1FTVu w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AyAwCPS+1Y/5FdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1NhgQsHg1+KE5ExH5AkhTSCDyEBCoV4AhqDST8YAQIBAQEBAQE?= =?us-ascii?q?BayiFFQEDAwEBIUsbAgEZAwECKAMCAgIlCxQHAggCBBOKEA6pGoIminkBAQEBA?= =?us-ascii?q?QEEAQEBAQEBAQEBH4hVCYJigxeBKTYWglAugjEFliOGXAGGf4tegX9VhFmIXYE?= =?us-ascii?q?6lAABHziBBVsVGCkRAYZIdYggAYEMAQEB?= X-IronPort-AV: E=Sophos;i="5.37,187,1488844800"; d="scan'208,217";a="409790238" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Apr 2017 21:34:47 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v3BLYk7g011713 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 11 Apr 2017 21:34:46 GMT Received: from xch-rcd-004.cisco.com (173.37.102.14) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 11 Apr 2017 16:34:46 -0500 Received: from xch-rcd-004.cisco.com ([173.37.102.14]) by XCH-RCD-004.cisco.com ([173.37.102.14]) with mapi id 15.00.1210.000; Tue, 11 Apr 2017 16:34:46 -0500 From: "Naiming Shen (naiming)" To: dhcwg Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-relay-port-03.txt Thread-Index: AQHSswqGjby8tYanrEe29E5GefF3IQ== Date: Tue, 11 Apr 2017 21:34:46 +0000 Message-ID: References: <149194608556.15690.4054762439570171581@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [128.107.155.109] Content-Type: multipart/alternative; boundary="_000_A3C1CDA7654C43729E1ADC05282EFE9Dciscocom_" MIME-Version: 1.0 Archived-At: Subject: [dhcwg] Fwd: I-D Action: draft-ietf-dhc-relay-port-03.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: Tue, 11 Apr 2017 21:35:11 -0000 --_000_A3C1CDA7654C43729E1ADC05282EFE9Dciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpIaSBESEMgV0csDQoNCldlIGhhdmUgdXBkYXRlZCB0aGUgZHJhZnQgdG8gMDMgdmVyc2lvbiBy ZXNwb25kaW5nIHRvIHRoZSBjb21tZW50cw0KbWFkZSBzbyBmYXIgZHJ1aW5nIHRoZSBXR0xDLiBU aGUgdGV4dCBvZiByZWxheSBhZ2VudCBhbmQgc2VydmVyIGJlaGF2aW9yDQpoYXMgYmVlbiBtb3Zl ZCBvdXQgZnJvbSByZWxheSBvcHRpb24gZGVmaW5pdGlvbiBwYXJ0IGludG8gYSBuZXcgc2VjdGlv bg0K4oCcUmVsYXkgQWdlbnQgYW5kIFNlcnZlciBCZWhhdmlvcuKAnS4NCg0KUGxlYXNlIHJldmll dyBhbmQgY29tbWVudC4NCg0KQmVzdCBSZWdhcmRzLA0KLSBOYWltaW5nDQoNCkJlZ2luIGZvcndh cmRlZCBtZXNzYWdlOg0KDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmlu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4NClN1YmplY3Q6IFtkaGN3Z10gSS1EIEFjdGlvbjogZHJh ZnQtaWV0Zi1kaGMtcmVsYXktcG9ydC0wMy50eHQNCkRhdGU6IEFwcmlsIDExLCAyMDE3IGF0IDI6 Mjg6MDUgUE0gUERUDQpUbzogPGktZC1hbm5vdW5jZUBpZXRmLm9yZzxtYWlsdG86aS1kLWFubm91 bmNlQGlldGYub3JnPj4NCkNjOiBkaGN3Z0BpZXRmLm9yZzxtYWlsdG86ZGhjd2dAaWV0Zi5vcmc+ DQoNCg0KQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUg SW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBv ZiB0aGUgRHluYW1pYyBIb3N0IENvbmZpZ3VyYXRpb24gb2YgdGhlIElFVEYuDQoNCiAgICAgICBU aXRsZSAgICAgICAgICAgOiBHZW5lcmFsaXplZCBVRFAgU291cmNlIFBvcnQgZm9yIERIQ1AgUmVs YXkNCiAgICAgICBBdXRob3JzICAgICAgICAgOiBOYWltaW5nIFNoZW4NCiAgICAgICAgICAgICAg ICAgICAgICAgICBFbmtlIENoZW4NCkZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtZGhjLXJl bGF5LXBvcnQtMDMudHh0DQpQYWdlcyAgICAgICAgICAgOiAxMA0KRGF0ZSAgICAgICAgICAgIDog MjAxNy0wNC0xMQ0KDQpBYnN0cmFjdDoNCiAgVGhpcyBkb2N1bWVudCBwcm9wb3NlcyBhbiBleHRl bnNpb24gdG8gdGhlIERIQ1AgYW5kIERIQ1B2NiBwcm90b2NvbHMNCiAgdGhhdCBhbGxvd3MgYW55 IHZhbGlkIG51bWJlciB0byBiZSB1c2VkIGFzIHRoZSByZWxheSBhZ2VudCdzIFVEUA0KICBzb3Vy Y2UgcG9ydCBmb3IgREhDUCBwYWNrZXRzLg0KDQoNClRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1 cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtaWV0Zi1kaGMtcmVsYXktcG9ydC8NCg0KVGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQg dmVyc2lvbnMgYXZhaWxhYmxlIGF0Og0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtZGhjLXJlbGF5LXBvcnQtMDMNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2h0bWwvZHJhZnQtaWV0Zi1kaGMtcmVsYXktcG9ydC0wMw0KDQpBIGRpZmYgZnJvbSB0aGUgcHJl dmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQpodHRwczovL3d3dy5pZXRmLm9yZy9yZmNk aWZmP3VybDI9ZHJhZnQtaWV0Zi1kaGMtcmVsYXktcG9ydC0wMw0KDQoNClBsZWFzZSBub3RlIHRo YXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1p c3Npb24NCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUg YXQgdG9vbHMuaWV0Zi5vcmcuDQoNCkludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUg YnkgYW5vbnltb3VzIEZUUCBhdDoNCmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMv DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpkaGN3 ZyBtYWlsaW5nIGxpc3QNCmRoY3dnQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2RoY3dnDQoNCg== --_000_A3C1CDA7654C43729E1ADC05282EFE9Dciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <2E0EC37C68954D4B962B0E3D8E0E1E4B@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCkhpIERIQyBXRywNCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPldlIGhhdmUgdXBkYXRlZCB0aGUgZHJhZnQgdG8gMDMgdmVy c2lvbiByZXNwb25kaW5nIHRvIHRoZSBjb21tZW50czwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5tYWRl IHNvIGZhciBkcnVpbmcgdGhlIFdHTEMuIFRoZSB0ZXh0IG9mIHJlbGF5IGFnZW50IGFuZCBzZXJ2 ZXIgYmVoYXZpb3I8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+aGFzIGJlZW4gbW92ZWQgb3V0IGZyb20g cmVsYXkgb3B0aW9uIGRlZmluaXRpb24gcGFydCBpbnRvIGEgbmV3IHNlY3Rpb248L2Rpdj4NCjxk aXYgY2xhc3M9IiI+4oCcUmVsYXkgQWdlbnQgYW5kIFNlcnZlciBCZWhhdmlvcuKAnS48L2Rpdj4N CjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlBsZWFz ZSByZXZpZXcgYW5kIGNvbW1lbnQuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5CZXN0IFJlZ2FyZHMsPC9kaXY+DQo8ZGl2IGNsYXNzPSIi Pi0gTmFpbWluZzxiciBjbGFzcz0iIj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPkJlZ2luIGZvcndhcmRlZCBtZXNz YWdlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYg c3R5bGU9Im1hcmdpbi10b3A6IDBweDsgbWFyZ2luLXJpZ2h0OiAwcHg7IG1hcmdpbi1ib3R0b206 IDBweDsgbWFyZ2luLWxlZnQ6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiAtd2Via2l0LXN5c3RlbS1mb250LCBIZWx2ZXRpY2EgTmV1ZSwgSGVsdmV0aWNhLCBzYW5z LXNlcmlmOyBjb2xvcjpyZ2JhKDAsIDAsIDAsIDEuMCk7IiBjbGFzcz0iIj48YiBjbGFzcz0iIj5G cm9tOg0KPC9iPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3lzdGVt LWZvbnQsIEhlbHZldGljYSBOZXVlLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj48 YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIiBjbGFzcz0iIj5pbnRlcm5l dC1kcmFmdHNAaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KPC9zcGFuPjwvZGl2Pg0KPGRpdiBz dHlsZT0ibWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tcmlnaHQ6IDBweDsgbWFyZ2luLWJvdHRvbTog MHB4OyBtYXJnaW4tbGVmdDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6IC13ZWJraXQtc3lzdGVtLWZvbnQsIEhlbHZldGljYSBOZXVlLCBIZWx2ZXRpY2EsIHNhbnMt c2VyaWY7IGNvbG9yOnJnYmEoMCwgMCwgMCwgMS4wKTsiIGNsYXNzPSIiPjxiIGNsYXNzPSIiPlN1 YmplY3Q6DQo8L2I+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogLXdlYmtpdC1zeXN0 ZW0tZm9udCwgSGVsdmV0aWNhIE5ldWUsIEhlbHZldGljYSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIi PjxiIGNsYXNzPSIiPltkaGN3Z10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1kaGMtcmVsYXktcG9y dC0wMy50eHQ8L2I+PGJyIGNsYXNzPSIiPg0KPC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFy Z2luLXRvcDogMHB4OyBtYXJnaW4tcmlnaHQ6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyBtYXJn aW4tbGVmdDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJr aXQtc3lzdGVtLWZvbnQsIEhlbHZldGljYSBOZXVlLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IGNv bG9yOnJnYmEoMCwgMCwgMCwgMS4wKTsiIGNsYXNzPSIiPjxiIGNsYXNzPSIiPkRhdGU6DQo8L2I+ PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogLXdlYmtpdC1zeXN0ZW0tZm9udCwgSGVs dmV0aWNhIE5ldWUsIEhlbHZldGljYSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPkFwcmlsIDExLCAy MDE3IGF0IDI6Mjg6MDUgUE0gUERUPGJyIGNsYXNzPSIiPg0KPC9zcGFuPjwvZGl2Pg0KPGRpdiBz dHlsZT0ibWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tcmlnaHQ6IDBweDsgbWFyZ2luLWJvdHRvbTog MHB4OyBtYXJnaW4tbGVmdDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6IC13ZWJraXQtc3lzdGVtLWZvbnQsIEhlbHZldGljYSBOZXVlLCBIZWx2ZXRpY2EsIHNhbnMt c2VyaWY7IGNvbG9yOnJnYmEoMCwgMCwgMCwgMS4wKTsiIGNsYXNzPSIiPjxiIGNsYXNzPSIiPlRv Og0KPC9iPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3lzdGVtLWZv bnQsIEhlbHZldGljYSBOZXVlLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4mbHQ7 PGEgaHJlZj0ibWFpbHRvOmktZC1hbm5vdW5jZUBpZXRmLm9yZyIgY2xhc3M9IiI+aS1kLWFubm91 bmNlQGlldGYub3JnPC9hPiZndDs8YnIgY2xhc3M9IiI+DQo8L3NwYW4+PC9kaXY+DQo8ZGl2IHN0 eWxlPSJtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1yaWdodDogMHB4OyBtYXJnaW4tYm90dG9tOiAw cHg7IG1hcmdpbi1sZWZ0OiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTogLXdlYmtpdC1zeXN0ZW0tZm9udCwgSGVsdmV0aWNhIE5ldWUsIEhlbHZldGljYSwgc2Fucy1z ZXJpZjsgY29sb3I6cmdiYSgwLCAwLCAwLCAxLjApOyIgY2xhc3M9IiI+PGIgY2xhc3M9IiI+Q2M6 DQo8L2I+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogLXdlYmtpdC1zeXN0ZW0tZm9u dCwgSGVsdmV0aWNhIE5ldWUsIEhlbHZldGljYSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPjxhIGhy ZWY9Im1haWx0bzpkaGN3Z0BpZXRmLm9yZyIgY2xhc3M9IiI+ZGhjd2dAaWV0Zi5vcmc8L2E+PGJy IGNsYXNzPSIiPg0KPC9zcGFuPjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4N CjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZh aWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLjxiciBj bGFzcz0iIj4NClRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIER5bmFtaWMgSG9zdCBD b25maWd1cmF0aW9uIG9mIHRoZSBJRVRGLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1RpdGxlICZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzogR2VuZXJh bGl6ZWQgVURQIFNvdXJjZSBQb3J0IGZvciBESENQIFJlbGF5PGJyIGNsYXNzPSIiPg0KJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7QXV0aG9ycyAmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs6IE5haW1pbmcgU2hlbjxiciBjbGFz cz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0Vua2UgQ2hlbjxiciBj bGFzcz0iIj4NCjxzcGFuIGNsYXNzPSJBcHBsZS10YWItc3BhbiIgc3R5bGU9IndoaXRlLXNwYWNl OnByZSI+PC9zcGFuPkZpbGVuYW1lICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOzogZHJhZnQtaWV0Zi1kaGMtcmVsYXktcG9ydC0wMy50eHQ8YnIgY2xhc3M9IiI+DQo8 c3BhbiBjbGFzcz0iQXBwbGUtdGFiLXNwYW4iIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUiPjwvc3Bh bj5QYWdlcyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDs6IDEwPGJyIGNsYXNzPSIiPg0KPHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1zcGFu IiBzdHlsZT0id2hpdGUtc3BhY2U6cHJlIj48L3NwYW4+RGF0ZSAmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs6IDIwMTctMDQt MTE8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpBYnN0cmFjdDo8YnIgY2xhc3M9IiI+DQom bmJzcDsmbmJzcDtUaGlzIGRvY3VtZW50IHByb3Bvc2VzIGFuIGV4dGVuc2lvbiB0byB0aGUgREhD UCBhbmQgREhDUHY2IHByb3RvY29sczxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwO3RoYXQgYWxs b3dzIGFueSB2YWxpZCBudW1iZXIgdG8gYmUgdXNlZCBhcyB0aGUgcmVsYXkgYWdlbnQncyBVRFA8 YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDtzb3VyY2UgcG9ydCBmb3IgREhDUCBwYWNrZXRzLjxi ciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClRoZSBJRVRGIGRhdGF0 cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOjxiciBjbGFzcz0iIj4NCjxhIGhy ZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtZGhjLXJlbGF5 LXBvcnQvIiBjbGFzcz0iIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1p ZXRmLWRoYy1yZWxheS1wb3J0LzwvYT48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGVy ZSBhcmUgYWxzbyBodG1saXplZCB2ZXJzaW9ucyBhdmFpbGFibGUgYXQ6PGJyIGNsYXNzPSIiPg0K aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZGhjLXJlbGF5LXBvcnQtMDM8 YnIgY2xhc3M9IiI+DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0 LWlldGYtZGhjLXJlbGF5LXBvcnQtMDM8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpBIGRp ZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6PGJyIGNsYXNzPSIi Pg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtZGhjLXJlbGF5 LXBvcnQtMDM8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpQbGVh c2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGlt ZSBvZiBzdWJtaXNzaW9uPGJyIGNsYXNzPSIiPg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24g YW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy48YnIgY2xhc3M9IiI+DQo8 YnIgY2xhc3M9IiI+DQpJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255 bW91cyBGVFAgYXQ6PGJyIGNsYXNzPSIiPg0KZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRy YWZ0cy88YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxiciBjbGFzcz0iIj4NCmRoY3dnIG1haWxpbmcgbGlz dDxiciBjbGFzcz0iIj4NCmRoY3dnQGlldGYub3JnPGJyIGNsYXNzPSIiPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaGN3ZzxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_A3C1CDA7654C43729E1ADC05282EFE9Dciscocom_-- From nobody Tue Apr 11 15:17:30 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 CFE2C1276AF for ; Tue, 11 Apr 2017 15:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.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 xCCwItStlvAg for ; Tue, 11 Apr 2017 15:17:27 -0700 (PDT) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::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 CB8E6124D6C for ; Tue, 11 Apr 2017 15:17:26 -0700 (PDT) Received: by mail-qt0-x22d.google.com with SMTP id c45so9488580qtb.1 for ; Tue, 11 Apr 2017 15:17:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=hJ9Q4GvKr7mBpVGGi0n8e4gELgk8ZMTzKGZdtxhRzvg=; b=a7kdo6CKWEqPYne/Rigml56ZH9TKZBfdyCErJyyo7SwNCnKClxbU8sODkodJr3nGv1 p9upy/H5KFUR4iLbl9uEWfHXek0oulVwBgZDI5IjL72kcZEBSK8quCe47MGAkSvk5eTh cw2cZUIGCmwefOeyoLZb3CK8qtDp7o8OE3BWzNpcWA8tQ/uQaxyMlHbfsyyURbREM9Lt SrNpCwPm6iF0x34PM1Re8DLaY2XnMRMFzSNgZJheyZCyUQaOIgiLod7j0K9iM4bnn78H pXdPh89faAYIE4+hqZBGoTaa3tgkTNOUGMswl56et6tAKG8udzhpEkfwqK+ioFRvCyQ1 HbPg== 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:content-transfer-encoding; bh=hJ9Q4GvKr7mBpVGGi0n8e4gELgk8ZMTzKGZdtxhRzvg=; b=GF52wDuBcsB6laJ4lgQJZyz7McYAewJcpLHIgcC1onkRgbSKSeLQHqY6sCnyWtcdPm OxpbOwkoVW/tUpmx0BzQIg3kxPaycdvjIaEshHrU147PG0NhqikKqZ7kWEwcPmeAjxa6 eef0JDPZr3VULDig+PNqhLm/yKOTpaluVSAJFQS/3lFiKK665/8uusnVeUK+qIoYNHM+ UUFaHmXfvGyOVANq+VLc0RgYlViMeSE93c5fK8xFnT+2Izzy3pVcIKYcNWqStjxcCuoO 4jDggMR646y1wnB1BW+e0Ue5O53Zk8N/MFDsnjef4GxMJo9xa0mdAoX1BPZ2/JXTyUOn RPIw== X-Gm-Message-State: AN3rC/4vpKwUw8qeN9mjwi/WBnIXEykaQ3mg0dA4iAFfAR5Cu8l8BALIAgHhE7VBUBn9FaX4ALA7wpsrwJcQlD0h X-Received: by 10.200.55.13 with SMTP id o13mr14345347qtb.57.1491949045766; Tue, 11 Apr 2017 15:17:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.183.136 with HTTP; Tue, 11 Apr 2017 15:16:45 -0700 (PDT) In-Reply-To: <5320BC41-545C-4510-89AC-9C62460E80CA@cisco.com> References: <5320BC41-545C-4510-89AC-9C62460E80CA@cisco.com> From: Warren Kumari Date: Tue, 11 Apr 2017 18:16:45 -0400 Message-ID: To: "Bernie Volz (volz)" Cc: The IESG , Tomek Mrugalski , "dhc-chairs@ietf.org" , "draft-ietf-dhc-relay-server-security@ietf.org" , "dhcwg@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [dhcwg] Discusses on draft-ietf-dhc-relay-server-security-04 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, 11 Apr 2017 22:17:29 -0000 On Tue, Apr 11, 2017 at 4:46 PM, Bernie Volz (volz) wrote: > Hi: > > Regarding the discusses: > > 1. Eric Rescorla Discuss (2017-04-07) > What's not clear to me from reading this document is whether anyone > actually does IPsec for DHCP relaying. If so, what configurations do > they run it in? If not, will they do so as the result of this > document? > > Answer: I do not know if anyone actually uses IPsec. The RFC3315 mechanis= m was optional and did not provide encryption so it may not have ever been = used. Therefore, I do not know what anyone actually does today (if anything= ). Those using DHCP that I am aware of with relays do not. > > The hope is that more would use this more robust version, and those opera= tors that find it important to do so will require it of their relay and ser= ver vendors by purchasing implementations that support this to-be-RFC. > > 2. Warren Kumari Discuss (2017-04-08) > This document says that it "replaces the text in RFC3315 Section 21.1.", = but it does not have an Updates tag. It is also contains a large blob of RF= C3315, with clear explanation of what exactly changed. > > ANSWER: If we said Updates, that would mean it would likely become a new = required standard for those implementing RFC 3315. For many DHCP items, we = only use the Updates tag when there is a =E2=80=9Crequired=E2=80=9D change = in earlier documents. This is not =E2=80=9Crequired=E2=80=9D =E2=80=93 it i= s an optional feature that vendors can chose to implement and operators can= choose to use/require of their vendors to implement. Regarding the text, m= uch of it is similar to what was in RFC 3315 because it is specifying the f= ull IPsec specification. The main things that changed are that it is requir= ed (if you want to claim conformance to this to-be-RFC, whereas if you say = you comply with 3315 there is no requirement to implement IPsec) and the us= e of encryption. > > > The writeup says "Even though this I-D introduces changes to RFC3315, the= WG doesn't want to enforce IPsec encryption on every DHCPv6 server. Theref= ore, it does not update RFC3315." -- so, if I'm writing a new DHCPv6 implem= entation, do I need to support this? The document reads like it tries to up= date 3315, but the writeup says otherwise -- once published, no-one will re= ad the shepherd writeup. I think that the document itself needs to be clear= er that this is an optional extension (so if I want to buy an implementatio= n which does this, I ask for RFC3315 and RFCxxxx). > > ANSWER: Whether you implement this IPsec requirement in the to-be-RFC is = an implementation choice. There is no requirement to implement this to-be-R= FC. And operators that wish to use IPsec must require their vendors to impl= ement this to-be-RFC. So there would be implementation that comply with RFC= 3315 and this-to-be-RFC. This will make it clear to anyone desiring relays= or servers whether they can use IPsec based on whether they implement this= -to-be-RFC. This is not much different than other DHCP extensions =E2=80=93= such as Bulk or Active Leaseuquery =E2=80=93 these are not part of the bas= e specification but OPTIONAL features documented in other RFCs. That really was not clear from my reading of the document -- it very much sounds like it is (trying) to add additional requirements to *all* DHCP implementations, not that this is an optional extension. Until I read the shepherd writeup and the WG discussions I thought that this was adding new requirements to the base spec (as, I think, did other ADs), and that it also tried to tell me how to run my servers. I really think that the document should clarify that this is an optional feature / extension -- unfortunately I don't have text to suggest. I happen to think that this is a USEFUL feature / extension, but please clarify that it is optional. > > > I also do not understand the relationship between this document (which ta= lks about text RFC3315), and draft-ietf-dhc-rfc3315bis (which is currently = in WGLC) -- if rfc3315bis is almost done, should this reference that instea= d? Or should rfc3315bis simply incorporate this? > > ANSWER: 3315bis has this exact same text EXCEPT it is optional. When work= ing on 3315bis we did not feel that it was worth documenting the old IPsec = =E2=80=9Crules=E2=80=9D from 3315 as they were weak and not very useful. Bu= t again, we did not want to make IPsec required as part of 3315bis. Also, w= e wanted this to-be-RFC to be available sooner than 3315bis might be. We co= uld certainly discuss REMOVING IPsec text from 3315bis and just referring t= o this to-be-RFC. That in the end may be cleaner. > > > Comment (2017-04-08) > I found the document confusing -- it says that it REQUIRES IPsec for DHCP= v4 and DHCPv6, but it reads like it is requiring that operators enable this= , not that implementations have to support this; what exactly is is trying = to do? > I think that it would be much clearer if it said that implementations of = this document must support IPsec and that operators are recommended to enab= le it (assuming that it what it means). > > ANSWER: Is it both =E2=80=93 for vendors to implement and for operators t= o use. It requires both because of key management. If you prefer we can cer= tainly add a sentence or reword some existing text to says =E2=80=9Cimpleme= ntations of this document must support IPsec and that operators are recomme= nded to enable it=E2=80=9D. Perhaps replace: > > For DHCPv6 [RFC3315], this specification REQUIRES IPsec encryption of > relay to relay and relay to server communication and replaces the > text in RFC3315 Section 21.1. > > For DHCPv4 [RFC2131], this specification REQUIRES IPsec encryption of > relay to server communication. > > With something like: > > For DHCPv6 [RFC3315], this specification REQUIRES relay and server > implementations to support IPsec encryption of relay to relay and > relay to server communication as documented below (this replaces > the text in RFC3315 Section 21.1). > > For DHCPv4 [RFC2131], this specification REQUIRES relay and server > implementations to support IPsec encryption of relay to server > communication as documented below. > > This specification RECOMMENDS that operators enable IPsec for this > communication. I think that this would be useful. Much of my comment stems from the earlier "what exactly is "this specification"? Is it DHCP, or DHCP with this optional extension? Again, I think that this is a useful document, happy to clear my DISCUSS once it is clear that this is an option, not a new requirement on all implementations. W > > - Bernie Volz > --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Wed Apr 12 02:55:44 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 32FD4131551; Wed, 12 Apr 2017 02:55:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alexey Melnikov To: "The IESG" Cc: draft-ietf-dhc-relay-server-security@ietf.org, Tomek Mrugalski , dhc-chairs@ietf.org, tomasz.mrugalski@gmail.com, dhcwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149199094119.15657.5325004759902471882.idtracker@ietfa.amsl.com> Date: Wed, 12 Apr 2017 02:55:41 -0700 Archived-At: Subject: [dhcwg] Alexey Melnikov's Yes on draft-ietf-dhc-relay-server-security-04: (with COMMENT) 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, 12 Apr 2017 09:55:41 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-dhc-relay-server-security-04: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dhc-relay-server-security/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for writing this document. I am curious to know whether there are existing or planned implementations/deployments of this document. I am also agreeing with Warren concerns. From nobody Wed Apr 12 11:39:32 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 3E45E12EB3D; Wed, 12 Apr 2017 11:39:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benoit Claise To: "The IESG" Cc: draft-ietf-dhc-relay-server-security@ietf.org, Tomek Mrugalski , dhc-chairs@ietf.org, tomasz.mrugalski@gmail.com, dhcwg@ietf.org, evyncke@cisco.com X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149202237124.15816.841661275205958980.idtracker@ietfa.amsl.com> Date: Wed, 12 Apr 2017 11:39:31 -0700 Archived-At: Subject: [dhcwg] Benoit Claise's No Objection on draft-ietf-dhc-relay-server-security-04: (with COMMENT) 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, 12 Apr 2017 18:39:31 -0000 Benoit Claise has entered the following ballot position for draft-ietf-dhc-relay-server-security-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dhc-relay-server-security/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The advantage of a late review is that everything has been said already by other ADs :-) From nobody Wed Apr 12 13:39:56 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 5AC7D120227; Wed, 12 Apr 2017 13:39:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-dhc-relay-server-security@ietf.org, Tomek Mrugalski , dhc-chairs@ietf.org, tomasz.mrugalski@gmail.com, dhcwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149202959436.15730.7482173620764260658.idtracker@ietfa.amsl.com> Date: Wed, 12 Apr 2017 13:39:54 -0700 Archived-At: Subject: [dhcwg] Ben Campbell's Yes on draft-ietf-dhc-relay-server-security-04: (with COMMENT) 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, 12 Apr 2017 20:39:54 -0000 Ben Campbell has entered the following ballot position for draft-ietf-dhc-relay-server-security-04: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dhc-relay-server-security/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I am balloting "Yes", but I share the curiosity about whether people will really do this. -3, third paragraph: "MUST exchange messages securely" "Securely" is too ambiguous for a MUST. What specific protections are required? -3, paragraph 4: The list starts with no context. A sentence or paragraph describing the purpose of the list would be helpful. From nobody Wed Apr 12 15:31:36 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 ADC19129A91; Wed, 12 Apr 2017 15:31:25 -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 anrzw5Dllxlb; Wed, 12 Apr 2017 15:31:20 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1F53129AD0; Wed, 12 Apr 2017 15:31:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3544; q=dns/txt; s=iport; t=1492036278; x=1493245878; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=lWMKV3lKvO+3HTMXVW7WfHLaIXS5IMeCgwnVYfNv6Ug=; b=ZGndhVvTLk6H2roSRg5uGRnNhdYQqQG7p2xj1/TlXO4/b4j8/kRJ5Md1 9oa5j+T/5+LfB/iyLeKpoJ78Fnrdhnm4weNTswA08rViY4Dn2u2C2Hmgp FrYGrNboQ7hhem7sj9BxN7FlEoXp33Ea4QDMBjB2UezUFzAvjfXlblghK 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DgAQDnqe5Y/4gNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1NhgQsHg1+KE6ctgg8shXgCGoNnPxgBAgEBAQEBAQFrKIUWBiM?= =?us-ascii?q?RRRACAQgaAiYCAgIwFRACBAENBYoWDqlYgiaLEQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBARgFgQuHIyuBYoEKhCgRAQaDHC6CMQWJJ5NjAYcBi1+Bf4UuiheUAQEfOH0?= =?us-ascii?q?IWxVBEQGEfoFKdQGGc4EhgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.37,191,1488844800"; d="scan'208";a="232234140" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Apr 2017 22:31:16 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v3CMVGo2019705 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 12 Apr 2017 22:31:17 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 12 Apr 2017 17:31:16 -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, 12 Apr 2017 17:31:16 -0500 From: "Bernie Volz (volz)" To: Ben Campbell , The IESG CC: "draft-ietf-dhc-relay-server-security@ietf.org" , Tomek Mrugalski , "dhc-chairs@ietf.org" , "dhcwg@ietf.org" Thread-Topic: Ben Campbell's Yes on draft-ietf-dhc-relay-server-security-04: (with COMMENT) Thread-Index: AQHSs8zyj4ZKg6OMBEaSOILNFPwHs6HCYieA Date: Wed, 12 Apr 2017 22:31:16 +0000 Message-ID: References: <149202959436.15730.7482173620764260658.idtracker@ietfa.amsl.com> In-Reply-To: <149202959436.15730.7482173620764260658.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.131.32.239] Content-Type: text/plain; charset="utf-8" Content-ID: <4A1EB0A24607C64794EAE301125F1B65@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [dhcwg] Ben Campbell's Yes on draft-ietf-dhc-relay-server-security-04: (with COMMENT) 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, 12 Apr 2017 22:31:26 -0000 SGk6DQoNCkZvcjoNCg0KICAgIC0zLCB0aGlyZCBwYXJhZ3JhcGg6ICJNVVNUIGV4Y2hhbmdlIG1l c3NhZ2VzIHNlY3VyZWx5Ig0KICAgICJTZWN1cmVseSIgaXMgdG9vIGFtYmlndW91cyBmb3IgYSBN VVNULiBXaGF0IHNwZWNpZmljIHByb3RlY3Rpb25zIGFyZQ0KICAgIHJlcXVpcmVkPw0KDQpJIGJl bGlldmUgdGhpcyBhbHNvIHdhcyB0aGUgNHRoIHBhcmFncmFwaD8NCkkgZ3Vlc3MgdGhlcmUgYXJl IHR3byBjaG9pY2VzIGhlcmU6DQoxLiBEcm9wIOKAnHNlY3VyZWx54oCdIGFzIHdlIGFyZSBqdXN0 IHNwZWNpZnlpbmcgdG8gdXNlIElQc2VjLg0KMi4gUmVwbGFjZSDigJxzZWN1cmVseeKAnSB3aXRo IOKAnGVuY3J5cHRlZCBhbmQgYXV0aGVudGljYXRlZOKAnS4NClNlZW1zIHRvIGJlICMxIG1pZ2h0 IGJlIGJldHRlciAoYXMgaXQgc2hvdWxkIGJlIHVubmVjZXNzYXJ5IGdpdmVuIHRoYXQgaXMgd2hh dCB0aGlzIGRvY3VtZW50IGlzIGFib3V0KS4NCg0KDQogICAgIC0zLCBwYXJhZ3JhcGggNDoNCiAg ICBUaGUgbGlzdCBzdGFydHMgd2l0aCBubyBjb250ZXh0LiBBIHNlbnRlbmNlIG9yIHBhcmFncmFw aCBkZXNjcmliaW5nIHRoZQ0KICAgIHB1cnBvc2Ugb2YgdGhlIGxpc3Qgd291bGQgYmUgaGVscGZ1 bC4NCg0KUkZDIDMzMTUgaGFkIGJlZm9yZSB0aGlzIGxpc3Q6DQogICBSZWxheSBhZ2VudHMgYW5k IHNlcnZlcnMgdGhhdCBzdXBwb3J0IHNlY3VyZSByZWxheSBhZ2VudCB0byBzZXJ2ZXIgb3INCiAg IHJlbGF5IGFnZW50IHRvIHJlbGF5IGFnZW50IGNvbW11bmljYXRpb24gdXNlIElQc2VjIHVuZGVy IHRoZQ0KICAgZm9sbG93aW5nIGNvbmRpdGlvbnM6DQoNCkJ1dCBJ4oCZbSBub3Qgc3VyZSDigJxj b25kaXRpb25z4oCdIGlzIHRoZSBiZXN0IHdvcmQ/IE5vdCBzdXJlIGlmIHRoZXJlIGlzIGEgYmV0 dGVyIHdvcmQgdG8gdXNlIHRvIGRlc2NyaWJlIHRoZXNlIGl0ZW1zPw0KDQpQZXJoYXBzIHJlcGxh Y2luZyB0aGUgZmlyc3Qgc2VudGVuY2UgaW4gdGhhdCA0dGggcGFyYWdyYXBoIHdpdGg6DQoNCiAg UmVsYXkgYWdlbnRzIGFuZCBzZXJ2ZXJzIE1VU1QgZXhjaGFuZ2UgbWVzc2FnZXMgdXNpbmcgdGhl DQogIElQc2VjIG1lY2hhbmlzbXMgZGVzY3JpYmVkIGluIFtSRkM0MzAxXSB3aXRoIHRoZSBjb25k aXRpb25zDQogIGFzIGZvbGxvd3M6DQoNCkFuZCwgbW92ZSB0aGUgcmVtYWluaW5nIHRleHQgaW4g dGhhdCA0dGggcGFyYWdyYXBoIHRvIHRoZSBlbmQgb2Ygc2VjdGlvbiA0IGFzIGEgc2VwYXJhdGUg cGFyYWdyYXBoLg0KDQotIEJlcm5pZQ0KDQpPbiA0LzEyLzE3LCA0OjM5IFBNLCAiQmVuIENhbXBi ZWxsIiA8YmVuQG5vc3RydW0uY29tPiB3cm90ZToNCg0KICAgIEJlbiBDYW1wYmVsbCBoYXMgZW50 ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCiAgICBkcmFmdC1pZXRmLWRo Yy1yZWxheS1zZXJ2ZXItc2VjdXJpdHktMDQ6IFllcw0KICAgIA0KICAgIFdoZW4gcmVzcG9uZGlu ZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbA0K ICAgIGVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVl bCBmcmVlIHRvIGN1dCB0aGlzDQogICAgaW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4p DQogICAgDQogICAgDQogICAgUGxlYXNlIHJlZmVyIHRvIGh0dHBzOi8vd3d3LmlldGYub3JnL2ll c2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0KICAgIGZvciBtb3JlIGluZm9ybWF0 aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQogICAgDQogICAg DQogICAgVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNh biBiZSBmb3VuZCBoZXJlOg0KICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWlldGYtZGhjLXJlbGF5LXNlcnZlci1zZWN1cml0eS8NCiAgICANCiAgICANCiAgICANCiAg ICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQogICAgQ09NTUVOVDoNCiAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAgDQog ICAgSSBhbSBiYWxsb3RpbmcgIlllcyIsIGJ1dCBJIHNoYXJlIHRoZSBjdXJpb3NpdHkgYWJvdXQg d2hldGhlciBwZW9wbGUgd2lsbA0KICAgIHJlYWxseSBkbyB0aGlzLg0KICAgIA0KICAgIC0zLCB0 aGlyZCBwYXJhZ3JhcGg6ICJNVVNUIGV4Y2hhbmdlIG1lc3NhZ2VzIHNlY3VyZWx5Ig0KICAgICJT ZWN1cmVseSIgaXMgdG9vIGFtYmlndW91cyBmb3IgYSBNVVNULiBXaGF0IHNwZWNpZmljIHByb3Rl Y3Rpb25zIGFyZQ0KICAgIHJlcXVpcmVkPw0KICAgIA0KICAgIC0zLCBwYXJhZ3JhcGggNDoNCiAg ICBUaGUgbGlzdCBzdGFydHMgd2l0aCBubyBjb250ZXh0LiBBIHNlbnRlbmNlIG9yIHBhcmFncmFw aCBkZXNjcmliaW5nIHRoZQ0KICAgIHB1cnBvc2Ugb2YgdGhlIGxpc3Qgd291bGQgYmUgaGVscGZ1 bC4NCiAgICANCiAgICANCiAgICANCg0K From nobody Wed Apr 12 19:53: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 E6FC0127867; Wed, 12 Apr 2017 19:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, 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 YD7NclgSeD97; Wed, 12 Apr 2017 19:52:56 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 B62AE1286B1; Wed, 12 Apr 2017 19:52:56 -0700 (PDT) Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v3D2qrSY090626 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 12 Apr 2017 21:52:54 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63] From: "Ben Campbell" To: "Bernie Volz" Cc: "The IESG" , "Tomek Mrugalski" , "dhc-chairs@ietf.org" , "draft-ietf-dhc-relay-server-security@ietf.org" , "dhcwg@ietf.org" Date: Wed, 12 Apr 2017 21:52:53 -0500 Message-ID: In-Reply-To: References: <149202959436.15730.7482173620764260658.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: Re: [dhcwg] Ben Campbell's Yes on draft-ietf-dhc-relay-server-security-04: (with COMMENT) 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, 13 Apr 2017 02:52:59 -0000 On 12 Apr 2017, at 17:31, Bernie Volz (volz) wrote: > Hi: > > For: > > -3, third paragraph: "MUST exchange messages securely" > "Securely" is too ambiguous for a MUST. What specific protections > are > required? > > I believe this also was the 4th paragraph? Yes > I guess there are two choices here: > 1. Drop “securely” as we are just specifying to use IPsec. > 2. Replace “securely” with “encrypted and authenticated”. > Seems to be #1 might be better (as it should be unnecessary given that > is what this document is about). Is ESP with null encryption allowed? > > > -3, paragraph 4: > The list starts with no context. A sentence or paragraph > describing the > purpose of the list would be helpful. > > RFC 3315 had before this list: > Relay agents and servers that support secure relay agent to server > or > relay agent to relay agent communication use IPsec under the > following conditions: > > But I’m not sure “conditions” is the best word? Not sure if > there is a better word to use to describe these items? Rules? Configuration? (But I don't think "conditions" is awful) > > Perhaps replacing the first sentence in that 4th paragraph with: > > Relay agents and servers MUST exchange messages using the > IPsec mechanisms described in [RFC4301] with the conditions > as follows: > > And, move the remaining text in that 4th paragraph to the end of > section 4 as a separate paragraph. > > - Bernie > > On 4/12/17, 4:39 PM, "Ben Campbell" wrote: > > Ben Campbell has entered the following ballot position for > draft-ietf-dhc-relay-server-security-04: Yes > > When responding, please keep the subject line intact and reply to > all > email addresses included in the To and CC lines. (Feel free to cut > this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found > here: > https://datatracker.ietf.org/doc/draft-ietf-dhc-relay-server-security/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I am balloting "Yes", but I share the curiosity about whether > people will > really do this. > > -3, third paragraph: "MUST exchange messages securely" > "Securely" is too ambiguous for a MUST. What specific protections > are > required? > > -3, paragraph 4: > The list starts with no context. A sentence or paragraph > describing the > purpose of the list would be helpful. From nobody Wed Apr 12 20:11: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 4A3321293E3; Wed, 12 Apr 2017 20:11:39 -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 4QCKm6sN3JeU; Wed, 12 Apr 2017 20:11:38 -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 DF5B9129524; Wed, 12 Apr 2017 20:11:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6250; q=dns/txt; s=iport; t=1492053093; x=1493262693; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=lz+tHbF6gs4+unEhYEtTt4pvoAFofqOdAhI5uSNEcfQ=; b=TiLTuzUvNuRRkHR4qxpQAkA8uzr9qdnFwpEK5WnhFzsm7l9I3UxELm+g pKXv+H0H5sjoV5THeeCb/mCsq7U25YwTaP44beNCbs+fBcc48CBzpnFtU EoNsyvy/RH9MQSyQbkasQLup7o9nlFncNummsG589qyffPlD/qzV6yac0 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C2AwDW6+5Y/51dJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1NhgQsHg1+KE5E2H5VZgg8shXgCGoNoPxgBAgEBAQEBAQFrKIU?= =?us-ascii?q?VAQEBAQIBIxFFBQsCAQgYAgImAgICMBUQAgQOBYoOCA6paIImixMBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEYBYELhyMrCYFZgQqEKBEBBoMcLoIxBYknk2MBhwGLX4F?= =?us-ascii?q?/hS6KF5QBAR84fQhbFUERAYR+gUp1AYZzgSGBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.37,193,1488844800"; d="scan'208";a="411573724" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Apr 2017 03:11:24 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v3D3BO8S030539 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 13 Apr 2017 03:11:24 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; Wed, 12 Apr 2017 22:11:24 -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, 12 Apr 2017 22:11:24 -0500 From: "Bernie Volz (volz)" To: Ben Campbell CC: The IESG , Tomek Mrugalski , "dhc-chairs@ietf.org" , "draft-ietf-dhc-relay-server-security@ietf.org" , "dhcwg@ietf.org" Thread-Topic: Ben Campbell's Yes on draft-ietf-dhc-relay-server-security-04: (with COMMENT) Thread-Index: AQHSs8zyj4ZKg6OMBEaSOILNFPwHs6HCYieAgACMKID//8IdgA== Date: Thu, 13 Apr 2017 03:11:24 +0000 Message-ID: <7ED92DCC-697F-4877-B6ED-F8076BE1E854@cisco.com> References: <149202959436.15730.7482173620764260658.idtracker@ietfa.amsl.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.20.0.170309 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.254.59] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [dhcwg] Ben Campbell's Yes on draft-ietf-dhc-relay-server-security-04: (with COMMENT) 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, 13 Apr 2017 03:11:39 -0000 SGk6DQoNCk9LLCBJ4oCZbGwgdXNlIGNvbmRpdGlvbnMuDQoNCj4gICAgSXMgRVNQIHdpdGggbnVs bCBlbmNyeXB0aW9uIGFsbG93ZWQ/DQoNCk5vLiBUaGF0IHdhcyB3aGF0IFJGQzMzMTUgaGFkIGJ1 dCB0aGlzIGRvY3VtZW50IGNoYW5nZXMgdGhhdC4NCg0KUkZDIDMzMTU6DQoNCiAgICAgIE1vZGUg ICAgICAgICAgICAgUmVsYXkgYWdlbnRzIGFuZCBzZXJ2ZXJzIHVzZSB0cmFuc3BvcnQgbW9kZSBh bmQNCiAgICAgICAgICAgICAgICAgICAgICAgRVNQLiBUaGUgaW5mb3JtYXRpb24gaW4gREhDUCBt ZXNzYWdlcyBpcyBub3QNCiAgICAgICAgICAgICAgICAgICAgICAgZ2VuZXJhbGx5IGNvbnNpZGVy ZWQgY29uZmlkZW50aWFsLCBzbyBlbmNyeXB0aW9uDQogICAgICAgICAgICAgICAgICAgICAgIG5l ZWQgbm90IGJlIHVzZWQgKGkuZS4sIE5VTEwgZW5jcnlwdGlvbiBjYW4gYmUNCiAgICAgICAgICAg ICAgICAgICAgICAgdXNlZCkuDQoNClRoaXMgbmV3IGRyYWZ0Og0KDQogICBFbmNyeXB0aW9uIGFu ZCBhdXRoZW50aWNhdGlvbiBhbGdvcml0aG1zDQogICAgICAgICAgICAgICAgICAgICAgICAgICBU aGlzIGRvY3VtZW50IFJFUVVJUkVTIGNvbWJpbmVkIG1vZGUNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgIGFsZ29yaXRobXMgZm9yIEVTUCBhdXRoZW50aWNhdGVkIGVuY3J5cHRpb24sDQogICAg ICAgICAgICAgICAgICAgICAgICAgICBFU1AgZW5jcnlwdGlvbiBhbGdvcml0aG1zLCBhbmQgRVNQ DQogICAgICAgICAgICAgICAgICAgICAgICAgICBhdXRoZW50aWNhdGlvbiBhbGdvcml0aG1zIGFz IHBlciBTZWN0aW9ucw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgMi4xLCAyLjIsIGFuZCAy LjMgb2YgW1JGQzczMjFdIHJlc3BlY3RpdmVseS4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg IEVuY3J5cHRpb24gaXMgcmVxdWlyZWQgYXMgcmVsYXkgYWdlbnRzIG1heQ0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgZm9yd2FyZCB1bmVuY3J5cHRlZCBjbGllbnQgbWVzc2FnZXMgYXMgd2Vs bA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgYXMgaW5jbHVkZSBhZGRpdGlvbmFsIHNlbnNp dGl2ZSBpbmZvcm1hdGlvbiwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgIHN1Y2ggYXMgdmVu ZG9yLXNwZWNpZmljIGluZm9ybWF0aW9uIChmb3INCiAgICAgICAgICAgICAgICAgICAgICAgICAg IGV4YW1wbGUsIFtDYWJsZUxhYnMtREhDUF0pIGFuZCBbUkZDNzgzOV0uDQoNCi0gQmVybmllDQoN Ck9uIDQvMTIvMTcsIDEwOjUyIFBNLCAiQmVuIENhbXBiZWxsIiA8YmVuQG5vc3RydW0uY29tPiB3 cm90ZToNCg0KICAgIE9uIDEyIEFwciAyMDE3LCBhdCAxNzozMSwgQmVybmllIFZvbHogKHZvbHop IHdyb3RlOg0KICAgIA0KICAgID4gSGk6DQogICAgPg0KICAgID4gRm9yOg0KICAgID4NCiAgICA+ ICAgICAtMywgdGhpcmQgcGFyYWdyYXBoOiAiTVVTVCBleGNoYW5nZSBtZXNzYWdlcyBzZWN1cmVs eSINCiAgICA+ICAgICAiU2VjdXJlbHkiIGlzIHRvbyBhbWJpZ3VvdXMgZm9yIGEgTVVTVC4gV2hh dCBzcGVjaWZpYyBwcm90ZWN0aW9ucyANCiAgICA+IGFyZQ0KICAgID4gICAgIHJlcXVpcmVkPw0K ICAgID4NCiAgICA+IEkgYmVsaWV2ZSB0aGlzIGFsc28gd2FzIHRoZSA0dGggcGFyYWdyYXBoPw0K ICAgIA0KICAgIFllcw0KICAgIA0KICAgID4gSSBndWVzcyB0aGVyZSBhcmUgdHdvIGNob2ljZXMg aGVyZToNCiAgICA+IDEuIERyb3Ag4oCcc2VjdXJlbHnigJ0gYXMgd2UgYXJlIGp1c3Qgc3BlY2lm eWluZyB0byB1c2UgSVBzZWMuDQogICAgPiAyLiBSZXBsYWNlIOKAnHNlY3VyZWx54oCdIHdpdGgg 4oCcZW5jcnlwdGVkIGFuZCBhdXRoZW50aWNhdGVk4oCdLg0KICAgID4gU2VlbXMgdG8gYmUgIzEg bWlnaHQgYmUgYmV0dGVyIChhcyBpdCBzaG91bGQgYmUgdW5uZWNlc3NhcnkgZ2l2ZW4gdGhhdCAN CiAgICA+IGlzIHdoYXQgdGhpcyBkb2N1bWVudCBpcyBhYm91dCkuDQogICAgDQogICAgSXMgRVNQ IHdpdGggbnVsbCBlbmNyeXB0aW9uIGFsbG93ZWQ/DQogICAgDQogICAgPg0KICAgID4NCiAgICA+ ICAgICAgLTMsIHBhcmFncmFwaCA0Og0KICAgID4gICAgIFRoZSBsaXN0IHN0YXJ0cyB3aXRoIG5v IGNvbnRleHQuIEEgc2VudGVuY2Ugb3IgcGFyYWdyYXBoIA0KICAgID4gZGVzY3JpYmluZyB0aGUN CiAgICA+ICAgICBwdXJwb3NlIG9mIHRoZSBsaXN0IHdvdWxkIGJlIGhlbHBmdWwuDQogICAgPg0K ICAgID4gUkZDIDMzMTUgaGFkIGJlZm9yZSB0aGlzIGxpc3Q6DQogICAgPiAgICBSZWxheSBhZ2Vu dHMgYW5kIHNlcnZlcnMgdGhhdCBzdXBwb3J0IHNlY3VyZSByZWxheSBhZ2VudCB0byBzZXJ2ZXIg DQogICAgPiBvcg0KICAgID4gICAgcmVsYXkgYWdlbnQgdG8gcmVsYXkgYWdlbnQgY29tbXVuaWNh dGlvbiB1c2UgSVBzZWMgdW5kZXIgdGhlDQogICAgPiAgICBmb2xsb3dpbmcgY29uZGl0aW9uczoN CiAgICA+DQogICAgPiBCdXQgSeKAmW0gbm90IHN1cmUg4oCcY29uZGl0aW9uc+KAnSBpcyB0aGUg YmVzdCB3b3JkPyBOb3Qgc3VyZSBpZiANCiAgICA+IHRoZXJlIGlzIGEgYmV0dGVyIHdvcmQgdG8g dXNlIHRvIGRlc2NyaWJlIHRoZXNlIGl0ZW1zPw0KICAgIA0KICAgIFJ1bGVzPyBDb25maWd1cmF0 aW9uPyAoQnV0IEkgZG9uJ3QgdGhpbmsgImNvbmRpdGlvbnMiIGlzIGF3ZnVsKQ0KICAgIA0KICAg ID4NCiAgICA+IFBlcmhhcHMgcmVwbGFjaW5nIHRoZSBmaXJzdCBzZW50ZW5jZSBpbiB0aGF0IDR0 aCBwYXJhZ3JhcGggd2l0aDoNCiAgICA+DQogICAgPiAgIFJlbGF5IGFnZW50cyBhbmQgc2VydmVy cyBNVVNUIGV4Y2hhbmdlIG1lc3NhZ2VzIHVzaW5nIHRoZQ0KICAgID4gICBJUHNlYyBtZWNoYW5p c21zIGRlc2NyaWJlZCBpbiBbUkZDNDMwMV0gd2l0aCB0aGUgY29uZGl0aW9ucw0KICAgID4gICBh cyBmb2xsb3dzOg0KICAgID4NCiAgICA+IEFuZCwgbW92ZSB0aGUgcmVtYWluaW5nIHRleHQgaW4g dGhhdCA0dGggcGFyYWdyYXBoIHRvIHRoZSBlbmQgb2YgDQogICAgPiBzZWN0aW9uIDQgYXMgYSBz ZXBhcmF0ZSBwYXJhZ3JhcGguDQogICAgPg0KICAgID4gLSBCZXJuaWUNCiAgICA+DQogICAgPiBP biA0LzEyLzE3LCA0OjM5IFBNLCAiQmVuIENhbXBiZWxsIiA8YmVuQG5vc3RydW0uY29tPiB3cm90 ZToNCiAgICA+DQogICAgPiAgICAgQmVuIENhbXBiZWxsIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dp bmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KICAgID4gICAgIGRyYWZ0LWlldGYtZGhjLXJlbGF5LXNl cnZlci1zZWN1cml0eS0wNDogWWVzDQogICAgPg0KICAgID4gICAgIFdoZW4gcmVzcG9uZGluZywg cGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIA0KICAgID4g YWxsDQogICAgPiAgICAgZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0Mg bGluZXMuIChGZWVsIGZyZWUgdG8gY3V0IA0KICAgID4gdGhpcw0KICAgID4gICAgIGludHJvZHVj dG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KICAgID4NCiAgICA+DQogICAgPiAgICAgUGxlYXNl IHJlZmVyIHRvIA0KICAgID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlz Y3Vzcy1jcml0ZXJpYS5odG1sDQogICAgPiAgICAgZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQg SUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCiAgICA+DQogICAgPg0KICAgID4g ICAgIFRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4g YmUgZm91bmQgDQogICAgPiBoZXJlOg0KICAgID4gICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWlldGYtZGhjLXJlbGF5LXNlcnZlci1zZWN1cml0eS8NCiAgICA+DQog ICAgPg0KICAgID4NCiAgICA+ICAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAgPiAgICAgQ09NTUVOVDoN CiAgICA+ICAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAgPg0KICAgID4gICAgIEkgYW0gYmFsbG90aW5n ICJZZXMiLCBidXQgSSBzaGFyZSB0aGUgY3VyaW9zaXR5IGFib3V0IHdoZXRoZXIgDQogICAgPiBw ZW9wbGUgd2lsbA0KICAgID4gICAgIHJlYWxseSBkbyB0aGlzLg0KICAgID4NCiAgICA+ICAgICAt MywgdGhpcmQgcGFyYWdyYXBoOiAiTVVTVCBleGNoYW5nZSBtZXNzYWdlcyBzZWN1cmVseSINCiAg ICA+ICAgICAiU2VjdXJlbHkiIGlzIHRvbyBhbWJpZ3VvdXMgZm9yIGEgTVVTVC4gV2hhdCBzcGVj aWZpYyBwcm90ZWN0aW9ucyANCiAgICA+IGFyZQ0KICAgID4gICAgIHJlcXVpcmVkPw0KICAgID4N CiAgICA+ICAgICAtMywgcGFyYWdyYXBoIDQ6DQogICAgPiAgICAgVGhlIGxpc3Qgc3RhcnRzIHdp dGggbm8gY29udGV4dC4gQSBzZW50ZW5jZSBvciBwYXJhZ3JhcGggDQogICAgPiBkZXNjcmliaW5n IHRoZQ0KICAgID4gICAgIHB1cnBvc2Ugb2YgdGhlIGxpc3Qgd291bGQgYmUgaGVscGZ1bC4NCiAg ICANCg0K From nobody Wed Apr 12 20:25: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 577E71286B1; Wed, 12 Apr 2017 20:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, 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 XW-ldvCbdiTT; Wed, 12 Apr 2017 20:25:35 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 E6F94124D37; Wed, 12 Apr 2017 20:25:34 -0700 (PDT) Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v3D3PUgE096516 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 12 Apr 2017 22:25:30 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63] From: "Ben Campbell" To: "Bernie Volz" Cc: "The IESG" , "Tomek Mrugalski" , "dhc-chairs@ietf.org" , "draft-ietf-dhc-relay-server-security@ietf.org" , "dhcwg@ietf.org" Date: Wed, 12 Apr 2017 22:25:30 -0500 Message-ID: In-Reply-To: <7ED92DCC-697F-4877-B6ED-F8076BE1E854@cisco.com> References: <149202959436.15730.7482173620764260658.idtracker@ietfa.amsl.com> <7ED92DCC-697F-4877-B6ED-F8076BE1E854@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: Re: [dhcwg] Ben Campbell's Yes on draft-ietf-dhc-relay-server-security-04: (with COMMENT) 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, 13 Apr 2017 03:25:36 -0000 On 12 Apr 2017, at 22:11, Bernie Volz (volz) wrote: > Hi: > > OK, I’ll use conditions. > >> Is ESP with null encryption allowed? > > No. That was what RFC3315 had but this document changes that. That would suggest that the "MUST be secure" assertion in paragraph 4 is redundant with other normative text, and could be restated without the capitalized MUST. Ben. > > RFC 3315: > > Mode Relay agents and servers use transport mode and > ESP. The information in DHCP messages is not > generally considered confidential, so > encryption > need not be used (i.e., NULL encryption can be > used). > > This new draft: > > Encryption and authentication algorithms > This document REQUIRES combined mode > algorithms for ESP authenticated > encryption, > ESP encryption algorithms, and ESP > authentication algorithms as per Sections > 2.1, 2.2, and 2.3 of [RFC7321] > respectively. > Encryption is required as relay agents may > forward unencrypted client messages as well > as include additional sensitive > information, > such as vendor-specific information (for > example, [CableLabs-DHCP]) and [RFC7839]. > > - Bernie > > On 4/12/17, 10:52 PM, "Ben Campbell" wrote: > > On 12 Apr 2017, at 17:31, Bernie Volz (volz) wrote: > > > Hi: > > > > For: > > > > -3, third paragraph: "MUST exchange messages securely" > > "Securely" is too ambiguous for a MUST. What specific > protections > > are > > required? > > > > I believe this also was the 4th paragraph? > > Yes > > > I guess there are two choices here: > > 1. Drop “securely” as we are just specifying to use IPsec. > > 2. Replace “securely” with “encrypted and > authenticated”. > > Seems to be #1 might be better (as it should be unnecessary > given that > > is what this document is about). > > Is ESP with null encryption allowed? > > > > > > > -3, paragraph 4: > > The list starts with no context. A sentence or paragraph > > describing the > > purpose of the list would be helpful. > > > > RFC 3315 had before this list: > > Relay agents and servers that support secure relay agent to > server > > or > > relay agent to relay agent communication use IPsec under the > > following conditions: > > > > But I’m not sure “conditions” is the best word? Not sure > if > > there is a better word to use to describe these items? > > Rules? Configuration? (But I don't think "conditions" is awful) > > > > > Perhaps replacing the first sentence in that 4th paragraph with: > > > > Relay agents and servers MUST exchange messages using the > > IPsec mechanisms described in [RFC4301] with the conditions > > as follows: > > > > And, move the remaining text in that 4th paragraph to the end of > > section 4 as a separate paragraph. > > > > - Bernie > > > > On 4/12/17, 4:39 PM, "Ben Campbell" wrote: > > > > Ben Campbell has entered the following ballot position for > > draft-ietf-dhc-relay-server-security-04: Yes > > > > When responding, please keep the subject line intact and > reply to > > all > > email addresses included in the To and CC lines. (Feel free > to cut > > this > > introductory paragraph, however.) > > > > > > Please refer to > > https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT > positions. > > > > > > The document, along with other ballot positions, can be > found > > here: > > > https://datatracker.ietf.org/doc/draft-ietf-dhc-relay-server-security/ > > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > > ---------------------------------------------------------------------- > > > > I am balloting "Yes", but I share the curiosity about > whether > > people will > > really do this. > > > > -3, third paragraph: "MUST exchange messages securely" > > "Securely" is too ambiguous for a MUST. What specific > protections > > are > > required? > > > > -3, paragraph 4: > > The list starts with no context. A sentence or paragraph > > describing the > > purpose of the list would be helpful. From nobody Wed Apr 12 20:39:15 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 A5A6B124D37; Wed, 12 Apr 2017 20:39:14 -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 b2w78xn9ntRt; Wed, 12 Apr 2017 20:39:12 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50A07128B91; Wed, 12 Apr 2017 20:39:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9854; q=dns/txt; s=iport; t=1492054752; x=1493264352; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=IgvHQreFElA3Lb6XJ/YY4ma0rMH+8Y60MsRVMMcJUJU=; b=iIh63pEtrg0dpJsavki/yJHntTD6a1abRgV2wrHD12jTJPSvsb16tOqC jG5FjZeJNMc5n/aKIf+7MwPuIKLeOZ8/e9S6j7Z3mA0xYWP17sUArSHZ3 KZUkdMAgEGmkzO++7koUcFfKIb7U4PGN4nxn20mWgZJBsQ1HavbdaTIwM U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DEAQAw8u5Y/4wNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1NhgQsHg1+KE5FViBqNP4IPLIV4AhqDaD8YAQIBAQEBAQEBayi?= =?us-ascii?q?FFQEBAQECASMRPgcFBwQCAQgRBAEBAQICIwMCAgIfERQBCAgCBA4FCIl2Aw0ID?= =?us-ascii?q?qlwgiaHMw2DUwEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgQuHI4INgQqCUYFXEQE?= =?us-ascii?q?GLYJvgl8FiSeTKDsBhwGHHIQ6ggiFLooXiwKIfwEfOH0IWxVBhRCBSnUBhnOBI?= =?us-ascii?q?YENAQEB?= X-IronPort-AV: E=Sophos;i="5.37,193,1488844800"; d="scan'208";a="230483471" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Apr 2017 03:39:11 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v3D3dBbd008792 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 13 Apr 2017 03:39:11 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 12 Apr 2017 22:39:09 -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, 12 Apr 2017 22:39:10 -0500 From: "Bernie Volz (volz)" To: Ben Campbell CC: The IESG , Tomek Mrugalski , "dhc-chairs@ietf.org" , "draft-ietf-dhc-relay-server-security@ietf.org" , "dhcwg@ietf.org" Thread-Topic: Ben Campbell's Yes on draft-ietf-dhc-relay-server-security-04: (with COMMENT) Thread-Index: AQHSs8zyj4ZKg6OMBEaSOILNFPwHs6HCYieAgACMKID//8IdgIAARv8A//+u3dA= Date: Thu, 13 Apr 2017 03:39:10 +0000 Message-ID: References: <149202959436.15730.7482173620764260658.idtracker@ietfa.amsl.com> <7ED92DCC-697F-4877-B6ED-F8076BE1E854@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 x-originating-ip: [10.86.254.59] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [dhcwg] Ben Campbell's Yes on draft-ietf-dhc-relay-server-security-04: (with COMMENT) 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, 13 Apr 2017 03:39:15 -0000 SGk6DQoNCj4gVGhhdCB3b3VsZCBzdWdnZXN0IHRoYXQgdGhlICJNVVNUIGJlIHNlY3VyZSIgYXNz ZXJ0aW9uIGluIHBhcmFncmFwaCA0IGlzIHJlZHVuZGFudCB3aXRoIG90aGVyIG5vcm1hdGl2ZSB0 ZXh0LCBhbmQgY291bGQgYmUgcmVzdGF0ZWQgd2l0aG91dCB0aGUgY2FwaXRhbGl6ZWQgTVVTVC4N Cg0KSSdtIG5vdCBzdXJlIGV4YWN0bHkgd2hhdCB0aGF0IHJlZmVyZW5jZSBpcyB0bz8gUGFyYWdy YXBoIDQgaXM6DQoNCiAgIFJlbGF5IGFnZW50cyBhbmQgc2VydmVycyBNVVNUIGV4Y2hhbmdlIG1l c3NhZ2VzIHNlY3VyZWx5IHVzaW5nIHRoZQ0KICAgSVBzZWMgbWVjaGFuaXNtcyBkZXNjcmliZWQg aW4gW1JGQzQzMDFdLiAgSWYgYSBjbGllbnQgbWVzc2FnZSBpcw0KICAgcmVsYXllZCB0aHJvdWdo IG11bHRpcGxlIHJlbGF5IGFnZW50cyAocmVsYXkgY2hhaW4pLCBlYWNoIG9mIHRoZQ0KICAgcmVs YXkgYWdlbnRzIE1VU1QgaGF2ZSBhbiBlc3RhYmxpc2hlZCBpbmRlcGVuZGVudCwgcGFpcndpc2Ug dHJ1c3QNCiAgIHJlbGF0aW9uc2hpcHMuICBUaGF0IGlzLCBpZiBtZXNzYWdlcyBmcm9tIGNsaWVu dCBDIHdpbGwgYmUgcmVsYXllZCBieQ0KICAgcmVsYXkgYWdlbnQgQSB0byByZWxheSBhZ2VudCBC IGFuZCB0aGVuIHRvIHRoZSBzZXJ2ZXIsIHJlbGF5IGFnZW50cyBBDQogICBhbmQgQiBNVVNUIGJl IGNvbmZpZ3VyZWQgdG8gdXNlIElQc2VjIGZvciB0aGUgbWVzc2FnZXMgdGhleSBleGNoYW5nZSwN CiAgIGFuZCByZWxheSBhZ2VudCBCIGFuZCB0aGUgc2VydmVyIE1VU1QgYmUgY29uZmlndXJlZCB0 byB1c2UgSVBzZWMgZm9yDQogICB0aGUgbWVzc2FnZXMgdGhleSBleGNoYW5nZS4NCg0KUGVyaGFw cyB5b3UgYXJlIHJlZmVycmluZyB0byB0aGUgZmlyc3QgTVVTVCBvciBhbGwgYmUgY2hhbmdlZCB0 byBsb3dlciBjYXNlPw0KDQpJJ20gcHJvcG9zaW5nIGdvaW5nIHdpdGg6DQoNCiAgIFJlbGF5IGFn ZW50cyBhbmQgc2VydmVycyBNVVNUIGJlIGFibGUgdG8gZXhjaGFuZ2UgbWVzc2FnZXMgdXNpbmcg dGhlDQogICBJUHNlYyBtZWNoYW5pc21zIGRlc2NyaWJlZCBpbiBbUkZDNDMwMV0gYW5kIHdpdGgg dGhlIGNvbmRpdGlvbnMNCiAgIGJlbG93LiAgSWYgYSBjbGllbnQgbWVzc2FnZSBpcyByZWxheWVk IHRocm91Z2ggbXVsdGlwbGUgcmVsYXkgYWdlbnRzDQogICAocmVsYXkgY2hhaW4pLCBlYWNoIG9m IHRoZSByZWxheSBhZ2VudHMgTVVTVCBoYXZlIGFuIGVzdGFibGlzaGVkDQogICBpbmRlcGVuZGVu dCwgcGFpcndpc2UgdHJ1c3QgcmVsYXRpb25zaGlwcy4gIFRoYXQgaXMsIGlmIG1lc3NhZ2VzIGZy b20NCiAgIGNsaWVudCBDIHdpbGwgYmUgcmVsYXllZCBieSByZWxheSBhZ2VudCBBIHRvIHJlbGF5 IGFnZW50IEIgYW5kIHRoZW4NCiAgIHRvIHRoZSBzZXJ2ZXIsIHJlbGF5IGFnZW50cyBBIGFuZCBC IE1VU1QgYmUgY29uZmlndXJlZCB0byB1c2UgSVBzZWMNCiAgIGZvciB0aGUgbWVzc2FnZXMgdGhl eSBleGNoYW5nZSwgYW5kIHJlbGF5IGFnZW50IEIgYW5kIHRoZSBzZXJ2ZXIgTVVTVA0KICAgYmUg Y29uZmlndXJlZCB0byB1c2UgSVBzZWMgZm9yIHRoZSBtZXNzYWdlcyB0aGV5IGV4Y2hhbmdlLg0K DQpXZSBkbyB3YW50IHRvIG1ha2UgaXQgY2xlYXIgdGhhdCBhbiBpbXBsZW1lbnRhdGlvbiB0aGF0 IGNvbmZvcm1zIHRvIHRoZSB0by1iZS1SRkMgbmVlZHMgdG8gc3VwcG9ydCBJUHNlYyB3aXRoIHRo b3NlIGNvbmRpdGlvbnMuDQoNCi0gQmVybmllDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQpGcm9tOiBCZW4gQ2FtcGJlbGwgW21haWx0bzpiZW5Abm9zdHJ1bS5jb21dIA0KU2VudDogV2Vk bmVzZGF5LCBBcHJpbCAxMiwgMjAxNyAxMToyNiBQTQ0KVG86IEJlcm5pZSBWb2x6ICh2b2x6KSA8 dm9sekBjaXNjby5jb20+DQpDYzogVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+OyBUb21layBNcnVn YWxza2kgPHRvbWFzei5tcnVnYWxza2lAZ21haWwuY29tPjsgZGhjLWNoYWlyc0BpZXRmLm9yZzsg ZHJhZnQtaWV0Zi1kaGMtcmVsYXktc2VydmVyLXNlY3VyaXR5QGlldGYub3JnOyBkaGN3Z0BpZXRm Lm9yZw0KU3ViamVjdDogUmU6IEJlbiBDYW1wYmVsbCdzIFllcyBvbiBkcmFmdC1pZXRmLWRoYy1y ZWxheS1zZXJ2ZXItc2VjdXJpdHktMDQ6ICh3aXRoIENPTU1FTlQpDQoNCk9uIDEyIEFwciAyMDE3 LCBhdCAyMjoxMSwgQmVybmllIFZvbHogKHZvbHopIHdyb3RlOg0KDQo+IEhpOg0KPg0KPiBPSywg SeKAmWxsIHVzZSBjb25kaXRpb25zLg0KPg0KPj4gICAgSXMgRVNQIHdpdGggbnVsbCBlbmNyeXB0 aW9uIGFsbG93ZWQ/DQo+DQo+IE5vLiBUaGF0IHdhcyB3aGF0IFJGQzMzMTUgaGFkIGJ1dCB0aGlz IGRvY3VtZW50IGNoYW5nZXMgdGhhdC4NCg0KVGhhdCB3b3VsZCBzdWdnZXN0IHRoYXQgdGhlICJN VVNUIGJlIHNlY3VyZSIgYXNzZXJ0aW9uIGluIHBhcmFncmFwaCA0IGlzIHJlZHVuZGFudCB3aXRo IG90aGVyIG5vcm1hdGl2ZSB0ZXh0LCBhbmQgY291bGQgYmUgcmVzdGF0ZWQgd2l0aG91dCB0aGUg Y2FwaXRhbGl6ZWQgTVVTVC4NCg0KQmVuLg0KDQo+DQo+IFJGQyAzMzE1Og0KPg0KPiAgICAgICBN b2RlICAgICAgICAgICAgIFJlbGF5IGFnZW50cyBhbmQgc2VydmVycyB1c2UgdHJhbnNwb3J0IG1v ZGUgYW5kDQo+ICAgICAgICAgICAgICAgICAgICAgICAgRVNQLiBUaGUgaW5mb3JtYXRpb24gaW4g REhDUCBtZXNzYWdlcyBpcyBub3QNCj4gICAgICAgICAgICAgICAgICAgICAgICBnZW5lcmFsbHkg Y29uc2lkZXJlZCBjb25maWRlbnRpYWwsIHNvIA0KPiBlbmNyeXB0aW9uDQo+ICAgICAgICAgICAg ICAgICAgICAgICAgbmVlZCBub3QgYmUgdXNlZCAoaS5lLiwgTlVMTCBlbmNyeXB0aW9uIGNhbiBi ZQ0KPiAgICAgICAgICAgICAgICAgICAgICAgIHVzZWQpLg0KPg0KPiBUaGlzIG5ldyBkcmFmdDoN Cj4NCj4gICAgRW5jcnlwdGlvbiBhbmQgYXV0aGVudGljYXRpb24gYWxnb3JpdGhtcw0KPiAgICAg ICAgICAgICAgICAgICAgICAgICAgICBUaGlzIGRvY3VtZW50IFJFUVVJUkVTIGNvbWJpbmVkIG1v ZGUNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgYWxnb3JpdGhtcyBmb3IgRVNQIGF1dGhl bnRpY2F0ZWQgDQo+IGVuY3J5cHRpb24sDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIEVT UCBlbmNyeXB0aW9uIGFsZ29yaXRobXMsIGFuZCBFU1ANCj4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgYXV0aGVudGljYXRpb24gYWxnb3JpdGhtcyBhcyBwZXIgU2VjdGlvbnMNCj4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgMi4xLCAyLjIsIGFuZCAyLjMgb2YgW1JGQzczMjFdIA0KPiBy ZXNwZWN0aXZlbHkuDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIEVuY3J5cHRpb24gaXMg cmVxdWlyZWQgYXMgcmVsYXkgYWdlbnRzIG1heQ0KPiAgICAgICAgICAgICAgICAgICAgICAgICAg ICBmb3J3YXJkIHVuZW5jcnlwdGVkIGNsaWVudCBtZXNzYWdlcyBhcyB3ZWxsDQo+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgIGFzIGluY2x1ZGUgYWRkaXRpb25hbCBzZW5zaXRpdmUgDQo+IGlu Zm9ybWF0aW9uLA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdWNoIGFzIHZlbmRvci1z cGVjaWZpYyBpbmZvcm1hdGlvbiAoZm9yDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGV4 YW1wbGUsIFtDYWJsZUxhYnMtREhDUF0pIGFuZCBbUkZDNzgzOV0uDQo+DQo+IC0gQmVybmllDQo+ DQo+IE9uIDQvMTIvMTcsIDEwOjUyIFBNLCAiQmVuIENhbXBiZWxsIiA8YmVuQG5vc3RydW0uY29t PiB3cm90ZToNCj4NCj4gICAgIE9uIDEyIEFwciAyMDE3LCBhdCAxNzozMSwgQmVybmllIFZvbHog KHZvbHopIHdyb3RlOg0KPg0KPiAgICAgPiBIaToNCj4gICAgID4NCj4gICAgID4gRm9yOg0KPiAg ICAgPg0KPiAgICAgPiAgICAgLTMsIHRoaXJkIHBhcmFncmFwaDogIk1VU1QgZXhjaGFuZ2UgbWVz c2FnZXMgc2VjdXJlbHkiDQo+ICAgICA+ICAgICAiU2VjdXJlbHkiIGlzIHRvbyBhbWJpZ3VvdXMg Zm9yIGEgTVVTVC4gV2hhdCBzcGVjaWZpYyANCj4gcHJvdGVjdGlvbnMNCj4gICAgID4gYXJlDQo+ ICAgICA+ICAgICByZXF1aXJlZD8NCj4gICAgID4NCj4gICAgID4gSSBiZWxpZXZlIHRoaXMgYWxz byB3YXMgdGhlIDR0aCBwYXJhZ3JhcGg/DQo+DQo+ICAgICBZZXMNCj4NCj4gICAgID4gSSBndWVz cyB0aGVyZSBhcmUgdHdvIGNob2ljZXMgaGVyZToNCj4gICAgID4gMS4gRHJvcCDigJxzZWN1cmVs eeKAnSBhcyB3ZSBhcmUganVzdCBzcGVjaWZ5aW5nIHRvIHVzZSBJUHNlYy4NCj4gICAgID4gMi4g UmVwbGFjZSDigJxzZWN1cmVseeKAnSB3aXRoIOKAnGVuY3J5cHRlZCBhbmQgYXV0aGVudGljYXRl ZOKAnS4NCj4gICAgID4gU2VlbXMgdG8gYmUgIzEgbWlnaHQgYmUgYmV0dGVyIChhcyBpdCBzaG91 bGQgYmUgdW5uZWNlc3NhcnkgDQo+IGdpdmVuIHRoYXQNCj4gICAgID4gaXMgd2hhdCB0aGlzIGRv Y3VtZW50IGlzIGFib3V0KS4NCj4NCj4gICAgIElzIEVTUCB3aXRoIG51bGwgZW5jcnlwdGlvbiBh bGxvd2VkPw0KPg0KPiAgICAgPg0KPiAgICAgPg0KPiAgICAgPiAgICAgIC0zLCBwYXJhZ3JhcGgg NDoNCj4gICAgID4gICAgIFRoZSBsaXN0IHN0YXJ0cyB3aXRoIG5vIGNvbnRleHQuIEEgc2VudGVu Y2Ugb3IgcGFyYWdyYXBoDQo+ICAgICA+IGRlc2NyaWJpbmcgdGhlDQo+ICAgICA+ICAgICBwdXJw b3NlIG9mIHRoZSBsaXN0IHdvdWxkIGJlIGhlbHBmdWwuDQo+ICAgICA+DQo+ICAgICA+IFJGQyAz MzE1IGhhZCBiZWZvcmUgdGhpcyBsaXN0Og0KPiAgICAgPiAgICBSZWxheSBhZ2VudHMgYW5kIHNl cnZlcnMgdGhhdCBzdXBwb3J0IHNlY3VyZSByZWxheSBhZ2VudCB0byANCj4gc2VydmVyDQo+ICAg ICA+IG9yDQo+ICAgICA+ICAgIHJlbGF5IGFnZW50IHRvIHJlbGF5IGFnZW50IGNvbW11bmljYXRp b24gdXNlIElQc2VjIHVuZGVyIHRoZQ0KPiAgICAgPiAgICBmb2xsb3dpbmcgY29uZGl0aW9uczoN Cj4gICAgID4NCj4gICAgID4gQnV0IEnigJltIG5vdCBzdXJlIOKAnGNvbmRpdGlvbnPigJ0gaXMg dGhlIGJlc3Qgd29yZD8gTm90IHN1cmUgaWYNCj4gICAgID4gdGhlcmUgaXMgYSBiZXR0ZXIgd29y ZCB0byB1c2UgdG8gZGVzY3JpYmUgdGhlc2UgaXRlbXM/DQo+DQo+ICAgICBSdWxlcz8gQ29uZmln dXJhdGlvbj8gKEJ1dCBJIGRvbid0IHRoaW5rICJjb25kaXRpb25zIiBpcyBhd2Z1bCkNCj4NCj4g ICAgID4NCj4gICAgID4gUGVyaGFwcyByZXBsYWNpbmcgdGhlIGZpcnN0IHNlbnRlbmNlIGluIHRo YXQgNHRoIHBhcmFncmFwaCB3aXRoOg0KPiAgICAgPg0KPiAgICAgPiAgIFJlbGF5IGFnZW50cyBh bmQgc2VydmVycyBNVVNUIGV4Y2hhbmdlIG1lc3NhZ2VzIHVzaW5nIHRoZQ0KPiAgICAgPiAgIElQ c2VjIG1lY2hhbmlzbXMgZGVzY3JpYmVkIGluIFtSRkM0MzAxXSB3aXRoIHRoZSBjb25kaXRpb25z DQo+ICAgICA+ICAgYXMgZm9sbG93czoNCj4gICAgID4NCj4gICAgID4gQW5kLCBtb3ZlIHRoZSBy ZW1haW5pbmcgdGV4dCBpbiB0aGF0IDR0aCBwYXJhZ3JhcGggdG8gdGhlIGVuZCBvZg0KPiAgICAg PiBzZWN0aW9uIDQgYXMgYSBzZXBhcmF0ZSBwYXJhZ3JhcGguDQo+ICAgICA+DQo+ICAgICA+IC0g QmVybmllDQo+ICAgICA+DQo+ICAgICA+IE9uIDQvMTIvMTcsIDQ6MzkgUE0sICJCZW4gQ2FtcGJl bGwiIDxiZW5Abm9zdHJ1bS5jb20+IHdyb3RlOg0KPiAgICAgPg0KPiAgICAgPiAgICAgQmVuIENh bXBiZWxsIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KPiAg ICAgPiAgICAgZHJhZnQtaWV0Zi1kaGMtcmVsYXktc2VydmVyLXNlY3VyaXR5LTA0OiBZZXMNCj4g ICAgID4NCj4gICAgID4gICAgIFdoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1Ympl Y3QgbGluZSBpbnRhY3QgYW5kIA0KPiByZXBseSB0bw0KPiAgICAgPiBhbGwNCj4gICAgID4gICAg IGVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBm cmVlIA0KPiB0byBjdXQNCj4gICAgID4gdGhpcw0KPiAgICAgPiAgICAgaW50cm9kdWN0b3J5IHBh cmFncmFwaCwgaG93ZXZlci4pDQo+ICAgICA+DQo+ICAgICA+DQo+ICAgICA+ICAgICBQbGVhc2Ug cmVmZXIgdG8NCj4gICAgID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlz Y3Vzcy1jcml0ZXJpYS5odG1sDQo+ICAgICA+ICAgICBmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91 dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgDQo+IHBvc2l0aW9ucy4NCj4gICAgID4NCj4gICAg ID4NCj4gICAgID4gICAgIFRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9z aXRpb25zLCBjYW4gYmUgDQo+IGZvdW5kDQo+ICAgICA+IGhlcmU6DQo+ICAgICA+ICAgICANCj4g aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1kaGMtcmVsYXktc2Vy dmVyLXNlY3VyaXR5Lw0KPiAgICAgPg0KPiAgICAgPg0KPiAgICAgPg0KPiAgICAgPiAgICAgDQo+ IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCj4gICAgID4gICAgIENPTU1FTlQ6DQo+ICAgICA+ICAgICANCj4gLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KPiAgICAgPg0KPiAgICAgPiAgICAgSSBhbSBiYWxsb3RpbmcgIlllcyIsIGJ1 dCBJIHNoYXJlIHRoZSBjdXJpb3NpdHkgYWJvdXQgDQo+IHdoZXRoZXINCj4gICAgID4gcGVvcGxl IHdpbGwNCj4gICAgID4gICAgIHJlYWxseSBkbyB0aGlzLg0KPiAgICAgPg0KPiAgICAgPiAgICAg LTMsIHRoaXJkIHBhcmFncmFwaDogIk1VU1QgZXhjaGFuZ2UgbWVzc2FnZXMgc2VjdXJlbHkiDQo+ ICAgICA+ICAgICAiU2VjdXJlbHkiIGlzIHRvbyBhbWJpZ3VvdXMgZm9yIGEgTVVTVC4gV2hhdCBz cGVjaWZpYyANCj4gcHJvdGVjdGlvbnMNCj4gICAgID4gYXJlDQo+ICAgICA+ICAgICByZXF1aXJl ZD8NCj4gICAgID4NCj4gICAgID4gICAgIC0zLCBwYXJhZ3JhcGggNDoNCj4gICAgID4gICAgIFRo ZSBsaXN0IHN0YXJ0cyB3aXRoIG5vIGNvbnRleHQuIEEgc2VudGVuY2Ugb3IgcGFyYWdyYXBoDQo+ ICAgICA+IGRlc2NyaWJpbmcgdGhlDQo+ICAgICA+ICAgICBwdXJwb3NlIG9mIHRoZSBsaXN0IHdv dWxkIGJlIGhlbHBmdWwuDQo= From nobody Fri Apr 14 12:29:15 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 668F61275C5 for ; Fri, 14 Apr 2017 11:56:26 -0700 (PDT) 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 1qGqJsfGSpnn for ; Fri, 14 Apr 2017 11:56:25 -0700 (PDT) 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 13105126DDF for ; Fri, 14 Apr 2017 11:56:25 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 0DC8FB813F0; Fri, 14 Apr 2017 11:56:17 -0700 (PDT) To: davidmiles@google.com, wdec@cisco.com, James.Bristow@swisscom.com, roberta.maglione@telecomitalia.it, 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 Cc: niels@qacafe.com, dhcwg@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20170414185617.0DC8FB813F0@rfc-editor.org> Date: Fri, 14 Apr 2017 11:56:17 -0700 (PDT) Archived-At: X-Mailman-Approved-At: Fri, 14 Apr 2017 12:29:13 -0700 Subject: [dhcwg] [Technical Errata Reported] RFC6704 (4995) 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, 14 Apr 2017 18:56:26 -0000 The following errata report has been submitted for RFC6704, "Forcerenew Nonce Authentication". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6704&eid=4995 -------------------------------------- Type: Technical Reported by: Niels Widger Section: 4 Original Text ------------- IANA has assigned the following new DHCPv4 option code from the registry "BOOTP Vendor Extensions and DHCP Options" maintained at http://www.iana.org/assignments/bootp-dhcp-parameters: Tag: 145 Name: FORCERENEW_NONCE_CAPABLE Data length: 1 Description: Forcerenew Nonce Capable Reference: this document Corrected Text -------------- IANA has assigned the following new DHCPv4 option code from the registry "BOOTP Vendor Extensions and DHCP Options" maintained at http://www.iana.org/assignments/bootp-dhcp-parameters: Tag: 145 Name: FORCERENEW_NONCE_CAPABLE Data length: n Description: Forcerenew Nonce Capable Reference: this document Notes ----- RFC 6704 Section 3.1.1 states that the FORCERENEW_NONCE_CAPABLE option is variable length and contains a list of algorithm types: The FORCERENEW_NONCE_CAPABLE option contains code 145, length n, and a sequence of algorithms the client supports: Code Len Algorithms +-----+-----+----+----+----+ | 145 | n | A1 | A2 | A3 | .... +-----+-----+----+----+----+ Figure 1: FORCERENEW_NONCE_CAPABLE Option 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. -------------------------------------- RFC6704 (draft-ietf-dhc-forcerenew-nonce-07) -------------------------------------- Title : Forcerenew Nonce Authentication Publication Date : August 2012 Author(s) : D. Miles, W. Dec, J. Bristow, R. Maglione Category : PROPOSED STANDARD Source : Dynamic Host Configuration Area : Internet Stream : IETF Verifying Party : IESG From nobody Fri Apr 14 12:29:30 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 B518C129A9E for ; Fri, 14 Apr 2017 12:28:52 -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 2BIO_9OhMind for ; Fri, 14 Apr 2017 12:28:51 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D922129576 for ; Fri, 14 Apr 2017 12:28:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4118; q=dns/txt; s=iport; t=1492198130; x=1493407730; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=827mvHi4ZuwOZw1yHukThzwlN4Qk63o8YZOxo/f2+WU=; b=bFu8a4qCYt4+7bH9VBjJMtl8oCGGaxDcnGlj87bX4zULtdgXZvd+P4KP Tq5A0WXwKbo6udvER7StviNrDaRwnWd1GKR96WiFAzig5K9rc8rjLgNCL T3nX9LNVCfrbfS8JhhJtguresan2ofsE0IE+EmeQkWmBckkT1EsbYE9YH A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CbAgDIIfFY/4cNJK1CGhkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNTYYELB4NfihWRPZV9gg8sgh0Bg1oCGoNlPxgBAgEBAQEBAQF?= =?us-ascii?q?rKIUWBiMRRRACAQgaAiYCAgIwFRACBAENBQmKDg4xqQyCJosRAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBHYELhyQrCYJjgTyBXIEGgz8ugjEFiSkRhjqBUItTAZJkgX+?= =?us-ascii?q?FMIoXlAkBHzgVcGMVGCkRAYRQDBCBY3UBE4gngQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.37,200,1488844800"; d="scan'208";a="236051980" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Apr 2017 19:28:49 +0000 Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v3EJSnnN022959 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 14 Apr 2017 19:28:49 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 14 Apr 2017 14:28:48 -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; Fri, 14 Apr 2017 14:28:48 -0500 From: "Bernie Volz (volz)" To: RFC Errata System , "davidmiles@google.com" , "Wojciech Dec (wdec)" , "James.Bristow@swisscom.com" , "roberta.maglione@telecomitalia.it" , "suresh.krishnan@ericsson.com" , "terry.manderson@icann.org" , "tomasz.mrugalski@gmail.com" , "iana@iana.org" CC: "niels@qacafe.com" , "dhcwg@ietf.org" Thread-Topic: [Technical Errata Reported] RFC6704 (4995) Thread-Index: AQHStVDWuuiX81czlkCrNygpnBjILKHFUM6A Date: Fri, 14 Apr 2017 19:28:48 +0000 Message-ID: <1C00068E-BBFE-4615-8606-21B2D8B76CDF@cisco.com> References: <20170414185617.0DC8FB813F0@rfc-editor.org> In-Reply-To: <20170414185617.0DC8FB813F0@rfc-editor.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.1.195] Content-Type: text/plain; charset="utf-8" Content-ID: <25CB0F851654FD45A051821559ABA723@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Fri, 14 Apr 2017 12:29:25 -0700 Subject: Re: [dhcwg] [Technical Errata Reported] RFC6704 (4995) 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, 14 Apr 2017 19:28:53 -0000 WWVzLCBJQU5BIHNob3VsZCBjb3JyZWN0IHRoZSB0YWJsZSB0byByZWZsZWN0IHRoYXQgdGhlIGxl bmd0aCBpcyBuLCBub3QgMS4NCg0KVGhpcyBpcyBhIHZhbGlkIGVycmF0dW0gdG8gSUFOQSwgYnV0 IEkgZG9u4oCZdCB0aGluayB0aGF0IHRoaXMgaXMgYSB2YWxpZCBlcnJhdHVtIHRvIHRoZSBSRkMu DQoNCldlIGNhbiBqdXN0IHJlcXVlc3QgdGhhdCBJQU5BIGNvcnJlY3QgdGhlIHRhYmxlPw0KDQot IEJlcm5pZQ0KDQpPbiA0LzE0LzE3LCAyOjU2IFBNLCAiUkZDIEVycmF0YSBTeXN0ZW0iIDxyZmMt ZWRpdG9yQHJmYy1lZGl0b3Iub3JnPiB3cm90ZToNCg0KICAgIFRoZSBmb2xsb3dpbmcgZXJyYXRh IHJlcG9ydCBoYXMgYmVlbiBzdWJtaXR0ZWQgZm9yIFJGQzY3MDQsDQogICAgIkZvcmNlcmVuZXcg Tm9uY2UgQXV0aGVudGljYXRpb24iLg0KICAgIA0KICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQogICAgWW91IG1heSByZXZpZXcgdGhlIHJlcG9ydCBiZWxvdyBhbmQg YXQ6DQogICAgaHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9lcnJhdGFfc2VhcmNoLnBocD9yZmM9 NjcwNCZlaWQ9NDk5NQ0KICAgIA0KICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQogICAgVHlwZTogVGVjaG5pY2FsDQogICAgUmVwb3J0ZWQgYnk6IE5pZWxzIFdpZGdl ciA8bmllbHNAcWFjYWZlLmNvbT4NCiAgICANCiAgICBTZWN0aW9uOiA0DQogICAgDQogICAgT3Jp Z2luYWwgVGV4dA0KICAgIC0tLS0tLS0tLS0tLS0NCiAgICAgICBJQU5BIGhhcyBhc3NpZ25lZCB0 aGUgZm9sbG93aW5nIG5ldyBESENQdjQgb3B0aW9uIGNvZGUgZnJvbSB0aGUNCiAgICAgICByZWdp c3RyeSAiQk9PVFAgVmVuZG9yIEV4dGVuc2lvbnMgYW5kIERIQ1AgT3B0aW9ucyIgbWFpbnRhaW5l ZCBhdA0KICAgICAgIGh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvYm9vdHAtZGhjcC1w YXJhbWV0ZXJzOg0KICAgIA0KICAgICAgIFRhZzogMTQ1DQogICAgDQogICAgICAgTmFtZTogRk9S Q0VSRU5FV19OT05DRV9DQVBBQkxFDQogICAgDQogICAgICAgRGF0YSBsZW5ndGg6IDENCiAgICAN CiAgICAgICBEZXNjcmlwdGlvbjogRm9yY2VyZW5ldyBOb25jZSBDYXBhYmxlDQogICAgDQogICAg ICAgUmVmZXJlbmNlOiB0aGlzIGRvY3VtZW50DQogICAgDQogICAgQ29ycmVjdGVkIFRleHQNCiAg ICAtLS0tLS0tLS0tLS0tLQ0KICAgICAgIElBTkEgaGFzIGFzc2lnbmVkIHRoZSBmb2xsb3dpbmcg bmV3IERIQ1B2NCBvcHRpb24gY29kZSBmcm9tIHRoZQ0KICAgICAgIHJlZ2lzdHJ5ICJCT09UUCBW ZW5kb3IgRXh0ZW5zaW9ucyBhbmQgREhDUCBPcHRpb25zIiBtYWludGFpbmVkIGF0DQogICAgICAg aHR0cDovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9ib290cC1kaGNwLXBhcmFtZXRlcnM6DQog ICAgDQogICAgICAgVGFnOiAxNDUNCiAgICANCiAgICAgICBOYW1lOiBGT1JDRVJFTkVXX05PTkNF X0NBUEFCTEUNCiAgICANCiAgICAgICBEYXRhIGxlbmd0aDogbg0KICAgIA0KICAgICAgIERlc2Ny aXB0aW9uOiBGb3JjZXJlbmV3IE5vbmNlIENhcGFibGUNCiAgICANCiAgICAgICBSZWZlcmVuY2U6 IHRoaXMgZG9jdW1lbnQNCiAgICANCiAgICBOb3Rlcw0KICAgIC0tLS0tDQogICAgUkZDIDY3MDQg U2VjdGlvbiAzLjEuMSBzdGF0ZXMgdGhhdCB0aGUgRk9SQ0VSRU5FV19OT05DRV9DQVBBQkxFIG9w dGlvbiBpcyB2YXJpYWJsZSBsZW5ndGggYW5kIGNvbnRhaW5zIGEgbGlzdCBvZiBhbGdvcml0aG0g dHlwZXM6DQogICAgDQogICAgVGhlIEZPUkNFUkVORVdfTk9OQ0VfQ0FQQUJMRSBvcHRpb24gY29u dGFpbnMgY29kZSAxNDUsIGxlbmd0aCBuLCBhbmQNCiAgICAgICBhIHNlcXVlbmNlIG9mIGFsZ29y aXRobXMgdGhlIGNsaWVudCBzdXBwb3J0czoNCiAgICANCiAgICAgICAgICAgICAgICAgQ29kZSAg IExlbiAgIEFsZ29yaXRobXMNCiAgICAgICAgICAgICAgICArLS0tLS0rLS0tLS0rLS0tLSstLS0t Ky0tLS0rDQogICAgICAgICAgICAgICAgfCAxNDUgfCAgbiAgfCBBMSB8IEEyIHwgQTMgfCAuLi4u DQogICAgICAgICAgICAgICAgKy0tLS0tKy0tLS0tKy0tLS0rLS0tLSstLS0tKw0KICAgIA0KICAg ICAgICAgICAgICAgICAgICAgRmlndXJlIDE6IEZPUkNFUkVORVdfTk9OQ0VfQ0FQQUJMRSBPcHRp b24NCiAgICANCiAgICBJbnN0cnVjdGlvbnM6DQogICAgLS0tLS0tLS0tLS0tLQ0KICAgIFRoaXMg ZXJyYXR1bSBpcyBjdXJyZW50bHkgcG9zdGVkIGFzICJSZXBvcnRlZCIuIElmIG5lY2Vzc2FyeSwg cGxlYXNlDQogICAgdXNlICJSZXBseSBBbGwiIHRvIGRpc2N1c3Mgd2hldGhlciBpdCBzaG91bGQg YmUgdmVyaWZpZWQgb3INCiAgICByZWplY3RlZC4gV2hlbiBhIGRlY2lzaW9uIGlzIHJlYWNoZWQs IHRoZSB2ZXJpZnlpbmcgcGFydHkgIA0KICAgIGNhbiBsb2cgaW4gdG8gY2hhbmdlIHRoZSBzdGF0 dXMgYW5kIGVkaXQgdGhlIHJlcG9ydCwgaWYgbmVjZXNzYXJ5LiANCiAgICANCiAgICAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgIFJGQzY3MDQgKGRyYWZ0LWlldGYt ZGhjLWZvcmNlcmVuZXctbm9uY2UtMDcpDQogICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCiAgICBUaXRsZSAgICAgICAgICAgICAgIDogRm9yY2VyZW5ldyBOb25jZSBB dXRoZW50aWNhdGlvbg0KICAgIFB1YmxpY2F0aW9uIERhdGUgICAgOiBBdWd1c3QgMjAxMg0KICAg IEF1dGhvcihzKSAgICAgICAgICAgOiBELiBNaWxlcywgVy4gRGVjLCBKLiBCcmlzdG93LCBSLiBN YWdsaW9uZQ0KICAgIENhdGVnb3J5ICAgICAgICAgICAgOiBQUk9QT1NFRCBTVEFOREFSRA0KICAg IFNvdXJjZSAgICAgICAgICAgICAgOiBEeW5hbWljIEhvc3QgQ29uZmlndXJhdGlvbg0KICAgIEFy ZWEgICAgICAgICAgICAgICAgOiBJbnRlcm5ldA0KICAgIFN0cmVhbSAgICAgICAgICAgICAgOiBJ RVRGDQogICAgVmVyaWZ5aW5nIFBhcnR5ICAgICA6IElFU0cNCiAgICANCg0K From nobody Sat Apr 15 02:36: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 98FBF12704B; Sat, 15 Apr 2017 02:35:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Francis Dupont To: Cc: dhcwg@ietf.org, ietf@ietf.org, draft-ietf-dhc-relay-server-security.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149224895859.15792.12555844017714647455@ietfa.amsl.com> Date: Sat, 15 Apr 2017 02:35:58 -0700 Archived-At: Subject: [dhcwg] Genart telechat review of draft-ietf-dhc-relay-server-security-03 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, 15 Apr 2017 09:35:59 -0000 Reviewer: Francis Dupont Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-dhc-relay-server-security-?? Reviewer: Francis Dupont Review Date: 2017-04-15 IETF LC End Date: 2017-03-13 IESG Telechat date: Not scheduled for a telechat Summary: Ready Major issues: None Minor issues: None Nits/editorial comments: I talked with authors at the IETF meeting: my comments were addressed. From nobody Mon Apr 17 13:43: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 5C886127977 for ; Mon, 17 Apr 2017 13:43:45 -0700 (PDT) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 UuL5VhIYbCzd for ; Mon, 17 Apr 2017 13:43:43 -0700 (PDT) Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e:c05::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 D7585129454 for ; Mon, 17 Apr 2017 13:43:40 -0700 (PDT) Received: by mail-pg0-x22a.google.com with SMTP id z127so13340699pgb.1 for ; Mon, 17 Apr 2017 13:43:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=iPX+VEQYgJ0GYOegI2iiFnvAdVWwAgeQRrYbXow4zaM=; b=OLOJdSWDA0HQsOIaafj6KOEKv2HezJQJ3c/p5TU3kveh1YTnxDukzpWycgCjTzVvqQ KDUDEqg+X3uLBTVMTDX8e4cSbgOyCIBX3rL0AM3DjBZd0OkZ01wZf/A0TrVXfAFQLbGY eDlpwCjF+GbBRwH1nXularHg0w4M8XiPMbp7vfrQpJCRH1FFhhOwJXUS8YzGBakG3k8d 4LhMA00IC1FPwXuKaBh94XaVGmeqIewoedq+xb4gtyndAC46LGSc3tIgAWH1Gu2EB3VE qdwZDUxSgVyKfhZhu6o4jzFTpm5ZB+3VPG20AisM1yaruozyCbdqMBdt2K/q5DOg0NF+ LP1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=iPX+VEQYgJ0GYOegI2iiFnvAdVWwAgeQRrYbXow4zaM=; b=jL7LDPOJYWwNETHsXnCLAPoS1jrI/plzr2/SZIuNw0bUSECVgrPzaQECD7X5JjeR5T JJmDA4Dsk5JTWI8OyllAwADCUswc7JO+IVGMgcR5aWdqw/TPico6vj9FgithrXEeO7NW q6xh+cvDrngocIebp0SEnFGCxeBBnIiwe3+l3/YOO/5Ua9tks+SnZIRWeSLUCiht0c0Y ey+WrHJyOKa5g2eCQQldu9UTq+td50s+FdetFjZqjfJ6lmeFralxgRbHY2sCh8NWIgDR zefOIQRwXk6mciFCO/W32BupsvVWoJ7p6dXqQREBHsUnFuFogvQNpb/imOQc22XqAmOD 5uDQ== X-Gm-Message-State: AN3rC/6EJCA+cNPOk7TDAKRvkV6jeNRSAapU0g0ZA7Kjj4UqH18gueB2 ttChs2RRKFCEJT24rk/GctcHnJcT2A== X-Received: by 10.84.143.1 with SMTP id 1mr18420208ply.70.1492461820486; Mon, 17 Apr 2017 13:43:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.162.41 with HTTP; Mon, 17 Apr 2017 13:43:00 -0700 (PDT) From: Kathleen Moriarty Date: Mon, 17 Apr 2017 16:43:00 -0400 Message-ID: To: "" Cc: Paul Wouters , Michael Richardson Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [dhcwg] light review of draft-ietf-dhc-sedhcpv6 and helpful suggestion 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, 17 Apr 2017 20:43:45 -0000 Dear authors, I just skimmed the draft triggered by another review and noticed the deployment concerns in the WGLC summary sent to the list. think I can help here with the remaining issues on making it easier to deploy. First, I'm really glad to see this work. Thanks for all of your efforts on it! Second, I know this is late in the process, but I think more text on opportunistic security for IPsec is worth documenting to overcome implementation hurdles and address the coffee shop use cases. I didn't see a reference to: https://tools.ietf.org/html/rfc7619 and am thinking the authors/WG might not be aware of this work. Additionally, it should be noted that there are several Linux implementations for IPsec with NULL authentication (OS). Paul Woulters is a author on the mentioned RFC and did implement this with IPsec for RedHat. Michael Richardson is an author on the draft: https://tools.ietf.org/html/draft-richardson-ipsec-opportunistic-17 documenting the OS IPsec implementation for the Linux FreeS/WAN project. I think it would be beneficial to see text that has OS as mandatory to implement (MTI) and upgradeable to authenticated IPsec when practical. Ideally, they would both be MTI, not mandatory to use (MTU) at least for the authenticated since that is too hard. But MTI on opportunistic would be a great next step that could be deployed. If we were able to get DCHPv6 supporting this option in code with OS, then people could turn it on. As you point out in the draft, enterprise and other managed scenarios could use an option with authentication if implemented. I think the MTI versus MTU could have been more clear in this draft and the relay one that just went through the IESG review. The current OS text leaves me, the reader, thinking it won't be implemented as it's not pointing to a practical implementable RFC. I am copying Michael and Paul (mentioned above) as one of them might be willing to help with text. I think this will greatly assist with the deployability of session encryption. Thank you! -- Best regards, Kathleen From nobody Mon Apr 17 15:35: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 BC45D1242F7 for ; Mon, 17 Apr 2017 15:35:49 -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 r1hP52-x43tG for ; Mon, 17 Apr 2017 15:35:48 -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 57A531315B6 for ; Mon, 17 Apr 2017 15:35:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3520; q=dns/txt; s=iport; t=1492468548; x=1493678148; h=from:to:subject:date:message-id:mime-version; bh=ZRIbL9sJMsGUji9HcgIdgfq78FMcRZTGIoY+dIBbPsk=; b=icpdwUP5UkX8BU0T73SqQTGJKRjPjFytwJY9bRQi4ECILCpLPalAF6Xv Qi//gK7ONlRFoafdqWkNuV1JQ9ZieRz/oknWWe1vzKrNgszhRlCGPoPwx LQLfcCYpHN3wn0tXa+rPIRwfNPWajad7FFAarg5Ugi26ZSH/xXk08Oqwc M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CgAwCuQvVY/5tdJa1dGwEBAQMBAQEJA?= =?us-ascii?q?QEBg1OFUooVkT2QTIU0gg+GQINqPxgBAgEBAQEBAQFrHQuFP2gBDD4CBDAnBIo?= =?us-ascii?q?qmx6QCIImix4BAQEBAQEEAQEBAQEBAQEBH4haCoQfhiEugjEFnRsBkmSBf4Uwi?= =?us-ascii?q?heUCQEfOIEFYxUaOwGEYIFzihABAQE?= X-IronPort-AV: E=Sophos; i="5.37,217,1488844800"; d="scan'208,217"; a="16086411" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Apr 2017 22:35:47 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v3HMZlcY011845 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 17 Apr 2017 22:35:47 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 17 Apr 2017 17:35: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, 17 Apr 2017 17:35:46 -0500 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: IETF-99 (Prague) Meeting Agenda Requests - due by May 28th Thread-Index: AQHSt8r0hSZfCLgt7kmWmK77CnIvAA== Date: Mon, 17 Apr 2017 22:35:46 +0000 Message-ID: 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_AFDD985902BD439588D2B79DF1D713C9ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [dhcwg] IETF-99 (Prague) Meeting Agenda Requests - due by May 28th 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, 17 Apr 2017 22:35:50 -0000 --_000_AFDD985902BD439588D2B79DF1D713C9ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGk6DQoNCklmIHlvdSBoYXZlIGFueSBpbnRlcmVzdCBpbiBwcmVzZW50aW5nIHRvIHRoZSBESEMg d2cgZHVyaW5nIElFVEYtOTksIHBsZWFzZSBzdWJtaXQgYSByZXF1ZXN0IGJ5IFR1ZXNkYXksIE1h eSAyN3RoLiBUb21layAmIEkgbXVzdCBzdWJtaXQgYSByZXF1ZXN0IGZvciBhIHNlc3Npb24gYnkg SnVuZSAybmQgZGVhZGxpbmUuDQpBcyBpbiB0aGUgcGFzdCwgcGxlYXNlIHByb3ZpZGU6DQpUaXRs ZSBPZiBTZXNzaW9uOg0KUHJlc2VudGVyOg0KUmVsYXRlZCBEcmFmdHM6DQpUaW1lIFJlcXVpcmVk Og0KUHVycG9zZSBvZiBTZXNzaW9uOg0KV2UgZG8gd2FudCB0byByZW1pbmQgdGhvc2UgcmVxdWVz dGluZyB0aW1lIHRoYXQgeW91IHNob3VsZCBmb2N1cyBvbiBkaXNjdXNzaW5nIGtleSBpc3N1ZXMg dGhhdCBuZWVkIHJlc29sdXRpb24gdG8gbW92ZSBhIGRyYWZ0IGZvcndhcmQgb3IgdG8gaW50cm9k dWNlIHBvdGVudGlhbCBuZXcgd29yay4NCldoaWxlIHdlIGFyZSBzdGlsbCAzIG1vbnRocyBmcm9t IHRociBtZWV0aW5nLCB0aGUgc2Vzc2lvbiByZXF1ZXN0cyBoYXZlIG9wZW5lZCB1cCBhbmQgd2Ug bmVlZCB0byBrbm93IGFwcHJveGltYXRlbHkgaG93IG11Y2ggdGltZSB0byByZXF1ZXN0Lg0KLSBC ZXJuaWUgJiBUb21law0K --_000_AFDD985902BD439588D2B79DF1D713C9ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <0AF649FC2E15CB4C8F82F1ED6730BBB4@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 ZGl2PkhpOjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SWYgeW91IGhhdmUgYW55IGlu dGVyZXN0IGluIHByZXNlbnRpbmcgdG8gdGhlIERIQyB3ZyBkdXJpbmcgSUVURi05OSwgcGxlYXNl IHN1Ym1pdCBhIHJlcXVlc3QgYnkgVHVlc2RheSwgTWF5IDI3dGguIFRvbWVrICZhbXA7IEkgbXVz dCBzdWJtaXQgYSByZXF1ZXN0IGZvciBhIHNlc3Npb24gYnkgSnVuZSAybmQgZGVhZGxpbmUuPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImJhY2tncm91bmQt Y29sb3I6IHJnYmEoMjU1LCAyNTUsIDI1NSwgMCk7Ij5BcyBpbiB0aGUgcGFzdCwgcGxlYXNlIHBy b3ZpZGU6PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJiYWNr Z3JvdW5kLWNvbG9yOiByZ2JhKDI1NSwgMjU1LCAyNTUsIDApOyI+VGl0bGUgT2YgU2Vzc2lvbjo8 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImJhY2tncm91bmQt Y29sb3I6IHJnYmEoMjU1LCAyNTUsIDI1NSwgMCk7Ij5QcmVzZW50ZXI6PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiByZ2JhKDI1 NSwgMjU1LCAyNTUsIDApOyI+UmVsYXRlZCBEcmFmdHM6PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6IHJnYmEo MjU1LCAyNTUsIDI1NSwgMCk7Ij5UaW1lIFJlcXVpcmVkOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiByZ2Jh KDI1NSwgMjU1LCAyNTUsIDApOyI+UHVycG9zZSBvZiBTZXNzaW9uOjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9y OiByZ2JhKDI1NSwgMjU1LCAyNTUsIDApOyI+V2UgZG8gd2FudCB0byByZW1pbmQgdGhvc2UgcmVx dWVzdGluZyB0aW1lIHRoYXQgeW91IHNob3VsZCBmb2N1cyBvbiBkaXNjdXNzaW5nIGtleSBpc3N1 ZXMgdGhhdCBuZWVkIHJlc29sdXRpb24gdG8gbW92ZSBhIGRyYWZ0IGZvcndhcmQgb3IgdG8gaW50 cm9kdWNlIHBvdGVudGlhbCBuZXcgd29yay48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6IHJnYmEoMjU1LCAyNTUsIDI1NSwgMCk7 Ij5XaGlsZSB3ZSBhcmUgc3RpbGwgMyBtb250aHMgZnJvbSB0aHI8L3NwYW4+PHNwYW4gc3R5bGU9 ImJhY2tncm91bmQtY29sb3I6IHJnYmEoMjU1LCAyNTUsIDI1NSwgMCk7Ij4mbmJzcDttZWV0aW5n LCB0aGUgc2Vzc2lvbiByZXF1ZXN0cyBoYXZlIG9wZW5lZCB1cCBhbmQgd2UgbmVlZCB0byBrbm93 IGFwcHJveGltYXRlbHkgaG93DQogbXVjaCB0aW1lIHRvIHJlcXVlc3QuPC9zcGFuPjwvcD4NCjxk aXY+LSBCZXJuaWUgJmFtcDsgVG9tZWs8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_AFDD985902BD439588D2B79DF1D713C9ciscocom_-- From nobody Tue Apr 18 08:19:22 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 91D52128CDB for ; Tue, 18 Apr 2017 08:19:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 aOcP7GXizn7R for ; Tue, 18 Apr 2017 08:19:20 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03409128B91 for ; Tue, 18 Apr 2017 08:19:20 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id CF080203CA; Tue, 18 Apr 2017 11:44:22 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id DB30D636BB; Tue, 18 Apr 2017 11:19:18 -0400 (EDT) From: Michael Richardson To: Kathleen Moriarty cc: "\" In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [dhcwg] light review of draft-ietf-dhc-sedhcpv6 and helpful suggestion 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, 18 Apr 2017 15:19:22 -0000 --=-=-= Content-Type: text/plain Kathleen Moriarty wrote: > Michael Richardson is an author on the draft: > https://tools.ietf.org/html/draft-richardson-ipsec-opportunistic-17 > documenting the OS IPsec implementation for the Linux FreeS/WAN > project. it is RFC4322 actually. We also tried to use DHCP(v4) to bootstrap IPsec for the last mile. We didn't try to use IPsec to secure DHCP, but the mechanism that we used would have permitted some interesting post-IP-address assignment to work. I haven't read dhc-sedhcpv6, but I might find time to do that so that I understand the problem. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlj2LnYACgkQgItw+93Q 3WXrvwf/YpjhPy0xQbMR5KHqeu9oia/LlszciFmlcYjyhSm8N1CTwoYWfkAI/HUK X5N9IYKpHpAY4aqG+RpCDd2TOeArKXG3yR6utfmLazjun9FoCXF9FTXCbS00pnpC 2oG3VxTbsh16Isxokpu3OgXl2ty93OtVOxj5vlWPrwstEn61hlUwRi13tW/8J7Tq WVYFkBSPQz40Es4mOEBfzPWdMmFj7VLYq2rxWvLq3mPTaUKzQFcAr3yVFZBLw7W0 EsPurUOdx7htamCu7x7ch3hCq1GyXJsqvM/d1EnVidTLtB9+rA0/I2SjeKK8dPXV UGKusr6lmxSVTtnFBx+81do547s/LQ== =crqF -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Apr 18 11:33:01 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 0015F128DF6; Tue, 18 Apr 2017 11:32:51 -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.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149254037195.16058.11578723312670883690@ietfa.amsl.com> Date: Tue, 18 Apr 2017 11:32:51 -0700 Archived-At: Subject: [dhcwg] I-D Action: draft-ietf-dhc-relay-port-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: Tue, 18 Apr 2017 18:32:52 -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 : Generalized UDP Source Port for DHCP Relay Authors : Naiming Shen Enke Chen Filename : draft-ietf-dhc-relay-port-04.txt Pages : 10 Date : 2017-04-18 Abstract: This document proposes an extension to the DHCP and DHCPv6 protocols that allows any valid number to be used as the relay agent's UDP source port for DHCP packets. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-relay-port/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dhc-relay-port-04 https://datatracker.ietf.org/doc/html/draft-ietf-dhc-relay-port-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-relay-port-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 Tue Apr 18 11:37: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 C2A571300CF for ; Tue, 18 Apr 2017 11:37:16 -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 gveKyylEYNxA for ; Tue, 18 Apr 2017 11:37:12 -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 CFC661293DA for ; Tue, 18 Apr 2017 11:37:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9047; q=dns/txt; s=iport; t=1492540626; x=1493750226; h=from:to:subject:date:message-id:references:mime-version; bh=lRXa+gc53WlH8mHzoR871fhP5LU1NF6uW/oTxv5yNGI=; b=BNmdQKv0F3g/lzSTubp2HOZKSiux7UzpowlUhEEdKi/scZ6WIN/lTuh0 gr/9rCxOGGFO9PjK3Zhq1Odk8VLRSguopr8VrCzoJHo7kl+cFAeXqn1fo ymaXAuOGM0ByychBPEYCnQ4Ojmxp3X+Jnk7vG0/uAISCO30nnN6VX1d2L A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DwAAB1XPZY/4ENJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1NhgQsHiASFcJFjkC2FNIIPIQEKhXgCg3Q/GAECAQEBAQEBAWs?= =?us-ascii?q?ohRUBAwMBAWwbAgEZAwECKAcnCxQHAggCBBMJihAOrXSLIgEBAQEBBQEBAQEBA?= =?us-ascii?q?QEBAR+IWoJtgxiBXxaCFmiCMQWWNIZuAYcDi2aCAFWEXIhdgTqLMohbAR84gQV?= =?us-ascii?q?jFRoqEQGGU3UBh30BgQwBAQE?= X-IronPort-AV: E=Sophos;i="5.37,219,1488844800"; d="scan'208,217";a="414196772" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Apr 2017 18:37:05 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v3IIb5sv017312 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 18 Apr 2017 18:37:05 GMT Received: from xch-rcd-004.cisco.com (173.37.102.14) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 18 Apr 2017 13:37:04 -0500 Received: from xch-rcd-004.cisco.com ([173.37.102.14]) by XCH-RCD-004.cisco.com ([173.37.102.14]) with mapi id 15.00.1210.000; Tue, 18 Apr 2017 13:37:04 -0500 From: "Naiming Shen (naiming)" To: dhcwg Thread-Topic: I-D Action: draft-ietf-dhc-relay-port-04.txt Thread-Index: AQHSuHI6s7VBr6g+ikyWGOUhzF2zMw== Date: Tue, 18 Apr 2017 18:37:04 +0000 Message-ID: <140C0811-06C3-4E74-8B67-AD3ACCCF241E@cisco.com> References: <149254037195.16058.11578723312670883690@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [128.107.155.85] Content-Type: multipart/alternative; boundary="_000_140C081106C34E748B67AD3ACCCF241Eciscocom_" MIME-Version: 1.0 Archived-At: Subject: [dhcwg] Fwd: I-D Action: draft-ietf-dhc-relay-port-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: Tue, 18 Apr 2017 18:37:17 -0000 --_000_140C081106C34E748B67AD3ACCCF241Eciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi DHC WG, Updated the draft, to rephrase the compatibility requirements for using this relay-port feature. Please review and comment. Best Regards, - Naiming Begin forwarded message: From: internet-drafts@ietf.org Subject: I-D Action: draft-ietf-dhc-relay-port-04.txt Date: April 18, 2017 at 11:32:51 AM PDT To: > Cc: dhcwg@ietf.org Reply-To: internet-drafts@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Dynamic Host Configuration of the IETF. Title : Generalized UDP Source Port for DHCP Relay Authors : Naiming Shen Enke Chen Filename : draft-ietf-dhc-relay-port-04.txt Pages : 10 Date : 2017-04-18 Abstract: This document proposes an extension to the DHCP and DHCPv6 protocols that allows any valid number to be used as the relay agent's UDP source port for DHCP packets. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-relay-port/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dhc-relay-port-04 https://datatracker.ietf.org/doc/html/draft-ietf-dhc-relay-port-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-relay-port-04 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --_000_140C081106C34E748B67AD3ACCCF241Eciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <19674CB3BF34B14DA9705FA684D892E7@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi DHC WG,

Updated the draft, to rephrase the compatibility requirements
for using this relay-port feature.

Please review and comment.

Best Regards,
- Naiming

Begin forwarded message:

From: internet-drafts@ietf.org
Subject: I-D Action: draft-ietf-dh= c-relay-port-04.txt
Date: April 18, 2017 at 11:32:51 AM PDT
To: <i-d-announce@ietf.org>
Cc: dhcwg@ietf.org
Reply-To: internet-drafts@ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Dynamic Host Configuration of the IETF.
       Title     &nb= sp;     : Generalized UDP Source Port for DHCP Rel= ay
       Authors     &= nbsp;   : Naiming Shen
            &nb= sp;            = Enke Chen
Filename &n= bsp;      : draft-ietf-dhc-relay-port-04.txt<= br class=3D""> Pages  = ;         : 10
Date  =           : 2017-04-18
Abstract:
  This document proposes an extension to the DHCP and DHCPv6 prot= ocols
  that allows any valid number to be used as the relay agent's UD= P
  source port for DHCP packets.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dhc-relay-port/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dhc-relay-port-04
https://datatracker.ietf.org/doc/html/draft-ietf-dhc-relay-port-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-relay-port-04


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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--_000_140C081106C34E748B67AD3ACCCF241Eciscocom_-- From nobody Wed Apr 19 05:37:19 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 6EB87129524 for ; Wed, 19 Apr 2017 05:36:43 -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 3w1KmZKzBBkm for ; Wed, 19 Apr 2017 05:36:41 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B173D12009C for ; Wed, 19 Apr 2017 05:36:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3996; q=dns/txt; s=iport; t=1492605401; x=1493815001; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=RmPUiTliq1cvBuW0fCaSNltZq39DGgobFz5ThihELmY=; b=XTVXZSn2d3XiYMc0z9SMEnA6OoU1YbPxjFgmEtg4rHa13JW0EVl0NBe8 MmYwNxtaK+nCS7G/Kn0LjQTbcCE3bgfk7Qd8HZhLm8fNON87EmgsxQ50K nvg197c2MaiXcDX6/taVAFx+GGkowx7q0U+SOvNr6TVObzXDZ32ok7OeL M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAQAeWfdY/5JdJa1CGhkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNUYYELB4NgihWnRYIPLIIdAYNaAhqDYj8YAQIBAQEBAQEBayi?= =?us-ascii?q?FFgYjEUUQAgEIGgImAgICMBUQAgQBDQUJihAOMaoXgiaLLgEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAR2BC4clK4JugTyBXIEGOYMGLoIxBYkyEYY+gVCLXAGSbYIAhTG?= =?us-ascii?q?KGohsiyMBHzgVcGMVGioRAYRUDBCBY3UBE4d0gQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.37,221,1488844800"; d="scan'208";a="237802989" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Apr 2017 12:36:40 +0000 Received: from XCH-RCD-007.cisco.com (xch-rcd-007.cisco.com [173.37.102.17]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v3JCaePT028311 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 19 Apr 2017 12:36:40 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-RCD-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 19 Apr 2017 07:36:39 -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, 19 Apr 2017 07:36:40 -0500 From: "Bernie Volz (volz)" To: RFC Errata System , "davidmiles@google.com" , "Wojciech Dec (wdec)" , "James.Bristow@swisscom.com" , "roberta.maglione@telecomitalia.it" , "terry.manderson@icann.org" , "tomasz.mrugalski@gmail.com" , "suresh@kaloom.com" CC: "niels@qacafe.com" , "dhcwg@ietf.org" Thread-Topic: [Technical Errata Reported] RFC6704 (4995) Thread-Index: AQHStVDWuuiX81czlkCrNygpnBjILKHMuVCA Date: Wed, 19 Apr 2017 12:36:39 +0000 Message-ID: <1BDC18F7-878D-4B77-A43E-6B87204C77F3@cisco.com> References: <20170414185617.0DC8FB813F0@rfc-editor.org> In-Reply-To: <20170414185617.0DC8FB813F0@rfc-editor.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.255.62] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Wed, 19 Apr 2017 05:37:18 -0700 Subject: Re: [dhcwg] [Technical Errata Reported] RFC6704 (4995) 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, 19 Apr 2017 12:36:43 -0000 VGhpcyBlcnJhdHVtIGlzIHZlcmlmaWVkLiBQbGVhc2UgdXBkYXRlIGl0IHRvIHJlZmxlY3QgdGhh dCBpcyB2ZXJpZmllZC4NCg0KV2UgY2FuIHRoZW4gbm90aWZ5IElBTkEgdG8gaGF2ZSB0aGUgdGFi bGUgY29ycmVjdGVkLg0KDQotIEJlcm5pZSBWb2x6DQoNCk9uIDQvMTQvMTcsIDI6NTYgUE0sICJS RkMgRXJyYXRhIFN5c3RlbSIgPHJmYy1lZGl0b3JAcmZjLWVkaXRvci5vcmc+IHdyb3RlOg0KDQog ICAgVGhlIGZvbGxvd2luZyBlcnJhdGEgcmVwb3J0IGhhcyBiZWVuIHN1Ym1pdHRlZCBmb3IgUkZD NjcwNCwNCiAgICAiRm9yY2VyZW5ldyBOb25jZSBBdXRoZW50aWNhdGlvbiIuDQogICAgDQogICAg LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICBZb3UgbWF5IHJldmll dyB0aGUgcmVwb3J0IGJlbG93IGFuZCBhdDoNCiAgICBodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3Jn L2VycmF0YV9zZWFyY2gucGhwP3JmYz02NzA0JmVpZD00OTk1DQogICAgDQogICAgLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICBUeXBlOiBUZWNobmljYWwNCiAgICBS ZXBvcnRlZCBieTogTmllbHMgV2lkZ2VyIDxuaWVsc0BxYWNhZmUuY29tPg0KICAgIA0KICAgIFNl Y3Rpb246IDQNCiAgICANCiAgICBPcmlnaW5hbCBUZXh0DQogICAgLS0tLS0tLS0tLS0tLQ0KICAg ICAgIElBTkEgaGFzIGFzc2lnbmVkIHRoZSBmb2xsb3dpbmcgbmV3IERIQ1B2NCBvcHRpb24gY29k ZSBmcm9tIHRoZQ0KICAgICAgIHJlZ2lzdHJ5ICJCT09UUCBWZW5kb3IgRXh0ZW5zaW9ucyBhbmQg REhDUCBPcHRpb25zIiBtYWludGFpbmVkIGF0DQogICAgICAgaHR0cDovL3d3dy5pYW5hLm9yZy9h c3NpZ25tZW50cy9ib290cC1kaGNwLXBhcmFtZXRlcnM6DQogICAgDQogICAgICAgVGFnOiAxNDUN CiAgICANCiAgICAgICBOYW1lOiBGT1JDRVJFTkVXX05PTkNFX0NBUEFCTEUNCiAgICANCiAgICAg ICBEYXRhIGxlbmd0aDogMQ0KICAgIA0KICAgICAgIERlc2NyaXB0aW9uOiBGb3JjZXJlbmV3IE5v bmNlIENhcGFibGUNCiAgICANCiAgICAgICBSZWZlcmVuY2U6IHRoaXMgZG9jdW1lbnQNCiAgICAN CiAgICBDb3JyZWN0ZWQgVGV4dA0KICAgIC0tLS0tLS0tLS0tLS0tDQogICAgICAgSUFOQSBoYXMg YXNzaWduZWQgdGhlIGZvbGxvd2luZyBuZXcgREhDUHY0IG9wdGlvbiBjb2RlIGZyb20gdGhlDQog ICAgICAgcmVnaXN0cnkgIkJPT1RQIFZlbmRvciBFeHRlbnNpb25zIGFuZCBESENQIE9wdGlvbnMi IG1haW50YWluZWQgYXQNCiAgICAgICBodHRwOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL2Jv b3RwLWRoY3AtcGFyYW1ldGVyczoNCiAgICANCiAgICAgICBUYWc6IDE0NQ0KICAgIA0KICAgICAg IE5hbWU6IEZPUkNFUkVORVdfTk9OQ0VfQ0FQQUJMRQ0KICAgIA0KICAgICAgIERhdGEgbGVuZ3Ro OiBuDQogICAgDQogICAgICAgRGVzY3JpcHRpb246IEZvcmNlcmVuZXcgTm9uY2UgQ2FwYWJsZQ0K ICAgIA0KICAgICAgIFJlZmVyZW5jZTogdGhpcyBkb2N1bWVudA0KICAgIA0KICAgIE5vdGVzDQog ICAgLS0tLS0NCiAgICBSRkMgNjcwNCBTZWN0aW9uIDMuMS4xIHN0YXRlcyB0aGF0IHRoZSBGT1JD RVJFTkVXX05PTkNFX0NBUEFCTEUgb3B0aW9uIGlzIHZhcmlhYmxlIGxlbmd0aCBhbmQgY29udGFp bnMgYSBsaXN0IG9mIGFsZ29yaXRobSB0eXBlczoNCiAgICANCiAgICBUaGUgRk9SQ0VSRU5FV19O T05DRV9DQVBBQkxFIG9wdGlvbiBjb250YWlucyBjb2RlIDE0NSwgbGVuZ3RoIG4sIGFuZA0KICAg ICAgIGEgc2VxdWVuY2Ugb2YgYWxnb3JpdGhtcyB0aGUgY2xpZW50IHN1cHBvcnRzOg0KICAgIA0K ICAgICAgICAgICAgICAgICBDb2RlICAgTGVuICAgQWxnb3JpdGhtcw0KICAgICAgICAgICAgICAg ICstLS0tLSstLS0tLSstLS0tKy0tLS0rLS0tLSsNCiAgICAgICAgICAgICAgICB8IDE0NSB8ICBu ICB8IEExIHwgQTIgfCBBMyB8IC4uLi4NCiAgICAgICAgICAgICAgICArLS0tLS0rLS0tLS0rLS0t LSstLS0tKy0tLS0rDQogICAgDQogICAgICAgICAgICAgICAgICAgICBGaWd1cmUgMTogRk9SQ0VS RU5FV19OT05DRV9DQVBBQkxFIE9wdGlvbg0KICAgIA0KICAgIEluc3RydWN0aW9uczoNCiAgICAt LS0tLS0tLS0tLS0tDQogICAgVGhpcyBlcnJhdHVtIGlzIGN1cnJlbnRseSBwb3N0ZWQgYXMgIlJl cG9ydGVkIi4gSWYgbmVjZXNzYXJ5LCBwbGVhc2UNCiAgICB1c2UgIlJlcGx5IEFsbCIgdG8gZGlz Y3VzcyB3aGV0aGVyIGl0IHNob3VsZCBiZSB2ZXJpZmllZCBvcg0KICAgIHJlamVjdGVkLiBXaGVu IGEgZGVjaXNpb24gaXMgcmVhY2hlZCwgdGhlIHZlcmlmeWluZyBwYXJ0eSAgDQogICAgY2FuIGxv ZyBpbiB0byBjaGFuZ2UgdGhlIHN0YXR1cyBhbmQgZWRpdCB0aGUgcmVwb3J0LCBpZiBuZWNlc3Nh cnkuIA0KICAgIA0KICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQog ICAgUkZDNjcwNCAoZHJhZnQtaWV0Zi1kaGMtZm9yY2VyZW5ldy1ub25jZS0wNykNCiAgICAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgIFRpdGxlICAgICAgICAgICAg ICAgOiBGb3JjZXJlbmV3IE5vbmNlIEF1dGhlbnRpY2F0aW9uDQogICAgUHVibGljYXRpb24gRGF0 ZSAgICA6IEF1Z3VzdCAyMDEyDQogICAgQXV0aG9yKHMpICAgICAgICAgICA6IEQuIE1pbGVzLCBX LiBEZWMsIEouIEJyaXN0b3csIFIuIE1hZ2xpb25lDQogICAgQ2F0ZWdvcnkgICAgICAgICAgICA6 IFBST1BPU0VEIFNUQU5EQVJEDQogICAgU291cmNlICAgICAgICAgICAgICA6IER5bmFtaWMgSG9z dCBDb25maWd1cmF0aW9uDQogICAgQXJlYSAgICAgICAgICAgICAgICA6IEludGVybmV0DQogICAg U3RyZWFtICAgICAgICAgICAgICA6IElFVEYNCiAgICBWZXJpZnlpbmcgUGFydHkgICAgIDogSUVT Rw0KICAgIA0KDQo= From nobody Wed Apr 19 06:41:54 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 0D74912954C; Wed, 19 Apr 2017 06:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 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, 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 lcBXzY733d-8; Wed, 19 Apr 2017 06:41:51 -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 68FFF1293F4; Wed, 19 Apr 2017 06:41:51 -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 v3JDfntw009204; Wed, 19 Apr 2017 06:41:50 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (xch15-06-08.nw.nos.boeing.com [137.136.238.222]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v3JDffsS009121 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Wed, 19 Apr 2017 06:41:41 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 19 Apr 2017 06:41:41 -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; Wed, 19 Apr 2017 06:41:41 -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 - summary Thread-Index: AQHSrj/Om2r5zeyMdU24tzLmWNqPBaHMxxkA Date: Wed, 19 Apr 2017 13:41:40 +0000 Message-ID: <257f4b807afa44d5841e7764859f150c@XCH15-06-08.nw.nos.boeing.com> References: <1380758a-b7d0-bb73-bf58-4e318e88a6d0@gmail.com> In-Reply-To: <1380758a-b7d0-bb73-bf58-4e318e88a6d0@gmail.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: [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 - summary 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, 19 Apr 2017 13:41:53 -0000 Hi, RFC7513 seems to suggest DHCP snooping, i.e., some L2 device on the link fr= om the DHCP server or relay to the client examines the contents of DHCP messag= es. Unfortunately, sedhcpv6 mandates encryption making snooping impossible. Does it mean that Secure DHCPv6 will be incompatible with SAVI? Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Tomek Mrugalski > Sent: Wednesday, April 05, 2017 12:07 PM > To: dhcwg > Cc: draft-ietf-dhc-sedhcpv6 authors > Subject: [dhcwg] WGLC on draft-ietf-dhc-sedhcpv6-21 - summary >=20 > It took a little bit more than planned, but the extra time gave us a > couple more comments. >=20 > We did receive a number of in depth reviews with technical comments. In > general, several people praised the significantly improved quality and > clarity of the document. Nobody said that is opposed to this work. So > from that perspective this last call is a success. >=20 > However, both chair and at least one co-author feel that an important > concern has not been addressed yet. There currently are no known > implementations or prototypes of this draft. For a typical DHCP draft > that adds an option or two that would probably be fine, but for this > particular draft it is not. For two reasons: First, we feel that this is > an essential piece of the whole DHCPv6 ecosystem and as such require > much more scrutiny then an average draft. Second, security is a complex > matter and any unclear aspects would gravely damage the > interoperability. Jinmei had put it well: "I suspect the current spec > still has some points that are critically unclear, which you would > immediately notice once you tried to implement it." >=20 > Given that, we declare that more effort is needed before this work is > deemed ready for IESG. At the same time, chairs would like to strongly > applaud authors' efforts to improve this work. This version is > significantly better than its predecessors. Thank you for your hard > work. You are doing excellent work. Please continue. >=20 > Also, to address the concern of missing implementations, chairs would > like to announce a DHCP hackathon in Prague. Details are TBD, but the > primary goal will be to have at least two independent implementations of > that draft. The hackathon will take place the weekend before IETF > meeting (that's July 15-16). A separate announcement will be sent soon. >=20 > That is well over 3 months away. Authors and supporters of this work, > please seriously consider dedicating some of your time implementing > prototypes and attending the hackathon, if you can. If you can't we will > organize some means for participating remotely. >=20 > Thank you to the authors and to everyone who commented. >=20 > Bernie & Tomek >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From nobody Wed Apr 19 06:46:02 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 4B7211296B3; Wed, 19 Apr 2017 06:46:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 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, URIBL_BLOCKED=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 La0q-6qGXxoI; Wed, 19 Apr 2017 06:45:58 -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 EEF4112954C; Wed, 19 Apr 2017 06:45:57 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id p68so20162748qke.1; Wed, 19 Apr 2017 06:45:57 -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=yzbNwQDWtjUDE77F6QiBuFmEZf6HsmcAOFCG0sHCKkY=; b=HPzfl7G8tYaJYCUO3ZOOuDfbViKhJ6fhGK5SG/r2eabKQoTZPImqXzSzfYSC8/sCBc ldEZDo7Qs89hjZAdNkGT0Aza6dcBRGb4TbkpjhOkVYD6DfpYQOMMm+m/7u9HZUyZ4AmS 8MNHw+/wOQ413VFL72OxmVlRl8JpYxDJ43D74vMqrNz/SRuHe9b2vQnD3gIoEz+UMDuf oQUqSDjDwbdIiP6ZPEE/gR9o5lpPweUTpMA+AYmZTUhQx9JYMRaHYgtNTgNlb1lSTk1S btL5LwXRK5gkOv9kBPvUAThwGmzDjxWZaQMXpn/tzvyWhgpywEOGOfcvDf479DFEqBZz dhMQ== 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=yzbNwQDWtjUDE77F6QiBuFmEZf6HsmcAOFCG0sHCKkY=; b=i/lWdg9ECWEkXUPTwOHoO7hBurHv+cJpG/wFjXVxAE+Bf2Vpd0jwjQedcLRUjBSDas j+8tPFRZE1u75m2bsX7OjCiMqpHNNc9ls1xoPDE5EvGqY3LxABsdWyjOV/hJwSYwa3OL iMqK/0QeRnHFBmy5RGBeKqVCtr0nUkZA94QAVOKJlzJsxGyXANTDRWDZZOp8oa3apaGU 30GGapESFdT1jgpKrO9PP4hA8HSYt+/z+F5Ga5Z+bmSzyGToYDWSj6HyQ5euXJE35X8p iIqHKyBhPPbaafjhJ1zXLUBgQU6hSTAl6at22TIXnqVsOqMAtYaM4V5mRZGys7je2Zl2 mw0g== X-Gm-Message-State: AN3rC/60Hlr8d2PYhZ75AXoTi3t9R3mfAqNgyo1l1/wYtUR0uhTy7Ao2 b1os1NKdD5qvDWwfffnwVjLnmShL+w== X-Received: by 10.55.102.196 with SMTP id a187mr2932795qkc.28.1492609557098; Wed, 19 Apr 2017 06:45:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.58.71 with HTTP; Wed, 19 Apr 2017 06:45:56 -0700 (PDT) In-Reply-To: <257f4b807afa44d5841e7764859f150c@XCH15-06-08.nw.nos.boeing.com> References: <1380758a-b7d0-bb73-bf58-4e318e88a6d0@gmail.com> <257f4b807afa44d5841e7764859f150c@XCH15-06-08.nw.nos.boeing.com> From: Lishan Li Date: Wed, 19 Apr 2017 21:45:56 +0800 Message-ID: To: "Templin, Fred L" Cc: Tomek Mrugalski , dhcwg , draft-ietf-dhc-sedhcpv6 authors Content-Type: multipart/alternative; boundary=94eb2c055938707880054d853e49 Archived-At: Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-sedhcpv6-21 - summary 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, 19 Apr 2017 13:46:00 -0000 --94eb2c055938707880054d853e49 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I have considered this problem. Yes, secure DHCPv6 is incompatible with SAVI. If secure DHCPv6 is implemented, SAVI cannot work well and have to be updated. Best Regards, Lishan =E5=9C=A8 2017=E5=B9=B44=E6=9C=8819=E6=97=A5=EF=BC=8C=E4=B8=8B=E5=8D=889:41= =EF=BC=8CTemplin, Fred L =E5=86=99=E9=81=93=EF= =BC=9A Hi, RFC7513 seems to suggest DHCP snooping, i.e., some L2 device on the link from the DHCP server or relay to the client examines the contents of DHCP messages. Unfortunately, sedhcpv6 mandates encryption making snooping impossible. Does it mean that Secure DHCPv6 will be incompatible with SAVI? Thanks - Fred fred.l.templin@boeing.com -----Original Message----- From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Tomek Mrugalski Sent: Wednesday, April 05, 2017 12:07 PM To: dhcwg Cc: draft-ietf-dhc-sedhcpv6 authors Subject: [dhcwg] WGLC on draft-ietf-dhc-sedhcpv6-21 - summary It took a little bit more than planned, but the extra time gave us a couple more comments. We did receive a number of in depth reviews with technical comments. In general, several people praised the significantly improved quality and clarity of the document. Nobody said that is opposed to this work. So from that perspective this last call is a success. However, both chair and at least one co-author feel that an important concern has not been addressed yet. There currently are no known implementations or prototypes of this draft. For a typical DHCP draft that adds an option or two that would probably be fine, but for this particular draft it is not. For two reasons: First, we feel that this is an essential piece of the whole DHCPv6 ecosystem and as such require much more scrutiny then an average draft. Second, security is a complex matter and any unclear aspects would gravely damage the interoperability. Jinmei had put it well: "I suspect the current spec still has some points that are critically unclear, which you would immediately notice once you tried to implement it." Given that, we declare that more effort is needed before this work is deemed ready for IESG. At the same time, chairs would like to strongly applaud authors' efforts to improve this work. This version is significantly better than its predecessors. Thank you for your hard work. You are doing excellent work. Please continue. Also, to address the concern of missing implementations, chairs would like to announce a DHCP hackathon in Prague. Details are TBD, but the primary goal will be to have at least two independent implementations of that draft. The hackathon will take place the weekend before IETF meeting (that's July 15-16). A separate announcement will be sent soon. That is well over 3 months away. Authors and supporters of this work, please seriously consider dedicating some of your time implementing prototypes and attending the hackathon, if you can. If you can't we will organize some means for participating remotely. Thank you to the authors and to everyone who commented. Bernie & Tomek _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg --94eb2c055938707880054d853e49 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,<= /div>

I have considered this problem. Yes, secure DHCPv6= is incompatible with SAVI.
If secure DHCPv6 is implemented, SAVI= cannot work well and have to be updated.

Best Reg= ards,
Lishan
=E5=9C= =A8 2017=E5=B9=B44=E6=9C=8819=E6=97=A5=EF=BC=8C=E4=B8=8B=E5=8D=889:41=EF=BC= =8CTemplin, Fred L <Fred.L.Templin@boeing.com> =E5=86=99=E9=81=93=EF=BC=9A
Hi,<= br>
RFC7513 seems to suggest DHCP snooping, i.e., some L2 device on the = link from
the DHCP server or relay to the client examines the contents o= f DHCP messages.
Unfortunately, sedhcpv6 mandates encryption making snoo= ping impossible.

Does it mean that Secure DHCPv6 will be incompatibl= e with SAVI?

Thanks - Fred
fred.l.templin@boeing.com

-----Original Message-----
From: dhcwg [mailto:dhcwg-bounces@ietf.org<= wbr>] On Behalf Of Tomek Mrugalski
Sent: Wednesday, April 05, 2017 12:07= PM
To: dhcwg <dh= cwg@ietf.org>
Cc: draft-ietf-dhc-sedhcpv6 authors <draft-ietf-dhc-s= edhcpv6@ietf.org>
Subject: [dhcwg] WGLC on draft-ietf-dhc-se= dhcpv6-21 - summary

It took a little bit more than planned, but the = extra time gave us a
couple more comments.

We did receive a numbe= r of in depth reviews with technical comments. In
general, several peopl= e praised the significantly improved quality and
clarity of the document= . Nobody said that is opposed to this work. So
from that perspective thi= s last call is a success.

However, both chair and at least one co-au= thor feel that an important
concern has not been addressed yet. There cu= rrently are no known
implementations or prototypes of this draft. For a = typical DHCP draft
that adds an option or two that would probably be fin= e, but for this
particular draft it is not. For two reasons: First, we f= eel that this is
an essential piece of the whole DHCPv6 ecosystem and as= such require
much more scrutiny then an average draft. Second, security= is a complex
matter and any unclear aspects would gravely damage theinteroperability. Jinmei had put it well: "I suspect the current spec=
still has some points that are critically unclear, which you would
i= mmediately notice once you tried to implement it."

Given that, = we declare that more effort is needed before this work is
deemed ready f= or IESG. At the same time, chairs would like to strongly
applaud authors= ' efforts to improve this work. This version is
significantly better= than its predecessors. Thank you for your hard
work. You are doing exce= llent work. Please continue.

Also, to address the concern of missing= implementations, chairs would
like to announce a DHCP hackathon in Prag= ue. Details are TBD, but the
primary goal will be to have at least two i= ndependent implementations of
that draft. The hackathon will take place = the weekend before IETF
meeting (that's July 15-16). A separate anno= uncement will be sent soon.

That is well over 3 months away. Authors= and supporters of this work,
please seriously consider dedicating some = of your time implementing
prototypes and attending the hackathon, if you= can. If you can't we will
organize some means for participating rem= otely.

Thank you to the authors and to everyone who commented.
Bernie & Tomek

__________________________________________= _____
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhc= wg



--94eb2c055938707880054d853e49-- From nobody Wed Apr 19 06:52:04 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 097E8127B60; Wed, 19 Apr 2017 06:52:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 2dMLieJJJjmX; Wed, 19 Apr 2017 06:52:00 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (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 ED9AF127868; Wed, 19 Apr 2017 06:51:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v3JDpwlZ051862; Wed, 19 Apr 2017 06:51:59 -0700 Received: from XCH15-06-09.nw.nos.boeing.com (xch15-06-09.nw.nos.boeing.com [137.136.239.172]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v3JDprAH051819 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Wed, 19 Apr 2017 06:51:53 -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; Wed, 19 Apr 2017 06:51:52 -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; Wed, 19 Apr 2017 06:51:52 -0700 From: "Templin, Fred L" To: Lishan Li CC: Tomek Mrugalski , dhcwg , draft-ietf-dhc-sedhcpv6 authors Thread-Topic: [dhcwg] WGLC on draft-ietf-dhc-sedhcpv6-21 - summary Thread-Index: AQHSrj/Om2r5zeyMdU24tzLmWNqPBaHMxxkAgAB4SgD//4s1MA== Date: Wed, 19 Apr 2017 13:51:52 +0000 Message-ID: <913306d77da44ee48136f4e86e26b433@XCH15-06-08.nw.nos.boeing.com> References: <1380758a-b7d0-bb73-bf58-4e318e88a6d0@gmail.com> <257f4b807afa44d5841e7764859f150c@XCH15-06-08.nw.nos.boeing.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 x-originating-ip: [137.136.248.6] Content-Type: multipart/alternative; boundary="_000_913306d77da44ee48136f4e86e26b433XCH150608nwnosboeingcom_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-sedhcpv6-21 - summary 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, 19 Apr 2017 13:52:02 -0000 --_000_913306d77da44ee48136f4e86e26b433XCH150608nwnosboeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 w5ggIEkgaGF2ZSBjb25zaWRlcmVkIHRoaXMgcHJvYmxlbS4gWWVzLCBzZWN1cmUgREhDUHY2IGlz IGluY29tcGF0aWJsZSB3aXRoIFNBVkkuDQoNCsOYICBJZiBzZWN1cmUgREhDUHY2IGlzIGltcGxl bWVudGVkLCBTQVZJIGNhbm5vdCB3b3JrIHdlbGwgYW5kIGhhdmUgdG8gYmUgdXBkYXRlZC4NCg0K T0ssIHNvIHlvdSBrbmV3IHRoaXMgYnV0IGhhcyBpdCBiZWVuIGRpc2N1c3NlZCBhbHJlYWR5IG9u IHRoZSBsaXN0cyBvciBpcw0KdGhpcyB0aGUgZmlyc3QgdGltZSBpdCBoYXMgY29tZSB1cCBmb3Ig ZGlzY3Vzc2lvbj8gQmVjYXVzZSB0aGlzIHNlZW1zIGxpa2UNCmEgcmF0aGVyIHNpZ25pZmljYW50 IGluY29tcGF0aWJpbGl0eSB0byBtZS4gQW5kLCB3aGVuIHlvdSBzYXkgU0FWSSBoYXMNCnRvIGJl IHVwZGF0ZWQsIGhvdyBkbyB5b3Ugc2VlIHRoYXQgaGFwcGVuaW5nPyBNdXN0IHRoZSBlbmNyeXB0 aW9uIGtleXMNCmhlbGQgYnkgdGhlIGNsaWVudCBhbmQvb3Igc2VydmVyIGJlIHNoYXJlZCB3aXRo IHRoZSBMMiBzbm9vcGluZyBkZXZpY2U/DQoNClRoYW5rcyAtIEZyZWQNCg0KDQpGcm9tOiBMaXNo YW4gTGkgW21haWx0bzpsaWxpc2hhbjQ4QGdtYWlsLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgQXBy aWwgMTksIDIwMTcgNjo0NiBBTQ0KVG86IFRlbXBsaW4sIEZyZWQgTCA8RnJlZC5MLlRlbXBsaW5A Ym9laW5nLmNvbT4NCkNjOiBUb21layBNcnVnYWxza2kgPHRvbWFzei5tcnVnYWxza2lAZ21haWwu Y29tPjsgZGhjd2cgPGRoY3dnQGlldGYub3JnPjsgZHJhZnQtaWV0Zi1kaGMtc2VkaGNwdjYgYXV0 aG9ycyA8ZHJhZnQtaWV0Zi1kaGMtc2VkaGNwdjZAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW2Ro Y3dnXSBXR0xDIG9uIGRyYWZ0LWlldGYtZGhjLXNlZGhjcHY2LTIxIC0gc3VtbWFyeQ0KDQpIaSwN Cg0KSSBoYXZlIGNvbnNpZGVyZWQgdGhpcyBwcm9ibGVtLiBZZXMsIHNlY3VyZSBESENQdjYgaXMg aW5jb21wYXRpYmxlIHdpdGggU0FWSS4NCklmIHNlY3VyZSBESENQdjYgaXMgaW1wbGVtZW50ZWQs IFNBVkkgY2Fubm90IHdvcmsgd2VsbCBhbmQgaGF2ZSB0byBiZSB1cGRhdGVkLg0KDQpCZXN0IFJl Z2FyZHMsDQpMaXNoYW4NCuWcqCAyMDE35bm0NOaciDE55pel77yM5LiL5Y2IOTo0Me+8jFRlbXBs aW4sIEZyZWQgTCA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbTxtYWlsdG86RnJlZC5MLlRlbXBs aW5AYm9laW5nLmNvbT4+IOWGmemBk++8mg0KDQpIaSwNCg0KUkZDNzUxMyBzZWVtcyB0byBzdWdn ZXN0IERIQ1Agc25vb3BpbmcsIGkuZS4sIHNvbWUgTDIgZGV2aWNlIG9uIHRoZSBsaW5rIGZyb20N CnRoZSBESENQIHNlcnZlciBvciByZWxheSB0byB0aGUgY2xpZW50IGV4YW1pbmVzIHRoZSBjb250 ZW50cyBvZiBESENQIG1lc3NhZ2VzLg0KVW5mb3J0dW5hdGVseSwgc2VkaGNwdjYgbWFuZGF0ZXMg ZW5jcnlwdGlvbiBtYWtpbmcgc25vb3BpbmcgaW1wb3NzaWJsZS4NCg0KRG9lcyBpdCBtZWFuIHRo YXQgU2VjdXJlIERIQ1B2NiB3aWxsIGJlIGluY29tcGF0aWJsZSB3aXRoIFNBVkk/DQoNClRoYW5r cyAtIEZyZWQNCmZyZWQubC50ZW1wbGluQGJvZWluZy5jb208bWFpbHRvOmZyZWQubC50ZW1wbGlu QGJvZWluZy5jb20+DQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGRoY3dn IFttYWlsdG86ZGhjd2ctYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86ZGhjd2ctYm91bmNlc0BpZXRm Lm9yZz5dIE9uIEJlaGFsZiBPZiBUb21layBNcnVnYWxza2kNClNlbnQ6IFdlZG5lc2RheSwgQXBy aWwgMDUsIDIwMTcgMTI6MDcgUE0NClRvOiBkaGN3ZyA8ZGhjd2dAaWV0Zi5vcmc8bWFpbHRvOmRo Y3dnQGlldGYub3JnPj4NCkNjOiBkcmFmdC1pZXRmLWRoYy1zZWRoY3B2NiBhdXRob3JzIDxkcmFm dC1pZXRmLWRoYy1zZWRoY3B2NkBpZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1kaGMtc2VkaGNw djZAaWV0Zi5vcmc+Pg0KU3ViamVjdDogW2RoY3dnXSBXR0xDIG9uIGRyYWZ0LWlldGYtZGhjLXNl ZGhjcHY2LTIxIC0gc3VtbWFyeQ0KDQpJdCB0b29rIGEgbGl0dGxlIGJpdCBtb3JlIHRoYW4gcGxh bm5lZCwgYnV0IHRoZSBleHRyYSB0aW1lIGdhdmUgdXMgYQ0KY291cGxlIG1vcmUgY29tbWVudHMu DQoNCldlIGRpZCByZWNlaXZlIGEgbnVtYmVyIG9mIGluIGRlcHRoIHJldmlld3Mgd2l0aCB0ZWNo bmljYWwgY29tbWVudHMuIEluDQpnZW5lcmFsLCBzZXZlcmFsIHBlb3BsZSBwcmFpc2VkIHRoZSBz aWduaWZpY2FudGx5IGltcHJvdmVkIHF1YWxpdHkgYW5kDQpjbGFyaXR5IG9mIHRoZSBkb2N1bWVu dC4gTm9ib2R5IHNhaWQgdGhhdCBpcyBvcHBvc2VkIHRvIHRoaXMgd29yay4gU28NCmZyb20gdGhh dCBwZXJzcGVjdGl2ZSB0aGlzIGxhc3QgY2FsbCBpcyBhIHN1Y2Nlc3MuDQoNCkhvd2V2ZXIsIGJv dGggY2hhaXIgYW5kIGF0IGxlYXN0IG9uZSBjby1hdXRob3IgZmVlbCB0aGF0IGFuIGltcG9ydGFu dA0KY29uY2VybiBoYXMgbm90IGJlZW4gYWRkcmVzc2VkIHlldC4gVGhlcmUgY3VycmVudGx5IGFy ZSBubyBrbm93bg0KaW1wbGVtZW50YXRpb25zIG9yIHByb3RvdHlwZXMgb2YgdGhpcyBkcmFmdC4g Rm9yIGEgdHlwaWNhbCBESENQIGRyYWZ0DQp0aGF0IGFkZHMgYW4gb3B0aW9uIG9yIHR3byB0aGF0 IHdvdWxkIHByb2JhYmx5IGJlIGZpbmUsIGJ1dCBmb3IgdGhpcw0KcGFydGljdWxhciBkcmFmdCBp dCBpcyBub3QuIEZvciB0d28gcmVhc29uczogRmlyc3QsIHdlIGZlZWwgdGhhdCB0aGlzIGlzDQph biBlc3NlbnRpYWwgcGllY2Ugb2YgdGhlIHdob2xlIERIQ1B2NiBlY29zeXN0ZW0gYW5kIGFzIHN1 Y2ggcmVxdWlyZQ0KbXVjaCBtb3JlIHNjcnV0aW55IHRoZW4gYW4gYXZlcmFnZSBkcmFmdC4gU2Vj b25kLCBzZWN1cml0eSBpcyBhIGNvbXBsZXgNCm1hdHRlciBhbmQgYW55IHVuY2xlYXIgYXNwZWN0 cyB3b3VsZCBncmF2ZWx5IGRhbWFnZSB0aGUNCmludGVyb3BlcmFiaWxpdHkuIEppbm1laSBoYWQg cHV0IGl0IHdlbGw6ICJJIHN1c3BlY3QgdGhlIGN1cnJlbnQgc3BlYw0Kc3RpbGwgaGFzIHNvbWUg cG9pbnRzIHRoYXQgYXJlIGNyaXRpY2FsbHkgdW5jbGVhciwgd2hpY2ggeW91IHdvdWxkDQppbW1l ZGlhdGVseSBub3RpY2Ugb25jZSB5b3UgdHJpZWQgdG8gaW1wbGVtZW50IGl0LiINCg0KR2l2ZW4g dGhhdCwgd2UgZGVjbGFyZSB0aGF0IG1vcmUgZWZmb3J0IGlzIG5lZWRlZCBiZWZvcmUgdGhpcyB3 b3JrIGlzDQpkZWVtZWQgcmVhZHkgZm9yIElFU0cuIEF0IHRoZSBzYW1lIHRpbWUsIGNoYWlycyB3 b3VsZCBsaWtlIHRvIHN0cm9uZ2x5DQphcHBsYXVkIGF1dGhvcnMnIGVmZm9ydHMgdG8gaW1wcm92 ZSB0aGlzIHdvcmsuIFRoaXMgdmVyc2lvbiBpcw0Kc2lnbmlmaWNhbnRseSBiZXR0ZXIgdGhhbiBp dHMgcHJlZGVjZXNzb3JzLiBUaGFuayB5b3UgZm9yIHlvdXIgaGFyZA0Kd29yay4gWW91IGFyZSBk b2luZyBleGNlbGxlbnQgd29yay4gUGxlYXNlIGNvbnRpbnVlLg0KDQpBbHNvLCB0byBhZGRyZXNz IHRoZSBjb25jZXJuIG9mIG1pc3NpbmcgaW1wbGVtZW50YXRpb25zLCBjaGFpcnMgd291bGQNCmxp a2UgdG8gYW5ub3VuY2UgYSBESENQIGhhY2thdGhvbiBpbiBQcmFndWUuIERldGFpbHMgYXJlIFRC RCwgYnV0IHRoZQ0KcHJpbWFyeSBnb2FsIHdpbGwgYmUgdG8gaGF2ZSBhdCBsZWFzdCB0d28gaW5k ZXBlbmRlbnQgaW1wbGVtZW50YXRpb25zIG9mDQp0aGF0IGRyYWZ0LiBUaGUgaGFja2F0aG9uIHdp bGwgdGFrZSBwbGFjZSB0aGUgd2Vla2VuZCBiZWZvcmUgSUVURg0KbWVldGluZyAodGhhdCdzIEp1 bHkgMTUtMTYpLiBBIHNlcGFyYXRlIGFubm91bmNlbWVudCB3aWxsIGJlIHNlbnQgc29vbi4NCg0K VGhhdCBpcyB3ZWxsIG92ZXIgMyBtb250aHMgYXdheS4gQXV0aG9ycyBhbmQgc3VwcG9ydGVycyBv ZiB0aGlzIHdvcmssDQpwbGVhc2Ugc2VyaW91c2x5IGNvbnNpZGVyIGRlZGljYXRpbmcgc29tZSBv ZiB5b3VyIHRpbWUgaW1wbGVtZW50aW5nDQpwcm90b3R5cGVzIGFuZCBhdHRlbmRpbmcgdGhlIGhh Y2thdGhvbiwgaWYgeW91IGNhbi4gSWYgeW91IGNhbid0IHdlIHdpbGwNCm9yZ2FuaXplIHNvbWUg bWVhbnMgZm9yIHBhcnRpY2lwYXRpbmcgcmVtb3RlbHkuDQoNClRoYW5rIHlvdSB0byB0aGUgYXV0 aG9ycyBhbmQgdG8gZXZlcnlvbmUgd2hvIGNvbW1lbnRlZC4NCg0KQmVybmllICYgVG9tZWsNCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmRoY3dnIG1h aWxpbmcgbGlzdA0KZGhjd2dAaWV0Zi5vcmc8bWFpbHRvOmRoY3dnQGlldGYub3JnPg0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaGN3Zw0KDQoNCg== --_000_913306d77da44ee48136f4e86e26b433XCH150608nwnosboeingcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiTVMgR290aGljIjsNCglwYW5vc2UtMToyIDExIDYgOSA3IDIgNSA4IDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6IlxATVMgR290aGljIjsNCglwYW5vc2UtMToyIDExIDYgOSA3IDIgNSA4IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGlu aywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJs dWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlw ZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsN Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNv TGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5 OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRv bTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpz cGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBp bjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0K CXttc28tbGlzdC1pZDo2MDMwMjg3MDY7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxp c3QtdGVtcGxhdGUtaWRzOjEwMDk4MDA0NzYgMTY3MTgzOTUwMCA2NzY5ODY5MSA2NzY5ODY5MyA2 NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpA bGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjA7DQoJbXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+DmDsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczsNCgltc28tZmFyZWFzdC1mb250LWZhbWls eTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBs aXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDps ZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9 DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206 MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0u MjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OldpbmdkaW5ncyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9y ZSI+w5g8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsi PiZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPkkgaGF2ZSBjb25zaWRlcmVk IHRoaXMgcHJvYmxlbS4gWWVzLCBzZWN1cmUgREhDUHY2IGlzIGluY29tcGF0aWJsZSB3aXRoIFNB VkkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRl eHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRM aXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OldpbmdkaW5ncyI+PHNwYW4gc3R5bGU9Im1z by1saXN0Oklnbm9yZSI+w5g8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDsiPiZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPklmIHNl Y3VyZSBESENQdjYgaXMgaW1wbGVtZW50ZWQsIFNBVkkgY2Fubm90IHdvcmsgd2VsbCBhbmQgaGF2 ZSB0byBiZSB1cGRhdGVkLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PSywgc28geW91IGtuZXcg dGhpcyBidXQgaGFzIGl0IGJlZW4gZGlzY3Vzc2VkIGFscmVhZHkgb24gdGhlIGxpc3RzIG9yIGlz PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50aGlzIHRoZSBmaXJzdCB0aW1l IGl0IGhhcyBjb21lIHVwIGZvciBkaXNjdXNzaW9uPyBCZWNhdXNlIHRoaXMgc2VlbXMgbGlrZTxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YSByYXRoZXIgc2lnbmlmaWNhbnQg aW5jb21wYXRpYmlsaXR5IHRvIG1lLiBBbmQsIHdoZW4geW91IHNheSBTQVZJIGhhczxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dG8gYmUgdXBkYXRlZCwgaG93IGRvIHlvdSBz ZWUgdGhhdCBoYXBwZW5pbmc/IE11c3QgdGhlIGVuY3J5cHRpb24ga2V5czxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+aGVsZCBieSB0aGUgY2xpZW50IGFuZC9vciBzZXJ2ZXIg YmUgc2hhcmVkIHdpdGggdGhlIEwyIHNub29waW5nIGRldmljZT88bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+VGhhbmtzIC0gRnJlZDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBw dDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IExpc2hhbiBM aSBbbWFpbHRvOmxpbGlzaGFuNDhAZ21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5l c2RheSwgQXByaWwgMTksIDIwMTcgNjo0NiBBTTxicj4NCjxiPlRvOjwvYj4gVGVtcGxpbiwgRnJl ZCBMICZsdDtGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gVG9t ZWsgTXJ1Z2Fsc2tpICZsdDt0b21hc3oubXJ1Z2Fsc2tpQGdtYWlsLmNvbSZndDs7IGRoY3dnICZs dDtkaGN3Z0BpZXRmLm9yZyZndDs7IGRyYWZ0LWlldGYtZGhjLXNlZGhjcHY2IGF1dGhvcnMgJmx0 O2RyYWZ0LWlldGYtZGhjLXNlZGhjcHY2QGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9i PiBSZTogW2RoY3dnXSBXR0xDIG9uIGRyYWZ0LWlldGYtZGhjLXNlZGhjcHY2LTIxIC0gc3VtbWFy eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkhpLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JIGhhdmUgY29uc2lkZXJlZCB0aGlzIHByb2JsZW0uIFllcywgc2VjdXJl IERIQ1B2NiBpcyBpbmNvbXBhdGlibGUgd2l0aCBTQVZJLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgc2VjdXJlIERIQ1B2NiBpcyBpbXBsZW1l bnRlZCwgU0FWSSBjYW5ub3Qgd29yayB3ZWxsIGFuZCBoYXZlIHRvIGJlIHVwZGF0ZWQuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJlc3QgUmVn YXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pkxpc2hhbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+5ZyoPC9zcGFuPiAyMDE3PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+5bm0PC9zcGFuPjQ8c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj7mnIg8L3NwYW4+MTk8c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj7ml6XvvIzk uIvljYg8L3NwYW4+OTo0MTxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPu+8jDwvc3Bhbj5UZW1wbGluLA0KIEZyZWQgTCAmbHQ7PGEgaHJlZj0i bWFpbHRvOkZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20iIHRhcmdldD0iX2JsYW5rIj5GcmVkLkwu VGVtcGxpbkBib2VpbmcuY29tPC9hPiZndDsNCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPuWGmemBk++8mjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGksPGJyPg0KPGJyPg0KUkZDNzUxMyBzZWVtcyB0 byBzdWdnZXN0IERIQ1Agc25vb3BpbmcsIGkuZS4sIHNvbWUgTDIgZGV2aWNlIG9uIHRoZSBsaW5r IGZyb208YnI+DQp0aGUgREhDUCBzZXJ2ZXIgb3IgcmVsYXkgdG8gdGhlIGNsaWVudCBleGFtaW5l cyB0aGUgY29udGVudHMgb2YgREhDUCBtZXNzYWdlcy48YnI+DQpVbmZvcnR1bmF0ZWx5LCBzZWRo Y3B2NiBtYW5kYXRlcyBlbmNyeXB0aW9uIG1ha2luZyBzbm9vcGluZyBpbXBvc3NpYmxlLjxicj4N Cjxicj4NCkRvZXMgaXQgbWVhbiB0aGF0IFNlY3VyZSBESENQdjYgd2lsbCBiZSBpbmNvbXBhdGli bGUgd2l0aCBTQVZJPzxicj4NCjxicj4NClRoYW5rcyAtIEZyZWQ8YnI+DQo8YSBocmVmPSJtYWls dG86ZnJlZC5sLnRlbXBsaW5AYm9laW5nLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmZyZWQubC50ZW1w bGluQGJvZWluZy5jb208L2E+PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTog ZGhjd2cgW21haWx0bzo8YSBocmVmPSJtYWlsdG86ZGhjd2ctYm91bmNlc0BpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPmRoY3dnLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgVG9t ZWsgTXJ1Z2Fsc2tpPGJyPg0KU2VudDogV2VkbmVzZGF5LCBBcHJpbCAwNSwgMjAxNyAxMjowNyBQ TTxicj4NClRvOiBkaGN3ZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRoY3dnQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+ZGhjd2dAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCkNjOiBkcmFmdC1pZXRmLWRo Yy1zZWRoY3B2NiBhdXRob3JzICZsdDs8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1kaGMtc2Vk aGNwdjZAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5kcmFmdC1pZXRmLWRoYy1zZWRoY3B2NkBp ZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KU3ViamVjdDogW2RoY3dnXSBXR0xDIG9uIGRyYWZ0LWlldGYt ZGhjLXNlZGhjcHY2LTIxIC0gc3VtbWFyeTxicj4NCjxicj4NCkl0IHRvb2sgYSBsaXR0bGUgYml0 IG1vcmUgdGhhbiBwbGFubmVkLCBidXQgdGhlIGV4dHJhIHRpbWUgZ2F2ZSB1cyBhPGJyPg0KY291 cGxlIG1vcmUgY29tbWVudHMuPGJyPg0KPGJyPg0KV2UgZGlkIHJlY2VpdmUgYSBudW1iZXIgb2Yg aW4gZGVwdGggcmV2aWV3cyB3aXRoIHRlY2huaWNhbCBjb21tZW50cy4gSW48YnI+DQpnZW5lcmFs LCBzZXZlcmFsIHBlb3BsZSBwcmFpc2VkIHRoZSBzaWduaWZpY2FudGx5IGltcHJvdmVkIHF1YWxp dHkgYW5kPGJyPg0KY2xhcml0eSBvZiB0aGUgZG9jdW1lbnQuIE5vYm9keSBzYWlkIHRoYXQgaXMg b3Bwb3NlZCB0byB0aGlzIHdvcmsuIFNvPGJyPg0KZnJvbSB0aGF0IHBlcnNwZWN0aXZlIHRoaXMg bGFzdCBjYWxsIGlzIGEgc3VjY2Vzcy48YnI+DQo8YnI+DQpIb3dldmVyLCBib3RoIGNoYWlyIGFu ZCBhdCBsZWFzdCBvbmUgY28tYXV0aG9yIGZlZWwgdGhhdCBhbiBpbXBvcnRhbnQ8YnI+DQpjb25j ZXJuIGhhcyBub3QgYmVlbiBhZGRyZXNzZWQgeWV0LiBUaGVyZSBjdXJyZW50bHkgYXJlIG5vIGtu b3duPGJyPg0KaW1wbGVtZW50YXRpb25zIG9yIHByb3RvdHlwZXMgb2YgdGhpcyBkcmFmdC4gRm9y IGEgdHlwaWNhbCBESENQIGRyYWZ0PGJyPg0KdGhhdCBhZGRzIGFuIG9wdGlvbiBvciB0d28gdGhh dCB3b3VsZCBwcm9iYWJseSBiZSBmaW5lLCBidXQgZm9yIHRoaXM8YnI+DQpwYXJ0aWN1bGFyIGRy YWZ0IGl0IGlzIG5vdC4gRm9yIHR3byByZWFzb25zOiBGaXJzdCwgd2UgZmVlbCB0aGF0IHRoaXMg aXM8YnI+DQphbiBlc3NlbnRpYWwgcGllY2Ugb2YgdGhlIHdob2xlIERIQ1B2NiBlY29zeXN0ZW0g YW5kIGFzIHN1Y2ggcmVxdWlyZTxicj4NCm11Y2ggbW9yZSBzY3J1dGlueSB0aGVuIGFuIGF2ZXJh Z2UgZHJhZnQuIFNlY29uZCwgc2VjdXJpdHkgaXMgYSBjb21wbGV4PGJyPg0KbWF0dGVyIGFuZCBh bnkgdW5jbGVhciBhc3BlY3RzIHdvdWxkIGdyYXZlbHkgZGFtYWdlIHRoZTxicj4NCmludGVyb3Bl cmFiaWxpdHkuIEppbm1laSBoYWQgcHV0IGl0IHdlbGw6ICZxdW90O0kgc3VzcGVjdCB0aGUgY3Vy cmVudCBzcGVjPGJyPg0Kc3RpbGwgaGFzIHNvbWUgcG9pbnRzIHRoYXQgYXJlIGNyaXRpY2FsbHkg dW5jbGVhciwgd2hpY2ggeW91IHdvdWxkPGJyPg0KaW1tZWRpYXRlbHkgbm90aWNlIG9uY2UgeW91 IHRyaWVkIHRvIGltcGxlbWVudCBpdC4mcXVvdDs8YnI+DQo8YnI+DQpHaXZlbiB0aGF0LCB3ZSBk ZWNsYXJlIHRoYXQgbW9yZSBlZmZvcnQgaXMgbmVlZGVkIGJlZm9yZSB0aGlzIHdvcmsgaXM8YnI+ DQpkZWVtZWQgcmVhZHkgZm9yIElFU0cuIEF0IHRoZSBzYW1lIHRpbWUsIGNoYWlycyB3b3VsZCBs aWtlIHRvIHN0cm9uZ2x5PGJyPg0KYXBwbGF1ZCBhdXRob3JzJyBlZmZvcnRzIHRvIGltcHJvdmUg dGhpcyB3b3JrLiBUaGlzIHZlcnNpb24gaXM8YnI+DQpzaWduaWZpY2FudGx5IGJldHRlciB0aGFu IGl0cyBwcmVkZWNlc3NvcnMuIFRoYW5rIHlvdSBmb3IgeW91ciBoYXJkPGJyPg0Kd29yay4gWW91 IGFyZSBkb2luZyBleGNlbGxlbnQgd29yay4gUGxlYXNlIGNvbnRpbnVlLjxicj4NCjxicj4NCkFs c28sIHRvIGFkZHJlc3MgdGhlIGNvbmNlcm4gb2YgbWlzc2luZyBpbXBsZW1lbnRhdGlvbnMsIGNo YWlycyB3b3VsZDxicj4NCmxpa2UgdG8gYW5ub3VuY2UgYSBESENQIGhhY2thdGhvbiBpbiBQcmFn dWUuIERldGFpbHMgYXJlIFRCRCwgYnV0IHRoZTxicj4NCnByaW1hcnkgZ29hbCB3aWxsIGJlIHRv IGhhdmUgYXQgbGVhc3QgdHdvIGluZGVwZW5kZW50IGltcGxlbWVudGF0aW9ucyBvZjxicj4NCnRo YXQgZHJhZnQuIFRoZSBoYWNrYXRob24gd2lsbCB0YWtlIHBsYWNlIHRoZSB3ZWVrZW5kIGJlZm9y ZSBJRVRGPGJyPg0KbWVldGluZyAodGhhdCdzIEp1bHkgMTUtMTYpLiBBIHNlcGFyYXRlIGFubm91 bmNlbWVudCB3aWxsIGJlIHNlbnQgc29vbi48YnI+DQo8YnI+DQpUaGF0IGlzIHdlbGwgb3ZlciAz IG1vbnRocyBhd2F5LiBBdXRob3JzIGFuZCBzdXBwb3J0ZXJzIG9mIHRoaXMgd29yayw8YnI+DQpw bGVhc2Ugc2VyaW91c2x5IGNvbnNpZGVyIGRlZGljYXRpbmcgc29tZSBvZiB5b3VyIHRpbWUgaW1w bGVtZW50aW5nPGJyPg0KcHJvdG90eXBlcyBhbmQgYXR0ZW5kaW5nIHRoZSBoYWNrYXRob24sIGlm IHlvdSBjYW4uIElmIHlvdSBjYW4ndCB3ZSB3aWxsPGJyPg0Kb3JnYW5pemUgc29tZSBtZWFucyBm b3IgcGFydGljaXBhdGluZyByZW1vdGVseS48YnI+DQo8YnI+DQpUaGFuayB5b3UgdG8gdGhlIGF1 dGhvcnMgYW5kIHRvIGV2ZXJ5b25lIHdobyBjb21tZW50ZWQuPGJyPg0KPGJyPg0KQmVybmllICZh bXA7IFRvbWVrPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+DQpkaGN3ZyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86 ZGhjd2dAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5kaGN3Z0BpZXRmLm9yZzwvYT48YnI+DQo8 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RoY3dnIiB0YXJn ZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaGN3Zzwv YT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_913306d77da44ee48136f4e86e26b433XCH150608nwnosboeingcom_-- From nobody Wed Apr 19 07:06: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 E84A61295A0; Wed, 19 Apr 2017 07:06:03 -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 MTRw2nKphGGE; Wed, 19 Apr 2017 07:06:02 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (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 C07D1129A8D; Wed, 19 Apr 2017 07:06:01 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id y33so19707071qta.2; Wed, 19 Apr 2017 07:06:01 -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=WRo1/CoriVJstt/cfVoENbVYpom9oTQ2GlVM/Kc22EM=; b=P1siCVbmrn9MMfkh1K7v2CbHZvR1J5UoYXTofaJfwzjLRZD2i7G+qmjuB6f0hlCciC TG4YyhRRJNjS1JpE4s/tGQYhEAcel8xEcDiyPm1ksfGiWl6Vh53fVbxX8ldHTBCL6xCj EZWYPgzq+rI9xV6+rxc8s3xjC/K4eZWkujzED9lvBrAvi3sM/znJi4efpHexmwRViRYx ixDEqTzWhPcNNSgGmqUvmnOcGayNoB1v/181nTM37mwsd+YH9OX+q2jKCPrQTOI3+Wp3 I4Th8uVa8hPSbl2hTgnbxAiixORfZY/6PfWapeEuYrvb1nsJzYCssn7bT1YWMWgGmSSU CZpA== 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=WRo1/CoriVJstt/cfVoENbVYpom9oTQ2GlVM/Kc22EM=; b=M7f3+zo8PQvR6Dc6QhROVhd7ZDIkFVRn1LnlaA2RgVIM6m5TrJw5db36ptPklUEbn5 7jRUwYuU7ziKngJRGxWB351ZJZ8waS8EcaRqGp89XtwoTGyxQWyazgZKxzxXbyIrtRD8 tN9bCq8pZox6aRZGVS+732C0BDDqCRX08lljpfMp/RxNqtz85M21gAbKBjkzl1RalLP/ JSwtdiKz6y+35JsqgaZwMAGUhjpQZcrRO3cz1GyzIXVmlTCGzfD37xXJMbiw3tGZLMi3 +GDFD566ViCRHkgo4ggTC+cWzcltS2u7jLm5NETxOZ5t4yFsK0r65PI8Vwibaic/pR+B kvMA== X-Gm-Message-State: AN3rC/6d8ObvfbThUgYuB9uOW7Eimx6bhPR+fq/UvjRFdJGra+6ch9jH wS4T7hnFMqqlxsUtq7GwVfybLVUOVQ== X-Received: by 10.237.35.162 with SMTP id j31mr2622895qtc.117.1492610760898; Wed, 19 Apr 2017 07:06:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.58.71 with HTTP; Wed, 19 Apr 2017 07:06:00 -0700 (PDT) In-Reply-To: <913306d77da44ee48136f4e86e26b433@XCH15-06-08.nw.nos.boeing.com> References: <1380758a-b7d0-bb73-bf58-4e318e88a6d0@gmail.com> <257f4b807afa44d5841e7764859f150c@XCH15-06-08.nw.nos.boeing.com> <913306d77da44ee48136f4e86e26b433@XCH15-06-08.nw.nos.boeing.com> From: Lishan Li Date: Wed, 19 Apr 2017 22:06:00 +0800 Message-ID: To: "Templin, Fred L" Cc: Tomek Mrugalski , dhcwg , draft-ietf-dhc-sedhcpv6 authors Content-Type: multipart/alternative; boundary=001a113e7f5430fa8c054d858630 Archived-At: Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-sedhcpv6-21 - summary 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, 19 Apr 2017 14:06:04 -0000 --001a113e7f5430fa8c054d858630 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable It is the first time to be discussed. In fact, I have no idea to update it. I just think that: The client's private key and server's private key is owned by themself and cannot be shared with L2 snooping device. However, this incompatibility cannot be the reason to stop this work. Firstly, we can think out some update method for SAVI. Secondly, in some scenario where SAVI is not deployed but DHCPv6 security needs to be protected, secure DHCPv6 can work. Best Regards, Lishan 2017-04-19 21:51 GMT+08:00 Templin, Fred L : > =C3=98 I have considered this problem. Yes, secure DHCPv6 is incompatibl= e > with SAVI. > > =C3=98 If secure DHCPv6 is implemented, SAVI cannot work well and have t= o be > updated. > > > > OK, so you knew this but has it been discussed already on the lists or is > > this the first time it has come up for discussion? Because this seems lik= e > > a rather significant incompatibility to me. And, when you say SAVI has > > to be updated, how do you see that happening? Must the encryption keys > > held by the client and/or server be shared with the L2 snooping device? > > > > Thanks - Fred > > > > > > *From:* Lishan Li [mailto:lilishan48@gmail.com] > *Sent:* Wednesday, April 19, 2017 6:46 AM > *To:* Templin, Fred L > *Cc:* Tomek Mrugalski ; dhcwg ; > draft-ietf-dhc-sedhcpv6 authors > *Subject:* Re: [dhcwg] WGLC on draft-ietf-dhc-sedhcpv6-21 - summary > > > > Hi, > > > > I have considered this problem. Yes, secure DHCPv6 is incompatible with > SAVI. > > If secure DHCPv6 is implemented, SAVI cannot work well and have to be > updated. > > > > Best Regards, > > Lishan > > =E5=9C=A8 2017=E5=B9=B44=E6=9C=8819=E6=97=A5=EF=BC=8C=E4=B8=8B=E5=8D=889:= 41=EF=BC=8CTemplin, Fred L =E5=86=99=E9=81=93= =EF=BC=9A > > > > Hi, > > RFC7513 seems to suggest DHCP snooping, i.e., some L2 device on the link > from > the DHCP server or relay to the client examines the contents of DHCP > messages. > Unfortunately, sedhcpv6 mandates encryption making snooping impossible. > > Does it mean that Secure DHCPv6 will be incompatible with SAVI? > > Thanks - Fred > fred.l.templin@boeing.com > > > -----Original Message----- > From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Tomek Mrugalski > Sent: Wednesday, April 05, 2017 12:07 PM > To: dhcwg > Cc: draft-ietf-dhc-sedhcpv6 authors > Subject: [dhcwg] WGLC on draft-ietf-dhc-sedhcpv6-21 - summary > > It took a little bit more than planned, but the extra time gave us a > couple more comments. > > We did receive a number of in depth reviews with technical comments. In > general, several people praised the significantly improved quality and > clarity of the document. Nobody said that is opposed to this work. So > from that perspective this last call is a success. > > However, both chair and at least one co-author feel that an important > concern has not been addressed yet. There currently are no known > implementations or prototypes of this draft. For a typical DHCP draft > that adds an option or two that would probably be fine, but for this > particular draft it is not. For two reasons: First, we feel that this is > an essential piece of the whole DHCPv6 ecosystem and as such require > much more scrutiny then an average draft. Second, security is a complex > matter and any unclear aspects would gravely damage the > interoperability. Jinmei had put it well: "I suspect the current spec > still has some points that are critically unclear, which you would > immediately notice once you tried to implement it." > > Given that, we declare that more effort is needed before this work is > deemed ready for IESG. At the same time, chairs would like to strongly > applaud authors' efforts to improve this work. This version is > significantly better than its predecessors. Thank you for your hard > work. You are doing excellent work. Please continue. > > Also, to address the concern of missing implementations, chairs would > like to announce a DHCP hackathon in Prague. Details are TBD, but the > primary goal will be to have at least two independent implementations of > that draft. The hackathon will take place the weekend before IETF > meeting (that's July 15-16). A separate announcement will be sent soon. > > That is well over 3 months away. Authors and supporters of this work, > please seriously consider dedicating some of your time implementing > prototypes and attending the hackathon, if you can. If you can't we will > organize some means for participating remotely. > > Thank you to the authors and to everyone who commented. > > Bernie & Tomek > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > > > > > --001a113e7f5430fa8c054d858630 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It is the first time to be discussed.=C2=A0
In fact, I= have no idea to update it. I just think that: The client's private key= and server's=C2=A0
private key is owned by themself and cann= ot be shared with L2 snooping device.

However, thi= s incompatibility cannot be the reason to stop this work. Firstly, we can= =C2=A0
think out some update method for SAVI. Secondly, in some s= cenario where SAVI is=C2=A0
not deployed but DHCPv6 security need= s to be protected, secure DHCPv6 can work.

Best Regards,
Lishan

2017-04-19 21:51 GMT+08:00 Te= mplin, Fred L <Fred.L.Templin@boeing.com>:

=C3=98=C2=A0 I have considered this problem. Yes, secure DHC= Pv6 is incompatible with SAVI.

=C3=98=C2=A0 If secure DHCPv6 is implemented, SAVI cannot wo= rk well and have to be updated.

=C2=A0

OK, so you knew this but has it been discussed alrea= dy on the lists or is

this the first time it has come up for discussion? B= ecause this seems like

a rather significant incompatibility to me. And, whe= n you say SAVI has

to be updated, how do you see that happening? Must t= he encryption keys

held by the client and/or server be shared with the = L2 snooping device?

=C2=A0

Thanks - Fred

=C2=A0

=C2=A0

From: Lishan Li [mailto:lilishan48@gmail.com]
Sent: Wednesday, April 19, 2017 6:46 AM
To: Templin, Fred L <Fred.L.Templin@boeing.com>
Cc: Tomek Mrugalski <tomasz.mrugalski@gmail.com>; dhcwg <dhcwg@ietf.org>; draft-= ietf-dhc-sedhcpv6 authors <draft-ietf-dhc-sedhcpv6@ietf.org>
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-sedhcpv6-21 - summary=

=C2=A0

Hi,

=C2=A0

I have considered this problem. Yes, secure DHCPv6 i= s incompatible with SAVI.

If secure DHCPv6 is implemented, SAVI cannot work we= ll and have to be updated.

=C2=A0

Best Regards,

Lishan

=E5=9C=A8 2017=E5=B9=B44=E6=9C=8819=E6=97=A5=EF=BC=8C=E4=B8=8B=E5=8D=889:41=EF=BC=8CTemplin, Fred L <= Fred.L.Templin@boeing.com> =E5=86=99=E9=81= =93=EF=BC=9A

=C2=A0

Hi,

RFC7513 seems to suggest DHCP snooping, i.e., some L2 device on the link fr= om
the DHCP server or relay to the client examines the contents of DHCP messag= es.
Unfortunately, sedhcpv6 mandates encryption making snooping impossible.

Does it mean that Secure DHCPv6 will be incompatible with SAVI?

Thanks - Fred
fred.l.templ= in@boeing.com


-----Original Message-----
From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Tomek Mrugalski
Sent: Wednesday, April 05, 2017 12:07 PM
To: dhcwg <dhcwg@iet= f.org>
Cc: draft-ietf-dhc-sedhcpv6 authors <draft-ietf-dhc-sedhcpv6@ietf.org>
Subject: [dhcwg] WGLC on draft-ietf-dhc-sedhcpv6-21 - summary

It took a little bit more than planned, but the extra time gave us a
couple more comments.

We did receive a number of in depth reviews with technical comments. In
general, several people praised the significantly improved quality and
clarity of the document. Nobody said that is opposed to this work. So
from that perspective this last call is a success.

However, both chair and at least one co-author feel that an important
concern has not been addressed yet. There currently are no known
implementations or prototypes of this draft. For a typical DHCP draft
that adds an option or two that would probably be fine, but for this
particular draft it is not. For two reasons: First, we feel that this is an essential piece of the whole DHCPv6 ecosystem and as such require
much more scrutiny then an average draft. Second, security is a complex
matter and any unclear aspects would gravely damage the
interoperability. Jinmei had put it well: "I suspect the current spec<= br> still has some points that are critically unclear, which you would
immediately notice once you tried to implement it."

Given that, we declare that more effort is needed before this work is
deemed ready for IESG. At the same time, chairs would like to strongly
applaud authors' efforts to improve this work. This version is
significantly better than its predecessors. Thank you for your hard
work. You are doing excellent work. Please continue.

Also, to address the concern of missing implementations, chairs would
like to announce a DHCP hackathon in Prague. Details are TBD, but the
primary goal will be to have at least two independent implementations of that draft. The hackathon will take place the weekend before IETF
meeting (that's July 15-16). A separate announcement will be sent soon.=

That is well over 3 months away. Authors and supporters of this work,
please seriously consider dedicating some of your time implementing
prototypes and attending the hackathon, if you can. If you can't we wil= l
organize some means for participating remotely.

Thank you to the authors and to everyone who commented.

Bernie & Tomek

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

=C2=A0<= /p>

=C2=A0


--001a113e7f5430fa8c054d858630-- From nobody Wed Apr 19 07:47: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 0544612952D for ; Wed, 19 Apr 2017 07:47:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=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 vagvVX9IDAUx for ; Wed, 19 Apr 2017 07:47:02 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (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 1820B12944F for ; Wed, 19 Apr 2017 07:47:02 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id h67so21977490qke.0 for ; Wed, 19 Apr 2017 07:47:02 -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=RaiG2aGCU5kehg3t7smAywDBHpWg2VUiZXGtx8xBrrc=; b=cWiERK9rmjrjFB2SqsLaB2F5IKp5wNdQBAwAPxaRueSQKdUG03pjQ3MlC5GeHAiOLY Jqn6CBBO6f9xRKvMVVj9kzwDKL0Ox731TQkOxNCZxcSJUT0uKFQUfu67WFgzdO7oXN+9 7NhhSh7BInobkO8IgRKktG6fizjJTCACwdfjl4YydSDFhgSBQEEwQqQKTuuGBkSg6v1m 93VCX4bCeFyOhF45AlSAVJBRyjwLliDkUHDccV1o63ZQPmnkJe2tX/bfCfMWqGfScQ6E bggkRAn31Bszb1vK8A2Z+q5fzLyLKlZiVQNTeyAn6ETZySc5S4nBH0qbpDjWrb4WR00X f3gA== 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=RaiG2aGCU5kehg3t7smAywDBHpWg2VUiZXGtx8xBrrc=; b=F6Nmj78CrdavW74b8XVRsv8KpCiloG7JVvEE+H2Rev+h5biAIfnZ7QeDpxFlwIxxXZ mOdppdZsRIGfXhEDce4acgm7dfudUE+BXo5/oP3HpHGBMfh/DtSlPfrDchZVhi3IbwyV IV/33tk6JDvajdmyQqfS0cqvMpZwlIHmEqv+WQvqIYns089D1y/XrRPce5CE9xjSZ5XD 4V+YpHXoaTEZjwg4aEc3Szi6CqABZMVJI8+VgG/nm//Zo7oPfp4IoE9IHG9+bXSxLuNh /cHOUphUWPFkrUL1nlHBYB2JKbitHvKQheZ9PcXnHXc/GNvVTeIj8PvWg9FhE8gulgQ+ pTLQ== X-Gm-Message-State: AN3rC/6OjqbrRYmTAnlwS3XRvjciS6rq40o4ttJpu+YEa5OltZxU5886 Pe0Adxz8FIst+w== X-Received: by 10.55.146.135 with SMTP id u129mr2651071qkd.124.1492613221200; Wed, 19 Apr 2017 07:47:01 -0700 (PDT) Received: from [10.0.20.202] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id 123sm2012155qkm.22.2017.04.19.07.47.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Apr 2017 07:47:00 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ted Lemon In-Reply-To: Date: Wed, 19 Apr 2017 10:46:59 -0400 Cc: "Templin, Fred L" , dhcwg , draft-ietf-dhc-sedhcpv6 authors Content-Transfer-Encoding: quoted-printable Message-Id: <2FED93A1-E998-43D1-AD46-13DA14A4F1BD@fugue.com> References: <1380758a-b7d0-bb73-bf58-4e318e88a6d0@gmail.com> <257f4b807afa44d5841e7764859f150c@XCH15-06-08.nw.nos.boeing.com> <913306d77da44ee48136f4e86e26b433@XCH15-06-08.nw.nos.boeing.com> To: Lishan Li X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-sedhcpv6-21 - summary 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, 19 Apr 2017 14:47:04 -0000 It might be worth evaluating how commonly SAVI is deployed in practice = before becoming concerned about this. Also, since SAVI actually solves = some of the same problems as sedhcpv6, it seems reasonable to think that = the availability of two incompatible solutions may still result in more = overall win. A way to address this in the document would be to simply = say that at present, the two approaches solve related problems but are = mutually incompatible, so the choice must be made between one and the = other. This is also not a very serious problem in the sense that RFC 7513 = proposes a DHCPv6-only address configuration model, which is not very = common in practice. In practice, SAVI First Come First Served (RFC = 6620) should be compatible with secure DHCPv6, and will generally = produce better results. For sites that want absolute control over address assignment through a = DHCP server, the options are either to not use Secure DHCPv6, or to = implement an updated SAVI that would have to be written up that takes = the assigned IP address out of the un-signed wrapper, or else uses layer = 2 relay in combination with putting the IP address in the relay wrapper, = as you've been advocating, Fred. From nobody Wed Apr 19 11:55:57 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 84354126C7A; Wed, 19 Apr 2017 11:55:54 -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.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149262815449.19325.17172513716907024776@ietfa.amsl.com> Date: Wed, 19 Apr 2017 11:55:54 -0700 Archived-At: Subject: [dhcwg] I-D Action: draft-ietf-dhc-relay-server-security-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, 19 Apr 2017 18:55:54 -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-05.txt Pages : 8 Date : 2017-04-19 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-05 https://datatracker.ietf.org/doc/html/draft-ietf-dhc-relay-server-security-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-relay-server-security-05 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 Apr 19 12:00:19 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 AEA52129C3D; Wed, 19 Apr 2017 12:00:07 -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 SYd9OTyY0caM; Wed, 19 Apr 2017 12:00:06 -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 AA7F0129C2B; Wed, 19 Apr 2017 12:00:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1418; q=dns/txt; s=iport; t=1492628405; x=1493838005; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=TvRYvKGJhMv4AkMd4yatXMaUeajJ6NYOMj+hGogxRoo=; b=F9JgVBU+bVZAPMvolf5KuIuCDkg1fdahdYJc/LoRYvs868dLSkU/Ulg6 maXn/xDjGzvTMWQ9FrGqQvlXSmtAxLK7KWm3VwrYgK47MPe0UXyhTxOCK mRJcjFx/YFKznp+0kw5vfS0XEfIfyllX7ukpevEpyb3hay0qFn1VakN6t U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AcAQA7s/dY/5BdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1RhgQsHg2CKFadFgg8uhXYcg2o/GAECAQEBAQEBAWsohT8RRRI?= =?us-ascii?q?BIgImAgQwFREBBA4NihEOqjyCJosiAQEBAQEBAQEBAQEBAQEBAQEBAQEZBYELh?= =?us-ascii?q?yWGMYEREQEGgxyCXwWQAo0tAYcQi2KCCYUxiGGBOpQQAR84fQhjFRqHD3UBhjy?= =?us-ascii?q?BIYENAQEB?= X-IronPort-AV: E=Sophos;i="5.37,222,1488844800"; d="scan'208";a="412926181" 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; 19 Apr 2017 19:00:04 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v3JJ02Ui027707 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 19 Apr 2017 19:00:03 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; Wed, 19 Apr 2017 14:00:01 -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, 19 Apr 2017 14:00:01 -0500 From: "Bernie Volz (volz)" To: The IESG CC: "dhc-chairs@ietf.org" , "draft-ietf-dhc-relay-server-security@ietf.org" , "dhcwg@ietf.org" Thread-Topic: IESG Discusses on draft-ietf-dhc-relay-server-security-04 Thread-Index: AdK5Pr76PLardk2ISZm7qPiNR7mu5g== Date: Wed, 19 Apr 2017 19:00:01 +0000 Message-ID: <36c922c04bee4233b58e5185f0a4f9ad@XCH-ALN-003.cisco.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.131.32.33] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [dhcwg] IESG Discusses on draft-ietf-dhc-relay-server-security-04 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, 19 Apr 2017 19:00:08 -0000 SGk6DQoNCkkndmUgcG9zdGVkIGEgLTA1IHdoaWNoIHRyaWVzIHRvIGFkZHJlc3MgdGhlIERpc2N1 c3NlcyAoZXhjZXB0IHBlcmhhcHMgZm9yIEJlbiBDYW1wYmVsbCdzIGFib3V0IHdoaWNoIEkgc2Vu dCBhIHNlcGFyYXRlIGVtYWlsIG9uIDQvMTIpLiBQbGVhc2UgcmV2aWV3IGFuZCBsZXQgbWUga25v dyBpZiB0aGlzIGhlbHBzIG9yIHdoZXRoZXIgbW9yZSBjaGFuZ2VzIGFyZSBuZWVkZWQuDQoNCkEg bmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1pZXRmLWRoYy1yZWxheS1zZXJ2ZXItc2VjdXJpdHkt MDUudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEJlcm5pZSBWb2x6IGFu ZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0LWlldGYtZGhj LXJlbGF5LXNlcnZlci1zZWN1cml0eQ0KUmV2aXNpb246CTA1DQpUaXRsZToJCVNlY3VyaXR5IG9m IE1lc3NhZ2VzIEV4Y2hhbmdlZCBCZXR3ZWVuIFNlcnZlcnMgYW5kIFJlbGF5IEFnZW50cw0KRG9j dW1lbnQgZGF0ZToJMjAxNy0wNC0xOQ0KR3JvdXA6CQlkaGMNClBhZ2VzOgkJOA0KVVJMOiAgICAg ICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLWRo Yy1yZWxheS1zZXJ2ZXItc2VjdXJpdHktMDUudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1kaGMtcmVsYXktc2VydmVyLXNlY3Vy aXR5Lw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLWRoYy1yZWxheS1zZXJ2ZXItc2VjdXJpdHktMDUNCkh0bWxpemVkOiAgICAgICBodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtZGhjLXJlbGF5LXNlcnZl ci1zZWN1cml0eS0wNQ0KRGlmZjogICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2Rp ZmY/dXJsMj1kcmFmdC1pZXRmLWRoYy1yZWxheS1zZXJ2ZXItc2VjdXJpdHktMDUNCg0KLSBCZXJu aWUgVm9seg0K From nobody Wed Apr 19 13:34:32 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 84475129C14 for ; Wed, 19 Apr 2017 12:14:16 -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_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kaloom.onmicrosoft.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 72XP_hRYnDG8 for ; Wed, 19 Apr 2017 12:14:07 -0700 (PDT) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660108.outbound.protection.outlook.com [40.107.66.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6217612945A for ; Wed, 19 Apr 2017 12:14:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kaloom.onmicrosoft.com; s=selector1-kaloom-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/dv/o0VfGynYPHSa0yAmeBjLU1ebl1OOUGL/zZ5E7PA=; b=HOmjABaAgfb7nFwltIhkgrmmEKMrKMcmNDJn1MA5RWLgrSzopfgc43GSLUF/QDiDE+6WA0yMq+WyrwwSqVbw71GXCL38SZQWjCFYn+lzgKodU/MDzZK3xpChDqfoFICBugX2AIueVit5kKZ93FuGkOycBbU1LeWmhweDpJMKAjA= Received: from YQXPR01MB0392.CANPRD01.PROD.OUTLOOK.COM (10.165.138.18) by YQXPR01MB0389.CANPRD01.PROD.OUTLOOK.COM (10.165.138.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.10; Wed, 19 Apr 2017 19:14:05 +0000 Received: from YQXPR01MB0392.CANPRD01.PROD.OUTLOOK.COM ([10.165.138.18]) by YQXPR01MB0392.CANPRD01.PROD.OUTLOOK.COM ([10.165.138.18]) with mapi id 15.01.1034.018; Wed, 19 Apr 2017 19:14:04 +0000 From: Suresh Krishnan To: Bernie Volz CC: RFC Editor , "davidmiles@google.com" , "Wojciech Dec (wdec)" , "James.Bristow@swisscom.com" , "roberta.maglione@telecomitalia.it" , Terry Manderson , Tomek Mrugalski , "niels@qacafe.com" , "dhcwg@ietf.org" Thread-Topic: [Technical Errata Reported] RFC6704 (4995) Thread-Index: AQHStVDWuuiX81czlkCrNygpnBjILKHMuVCAgABeRgA= Date: Wed, 19 Apr 2017 19:14:04 +0000 Message-ID: <3C90BC64-08D9-432E-B16E-0A3C59ADFCE1@kaloom.com> References: <20170414185617.0DC8FB813F0@rfc-editor.org> <1BDC18F7-878D-4B77-A43E-6B87204C77F3@cisco.com> In-Reply-To: <1BDC18F7-878D-4B77-A43E-6B87204C77F3@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=kaloom.com; x-originating-ip: [67.22.228.34] x-microsoft-exchange-diagnostics: 1; YQXPR01MB0389; 7:zEE8GpZi2lXYliHBChwNvRVfHUg0Z7e4UBAb1gHFG62xYWHsrIWuKPUUq/Bky86nb2DvyrqNf1QdSwbm0Qxk6G2eRGjxYMGpABfWS+Cd4+WPvytGO/dFaa8JBqat6Phk9ALvI46EMm6KuUh7sVwyv+8MtMo/Vpi+KvBmftvAufxagvkzgmsvy+8caIPzohYiqKGKQZKgyrxKLGBXn7weEhZ99NI/fHdWy6iEVUDpqqqV1vWYJxvCE/4QdF1ZbdrRYTdsdY4AXhcc4FsGb49WijnPK+cHJq6o0yqCv10ZeWk/bEE/mN3Bg8SakRoXqbPWyQSqaJpEdeqJVQl7HFBYlg== x-ms-office365-filtering-correlation-id: 5e4d3af4-2c9e-4daa-4bff-08d487583eed x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075); SRVR:YQXPR01MB0389; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014)(1591387915157); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(20161123560025)(2016111802025)(20161123555025)(20161123564025)(6072148)(6043046); SRVR:YQXPR01MB0389; BCL:0; PCL:0; RULEID:; SRVR:YQXPR01MB0389; x-forefront-prvs: 028256169F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39830400002)(39410400002)(39400400002)(24454002)(50944005)(377454003)(102836003)(33656002)(6116002)(53546009)(3846002)(966004)(39060400002)(6246003)(25786009)(3660700001)(7736002)(4326008)(110136004)(38730400002)(53936002)(305945005)(86362001)(2906002)(54356999)(122556002)(76176999)(66066001)(3280700002)(8936002)(50986999)(229853002)(189998001)(82746002)(7416002)(36756003)(6916009)(2950100002)(83716003)(6306002)(81166006)(8676002)(6512007)(16799955002)(2900100001)(6486002)(54906002)(6506006)(15188155005)(77096006)(5660300001)(80792005)(6436002); DIR:OUT; SFP:1102; SCL:1; SRVR:YQXPR01MB0389; H:YQXPR01MB0392.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: <1AE1B534CFC58543BF979E9BE9E0E11A@CANPRD01.PROD.OUTLOOK.COM> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: kaloom.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Apr 2017 19:14:04.7812 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 47d58e26-f796-48e8-ac40-1c365c204513 X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQXPR01MB0389 Archived-At: X-Mailman-Approved-At: Wed, 19 Apr 2017 13:34:31 -0700 Subject: Re: [dhcwg] [Technical Errata Reported] RFC6704 (4995) 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, 19 Apr 2017 19:14:17 -0000 Hi Bernie, I will try to figure out how to do the IANA update. I will hold onto the = erratum until then. Thanks Suresh > On Apr 19, 2017, at 8:36 AM, Bernie Volz (volz) wrote: >=20 > This erratum is verified. Please update it to reflect that is verified. >=20 > We can then notify IANA to have the table corrected. >=20 > - Bernie Volz >=20 > On 4/14/17, 2:56 PM, "RFC Errata System" wrot= e: >=20 > The following errata report has been submitted for RFC6704, > "Forcerenew Nonce Authentication". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D6704&eid=3D4995 >=20 > -------------------------------------- > Type: Technical > Reported by: Niels Widger >=20 > Section: 4 >=20 > Original Text > ------------- > IANA has assigned the following new DHCPv4 option code from the > registry "BOOTP Vendor Extensions and DHCP Options" maintained at > http://www.iana.org/assignments/bootp-dhcp-parameters: >=20 > Tag: 145 >=20 > Name: FORCERENEW_NONCE_CAPABLE >=20 > Data length: 1 >=20 > Description: Forcerenew Nonce Capable >=20 > Reference: this document >=20 > Corrected Text > -------------- > IANA has assigned the following new DHCPv4 option code from the > registry "BOOTP Vendor Extensions and DHCP Options" maintained at > http://www.iana.org/assignments/bootp-dhcp-parameters: >=20 > Tag: 145 >=20 > Name: FORCERENEW_NONCE_CAPABLE >=20 > Data length: n >=20 > Description: Forcerenew Nonce Capable >=20 > Reference: this document >=20 > Notes > ----- > RFC 6704 Section 3.1.1 states that the FORCERENEW_NONCE_CAPABLE option= is variable length and contains a list of algorithm types: >=20 > The FORCERENEW_NONCE_CAPABLE option contains code 145, length n, and > a sequence of algorithms the client supports: >=20 > Code Len Algorithms > +-----+-----+----+----+----+ > | 145 | n | A1 | A2 | A3 | .... > +-----+-----+----+----+----+ >=20 > Figure 1: FORCERENEW_NONCE_CAPABLE Option >=20 > 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 =20 > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC6704 (draft-ietf-dhc-forcerenew-nonce-07) > -------------------------------------- > Title : Forcerenew Nonce Authentication > Publication Date : August 2012 > Author(s) : D. Miles, W. Dec, J. Bristow, R. Maglione > Category : PROPOSED STANDARD > Source : Dynamic Host Configuration > Area : Internet > Stream : IETF > Verifying Party : IESG >=20 >=20 From nobody Wed Apr 19 15:38: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 3B501127337; Wed, 19 Apr 2017 15:38:41 -0700 (PDT) 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 ylvnuJ2Ye2lD; Wed, 19 Apr 2017 15:38:39 -0700 (PDT) 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 A274212025C; Wed, 19 Apr 2017 15:38:39 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 12223B8124F; Wed, 19 Apr 2017 15:38:25 -0700 (PDT) To: niels@qacafe.com, davidmiles@google.com, wdec@cisco.com, James.Bristow@swisscom.com, roberta.maglione@telecomitalia.it X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: suresh@kaloom.com, iesg@ietf.org, dhcwg@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20170419223825.12223B8124F@rfc-editor.org> Date: Wed, 19 Apr 2017 15:38:25 -0700 (PDT) Archived-At: Subject: [dhcwg] [Errata Verified] RFC6704 (4995) 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, 19 Apr 2017 22:38:41 -0000 The following errata report has been verified for RFC6704, "Forcerenew Nonce Authentication". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6704&eid=4995 -------------------------------------- Status: Verified Type: Technical Reported by: Niels Widger Date Reported: 2017-04-14 Verified by: Suresh Krishnan (IESG) Section: 4 Original Text ------------- IANA has assigned the following new DHCPv4 option code from the registry "BOOTP Vendor Extensions and DHCP Options" maintained at http://www.iana.org/assignments/bootp-dhcp-parameters: Tag: 145 Name: FORCERENEW_NONCE_CAPABLE Data length: 1 Description: Forcerenew Nonce Capable Reference: this document Corrected Text -------------- IANA has assigned the following new DHCPv4 option code from the registry "BOOTP Vendor Extensions and DHCP Options" maintained at http://www.iana.org/assignments/bootp-dhcp-parameters: Tag: 145 Name: FORCERENEW_NONCE_CAPABLE Data length: n Description: Forcerenew Nonce Capable Reference: this document Notes ----- RFC 6704 Section 3.1.1 states that the FORCERENEW_NONCE_CAPABLE option is variable length and contains a list of algorithm types: The FORCERENEW_NONCE_CAPABLE option contains code 145, length n, and a sequence of algorithms the client supports: Code Len Algorithms +-----+-----+----+----+----+ | 145 | n | A1 | A2 | A3 | .... +-----+-----+----+----+----+ Figure 1: FORCERENEW_NONCE_CAPABLE Option Verifier's note(Suresh Krishnan - INT AD): This erratum is correct and it requires a change in the IANA registry. I authorize IANA to make this change. -------------------------------------- RFC6704 (draft-ietf-dhc-forcerenew-nonce-07) -------------------------------------- Title : Forcerenew Nonce Authentication Publication Date : August 2012 Author(s) : D. Miles, W. Dec, J. Bristow, R. Maglione Category : PROPOSED STANDARD Source : Dynamic Host Configuration Area : Internet Stream : IETF Verifying Party : IESG From nobody Wed Apr 19 19:50: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 A3DDC129C13 for ; Wed, 19 Apr 2017 15:16:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 vH6nyBh8G_d9 for ; Wed, 19 Apr 2017 15:16:32 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81B3812EA8C for ; Wed, 19 Apr 2017 15:16:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 98D971C1B1A; Wed, 19 Apr 2017 15:16:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3EYSDLRQ7fZ; Wed, 19 Apr 2017 15:16:24 -0700 (PDT) Received: from [10.0.1.11] (cpe-76-168-191-223.socal.res.rr.com [76.168.191.223]) by c8a.amsl.com (Postfix) with ESMTPA id 236AC1C1B14; Wed, 19 Apr 2017 15:16:24 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Megan Ferguson In-Reply-To: <3C90BC64-08D9-432E-B16E-0A3C59ADFCE1@kaloom.com> Date: Wed, 19 Apr 2017 15:16:29 -0700 Cc: "Bernie Volz (volz)" , RFC System , "davidmiles@google.com" , "Wojciech Dec (wdec)" , "James.Bristow@swisscom.com" , "roberta.maglione@telecomitalia.it" , Terry Manderson , Tomek Mrugalski , "niels@qacafe.com" , "dhcwg@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <9A5F946F-C968-49AE-A6E7-F24608AEB3BE@amsl.com> References: <20170414185617.0DC8FB813F0@rfc-editor.org> <1BDC18F7-878D-4B77-A43E-6B87204C77F3@cisco.com> <3C90BC64-08D9-432E-B16E-0A3C59ADFCE1@kaloom.com> To: Suresh Krishnan X-Mailer: Apple Mail (2.1878.6) Archived-At: X-Mailman-Approved-At: Wed, 19 Apr 2017 19:50:40 -0700 Subject: Re: [dhcwg] [Technical Errata Reported] RFC6704 (4995) 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, 19 Apr 2017 22:16:36 -0000 Hi Suresh, Just forwarding this message from Amanda at IANA for FYI as I see you = were not CC=92d. Thank you. RFC Editor/mf > Begin forwarded message: >=20 >> From: "Amanda Baber via RT" >> Subject: [IANA #957997] [IANA] Fwd: [Technical Errata Reported] = RFC6704 (4995) >> Date: April 18, 2017 at 2:16:19 PM PDT >> Cc: rfc-editor@rfc-editor.org, volz@cisco.com, = terry.manderson@icann.org >> Reply-To: iana-issues-comment@iana.org >>=20 >> Hi Bernie, >>=20 >> Megan forwarded us this note about errata 4995. >>=20 >> Because the IANA Considerations section specifically says that the = entry in the length field is "1," and it's an IETF Consensus registry, = we would need an AD-verified errata report in order to change the length = to "n." We'll add a link to the errata report to the reference field = when we make the change. >>=20 >> Best regards, >>=20 >> Amanda Baber >> Lead IANA Services Specialist On Apr 19, 2017, at 12:14 PM, Suresh Krishnan wrote: > Hi Bernie, > I will try to figure out how to do the IANA update. I will hold onto = the erratum until then. >=20 > Thanks > Suresh >=20 >> On Apr 19, 2017, at 8:36 AM, Bernie Volz (volz) = wrote: >>=20 >> This erratum is verified. Please update it to reflect that is = verified. >>=20 >> We can then notify IANA to have the table corrected. >>=20 >> - Bernie Volz >>=20 >> On 4/14/17, 2:56 PM, "RFC Errata System" = wrote: >>=20 >> The following errata report has been submitted for RFC6704, >> "Forcerenew Nonce Authentication". >>=20 >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=3D6704&eid=3D4995 >>=20 >> -------------------------------------- >> Type: Technical >> Reported by: Niels Widger >>=20 >> Section: 4 >>=20 >> Original Text >> ------------- >> IANA has assigned the following new DHCPv4 option code from the >> registry "BOOTP Vendor Extensions and DHCP Options" maintained = at >> http://www.iana.org/assignments/bootp-dhcp-parameters: >>=20 >> Tag: 145 >>=20 >> Name: FORCERENEW_NONCE_CAPABLE >>=20 >> Data length: 1 >>=20 >> Description: Forcerenew Nonce Capable >>=20 >> Reference: this document >>=20 >> Corrected Text >> -------------- >> IANA has assigned the following new DHCPv4 option code from the >> registry "BOOTP Vendor Extensions and DHCP Options" maintained = at >> http://www.iana.org/assignments/bootp-dhcp-parameters: >>=20 >> Tag: 145 >>=20 >> Name: FORCERENEW_NONCE_CAPABLE >>=20 >> Data length: n >>=20 >> Description: Forcerenew Nonce Capable >>=20 >> Reference: this document >>=20 >> Notes >> ----- >> RFC 6704 Section 3.1.1 states that the FORCERENEW_NONCE_CAPABLE = option is variable length and contains a list of algorithm types: >>=20 >> The FORCERENEW_NONCE_CAPABLE option contains code 145, length n, = and >> a sequence of algorithms the client supports: >>=20 >> Code Len Algorithms >> +-----+-----+----+----+----+ >> | 145 | n | A1 | A2 | A3 | .... >> +-----+-----+----+----+----+ >>=20 >> Figure 1: FORCERENEW_NONCE_CAPABLE Option >>=20 >> 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 =20 >> can log in to change the status and edit the report, if necessary.=20= >>=20 >> -------------------------------------- >> RFC6704 (draft-ietf-dhc-forcerenew-nonce-07) >> -------------------------------------- >> Title : Forcerenew Nonce Authentication >> Publication Date : August 2012 >> Author(s) : D. Miles, W. Dec, J. Bristow, R. Maglione >> Category : PROPOSED STANDARD >> Source : Dynamic Host Configuration >> Area : Internet >> Stream : IETF >> Verifying Party : IESG >>=20 >>=20 >=20 From nobody Wed Apr 19 19:50: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 4E1C7129B7F for ; Wed, 19 Apr 2017 15:39:02 -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_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kaloom.onmicrosoft.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 XNKvzfONzxSA for ; Wed, 19 Apr 2017 15:38:54 -0700 (PDT) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670133.outbound.protection.outlook.com [40.107.67.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81A1012025C for ; Wed, 19 Apr 2017 15:38:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kaloom.onmicrosoft.com; s=selector1-kaloom-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=V8W6PRofRw32cRY7ICs9OUMvmKrb/MwcLRAd0ZkdwSM=; b=dmtkcMmcD4RZLFWjrIceyt7fH//JxzLNRx/lFqV7/tueQruI3eKQghOL/zPs3Y+3fHAT1GcFRiHrf5ND7MuZzHBslkBVcVBgeivRTpU02YikoQ9r688nNxekrRjLAxYYy+HBONhD0VpfR467hwA0r0Tru8QWS5BB1+qGehmyp1w= Received: from YQXPR01MB0392.CANPRD01.PROD.OUTLOOK.COM (10.165.138.18) by YQXPR01MB0389.CANPRD01.PROD.OUTLOOK.COM (10.165.138.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.10; Wed, 19 Apr 2017 22:38:49 +0000 Received: from YQXPR01MB0392.CANPRD01.PROD.OUTLOOK.COM ([10.165.138.18]) by YQXPR01MB0392.CANPRD01.PROD.OUTLOOK.COM ([10.165.138.18]) with mapi id 15.01.1034.018; Wed, 19 Apr 2017 22:38:48 +0000 From: Suresh Krishnan To: Megan Ferguson CC: Bernie Volz , RFC Editor , "davidmiles@google.com" , "Wojciech Dec (wdec)" , "James.Bristow@swisscom.com" , "roberta.maglione@telecomitalia.it" , Terry Manderson , Tomek Mrugalski , "niels@qacafe.com" , "dhcwg@ietf.org" Thread-Topic: [Technical Errata Reported] RFC6704 (4995) Thread-Index: AQHStVDWuuiX81czlkCrNygpnBjILKHMuVCAgABeRgCAADL3gIAABjwA Date: Wed, 19 Apr 2017 22:38:48 +0000 Message-ID: <52C8D6BA-C1CE-43B0-82F6-48BB6799BB59@kaloom.com> References: <20170414185617.0DC8FB813F0@rfc-editor.org> <1BDC18F7-878D-4B77-A43E-6B87204C77F3@cisco.com> <3C90BC64-08D9-432E-B16E-0A3C59ADFCE1@kaloom.com> <9A5F946F-C968-49AE-A6E7-F24608AEB3BE@amsl.com> In-Reply-To: <9A5F946F-C968-49AE-A6E7-F24608AEB3BE@amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: amsl.com; dkim=none (message not signed) header.d=none;amsl.com; dmarc=none action=none header.from=kaloom.com; x-originating-ip: [67.22.228.34] x-microsoft-exchange-diagnostics: 1; YQXPR01MB0389; 7:prX1uRy+/GEeLAgOeaUpMekEcMRbcYfrQYtsGhUYjfrzPqUUNHAYR4pNUN2Qn8971cLpq1TUylnnnIPmXAKHuBxy00rdLGoo9T1QdPfV4emDXLP5JVzm0MAzMzW2MMyRFUdADHKlAs5Q51WghhAkyg7dVg5qrs9d5xZZkNBY3Dm6lHBYvOq1NA72NUxKlI1aqwzzjtJkf6hC0b9fHMChAeg4Pt/1PfPt5fhsx9yyfQHX5PeC161YyKjSubfzaOxnA8celKdSnTvOIPtjWYK4FwETcsRbnj8iRaiOu9lh3flwRkKdUa19urHSRGR2r1pm+fsKY8onhKim+jQAiIWwRA== x-ms-office365-filtering-correlation-id: 08ad58e3-beef-4548-a834-08d48774d8ca x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075); SRVR:YQXPR01MB0389; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(100405760836317)(95692535739014)(1591387915157); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(6041248)(20161123560025)(2016111802025)(20161123555025)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(6043046)(6072148); SRVR:YQXPR01MB0389; BCL:0; PCL:0; RULEID:; SRVR:YQXPR01MB0389; x-forefront-prvs: 028256169F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39400400002)(39410400002)(39830400002)(39450400003)(69234005)(50944005)(377454003)(24454002)(83716003)(6916009)(2950100002)(50986999)(229853002)(82746002)(36756003)(189998001)(7416002)(77096006)(15188155005)(54906002)(6486002)(6436002)(6506006)(80792005)(5660300001)(81166006)(6306002)(8676002)(6512007)(16799955002)(2900100001)(68736007)(38730400002)(53936002)(7736002)(110136004)(4326008)(2906002)(86362001)(102836003)(3846002)(966004)(53546009)(39060400002)(25786009)(6246003)(6116002)(3660700001)(33656002)(305945005)(66066001)(3280700002)(8936002)(122556002)(54356999)(76176999)(93886004)(24704002); DIR:OUT; SFP:1102; SCL:1; SRVR:YQXPR01MB0389; H:YQXPR01MB0392.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <5BEA072313AD4C44822E7EA739AF25ED@CANPRD01.PROD.OUTLOOK.COM> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: kaloom.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Apr 2017 22:38:48.7384 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 47d58e26-f796-48e8-ac40-1c365c204513 X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQXPR01MB0389 Archived-At: X-Mailman-Approved-At: Wed, 19 Apr 2017 19:50:40 -0700 Subject: Re: [dhcwg] [Technical Errata Reported] RFC6704 (4995) 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, 19 Apr 2017 22:39:02 -0000 DQo+IE9uIEFwciAxOSwgMjAxNywgYXQgNjoxNiBQTSwgTWVnYW4gRmVyZ3Vzb24gPG1mZXJndXNv bkBhbXNsLmNvbT4gd3JvdGU6DQo+IA0KPiBIaSBTdXJlc2gsDQo+IA0KPiBKdXN0IGZvcndhcmRp bmcgdGhpcyBtZXNzYWdlIGZyb20gQW1hbmRhIGF0IElBTkEgZm9yIEZZSSBhcyBJIHNlZSB5b3Ug d2VyZSBub3QgQ0PigJlkLg0KDQpUaGFua3MgTWVnYW4uIEkgd2lsbCBnbyBhbmQgdmVyaWZ5IHRo ZSBFcnJhdHVtLg0KDQpSZWdhcmRzDQpTdXJlc2gNCg0KDQo+IA0KPiBUaGFuayB5b3UuDQo+IA0K PiBSRkMgRWRpdG9yL21mDQo+IA0KPj4gQmVnaW4gZm9yd2FyZGVkIG1lc3NhZ2U6DQo+PiANCj4+ PiBGcm9tOiAiQW1hbmRhIEJhYmVyIHZpYSBSVCIgPGlhbmEtaXNzdWVzLWNvbW1lbnRAaWFuYS5v cmc+DQo+Pj4gU3ViamVjdDogW0lBTkEgIzk1Nzk5N10gW0lBTkFdIEZ3ZDogW1RlY2huaWNhbCBF cnJhdGEgUmVwb3J0ZWRdIFJGQzY3MDQgKDQ5OTUpDQo+Pj4gRGF0ZTogQXByaWwgMTgsIDIwMTcg YXQgMjoxNjoxOSBQTSBQRFQNCj4+PiBDYzogcmZjLWVkaXRvckByZmMtZWRpdG9yLm9yZywgdm9s ekBjaXNjby5jb20sIHRlcnJ5Lm1hbmRlcnNvbkBpY2Fubi5vcmcNCj4+PiBSZXBseS1UbzogaWFu YS1pc3N1ZXMtY29tbWVudEBpYW5hLm9yZw0KPj4+IA0KPj4+IEhpIEJlcm5pZSwNCj4+PiANCj4+ PiBNZWdhbiBmb3J3YXJkZWQgdXMgdGhpcyBub3RlIGFib3V0IGVycmF0YSA0OTk1Lg0KPj4+IA0K Pj4+IEJlY2F1c2UgdGhlIElBTkEgQ29uc2lkZXJhdGlvbnMgc2VjdGlvbiBzcGVjaWZpY2FsbHkg c2F5cyB0aGF0IHRoZSBlbnRyeSBpbiB0aGUgbGVuZ3RoIGZpZWxkIGlzICIxLCIgYW5kIGl0J3Mg YW4gSUVURiBDb25zZW5zdXMgcmVnaXN0cnksIHdlIHdvdWxkIG5lZWQgYW4gQUQtdmVyaWZpZWQg ZXJyYXRhIHJlcG9ydCBpbiBvcmRlciB0byBjaGFuZ2UgdGhlIGxlbmd0aCB0byAibi4iIFdlJ2xs IGFkZCBhIGxpbmsgdG8gdGhlIGVycmF0YSByZXBvcnQgdG8gdGhlIHJlZmVyZW5jZSBmaWVsZCB3 aGVuIHdlIG1ha2UgdGhlIGNoYW5nZS4NCj4+PiANCj4+PiBCZXN0IHJlZ2FyZHMsDQo+Pj4gDQo+ Pj4gQW1hbmRhIEJhYmVyDQo+Pj4gTGVhZCBJQU5BIFNlcnZpY2VzIFNwZWNpYWxpc3QNCj4gDQo+ IA0KPiANCj4gT24gQXByIDE5LCAyMDE3LCBhdCAxMjoxNCBQTSwgU3VyZXNoIEtyaXNobmFuIDxT dXJlc2hAa2Fsb29tLmNvbT4gd3JvdGU6DQo+IA0KPj4gSGkgQmVybmllLA0KPj4gSSB3aWxsIHRy eSB0byBmaWd1cmUgb3V0IGhvdyB0byBkbyB0aGUgSUFOQSB1cGRhdGUuIEkgd2lsbCBob2xkIG9u dG8gdGhlIGVycmF0dW0gdW50aWwgdGhlbi4NCj4+IA0KPj4gVGhhbmtzDQo+PiBTdXJlc2gNCj4+ IA0KPj4+IE9uIEFwciAxOSwgMjAxNywgYXQgODozNiBBTSwgQmVybmllIFZvbHogKHZvbHopIDx2 b2x6QGNpc2NvLmNvbT4gd3JvdGU6DQo+Pj4gDQo+Pj4gVGhpcyBlcnJhdHVtIGlzIHZlcmlmaWVk LiBQbGVhc2UgdXBkYXRlIGl0IHRvIHJlZmxlY3QgdGhhdCBpcyB2ZXJpZmllZC4NCj4+PiANCj4+ PiBXZSBjYW4gdGhlbiBub3RpZnkgSUFOQSB0byBoYXZlIHRoZSB0YWJsZSBjb3JyZWN0ZWQuDQo+ Pj4gDQo+Pj4gLSBCZXJuaWUgVm9seg0KPj4+IA0KPj4+IE9uIDQvMTQvMTcsIDI6NTYgUE0sICJS RkMgRXJyYXRhIFN5c3RlbSIgPHJmYy1lZGl0b3JAcmZjLWVkaXRvci5vcmc+IHdyb3RlOg0KPj4+ IA0KPj4+ICBUaGUgZm9sbG93aW5nIGVycmF0YSByZXBvcnQgaGFzIGJlZW4gc3VibWl0dGVkIGZv ciBSRkM2NzA0LA0KPj4+ICAiRm9yY2VyZW5ldyBOb25jZSBBdXRoZW50aWNhdGlvbiIuDQo+Pj4g DQo+Pj4gIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4gIFlvdSBt YXkgcmV2aWV3IHRoZSByZXBvcnQgYmVsb3cgYW5kIGF0Og0KPj4+ICBodHRwOi8vd3d3LnJmYy1l ZGl0b3Iub3JnL2VycmF0YV9zZWFyY2gucGhwP3JmYz02NzA0JmVpZD00OTk1DQo+Pj4gDQo+Pj4g IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4gIFR5cGU6IFRlY2hu aWNhbA0KPj4+ICBSZXBvcnRlZCBieTogTmllbHMgV2lkZ2VyIDxuaWVsc0BxYWNhZmUuY29tPg0K Pj4+IA0KPj4+ICBTZWN0aW9uOiA0DQo+Pj4gDQo+Pj4gIE9yaWdpbmFsIFRleHQNCj4+PiAgLS0t LS0tLS0tLS0tLQ0KPj4+ICAgICBJQU5BIGhhcyBhc3NpZ25lZCB0aGUgZm9sbG93aW5nIG5ldyBE SENQdjQgb3B0aW9uIGNvZGUgZnJvbSB0aGUNCj4+PiAgICAgcmVnaXN0cnkgIkJPT1RQIFZlbmRv ciBFeHRlbnNpb25zIGFuZCBESENQIE9wdGlvbnMiIG1haW50YWluZWQgYXQNCj4+PiAgICAgaHR0 cDovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9ib290cC1kaGNwLXBhcmFtZXRlcnM6DQo+Pj4g DQo+Pj4gICAgIFRhZzogMTQ1DQo+Pj4gDQo+Pj4gICAgIE5hbWU6IEZPUkNFUkVORVdfTk9OQ0Vf Q0FQQUJMRQ0KPj4+IA0KPj4+ICAgICBEYXRhIGxlbmd0aDogMQ0KPj4+IA0KPj4+ICAgICBEZXNj cmlwdGlvbjogRm9yY2VyZW5ldyBOb25jZSBDYXBhYmxlDQo+Pj4gDQo+Pj4gICAgIFJlZmVyZW5j ZTogdGhpcyBkb2N1bWVudA0KPj4+IA0KPj4+ICBDb3JyZWN0ZWQgVGV4dA0KPj4+ICAtLS0tLS0t LS0tLS0tLQ0KPj4+ICAgICBJQU5BIGhhcyBhc3NpZ25lZCB0aGUgZm9sbG93aW5nIG5ldyBESENQ djQgb3B0aW9uIGNvZGUgZnJvbSB0aGUNCj4+PiAgICAgcmVnaXN0cnkgIkJPT1RQIFZlbmRvciBF eHRlbnNpb25zIGFuZCBESENQIE9wdGlvbnMiIG1haW50YWluZWQgYXQNCj4+PiAgICAgaHR0cDov L3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9ib290cC1kaGNwLXBhcmFtZXRlcnM6DQo+Pj4gDQo+ Pj4gICAgIFRhZzogMTQ1DQo+Pj4gDQo+Pj4gICAgIE5hbWU6IEZPUkNFUkVORVdfTk9OQ0VfQ0FQ QUJMRQ0KPj4+IA0KPj4+ICAgICBEYXRhIGxlbmd0aDogbg0KPj4+IA0KPj4+ICAgICBEZXNjcmlw dGlvbjogRm9yY2VyZW5ldyBOb25jZSBDYXBhYmxlDQo+Pj4gDQo+Pj4gICAgIFJlZmVyZW5jZTog dGhpcyBkb2N1bWVudA0KPj4+IA0KPj4+ICBOb3Rlcw0KPj4+ICAtLS0tLQ0KPj4+ICBSRkMgNjcw NCBTZWN0aW9uIDMuMS4xIHN0YXRlcyB0aGF0IHRoZSBGT1JDRVJFTkVXX05PTkNFX0NBUEFCTEUg b3B0aW9uIGlzIHZhcmlhYmxlIGxlbmd0aCBhbmQgY29udGFpbnMgYSBsaXN0IG9mIGFsZ29yaXRo bSB0eXBlczoNCj4+PiANCj4+PiAgVGhlIEZPUkNFUkVORVdfTk9OQ0VfQ0FQQUJMRSBvcHRpb24g Y29udGFpbnMgY29kZSAxNDUsIGxlbmd0aCBuLCBhbmQNCj4+PiAgICAgYSBzZXF1ZW5jZSBvZiBh bGdvcml0aG1zIHRoZSBjbGllbnQgc3VwcG9ydHM6DQo+Pj4gDQo+Pj4gICAgICAgICAgICAgICBD b2RlICAgTGVuICAgQWxnb3JpdGhtcw0KPj4+ICAgICAgICAgICAgICArLS0tLS0rLS0tLS0rLS0t LSstLS0tKy0tLS0rDQo+Pj4gICAgICAgICAgICAgIHwgMTQ1IHwgIG4gIHwgQTEgfCBBMiB8IEEz IHwgLi4uLg0KPj4+ICAgICAgICAgICAgICArLS0tLS0rLS0tLS0rLS0tLSstLS0tKy0tLS0rDQo+ Pj4gDQo+Pj4gICAgICAgICAgICAgICAgICAgRmlndXJlIDE6IEZPUkNFUkVORVdfTk9OQ0VfQ0FQ QUJMRSBPcHRpb24NCj4+PiANCj4+PiAgSW5zdHJ1Y3Rpb25zOg0KPj4+ICAtLS0tLS0tLS0tLS0t DQo+Pj4gIFRoaXMgZXJyYXR1bSBpcyBjdXJyZW50bHkgcG9zdGVkIGFzICJSZXBvcnRlZCIuIElm IG5lY2Vzc2FyeSwgcGxlYXNlDQo+Pj4gIHVzZSAiUmVwbHkgQWxsIiB0byBkaXNjdXNzIHdoZXRo ZXIgaXQgc2hvdWxkIGJlIHZlcmlmaWVkIG9yDQo+Pj4gIHJlamVjdGVkLiBXaGVuIGEgZGVjaXNp b24gaXMgcmVhY2hlZCwgdGhlIHZlcmlmeWluZyBwYXJ0eSAgDQo+Pj4gIGNhbiBsb2cgaW4gdG8g Y2hhbmdlIHRoZSBzdGF0dXMgYW5kIGVkaXQgdGhlIHJlcG9ydCwgaWYgbmVjZXNzYXJ5LiANCj4+ PiANCj4+PiAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+PiAgUkZD NjcwNCAoZHJhZnQtaWV0Zi1kaGMtZm9yY2VyZW5ldy1ub25jZS0wNykNCj4+PiAgLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+PiAgVGl0bGUgICAgICAgICAgICAgICA6 IEZvcmNlcmVuZXcgTm9uY2UgQXV0aGVudGljYXRpb24NCj4+PiAgUHVibGljYXRpb24gRGF0ZSAg ICA6IEF1Z3VzdCAyMDEyDQo+Pj4gIEF1dGhvcihzKSAgICAgICAgICAgOiBELiBNaWxlcywgVy4g RGVjLCBKLiBCcmlzdG93LCBSLiBNYWdsaW9uZQ0KPj4+ICBDYXRlZ29yeSAgICAgICAgICAgIDog UFJPUE9TRUQgU1RBTkRBUkQNCj4+PiAgU291cmNlICAgICAgICAgICAgICA6IER5bmFtaWMgSG9z dCBDb25maWd1cmF0aW9uDQo+Pj4gIEFyZWEgICAgICAgICAgICAgICAgOiBJbnRlcm5ldA0KPj4+ ICBTdHJlYW0gICAgICAgICAgICAgIDogSUVURg0KPj4+ICBWZXJpZnlpbmcgUGFydHkgICAgIDog SUVTRw0KPj4+IA0KPj4+IA0KPj4gDQo+IA0KDQo= From nobody Thu Apr 20 04:25:27 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 985901293F8 for ; Thu, 20 Apr 2017 04:25:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 fftzGKAfQiD7 for ; Thu, 20 Apr 2017 04:25:18 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::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 292DD129A9C for ; Thu, 20 Apr 2017 04:25:15 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id k13so36727153ywk.1 for ; Thu, 20 Apr 2017 04:25:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uMtg/BiTSua9g4TnaLtCD7+Mrp2N6cYy2o5vbedZCdI=; b=muyjZRB+d2Cd+4W3LRkDwPyy4x3+ip/rr780fJLZB1mtlmFNFg0qRnpFaGcGfi4IN0 qqSIObzx5hLfQaRRfG1vNn5k58WBqtIs2yLZFfuIRmD6o1K9SsAlohA1dHh9PSc5coib NpaXwDno+o8IvzoYeeZCriDFTnyyHqMSOhgXAETivJyadow6U66+QkKM1n3dtfmekEnn odiynWk/Bgri3bccSQ6aYSCEsn0nL+PEpLuRH0orzMrmAxFOiFKldnUJNOQHo7f7nnPx IcUJvP47bzp83trEBMc5YerHZ8cYpWaoWwUhJjn8dooPh83hVidMWPN9VYCvkTXGJUUs gewQ== 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=uMtg/BiTSua9g4TnaLtCD7+Mrp2N6cYy2o5vbedZCdI=; b=aETmswrmLe4xtDI+5QzIRR097jjKFPSo7fetc3oJbj6FCyL4WsiC/C//nG2lt9KpdA DteaowDaqvSMd2m+jVNBms/Z9tHepCZlNJF+MUax+ijuPzAVCZAsBAXqWJ/BFMunx9b3 D5cOwWV57Q+DtDe83mqz3RzUOygMms0HV0/BzyZD4gvS/ez9Ly7Pw/R/dhjgllFbpZPe NOQEoJMpFQLgpaKE9Zb9qPD1TAmN0Gsj9eOMiWxHWrR6v13kxNOforpJ5sHLXKs/ewhr /6ogsYBTg7VvO/WYbkUOF7C+A2+Abnfl9SU2PLgIoTUeBFin3OOiNDD9m1eyuqjFTcnf r8zQ== X-Gm-Message-State: AN3rC/77WU8vIG/EHjdmDIVavdk0an5ZawDVWYPURPGSROzlLUt3DpfG 8bqMSEsGpVvZU/qSTYJC4n61f/brKA== X-Received: by 10.129.125.193 with SMTP id y184mr6000607ywc.120.1492687514493; Thu, 20 Apr 2017 04:25:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.113.7 with HTTP; Thu, 20 Apr 2017 04:24:34 -0700 (PDT) In-Reply-To: <36c922c04bee4233b58e5185f0a4f9ad@XCH-ALN-003.cisco.com> References: <36c922c04bee4233b58e5185f0a4f9ad@XCH-ALN-003.cisco.com> From: Eric Rescorla Date: Thu, 20 Apr 2017 07:24:34 -0400 Message-ID: To: "Bernie Volz (volz)" Cc: The IESG , "dhc-chairs@ietf.org" , "draft-ietf-dhc-relay-server-security@ietf.org" , "dhcwg@ietf.org" Content-Type: multipart/alternative; boundary=001a11492bfc0ff9a4054d976540 Archived-At: Subject: Re: [dhcwg] IESG Discusses on draft-ietf-dhc-relay-server-security-04 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, 20 Apr 2017 11:25:20 -0000 --001a11492bfc0ff9a4054d976540 Content-Type: text/plain; charset=UTF-8 Hmm... I don't think this really resolves my concern, which is: is anyone going to actually do this. I don't think that has to be in the draft, but I'd like understand it. -Ekr On Wed, Apr 19, 2017 at 3:00 PM, Bernie Volz (volz) wrote: > Hi: > > I've posted a -05 which tries to address the Discusses (except perhaps for > Ben Campbell's about which I sent a separate email on 4/12). Please review > and let me know if this helps or whether more changes are needed. > > A new version of I-D, draft-ietf-dhc-relay-server-security-05.txt > has been successfully submitted by Bernie Volz and posted to the IETF > repository. > > Name: draft-ietf-dhc-relay-server-security > Revision: 05 > Title: Security of Messages Exchanged Between Servers and Relay > Agents > Document date: 2017-04-19 > Group: dhc > Pages: 8 > URL: https://www.ietf.org/internet-drafts/draft-ietf-dhc-relay- > server-security-05.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-05 > Htmlized: https://datatracker.ietf.org/ > doc/html/draft-ietf-dhc-relay-server-security-05 > Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-relay- > server-security-05 > > - Bernie Volz > --001a11492bfc0ff9a4054d976540 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hmm... I don't think this really resolves my concern, = which is: is anyone going to actually do this.

I don'= ;t think that has to be in the draft, but I'd like understand it.
=

-Ekr


On Wed, Apr 19,= 2017 at 3:00 PM, Bernie Volz (volz) <volz@cisco.com> wrote:
Hi:

I've posted a -05 which tries to address the Discusses (except perhaps = for Ben Campbell's about which I sent a separate email on 4/12). Please= review and let me know if this helps or whether more changes are needed.
A new version of I-D, draft-ietf-dhc-relay-server-security-05.txt
has been successfully submitted by Bernie Volz and posted to the IETF repos= itory.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-dhc-relay-server-<= wbr>security
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A005
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Security of Messages Exchanged Bet= ween Servers and Relay Agents
Document date:=C2=A0 2017-04-19
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 dhc
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 8
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-i= etf-dhc-relay-server-security-05.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-ietf-dhc-relay-server-security/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-ietf-dhc-relay-server-securi= ty-05
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-ietf-dhc-rela= y-server-security-05
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dh= c-relay-server-security-05

- Bernie Volz

--001a11492bfc0ff9a4054d976540-- From nobody Thu Apr 20 06:39:20 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 30F2F129AF7; Thu, 20 Apr 2017 06:39:11 -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 JDjFCIYBeugC; Thu, 20 Apr 2017 06:39:09 -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 7CBAE124BE8; Thu, 20 Apr 2017 06:39:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18900; q=dns/txt; s=iport; t=1492695549; x=1493905149; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=J4RxDbaWTS8qlzdTkujC9OEm6XFGyIXhqneeIHHdUvc=; b=BcZTC7OOYlasFyTSU/lwdkVAiBitJFk58dFPAeAb170WN2TV8sZtdvGp 486yBetojdbX+KB6M25BXrcWMtOPyLtpxudvDDBS12MCc65xCyhNvLxhQ kMFkTyYNmCXUf6Ko5dtTkgx4x5U+lb+nXnxdSZRH0oU79wFUfZa5vIA/P w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AqAQDAuPhY/4QNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm5mYYELB4NgihWRY5AuhTWCDzCFdAIag2A/GAECAQEBAQEBAWs?= =?us-ascii?q?ohRUBAQEBAyMKTBACAQgOAwQBASgDAgICMBQJCAEBBA4FCIoUDqpOgiaLHwEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBARgFiDCDGYMAGIEREQEGTIJQgl8FkASNMAGHFIt?= =?us-ascii?q?lggmFM4hlgT2UEwEfOH0IYxUahw91AYZ/gSGBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.37,225,1488844800"; d="scan'208,217";a="415121290" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Apr 2017 13:39:08 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v3KDd8Uf032750 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 20 Apr 2017 13:39:08 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 20 Apr 2017 08:39: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; Thu, 20 Apr 2017 08:39:07 -0500 From: "Bernie Volz (volz)" To: Eric Rescorla CC: The IESG , "dhc-chairs@ietf.org" , "draft-ietf-dhc-relay-server-security@ietf.org" , "dhcwg@ietf.org" Thread-Topic: IESG Discusses on draft-ietf-dhc-relay-server-security-04 Thread-Index: AdK5Pr76PLardk2ISZm7qPiNR7mu5gAs9mUAAAYfFvA= Date: Thu, 20 Apr 2017 13:39:07 +0000 Message-ID: References: <36c922c04bee4233b58e5185f0a4f9ad@XCH-ALN-003.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 x-originating-ip: [10.98.1.195] Content-Type: multipart/alternative; boundary="_000_b11b9d34fe4c4132b608e6b43e853252XCHALN003ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [dhcwg] IESG Discusses on draft-ietf-dhc-relay-server-security-04 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, 20 Apr 2017 13:39:11 -0000 --_000_b11b9d34fe4c4132b608e6b43e853252XCHALN003ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RXJpYzoNCg0KSSBjYW7igJl0IHNheSB3aGV0aGVyIGFueW9uZSB3b3VsZCBhY3R1YWxseSBkbyB0 aGlzLg0KDQpPbiB0aGUgb25lIGhhbmQsIE5PVCBoYXZpbmcgdGhpcyBkb2N1bWVudCBtYXkgbWFr ZSBpdCBsZXNzIGxpa2VseSB0aGF0IGFueW9uZSB3b3VsZCwgc28gaGF2aW5nIHRoZSBkb2N1bWVu dCBDT1VMRCBtZWFuIHNvbWVvbmUgd2lsbCBtYWtlIHVzZSBvZiBpdC4NCg0KSSBhbHNvIHRoaW5r IHRoYXQgdGhlcmUgbWF5IGJlIGxpdHRsZSB0byBhZGQgdG8gYSBzZXJ2ZXIgb3IgcmVsYXkgaW1w bGVtZW50YXRpb24gdG8gZG8gdGhpcyBzaW5jZSBpdCBtYXkganVzdCByZXF1aXJlIHNvbWUg4oCc aG9zdOKAnSBjb25maWd1cmF0aW9uIOKAkyBhcyBpbiBodHRwczovL2FjY2Vzcy5yZWRoYXQuY29t L2RvY3VtZW50YXRpb24vZW4tVVMvUmVkX0hhdF9FbnRlcnByaXNlX0xpbnV4LzQvaHRtbC9TZWN1 cml0eV9HdWlkZS9zMS1pcHNlYy1ob3N0Mmhvc3QuaHRtbC4gVGh1cyB0aGUgYmFyIHRvIGltcGxl bWVudCBpcyBsb3cg4oCTIGp1c3QgcmVxdWlyZXMgc29tZSBhZGRpdGlvbmFsIGhvc3QgY29uZmln dXJhdGlvbi4gT2YgY291cnNlLCBpdCBtYXkgYmUgbW9yZSBkaWZmaWN1bHQgdG8gZGVwbG95IG9u IHJlbGF5cyAob24gcm91dGVycyk/DQoNCk9uZSByZWFzb24gdGhhdCBJIHRoaW5rIHRoYXQgdGhp cyBtYXkgbm90IGJlIHVzZWQgaGVhdmlseSAoaWYgYXQgYWxsKSBpcyB0aGF0IG1vc3Qgb2YgdGhl IHJlbGF5IHRvIHNlcnZlciBjb21taW5hdGlvbiBpcyBpbiBwcm9iYWJseSBmbG93aW5nIGluIGFu IG9wZXJhdG9y4oCZcyBpbmZyYXN0cnVjdHVyZSAoZGF0YSBjZW50ZXIpIG5ldHdvcmsgYW5kIGhl bmNlIHRoZXkgbGlrZWx5IGhhdmUgc2VjdXJlZCB0aGF0IGluZnJhc3RydWN0dXJlIGNvbW11bmlj YXRpb24gaW4gZ2VuZXJhbCBhbmQgdGh1cyB0aGUgcmVsYXkgdG8gcmVsYXkgLyByZWxheSB0byBz ZXJ2ZXIgY29tbXVuaWNhdGlvbiBtYXkgYmUgcGFydCBvZiB0aGF0IOKAkyB0aGlzIG1heSBiZSB0 aGUgc2FtZSBwYXRoIHVzZWQgdG8gbWFuYWdlIHRoZSByZWxheXMsIGZvciBleGFtcGxlLg0KDQoN Ci0gICAgICAgICAgQmVybmllDQoNCkZyb206IEVyaWMgUmVzY29ybGEgW21haWx0bzpla3JAcnRm bS5jb21dDQpTZW50OiBUaHVyc2RheSwgQXByaWwgMjAsIDIwMTcgNzoyNSBBTQ0KVG86IEJlcm5p ZSBWb2x6ICh2b2x6KSA8dm9sekBjaXNjby5jb20+DQpDYzogVGhlIElFU0cgPGllc2dAaWV0Zi5v cmc+OyBkaGMtY2hhaXJzQGlldGYub3JnOyBkcmFmdC1pZXRmLWRoYy1yZWxheS1zZXJ2ZXItc2Vj dXJpdHlAaWV0Zi5vcmc7IGRoY3dnQGlldGYub3JnDQpTdWJqZWN0OiBSZTogSUVTRyBEaXNjdXNz ZXMgb24gZHJhZnQtaWV0Zi1kaGMtcmVsYXktc2VydmVyLXNlY3VyaXR5LTA0DQoNCkhtbS4uLiBJ IGRvbid0IHRoaW5rIHRoaXMgcmVhbGx5IHJlc29sdmVzIG15IGNvbmNlcm4sIHdoaWNoIGlzOiBp cyBhbnlvbmUgZ29pbmcgdG8gYWN0dWFsbHkgZG8gdGhpcy4NCg0KSSBkb24ndCB0aGluayB0aGF0 IGhhcyB0byBiZSBpbiB0aGUgZHJhZnQsIGJ1dCBJJ2QgbGlrZSB1bmRlcnN0YW5kIGl0Lg0KDQot RWtyDQoNCg0KT24gV2VkLCBBcHIgMTksIDIwMTcgYXQgMzowMCBQTSwgQmVybmllIFZvbHogKHZv bHopIDx2b2x6QGNpc2NvLmNvbTxtYWlsdG86dm9sekBjaXNjby5jb20+PiB3cm90ZToNCkhpOg0K DQpJJ3ZlIHBvc3RlZCBhIC0wNSB3aGljaCB0cmllcyB0byBhZGRyZXNzIHRoZSBEaXNjdXNzZXMg KGV4Y2VwdCBwZXJoYXBzIGZvciBCZW4gQ2FtcGJlbGwncyBhYm91dCB3aGljaCBJIHNlbnQgYSBz ZXBhcmF0ZSBlbWFpbCBvbiA0LzEyKS4gUGxlYXNlIHJldmlldyBhbmQgbGV0IG1lIGtub3cgaWYg dGhpcyBoZWxwcyBvciB3aGV0aGVyIG1vcmUgY2hhbmdlcyBhcmUgbmVlZGVkLg0KDQpBIG5ldyB2 ZXJzaW9uIG9mIEktRCwgZHJhZnQtaWV0Zi1kaGMtcmVsYXktc2VydmVyLXNlY3VyaXR5LTA1LnR4 dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBCZXJuaWUgVm9seiBhbmQgcG9z dGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6ICAgICAgICAgICBkcmFmdC1pZXRm LWRoYy1yZWxheS1zZXJ2ZXItc2VjdXJpdHkNClJldmlzaW9uOiAgICAgICAwNQ0KVGl0bGU6ICAg ICAgICAgIFNlY3VyaXR5IG9mIE1lc3NhZ2VzIEV4Y2hhbmdlZCBCZXR3ZWVuIFNlcnZlcnMgYW5k IFJlbGF5IEFnZW50cw0KRG9jdW1lbnQgZGF0ZTogIDIwMTctMDQtMTkNCkdyb3VwOiAgICAgICAg ICBkaGMNClBhZ2VzOiAgICAgICAgICA4DQpVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtZGhjLXJlbGF5LXNlcnZlci1zZWN1cml0 eS0wNS50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1pZXRmLWRoYy1yZWxheS1zZXJ2ZXItc2VjdXJpdHkvDQpIdG1saXplZDogICAgICAg aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZGhjLXJlbGF5LXNlcnZlci1z ZWN1cml0eS0wNQ0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2h0bWwvZHJhZnQtaWV0Zi1kaGMtcmVsYXktc2VydmVyLXNlY3VyaXR5LTA1DQpEaWZmOiAg ICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtZGhj LXJlbGF5LXNlcnZlci1zZWN1cml0eS0wNQ0KDQotIEJlcm5pZSBWb2x6DQoNCg== --_000_b11b9d34fe4c4132b608e6b43e853252XCHALN003ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv TGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgN Cgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLmhvZW56Yg0KCXttc28tc3R5bGUtbmFtZTpob2VuemI7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAx MS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3Qg bDANCgl7bXNvLWxpc3QtaWQ6MTc2NzczMDE1NzsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCglt c28tbGlzdC10ZW1wbGF0ZS1pZHM6LTg4NjU1NDcwOCAxNzUwNDc1MjMwIDY3Njk4NjkxIDY3Njk4 NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4Njkz O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MDsNCgltc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6LTsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJl YXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDps ZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXci O30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7 bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5FcmljOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+SSBjYW7igJl0IHNheSB3aGV0aGVyIGFueW9uZSB3b3VsZCBhY3R1YWxseSBkbyB0 aGlzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+T24gdGhlIG9u ZSBoYW5kLCBOT1QgaGF2aW5nIHRoaXMgZG9jdW1lbnQgbWF5IG1ha2UgaXQgbGVzcyBsaWtlbHkg dGhhdCBhbnlvbmUgd291bGQsIHNvIGhhdmluZyB0aGUgZG9jdW1lbnQgQ09VTEQgbWVhbiBzb21l b25lIHdpbGwgbWFrZSB1c2Ugb2YgaXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5JIGFsc28gdGhpbmsgdGhhdCB0aGVyZSBtYXkgYmUgbGl0dGxlIHRvIGFkZCB0 byBhIHNlcnZlciBvciByZWxheSBpbXBsZW1lbnRhdGlvbiB0byBkbyB0aGlzIHNpbmNlIGl0IG1h eSBqdXN0IHJlcXVpcmUgc29tZSDigJxob3N04oCdIGNvbmZpZ3VyYXRpb24g4oCTIGFzIGluDQo8 YSBocmVmPSJodHRwczovL2FjY2Vzcy5yZWRoYXQuY29tL2RvY3VtZW50YXRpb24vZW4tVVMvUmVk X0hhdF9FbnRlcnByaXNlX0xpbnV4LzQvaHRtbC9TZWN1cml0eV9HdWlkZS9zMS1pcHNlYy1ob3N0 Mmhvc3QuaHRtbCI+DQpodHRwczovL2FjY2Vzcy5yZWRoYXQuY29tL2RvY3VtZW50YXRpb24vZW4t VVMvUmVkX0hhdF9FbnRlcnByaXNlX0xpbnV4LzQvaHRtbC9TZWN1cml0eV9HdWlkZS9zMS1pcHNl Yy1ob3N0Mmhvc3QuaHRtbDwvYT4uIFRodXMgdGhlIGJhciB0byBpbXBsZW1lbnQgaXMgbG93IOKA kyBqdXN0IHJlcXVpcmVzIHNvbWUgYWRkaXRpb25hbCBob3N0IGNvbmZpZ3VyYXRpb24uIE9mIGNv dXJzZSwgaXQgbWF5IGJlIG1vcmUgZGlmZmljdWx0IHRvIGRlcGxveSBvbiByZWxheXMNCiAob24g cm91dGVycyk/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5PbmUg cmVhc29uIHRoYXQgSSB0aGluayB0aGF0IHRoaXMgbWF5IG5vdCBiZSB1c2VkIGhlYXZpbHkgKGlm IGF0IGFsbCkgaXMgdGhhdCBtb3N0IG9mIHRoZSByZWxheSB0byBzZXJ2ZXIgY29tbWluYXRpb24g aXMgaW4gcHJvYmFibHkgZmxvd2luZyBpbiBhbiBvcGVyYXRvcuKAmXMNCiBpbmZyYXN0cnVjdHVy ZSAoZGF0YSBjZW50ZXIpIG5ldHdvcmsgYW5kIGhlbmNlIHRoZXkgbGlrZWx5IGhhdmUgc2VjdXJl ZCB0aGF0IGluZnJhc3RydWN0dXJlIGNvbW11bmljYXRpb24gaW4gZ2VuZXJhbCBhbmQgdGh1cyB0 aGUgcmVsYXkgdG8gcmVsYXkgLyByZWxheSB0byBzZXJ2ZXIgY29tbXVuaWNhdGlvbiBtYXkgYmUg cGFydCBvZiB0aGF0IOKAkyB0aGlzIG1heSBiZSB0aGUgc2FtZSBwYXRoIHVzZWQgdG8gbWFuYWdl IHRoZSByZWxheXMsIGZvcg0KIGV4YW1wbGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4 dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExp c3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0 Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPkJlcm5pZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBFcmljIFJlc2NvcmxhIFttYWlsdG86ZWtyQHJ0Zm0u Y29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBBcHJpbCAyMCwgMjAxNyA3OjI1IEFN PGJyPg0KPGI+VG86PC9iPiBCZXJuaWUgVm9seiAodm9seikgJmx0O3ZvbHpAY2lzY28uY29tJmd0 Ozxicj4NCjxiPkNjOjwvYj4gVGhlIElFU0cgJmx0O2llc2dAaWV0Zi5vcmcmZ3Q7OyBkaGMtY2hh aXJzQGlldGYub3JnOyBkcmFmdC1pZXRmLWRoYy1yZWxheS1zZXJ2ZXItc2VjdXJpdHlAaWV0Zi5v cmc7IGRoY3dnQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBJRVNHIERpc2N1c3Nl cyBvbiBkcmFmdC1pZXRmLWRoYy1yZWxheS1zZXJ2ZXItc2VjdXJpdHktMDQ8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IbW0uLi4gSSBkb24ndCB0aGluayB0aGlzIHJlYWxs eSByZXNvbHZlcyBteSBjb25jZXJuLCB3aGljaCBpczogaXMgYW55b25lIGdvaW5nIHRvIGFjdHVh bGx5IGRvIHRoaXMuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5JIGRvbid0IHRoaW5rIHRoYXQgaGFzIHRvIGJlIGluIHRoZSBkcmFmdCwgYnV0IEknZCBsaWtl IHVuZGVyc3RhbmQgaXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4tRWtyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIEFw ciAxOSwgMjAxNyBhdCAzOjAwIFBNLCBCZXJuaWUgVm9seiAodm9seikgJmx0OzxhIGhyZWY9Im1h aWx0bzp2b2x6QGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnZvbHpAY2lzY28uY29tPC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0 O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SGk6PGJyPg0KPGJyPg0KSSd2ZSBwb3N0ZWQgYSAtMDUgd2hpY2ggdHJpZXMgdG8gYWRkcmVz cyB0aGUgRGlzY3Vzc2VzIChleGNlcHQgcGVyaGFwcyBmb3IgQmVuIENhbXBiZWxsJ3MgYWJvdXQg d2hpY2ggSSBzZW50IGEgc2VwYXJhdGUgZW1haWwgb24gNC8xMikuIFBsZWFzZSByZXZpZXcgYW5k IGxldCBtZSBrbm93IGlmIHRoaXMgaGVscHMgb3Igd2hldGhlciBtb3JlIGNoYW5nZXMgYXJlIG5l ZWRlZC48YnI+DQo8YnI+DQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtaWV0Zi1kaGMtcmVs YXktc2VydmVyLXNlY3VyaXR5LTA1LnR4dDxicj4NCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJt aXR0ZWQgYnkgQmVybmllIFZvbHogYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Ljxi cj4NCjxicj4NCk5hbWU6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtk cmFmdC1pZXRmLWRoYy1yZWxheS1zZXJ2ZXItc2VjdXJpdHk8YnI+DQpSZXZpc2lvbjombmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDswNTxicj4NClRpdGxlOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgU2VjdXJpdHkgb2YgTWVzc2FnZXMgRXhjaGFuZ2VkIEJldHdlZW4gU2VydmVy cyBhbmQgUmVsYXkgQWdlbnRzPGJyPg0KRG9jdW1lbnQgZGF0ZTombmJzcDsgMjAxNy0wNC0xOTxi cj4NCkdyb3VwOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgZGhjPGJyPg0KUGFn ZXM6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA4PGJyPg0KVVJMOiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLWRoYy1yZWxheS1zZXJ2ZXItc2VjdXJp dHktMDUudHh0IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5l dC1kcmFmdHMvZHJhZnQtaWV0Zi1kaGMtcmVsYXktc2VydmVyLXNlY3VyaXR5LTA1LnR4dDwvYT48 YnI+DQpTdGF0dXM6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxhIGhyZWY9Imh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtZGhjLXJlbGF5LXNlcnZl ci1zZWN1cml0eS8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1pZXRmLWRoYy1yZWxheS1zZXJ2ZXItc2VjdXJpdHkvPC9hPjxicj4NCkh0bWxp emVkOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWRoYy1yZWxheS1zZXJ2ZXItc2VjdXJpdHktMDUiIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1kaGMtcmVs YXktc2VydmVyLXNlY3VyaXR5LTA1PC9hPjxicj4NCkh0bWxpemVkOiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwv ZHJhZnQtaWV0Zi1kaGMtcmVsYXktc2VydmVyLXNlY3VyaXR5LTA1IiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLWRoYy1yZWxh eS1zZXJ2ZXItc2VjdXJpdHktMDU8L2E+PGJyPg0KRGlmZjombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/ dXJsMj1kcmFmdC1pZXRmLWRoYy1yZWxheS1zZXJ2ZXItc2VjdXJpdHktMDUiIHRhcmdldD0iX2Js YW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1kaGMtcmVs YXktc2VydmVyLXNlY3VyaXR5LTA1PC9hPjxicj4NCjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4 Ij48YnI+DQo8c3BhbiBjbGFzcz0iaG9lbnpiIj4tIEJlcm5pZSBWb2x6PC9zcGFuPjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_b11b9d34fe4c4132b608e6b43e853252XCHALN003ciscocom_-- From nobody Thu Apr 20 07:10:04 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 5339B131476; Thu, 20 Apr 2017 07:10:02 -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 qGBg_lzay-46; Thu, 20 Apr 2017 07:10:00 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D371129571; Thu, 20 Apr 2017 07:09:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18264; q=dns/txt; s=iport; t=1492697399; x=1493906999; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=zHn2tGhCReO3wKyFYduik4m4hibPiuTXgDWkVrf5uJE=; b=Qfkqa//UnHxbZZG6fsv0I8K69g+jK1gtSK7/hZuS4enkJunrtIuE5JDV 7HWiC/+Y38q1L6Bc2awfd8rlFrWJVylA4E6OE5N/3BZXtTi3DKt520J/B bnhl1fa1MxhPFqaQOWMHso7/Vf71Q4z75Oi8RO+4tWA3jTg3vgUnC9jx+ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DNAACMwPhY/5JdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm5mYYELB411kWOVY4IPMIV0AoN8PxgBAgEBAQEBAQFrKIUVAQE?= =?us-ascii?q?BAQMtTBACAQgRAwEBASgHMhQJCAEBBAENBYocDq0Aix4BAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEYBYZTgV2DGYMAGIEREQEGNhaFLwWQBEGMbwGHFItuggCFM4hlgT2?= =?us-ascii?q?UEwEfOH0IYxUahw91AYZ/gSGBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.37,225,1488844800"; d="scan'208,217";a="235297905" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Apr 2017 14:09:57 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v3KE9v0K019390 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 20 Apr 2017 14:09:57 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 20 Apr 2017 09:09:57 -0500 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Thu, 20 Apr 2017 09:09:57 -0500 From: "Yogendra Pal (yogpal)" To: "Bernie Volz (volz)" , Eric Rescorla CC: The IESG , "dhc-chairs@ietf.org" , "draft-ietf-dhc-relay-server-security@ietf.org" , "dhcwg@ietf.org" Thread-Topic: IESG Discusses on draft-ietf-dhc-relay-server-security-04 Thread-Index: AdK5Pr76PLardk2ISZm7qPiNR7mu5gAs9mUAAAYfFvAACy2wgA== Date: Thu, 20 Apr 2017 14:09:57 +0000 Message-ID: References: <36c922c04bee4233b58e5185f0a4f9ad@XCH-ALN-003.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.65.40.21] Content-Type: multipart/alternative; boundary="_000_D51EBD862673Fyogpalciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [dhcwg] IESG Discusses on draft-ietf-dhc-relay-server-security-04 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, 20 Apr 2017 14:10:02 -0000 --_000_D51EBD862673Fyogpalciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FYI...Hi Bernie and Eric, We're planning to implement this in our firewall product (ASA). Regards, Yogendra From: "Bernie Volz (volz)" > Date: Thursday, 20 April 2017 7:09 pm To: Eric Rescorla > Cc: The IESG >, "dhc-chairs@ietf.org" = >, "draft-ietf-dhc-relay-server-security@ietf.org" >, "dhcwg@ietf.org" > Subject: RE: IESG Discusses on draft-ietf-dhc-relay-server-security-04 Resent-From: > Resent-To: >, Yogendra Pal > Resent-Date: Thursday, 20 April 2017 7:09 pm Eric: I can't say whether anyone would actually do this. On the one hand, NOT having this document may make it less likely that anyo= ne would, so having the document COULD mean someone will make use of it. I also think that there may be little to add to a server or relay implement= ation to do this since it may just require some "host" configuration - as i= n https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/4/= html/Security_Guide/s1-ipsec-host2host.html. Thus the bar to implement is l= ow - just requires some additional host configuration. Of course, it may be= more difficult to deploy on relays (on routers)? One reason that I think that this may not be used heavily (if at all) is th= at most of the relay to server commination is in probably flowing in an ope= rator's infrastructure (data center) network and hence they likely have sec= ured that infrastructure communication in general and thus the relay to rel= ay / relay to server communication may be part of that - this may be the sa= me path used to manage the relays, for example. - Bernie From: Eric Rescorla [mailto:ekr@rtfm.com] Sent: Thursday, April 20, 2017 7:25 AM To: Bernie Volz (volz) > Cc: The IESG >; dhc-chairs@ietf.org; draft-ietf-dhc-relay-server-security@ietf.org; dhcwg@ietf.org Subject: Re: IESG Discusses on draft-ietf-dhc-relay-server-security-04 Hmm... I don't think this really resolves my concern, which is: is anyone g= oing to actually do this. I don't think that has to be in the draft, but I'd like understand it. -Ekr On Wed, Apr 19, 2017 at 3:00 PM, Bernie Volz (volz) > wrote: Hi: I've posted a -05 which tries to address the Discusses (except perhaps for = Ben Campbell's about which I sent a separate email on 4/12). Please review = and let me know if this helps or whether more changes are needed. A new version of I-D, draft-ietf-dhc-relay-server-security-05.txt has been successfully submitted by Bernie Volz and posted to the IETF repos= itory. Name: draft-ietf-dhc-relay-server-security Revision: 05 Title: Security of Messages Exchanged Between Servers and Relay Ag= ents Document date: 2017-04-19 Group: dhc Pages: 8 URL: https://www.ietf.org/internet-drafts/draft-ietf-dhc-relay-s= erver-security-05.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-05 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-dhc-relay-= server-security-05 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-relay-se= rver-security-05 - Bernie Volz --_000_D51EBD862673Fyogpalciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <0BC6CA3336B4F2489876502DA05F3BC8@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
FYI…Hi Bernie and Eric,

We’re planning to implement this in our firewall product (ASA).<= /div>

Regards, Yogendra
From: "Bernie Volz (volz)"= ; <volz@cisco.com>
Date: Thursday, 20 April 2017 7:09 = pm
To: Eric Rescorla <ekr@rtfm.com>
Cc: The IESG <iesg@ietf.org>, "dhc-chairs@ietf.org" <dhc-chairs@ietf.org>, "draft-ietf-dhc-relay-server-security@ietf.or= g" <draft= -ietf-dhc-relay-server-security@ietf.org>, "dhcwg@ietf.org" <dhcwg@ietf.org>
Subject: RE: IESG Discusses on draf= t-ietf-dhc-relay-server-security-04
Resent-From: <alias-bounces@ietf.org>
Resent-To: <volz@cisco.com>, Yogendra Pal <yogpal@cisco.com>
Resent-Date: Thursday, 20 April 201= 7 7:09 pm

Eric:

 

I can’t say whether anyone wo= uld actually do this.

 

On the one hand, NOT having this do= cument may make it less likely that anyone would, so having the document CO= ULD mean someone will make use of it.

 

I also think that there may be litt= le to add to a server or relay implementation to do this since it may just = require some “host” configuration – as in https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/4/ht= ml/Security_Guide/s1-ipsec-host2host.html. Thus the bar to implement is= low – just requires some additional host configuration. Of course, i= t may be more difficult to deploy on relays (on routers)?

 

One reason that I think that this m= ay not be used heavily (if at all) is that most of the relay to server comm= ination is in probably flowing in an operator’s infrastructure (data center) network and hence they likel= y have secured that infrastructure communication in general and thus the re= lay to relay / relay to server communication may be part of that – th= is may be the same path used to manage the relays, for example.

 

-

 

I don't think that has to be in the draft, but I'd l= ike understand it.

 

-Ekr

 

 

On Wed, Apr 19, 2017 at 3:00 PM, Bernie Volz (volz) = <volz@cisco.com&= gt; wrote:

Hi:

I've posted a -05 which tries to address the Discusses (except perhaps for = Ben Campbell's about which I sent a separate email on 4/12). Please review = and let me know if this helps or whether more changes are needed.

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

Name:           draft-ietf-dhc-relay-server-s= ecurity
Revision:       05
Title:          Security of Messages Exchanged Bet= ween Servers and Relay Agents
Document date:  2017-04-19
Group:          dhc
Pages:          8
URL:            https://www.ietf.org/internet-drafts/draft-ietf-dhc-relay-server-security-0= 5.txt
Status:         https://= datatracker.ietf.org/doc/draft-ietf-dhc-relay-server-security/
Htmlized:       https://tools.ie= tf.org/html/draft-ietf-dhc-relay-server-security-05
Htmlized:       https:= //datatracker.ietf.org/doc/html/draft-ietf-dhc-relay-server-security-05=
Diff:           https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-relay-server-security-= 05

- Bernie Volz

 

--_000_D51EBD862673Fyogpalciscocom_-- From nobody Thu Apr 20 07:22:24 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 41DDA127241 for ; Thu, 20 Apr 2017 07:22:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 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] 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 1LITU2JpMPHA for ; Thu, 20 Apr 2017 07:22:19 -0700 (PDT) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (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 8A166127342 for ; Thu, 20 Apr 2017 07:22:19 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id m36so46204615qtb.0 for ; Thu, 20 Apr 2017 07:22:19 -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=V+Fq0eVa1rmp1Pu4aWTcOBDScqgo5d9ByFd83tSSbqs=; b=StZ40jnGyC74nfhQW9hF2ZcIcMIog2PeK5rKeH/TZVnVZXjlhi4Q+R68AYfSD/yCIg DQb2vQ2IfKh3s+b9kylau4kW3B7p/U9qy3zK5jIPa71fVDmHb0OucV/zoit/QwqB3cmS mKDQciPjkGrBXN1YVTb8hstbodXR9kzPFb2J9Mc45qpc08+m/swWF82EPlXM8GWlOTRX yIpeJ0D7NiWpaXL3SyXyWystCLz3A9Ps06XqpK4c4XzToy0qoAeneH+pBWLR6BGLnlWH P2IqhPa5DsadGX8bvGnhly46gR6NjXeKVrnv3LZfxwDv7euXtLdYNK+9gsWFqT0I/oRF ZG0A== 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=V+Fq0eVa1rmp1Pu4aWTcOBDScqgo5d9ByFd83tSSbqs=; b=tKwaQiKKfyBfRsqLTbvF0dguBixcKLB/J8EpF8eJc2cLdBmgjYZDPGi6X64PFUScj8 6DT0W0U0SHs/34QnOE4nzdvYSBCQIUPNsG/s0GZnhcho/J2MTjI3Mz0bJsdxVInfyfoz pfOi1uWSmZIdvvrA+koVsUsWQMkxbGw63EJ+iOxQxz1Gl/MajVfJSwk7UHuaEcNX8orb YGKkPr+AEZYonWA3blv0yG4KPVHqOzt6mzNuuEFViW4KRdUShF7gHai1QD7SlnLtIPIz jEl+B7NwfCK5N2nKeG4lH2XuB9EKfWhPp6ElK/yUMHC/IZM+577GUjSMoYpJMzk54+Wh NzMg== X-Gm-Message-State: AN3rC/4eSIhJyMIIi3PRoFM4a+vtUBdXXxLmoB1DwEtiwfHxgT/BPQx5 odF85/nBirUdIXEQ7HUj5Wr7gx1W3Q== X-Received: by 10.237.34.22 with SMTP id n22mr8009278qtc.164.1492698138651; Thu, 20 Apr 2017 07:22:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.58.71 with HTTP; Thu, 20 Apr 2017 07:22:18 -0700 (PDT) In-Reply-To: References: From: Lishan Li Date: Thu, 20 Apr 2017 22:22:18 +0800 Message-ID: To: Kathleen Moriarty Cc: "" , Michael Richardson , Paul Wouters Content-Type: multipart/alternative; boundary=001a113e49b84fb1d8054d99de1b Archived-At: Subject: Re: [dhcwg] light review of draft-ietf-dhc-sedhcpv6 and helpful suggestion 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, 20 Apr 2017 14:22:21 -0000 --001a113e49b84fb1d8054d99de1b Content-Type: text/plain; charset=UTF-8 Hi, Kathleen, Thanks a lot for your valuable comments on the draft. Please see inline. Best Regards, Lishan 2017-04-18 4:43 GMT+08:00 Kathleen Moriarty : > Dear authors, > > I just skimmed the draft triggered by another review and noticed the > deployment concerns in the WGLC summary sent to the list. think I can > help here with the remaining issues on making it easier to deploy. > > First, I'm really glad to see this work. Thanks for all of your > efforts on it! Second, I know this is late in the process, but I > think more text on opportunistic security for IPsec is worth > documenting to overcome implementation hurdles and address the coffee > shop use cases. I didn't see a reference to: > > https://tools.ietf.org/html/rfc7619 > > and am thinking the authors/WG might not be aware of this work. > Additionally, it should be noted that there are several Linux > implementations for IPsec with NULL authentication (OS). Paul > Woulters is a author on the mentioned RFC and did implement this with > IPsec for RedHat. > [LS]: In the before, we are just aware of the work of RFC7435 and not aware of RFC7619. For the reference of RFC7619, I have one question and want to get your guidance. RFC7619 proposes the NULL authentication method for IPsec. If we add the reference of RFC7619 for coffee shop scenario, then IPsec is used to protect the security of DHCPv6? Right? However, our document defines the secure DHCPv6 mechanism, not using the IPsec mechanism. If the IPsec mechanism is used, then the client and Relay, Relay and Relay, Relay and server need to establish the IPsec communication. And for our document, we just want to protect the information between the client and server, so secure DHCPv6 is suited. As opportunistic security for IPsec, our document proposes opportunistic security for DHCPv6. For the coffee shop, then the client and server can start the NULL authentication mode, which is easy to deployed. Could you please help check whether my understanding correct? Looking forward to your further comments. > > Michael Richardson is an author on the draft: > https://tools.ietf.org/html/draft-richardson-ipsec-opportunistic-17 > > documenting the OS IPsec implementation for the Linux FreeS/WAN project. > > I think it would be beneficial to see text that has OS as mandatory to > implement (MTI) and upgradeable to authenticated IPsec when practical. > Ideally, they would both be MTI, not mandatory to use (MTU) at least > for the authenticated since that is too hard. But MTI on > opportunistic would be a great next step that could be deployed. If > we were able to get DCHPv6 supporting this option in code with OS, > then people could turn it on. As you point out in the draft, > enterprise and other managed scenarios could use an option with > authentication if implemented. I think the MTI versus MTU could have > been more clear in this draft and the relay one that just went through > the IESG review. > > The current OS text leaves me, the reader, thinking it won't be > implemented as it's not pointing to a practical implementable RFC. I > am copying Michael and Paul (mentioned above) as one of them might be > willing to help with text. I think this will greatly assist with the > deployability of session encryption. [LS]: So, in our document, we need to states that: Opportunistic security is mandatory to implement, not just say that opportunistic security can be used for secure DHCPv6 deployment. Could you please help check whether my understanding correct? Thanks again, Lishan --001a113e49b84fb1d8054d99de1b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Kathleen,

Thanks a lot f= or your valuable comments on the draft. Please see inline.

Best Regards,
Lishan
2017-04-18 4:43 GMT+08:00 Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>:
Dear authors,

I just skimmed the draft=C2=A0 triggered by another review and noticed the<= br> deployment concerns in the WGLC summary sent to the list.=C2=A0 think I can=
help here with the remaining issues on making it easier to deploy.

First, I'm really glad to see this work.=C2=A0 Thanks for all of your efforts on it!=C2=A0 Second, I know this is late in the process, but I
think more text on opportunistic security for IPsec is worth
documenting to overcome implementation hurdles and address the coffee
shop use cases.=C2=A0 I didn't see a reference to:

https://tools.ietf.org/html/rfc7619

and am thinking the authors/WG might not be aware of this work.
Additionally, it should be noted that there are several Linux
implementations for IPsec with NULL authentication (OS).=C2=A0 Paul
Woulters is a author on the mentioned RFC and did implement this with
IPsec for RedHat.
[LS]: In the before, we are just awa= re of the work of RFC7435 and not aware
of RFC7619. For the refer= ence of RFC7619, I have one question and want to=C2=A0
get your g= uidance.=C2=A0
RFC7619 proposes the NULL authentication method fo= r IPsec. If we add the=C2=A0
reference of RFC7619 for coffee shop= scenario, then IPsec is used to protect=C2=A0
the security of DH= CPv6? Right?

However, our document defines the sec= ure DHCPv6 mechanism, not using=C2=A0
the IPsec mechanism. If the= IPsec mechanism is used, then the client and Relay,=C2=A0
Relay = and Relay, Relay and server need to establish the IPsec communication.
And for our document, we just want to protect the information between= the client=C2=A0
and server, so secure DHCPv6 is suited.=C2=A0

As opportunistic security for IPsec, our document p= roposes opportunistic security
for DHCPv6. For the coffee shop, t= hen the client and server can start the NULL
authentication mode,= which is easy to deployed.

Could you please help = check whether my understanding correct? Looking forward to=C2=A0
= your further comments.

Michael Richardson is an author on the draft:
https://tools.ietf.org/html/draft-richardson-ipsec-opportunistic-17

documenting the OS IPsec implementation for the Linux FreeS/WAN project.
I think it would be beneficial to see text that has OS as mandatory to
implement (MTI) and upgradeable to authenticated IPsec when practical.
Ideally, they would both be MTI, not mandatory to use (MTU) at least
for the authenticated since that is too hard.=C2=A0 But MTI on
opportunistic would be a great next step that could be deployed.=C2=A0 If we were able to get DCHPv6 supporting this option in code with OS,
then people could turn it on.=C2=A0 As you point out in the draft,
enterprise and other managed scenarios could use an option with
authentication if implemented.=C2=A0 I think the MTI versus MTU could have<= br> been more clear in this draft and the relay one that just went through
the IESG review.

The current OS text leaves me, the reader, thinking it won't be
implemented as it's not pointing to a practical implementable RFC.=C2= =A0 I
am copying Michael and Paul (mentioned above) as one of them might be
willing to help with text.=C2=A0 I think this will greatly assist with the<= br> deployability of session encryption.
[LS]: So, in our docu= ment, we need to states that: Opportunistic security=C2=A0
is man= datory to implement, not just say that opportunistic security can be=C2=A0<= /div>
used for secure DHCPv6 deployment. Could you please help check wh= ether=C2=A0
my understanding correct?

Thanks again,
Lishan=C2=A0

=
--001a113e49b84fb1d8054d99de1b-- From nobody Thu Apr 20 10:51:07 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 D7BAB129431; Thu, 20 Apr 2017 10:50:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Warren Kumari To: "The IESG" Cc: draft-ietf-dhc-relay-server-security@ietf.org, Tomek Mrugalski , dhc-chairs@ietf.org, tomasz.mrugalski@gmail.com, dhcwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149271065887.22294.4656740043867628182.idtracker@ietfa.amsl.com> Date: Thu, 20 Apr 2017 10:50:58 -0700 Archived-At: Subject: [dhcwg] Warren Kumari's No Objection on draft-ietf-dhc-relay-server-security-05: (with COMMENT) 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: Thu, 20 Apr 2017 17:50:59 -0000 Warren Kumari has entered the following ballot position for draft-ietf-dhc-relay-server-security-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dhc-relay-server-security/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- "This document specifies the optional requirements for relay agent and server implementations to support IPsec authentication and encryption and recommends operators enable this IPsec support." Thank you, this adequately addresses my discuss. From nobody Thu Apr 20 10:53:27 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 E51181294A6; Thu, 20 Apr 2017 10:53:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, 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 O5XKDUiTJ-VN; Thu, 20 Apr 2017 10:53:24 -0700 (PDT) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::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 8B256127F0E; Thu, 20 Apr 2017 10:53:24 -0700 (PDT) Received: by mail-qt0-x22d.google.com with SMTP id y33so51681420qta.2; Thu, 20 Apr 2017 10:53:24 -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:cc; bh=n2okZI+1s6E+paDmWbBwk68t//YckIhoMhhIWv3xv10=; b=IC1wqD8WgVb1srVEP3XtJoUR/h1dRMadSwHCdeNBj973X9Q7nenb7LVqlfhd2Mydgq FA1EEDJaLN9UTmpup6K0N5cx4BO6pd5huKA9eieNsFCUJj5v85pRi1UabKDHlgA1k92f lcsy5UXg3GMeAL1x2BbzW43PTPkbE9YPHmejwds3AtPmsuh6ng7Ru1iMu4tIPTAoUPIw DK7CKFRQVilGQEnoMEqFA5od5EaGCqw7yIKolsaaktLHMt7oQSsMUggQrXRUA4TYkGAT 3O0WM6IaXSi5U1kh1z2voNquqduDQm3bo347/Dp7ieTL5Cf5LMOyY7waKsb2lEkamoFS FI4w== 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:cc; bh=n2okZI+1s6E+paDmWbBwk68t//YckIhoMhhIWv3xv10=; b=f4HETQX6YQxg8C2oxXzGbkIPbWVGvTJwYIiz0LYNJJ/3b4/Y9ysK+quq/K6mJmdkBd vAxCl9vbnWZlPyMRC1ohA54KyqAAaZhNwyvLlneGQ6EKKcfa1zY9hJmJqiT5O5sp6x4O A/65TuKQ6HeHfUNpGQJVeOLyCO+1jh8govzdvFseVqap8IFEYQY2kEfkJ0hiDznwQfwH OP3Gfa+KUP3TkAqnFbWJUb0Ddbqp+/PX+z6tDbgRXbJPj07KMhAvxuIqaRtHVcuXIBXk T7xjCEspfjP0GEddljOX59sneKYsIawAonRSSkfRdCD5JsdyUpJ0gPvrKpEgY82BDoip wkvQ== X-Gm-Message-State: AN3rC/6eZ6Q7s4VqVYmKN94evmfiEhqQGCjZl7AprXB8rAQ43sTpR3pF aZv5hn8kFMnMIOhdd/Qc4aCUNwqggw== X-Received: by 10.200.36.212 with SMTP id t20mr10161697qtt.269.1492710803167; Thu, 20 Apr 2017 10:53:23 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.208 with HTTP; Thu, 20 Apr 2017 10:53:22 -0700 (PDT) From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Thu, 20 Apr 2017 10:53:22 -0700 X-Google-Sender-Auth: E3JdbT_qHYMun8Fa79vP40vGfMc Message-ID: To: Timothy Carlin Cc: dhcwg , draft-ietf-dhc-sedhcpv6 authors Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [dhcwg] sedhcpv6 data size issue (Re: 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, 20 Apr 2017 17:53:26 -0000 At Wed, 5 Apr 2017 13:13:38 -0400, Timothy Carlin wrote: > I'm also wondering about using RSA for encryption, as the data size (and > thus message size) is limited to the key size that the client or server > provides. This could cause problems with large DHCP messages. Could a > symmetric key algorithm (e.g. AES) be used? The keys for this would have > to be negotiated during the initial Information-request/Reply. I agree the data size limitation of RSA can be critical. At least data for the very initial Encrypted-Query message is quite unlikely to be encrypted at once, since the data contains a certificate option (which contains the client's public key). Assuming a 2048-bit key, we can only encrypt 256 - (overhead for padding etc) octets of data at once. I'm afraid this is too limited even for subsequent messages that don't contain the certificate option. One straightforward workaround is to divide the data and encrypt each chunk separately, but this may not be acceptable due to the cost, especially for the server. (Even if we adopt this approach I guess the current draft text is too unclear about it and should be revised to describe specifically how to do it). I suspect using symmetric session keys can't be an (easy) option, either. At least I don't think we can do this negotiation in the initial Information-Request/Reply exchange, since to do so the client would have to include its certificate in the Information-Request message but we intentionally avoid that due to a privacy concern. In any case, I'm afraid this issue will require some substantial changes to the specification. Right now I don't have a clear idea about what's the best. -- JINMEI, Tatuya From nobody Fri Apr 21 01:26: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 7689B1288B8; Fri, 21 Apr 2017 01:26:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 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] 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 8IRN4U42FqI6; Fri, 21 Apr 2017 01:26:46 -0700 (PDT) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (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 A9F2E129440; Fri, 21 Apr 2017 01:26:17 -0700 (PDT) Received: by mail-qt0-x232.google.com with SMTP id y33so64445375qta.2; Fri, 21 Apr 2017 01:26:17 -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=QWKIHdudejqgyxkcdtojXY3x8kuf/dRZ1QFwvEtPz3Q=; b=E5rsgV+x62zFDVR7bEDUZECIK7n7PRiV0Edq1xTCL4vf4EjTLlch/I0UWnSau0NWlm tvy+wCdK2VSenILDzuQ5wFdnmB83jNMdDaPS0UdmTLQBiqIRNbYzQ1HRhzTvjElmLuVb V7zeUw7wh1iYQMqMsId9E+cVPQtX7BtkRRdnQ/wRUZIOJ0leRZ3EzVEoadgxJrAaLuI8 nsBCvoyxk1/dma5JiHbWIQCBFJTHTCaEWScTcpM1d/BPZF6WRrdQtvrMmKN6yq/+WFqm 6J7s2sRXoSddVqhUoT4RwgdX8lfQpNQYqBZtdmN4IvVaRCqO3JAnXOWbyb2aSbgmMst+ KVjQ== 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=QWKIHdudejqgyxkcdtojXY3x8kuf/dRZ1QFwvEtPz3Q=; b=h0eMotX0YoV/jJowHLcWBMOeh/2xxFu8j9geZv4oBKztBCt/ibfqKEqpL3yKoicDdY +j6Ls3+xTHpO5X1GMhQYkEPvbLTaCl7smYysys/wtr5bbKlkZlH77uQwm4MWVhsbl4Ov bkikawJG/wbAwxVr7jo70vuHgtwvZAymxTAqykWwVqfCZUp+TbUzTFJk8kPsN7lJpxHQ JMmULolPJckAdO4xclqopglnSaHtYor9wf5DhqogWS85yq8n3WlTVokzAK/akxREYTta fPkyG+A1OIOssY+mV3QsWp59+1BQv3+u0wbmDfKGyZe9HWgCJeM6NZ+tNvUo2RzERSoK UPUw== X-Gm-Message-State: AN3rC/7uUgig+7mdcISZYvLYLHaY6+l31jbWxsacA9wFx8t/BDJi0Ic/ x7ORDZ1KlOYfvtKujUy6sn1Ihu7G/w== X-Received: by 10.237.34.22 with SMTP id n22mr11699171qtc.164.1492763176824; Fri, 21 Apr 2017 01:26:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.58.71 with HTTP; Fri, 21 Apr 2017 01:26:16 -0700 (PDT) In-Reply-To: References: From: Lishan Li Date: Fri, 21 Apr 2017 16:26:16 +0800 Message-ID: To: Tomek Mrugalski Cc: "Templin, Fred L" , dhcwg , draft-ietf-dhc-sedhcpv6 authors Content-Type: multipart/alternative; boundary=001a113e49b8e37764054da9020b 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, 21 Apr 2017 08:26:49 -0000 --001a113e49b8e37764054da9020b Content-Type: text/plain; charset=UTF-8 Hi, Tomek, Thanks a lot for the valuable comments. Sorry for the late reply. For some general issue, I will start a new session for discussion. For the other easy issues, please see inline. Best Regards, Lishan 2017-03-31 2:00 GMT+08:00 Tomek Mrugalski : > 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. > [Lishan]: Ted rewrite the text of Section 5.1 and 5.2. So it is clear and easy to read. > > 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). > [LS]: The increasing-number option is first sent by the Reply message. And the client checks it. If the client does not store it, then we assume that the initial value is zero, then the check will success. > > 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. > [LS]: Will clarify it. > > 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. > [LS]: Agree. > > "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? > [LS]: Increasing-number is optional. change "can" to "SHOULD". > > "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? > [LS]: The client will not check the transaction-id. For all the transaction-id, the client will try to decrypt it. > > "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." > [LS]: Agree. > > "The encryption text SHOULD...". What is encryption text? Did you mean > encrypted message or the message to be encrypted? > [LS]: I mean the encrypted text. Will explain it more clear. > > 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. > [LS]: I also don't know much about it. For the general security issues, will consult Randy Bush or Stephen Farrall for their guidance. > > 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? > [LS]: I think it is a general secure issue. And we can consult some security expert. > > "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. > [LS]: In these scenarios, decryption fails. In this way, the server cannot recognize which client. And it is difficult for the server to send the AuthenticationFail status code. > > "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."). > > [LS]: Bernie has given the same comments. Will modify it. > 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). > [LS]: After the IETF meeting, we will add the reference of it. > > 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. > [LS]: Will have a pointer to 5.4 > > 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. > [LS]: Agree. > > 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. > [LS]: Will discuss it in another session. > > 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. > > > Thanks again, Lishan --001a113e49b8e37764054da9020b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Tomek,

Thanks a lot for the valuabl= e comments. Sorry for the late reply. For some general issue, I will start = a new session for discussion. For the other easy issues, please see inline.=

Best Regards,
Lishan

2017-03-31 2:00 GMT+08:00= Tomek Mrugalski <tomasz.mrugalski@gmail.com>:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">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 (=3D=3D), 5 comments (--).. Please fix them. Ping<= br> 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.=C2=A0<= /blockquote>

I like section 5, especially 5.1 and 5.2 a lot. It's a great two-page intro to the concept.
[Lishan]: Ted rewrite the text o= f Section 5.1 and 5.2. So it is clear=C2=A0
and easy to read.=C2= =A0

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<= br> it against), but some checks are definitely applicable (e.g. drop
because signature is missing, multiple signatures or certificate missing).<= br>
[LS]: The increasing-number option is first sent by th= e Reply message.=C2=A0
And the client checks it. If the client do= es not store it, then we assume=C2=A0
that the initial value is z= ero, then the check will success.=C2=A0

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" =3D> "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 MU= ST send
Certificate option". It's also not shown on Figure 1. Yet, the ser= ver
section says that incoming messages without Certificate option are to be dropped. This should be clarified.
[LS]: Will clarify = it.=C2=A0

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.
[LS]: Agree.=C2=A0
=

"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?
=
[LS]: Increasing-number is optional. change "can&quo= t; to "SHOULD".=C2=A0

"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?
[LS]: The client will not= check the transaction-id. For all the transaction-id,=C2=A0
the = client will try to decrypt it. =C2=A0

"In this document, it is assumed that the client will not have multipl= e
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 ca= n
maintain multiple DHCPv6 sessions, but such scenario is not considered
here for clarity reasons."
[LS]: Agree.=C2=A0

"The encryption text SHOULD...". What is encryption text? Did you= mean
encrypted message or the message to be encrypted?
[LS]= : I mean the encrypted text. Will explain it more clear.=C2=A0

nit: "as explain in [RFC5652]" =3D> "as explained in [RFC= 5652]"

"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.
[LS]: I also don't know much abou= t it. For the general security issues,=C2=A0
will consult Randy B= ush or Stephen Farrall for their guidance. =C2=A0

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 descrip= tion
of the concept was accurate enough. Any other thoughts on this?
[LS]: I think it is a general secure issue. And we can consult so= me security=C2=A0
expert.=C2=A0

"switch to other DHCPv6 server if it has another one." =3D> &q= uot;switch to
other DHCPv6 server if available."

The text uses "one and only one" several times. You may consider<= br> 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 payi= ng
cost to decrypt messages."
=3D> "The DHCPv6 server drops the message if the value of Se= rver
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 ta= g
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.
[LS]: In these scenarios, decryption fails. In this way, the server canno= t=C2=A0
recognize which client. And it is difficult for the serve= r to send the AuthenticationFail
status code.=C2=A0

"For the signature failure, the server SHOULD send an encrypted Reply<= br> 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 bette= r
to say the server must be able to retain the increasing number across
restarts.

Remove "And " at the beginning of two sentences in first paragrap= h.

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: Con= tains 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 f= or
SHA-id List ("Contains a list of supported Signature/Hash Algorithm pairs.").

[LS]: Bernie has given the same comments. Will modify= it.=C2=A0
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.<= br>
10.1.2
"The Certificate option carries the certificate of th= e 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 mess= age
with a certificate". It would be better to say "The Certificate o= ption
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 earli= er
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:" =3D> "share the standard fo= rmat of DHCPv6
messages:".

Section 11
"There are some mandatory algorithm for encryption algorithm in this document.=C2=A0 It may be at some point that the mandatory algorithm= is no
longer safe to use." =3D> "There are some mandatory algorithms= specified
in this document.=C2=A0 It may be at some point that the mandatory algorith= m
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).
[LS]: A= fter the IETF meeting, we will add the reference of it.

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<= br> (or have a pointer to 5.4) if you decide to create deployment
considerations section.
[LS]: Will have a pointer to 5= .4=C2=A0

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.
[LS]: Agree.=C2=A0

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.
[LS]: Will discuss it in another session.=C2=A0

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.


Thanks again,
Lishan=C2=A0


<= /div>
--001a113e49b8e37764054da9020b-- From nobody Fri Apr 21 01:45:14 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 4C1241294F4 for ; Fri, 21 Apr 2017 01:45:13 -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 JO12KfISdhev for ; Fri, 21 Apr 2017 01:45:11 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (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 A3D7512948E for ; Fri, 21 Apr 2017 01:45:11 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id d80so1911769qke.3 for ; Fri, 21 Apr 2017 01:45:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=JgkuBfaEVnRyJAglDZMAj3LInJpZMg08QcdJvgCL56Q=; b=aUa65ThgXJoUjrXjsW4W7tqRKvko66KhrOo8AXJdGPDbehzx6IzrMeCHORFCf8sbm+ KlWOewJDod9fAE4+SojcKUoQ7EcDYLOXJyR0fUK5aJ81E3HzZjYvKl7EHKYSGgeY+Rjj ZrxqwEqKX4NwyasACFVFZ8FDYnPolXOp/eYsQV45njP/sRqhWh1nV6SIKOdjce+Lxknp qlYLmUewE6kcIJYxFOHEP+oE74ou6aB6YQV/1t5UUzx1o5EEO5Ib1YfyTb1wehEMNBFL YJO+7ApRvtzURuX5x2q9xrSGI5ffrSWrmOunJKNvTOV68HoYqerC4nruhjz48HmOYuxD NTkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=JgkuBfaEVnRyJAglDZMAj3LInJpZMg08QcdJvgCL56Q=; b=n61aG7Jj1Z1e47cdKJxtyBJkenygTT+9hASe3n3csauvn14MTmyZ+6wqOMWgeHN9mN W1pcPLzQ6S+cFbnkTeT03DvMuxZYgGqy4r0tqudtuZmz0pNs0uBQDXhO39eQz+LwicuP HmHQYYOVe4cupaAIJOnQaVFLJDUsS85nzN2Dac+8Av3DLb251mq215/K1gGVaK7i5Qe8 3/1sXD3b1uqRQWvJp9jhabiGtvtSAdpfpRuW2zp4HB4EczFtgi87DscyBEXpdXw4qczD zjc7ve4EyTn4WG8qNC19VliTF3lG7GO/eHzWMr2vIWMhZmyaM2gsheJGrl5ZjR4XGwSq hadQ== X-Gm-Message-State: AN3rC/65Fm2i/shQ3l2D0lLAfyiwHM+qOh9dS67Cr2w2XzWTbUX/T0F5 O/9576ksx5qUA1UiTJDvBPDrOcztCg== X-Received: by 10.55.155.7 with SMTP id d7mr12650217qke.320.1492764310699; Fri, 21 Apr 2017 01:45:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.58.71 with HTTP; Fri, 21 Apr 2017 01:45:10 -0700 (PDT) From: Lishan Li Date: Fri, 21 Apr 2017 16:45:10 +0800 Message-ID: To: dhcwg Content-Type: multipart/alternative; boundary=94eb2c06016a790898054da94632 Archived-At: Subject: [dhcwg] Remaining Issue for Secure DHCPv6 WGLC 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, 21 Apr 2017 08:45:13 -0000 --94eb2c06016a790898054da94632 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear All, Thanks a lot for all the valuable comments on secure DHCPv6 WGLC. As the DHC chairs, Bernie and Tomek gave us many support and valuable comments. It is my honor to work with them. Thanks to the DHC chairs. For the proposed comments, there are still some remaining issues for discussion in the following. 1. Bernie: 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? [LS]: According to Ted's comments, Clients that don't have the current time don't get very good security. I think that we can add it into the security consideration part. 2. Jinmei: 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. [LS]: Tomek has the same comment on the Reconfigure message. As Jinmei suggested: If the encrypted DHCPv6 message is Reconfigure message, then the transaction-id of the Encrypted-Response message is regenerated. 3. Tomek: 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. [LS]: Kathleen Moriarty also proposes this problem. She suggested us to have opportunistic security as mandatory to implement. Otherwise, the reader will think that it's not pointing to a practical implementable RFC. Maybe another way is Tomek's suggestion, changing the name of the draft. In this way, there will be less issues. 4. Tomek: I mentioned that I was concerned with the possibility of clients and servers getting =E2=80=9Cjunk=E2=80=9D is a security concern as someone could gener= ate 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]: According to Sten Carlsen's comments, there is no other method than careful programming and careful testing with deliberate intent to find weak spots. I think that it is a general problem for encryption, not the specific problem for secure DHCPv6. 5. Tomek: "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= . [LS]: I also think that it is a general security problem. Looking forward to the guidance from some security experts. 6. Bernie: Regarding the reference of RFC5652, check in with Stephen to get more clarity on what pieces are applicable? [LS]: Looking forward to the guidance from some security experts. Looking forward to all the comments and guidance. Thanks in advance. Best Regards, Lishan --94eb2c06016a790898054da94632 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear All,=C2=A0

Thanks a lot= for all the valuable comments on secure DHCPv6 WGLC. As the=C2=A0
DHC chairs, Bernie and Tomek gave us many support and valuable comments.= =C2=A0
It is my honor to work with them. Thanks to the DHC chairs= .

For the proposed comments, there are still some = remaining issues for discussion
in the following.

<= /div>
1. Bernie: What about verifying the certificate's time? A cli= ent might not have current
time and so may not be able to determi= ne if certificate has expired?=C2=A0

[LS]: Accordi= ng to Ted's comments, Clients that don't have the current time don&= #39;t get=C2=A0
very good security. I think that we can add it in= to the security consideration part.

2. Jinmei: rel= ated to the previous point, I think it's better to prohibit the=C2=A0
transaction ID of 0 for Encryption-query messages (the client must= re-generate=C2=A0
the ID when its implementation generates 0).= =C2=A0 Otherwise it's possible for the
client to see a 0 tran= saction ID in Encryption-response messages for
normal cases other= than Reconfigure.

[LS]: Tomek has the same commen= t on the Reconfigure message. As Jinmei=C2=A0
suggested: If the e= ncrypted DHCPv6 message is Reconfigure message, then=C2=A0
the tr= ansaction-id of the Encrypted-Response message is regenerated.=C2=A0
<= div>
3. Tomek: This draft defines a set of recommendations fo= r secure environment.=C2=A0
It is not expected to be used by all = DHCP implementations is every deployment,=C2=A0
just those who ar= e interested in improved security. In certain way it is very similar=C2=A0<= /div>
to anonymity profile. Anonymity profile defined set or rules that= are not expected=C2=A0
to be used by all DHCP implementations in= every deployment, just those who are=C2=A0
interested in improve= d privacy. So maybe it should be called Security Profile for=C2=A0
DHCPv6? I think this approach does not change anything from technical per= spective,=C2=A0
but simply frames the solution better. Described = that way it may also be easier to=C2=A0
accept to people who may = afraid we want to force everyone to encrypt everything=C2=A0
ever= ywhere. It's just a suggestion to consider, I don't insist on it if= authors or the WG=C2=A0
disagree.

[LS]:= Kathleen Moriarty also proposes this problem. She suggested us to=C2=A0
have opportunistic security as mandatory to implement. Otherwise, t= he reader=C2=A0
will think that it's not pointing to a practi= cal implementable RFC.
Maybe another way is Tomek's suggestio= n, changing the name of the draft.=C2=A0
In this way, there will = be less issues.

4. Tomek: I mentioned that I was c= oncerned with the possibility of clients and servers=C2=A0
gettin= g =E2=80=9Cjunk=E2=80=9D is a security concern as someone could generate ba= d packets with=C2=A0
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=C2=A0
thi= nk about whether to add some magic value to the first few bytes of a messag= e=C2=A0
before encrypting it and then the decrypter can check tho= se first few bytes to see if=C2=A0
they are value and discard the= message if not. Perhaps the encoding from RFC5652=C2=A0
would ac= complish this if we are using more than just the encryptedContent? Anyway,= =C2=A0
something to think about.

[LS]: A= ccording to Sten Carlsen's comments, there is no other method than care= ful=C2=A0
programming and careful testing with deliberate intent = to find weak spots.
I think that it is a general problem for encr= yption, not the specific problem for=C2=A0
secure DHCPv6.=C2=A0

5. Tomek: "After the decryption, it handles th= e message as per 3315". I'm not a
security expert by any= stretch of that word, so excuse my naive question. Anyway,=C2=A0
can you always detect that the decryption was a success or failure? Some d= ecryption=C2=A0
techniques will produce output, even when the key= is incorrect, but the output will be=C2=A0
an almost random garb= age. Can the mechanism defined in RFC5652 always reliably=C2=A0
c= onclude the decoding operation was success/failure? If not, I'm afraid = that asking=C2=A0
clients and server to decode random garbage wil= l break some implementations.

[LS]: I also think t= hat it is a general security problem. Looking forward to the guidance=C2=A0=
from some security experts.

6. Bernie: = Regarding the reference of RFC5652, check in with Stephen to=C2=A0
get more clarity on what pieces are applicable?

= [LS]: Looking forward to the guidance from some security experts.

Looking forward to all the comments and guidance. Thanks in= advance.

Best Regards,
Lishan


--94eb2c06016a790898054da94632-- From nobody Fri Apr 21 09: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 7F05F129A92; Fri, 21 Apr 2017 09:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 yxzBf8dE6icy; Fri, 21 Apr 2017 09:45:29 -0700 (PDT) Received: from mail-qt0-x242.google.com (mail-qt0-x242.google.com [IPv6:2607:f8b0:400d:c0d::242]) (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 A3EB0129572; Fri, 21 Apr 2017 09:45:29 -0700 (PDT) Received: by mail-qt0-x242.google.com with SMTP id t52so12590968qtb.3; Fri, 21 Apr 2017 09:45:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jk+jnAZ+zOLbdSXiSV2HFz204QybZtLBUCYIBrqdBB4=; b=lskanG2w15kcOk9UWi27FsJRkwOb+TOgapsl4rcBV0Lv+VDlbFU9TIYCx4iME0TFlU JU2DXtsl+6gkL6TaSRVwdjMwpekvp331IIwfU/ABTZIm8V2GlU5EJe+F4zlrXT9n/Q3K yeMKNO2x0TefPoBN1YytsFbIIafnUHrmQP40jnwVot5qggycBdPj0GzYWXJRHKz03vvj 2hxUkC/zvtq2rZZmiQowL9q2AJAqPhwNvftf5ZRIvLScQmG5gVJqbNCc1PyOOjWF43+R WIIxoPWhOB0zg9PpK3wmER9iIiJ9k1yFydZB9e+Rm236GMnKp6hxkpmjfpuoYeVmzJ1d ucvA== 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=jk+jnAZ+zOLbdSXiSV2HFz204QybZtLBUCYIBrqdBB4=; b=h9bXSrqViyxMIcwAQbTuw7K1BzSZQtlPbaBmM/X6R+0EE7MML0tpH6PISAaYl+HIEj GbDjkWhS8WsaOXWHGcfmBYuU8HWQnoZSM5npNEUJpkdJqP4EQqn8i0kmLOAmviKk3aCn 6/vN4jiT3t4gk8csyMngoNT6gjKQmaUSVMJEleqTOWBNUM97KJiOMVpyK9xeCo/lCdYG ctQxvB46l80zOZq6Akdj7r8flEkY4UqiNoHleKe47f8NB8DL5m5zlP7QTC0XIatvG7G3 VpxxYS+nIV1j60I3+K6l2xAqGvpo+nBbBoSIe8M/NJ+EpmpV6IVfsMXYHcyeR4KibH74 zBUQ== X-Gm-Message-State: AN3rC/78esPT99hE0au6++dtOoZ6b69OJ55wA0ggEM2pr9Ar7NIkrsPq ARGnpPNcWMv3ig== X-Received: by 10.200.48.14 with SMTP id f14mr14418517qte.201.1492793128348; Fri, 21 Apr 2017 09:45:28 -0700 (PDT) Received: from [10.0.1.10] (ool-457c4d63.dyn.optonline.net. [69.124.77.99]) by smtp.gmail.com with ESMTPSA id p19sm6664791qtp.36.2017.04.21.09.45.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Apr 2017 09:45:27 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-A9F14B0A-7EE5-40B1-B7E8-FC23CB89EB41 Mime-Version: 1.0 (1.0) From: Kathleen Moriarty X-Mailer: iPhone Mail (14D27) In-Reply-To: Date: Fri, 21 Apr 2017 12:45:26 -0400 Cc: "Bernie Volz (volz)" , Eric Rescorla , "dhc-chairs@ietf.org" , The IESG , "draft-ietf-dhc-relay-server-security@ietf.org" , "dhcwg@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: <09030C6C-90BD-4246-965C-CC3239DCABE9@gmail.com> References: <36c922c04bee4233b58e5185f0a4f9ad@XCH-ALN-003.cisco.com> To: "Yogendra Pal (yogpal)" Archived-At: Subject: Re: [dhcwg] IESG Discusses on draft-ietf-dhc-relay-server-security-04 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, 21 Apr 2017 16:45:33 -0000 --Apple-Mail-A9F14B0A-7EE5-40B1-B7E8-FC23CB89EB41 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sent from my iPhone > On Apr 20, 2017, at 10:09 AM, Yogendra Pal (yogpal) wro= te: >=20 > FYI=E2=80=A6Hi Bernie and Eric, >=20 > We=E2=80=99re planning to implement this in our firewall product (ASA). Excellent, glad to hear it! Kathleen=20 >=20 > Regards, Yogendra > From: "Bernie Volz (volz)" > Date: Thursday, 20 April 2017 7:09 pm > To: Eric Rescorla > Cc: The IESG , "dhc-chairs@ietf.org" ,= "draft-ietf-dhc-relay-server-security@ietf.org" , "dhcwg@ietf.org" > Subject: RE: IESG Discusses on draft-ietf-dhc-relay-server-security-04 > Resent-From: > Resent-To: , Yogendra Pal > Resent-Date: Thursday, 20 April 2017 7:09 pm >=20 > Eric: > =20 > I can=E2=80=99t say whether anyone would actually do this. > =20 > On the one hand, NOT having this document may make it less likely that any= one would, so having the document COULD mean someone will make use of it. > =20 > I also think that there may be little to add to a server or relay implemen= tation to do this since it may just require some =E2=80=9Chost=E2=80=9D conf= iguration =E2=80=93 as in https://access.redhat.com/documentation/en-US/Red_= Hat_Enterprise_Linux/4/html/Security_Guide/s1-ipsec-host2host.html. Thus the= bar to implement is low =E2=80=93 just requires some additional host config= uration. Of course, it may be more difficult to deploy on relays (on routers= )? > =20 > One reason that I think that this may not be used heavily (if at all) is t= hat most of the relay to server commination is in probably flowing in an ope= rator=E2=80=99s infrastructure (data center) network and hence they likely h= ave secured that infrastructure communication in general and thus the relay t= o relay / relay to server communication may be part of that =E2=80=93 this m= ay be the same path used to manage the relays, for example. > =20 > - Bernie > =20 > From: Eric Rescorla [mailto:ekr@rtfm.com]=20 > Sent: Thursday, April 20, 2017 7:25 AM > To: Bernie Volz (volz) > Cc: The IESG ; dhc-chairs@ietf.org; draft-ietf-dhc-relay-se= rver-security@ietf.org; dhcwg@ietf.org > Subject: Re: IESG Discusses on draft-ietf-dhc-relay-server-security-04 > =20 > Hmm... I don't think this really resolves my concern, which is: is anyone g= oing to actually do this. > =20 > I don't think that has to be in the draft, but I'd like understand it. > =20 > -Ekr > =20 > =20 > On Wed, Apr 19, 2017 at 3:00 PM, Bernie Volz (volz) wrote= : > Hi: >=20 > I've posted a -05 which tries to address the Discusses (except perhaps for= Ben Campbell's about which I sent a separate email on 4/12). Please review a= nd let me know if this helps or whether more changes are needed. >=20 > A new version of I-D, draft-ietf-dhc-relay-server-security-05.txt > has been successfully submitted by Bernie Volz and posted to the IETF repo= sitory. >=20 > Name: draft-ietf-dhc-relay-server-security > Revision: 05 > Title: Security of Messages Exchanged Between Servers and Relay A= gents > Document date: 2017-04-19 > Group: dhc > Pages: 8 > URL: https://www.ietf.org/internet-drafts/draft-ietf-dhc-relay-= server-security-05.txt > Status: https://datatracker.ietf.org/doc/draft-ietf-dhc-relay-serv= er-security/ > Htmlized: https://tools.ietf.org/html/draft-ietf-dhc-relay-server-se= curity-05 > Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-dhc-relay= -server-security-05 > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-relay-s= erver-security-05 >=20 > - Bernie Volz > =20 --Apple-Mail-A9F14B0A-7EE5-40B1-B7E8-FC23CB89EB41 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


Sent from my iPhone
=
On Apr 20, 2017, at 10:09 AM, Yogendra Pal (yogpal) <yogpal@cisco.com> wrote:

FYI=E2=80=A6Hi Bernie and Eric,

We=E2=80=99re planning to implement this in our firewall product (ASA).=

Excellent, glad to hear it!

=
Kathleen 

Regards, Yogendra
From: "Bernie Volz (volz)" <volz@cisco.com>
Date: Thursday, 20 April 2017 7:09 p= m
To: Eric Rescorla <ekr@rtfm.com>
Cc: The IESG <iesg@ietf.org>, "dhc-chairs@ietf.org" <dhc-cha= irs@ietf.org>, "draft-ietf-dhc-relay-server-security@ietf.org" <draft-= ietf-dhc-relay-server-security@ietf.org>, "dhcwg@ietf.org" <dhcwg@ietf= .org>
Subject: RE: IESG Discusses on draft= -ietf-dhc-relay-server-security-04
Resent-From: <alias-bounces@ietf.org>
Resent-To: <volz@cisco.com>, Yogendra Pal <yogpal@cisco.com>
Resent-Date: Thursday, 20 April 2017= 7:09 pm

Eric:

 

I can=E2=80=99t say whether anyone wo= uld actually do this.

 

On the one hand, NOT having this docu= ment may make it less likely that anyone would, so having the document COULD= mean someone will make use of it.

 

I also think that there may be little= to add to a server or relay implementation to do this since it may just req= uire some =E2=80=9Chost=E2=80=9D configuration =E2=80=93 as in https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/4/htm= l/Security_Guide/s1-ipsec-host2host.html. Thus the bar to implement is l= ow =E2=80=93 just requires some additional host configuration. Of course, it= may be more difficult to deploy on relays (on routers)?

 

One reason that I think that this may= not be used heavily (if at all) is that most of the relay to server commina= tion is in probably flowing in an operator=E2=80=99s infrastructure (data center) network and hence they like= ly have secured that infrastructure communication in general and thus the re= lay to relay / relay to server communication may be part of that =E2=80=93 t= his may be the same path used to manage the relays, for example.

 

-&= nbsp;         Bernie<= /p>

 

From: Eric Rescorla [mail= to:ekr@rtfm.com]
Sent: Thursday, April 20, 2017 7:25 AM
To: Bernie Volz (volz) <volz@cis= co.com>
Cc: The IESG <iesg@ietf.org&g= t;; dhc-chairs@ietf.org; draft-ietf-dhc-relay-server-security@ietf.org; dhcwg@ietf.org
Subject: Re: IESG Discusses on draft-ietf-dhc-relay-server-security-0= 4

 

Hmm... I don't think this really resolves my concern,= which is: is anyone going to actually do this.

 

I don't think that has to be in the draft, but I'd li= ke understand it.

 

-Ekr

 

 

On Wed, Apr 19, 2017 at 3:00 PM, Bernie Volz (volz) &= lt;volz@cisco.com>= ; wrote:

Hi:

I've posted a -05 which tries to address the Discusses (except perhaps for B= en Campbell's about which I sent a separate email on 4/12). Please review an= d let me know if this helps or whether more changes are needed.

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

Name:           draft-ietf-dhc-relay-server-se= curity
Revision:       05
Title:          Security of Messages Exchanged Betw= een Servers and Relay Agents
Document date:  2017-04-19
Group:          dhc
Pages:          8
URL:            https://www.ietf.org/internet-drafts/draft-ietf-dhc-relay-server-security-05= .txt
Status:         https://da= tatracker.ietf.org/doc/draft-ietf-dhc-relay-server-security/
Htmlized:       https://tools.ietf= .org/html/draft-ietf-dhc-relay-server-security-05
Htmlized:       https://= datatracker.ietf.org/doc/html/draft-ietf-dhc-relay-server-security-05 Diff:           = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-relay-server-security-05<= /a>

- Bernie Volz

 
= --Apple-Mail-A9F14B0A-7EE5-40B1-B7E8-FC23CB89EB41-- From nobody Sat Apr 22 09:59:37 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 3DF6F127077; Sat, 22 Apr 2017 09:59:36 -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 ZsQGRsf6QDmv; Sat, 22 Apr 2017 09:59:34 -0700 (PDT) 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 245301294AB; Sat, 22 Apr 2017 09:59:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3912; q=dns/txt; s=iport; t=1492880374; x=1494089974; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=PKMh1oKuOepMSH2Ovr7CXw86HTsVqIRB/BO/z+X03q0=; b=GmPeJgZ63xmZJfqxdtEb6qTWnBtPrm7QZXXczYcl55Qy7TWNQ/7yjcga Uw1nh8yvB3mN1WpROp5g/8PnzhXE+kKQRD6kJoEcLzdWHo9+X9ZOmWanX DTRuG/1zNeiFXgUCDoML9Trg9G8G5MlTJXNW3H4s5MIROmw+MjVgtQpsP E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BrAQDhivtY/5NdJa1cDgsBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNUYYEMB4NgihWRaIMfkkaCDyEPhXQChAw/GAECAQEBAQEBAWs?= =?us-ascii?q?ohRUBAQEBAgEBAR8BTAsFBwQCAQgRBAEBAgMfBAIDAicLFAkIAgQBDQUIEYl7C?= =?us-ascii?q?A6MK51ZAYIqixsBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYEIgyaEAoMZgTyCdw6?= =?us-ascii?q?DGYJiBZ1BAYcWi2aRYJQYAR84gQZjFUSEZh8ZgQ09dYZ5gTCBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.37,234,1488844800"; d="scan'208";a="416179076" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Apr 2017 16:59:33 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v3MGxXUd022561 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 22 Apr 2017 16:59:33 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sat, 22 Apr 2017 11:59:32 -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, 22 Apr 2017 11:59:32 -0500 From: "Bernie Volz (volz)" To: =?iso-2022-jp?B?GyRCP0BMQEMjOkgbKEI=?= , Timothy Carlin CC: dhcwg , draft-ietf-dhc-sedhcpv6 authors Thread-Topic: [dhcwg] sedhcpv6 data size issue (Re: WGLC on draft-ietf-dhc-sedhcpv6-21 - Respond by March 29th) Thread-Index: AQHSuf8ILJ2o6tUo4E2uk2ZsrOk7tqHRm15Q Date: Sat, 22 Apr 2017 16:59:32 +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.98.1.195] Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [dhcwg] sedhcpv6 data size issue (Re: 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: Sat, 22 Apr 2017 16:59:36 -0000 Perhaps the RSA limitation can be resolved as described in https://tls.mbed= .org/kb/cryptography/rsa-encryption-maximum-data-size. Generate a 256-bit random keystring K Encrypt your data with AES-CBC with K Encrypt K with RSA Send both to the other side Not sure if generating the 256-bit random keystring would be done for each= message exchange, or perhaps just once (such as initially for the Reply to= the Information-Request) and both the client and server use the same K for= subsequent messages. This might be sufficient? There's additional information at https://security.stackexchange.com/questi= ons/33434/rsa-maximum-bytes-to-encrypt-comparison-to-aes-in-terms-of-securi= ty, which basically implies that calculating K once and reusing it would be= sufficient. But there's also the problem of the server determining which K to use to de= crypt the message since it may have LOTS of K's - one for each 'active' cli= ent. Perhaps that means the server needs to provide some kind of index for = which K and the client includes this (in plaintext). The downside is that i= t lets someone determine when a particular client is doing a DHCPv6 exchang= e, but that probably can be derived from some of the network metadata anywa= y (i.e., the client's source address). Perhaps the server just uses that me= tadata (i.e., client's source address or Relay-Forw peer-address) for the s= erver to determine the K. This does mean the client must use the same link-= local address for the "life" of the DHCP transactions using a particular K. - Bernie -----Original Message----- From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of ???? Sent: Thursday, April 20, 2017 1:53 PM To: Timothy Carlin Cc: dhcwg ; draft-ietf-dhc-sedhcpv6 authors Subject: [dhcwg] sedhcpv6 data size issue (Re: WGLC on draft-ietf-dhc-sedhc= pv6-21 - Respond by March 29th) At Wed, 5 Apr 2017 13:13:38 -0400, Timothy Carlin wrote: > I'm also wondering about using RSA for encryption, as the data size=20 > (and thus message size) is limited to the key size that the client or=20 > server provides. This could cause problems with large DHCP messages. =20 > Could a symmetric key algorithm (e.g. AES) be used? The keys for this=20 > would have to be negotiated during the initial Information-request/Reply. I agree the data size limitation of RSA can be critical. At least data for= the very initial Encrypted-Query message is quite unlikely to be encrypted= at once, since the data contains a certificate option (which contains the = client's public key). Assuming a 2048-bit key, we can only encrypt 256 - (= overhead for padding etc) octets of data at once. I'm afraid this is too l= imited even for subsequent messages that don't contain the certificate opti= on. One straightforward workaround is to divide the data and encrypt each = chunk separately, but this may not be acceptable due to the cost, especiall= y for the server. (Even if we adopt this approach I guess the current draf= t text is too unclear about it and should be revised to describe specifical= ly how to do it). I suspect using symmetric session keys can't be an (easy) option, either. = At least I don't think we can do this negotiation in the initial Informatio= n-Request/Reply exchange, since to do so the client would have to include i= ts certificate in the Information-Request message but we intentionally avoi= d that due to a privacy concern. In any case, I'm afraid this issue will require some substantial changes to= the specification. Right now I don't have a clear idea about what's the b= est. -- JINMEI, Tatuya _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From nobody Sat Apr 22 11:31: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 C073C12951E; Sat, 22 Apr 2017 11:31:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.303 X-Spam-Level: X-Spam-Status: No, score=-17.303 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_H2=-2.8, 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 e58AR_ZuC7rn; Sat, 22 Apr 2017 11:31:12 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B853B129443; Sat, 22 Apr 2017 11:31:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4465; q=dns/txt; s=iport; t=1492885872; x=1494095472; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=x3awb7gulROQcPOWqPfkYWLQzu2MR6pSgQMKfXHbl0g=; b=ALXbNWofX/bQhQiiifiPp05vXzbfG5EGnCuJgI9YGv+/0kQcJL+nikIf GDJX63949nSsiJsSFvh7NHAXsvypgm056iPw5X4m61KfA652PY6H3+I1G jCJxBGqp55indW+pVpPF44Qz9teXYGKmMbY6gDu8+RItoevmRaVMV63Cn c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DPAACNoPtY/5tdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1RhgQwHjXWRZ5Vlgg8hC4V4AoQMPxgBAgEBAQEBAQFrKIUVAQE?= =?us-ascii?q?BAQMBATg0FwQCAQgOAwMBAQEfCQcnCxQJCAIEARIIihQOrDmLGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBARgFiDCDGYE8gwWFewWWSYZ4AYcWi2aCCYUziGeBPYhviyk?= =?us-ascii?q?BHziBBmMVGiqGaHWIKYENAQEB?= X-IronPort-AV: E=Sophos;i="5.37,235,1488844800"; d="scan'208";a="239857395" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Apr 2017 18:31:11 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v3MIVBgW001129 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 22 Apr 2017 18:31:11 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, 22 Apr 2017 13:31:11 -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, 22 Apr 2017 13:31:11 -0500 From: "Bernie Volz (volz)" To: Tomek Mrugalski , dhcwg , "draft-ietf-dhc-relay-port@ietf.org" Thread-Topic: [dhcwg] WGLC on draft-ietf-dhc-relay-port-02 - respond by Apr 26 Thread-Index: AQHSrkJ4jGafpAaCIk+/kF5HBW5FkaHRyhDA Date: Sat, 22 Apr 2017 18:31:10 +0000 Message-ID: <7ba7b94f31bb41dbb404ef1c33026431@XCH-ALN-003.cisco.com> References: <4cb9bdab-f3a2-a9d0-1056-302b5ecdeae7@gmail.com> In-Reply-To: <4cb9bdab-f3a2-a9d0-1056-302b5ecdeae7@gmail.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.195] 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-relay-port-02 - respond by Apr 26 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, 22 Apr 2017 18:31:15 -0000 Hi: I reviewed the 04 version. This document could use some updates. Below are my comments. I think these = should be addressed before the document advances, but otherwise I think it = should be mostly ready to move forward. 1. General - I would highly recommend this draft adopt and document the "DH= CP" terminology as follows: DHCP means DHCPv4 and DHCPv6. DHCPv4 means the Dynamic Host Configuration Protocol for IPv4 as document= ed in RFC2131. DHCPv6 means the Dynamic Host Configuration Protocol for IPv6 as documente= d in RFC3315. And make use of these correctly. The document currently uses DHCP to mean DHCPv4 or both DHCPv4 and DHCPv6. Similarly, I 'd suggest using IPv4 and IPv6 (or IP when being general and a= pply to both or either). 2. Abstract - As currently written I don't see why this RFC is needed. Rela= y source ports in 2131/3315 are meaningless and the abstract "allows any va= lid number" which is already the case. It needs to be document that this pr= ovides the means for the relay to receive packets from a server or (upstrea= m) relay on any port, not just the default port. 3. Introduction (1) - The "to remember inbound" may cause some concern with= regards to relay's -- since they actually do not remember anything (they a= re supposed to be stateless). I wonder if this text can be cleaned up -- s= ervers need to "remember" while processing a packet; (cascading) relay's ne= ed to add this port information to the Relay-Forw packets. 4. Section 4.2 - there are several places where "non-DHCP UDP port" is used= . I wonder whether we could just say "port other than 547. I know this is i= n the terminology, but in this case it is DHCPv6 specific text so why make = someone look it up? I guess you could use: "non-DHCP UDP Port (not 547)" or= similar if you wanted to keep the reference to that term? This same comment applies to section 5.1 and 5.2 (though in 5.1 port 67 app= lies).=20 In the end, it may be that the definition isn't that useful and perhaps tha= t would even be better to remove it and just use the explicit port numbers?= I think this would help readability. But review and consider. 5. Section 7 (IANA). Please look at a document such as https://tools.ietf.o= rg/html/rfc7839#section-8. To avoid confusion, we have put the URL of the t= ables in the IANA considerations. This practice should be followed here to = that it is clear to IANA exactly which set of tables to update. 6. Section 8 (Security Considerations). This should reference the security = considerations of RFC 2131 and 3315. The text that is there is more of an operational consideration rather than = what security issues this new work might expose - which may be nothing new = over 2131/3315. But pointing out that firewalls need to be adjusted is a go= od thing. 7. Section 10 (Document Change Log). Usually an RFC Editor note is added to= request that they REMOVE this material in the RFC publication process. - Bernie -----Original Message----- From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Tomek Mrugalski Sent: Wednesday, April 05, 2017 3:26 PM To: dhcwg Subject: [dhcwg] WGLC on draft-ietf-dhc-relay-port-02 - respond by Apr 26 Hi, draft-ietf-dhc-relay-port-02 defines a small extension to the DHCPv4 and DHCPv6 protocols that allows usage of other UDP source ports to be used by = relay agents. Authors believe this document is ready. The discussions so fa= r on the mailing list were a bit modest, but the concept is simple, the dra= ft was presented twice (in Buenos Aires and Berlin) and enjoyed a favourabl= e reception in the room. As such, we announce a working group last call on = this document. Please review and comment. This is a very short document. It has around 6 pages of actual text. Many WG participants may celebrate upcoming Easter and take some days off, = therefore this WGLC is a bit longer than typical two weeks. Title: Generalized UDP Source Port for DHCP Relay Authors: N. Shen, E. Chen Filename: draft-ietf-dhc-relay-port-02 Pages: 10 (around 6 of actual technical text) Date: 2017-02-28 Link: https://tools.ietf.org/html/draft-ietf-dhc-relay-port-02 Responses by April 26th are appreciated. Thanks, Bernie and Tomek _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From nobody Mon Apr 24 08:55:39 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 F21A3131761; Mon, 24 Apr 2017 08:55:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Eric Rescorla To: "The IESG" Cc: draft-ietf-dhc-relay-server-security@ietf.org, Tomek Mrugalski , dhc-chairs@ietf.org, tomasz.mrugalski@gmail.com, dhcwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149304933098.25881.2630128409132458445.idtracker@ietfa.amsl.com> Date: Mon, 24 Apr 2017 08:55:30 -0700 Archived-At: Subject: [dhcwg] Eric Rescorla's No Objection on draft-ietf-dhc-relay-server-security-05: (with COMMENT) 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: Mon, 24 Apr 2017 15:55:31 -0000 Eric Rescorla has entered the following ballot position for draft-ietf-dhc-relay-server-security-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dhc-relay-server-security/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Based on e-mail it seems like at least one company is implementing. Personally, were I voting, I'd vote against making an MTI that I expect almost nobody to follow, but I concede that that's not enough to hold a discuss here. From nobody Mon Apr 24 15:54:44 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 8362112706D; Mon, 24 Apr 2017 15:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, 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 SNVq1lZ-Vwvx; Mon, 24 Apr 2017 15:54:41 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (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 F09E7126FDC; Mon, 24 Apr 2017 15:54:40 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id m36so126826609qtb.0; Mon, 24 Apr 2017 15:54:40 -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=kQ9xbMxuAzvehp8C1VcSswoEQiylJ6+JrBboI7SRhE4=; b=ek7VwNYZpt60qcu3YTAtV+UHzp5Um+TOgEKMfIuRop7dpevcmlXtIT7LWWP4rbGMon yuczlivsih7cvXt8opapcYDPHkJi60lhJmhu7GEUxtUUJb0GEtJyOsX4IqaTICkUnpn0 fy6r/vlumXbphZQnAnH3l3Jt6ItdQb0qgZI/dnpizPqnTijbeNuT2SGjxd+sg7DRbqL4 l7H2+8QrPy/qPhApBal6Dbkc8zl6X64MeD3alGuM24O1+3Rmz86OTmN9nydHmGCmDxmW +cXf7FZX155qPhyohRnJvP+ZIDIvnKHxzb+kVRNQGM3o1t0/U9jdimzZpFZ42aJmABdZ YeZw== 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=kQ9xbMxuAzvehp8C1VcSswoEQiylJ6+JrBboI7SRhE4=; b=c22uMWuO7y0r2AIDcfYBnmNGNoDnm0jPBihnpBJcOsg+Dh7NkpW8/zsBiq6ns4gQpN +P20coRfTtE8aRpJoxeBWIX7ZaqI7OqJOnoZ91eBw8Fr5Qec8JsdLSYr87WmvhjgeKJ9 t1LNZx08w910mwqunjsmJpG2HDevWLuTO9t3ea9bVpA/D7R9JUvKlAc9Ow2fd2Y3rgGa F3Tq9sTulWXE/NuzBZEy+IVZUhFGIrSphuybfq+d1jMoFgsuLUkWeRgARL4dB/t0B1IU ALR2a0wWCxNkM3EJzIFZ3YxboH1zGHKjD7xV0ipj5dtzbReZDQWN6QP3DAD/fYkAaSbO fsww== X-Gm-Message-State: AN3rC/5puObG9RorTIU9BpZXOO70jMQE026mlxj93k1FvCrjWdIRuQsS Xw42V9tYzRjh+JMoBZzzGG+GJ0mpl0fk9ME= X-Received: by 10.200.51.132 with SMTP id c4mr28242310qtb.13.1493074479961; Mon, 24 Apr 2017 15:54:39 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.208 with HTTP; Mon, 24 Apr 2017 15:54:39 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Mon, 24 Apr 2017 15:54:39 -0700 X-Google-Sender-Auth: EUJJaS-J-RwDzgM9g7EKYiKVTNU Message-ID: To: "Bernie Volz (volz)" Cc: Timothy Carlin , dhcwg , draft-ietf-dhc-sedhcpv6 authors Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [dhcwg] sedhcpv6 data size issue (Re: 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, 24 Apr 2017 22:54:43 -0000 At Sat, 22 Apr 2017 16:59:32 +0000, "Bernie Volz (volz)" wrote: > Perhaps the RSA limitation can be resolved as described in https://tls.mbed.org/kb/cryptography/rsa-encryption-maximum-data-size. > > Generate a 256-bit random keystring K > Encrypt your data with AES-CBC with K > Encrypt K with RSA > Send both to the other side > > Not sure if generating the 256-bit random keystring would be done > for each message exchange, or perhaps just once (such as initially > for the Reply to the Information-Request) and both the client and > server use the same K for subsequent messages. This might be > sufficient? This is basically one form of "using a symmetric session key", so we'd use the same K for all subsequent messages. But this can't be in the Reply to the initial Information-Request, since at that point the server may not know the client's public key. So I'd expect the client to generate K and include it (encrypted with RSA) and actual data (encrypted using K) in the initial encrypted message to the server. > But there's also the problem of the server determining which K to > use to decrypt the message since it may have LOTS of K's - one for > each 'active' client. Perhaps that means the server needs to provide > some kind of index for which K and the client includes this (in > plaintext). Right, and > The downside is that it lets someone determine when a > particular client is doing a DHCPv6 exchange, but that probably can > be derived from some of the network metadata anyway (i.e., the > client's source address). Perhaps the server just uses that metadata > (i.e., client's source address or Relay-Forw peer-address) for the > server to determine the K. This does mean the client must use the > same link-local address for the "life" of the DHCP transactions > using a particular K. I wouldn't too much worry about the identity disclosure due to that. As you said, unless the client keeps changing the link-local address to send DHCPv6 messages, the same level of identify is already disclosed. But if we really worry about it, we could also include the encrypted K in all messages to the server. In any case, I believe this problem can be solvable, but will require a quite substantial update to the current spec. -- JINMEI, Tatuya From nobody Mon Apr 24 21:02:10 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 41F2B1294CE; Mon, 24 Apr 2017 21:02:09 -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 bKstzPFsNei6; Mon, 24 Apr 2017 21:02:05 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93C9C127698; Mon, 24 Apr 2017 21:02:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=33660; q=dns/txt; s=iport; t=1493092925; x=1494302525; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=668V28qZ+mxCO3/usJ5QsM+uQV0MDKAcezQbwnjiOEs=; b=IFTSx7ifBnXrPk4271nH0TIqCpJvYHNEfpArPgNla1CHBJkc/ooIHrIt THzUQbt6HVdQFVBP4awjJG0T48aF4bbjUdlDodujadMH1oBTeRJ6VMupo Q3eN1BT9ThH50bM6tQWn+GDHzPPvQqBXm93pniyesNbEzHr3K8tHE9Sgh I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BsAQD5yP5Y/4oNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm5mYXoSB4NgihWRbJVlgg8hAQqFeAIag3w/GAECAQEBAQEBAWs?= =?us-ascii?q?ohRUBAQEBAwEBIUsLDAQCAQgRAwEBASEHAwICAiULFAkIAgQOBQmKEw6qVYImi?= =?us-ascii?q?x4BAQEBAQEBAQEBAQEBAQEBAQEBAQEdiDArgm6BPIMFNoJmLoIxBZZJhngBhxa?= =?us-ascii?q?Lb4IAhTOIZ4E9iG+LKQEfOIEGYxUaKhEBhGOBc3WIKYENAQEB?= X-IronPort-AV: E=Sophos;i="5.37,247,1488844800"; d="scan'208,217";a="414232286" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Apr 2017 04:02:04 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v3P4244c002289 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 25 Apr 2017 04:02:04 GMT Received: from xch-rcd-004.cisco.com (173.37.102.14) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 24 Apr 2017 23:02:03 -0500 Received: from xch-rcd-004.cisco.com ([173.37.102.14]) by XCH-RCD-004.cisco.com ([173.37.102.14]) with mapi id 15.00.1210.000; Mon, 24 Apr 2017 23:02:03 -0500 From: "Naiming Shen (naiming)" To: "Bernie Volz (volz)" CC: Tomek Mrugalski , dhcwg , "draft-ietf-dhc-relay-port@ietf.org" Thread-Topic: [dhcwg] WGLC on draft-ietf-dhc-relay-port-02 - respond by Apr 26 Thread-Index: AQHSrkJ4jGafpAaCIk+/kF5HBW5FkaHRyhDAgAQelgA= Date: Tue, 25 Apr 2017 04:02:03 +0000 Message-ID: References: <4cb9bdab-f3a2-a9d0-1056-302b5ecdeae7@gmail.com> <7ba7b94f31bb41dbb404ef1c33026431@XCH-ALN-003.cisco.com> In-Reply-To: <7ba7b94f31bb41dbb404ef1c33026431@XCH-ALN-003.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.26.105] Content-Type: multipart/alternative; boundary="_000_A7E53EB44CBB4E32BDB4F9C7CBDF0CB2ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-relay-port-02 - respond by Apr 26 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, 25 Apr 2017 04:02:09 -0000 --_000_A7E53EB44CBB4E32BDB4F9C7CBDF0CB2ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpIaSBCZXJuaWUsDQoNClRoYW5rcyBmb3IgdGhlIGRldGFpbGVkIGNvbW1lbnRzLiBSZXBsaWVz IGlubGluZToNCg0KDQpPbiBBcHIgMjIsIDIwMTcsIGF0IDExOjMxIEFNLCBCZXJuaWUgVm9seiAo dm9seikgPHZvbHpAY2lzY28uY29tPG1haWx0bzp2b2x6QGNpc2NvLmNvbT4+IHdyb3RlOg0KDQpI aToNCg0KSSByZXZpZXdlZCB0aGUgMDQgdmVyc2lvbi4NCg0KVGhpcyBkb2N1bWVudCBjb3VsZCB1 c2Ugc29tZSB1cGRhdGVzLiBCZWxvdyBhcmUgbXkgY29tbWVudHMuIEkgdGhpbmsgdGhlc2Ugc2hv dWxkIGJlIGFkZHJlc3NlZCBiZWZvcmUgdGhlIGRvY3VtZW50IGFkdmFuY2VzLCBidXQgb3RoZXJ3 aXNlIEkgdGhpbmsgaXQgc2hvdWxkIGJlIG1vc3RseSByZWFkeSB0byBtb3ZlIGZvcndhcmQuDQoN CjEuIEdlbmVyYWwgLSBJIHdvdWxkIGhpZ2hseSByZWNvbW1lbmQgdGhpcyBkcmFmdCBhZG9wdCBh bmQgZG9jdW1lbnQgdGhlICJESENQIiB0ZXJtaW5vbG9neSBhcyBmb2xsb3dzOg0KREhDUCBtZWFu cyBESENQdjQgYW5kIERIQ1B2Ni4NCkRIQ1B2NCBtZWFucyB0aGUgRHluYW1pYyBIb3N0IENvbmZp Z3VyYXRpb24gIFByb3RvY29sIGZvciBJUHY0IGFzIGRvY3VtZW50ZWQgaW4gUkZDMjEzMS4NCkRI Q1B2NiBtZWFucyB0aGUgRHluYW1pYyBIb3N0IENvbmZpZ3VyYXRpb24gUHJvdG9jb2wgZm9yIElQ djYgYXMgZG9jdW1lbnRlZCBpbiBSRkMzMzE1Lg0KQW5kIG1ha2UgdXNlIG9mIHRoZXNlIGNvcnJl Y3RseS4NCg0KVGhlIGRvY3VtZW50IGN1cnJlbnRseSB1c2VzIERIQ1AgdG8gbWVhbiBESENQdjQg b3IgYm90aCBESENQdjQgYW5kIERIQ1B2Ni4NCg0KU2ltaWxhcmx5LCBJICdkIHN1Z2dlc3QgdXNp bmcgSVB2NCBhbmQgSVB2NiAob3IgSVAgd2hlbiBiZWluZyBnZW5lcmFsIGFuZCBhcHBseSB0byBi b3RoIG9yIGVpdGhlcikuDQoNClN1cmUuIE1ha2VzIHNlbnNlLiBXaWxsIGdvIHRocm91Z2ggdGhv c2UgYW5kIG5vdCB0byBtaXggdGhlIERIQ1AgYW5kIERIQ1B2NCB1c2FnZS4NClNvbWUgb2YgdGhl IHBsYWNlcywganVzdCBJUHY0IGFuZCBJUHY2IGlzIGZpbmUuDQoNCg0KMi4gQWJzdHJhY3QgLSBB cyBjdXJyZW50bHkgd3JpdHRlbiBJIGRvbid0IHNlZSB3aHkgdGhpcyBSRkMgaXMgbmVlZGVkLiBS ZWxheSBzb3VyY2UgcG9ydHMgaW4gMjEzMS8zMzE1IGFyZSBtZWFuaW5nbGVzcyBhbmQgdGhlIGFi c3RyYWN0ICJhbGxvd3MgYW55IHZhbGlkIG51bWJlciIgd2hpY2ggaXMgYWxyZWFkeSB0aGUgY2Fz ZS4gSXQgbmVlZHMgdG8gYmUgZG9jdW1lbnQgdGhhdCB0aGlzIHByb3ZpZGVzIHRoZSBtZWFucyBm b3IgdGhlIHJlbGF5IHRvIHJlY2VpdmUgcGFja2V0cyBmcm9tIGEgc2VydmVyIG9yICh1cHN0cmVh bSkgcmVsYXkgb24gYW55IHBvcnQsIG5vdCBqdXN0IHRoZSBkZWZhdWx0IHBvcnQuDQoNCk9rLCB3 aGF0IGFib3V0IHRoaXM/DQoNCiAgIFRoaXMgZG9jdW1lbnQgcHJvcG9zZXMgYW4gZXh0ZW5zaW9u IHRvIHRoZSBESENQIHByb3RvY29scyB0aGF0IGFsbG93cw0KICAgYSByZWxheSBhZ2VudCB0byBy ZWNlaXZlIHBhY2tldHMgZnJvbSBhIHNlcnZlciBvciBhbiB1cHN0cmVhbSByZWxheQ0KICAgYWdl bnQgb24gYW55IFVEUCBwb3J0LCBub3QganVzdCB0aGUgZGVmYXVsdCBwb3J0IDY3IGZvciBJUHY0 IG9yDQogICBkZWZhdWx0IHBvcnQgNTQ3IGZvciBJUHY2Lg0KDQoNCjMuIEludHJvZHVjdGlvbiAo MSkgLSBUaGUgInRvIHJlbWVtYmVyIGluYm91bmQiIG1heSBjYXVzZSBzb21lIGNvbmNlcm4gd2l0 aCByZWdhcmRzIHRvIHJlbGF5J3MgLS0gc2luY2UgdGhleSBhY3R1YWxseSBkbyBub3QgcmVtZW1i ZXIgYW55dGhpbmcgKHRoZXkgYXJlIHN1cHBvc2VkIHRvIGJlIHN0YXRlbGVzcykuICBJIHdvbmRl ciBpZiB0aGlzIHRleHQgY2FuIGJlIGNsZWFuZWQgdXAgLS0gc2VydmVycyBuZWVkIHRvICJyZW1l bWJlciIgd2hpbGUgcHJvY2Vzc2luZyBhIHBhY2tldDsgKGNhc2NhZGluZykgcmVsYXkncyBuZWVk IHRvIGFkZCB0aGlzIHBvcnQgaW5mb3JtYXRpb24gdG8gdGhlIFJlbGF5LUZvcncgcGFja2V0cy4N Cg0KT2ssIGhvdyBhYm91dCB0aGlzPw0KDQogICBUaGlzIGV4dGVuc2lvbiByZXF1aXJlcw0KICAg YSBESENQIHNlcnZlciB0byByZW1lbWJlciB0aGUgaW5ib3VuZCBwYWNrZXQncyBVRFAgcG9ydCBu dW1iZXIgYWxvbmcNCiAgIHdpdGggdGhlIElQL0lQdjYgYWRkcmVzcy4gIFRoZSBESENQIHNlcnZl ciB3aGVuIHNlbmRpbmcgYmFjayByZXBsaWVzDQogICBNVVNUIHVzZSB0aGUgVURQIHBvcnQgbnVt YmVyIHRoYXQgdGhlIGluY29taW5nIHJlbGF5IGFnZW50IHVzZXMNCiAgIGluc3RlYWQgb2YgdGhl IGZpeGVkIERIQ1AgcG9ydCBudW1iZXIuICBJbiB0aGUgY2FzZSBvZiBJUHY2IGNhc2NhZGVkDQog ICByZWxheSBhZ2VudHMgW1JGQzMzMTVdLCB0aGUgdXBzdHJlYW0gcmVsYXkgYWdlbnQgbmVlZHMg dG8gdXNlIHRoZQ0KICAgIlJlbGF5IFNvdXJjZSBQb3J0IE9wdGlvbiIgdG8gcmVjb3JkIHRoZSBk b3duc3RyZWFtIHNvdXJjZSBwb3J0IGFuZA0KICAgaXQgTVVTVCB1c2UgdGhpcyByZWNvcmRlZCBw b3J0IG51bWJlciBpbnN0ZWFkIG9mIHRoZSBmaXhlZCBESENQIHBvcnQNCiAgIG51bWJlciB3aGVu IHJlcGxheWluZyB0aGUgcmVwbHkgbWVzc2FnZXMuDQoNCg0KNC4gU2VjdGlvbiA0LjIgLSB0aGVy ZSBhcmUgc2V2ZXJhbCBwbGFjZXMgd2hlcmUgIm5vbi1ESENQIFVEUCBwb3J0IiBpcyB1c2VkLiBJ IHdvbmRlciB3aGV0aGVyIHdlIGNvdWxkIGp1c3Qgc2F5ICJwb3J0IG90aGVyIHRoYW4gNTQ3LiBJ IGtub3cgdGhpcyBpcyBpbiB0aGUgdGVybWlub2xvZ3ksIGJ1dCBpbiB0aGlzIGNhc2UgaXQgaXMg REhDUHY2IHNwZWNpZmljIHRleHQgc28gd2h5IG1ha2Ugc29tZW9uZSBsb29rIGl0IHVwPyBJIGd1 ZXNzIHlvdSBjb3VsZCB1c2U6ICJub24tREhDUCBVRFAgUG9ydCAobm90IDU0NykiIG9yIHNpbWls YXIgaWYgeW91IHdhbnRlZCB0byBrZWVwIHRoZSByZWZlcmVuY2UgdG8gdGhhdCB0ZXJtPw0KDQpU aGlzIHNhbWUgY29tbWVudCBhcHBsaWVzIHRvIHNlY3Rpb24gNS4xIGFuZCA1LjIgKHRob3VnaCBp biA1LjEgcG9ydCA2NyBhcHBsaWVzKS4NCg0KSW4gdGhlIGVuZCwgaXQgbWF5IGJlIHRoYXQgdGhl IGRlZmluaXRpb24gaXNuJ3QgdGhhdCB1c2VmdWwgYW5kIHBlcmhhcHMgdGhhdCB3b3VsZCBldmVu IGJlIGJldHRlciB0byByZW1vdmUgaXQgYW5kIGp1c3QgdXNlIHRoZSBleHBsaWNpdCBwb3J0IG51 bWJlcnM/IEkgdGhpbmsgdGhpcyB3b3VsZCBoZWxwIHJlYWRhYmlsaXR5LiBCdXQgcmV2aWV3IGFu ZCBjb25zaWRlci4NCg0KSSBzdGlsbCB0aGluayBpdOKAmXMganVzdCB0b28gbWFueSBwbGFjZXMg d2UgYXJlIHRhbGtpbmcgYWJvdXQgYm90aCBJUHY0IGFuZCBJUHY2IGFuZA0KaGF2ZSB0byBzYXkg Ym90aCBvZiB0aGUgcG9ydHMgZXhwbGljaXRseS4gQnV0IHRob3NlIHNvbWUgb2YgdGhlIHBsYWNl cyBpcyBvbmx5IGZvcg0KSVB2NCBvciBvbmx5IGZvciBJUHY2LCBJ4oCZbGwgZG8gd2hhdCB5b3Ug c3VnZ2VzdGVkLCB0byB1c2UgdGhlIChub3QgNjcpIG9yIHRvIHVzZQ0KdGhlIChub3QgNTQ3KSBp biB0aG9zZSBwbGFjZXMuDQoNCg0KNS4gU2VjdGlvbiA3IChJQU5BKS4gUGxlYXNlIGxvb2sgYXQg YSBkb2N1bWVudCBzdWNoIGFzIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3ODM5I3Nl Y3Rpb24tOC4gVG8gYXZvaWQgY29uZnVzaW9uLCB3ZSBoYXZlIHB1dCB0aGUgVVJMIG9mIHRoZSB0 YWJsZXMgaW4gdGhlIElBTkEgY29uc2lkZXJhdGlvbnMuIFRoaXMgcHJhY3RpY2Ugc2hvdWxkIGJl IGZvbGxvd2VkIGhlcmUgdG8gdGhhdCBpdCBpcyBjbGVhciB0byBJQU5BIGV4YWN0bHkgd2hpY2gg c2V0IG9mIHRhYmxlcyB0byB1cGRhdGUuDQoNCk9rLCBzdXJlLiBCdXQgdGhlIGV4YW1wbGUgeW91 IHNpdGVkLCBpdCBhbHJlYWR5IGhhZCB0aGUgSUFOQSBudW1iZXIgYXNzaWduZWQuDQpGb3IgdGhp cyBvbmUsIHdlIGhhdmUgbm90IHNvIGZhciwgaG93IGFib3V0IHRoZXNlIHNlbnRlbmNlcz8NCg0K ICAgQSBuZXcgc3ViLW9wdGlvbiwgREhDUHY0IFJlbGF5IFNvdXJjZSBQb3J0LCBpcyBkZWZpbmVk IGluIHRoaXMNCiAgIGRvY3VtZW50IHdpdGhpbiB0aGUgSVB2NCBSZWxheSBBZ2VudCBJbmZvcm1h dGlvbiBPcHRpb24uICBJdCBuZWVkcyB0bw0KICAgYmUgYXNzaWduZWQgYnkgSUFOQSBpbiB0aGUg IkRIQ1AgUmVsYXkgQWdlbnQgU3ViLU9wdGlvbiBDb2RlcyINCiAgIHJlZ2lzdHJ5LCBodHRwOi8v d3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL2Jvb3RwLWRoY3AtcGFyYW1ldGVycyBhcw0KICAgc3Bl Y2lmaWVkIGluIFtSRkMzMDQ2XS4NCg0KICAgQSBuZXcgb3B0aW9uLCBESENQdjYgUmVsYXkgU291 cmNlIFBvcnQsIGlzIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudA0KICAgZm9yIERIQ1B2NiBhbmQg aXQgbmVlZHMgdG8gYmUgYXNzaWduZWQgYnkgSUFOQSBmb3IgdGhlIERIQ1B2NiBvcHRpb24NCiAg IGNvZGUsIGluIHRoZSAiT3B0aW9uIENvZGVzIiByZWdpc3RyeSBmb3IgREhDUHY2LA0KICAgaHR0 cDovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9kaGNwdjYtcGFyYW1ldGVycyBhcyBzcGVjaWZp ZWQgaW4NCiAgIFtSRkMzMzE1XS4NCg0KDQo2LiBTZWN0aW9uIDggKFNlY3VyaXR5IENvbnNpZGVy YXRpb25zKS4gVGhpcyBzaG91bGQgcmVmZXJlbmNlIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9u cyBvZiBSRkMgMjEzMSBhbmQgMzMxNS4NCg0KVGhlIHRleHQgdGhhdCBpcyB0aGVyZSBpcyBtb3Jl IG9mIGFuIG9wZXJhdGlvbmFsIGNvbnNpZGVyYXRpb24gcmF0aGVyIHRoYW4gd2hhdCBzZWN1cml0 eSBpc3N1ZXMgdGhpcyBuZXcgd29yayBtaWdodCBleHBvc2UgLSB3aGljaCBtYXkgYmUgbm90aGlu ZyBuZXcgb3ZlciAyMTMxLzMzMTUuIEJ1dCBwb2ludGluZyBvdXQgdGhhdCBmaXJld2FsbHMgbmVl ZCB0byBiZSBhZGp1c3RlZCBpcyBhIGdvb2QgdGhpbmcuDQoNCk9rLCBJIGFkZGVkIHRoaXMgcGFy YWdyYXBoIGluIHRoZSBmcm9udCwgYW5kIGEg4oCYQWx0aG91Z2jigJkgdG8gc3RhcnQgdGhlIG9y aWdpbmFsIHNlbnRlbmNlOg0KDQogICBbUkZDMzExOF0gYW5kIFtSRkMzMzE1XSBkZXNjcmliZWQg bWFueSBvZiB0aGUgdGhyZWF0cyBpbiB1c2luZyBESENQLg0KICAgVGhpcyBleHRlbnNpb24gZG9l cyBub3QgcmFpc2UgYWRkaXRpb24gc2VjdXJpdHkgaXNzdWVzLg0KDQogICBBbHRob3VnaCBpZiB0 aGUgbmV0d29yayB1c2VzIGZpcmV3YWxsIHRvIGJsb2NrIG9yIGFsbG93IERIQ1AgcGFja2V0cw0K ICAgICDigKYuDQoNCg0KDQo3LiBTZWN0aW9uIDEwIChEb2N1bWVudCBDaGFuZ2UgTG9nKS4gVXN1 YWxseSBhbiBSRkMgRWRpdG9yIG5vdGUgaXMgYWRkZWQgdG8gcmVxdWVzdCB0aGF0IHRoZXkgUkVN T1ZFIHRoaXMgbWF0ZXJpYWwgaW4gdGhlIFJGQyBwdWJsaWNhdGlvbiBwcm9jZXNzLg0KDQpTdXJl LiBXaWxsIHJlbW92ZSB0aGVzZSBpbiB0aGUgbmV4dCB2ZXJzaW9uLg0KDQp0aGFua3MuDQotIE5h aW1pbmcNCg0KDQotIEJlcm5pZQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog ZGhjd2cgW21haWx0bzpkaGN3Zy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgVG9tZWsg TXJ1Z2Fsc2tpDQpTZW50OiBXZWRuZXNkYXksIEFwcmlsIDA1LCAyMDE3IDM6MjYgUE0NClRvOiBk aGN3ZyA8ZGhjd2dAaWV0Zi5vcmc8bWFpbHRvOmRoY3dnQGlldGYub3JnPj4NClN1YmplY3Q6IFtk aGN3Z10gV0dMQyBvbiBkcmFmdC1pZXRmLWRoYy1yZWxheS1wb3J0LTAyIC0gcmVzcG9uZCBieSBB cHIgMjYNCg0KSGksDQpkcmFmdC1pZXRmLWRoYy1yZWxheS1wb3J0LTAyIGRlZmluZXMgYSBzbWFs bCBleHRlbnNpb24gdG8gdGhlIERIQ1B2NCBhbmQNCkRIQ1B2NiBwcm90b2NvbHMgdGhhdCBhbGxv d3MgdXNhZ2Ugb2Ygb3RoZXIgVURQIHNvdXJjZSBwb3J0cyB0byBiZSB1c2VkIGJ5IHJlbGF5IGFn ZW50cy4gQXV0aG9ycyBiZWxpZXZlIHRoaXMgZG9jdW1lbnQgaXMgcmVhZHkuIFRoZSBkaXNjdXNz aW9ucyBzbyBmYXIgb24gdGhlIG1haWxpbmcgbGlzdCB3ZXJlIGEgYml0IG1vZGVzdCwgYnV0IHRo ZSBjb25jZXB0IGlzIHNpbXBsZSwgdGhlIGRyYWZ0IHdhcyBwcmVzZW50ZWQgdHdpY2UgKGluIEJ1 ZW5vcyBBaXJlcyBhbmQgQmVybGluKSBhbmQgZW5qb3llZCBhIGZhdm91cmFibGUgcmVjZXB0aW9u IGluIHRoZSByb29tLiBBcyBzdWNoLCB3ZSBhbm5vdW5jZSBhIHdvcmtpbmcgZ3JvdXAgbGFzdCBj YWxsIG9uIHRoaXMgZG9jdW1lbnQuIFBsZWFzZSByZXZpZXcgYW5kIGNvbW1lbnQuDQoNClRoaXMg aXMgYSB2ZXJ5IHNob3J0IGRvY3VtZW50LiBJdCBoYXMgYXJvdW5kIDYgcGFnZXMgb2YgYWN0dWFs IHRleHQuDQoNCk1hbnkgV0cgcGFydGljaXBhbnRzIG1heSBjZWxlYnJhdGUgdXBjb21pbmcgRWFz dGVyIGFuZCB0YWtlIHNvbWUgZGF5cyBvZmYsIHRoZXJlZm9yZSB0aGlzIFdHTEMgaXMgYSBiaXQg bG9uZ2VyIHRoYW4gdHlwaWNhbCB0d28gd2Vla3MuDQoNClRpdGxlOiBHZW5lcmFsaXplZCBVRFAg U291cmNlIFBvcnQgZm9yIERIQ1AgUmVsYXkNCkF1dGhvcnM6IE4uIFNoZW4sIEUuIENoZW4NCkZp bGVuYW1lOiBkcmFmdC1pZXRmLWRoYy1yZWxheS1wb3J0LTAyDQpQYWdlczogMTAgKGFyb3VuZCA2 IG9mIGFjdHVhbCB0ZWNobmljYWwgdGV4dCkNCkRhdGU6IDIwMTctMDItMjgNCkxpbms6IGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWRoYy1yZWxheS1wb3J0LTAyDQoNClJl c3BvbnNlcyBieSBBcHJpbCAyNnRoIGFyZSBhcHByZWNpYXRlZC4NCg0KVGhhbmtzLA0KQmVybmll IGFuZCBUb21law0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KZGhjd2cgbWFpbGluZyBsaXN0DQpkaGN3Z0BpZXRmLm9yZzxtYWlsdG86ZGhjd2dAaWV0 Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RoY3dnDQoNCg== --_000_A7E53EB44CBB4E32BDB4F9C7CBDF0CB2ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <57E15514FDFCE244AA464E8C168D7D8C@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCkhpIEJlcm5pZSwNCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRoYW5rcyBmb3IgdGhlIGRldGFpbGVkIGNvbW1lbnRzLiBS ZXBsaWVzIGlubGluZTo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxkaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJj aXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gQXByIDIyLCAyMDE3LCBhdCAxMTozMSBB TSwgQmVybmllIFZvbHogKHZvbHopICZsdDs8YSBocmVmPSJtYWlsdG86dm9sekBjaXNjby5jb20i IGNsYXNzPSIiPnZvbHpAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9 IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9 IiI+SGk6PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSSByZXZpZXdlZCB0aGUgMDQgdmVy c2lvbi48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGlzIGRvY3VtZW50IGNvdWxkIHVz ZSBzb21lIHVwZGF0ZXMuIEJlbG93IGFyZSBteSBjb21tZW50cy4gSSB0aGluayB0aGVzZSBzaG91 bGQgYmUgYWRkcmVzc2VkIGJlZm9yZSB0aGUgZG9jdW1lbnQgYWR2YW5jZXMsIGJ1dCBvdGhlcndp c2UgSSB0aGluayBpdCBzaG91bGQgYmUgbW9zdGx5IHJlYWR5IHRvIG1vdmUgZm9yd2FyZC48YnIg Y2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQoxLiBHZW5lcmFsIC0gSSB3b3VsZCBoaWdobHkgcmVj b21tZW5kIHRoaXMgZHJhZnQgYWRvcHQgYW5kIGRvY3VtZW50IHRoZSAmcXVvdDtESENQJnF1b3Q7 IHRlcm1pbm9sb2d5IGFzIGZvbGxvd3M6PGJyIGNsYXNzPSIiPg0KPHNwYW4gY2xhc3M9IkFwcGxl LXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6cHJlIj48L3NwYW4+REhDUCBtZWFucyBESENQ djQgYW5kIERIQ1B2Ni48YnIgY2xhc3M9IiI+DQo8c3BhbiBjbGFzcz0iQXBwbGUtdGFiLXNwYW4i IHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUiPjwvc3Bhbj5ESENQdjQgbWVhbnMgdGhlIER5bmFtaWMg SG9zdCBDb25maWd1cmF0aW9uICZuYnNwO1Byb3RvY29sIGZvciBJUHY0IGFzIGRvY3VtZW50ZWQg aW4gUkZDMjEzMS48YnIgY2xhc3M9IiI+DQo8c3BhbiBjbGFzcz0iQXBwbGUtdGFiLXNwYW4iIHN0 eWxlPSJ3aGl0ZS1zcGFjZTpwcmUiPjwvc3Bhbj5ESENQdjYgbWVhbnMgdGhlIER5bmFtaWMgSG9z dCBDb25maWd1cmF0aW9uIFByb3RvY29sIGZvciBJUHY2IGFzIGRvY3VtZW50ZWQgaW4gUkZDMzMx NS48YnIgY2xhc3M9IiI+DQpBbmQgbWFrZSB1c2Ugb2YgdGhlc2UgY29ycmVjdGx5LjxiciBjbGFz cz0iIj4NCjxiciBjbGFzcz0iIj4NClRoZSBkb2N1bWVudCBjdXJyZW50bHkgdXNlcyBESENQIHRv IG1lYW4gREhDUHY0IG9yIGJvdGggREhDUHY0IGFuZCBESENQdjYuPGJyIGNsYXNzPSIiPg0KPGJy IGNsYXNzPSIiPg0KU2ltaWxhcmx5LCBJICdkIHN1Z2dlc3QgdXNpbmcgSVB2NCBhbmQgSVB2NiAo b3IgSVAgd2hlbiBiZWluZyBnZW5lcmFsIGFuZCBhcHBseSB0byBib3RoIG9yIGVpdGhlcikuPGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyIGNsYXNz PSIiPg0KPC9kaXY+DQpTdXJlLiBNYWtlcyBzZW5zZS4gV2lsbCBnbyB0aHJvdWdoIHRob3NlIGFu ZCBub3QgdG8gbWl4IHRoZSBESENQIGFuZCBESENQdjQgdXNhZ2UuPC9kaXY+DQo8ZGl2PlNvbWUg b2YgdGhlIHBsYWNlcywganVzdCBJUHY0IGFuZCBJUHY2IGlzIGZpbmUuPC9kaXY+DQo8ZGl2Pjxi ciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFz cz0iIj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KMi4gQWJzdHJhY3QgLSBBcyBjdXJy ZW50bHkgd3JpdHRlbiBJIGRvbid0IHNlZSB3aHkgdGhpcyBSRkMgaXMgbmVlZGVkLiBSZWxheSBz b3VyY2UgcG9ydHMgaW4gMjEzMS8zMzE1IGFyZSBtZWFuaW5nbGVzcyBhbmQgdGhlIGFic3RyYWN0 ICZxdW90O2FsbG93cyBhbnkgdmFsaWQgbnVtYmVyJnF1b3Q7IHdoaWNoIGlzIGFscmVhZHkgdGhl IGNhc2UuIEl0IG5lZWRzIHRvIGJlIGRvY3VtZW50IHRoYXQgdGhpcyBwcm92aWRlcyB0aGUgbWVh bnMgZm9yIHRoZSByZWxheSB0bw0KIHJlY2VpdmUgcGFja2V0cyBmcm9tIGEgc2VydmVyIG9yICh1 cHN0cmVhbSkgcmVsYXkgb24gYW55IHBvcnQsIG5vdCBqdXN0IHRoZSBkZWZhdWx0IHBvcnQuPGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyIGNsYXNz PSIiPg0KPC9kaXY+DQpPaywgd2hhdCBhYm91dCB0aGlzPzwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1zaXplOiAx NHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogTWVubG87IGJhY2tncm91bmQt Y29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQt dmFyaWFudC1saWdhdHVyZXM6IG5vLWNvbW1vbi1saWdhdHVyZXMiIGNsYXNzPSIiPiZuYnNwOyAm bmJzcDtUaGlzIGRvY3VtZW50IHByb3Bvc2VzIGFuIGV4dGVuc2lvbiB0byB0aGUgREhDUCBwcm90 b2NvbHMgdGhhdCBhbGxvd3M8L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBweDsg Zm9udC1zaXplOiAxNHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogTWVubG87 IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsiIGNsYXNzPSIiPg0KPHNwYW4g c3R5bGU9ImZvbnQtdmFyaWFudC1saWdhdHVyZXM6IG5vLWNvbW1vbi1saWdhdHVyZXMiIGNsYXNz PSIiPiZuYnNwOyZuYnNwOyBhIHJlbGF5IGFnZW50IHRvIHJlY2VpdmUgcGFja2V0cyBmcm9tIGEg c2VydmVyIG9yIGFuIHVwc3RyZWFtIHJlbGF5PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFy Z2luOiAwcHg7IGZvbnQtc2l6ZTogMTRweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1p bHk6IE1lbmxvOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7IiBjbGFzcz0i Ij4NCjxzcGFuIHN0eWxlPSJmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBuby1jb21tb24tbGlnYXR1 cmVzIiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsgYWdlbnQgb24gYW55IFVEUCBwb3J0LCBub3QganVz dCB0aGUgZGVmYXVsdCBwb3J0IDY3IGZvciBJUHY0IG9yPC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHls ZT0ibWFyZ2luOiAwcHg7IGZvbnQtc2l6ZTogMTRweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9u dC1mYW1pbHk6IE1lbmxvOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7IiBj bGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBuby1jb21tb24t bGlnYXR1cmVzIiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsgZGVmYXVsdCBwb3J0IDU0NyBmb3IgSVB2 Ni48L3NwYW4+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXZhcmlhbnQt bGlnYXR1cmVzOiBuby1jb21tb24tbGlnYXR1cmVzIiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8 L3NwYW4+PC9kaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xh c3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjMuIEludHJvZHVjdGlvbiAoMSkg LSBUaGUgJnF1b3Q7dG8gcmVtZW1iZXIgaW5ib3VuZCZxdW90OyBtYXkgY2F1c2Ugc29tZSBjb25j ZXJuIHdpdGggcmVnYXJkcyB0byByZWxheSdzIC0tIHNpbmNlIHRoZXkgYWN0dWFsbHkgZG8gbm90 IHJlbWVtYmVyIGFueXRoaW5nICh0aGV5IGFyZSBzdXBwb3NlZCB0byBiZSBzdGF0ZWxlc3MpLiAm bmJzcDtJIHdvbmRlciBpZiB0aGlzIHRleHQgY2FuIGJlIGNsZWFuZWQgdXAgLS0gc2VydmVycyBu ZWVkIHRvICZxdW90O3JlbWVtYmVyJnF1b3Q7IHdoaWxlDQogcHJvY2Vzc2luZyBhIHBhY2tldDsg KGNhc2NhZGluZykgcmVsYXkncyBuZWVkIHRvIGFkZCB0aGlzIHBvcnQgaW5mb3JtYXRpb24gdG8g dGhlIFJlbGF5LUZvcncgcGFja2V0cy48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCk9rLCBob3cgYWJvdXQgdGhp cz88L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i bWFyZ2luOiAwcHg7IGZvbnQtc2l6ZTogMTRweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1m YW1pbHk6IE1lbmxvOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7IiBjbGFz cz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBuby1jb21tb24tbGln YXR1cmVzIiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7VGhpcyBleHRlbnNpb24gcmVxdWlyZXM8L3Nw YW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1zaXplOiAxNHB4OyBsaW5l LWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogTWVubG87IGJhY2tncm91bmQtY29sb3I6IHJn YigyNTUsIDI1NSwgMjU1KTsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtdmFyaWFudC1s aWdhdHVyZXM6IG5vLWNvbW1vbi1saWdhdHVyZXMiIGNsYXNzPSIiPiZuYnNwOyZuYnNwOyBhIERI Q1Agc2VydmVyIHRvIHJlbWVtYmVyIHRoZSBpbmJvdW5kIHBhY2tldCdzIFVEUCBwb3J0IG51bWJl ciBhbG9uZzwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXNpemU6 IDE0cHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiBNZW5sbzsgYmFja2dyb3Vu ZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9u dC12YXJpYW50LWxpZ2F0dXJlczogbm8tY29tbW9uLWxpZ2F0dXJlcyIgY2xhc3M9IiI+Jm5ic3A7 Jm5ic3A7IHdpdGggdGhlIElQL0lQdjYgYWRkcmVzcy4mbmJzcDsgVGhlIERIQ1Agc2VydmVyIHdo ZW4gc2VuZGluZyBiYWNrIHJlcGxpZXM8L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46 IDBweDsgZm9udC1zaXplOiAxNHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTog TWVubG87IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsiIGNsYXNzPSIiPg0K PHNwYW4gc3R5bGU9ImZvbnQtdmFyaWFudC1saWdhdHVyZXM6IG5vLWNvbW1vbi1saWdhdHVyZXMi IGNsYXNzPSIiPiZuYnNwOyZuYnNwOyBNVVNUIHVzZSB0aGUgVURQIHBvcnQgbnVtYmVyIHRoYXQg dGhlIGluY29taW5nIHJlbGF5IGFnZW50IHVzZXM8L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJt YXJnaW46IDBweDsgZm9udC1zaXplOiAxNHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZh bWlseTogTWVubG87IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsiIGNsYXNz PSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtdmFyaWFudC1saWdhdHVyZXM6IG5vLWNvbW1vbi1saWdh dHVyZXMiIGNsYXNzPSIiPiZuYnNwOyZuYnNwOyBpbnN0ZWFkIG9mIHRoZSBmaXhlZCBESENQIHBv cnQgbnVtYmVyLiZuYnNwOyBJbiB0aGUgY2FzZSBvZiBJUHY2IGNhc2NhZGVkPC9zcGFuPjwvZGl2 Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtc2l6ZTogMTRweDsgbGluZS1oZWlnaHQ6 IG5vcm1hbDsgZm9udC1mYW1pbHk6IE1lbmxvOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAy NTUsIDI1NSk7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXZhcmlhbnQtbGlnYXR1cmVz OiBuby1jb21tb24tbGlnYXR1cmVzIiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsgcmVsYXkgYWdlbnRz IFtSRkMzMzE1XSwgdGhlIHVwc3RyZWFtIHJlbGF5IGFnZW50IG5lZWRzIHRvIHVzZSB0aGU8L3Nw YW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1zaXplOiAxNHB4OyBsaW5l LWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogTWVubG87IGJhY2tncm91bmQtY29sb3I6IHJn YigyNTUsIDI1NSwgMjU1KTsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtdmFyaWFudC1s aWdhdHVyZXM6IG5vLWNvbW1vbi1saWdhdHVyZXMiIGNsYXNzPSIiPiZuYnNwOyZuYnNwOyAmcXVv dDtSZWxheSBTb3VyY2UgUG9ydCBPcHRpb24mcXVvdDsgdG8gcmVjb3JkIHRoZSBkb3duc3RyZWFt IHNvdXJjZSBwb3J0IGFuZDwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMHB4OyBm b250LXNpemU6IDE0cHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiBNZW5sbzsg YmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyIgY2xhc3M9IiI+DQo8c3BhbiBz dHlsZT0iZm9udC12YXJpYW50LWxpZ2F0dXJlczogbm8tY29tbW9uLWxpZ2F0dXJlcyIgY2xhc3M9 IiI+Jm5ic3A7Jm5ic3A7IGl0IE1VU1QgdXNlIHRoaXMgcmVjb3JkZWQgcG9ydCBudW1iZXIgaW5z dGVhZCBvZiB0aGUgZml4ZWQgREhDUCBwb3J0PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFy Z2luOiAwcHg7IGZvbnQtc2l6ZTogMTRweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1p bHk6IE1lbmxvOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7IiBjbGFzcz0i Ij4NCjxzcGFuIHN0eWxlPSJmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBuby1jb21tb24tbGlnYXR1 cmVzIiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsgbnVtYmVyIHdoZW4gcmVwbGF5aW5nIHRoZSByZXBs eSBtZXNzYWdlcy48L3NwYW4+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250 LXZhcmlhbnQtbGlnYXR1cmVzOiBuby1jb21tb24tbGlnYXR1cmVzIiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+DQo8L3NwYW4+PC9kaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4N CjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjQuIFNlY3Rpb24g NC4yIC0gdGhlcmUgYXJlIHNldmVyYWwgcGxhY2VzIHdoZXJlICZxdW90O25vbi1ESENQIFVEUCBw b3J0JnF1b3Q7IGlzIHVzZWQuIEkgd29uZGVyIHdoZXRoZXIgd2UgY291bGQganVzdCBzYXkgJnF1 b3Q7cG9ydCBvdGhlciB0aGFuIDU0Ny4gSSBrbm93IHRoaXMgaXMgaW4gdGhlIHRlcm1pbm9sb2d5 LCBidXQgaW4gdGhpcyBjYXNlIGl0IGlzIERIQ1B2NiBzcGVjaWZpYyB0ZXh0IHNvIHdoeSBtYWtl IHNvbWVvbmUgbG9vayBpdCB1cD8gSSBndWVzcyB5b3UNCiBjb3VsZCB1c2U6ICZxdW90O25vbi1E SENQIFVEUCBQb3J0IChub3QgNTQ3KSZxdW90OyBvciBzaW1pbGFyIGlmIHlvdSB3YW50ZWQgdG8g a2VlcCB0aGUgcmVmZXJlbmNlIHRvIHRoYXQgdGVybT88YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9 IiI+DQpUaGlzIHNhbWUgY29tbWVudCBhcHBsaWVzIHRvIHNlY3Rpb24gNS4xIGFuZCA1LjIgKHRo b3VnaCBpbiA1LjEgcG9ydCA2NyBhcHBsaWVzKS4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0i Ij4NCkluIHRoZSBlbmQsIGl0IG1heSBiZSB0aGF0IHRoZSBkZWZpbml0aW9uIGlzbid0IHRoYXQg dXNlZnVsIGFuZCBwZXJoYXBzIHRoYXQgd291bGQgZXZlbiBiZSBiZXR0ZXIgdG8gcmVtb3ZlIGl0 IGFuZCBqdXN0IHVzZSB0aGUgZXhwbGljaXQgcG9ydCBudW1iZXJzPyBJIHRoaW5rIHRoaXMgd291 bGQgaGVscCByZWFkYWJpbGl0eS4gQnV0IHJldmlldyBhbmQgY29uc2lkZXIuPGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9k aXY+DQpJIHN0aWxsIHRoaW5rIGl04oCZcyBqdXN0IHRvbyBtYW55IHBsYWNlcyB3ZSBhcmUgdGFs a2luZyBhYm91dCBib3RoIElQdjQgYW5kIElQdjYgYW5kPC9kaXY+DQo8ZGl2PmhhdmUgdG8gc2F5 IGJvdGggb2YgdGhlIHBvcnRzIGV4cGxpY2l0bHkuIEJ1dCB0aG9zZSBzb21lIG9mIHRoZSBwbGFj ZXMgaXMgb25seSBmb3I8L2Rpdj4NCjxkaXY+SVB2NCBvciBvbmx5IGZvciBJUHY2LCBJ4oCZbGwg ZG8gd2hhdCB5b3Ugc3VnZ2VzdGVkLCB0byB1c2UgdGhlIChub3QgNjcpIG9yIHRvIHVzZTwvZGl2 Pg0KPGRpdj50aGUgKG5vdCA1NDcpIGluIHRob3NlIHBsYWNlcy48L2Rpdj4NCjxkaXY+PGJyIGNs YXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIi Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo1LiBTZWN0aW9uIDcgKElBTkEpLiBQbGVh c2UgbG9vayBhdCBhIGRvY3VtZW50IHN1Y2ggYXMgPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL3JmYzc4Mzkjc2VjdGlvbi04IiBjbGFzcz0iIj4NCmh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9yZmM3ODM5I3NlY3Rpb24tODwvYT4uIFRvIGF2b2lkIGNvbmZ1c2lvbiwgd2Ug aGF2ZSBwdXQgdGhlIFVSTCBvZiB0aGUgdGFibGVzIGluIHRoZSBJQU5BIGNvbnNpZGVyYXRpb25z LiBUaGlzIHByYWN0aWNlIHNob3VsZCBiZSBmb2xsb3dlZCBoZXJlIHRvIHRoYXQgaXQgaXMgY2xl YXIgdG8gSUFOQSBleGFjdGx5IHdoaWNoIHNldCBvZiB0YWJsZXMgdG8gdXBkYXRlLjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KT2ssIHN1cmUuIEJ1dCB0aGUgZXhhbXBsZSB5b3Ugc2l0ZWQsIGl0IGFscmVhZHkg aGFkIHRoZSBJQU5BIG51bWJlciBhc3NpZ25lZC48L2Rpdj4NCjxkaXY+Rm9yIHRoaXMgb25lLCB3 ZSBoYXZlIG5vdCBzbyBmYXIsIGhvdyBhYm91dCB0aGVzZSBzZW50ZW5jZXM/PC9kaXY+DQo8ZGl2 PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMHB4OyBm b250LXNpemU6IDE0cHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiBNZW5sbzsg YmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyIgY2xhc3M9IiI+DQo8c3BhbiBz dHlsZT0iZm9udC12YXJpYW50LWxpZ2F0dXJlczogbm8tY29tbW9uLWxpZ2F0dXJlcyIgY2xhc3M9 IiI+Jm5ic3A7ICZuYnNwO0EgbmV3IHN1Yi1vcHRpb24sIERIQ1B2NCBSZWxheSBTb3VyY2UgUG9y dCwgaXMgZGVmaW5lZCBpbiB0aGlzPC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAw cHg7IGZvbnQtc2l6ZTogMTRweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6IE1l bmxvOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7IiBjbGFzcz0iIj4NCjxz cGFuIHN0eWxlPSJmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBuby1jb21tb24tbGlnYXR1cmVzIiBj bGFzcz0iIj4mbmJzcDsmbmJzcDsgZG9jdW1lbnQgd2l0aGluIHRoZSBJUHY0IFJlbGF5IEFnZW50 IEluZm9ybWF0aW9uIE9wdGlvbi4mbmJzcDsgSXQgbmVlZHMgdG88L3NwYW4+PC9kaXY+DQo8ZGl2 IHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1zaXplOiAxNHB4OyBsaW5lLWhlaWdodDogbm9ybWFs OyBmb250LWZhbWlseTogTWVubG87IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1 KTsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtdmFyaWFudC1saWdhdHVyZXM6IG5vLWNv bW1vbi1saWdhdHVyZXMiIGNsYXNzPSIiPiZuYnNwOyZuYnNwOyBiZSBhc3NpZ25lZCBieSBJQU5B IGluIHRoZSAmcXVvdDtESENQIFJlbGF5IEFnZW50IFN1Yi1PcHRpb24gQ29kZXMmcXVvdDs8L3Nw YW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1zaXplOiAxNHB4OyBsaW5l LWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogTWVubG87IGJhY2tncm91bmQtY29sb3I6IHJn YigyNTUsIDI1NSwgMjU1KTsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtdmFyaWFudC1s aWdhdHVyZXM6IG5vLWNvbW1vbi1saWdhdHVyZXMiIGNsYXNzPSIiPiZuYnNwOyZuYnNwOyByZWdp c3RyeSwgPGEgaHJlZj0iaHR0cDovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9ib290cC1kaGNw LXBhcmFtZXRlcnMiIGNsYXNzPSIiPg0KaHR0cDovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9i b290cC1kaGNwLXBhcmFtZXRlcnM8L2E+IGFzPC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFy Z2luOiAwcHg7IGZvbnQtc2l6ZTogMTRweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1p bHk6IE1lbmxvOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7IiBjbGFzcz0i Ij4NCjxzcGFuIHN0eWxlPSJmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBuby1jb21tb24tbGlnYXR1 cmVzIiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsgc3BlY2lmaWVkIGluIFtSRkMzMDQ2XS48L3NwYW4+ PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1zaXplOiAxNHB4OyBsaW5lLWhl aWdodDogbm9ybWFsOyBmb250LWZhbWlseTogTWVubG87IGJhY2tncm91bmQtY29sb3I6IHJnYigy NTUsIDI1NSwgMjU1KTsgbWluLWhlaWdodDogMTZweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9 ImZvbnQtdmFyaWFudC1saWdhdHVyZXM6IG5vLWNvbW1vbi1saWdhdHVyZXMiIGNsYXNzPSIiPjwv c3Bhbj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250 LXNpemU6IDE0cHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiBNZW5sbzsgYmFj a2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHls ZT0iZm9udC12YXJpYW50LWxpZ2F0dXJlczogbm8tY29tbW9uLWxpZ2F0dXJlcyIgY2xhc3M9IiI+ Jm5ic3A7Jm5ic3A7IEEgbmV3IG9wdGlvbiwgREhDUHY2IFJlbGF5IFNvdXJjZSBQb3J0LCBpcyBk ZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQ8L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46 IDBweDsgZm9udC1zaXplOiAxNHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTog TWVubG87IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsiIGNsYXNzPSIiPg0K PHNwYW4gc3R5bGU9ImZvbnQtdmFyaWFudC1saWdhdHVyZXM6IG5vLWNvbW1vbi1saWdhdHVyZXMi IGNsYXNzPSIiPiZuYnNwOyZuYnNwOyBmb3IgREhDUHY2IGFuZCBpdCBuZWVkcyB0byBiZSBhc3Np Z25lZCBieSBJQU5BIGZvciB0aGUgREhDUHY2IG9wdGlvbjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5 bGU9Im1hcmdpbjogMHB4OyBmb250LXNpemU6IDE0cHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZv bnQtZmFtaWx5OiBNZW5sbzsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyIg Y2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC12YXJpYW50LWxpZ2F0dXJlczogbm8tY29tbW9u LWxpZ2F0dXJlcyIgY2xhc3M9IiI+Jm5ic3A7Jm5ic3A7IGNvZGUsIGluIHRoZSAmcXVvdDtPcHRp b24gQ29kZXMmcXVvdDsgcmVnaXN0cnkgZm9yIERIQ1B2Niw8L3NwYW4+PC9kaXY+DQo8ZGl2IHN0 eWxlPSJtYXJnaW46IDBweDsgZm9udC1zaXplOiAxNHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBm b250LWZhbWlseTogTWVubG87IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsi IGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtdmFyaWFudC1saWdhdHVyZXM6IG5vLWNvbW1v bi1saWdhdHVyZXMiIGNsYXNzPSIiPiZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwOi8vd3d3Lmlh bmEub3JnL2Fzc2lnbm1lbnRzL2RoY3B2Ni1wYXJhbWV0ZXJzIiBjbGFzcz0iIj4NCmh0dHA6Ly93 d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvZGhjcHY2LXBhcmFtZXRlcnM8L2E+IGFzIHNwZWNpZmll ZCBpbjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXNpemU6IDE0 cHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiBNZW5sbzsgYmFja2dyb3VuZC1j b2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC12 YXJpYW50LWxpZ2F0dXJlczogbm8tY29tbW9uLWxpZ2F0dXJlcyIgY2xhc3M9IiI+Jm5ic3A7Jm5i c3A7IFtSRkMzMzE1XS48L3NwYW4+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJm b250LXZhcmlhbnQtbGlnYXR1cmVzOiBuby1jb21tb24tbGlnYXR1cmVzIiBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+DQo8L3NwYW4+PC9kaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0i Ij4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjYuIFNlY3Rp b24gOCAoU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMpLiBUaGlzIHNob3VsZCByZWZlcmVuY2UgdGhl IHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIG9mIFJGQyAyMTMxIGFuZCAzMzE1LjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxk aXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NClRoZSB0ZXh0IHRoYXQg aXMgdGhlcmUgaXMgbW9yZSBvZiBhbiBvcGVyYXRpb25hbCBjb25zaWRlcmF0aW9uIHJhdGhlciB0 aGFuIHdoYXQgc2VjdXJpdHkgaXNzdWVzIHRoaXMgbmV3IHdvcmsgbWlnaHQgZXhwb3NlIC0gd2hp Y2ggbWF5IGJlIG5vdGhpbmcgbmV3IG92ZXIgMjEzMS8zMzE1LiBCdXQgcG9pbnRpbmcgb3V0IHRo YXQgZmlyZXdhbGxzIG5lZWQgdG8gYmUgYWRqdXN0ZWQgaXMgYSBnb29kIHRoaW5nLjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KT2ssIEkgYWRkZWQgdGhpcyBwYXJhZ3JhcGggaW4gdGhlIGZyb250LCBhbmQgYSDi gJhBbHRob3VnaOKAmSB0byBzdGFydCB0aGUgb3JpZ2luYWwgc2VudGVuY2U6PC9kaXY+DQo8ZGl2 PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMHB4OyBm b250LXNpemU6IDE0cHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiBNZW5sbzsg YmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyIgY2xhc3M9IiI+DQo8c3BhbiBz dHlsZT0iZm9udC12YXJpYW50LWxpZ2F0dXJlczogbm8tY29tbW9uLWxpZ2F0dXJlcyIgY2xhc3M9 IiI+Jm5ic3A7ICZuYnNwO1tSRkMzMTE4XSBhbmQgW1JGQzMzMTVdIGRlc2NyaWJlZCBtYW55IG9m IHRoZSB0aHJlYXRzIGluIHVzaW5nIERIQ1AuPC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFy Z2luOiAwcHg7IGZvbnQtc2l6ZTogMTRweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1p bHk6IE1lbmxvOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7IiBjbGFzcz0i Ij4NCjxzcGFuIHN0eWxlPSJmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBuby1jb21tb24tbGlnYXR1 cmVzIiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsgVGhpcyBleHRlbnNpb24gZG9lcyBub3QgcmFpc2Ug YWRkaXRpb24gc2VjdXJpdHkgaXNzdWVzLjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdp bjogMHB4OyBmb250LXNpemU6IDE0cHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5 OiBNZW5sbzsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyBtaW4taGVpZ2h0 OiAxNnB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC12YXJpYW50LWxpZ2F0dXJlczog bm8tY29tbW9uLWxpZ2F0dXJlcyIgY2xhc3M9IiI+PC9zcGFuPjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtc2l6ZTogMTRweDsgbGluZS1oZWlnaHQ6 IG5vcm1hbDsgZm9udC1mYW1pbHk6IE1lbmxvOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAy NTUsIDI1NSk7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXZhcmlhbnQtbGlnYXR1cmVz OiBuby1jb21tb24tbGlnYXR1cmVzIiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsgQWx0aG91Z2ggaWYg dGhlIG5ldHdvcmsgdXNlcyBmaXJld2FsbCB0byBibG9jayBvciBhbGxvdyBESENQIHBhY2tldHM8 L3NwYW4+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXZhcmlhbnQtbGln YXR1cmVzOiBuby1jb21tb24tbGlnYXR1cmVzIiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICZuYnNw O+KApi48L3NwYW4+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXZhcmlh bnQtbGlnYXR1cmVzOiBuby1jb21tb24tbGlnYXR1cmVzIiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+ DQo8L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+DQo3LiBTZWN0aW9uIDEwIChEb2N1bWVudCBDaGFuZ2UgTG9nKS4gVXN1YWxseSBh biBSRkMgRWRpdG9yIG5vdGUgaXMgYWRkZWQgdG8gcmVxdWVzdCB0aGF0IHRoZXkgUkVNT1ZFIHRo aXMgbWF0ZXJpYWwgaW4gdGhlIFJGQyBwdWJsaWNhdGlvbiBwcm9jZXNzLjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KU3VyZS4gV2lsbCByZW1vdmUgdGhlc2UgaW4gdGhlIG5leHQgdmVyc2lvbi48L2Rpdj4NCjxk aXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PnRoYW5rcy48L2Rpdj4NCjxkaXY+LSBOYWlt aW5nPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNs YXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KLSBC ZXJuaWU8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLTxiciBjbGFzcz0iIj4NCkZyb206IGRoY3dnIFs8YSBocmVmPSJtYWlsdG86ZGhjd2ctYm91 bmNlc0BpZXRmLm9yZyIgY2xhc3M9IiI+bWFpbHRvOmRoY3dnLWJvdW5jZXNAaWV0Zi5vcmc8L2E+ XSBPbiBCZWhhbGYgT2YgVG9tZWsgTXJ1Z2Fsc2tpPGJyIGNsYXNzPSIiPg0KU2VudDogV2VkbmVz ZGF5LCBBcHJpbCAwNSwgMjAxNyAzOjI2IFBNPGJyIGNsYXNzPSIiPg0KVG86IGRoY3dnICZsdDs8 YSBocmVmPSJtYWlsdG86ZGhjd2dAaWV0Zi5vcmciIGNsYXNzPSIiPmRoY3dnQGlldGYub3JnPC9h PiZndDs8YnIgY2xhc3M9IiI+DQpTdWJqZWN0OiBbZGhjd2ddIFdHTEMgb24gZHJhZnQtaWV0Zi1k aGMtcmVsYXktcG9ydC0wMiAtIHJlc3BvbmQgYnkgQXByIDI2PGJyIGNsYXNzPSIiPg0KPGJyIGNs YXNzPSIiPg0KSGksPGJyIGNsYXNzPSIiPg0KZHJhZnQtaWV0Zi1kaGMtcmVsYXktcG9ydC0wMiBk ZWZpbmVzIGEgc21hbGwgZXh0ZW5zaW9uIHRvIHRoZSBESENQdjQgYW5kPGJyIGNsYXNzPSIiPg0K REhDUHY2IHByb3RvY29scyB0aGF0IGFsbG93cyB1c2FnZSBvZiBvdGhlciBVRFAgc291cmNlIHBv cnRzIHRvIGJlIHVzZWQgYnkgcmVsYXkgYWdlbnRzLiBBdXRob3JzIGJlbGlldmUgdGhpcyBkb2N1 bWVudCBpcyByZWFkeS4gVGhlIGRpc2N1c3Npb25zIHNvIGZhciBvbiB0aGUgbWFpbGluZyBsaXN0 IHdlcmUgYSBiaXQgbW9kZXN0LCBidXQgdGhlIGNvbmNlcHQgaXMgc2ltcGxlLCB0aGUgZHJhZnQg d2FzIHByZXNlbnRlZCB0d2ljZSAoaW4gQnVlbm9zDQogQWlyZXMgYW5kIEJlcmxpbikgYW5kIGVu am95ZWQgYSBmYXZvdXJhYmxlIHJlY2VwdGlvbiBpbiB0aGUgcm9vbS4gQXMgc3VjaCwgd2UgYW5u b3VuY2UgYSB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBvbiB0aGlzIGRvY3VtZW50LiBQbGVhc2Ug cmV2aWV3IGFuZCBjb21tZW50LjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClRoaXMgaXMg YSB2ZXJ5IHNob3J0IGRvY3VtZW50LiBJdCBoYXMgYXJvdW5kIDYgcGFnZXMgb2YgYWN0dWFsIHRl eHQuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KTWFueSBXRyBwYXJ0aWNpcGFudHMgbWF5 IGNlbGVicmF0ZSB1cGNvbWluZyBFYXN0ZXIgYW5kIHRha2Ugc29tZSBkYXlzIG9mZiwgdGhlcmVm b3JlIHRoaXMgV0dMQyBpcyBhIGJpdCBsb25nZXIgdGhhbiB0eXBpY2FsIHR3byB3ZWVrcy48YnIg Y2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpUaXRsZTogR2VuZXJhbGl6ZWQgVURQIFNvdXJjZSBQ b3J0IGZvciBESENQIFJlbGF5PGJyIGNsYXNzPSIiPg0KQXV0aG9yczogTi4gU2hlbiwgRS4gQ2hl bjxiciBjbGFzcz0iIj4NCkZpbGVuYW1lOiBkcmFmdC1pZXRmLWRoYy1yZWxheS1wb3J0LTAyPGJy IGNsYXNzPSIiPg0KUGFnZXM6IDEwIChhcm91bmQgNiBvZiBhY3R1YWwgdGVjaG5pY2FsIHRleHQp PGJyIGNsYXNzPSIiPg0KRGF0ZTogMjAxNy0wMi0yODxiciBjbGFzcz0iIj4NCkxpbms6IDxhIGhy ZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWRoYy1yZWxheS1wb3J0 LTAyIiBjbGFzcz0iIj4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWRo Yy1yZWxheS1wb3J0LTAyPC9hPjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClJlc3BvbnNl cyBieSBBcHJpbCAyNnRoIGFyZSBhcHByZWNpYXRlZC48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9 IiI+DQpUaGFua3MsPGJyIGNsYXNzPSIiPg0KQmVybmllIGFuZCBUb21lazxiciBjbGFzcz0iIj4N CjxiciBjbGFzcz0iIj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyIGNsYXNzPSIiPg0KZGhjd2cgbWFpbGluZyBsaXN0PGJyIGNsYXNzPSIiPg0KPGEg aHJlZj0ibWFpbHRvOmRoY3dnQGlldGYub3JnIiBjbGFzcz0iIj5kaGN3Z0BpZXRmLm9yZzwvYT48 YnIgY2xhc3M9IiI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RoY3dn PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_A7E53EB44CBB4E32BDB4F9C7CBDF0CB2ciscocom_-- From nobody Tue Apr 25 03:34:02 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 44F5C12EB4F; Tue, 25 Apr 2017 03:34:01 -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 L7XThuye0DPH; Tue, 25 Apr 2017 03:33:58 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC35512EB4C; Tue, 25 Apr 2017 03:33:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26198; q=dns/txt; s=iport; t=1493116437; x=1494326037; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=FFa0n8b908CCYu8FSNFgDDIE3qgNNdJgn2CGq7ky41A=; b=SnjuUH/V9c1t2c2x/9ywpPFXeZ1/K5FeC2fkqK2+S8PE3khJWMElsDHe 10TOV6MmbTtgK31RFKvUCDg6NXmAvAErOm7SY+DZuiDaqDDvMU1mPpiZy wPcu1admZWIkVimxjr66CG8SwYQZLpg5VOuLpOc0sVugGZ2srhZNsoFns 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DQAAD0JP9Y/5JdJa1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm5mYXoSjXyRbpVlgg8hAQqFeAKEDz8YAQIBAQEBAQEBayiFFQE?= =?us-ascii?q?BAQEDAQFsCwwEAgEIEQMBAQEhBwcnCxQJCAIEDgUJihMOrF+LGgEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAR2IMCuCboE8gwU2gxSCMQWWSYZ4AYcWi2+CAIUziGeBPYh?= =?us-ascii?q?viykBHziBBmMVGioRAYRjgXN1iTYBAQE?= X-IronPort-AV: E=Sophos;i="5.37,249,1488844800"; d="scan'208,217";a="235123095" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Apr 2017 10:33:56 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v3PAXupp017673 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 25 Apr 2017 10:33:56 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, 25 Apr 2017 05:33:56 -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, 25 Apr 2017 05:33:55 -0500 From: "Bernie Volz (volz)" To: "Naiming Shen (naiming)" CC: Tomek Mrugalski , dhcwg , "draft-ietf-dhc-relay-port@ietf.org" Thread-Topic: [dhcwg] WGLC on draft-ietf-dhc-relay-port-02 - respond by Apr 26 Thread-Index: AQHSrkJ4jGafpAaCIk+/kF5HBW5FkaHRyhDAgAQelgCAABm2Gw== Date: Tue, 25 Apr 2017 10:33:55 +0000 Message-ID: References: <4cb9bdab-f3a2-a9d0-1056-302b5ecdeae7@gmail.com> <7ba7b94f31bb41dbb404ef1c33026431@XCH-ALN-003.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_A699CC6A7B19493A857FB48E47A6540Aciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-relay-port-02 - respond by Apr 26 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, 25 Apr 2017 10:34:01 -0000 --_000_A699CC6A7B19493A857FB48E47A6540Aciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Sounds fine. - Bernie (from iPad) On Apr 25, 2017, at 12:02 AM, Naiming Shen (naiming) > wrote: Hi Bernie, Thanks for the detailed comments. Replies inline: On Apr 22, 2017, at 11:31 AM, Bernie Volz (volz) > wrote: Hi: I reviewed the 04 version. This document could use some updates. Below are my comments. I think these = should be addressed before the document advances, but otherwise I think it = should be mostly ready to move forward. 1. General - I would highly recommend this draft adopt and document the "DH= CP" terminology as follows: DHCP means DHCPv4 and DHCPv6. DHCPv4 means the Dynamic Host Configuration Protocol for IPv4 as documente= d in RFC2131. DHCPv6 means the Dynamic Host Configuration Protocol for IPv6 as documented= in RFC3315. And make use of these correctly. The document currently uses DHCP to mean DHCPv4 or both DHCPv4 and DHCPv6. Similarly, I 'd suggest using IPv4 and IPv6 (or IP when being general and a= pply to both or either). Sure. Makes sense. Will go through those and not to mix the DHCP and DHCPv4= usage. Some of the places, just IPv4 and IPv6 is fine. 2. Abstract - As currently written I don't see why this RFC is needed. Rela= y source ports in 2131/3315 are meaningless and the abstract "allows any va= lid number" which is already the case. It needs to be document that this pr= ovides the means for the relay to receive packets from a server or (upstrea= m) relay on any port, not just the default port. Ok, what about this? This document proposes an extension to the DHCP protocols that allows a relay agent to receive packets from a server or an upstream relay agent on any UDP port, not just the default port 67 for IPv4 or default port 547 for IPv6. 3. Introduction (1) - The "to remember inbound" may cause some concern with= regards to relay's -- since they actually do not remember anything (they a= re supposed to be stateless). I wonder if this text can be cleaned up -- s= ervers need to "remember" while processing a packet; (cascading) relay's ne= ed to add this port information to the Relay-Forw packets. Ok, how about this? This extension requires a DHCP server to remember the inbound packet's UDP port number along with the IP/IPv6 address. The DHCP server when sending back replies MUST use the UDP port number that the incoming relay agent uses instead of the fixed DHCP port number. In the case of IPv6 cascaded relay agents [RFC3315], the upstream relay agent needs to use the "Relay Source Port Option" to record the downstream source port and it MUST use this recorded port number instead of the fixed DHCP port number when replaying the reply messages. 4. Section 4.2 - there are several places where "non-DHCP UDP port" is used= . I wonder whether we could just say "port other than 547. I know this is i= n the terminology, but in this case it is DHCPv6 specific text so why make = someone look it up? I guess you could use: "non-DHCP UDP Port (not 547)" or= similar if you wanted to keep the reference to that term? This same comment applies to section 5.1 and 5.2 (though in 5.1 port 67 app= lies). In the end, it may be that the definition isn't that useful and perhaps tha= t would even be better to remove it and just use the explicit port numbers?= I think this would help readability. But review and consider. I still think it=92s just too many places we are talking about both IPv4 an= d IPv6 and have to say both of the ports explicitly. But those some of the places is o= nly for IPv4 or only for IPv6, I=92ll do what you suggested, to use the (not 67) or= to use the (not 547) in those places. 5. Section 7 (IANA). Please look at a document such as https://tools.ietf.o= rg/html/rfc7839#section-8. To avoid confusion, we have put the URL of the t= ables in the IANA considerations. This practice should be followed here to = that it is clear to IANA exactly which set of tables to update. Ok, sure. But the example you sited, it already had the IANA number assigne= d. For this one, we have not so far, how about these sentences? A new sub-option, DHCPv4 Relay Source Port, is defined in this document within the IPv4 Relay Agent Information Option. It needs to be assigned by IANA in the "DHCP Relay Agent Sub-Option Codes" registry, http://www.iana.org/assignments/bootp-dhcp-parameters as specified in [RFC3046]. A new option, DHCPv6 Relay Source Port, is defined in this document for DHCPv6 and it needs to be assigned by IANA for the DHCPv6 option code, in the "Option Codes" registry for DHCPv6, http://www.iana.org/assignments/dhcpv6-parameters as specified in [RFC3315]. 6. Section 8 (Security Considerations). This should reference the security = considerations of RFC 2131 and 3315. The text that is there is more of an operational consideration rather than = what security issues this new work might expose - which may be nothing new = over 2131/3315. But pointing out that firewalls need to be adjusted is a go= od thing. Ok, I added this paragraph in the front, and a =91Although=92 to start the = original sentence: [RFC3118] and [RFC3315] described many of the threats in using DHCP. This extension does not raise addition security issues. Although if the network uses firewall to block or allow DHCP packets =85. 7. Section 10 (Document Change Log). Usually an RFC Editor note is added to= request that they REMOVE this material in the RFC publication process. Sure. Will remove these in the next version. thanks. - Naiming - Bernie -----Original Message----- From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Tomek Mrugalski Sent: Wednesday, April 05, 2017 3:26 PM To: dhcwg > Subject: [dhcwg] WGLC on draft-ietf-dhc-relay-port-02 - respond by Apr 26 Hi, draft-ietf-dhc-relay-port-02 defines a small extension to the DHCPv4 and DHCPv6 protocols that allows usage of other UDP source ports to be used by = relay agents. Authors believe this document is ready. The discussions so fa= r on the mailing list were a bit modest, but the concept is simple, the dra= ft was presented twice (in Buenos Aires and Berlin) and enjoyed a favourabl= e reception in the room. As such, we announce a working group last call on = this document. Please review and comment. This is a very short document. It has around 6 pages of actual text. Many WG participants may celebrate upcoming Easter and take some days off, = therefore this WGLC is a bit longer than typical two weeks. Title: Generalized UDP Source Port for DHCP Relay Authors: N. Shen, E. Chen Filename: draft-ietf-dhc-relay-port-02 Pages: 10 (around 6 of actual technical text) Date: 2017-02-28 Link: https://tools.ietf.org/html/draft-ietf-dhc-relay-port-02 Responses by April 26th are appreciated. Thanks, Bernie and Tomek _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg --_000_A699CC6A7B19493A857FB48E47A6540Aciscocom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Sounds fine.

- Bernie (from iPad)

Hi Bernie,

Thanks for the detailed comments. Replies inline:


On Apr 22, 2017, at 11:31 AM, Bernie Volz (volz) <volz@cisco.com> wrote:

Hi:

I reviewed the 04 version.

This document could use some updates. Below are my comments. I think these = should be addressed before the document advances, but otherwise I think it = should be mostly ready to move forward.

1. General - I would highly recommend this draft adopt and document the &qu= ot;DHCP" terminology as follows:
DHCP means = DHCPv4 and DHCPv6.
DHCPv4 mean= s the Dynamic Host Configuration  Protocol for IPv4 as documented in R= FC2131.
DHCPv6 mean= s the Dynamic Host Configuration Protocol for IPv6 as documented in RFC3315= .
And make use of these correctly.

The document currently uses DHCP to mean DHCPv4 or both DHCPv4 and DHCPv6.<= br class=3D"">
Similarly, I 'd suggest using IPv4 and IPv6 (or IP when being general and a= pply to both or either).

Sure. Makes sense. Will go through those and not to mix the DHCP and DHCPv4= usage.
Some of the places, just IPv4 and IPv6 is fine.


2. Abstract - As currently written I don't see why this RFC is needed. Rela= y source ports in 2131/3315 are meaningless and the abstract "allows a= ny valid number" which is already the case. It needs to be document th= at this provides the means for the relay to receive packets from a server or (upstream) relay on any port, not just th= e default port.

Ok, what about this?

&nbs= p;  This document proposes an extension to the DHCP protocols that all= ows
&nbs= p;  a relay agent to receive packets from a server or an upstream rela= y
&nbs= p;  agent on any UDP port, not just the default port 67 for IPv4 or
&nbs= p;  default port 547 for IPv6.


3. Introduction (1) - The "to remember inbound" may cause some co= ncern with regards to relay's -- since they actually do not remember anythi= ng (they are supposed to be stateless).  I wonder if this text can be = cleaned up -- servers need to "remember" while processing a packet; (cascading) relay's need to add this port information= to the Relay-Forw packets.

Ok, how about this?

&nbs= p;  This extension requires
&nbs= p;  a DHCP server to remember the inbound packet's UDP port number alo= ng
&nbs= p;  with the IP/IPv6 address.  The DHCP server when sending back = replies
&nbs= p;  MUST use the UDP port number that the incoming relay agent uses
&nbs= p;  instead of the fixed DHCP port number.  In the case of IPv6 c= ascaded
&nbs= p;  relay agents [RFC3315], the upstream relay agent needs to use the<= /span>
&nbs= p;  "Relay Source Port Option" to record the downstream sour= ce port and
&nbs= p;  it MUST use this recorded port number instead of the fixed DHCP po= rt
&nbs= p;  number when replaying the reply messages.


4. Section 4.2 - there are several places where "non-DHCP UDP port&quo= t; is used. I wonder whether we could just say "port other than 547. I= know this is in the terminology, but in this case it is DHCPv6 specific te= xt so why make someone look it up? I guess you could use: "non-DHCP UDP Port (not 547)" or similar if you wante= d to keep the reference to that term?

This same comment applies to section 5.1 and 5.2 (though in 5.1 port 67 app= lies).

In the end, it may be that the definition isn't that useful and perhaps tha= t would even be better to remove it and just use the explicit port numbers?= I think this would help readability. But review and consider.

I still think it=92s just too many places we are talking about both IPv4 an= d IPv6 and
have to say both of the ports explicitly. But those some of the places= is only for
IPv4 or only for IPv6, I=92ll do what you suggested, to use the (not 6= 7) or to use
the (not 547) in those places.


5. Section 7 (IANA). Please look at a document such as https://tools.ietf.org/html/rfc7839#section-8. To avoid confusion, we h= ave put the URL of the tables in the IANA considerations. This practice sho= uld be followed here to that it is clear to IANA exactly which set of table= s to update.

Ok, sure. But the example you sited, it already had the IANA number assigne= d.
For this one, we have not so far, how about these sentences?

&nbs= p;  A new sub-option, DHCPv4 Relay Source Port, is defined in this
&nbs= p;  document within the IPv4 Relay Agent Information Option.  It = needs to
&nbs= p;  be assigned by IANA in the "DHCP Relay Agent Sub-Option Codes= "
&nbs= p;  registry, http://www.iana.org/assignments/bootp-dhcp-parameters as
&nbs= p;  specified in [RFC3046].

&nbs= p;  A new option, DHCPv6 Relay Source Port, is defined in this documen= t
&nbs= p;  for DHCPv6 and it needs to be assigned by IANA for the DHCPv6 opti= on
&nbs= p;  code, in the "Option Codes" registry for DHCPv6,<= /div>
&nbs= p;  http://www.iana.org/assignments/dhcpv6-parameters as specified in
&nbs= p;  [RFC3315].


6. Section 8 (Security Considerations). This should reference the security = considerations of RFC 2131 and 3315.

The text that is there is more of an operational consideration rather than = what security issues this new work might expose - which may be nothing new = over 2131/3315. But pointing out that firewalls need to be adjusted is a go= od thing.

Ok, I added this paragraph in the front, and a =91Although=92 to start the = original sentence:

&nbs= p;  [RFC3118] and [RFC3315] described many of the threats in using DHC= P.
&nbs= p;  This extension does not raise addition security issues.

&nbs= p;  Although if the network uses firewall to block or allow DHCP packe= ts
     =85.



7. Section 10 (Document Change Log). Usually an RFC Editor note is added to= request that they REMOVE this material in the RFC publication process.

Sure. Will remove these in the next version.

thanks.
- Naiming


- Bernie

-----Original Message-----
From: dhcwg [mailto:dh= cwg-bounces@ietf.org] On Behalf Of Tomek Mrugalski
Sent: Wednesday, April 05, 2017 3:26 PM
To: dhcwg <dhcwg@ietf.org>
Subject: [dhcwg] WGLC on draft-ietf-dhc-relay-port-02 - respond by Apr 26
Hi,
draft-ietf-dhc-relay-port-02 defines a small extension to the DHCPv4 and DHCPv6 protocols that allows usage of other UDP source ports to be used by = relay agents. Authors believe this document is ready. The discussions so fa= r on the mailing list were a bit modest, but the concept is simple, the dra= ft was presented twice (in Buenos Aires and Berlin) and enjoyed a favourable reception in the room. As such,= we announce a working group last call on this document. Please review and = comment.

This is a very short document. It has around 6 pages of actual text.

Many WG participants may celebrate upcoming Easter and take some days off, = therefore this WGLC is a bit longer than typical two weeks.

Title: Generalized UDP Source Port for DHCP Relay
Authors: N. Shen, E. Chen
Filename: draft-ietf-dhc-relay-port-02
Pages: 10 (around 6 of actual technical text)
Date: 2017-02-28
Link: https://tools.ietf.org/html/draft-ietf-dhc-relay-port-02

Responses by April 26th are appreciated.

Thanks,
Bernie and Tomek

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

--_000_A699CC6A7B19493A857FB48E47A6540Aciscocom_-- From nobody Tue Apr 25 15:12:51 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 7766A128BB6; Tue, 25 Apr 2017 15:12:49 -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.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149315836945.6988.12636438912250101174@ietfa.amsl.com> Date: Tue, 25 Apr 2017 15:12:49 -0700 Archived-At: Subject: [dhcwg] I-D Action: draft-ietf-dhc-relay-port-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: Tue, 25 Apr 2017 22:12:49 -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 : Generalized UDP Source Port for DHCP Relay Authors : Naiming Shen Enke Chen Filename : draft-ietf-dhc-relay-port-05.txt Pages : 9 Date : 2017-04-25 Abstract: This document proposes an extension to the DHCP protocols that allows a relay agent to receive packets from a server or an upstream relay agent on any UDP port, not just the default port 67 for IPv4 or default port 547 for IPv6. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-relay-port/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dhc-relay-port-05 https://datatracker.ietf.org/doc/html/draft-ietf-dhc-relay-port-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-relay-port-05 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 Tue Apr 25 15:17:08 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 8E45B1294B2 for ; Tue, 25 Apr 2017 15:17:05 -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 AR0t3tHbOzqd for ; Tue, 25 Apr 2017 15:17:03 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EC911279E5 for ; Tue, 25 Apr 2017 15:17:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10808; q=dns/txt; s=iport; t=1493158623; x=1494368223; h=from:to:subject:date:message-id:references:mime-version; bh=SssnsshqY02Plskc6WVmqQ18PEdM8v0FOMDJuGJkZHc=; b=QqPF8pzLVTwgc3DnAAbssIc3cbu3EE8Pb5lerScDkr//q2cmNdXuScn9 IgNyCDsSy2yxElV85KQKMdhf247geS8v0dtyL7IYLGRUtwfDEevYTQp5j QKOfcYUAlNIkqrH3tpfUlMeA3D6Cbuz4b9l2kfy2PRTPoCEFlFL37D3xY k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BsAQClyf9Y/5JdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1RhgQwHg2CKFZFvkDCFNYIPIQEKhXgCGoN7PxgBAgEBAQEBAQF?= =?us-ascii?q?rKIUVAQMDAQEhSxsCARkDAQIoAwICAiULFAcCCAIEE4ocDqpxgiaLKgEBAQEBA?= =?us-ascii?q?QQBAQEBAQEBAQEfiFuCboMYgSk2FoJQLoIxBZZJhngBhxaLb4IAVYReiGeBPZQ?= =?us-ascii?q?YAR84gQZjFRoqEQGGVnWIKQGBDAEBAQ?= X-IronPort-AV: E=Sophos;i="5.37,251,1488844800"; d="scan'208,217";a="237545383" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Apr 2017 22:17:02 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v3PMH2Qa023420 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 25 Apr 2017 22:17:02 GMT Received: from xch-rcd-004.cisco.com (173.37.102.14) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 25 Apr 2017 17:17:01 -0500 Received: from xch-rcd-004.cisco.com ([173.37.102.14]) by XCH-RCD-004.cisco.com ([173.37.102.14]) with mapi id 15.00.1210.000; Tue, 25 Apr 2017 17:17:02 -0500 From: "Naiming Shen (naiming)" To: dhcwg Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-relay-port-05.txt Thread-Index: AQHSvhEbo2nOibSIcUOJYlLiV1FgSA== Date: Tue, 25 Apr 2017 22:17:02 +0000 Message-ID: <60676CDC-6B9E-4A53-BF0D-587FBC43E4AD@cisco.com> References: <149315836945.6988.12636438912250101174@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [128.107.155.85] Content-Type: multipart/alternative; boundary="_000_60676CDC6B9E4A53BF0D587FBC43E4ADciscocom_" MIME-Version: 1.0 Archived-At: Subject: [dhcwg] Fwd: I-D Action: draft-ietf-dhc-relay-port-05.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: Tue, 25 Apr 2017 22:17:06 -0000 --_000_60676CDC6B9E4A53BF0D587FBC43E4ADciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpIaSBESEMgV0csDQoNClVwZGF0ZWQgdGhlIGRyYWZ0IGJhc2VkIG9uIG1haW5seSBCZXJuaWXi gJlzIGRldGFpbGVkIGNvbW1lbnRzLg0KDQpQbGVhc2UgcmV2aWV3IGFuZCBjb21tZW50Lg0KDQpC ZXN0IFJlZ2FyZHMsDQotIE5haW1pbmcNCg0KQmVnaW4gZm9yd2FyZGVkIG1lc3NhZ2U6DQoNCkZy b206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzxtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnPg0KU3ViamVjdDogW2RoY3dnXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWRoYy1yZWxheS1w b3J0LTA1LnR4dA0KRGF0ZTogQXByaWwgMjUsIDIwMTcgYXQgMzoxMjo0OSBQTSBQRFQNClRvOiA8 aS1kLWFubm91bmNlQGlldGYub3JnPG1haWx0bzppLWQtYW5ub3VuY2VAaWV0Zi5vcmc+Pg0KQ2M6 IGRoY3dnQGlldGYub3JnPG1haWx0bzpkaGN3Z0BpZXRmLm9yZz4NCg0KDQpBIE5ldyBJbnRlcm5l dC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGly ZWN0b3JpZXMuDQpUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBEeW5hbWljIEhvc3Qg Q29uZmlndXJhdGlvbiBvZiB0aGUgSUVURi4NCg0KICAgICAgIFRpdGxlICAgICAgICAgICA6IEdl bmVyYWxpemVkIFVEUCBTb3VyY2UgUG9ydCBmb3IgREhDUCBSZWxheQ0KICAgICAgIEF1dGhvcnMg ICAgICAgICA6IE5haW1pbmcgU2hlbg0KICAgICAgICAgICAgICAgICAgICAgICAgIEVua2UgQ2hl bg0KRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1kaGMtcmVsYXktcG9ydC0wNS50eHQNClBh Z2VzICAgICAgICAgICA6IDkNCkRhdGUgICAgICAgICAgICA6IDIwMTctMDQtMjUNCg0KQWJzdHJh Y3Q6DQogIFRoaXMgZG9jdW1lbnQgcHJvcG9zZXMgYW4gZXh0ZW5zaW9uIHRvIHRoZSBESENQIHBy b3RvY29scyB0aGF0IGFsbG93cw0KICBhIHJlbGF5IGFnZW50IHRvIHJlY2VpdmUgcGFja2V0cyBm cm9tIGEgc2VydmVyIG9yIGFuIHVwc3RyZWFtIHJlbGF5DQogIGFnZW50IG9uIGFueSBVRFAgcG9y dCwgbm90IGp1c3QgdGhlIGRlZmF1bHQgcG9ydCA2NyBmb3IgSVB2NCBvcg0KICBkZWZhdWx0IHBv cnQgNTQ3IGZvciBJUHY2Lg0KDQoNClRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZv ciB0aGlzIGRyYWZ0IGlzOg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt aWV0Zi1kaGMtcmVsYXktcG9ydC8NCg0KVGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMg YXZhaWxhYmxlIGF0Og0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZGhj LXJlbGF5LXBvcnQtMDUNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJh ZnQtaWV0Zi1kaGMtcmVsYXktcG9ydC0wNQ0KDQpBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVy c2lvbiBpcyBhdmFpbGFibGUgYXQ6DQpodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9 ZHJhZnQtaWV0Zi1kaGMtcmVsYXktcG9ydC0wNQ0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5 IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCnVu dGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMu aWV0Zi5vcmcuDQoNCkludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnlt b3VzIEZUUCBhdDoNCmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpkaGN3ZyBtYWlsaW5n IGxpc3QNCmRoY3dnQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2RoY3dnDQoNCg== --_000_60676CDC6B9E4A53BF0D587FBC43E4ADciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <994176BFD212BE4688E08514E084043E@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCkhpIERIQyBXRywNCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlVwZGF0ZWQgdGhlIGRyYWZ0IGJhc2VkIG9uIG1haW5seSBC ZXJuaWXigJlzIGRldGFpbGVkIGNvbW1lbnRzLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+UGxlYXNlIHJldmlldyBhbmQgY29tbWVudC48 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PkJlc3QgUmVnYXJkcyw8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+LSBOYWltaW5nPGJyIGNsYXNzPSIi Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4N CjxkaXYgY2xhc3M9IiI+QmVnaW4gZm9yd2FyZGVkIG1lc3NhZ2U6PC9kaXY+DQo8YnIgY2xhc3M9 IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBzdHlsZT0ibWFyZ2luLXRvcDogMHB4 OyBtYXJnaW4tcmlnaHQ6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyBtYXJnaW4tbGVmdDogMHB4 OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3lzdGVtLWZv bnQsIEhlbHZldGljYSBOZXVlLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IGNvbG9yOnJnYmEoMCwg MCwgMCwgMS4wKTsiIGNsYXNzPSIiPjxiIGNsYXNzPSIiPkZyb206DQo8L2I+PC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTogLXdlYmtpdC1zeXN0ZW0tZm9udCwgSGVsdmV0aWNhIE5ldWUs IEhlbHZldGljYSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPjxhIGhyZWY9Im1haWx0bzppbnRlcm5l dC1kcmFmdHNAaWV0Zi5vcmciIGNsYXNzPSIiPmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvYT48 YnIgY2xhc3M9IiI+DQo8L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tdG9wOiAwcHg7 IG1hcmdpbi1yaWdodDogMHB4OyBtYXJnaW4tYm90dG9tOiAwcHg7IG1hcmdpbi1sZWZ0OiAwcHg7 IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogLXdlYmtpdC1zeXN0ZW0tZm9u dCwgSGVsdmV0aWNhIE5ldWUsIEhlbHZldGljYSwgc2Fucy1zZXJpZjsgY29sb3I6cmdiYSgwLCAw LCAwLCAxLjApOyIgY2xhc3M9IiI+PGIgY2xhc3M9IiI+U3ViamVjdDoNCjwvYj48L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAtd2Via2l0LXN5c3RlbS1mb250LCBIZWx2ZXRpY2EgTmV1 ZSwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+PGIgY2xhc3M9IiI+W2RoY3dnXSBJ LUQgQWN0aW9uOiBkcmFmdC1pZXRmLWRoYy1yZWxheS1wb3J0LTA1LnR4dDwvYj48YnIgY2xhc3M9 IiI+DQo8L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1y aWdodDogMHB4OyBtYXJnaW4tYm90dG9tOiAwcHg7IG1hcmdpbi1sZWZ0OiAwcHg7IiBjbGFzcz0i Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogLXdlYmtpdC1zeXN0ZW0tZm9udCwgSGVsdmV0 aWNhIE5ldWUsIEhlbHZldGljYSwgc2Fucy1zZXJpZjsgY29sb3I6cmdiYSgwLCAwLCAwLCAxLjAp OyIgY2xhc3M9IiI+PGIgY2xhc3M9IiI+RGF0ZToNCjwvYj48L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiAtd2Via2l0LXN5c3RlbS1mb250LCBIZWx2ZXRpY2EgTmV1ZSwgSGVsdmV0aWNh LCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+QXByaWwgMjUsIDIwMTcgYXQgMzoxMjo0OSBQTSBQRFQ8 YnIgY2xhc3M9IiI+DQo8L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tdG9wOiAwcHg7 IG1hcmdpbi1yaWdodDogMHB4OyBtYXJnaW4tYm90dG9tOiAwcHg7IG1hcmdpbi1sZWZ0OiAwcHg7 IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogLXdlYmtpdC1zeXN0ZW0tZm9u dCwgSGVsdmV0aWNhIE5ldWUsIEhlbHZldGljYSwgc2Fucy1zZXJpZjsgY29sb3I6cmdiYSgwLCAw LCAwLCAxLjApOyIgY2xhc3M9IiI+PGIgY2xhc3M9IiI+VG86DQo8L2I+PC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTogLXdlYmtpdC1zeXN0ZW0tZm9udCwgSGVsdmV0aWNhIE5ldWUsIEhl bHZldGljYSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPiZsdDs8YSBocmVmPSJtYWlsdG86aS1kLWFu bm91bmNlQGlldGYub3JnIiBjbGFzcz0iIj5pLWQtYW5ub3VuY2VAaWV0Zi5vcmc8L2E+Jmd0Ozxi ciBjbGFzcz0iIj4NCjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi10b3A6IDBweDsg bWFyZ2luLXJpZ2h0OiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsgbWFyZ2luLWxlZnQ6IDBweDsi IGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAtd2Via2l0LXN5c3RlbS1mb250 LCBIZWx2ZXRpY2EgTmV1ZSwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBjb2xvcjpyZ2JhKDAsIDAs IDAsIDEuMCk7IiBjbGFzcz0iIj48YiBjbGFzcz0iIj5DYzoNCjwvYj48L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiAtd2Via2l0LXN5c3RlbS1mb250LCBIZWx2ZXRpY2EgTmV1ZSwgSGVs dmV0aWNhLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+PGEgaHJlZj0ibWFpbHRvOmRoY3dnQGlldGYu b3JnIiBjbGFzcz0iIj5kaGN3Z0BpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQo8L3NwYW4+PC9k aXY+DQo8YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+DQpBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGlu ZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuPGJyIGNsYXNzPSIiPg0KVGhpcyBkcmFmdCBp cyBhIHdvcmsgaXRlbSBvZiB0aGUgRHluYW1pYyBIb3N0IENvbmZpZ3VyYXRpb24gb2YgdGhlIElF VEYuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7VGl0bGUgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7OiBHZW5lcmFsaXplZCBVRFAgU291cmNlIFBvcnQg Zm9yIERIQ1AgUmVsYXk8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDtBdXRob3JzICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOzogTmFpbWluZyBTaGVuPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7RW5rZSBDaGVuPGJyIGNsYXNzPSIiPg0KPHNwYW4gY2xhc3M9 IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6cHJlIj48L3NwYW4+RmlsZW5hbWUg Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7OiBkcmFmdC1pZXRmLWRo Yy1yZWxheS1wb3J0LTA1LnR4dDxiciBjbGFzcz0iIj4NCjxzcGFuIGNsYXNzPSJBcHBsZS10YWIt c3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOnByZSI+PC9zcGFuPlBhZ2VzICZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzogOTxiciBjbGFz cz0iIj4NCjxzcGFuIGNsYXNzPSJBcHBsZS10YWItc3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOnBy ZSI+PC9zcGFuPkRhdGUgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7OiAyMDE3LTA0LTI1PGJyIGNsYXNzPSIiPg0KPGJyIGNs YXNzPSIiPg0KQWJzdHJhY3Q6PGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7VGhpcyBkb2N1bWVu dCBwcm9wb3NlcyBhbiBleHRlbnNpb24gdG8gdGhlIERIQ1AgcHJvdG9jb2xzIHRoYXQgYWxsb3dz PGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7YSByZWxheSBhZ2VudCB0byByZWNlaXZlIHBhY2tl dHMgZnJvbSBhIHNlcnZlciBvciBhbiB1cHN0cmVhbSByZWxheTxiciBjbGFzcz0iIj4NCiZuYnNw OyZuYnNwO2FnZW50IG9uIGFueSBVRFAgcG9ydCwgbm90IGp1c3QgdGhlIGRlZmF1bHQgcG9ydCA2 NyBmb3IgSVB2NCBvcjxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwO2RlZmF1bHQgcG9ydCA1NDcg Zm9yIElQdjYuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KVGhl IElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6PGJyIGNsYXNz PSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0 Zi1kaGMtcmVsYXktcG9ydC8iIGNsYXNzPSIiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWlldGYtZGhjLXJlbGF5LXBvcnQvPC9hPjxiciBjbGFzcz0iIj4NCjxiciBjbGFz cz0iIj4NClRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBhdDo8YnIg Y2xhc3M9IiI+DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1kaGMtcmVs YXktcG9ydC0wNTxiciBjbGFzcz0iIj4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2h0bWwvZHJhZnQtaWV0Zi1kaGMtcmVsYXktcG9ydC0wNTxiciBjbGFzcz0iIj4NCjxiciBjbGFz cz0iIj4NCkEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDo8 YnIgY2xhc3M9IiI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0 Zi1kaGMtcmVsYXktcG9ydC0wNTxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFz cz0iIj4NClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBm cm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb248YnIgY2xhc3M9IiI+DQp1bnRpbCB0aGUgaHRtbGl6 ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLjxiciBj bGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFi bGUgYnkgYW5vbnltb3VzIEZUUCBhdDo8YnIgY2xhc3M9IiI+DQpmdHA6Ly9mdHAuaWV0Zi5vcmcv aW50ZXJuZXQtZHJhZnRzLzxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0KZGhjd2cg bWFpbGluZyBsaXN0PGJyIGNsYXNzPSIiPg0KZGhjd2dAaWV0Zi5vcmc8YnIgY2xhc3M9IiI+DQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RoY3dnPGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_60676CDC6B9E4A53BF0D587FBC43E4ADciscocom_-- From nobody Fri Apr 28 11:07:32 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 33851129C48 for ; Fri, 28 Apr 2017 11:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 734ta3aYxkUC for ; Fri, 28 Apr 2017 11:07:28 -0700 (PDT) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::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 709641296CF for ; Fri, 28 Apr 2017 11:04:14 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id 75so37932407lfs.2 for ; Fri, 28 Apr 2017 11:04:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=62kuc6L2p9tpLrEL95lVZ8YFCGx6MHeVHwT72Ii1DEM=; b=NpjLwmdfvg5q5I9R4Bnbku6pGuq2Hw15ipjIzv7kn96wyQdEe5/B6mwCYZC9RfagsY FbPzWyWPtQ+PS3MrvykndjhXeB4cYmA/T6oWC3N/5iPnGQ+Wivfyn00zYZ9tweQWLNLt in6/QN53JfzkGLFlOOPERjtBeFqascxt2nuOs9PGsyEpfPReTlftpZ0FD0jXBF22Cw3u etFMj/0T8PTDXn4CgiYUnHphuvZpPzmkPw57v5iGax39S+rCOzVomKfVwEeMDbmTiWo7 mQvAvM7K/qEgNxHTvQXgKOLkoiCztaLfuvnLCw8qT0urAsOnVkQe5s/NpPjKrt4wxpm0 YkBg== 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:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=62kuc6L2p9tpLrEL95lVZ8YFCGx6MHeVHwT72Ii1DEM=; b=eFEkz0vnqsYXIlmmGFyNQ2r2SZZzq4qIjtHrI5lflJU2REEikEyYwlEny7uKTDEqkF 86gi4IZc4Qlm8clXYG6lnnxyiiadvdJWvIUdaKcY6/UAF6wFYBvDjjip0BtAU51MhEEd xqsrf2MzBY+vhMIqjVcFd5AEKphfS5hJsqr2VrrBT0U5/Ny52ysJEm7UwTnhgg9ebJlq 3oyrxcU1qNvfL98XN+Qm8NFphPT+hZ+YAfQ/temNSQ5UpBr3lEK4bMQfTNW5rUSIBxOy +jXd630oPdx18uN8fciNux+vm00Trfi9U9oX4k/xbr5pDcs86ahj6NhygRmG+3F44iFZ fG0w== X-Gm-Message-State: AN3rC/6jy5O8D/jUTbBj34wbwVRFjWjzMoirdn9AtQqL3xLOvC1rXnyp Tfeqfjx8vr6aS2D+ X-Received: by 10.25.33.14 with SMTP id h14mr4432457lfh.68.1493402652279; Fri, 28 Apr 2017 11:04:12 -0700 (PDT) Received: from [192.168.0.4] (109241207033.gdansk.vectranet.pl. [109.241.207.33]) by smtp.googlemail.com with ESMTPSA id z23sm1161639lff.40.2017.04.28.11.04.10 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Apr 2017 11:04:10 -0700 (PDT) To: dhcwg References: <4cb9bdab-f3a2-a9d0-1056-302b5ecdeae7@gmail.com> From: Tomek Mrugalski Message-ID: <5f8fcb54-e8df-90a3-c6dd-163937d020a8@gmail.com> Date: Fri, 28 Apr 2017 20:04:09 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <4cb9bdab-f3a2-a9d0-1056-302b5ecdeae7@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [dhcwg] WGLC on draft-ietf-dhc-relay-port-02 - Passed! 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, 28 Apr 2017 18:07:30 -0000 W dniu 05.04.2017 o 21:25, Tomek Mrugalski pisze: > Responses by April 26th are appreciated. I (Bernie recused himself on this one as all authors work for the same company as he does) reviewed the responses received to this last and determined that there's a consensus in the working group to proceed forward with this document. Authors already seem to have addressed all comments in the -05, which has been published recently. Thank you to everyone who commented and to authors for addressing all the issues raised quickly. Tomek p.s. I will do my shepherd duties once I get back from a short vacation and business trip. Expect some movement here around mid-May.