From nobody Sat May 1 11:56:53 2021 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E3F1E3A24DE; Sat, 1 May 2021 11:56:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joseph Salowey via Datatracker To: Cc: core@ietf.org, draft-ietf-core-senml-versions.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.28.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161989540388.8528.14442751027312770969@ietfa.amsl.com> Reply-To: Joseph Salowey Date: Sat, 01 May 2021 11:56:43 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-core-senml-versions-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 May 2021 18:56:44 -0000 Reviewer: Joseph Salowey Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is the document is ready. This is a short document that describes how to encode features in the SenML version. The document is clear, I don't see any security. The encoding features in a version string will cause some confusion, but this is pointed out. From nobody Sat May 1 21:36:03 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 385A83A1C4B; Sat, 1 May 2021 21:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=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 8Mchy3hWfH9k; Sat, 1 May 2021 21:35:58 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 85CC13A1C4C; Sat, 1 May 2021 21:35:58 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 1424ZniJ028948 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 2 May 2021 00:35:54 -0400 Date: Sat, 1 May 2021 21:35:49 -0700 From: Benjamin Kaduk To: Daniel Franke Cc: secdir@ietf.org, draft-ietf-tls-dtls-connection-id.all@ietf.org Message-ID: <20210502043549.GF79563@kduck.mit.edu> References: <161910581603.10398.13918665853904033223@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <161910581603.10398.13918665853904033223@ietfa.amsl.com> Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-tls-dtls-connection-id-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 May 2021 04:36:01 -0000 Hi Daniel, Thanks for the review. There was some effort towards a return-routability check at the DTLS layer, in draft-tschofenig-tls-dtls-rrc, but we seem to have failed to follow up after the adoption call was issued. I've pinged the chairs to check on its progress. -Ben On Thu, Apr 22, 2021 at 08:36:56AM -0700, Daniel Franke via Datatracker wrote: > Reviewer: Daniel Franke > Review result: Ready > > I have reviewed this document as part of the security directorate's ongoing > effort to review all IETF documents being processed by the IESG. These > comments were written primarily for the benefit of the security area directors. > Document editors and WG chairs should treat these comments just like any other > last call comments. > > Apologies for the absolute last-minute review; I overlooked until just now that > this had been assigned a telechat date. > > This document is Ready. I do have some concerns — in particular I think relying > on application-layer measures to prevent amplified reflection attacks is a bit > dubious — but these have been debated to death already, the issues are > well-captured in the document, and I don't think I have anything new to add. > > From nobody Sun May 2 21:43:59 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 569393A1FE7; Sun, 2 May 2021 21:43:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, 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 TIsCbgpZQymZ; Sun, 2 May 2021 21:43:52 -0700 (PDT) Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (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 13EF33A2007; Sun, 2 May 2021 21:43:51 -0700 (PDT) Received: by mail-il1-x130.google.com with SMTP id h6so2889763ila.7; Sun, 02 May 2021 21:43:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=btUViEUvaBwwBlkVa+8frP3qUOJklz2Z63BlAzwRE84=; b=dHnG89lM8uBjDVxC33nO8S3zP3rKu5+l5x8DMytZaKDVDR08TYYaWyibQplBfHy1r+ mTKRja/8C2JrAxmMmXUAWxngcb2pfe6AZFf9OaAxfHmWIghUM2u+wcnkYOjIC4cshBOc HcUvD0l/aQiSObi66FpHdcNTa/iGosHDQsi+nb8JgHAYwz1DqbMPRJ/Gtn3YOWRi0Wab QYYbRm9gC1/NuKBpgtGjNsrWGXD05laHORt4F5O8ya9K7J9fzNqDEPRTBPVFBVg9AyUn DMZ4PAhGqhav10VOjn7LAjM8ItXx6IELmMWLsaKCMXo8wLrnNIRG86qbmfMVU31gT3Kh Tvyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=btUViEUvaBwwBlkVa+8frP3qUOJklz2Z63BlAzwRE84=; b=pfnPzR/Aa1FxFWl8KZFyfXkFA1qHr+X22bQ2SejS7HqdkLpXOjKUVkvev+s9UCC2fw 0dTazNRWejf9q7xT0MI/ryp/5K6I8rx63oBvN+prTze0qv8BHV/1dU429RzIXnqJgTFr 0J51DGDNBhqJ/YCSMbCFQ6mwxlX2EOJXh1RQ0u+7XQcd+QwVdXfbkOunxxVv4oI1gYcM 5QKAZb4ENDPAnFW/NgZ0eeWIasTgxNy2PBveMQpMRAu4KlzrkSIOslpL8+GZRG+q93Ed LD5qa2huCy7Ql65vA4Gc2stccVT9vYsTay99Dz9QknK8kHrnzxJl4J+lpZ2HZHUh6I3e kJJw== X-Gm-Message-State: AOAM530qPkFYrYl1j2z2gquwEv6+ce8sqaRIRpxqMSlm5YxMyudAh5rh DyLxDcgRCQo/2/nQclJ1ByiiUnR5UtoNIJKAPstJyOc5noU= X-Google-Smtp-Source: ABdhPJy141mMg89dBghpS977BPL0SaIPy2cKMGarMle8cmiV2z71z5Oi083haFGpYDwlfgzhBaltphjPxXvbmFJaC+g= X-Received: by 2002:a92:8e4f:: with SMTP id k15mr14015516ilh.16.1620017029313; Sun, 02 May 2021 21:43:49 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?Magnus_Nystr=C3=B6m?= Date: Sun, 2 May 2021 21:43:38 -0700 Message-ID: To: secdir@ietf.org, draft-ietf-idr-bgp-flowspec-oid@ietf.org Content-Type: multipart/alternative; boundary="0000000000008ffb8605c1659b4a" Archived-At: Subject: [secdir] Secdir review of draft-ietf-idr-bgp-flowspec-oid-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2021 04:43:57 -0000 --0000000000008ffb8605c1659b4a Content-Type: text/plain; charset="UTF-8" I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes "a modification to the validation procedure defined for the dissemination of BGP Flow Specifications." More specifically. the memo describes a mechanism which relaxes the existing validation rule that requires Flow Specifications to be originating from the originator of the best-match unicast route, and now allows such specifications to be originated within the same AS as the validator. As a result. the Security Considerations section does call out: "The original AS_PATH validation rule ([RFC4271] section 6.3 ) becomes hereby optional (section 4.2 ). If that original rule is actually not enforced it may introduce some security risks. A peer (or a client of a route server peer) in AS X could advertise a rogue Flow Specification route...." and "If t[the originator of a rule] is known for a fact not to be a route server, that optional rule SHOULD be enforced for Flow Specification routes." It is not clear to me how a validator would now "for a fact" that a peer isn't a route server, and thus that it would have to enforce the now-optional path validation rule. It seems some clarity on this would be good such that implementations have less of a risk of accepting flow specifications from unauthorized parties, even if they are on the same AS. Editorial: - "Let's consider the particular case where the Flow Specification is originated in any location within the same autonomous system than the speaker performing the validation (for example by a centralized BGP route controller), and the best-match unicast route is originated in another autonomous system." - should the word "than" be replaced with "that" here? - In the security considerations section, "becomes hereby optional" could probably be simplified to "becomes optional" or similar, and "actually" could be removed. Thanks, -- Magnus --0000000000008ffb8605c1659b4a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<= div class=3D"gmail_quote">
I have reviewed this document as part of the security directorate's ong= oing effort to review all IETF documents being processed by the IESG. These= comments were written primarily for the benefit of the security area direc= tors.=C2=A0 Document editors and WG chairs should treat these comments just= like any other last call comments.

This document describes "a modification to the val= idation procedure defined for the dissemination
of BGP Flow = Specifications." More specifically. the memo describes a mechanism whi= ch relaxes=C2=A0 the existing validation rule that requires Flow Specificat= ions to be originating from the originator of the best-match unicast rout= e, and now allows such specifications to be originated within the same AS a= s the validator. As a result. the Security Considerations section does call= out: "The original AS_PATH validation rule ([RFC4271] section=C2=A06.3) becomes= =C2=A0 hereby optional (section 4.2). If that original r= ule is actually not enforced it may introduce some security risks. A pee= r (or a client of a route server peer) in AS X could advertise a rogue Fl= ow Specification route...." and "If t[the originator of a rule]= is known for a fact not to be a route server, that optional rule SHOULD = be enforced for Flow Specification routes."

It is not clear to me how a validator would now "for a fact" tha= t a peer isn't a route server, and thus that it would have to enforce t= he now-optional path validation rule. It seems some clarity on this would b= e good such that implementations have less of a risk of accepting flow spec= ifications from unauthorized parties, even if they are on the same AS.

Editorial:
  • "Let's co= nsider the particular case where the Flow Specification is originated in = any location within the same autonomous system than the speaker performin= g the validation (for example by a centralized BGP route controller), and= the best-match unicast route is originated in another autonomous system.= " - should the word "than" be replaced with "that"= here?
  • In the security considerations section, "becomes hereby= optional" could probably be simplified to "becomes optional"= ; or similar, and "actually" could be removed.

Thanks,
-- Magnus

--0000000000008ffb8605c1659b4a-- From nobody Mon May 3 02:46:24 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38EC83A167A for ; Mon, 3 May 2021 02:46:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 XVZVoQcgM37V for ; Mon, 3 May 2021 02:46:18 -0700 (PDT) Received: from us-smtp-delivery-140.mimecast.com (us-smtp-delivery-140.mimecast.com [216.205.24.140]) (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 B5BFB3A1677 for ; Mon, 3 May 2021 02:46:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=mimecast20190606; t=1620035177; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=FK3p6T5ZySIbucN11Edel3B6QLx/qMA+RQ6QFuHWC70=; b=YhzBgKTTiZvrKdyIRmaU0YgJ8InYBhLD67XBAen9b6R6fXqzT/a/uZA7Jp39Mm8u8E8UXE YctrTtHph4Y3P4peU+MT9U5nDIOdVejIX8OO71/QzAgMWkXARPus8H/1HIWxDDfmk1Kjkp MR5wyZv/k31shYMIL0gLtgwQs3cmK7o= Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12lp2044.outbound.protection.outlook.com [104.47.66.44]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-411-AZct7dnhPdu4QOXRgKpm8A-1; Mon, 03 May 2021 05:46:15 -0400 X-MC-Unique: AZct7dnhPdu4QOXRgKpm8A-1 Received: from PH0PR16MB4118.namprd16.prod.outlook.com (2603:10b6:510:59::7) by PH0PR16MB4149.namprd16.prod.outlook.com (2603:10b6:510:52::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4087.26; Mon, 3 May 2021 09:46:12 +0000 Received: from PH0PR16MB4118.namprd16.prod.outlook.com ([fe80::30aa:2254:f287:6b4]) by PH0PR16MB4118.namprd16.prod.outlook.com ([fe80::30aa:2254:f287:6b4%3]) with mapi id 15.20.4087.044; Mon, 3 May 2021 09:46:12 +0000 From: "Konda, Tirumaleswar Reddy" To: "secdir@ietf.org" , "dnsop@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-dnsop-nsec-ttl-04 Thread-Index: Adc/E7RRcg7oO2p8QCupjXi7vlixYg== Date: Mon, 3 May 2021 09:46:11 +0000 Message-ID: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.6.100.41 dlp-reaction: no-action x-originating-ip: [49.37.163.213] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9120669e-4897-4104-14ce-08d90e184945 x-ms-traffictypediagnostic: PH0PR16MB4149: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0 x-microsoft-antispam-message-info: iO4HCBcXlgaG+tn1XQZuHfs7jYoJPnWy6zibtT392UvYuKQgooLbrmeKc/XerxK/E47uAFH2ea8UjIBefCgWjLcORGdtZrWniawBeS36oflbVNbiEgW9clDAmq5bWrWZwZ62RZzFVJQcUSPWZSzwUtqx/QHgs23ZYzBm3vo3+Uyb+kKIDXRewb0KgjFaZsuVemchnb7b5tcpIhvrOeQ5APB/kkmx9kPa8zc4UW4fsMQS928F5w5ZpR74YEr8ivWAtuAXtVC4gHfjvmv3WnXj7m4YY0IN5ol6LswzBSwqrRw/og1CsFr0/IEN5PTEsMA6WJC67SkVc2kVmNUlHK49uKgGOlAVBoChfJSJ8namoQuZCs/4rhQqSN5H6B9dIeKlfbYSP4XR7eXVb8hyCmi8dPb5nvE2/e7CyVa/2qQZ0go5Wm+Hfh/k1vQ/I14M0H9wjUI8rXWS7TnvfVyLKfL20MikfuFwPRRdMzds4/tjlE/90qkhnxwVI1ebliEBqXOtr5fZ73jeCBF4oHsWPnO0igmtdupC3RF7bL9JhYwbhcWUUnw+WBG6kq5NxgrCA2HGRZ9sBPsn6U8Qw4f0zgC3VVPZWgIRqBfIRLO8WpUmOPC4eD2ms8c+AMbnGxW7wEvpal/tr/avmC3cOmn/HBiLP+wvjL0tlIpKzUF4mdMXXqqQE5YMeSg8UqYD1vhPTVNN x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR16MB4118.namprd16.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(366004)(136003)(376002)(39860400002)(346002)(32952001)(7696005)(38100700002)(6506007)(122000001)(8936002)(76116006)(83380400001)(66556008)(66446008)(66476007)(64756008)(110136005)(316002)(4744005)(2906002)(66946007)(450100002)(478600001)(55016002)(71200400001)(186003)(8676002)(33656002)(86362001)(26005)(52536014)(5660300002)(9686003)(85282002); DIR:OUT; SFP:1101 x-ms-exchange-antispam-messagedata: =?us-ascii?Q?TywoFi9Fr/8l2lVDrHcRGBxtsk3t9Vl2/JQgAB2UqG2MKWmm43H3aToWzkH4?= =?us-ascii?Q?FPoTwf0obqGK328YvezirHZk/A2QYbmSqGp68BV2CcxglMjZ/GPjfJNBkwuK?= =?us-ascii?Q?qG2MifsDTnAIREsJl5wmB2J081SNx+WHnQEPf5PYL8iLB4/Q6n4xhZiJo5tM?= =?us-ascii?Q?6BXRDGNVYfhaC5+IWeGIP8HWwPKzDWbmRyU+e2iAqZDEJIxFIMLab+7dK6Ml?= =?us-ascii?Q?7SdMpTNczTOhxwEoNeEHmQ8bqcwHvjVqkc291sUuF3lXZdqWaCLsexR40qGQ?= =?us-ascii?Q?2PxFJlMfSfbWGTNE8dmFlyDV6kUHNExAe5Ki2fKKal3TRGt/MGEUhtmC3zF9?= =?us-ascii?Q?kXxVEb/s/8Gv5y4VyOaz7cmnZKLdXs1DsEEaeoxSAO0DFFNsgFr2oaWqepyr?= =?us-ascii?Q?ganHLj70tBWR4npQvi2UfLgNVFfO05cfjjEkqfRFX2tPujPCFnh3Xmv5asf/?= =?us-ascii?Q?kgy4eufzSx+voFTwKA0Dc2xTcLLV+Kua9yshXEpqLb6kAlIOvo/yJgqQq5ay?= =?us-ascii?Q?Gip/J5EBlUK8j4ARd5gmCKr4LGfFh64Z6WfD8hFIlMprfX8V5iI3OrOM0eJ4?= =?us-ascii?Q?uYEAV0qHK0VeBb3UmVs5klCV22cUGNXbE9YGiXKpsPX6+LwsGtz3YgW8H4XK?= =?us-ascii?Q?otVmvhZK61csxde5Rn6DY6i+hedrfK89KaNMZPmpc0aDK+FQpaAkROSESpR+?= =?us-ascii?Q?tBltMh8wpxGrn/FkscJzu7tqTQRH1btbCnkDMMRWYcilH+mOuM9wDu2L072K?= =?us-ascii?Q?kaR0fBWnVn9GP6jXNVIpYDu2CieFs+1xjlbw42k5E79Kc6gRdgHBFJcalQaU?= =?us-ascii?Q?eUbUzSceJ/JeObdZIJh1DfJn+gXoPWLj6pgaoGX1byIsvQDKnr3YKGSDl7HT?= =?us-ascii?Q?5qlxvw8zf1rZ8aagKHQ0A5LmWBEo1uPnYUMo+mr2cZR4FJz53g7VnY33UuOH?= =?us-ascii?Q?dk/ZoBwRgD49LGF1cBYng8po8CvAWoBajVSlpkhC2b9sFCiA+3dHVG/JcsD2?= =?us-ascii?Q?U8m5bnFqTdFnW0Z9jPzAuhigqzv7F6p4szQSjZC0/f0uvispDBOx+RBV6s2d?= =?us-ascii?Q?tKyVxSlcS3JLcm4+hf4WN/Fk1P9AX3eWT7uvey/Zwno2q3B3Ms2yjD4J7diZ?= =?us-ascii?Q?XPyMI6bYqAWasl3ivZ/ai6EgKJpDc4e1cv4GlL5c8HEGNM5W/rew6VH9FzN+?= =?us-ascii?Q?QarwOhkNwTRMKtSZF6e1D4Uw8Y6HCDHE3reX8gLI+uLbs8cfx4foalGG1nQ1?= =?us-ascii?Q?CL0WJ0YPYj5CMTXld4UvHP0SJWN3mg4LoN6uaBmHofAWg8NRdGrg1h7ZcpeM?= =?us-ascii?Q?lqMFmtMByKt4So0Hit6oHKXI?= x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: mcafee.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR16MB4118.namprd16.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9120669e-4897-4104-14ce-08d90e184945 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 May 2021 09:46:11.9529 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: i5nJgpaED2HR4LLGWsAkaspkCt0NSSpD7cuNm1M5tSqRGV53RhQQfU1GydEKe4QNLQqoJ/AIXERBaiSwDiIx3+GJtGeWmNZ09b+SEY7yE7lvq5K8ek3FlH959SV4y4ee X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR16MB4149 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA40A35 smtp.mailfrom=tirumaleswarreddy_konda@mcafee.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: mcafee.com Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_PH0PR16MB41182B3A2DD375C674D47BDFEA5B9PH0PR16MB4118namp_" Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-dnsop-nsec-ttl-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2021 09:46:22 -0000 --_000_PH0PR16MB41182B3A2DD375C674D47BDFEA5B9PH0PR16MB4118namp_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Reviewer: Tirumaleswar Reddy Review result: Ready I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These r= eviews are primarily for the benefit of the Security ADs. Document editors = and WG chairs should treat these comments just like any other last call com= ments. I think the Security Considerations section is adequate in its coverage to = address the attack not handled in a number of RFCs the document will update= . Thanks, -Tiru --_000_PH0PR16MB41182B3A2DD375C674D47BDFEA5B9PH0PR16MB4118namp_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable

Reviewer: Tirumaleswar Reddy

Review result: Ready

 

I have reviewed this document as part of the securit= y directorate's ongoing effort to review all IETF documents being processed= by the  IESG.  These reviews are primarily for the benefit of th= e Security ADs. Document editors and WG chairs should treat these comments just like any other last call comments.

I think the Security Considerations section is ad= equate in its coverage to address the attack not handled in a number of RFC= s the document will update.

 

Thanks,

-Tiru

--_000_PH0PR16MB41182B3A2DD375C674D47BDFEA5B9PH0PR16MB4118namp_-- From nobody Mon May 3 03:36:23 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A8083A1888; Mon, 3 May 2021 03:36:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.916 X-Spam-Level: X-Spam-Status: No, score=-11.916 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_NONE=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 header.b=RmI7yhbA; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=EGavVyl6 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 qOOVr79qhC2V; Mon, 3 May 2021 03:36:17 -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 0941F3A1886; Mon, 3 May 2021 03:36:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28232; q=dns/txt; s=iport; t=1620038176; x=1621247776; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=itKBnU2/VqWuIUW2ERydRVjpuEl07qT7SRd6uRIIC5k=; b=RmI7yhbATEDR/LWa2JrabDF8WT7MMIvZRo07Y9sZPDUVNbROWGlAbW7S DFeDrmFmgXIonqboBcb1gvq6JaJ4ZrFgIZbr/nkNMOrWSCuM8mWhPsA35 iTAjPBMh5NQJCQqd4vJRJ/Ke7wX+njb76QJvMZBdrfgVoOQD0ulhdLXhl M=; X-IPAS-Result: =?us-ascii?q?A0CWAACE0Y9g/4oNJK1aHAEBAQEBAQcBARIBAQQEAQGCB?= =?us-ascii?q?AYBAQsBgSIwUQd3WjYxC4Q5g0gDhTmIbwOKM48egS4UgREDVAsBAQENAQEqC?= =?us-ascii?q?AIEAQGEUAIXgWQCJTUIDgIEAQEBAwIDAQEBAQEFAQEBAgEGBHEThVANhkQBA?= =?us-ascii?q?QEEIwoTAQE4DwIBCBEEAQErAgICHxEdCAIEARIIgmqBflcDLwEDCz6cWQKKH?= =?us-ascii?q?3qBMoEBggQBAQYEBIU9DQuCEwMGgToBgniEDAEBhlknHIFJQoEVQ4FfgQA+g?= =?us-ascii?q?h5CAQECAYFDAhorgmo2giuBWWsIYgEDIhkICAYCgQUTKgg6DgELDZEOg16He?= =?us-ascii?q?oNWiTOQVzlbCoMQiXmNc4VZEINUoU6VL4IWiWmDHY9PCoRrAgQCBAUCDgEBB?= =?us-ascii?q?oEjMgE4gVlwFYMkUBcCDo4fDBaDToUUhUlzAjYCBgEJAQEDCXyJTQICJAeBB?= =?us-ascii?q?wEyXQEB?= IronPort-PHdr: A9a23:QR9PKBTIXKcFzjXpuexCxW+JVdpso0/LVj590bIulq5Of6K//p/rI E3Y47B3gUTUWZnAg9pLjuPXt+brXmlTqZqCsXVXdptKWldFjMgNhAUvDYaDDlGzN//laSE2X aEgHF9o9n22Kw5ZTcD5YVCBrXi77DpUERL6ZkJ5I+3vEdvUiMK6n+m555zUZVBOgzywKbN/J Rm7t0PfrM4T1IBjMa02jBDOpyggRg== IronPort-HdrOrdr: A9a23:LnOtj6mCba2jWhiYsfdqslUuFirpDfN2jmdD5ilNYBxZY6Wkvu iUtrAyyQL0hDENWHsphNCHP+26TWnB8INuiLNxAZ6LZyOjnGezNolt4c/ZwzPmEzDj7eI178 ldWoBEIpnLAVB+5PyU3CCRGdwt2cTC1aiui/vXwXsFd3AXV4hL6QBlBgGHVmh/QwdbDZQ0fa DsmfZvjTymZHgRc4CHFmAINtKz6OHjubDHRVo9BxAh4BSTlj/A0t7HOjWRwxt2aUI2/Z4M6m 7A+jaJg5mLk/b+8RPE0n+W0pI+oqqd9vJmJOihzvcYMS/tjAHAXvUuZ5SnsCouqO+irHYG+e O82CsIBMh453PPcmzdm3KEsGOMvEdMmh3f4GSVjnf5rcvySChSMbs6uatibhDb50A81esMt5 5j4mODu5JbSTPGkSjtjuK4Li1Cq0uurXIu1dMUlnxUOLFuDoN5kIp3xjIwLL4wWAbBrKw3Gu hnC8/RoNxMd0mBUnzftm5zhPSxQ3UaBH69Mwk/k/3Q9wITsGFyzkMeysBatGwH7ogBR55N4P mBGrh0lYtJUtQdYctGdac8aPryLlaIbQPHMWqUL1iiProAIWjxp5n+56hww+22ZpoSzt8XlI 7aWF1V8U4+EnieSvGm7dluyFTgUW+9VTPixoV1/J5ioIDxQ7LtLGmNU1Yrn8y8o+gOA8HSVv qpUagmRsPLHC/LI8Jkzgf+U55dJT01S8sOoOs2XFqIv4bKJ+TRx6jmWceWAICoPScvW2v5DH dGdiP0Pt984keiXWK9hBDQXnjqa1Hu5J4YKtmcw8EjjKw2cqFcuAkcjlq0ouuRLydZj6AwdE xiZLX9kq26omGy9X3S73pgPwdcCko92sSjb1p64Ssxd2/ke7cKvNuSPUpI2mGcGxN5R8TKVB JEq09v4qKxJZyIzSUkA9aqW1jqyUc7lTavddMxi6eD7cDqdtcEFZ4gQrV2DhiOPQdygxxWpG BKbxIkSkfTGij1s7isiIUZCYjkBoBBqTbuBfQRiHrE8W2AuMkkRxIgLkCTeP/SpTxreh15qR la9bQFjL+JhDC1QFFP8dgQARlrc2SYALVPEQKfQp5b84qbID1YfCOtmSGQjQ01dy7M8Ugf71 aRdxG8SLXsHkdXvGxe3+LR1G5MMk+Zf052dxlBwNZAPGzbp3d+1vKKbKKv022XLkAP2P0ZLS utW0pjHip+g9+wzxKbgzCECDEvwYgvJPXUCPA5f6jUwW7FEvzDqYgWW/tV9o1iLtbgr6sCVv +eYRacKFrDeqsU8h3QonYuIy9vrnY41fvuxR3+9WC9mHoyG+DbLlgjR7YVJbinniPZbufN1J VyltQuu+Ssdm33d96d0KnSKydZNQm7mx/Ac8g47ZRP+a4ivrp6GJfWFTPOyXFcxR07aMP5jl kXTqh36K3IU7UfMvA6amZc5B4khd6PJEwkvkjtDugycUokgnXbM9mKioC44IYHEwmEvk/9KF Of+ypS87PZRCOFz6cdEL91LmJMakQwgU4SsN+qZsnVEkGteO5C9lbhbSP4f79ZVaSfGbIf6h x9+MqFmueLdyz+nADc1AELV55m4iKiW4e1BgnJBOtDt9q9Ml6IirGx4MGygCzsIAHLHXgwlM lAbwgIcs9HijM+l4U53Si5V7zvrise4iljyCAikkSox5Ov72jaF1xXKAHVgp1ZWj9IL3iD5P 61hdSwxTD6+zhK2Z7KCUdWcJVPArErP/vKExs= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.82,268,1613433600"; d="scan'208,217";a="692827641" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 03 May 2021 10:36:14 +0000 Received: from mail.cisco.com (xbe-aln-006.cisco.com [173.36.7.21]) by alln-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 143AaEnm022266 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Mon, 3 May 2021 10:36:14 GMT Received: from xfe-aln-004.cisco.com (173.37.135.124) by xbe-aln-006.cisco.com (173.36.7.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Mon, 3 May 2021 05:36:14 -0500 Received: from xfe-rcd-002.cisco.com (173.37.227.250) by xfe-aln-004.cisco.com (173.37.135.124) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Mon, 3 May 2021 05:36:13 -0500 Received: from NAM04-MW2-obe.outbound.protection.outlook.com (72.163.14.9) by xfe-rcd-002.cisco.com (173.37.227.250) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3 via Frontend Transport; Mon, 3 May 2021 05:36:13 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=b4+ZvSb+xVfmeLvvCvX96dBk+r95Zw4wA3hNshMz0R7520TfH3CPa2LqRL0RE1nEMq7PT26FoOJyqKvNAqvIpeqNOhzhX+cqzvCd0ubtzNY6C+QRiS2oxz5WIws+zRvDYBUvZgwybMUxFq7vDU04/gB2CJridY5v+e95gpNq2YFNHvUyNWhDeV5PVXfan/xYYsiDDliMzNyv/yeA7YU8uWnD8ViWvm5VMe1rB9OY1Okcj4NDWMd6EnkiI+g1LKmTI2qGCNfhKHSosMYnbt+cMLPVAt1UXsBpVNJqQxNgGxX/XYgM5qe9mvNjloOyZIQsmcuRSM4NEvPQM2eV12u1SA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=itKBnU2/VqWuIUW2ERydRVjpuEl07qT7SRd6uRIIC5k=; b=awn/g/wzbmuOvVX4Ehz9XqXKa+T8TJsgnjh+ZUZmuxlCAAwPJpmQOQec/aqw5ahAJy64gZTDA/CAar1HdMpK0rvhGDThzqr4rzx8kM3Hc+K/c4u+F0cpuAd0jSYPSEzVEYsCm/tCVzG5b4ExkZELpqepfpkUk14XaN1drcWlh+SJoIWxYBxZcLt9PlE8muKzJZ5Cn2FdFejlNXzjZpjB00M3Tkvz81tzKQbzvBf5hsyKly6sciEvlSl+oeZOv50lG+z7PPZpC6qNpHVy0WZ24yWSXlOQmn5S74lT130R1nyUDZEVrfnTusfyTz0ifVC8V2wjQd45MQF3wiqCQRfDBg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=itKBnU2/VqWuIUW2ERydRVjpuEl07qT7SRd6uRIIC5k=; b=EGavVyl696F1tZgDU03gkWepUzvaUzQcpwTuOE261adkN72TuAAlfDUQ1UJ3RdKGmAb7hYLBmAa2xjNMnq2GBkCYmi+ppqf1tC7RF05qFjxTTuYJfEhDYgWARbWNlFp1H+GpsLU/ssDALUGPmw2QPw2xyiNcsqVQ4kDQWvbZCVI= Received: from DM6PR11MB3194.namprd11.prod.outlook.com (2603:10b6:5:5c::25) by DM6PR11MB3594.namprd11.prod.outlook.com (2603:10b6:5:13b::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4087.44; Mon, 3 May 2021 10:36:12 +0000 Received: from DM6PR11MB3194.namprd11.prod.outlook.com ([fe80::e4e0:cf18:7be1:8019]) by DM6PR11MB3194.namprd11.prod.outlook.com ([fe80::e4e0:cf18:7be1:8019%7]) with mapi id 15.20.4087.043; Mon, 3 May 2021 10:36:12 +0000 From: "Juan Alcaide (jalcaide)" To: =?utf-8?B?TWFnbnVzIE55c3Ryw7Zt?= , "secdir@ietf.org" , "draft-ietf-idr-bgp-flowspec-oid@ietf.org" Thread-Topic: Secdir review of draft-ietf-idr-bgp-flowspec-oid-13 Thread-Index: AQHXP9b+AhhGGu0YA0eUTG7ppR6g/arRhrnQ Date: Mon, 3 May 2021 10:36:11 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [83.38.90.229] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6fb80b48-351e-4a65-280c-08d90e1f4577 x-ms-traffictypediagnostic: DM6PR11MB3594: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: NDqGq+jEgkCGqC7lMyjKmh5LjUVJzeqM3u5ti9eC9OxWPUtKcQvlIpWzUBku8mjAXBDkcflbP2JHeWymgC9Vzp399t+0FQS2H+9M0jI8B863mI3B4s/V+1t1JBXtQXlPVRye4ExjA5XD8gDMSK9Day1xl5Gv35rv2jSlLP5g/1hH6WDyeJCm9YbfW/3Iw71YO9bgjeBQ8M9737HfG+9J0S9JFVvCJuiHAeIoRTtRzryO9JzvlL87DmZzQiOm2r/5iILDnu/MMV6zWKGAM1H4sa2OSnGErICyYT62t812WIyo0wYTFlfPdLI7PDf52g33QRUFjd//N3KOvHZBFWKKp5loVm28avkIvRUY16gs0++UITHOBzyZZVJL1LzybX57yrllZwm+rCud+uvRAm9XQWVFOW2I7ILUskKhqfp0Kx+WBuiaaH1dYLFcTQF8jZcBC8O7enBcJphZZk++2LYqxWqQCNRZ8L+0XOy7+qszCa4Bkph5VRfBy2/fi0zy5HbK+DRGWD8T9Eg86QnbAedWjzLmoO8gbgMymyVfk4gEA3aYZLVnovFVxiFO+Llyjl/ofalBzbRUd8fNrqMItQ02uk9DjA0fIvTb/Yt29M1c11biEb/K/Zi4d9aZX69fG7m+89wGIqrzjhMUl48ujU3UVSDnZb8JAl2zhNtGg1TgomVbfsNhDK8CkMs8YBnnAwJm x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR11MB3194.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(376002)(396003)(136003)(346002)(39860400002)(366004)(478600001)(38100700002)(33656002)(52536014)(186003)(66574015)(26005)(5660300002)(8676002)(83380400001)(8936002)(66556008)(76116006)(66476007)(66946007)(316002)(2906002)(7696005)(55016002)(9686003)(122000001)(53546011)(6506007)(86362001)(110136005)(71200400001)(64756008)(66446008)(166002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?eXhKRXJiWkVjbytWNXFZRHE0MEZHVTU0VlloYlROdGpFV1IvbGhFVTdvaW9G?= =?utf-8?B?QTAveVRxSHBWMFl5V3d4L21aK1RyNjRWUkw5V1RnbWVOOWJMTUdIN2w0T3pM?= =?utf-8?B?TC8yQWNvS2xOUlF6WDVGM2RlVjNRMkl6TEh6ZFZ5U3NhVzNqUW1oY281ZklP?= =?utf-8?B?ODNRL1g2QUNKRWZGdy9lOVNPdDR4bExmdTYvWWQ2Z0NQQlliSGFPdm1KUHJs?= =?utf-8?B?b2R4YXRNSzFKQTNIai9Nbmc4L0ZlTnQ0UXR0UGNxalI5MUpZYzJmOUNvWFBK?= =?utf-8?B?elpPWU5HcjkyRUlxSS9iaWZBUWhhNHRUM01walVRSVEvWlRIYiszTHd3YXA0?= =?utf-8?B?RlU4UWkrczZYWUNZN29VQ3pwcCt1dTBLY0xIczlRdmtia2Q5M25hOVBjSzhm?= =?utf-8?B?dDlVbzVZQXFtc09aS3ZCWW8xK1VjK2VyZkdyZEVYUE1mWTYveUZLdGtJWlph?= =?utf-8?B?Z0VDQzExNE8vY3hqVExqVGs4UGdCaTgxOTllRXlyQklmQ2Yzc2VXSnpUdnVa?= =?utf-8?B?T1puVmtJR1paRGtwVjV3bHVoMDJsOW5DeUpXVWZUenl2QzRxaXUxOVhzY3p0?= =?utf-8?B?b3JMU1lZdXdYcGRRM0l3SzVabTJmUGxzZ3FaQnk3TnU5RTlXQlluaVh1dEo4?= =?utf-8?B?YVAzZkdMYVpuMFQwVEZrZXFPditZQjJQa3JyZWgvQTJyMFlkemVpZm15SytN?= =?utf-8?B?VVFIREN3TWozcnR6T0puMGhXcS93OFFXbTZXWnlrQUJWdEpORmQrb3ZvSC9E?= =?utf-8?B?RkxzYmtFWDZ5cVpJNTcrR2JCSGRLb3FBZTcvb2xVc01nQ1J4YmNGM2F3TWdT?= =?utf-8?B?MkxsNWFHK2tyTlRPQnpSNGJXSTV6M2pwekc4UmFYOVFFS1BtREZwL29jakhF?= =?utf-8?B?dGR6MGpGYzhmVDVoc3pkSUVRRm1oY0ttWkdnYXAzWVJ2MDFhci9nSTQ4dk1N?= =?utf-8?B?NzBPeTBPa3hIQ01wSjZObkZtakErYmptZVpXdTdFeW10ZFZwOTc2UUVkbXJo?= =?utf-8?B?V29Td01ybGJmeCtDdkJRRUo1dnA1cG0zNThhMmw1bTJkK2t3cmxHL2hHN1Vr?= =?utf-8?B?ZFp5NU9NaEF4Sm02M1JRYVpvelZMTlpPNmU3aEJPbkk2ZVVkZTdySnJ6THJB?= =?utf-8?B?UHNFZUdUM1h3L2JwZHBNUG1UMEtoc1RUakRoeEV4ZjZSbWNtWkc1V1pRSGl1?= =?utf-8?B?YjNsMERzVXYvaE44WFo1Y0IzWUJsZ0Y0Q1JVRFZsZytlWlhlemR1VmdkTnM1?= =?utf-8?B?T1VJZEtIOHA4b01Ya0VFc2hQT2M1d2t0UjBPQ1dqY0lUSG5sakl5SWxkU3Fr?= =?utf-8?B?UnNGdEFOMUVLUytWVm5odDNmWlAvdEJhOTB5VFVMZzlGYjFwSCtBRVlhbmFG?= =?utf-8?B?N08yZ1U4cUxJYjlaVWFqSS8xUlF3Tzd6eUNZVytabFYvbytidDE1ZStzTllN?= =?utf-8?B?TDBjUmV4NGVkekVTOCs2OGs1cFlGcGlmWUtpcWg4UmxORm5Oc1pCSEZFR2lO?= =?utf-8?B?dnlIcFpxU1pTT3hsTGtESDlDS3pJNE1XTGo5Sy8rdUFiU0EzSElxcUFFdHRh?= =?utf-8?B?SGVRQythK1lRZEg0N3VnSTBObjg1dVMzR3dHMVp4Y2s3THdKMzJGQXNmbVhK?= =?utf-8?B?aFdVbVQ0QUlQN1VPbWVURk5RVDI2TU9LK3EvR3N5Tjk0cVgwYmUwZjZyQklV?= =?utf-8?B?Mlorcjl5cnNMc1hCc05nU3ZveEFVamVZMTN5ZTBiTmV1anYrRDJjY3JCZGZ4?= =?utf-8?Q?Sl0FB60Z4+AIQ17W70=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR11MB3194503DF53A14C12FC749E4CD5B9DM6PR11MB3194namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR11MB3194.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6fb80b48-351e-4a65-280c-08d90e1f4577 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 May 2021 10:36:12.0388 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: c0ReMNuARkcREXkG+VMZpcZHlVkZvsA5xNDdUvw76yXe6mKaCSblmjpR/s4tlyaU97UgP/wLRn0hStVzI6yxKg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB3594 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.21, xbe-aln-006.cisco.com X-Outbound-Node: alln-core-5.cisco.com Archived-At: Subject: Re: [secdir] Secdir review of draft-ietf-idr-bgp-flowspec-oid-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2021 10:36:22 -0000 --_000_DM6PR11MB3194503DF53A14C12FC749E4CD5B9DM6PR11MB3194namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLCBNYWdudXMNCg0KSW5saW5lLi4NCg0KRnJvbTogTWFn bnVzIE55c3Ryw7ZtIDxtYWdudXNuQGdtYWlsLmNvbT4NClNlbnQ6IE1vbmRheSwgTWF5IDMsIDIw MjEgNjo0NCBBTQ0KVG86IHNlY2RpckBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1pZHItYmdwLWZsb3dz cGVjLW9pZEBpZXRmLm9yZw0KU3ViamVjdDogU2VjZGlyIHJldmlldyBvZiBkcmFmdC1pZXRmLWlk ci1iZ3AtZmxvd3NwZWMtb2lkLTEzDQoNCkkgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFz IHBhcnQgb2YgdGhlIHNlY3VyaXR5IGRpcmVjdG9yYXRlJ3Mgb25nb2luZyBlZmZvcnQgdG8gcmV2 aWV3IGFsbCBJRVRGIGRvY3VtZW50cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhlIElFU0cuIFRoZXNl IGNvbW1lbnRzIHdlcmUgd3JpdHRlbiBwcmltYXJpbHkgZm9yIHRoZSBiZW5lZml0IG9mIHRoZSBz ZWN1cml0eSBhcmVhIGRpcmVjdG9ycy4gIERvY3VtZW50IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBz aG91bGQgdHJlYXQgdGhlc2UgY29tbWVudHMganVzdCBsaWtlIGFueSBvdGhlciBsYXN0IGNhbGwg Y29tbWVudHMuDQoNClRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzICJhIG1vZGlmaWNhdGlvbiB0byB0 aGUgdmFsaWRhdGlvbiBwcm9jZWR1cmUgZGVmaW5lZCBmb3IgdGhlIGRpc3NlbWluYXRpb24NCm9m IEJHUCBGbG93IFNwZWNpZmljYXRpb25zLiIgTW9yZSBzcGVjaWZpY2FsbHkuIHRoZSBtZW1vIGRl c2NyaWJlcyBhIG1lY2hhbmlzbSB3aGljaCByZWxheGVzICB0aGUgZXhpc3RpbmcgdmFsaWRhdGlv biBydWxlIHRoYXQgcmVxdWlyZXMgRmxvdyBTcGVjaWZpY2F0aW9ucyB0byBiZSBvcmlnaW5hdGlu ZyBmcm9tIHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBiZXN0LW1hdGNoIHVuaWNhc3Qgcm91dGUsIGFu ZCBub3cgYWxsb3dzIHN1Y2ggc3BlY2lmaWNhdGlvbnMgdG8gYmUgb3JpZ2luYXRlZCB3aXRoaW4g dGhlIHNhbWUgQVMgYXMgdGhlIHZhbGlkYXRvci4gQXMgYSByZXN1bHQuIHRoZSBTZWN1cml0eSBD b25zaWRlcmF0aW9ucyBzZWN0aW9uIGRvZXMgY2FsbCBvdXQ6ICJUaGUgb3JpZ2luYWwgQVNfUEFU SCB2YWxpZGF0aW9uIHJ1bGUgKFtSRkM0MjcxXSBzZWN0aW9uIDYuMzxodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvcmZjNDI3MSNzZWN0aW9uLTYuMz4pIGJlY29tZXMgIGhlcmVieSBvcHRpb25h bCAoc2VjdGlvbiA0LjI8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtaWRy LWJncC1mbG93c3BlYy1vaWQtMTMjc2VjdGlvbi00LjI+KS4gSWYgdGhhdCBvcmlnaW5hbCBydWxl IGlzIGFjdHVhbGx5IG5vdCBlbmZvcmNlZCBpdCBtYXkgaW50cm9kdWNlIHNvbWUgc2VjdXJpdHkg cmlza3MuIEEgcGVlciAob3IgYSBjbGllbnQgb2YgYSByb3V0ZSBzZXJ2ZXIgcGVlcikgaW4gQVMg WCBjb3VsZCBhZHZlcnRpc2UgYSByb2d1ZSBGbG93IFNwZWNpZmljYXRpb24gcm91dGUuLi4uIiBh bmQgIklmIHRbdGhlIG9yaWdpbmF0b3Igb2YgYSBydWxlXSBpcyBrbm93biBmb3IgYSBmYWN0IG5v dCB0byBiZSBhIHJvdXRlIHNlcnZlciwgdGhhdCBvcHRpb25hbCBydWxlIFNIT1VMRCBiZSBlbmZv cmNlZCBmb3IgRmxvdyBTcGVjaWZpY2F0aW9uIHJvdXRlcy4iDQoNCkl0IGlzIG5vdCBjbGVhciB0 byBtZSBob3cgYSB2YWxpZGF0b3Igd291bGQgbm93ICJmb3IgYSBmYWN0IiB0aGF0IGEgcGVlciBp c24ndCBhIHJvdXRlIHNlcnZlciwgYW5kIHRodXMgdGhhdCBpdCB3b3VsZCBoYXZlIHRvIGVuZm9y Y2UgdGhlIG5vdy1vcHRpb25hbCBwYXRoIHZhbGlkYXRpb24gcnVsZS4gSXQgc2VlbXMgc29tZSBj bGFyaXR5IG9uIHRoaXMgd291bGQgYmUgZ29vZCBzdWNoIHRoYXQgaW1wbGVtZW50YXRpb25zIGhh dmUgbGVzcyBvZiBhIHJpc2sgb2YgYWNjZXB0aW5nIGZsb3cgc3BlY2lmaWNhdGlvbnMgZnJvbSB1 bmF1dGhvcml6ZWQgcGFydGllcywgZXZlbiBpZiB0aGV5IGFyZSBvbiB0aGUgc2FtZSBBUy4NCg0K W0pVQU5dOiBUaGlzIHBhcmFncmFwaCB3YXMgbm90IGludGVuZGVkIHRvIHByZXNzdXJlIHRoZSBv cGVyYXRvciB0byBrbm93IGlmIHRoZSBwZWVyIHdhcyBhIHJvdXRlIHNlcnZlciwgaXQgd2FzIGp1 c3QgYSDigJhpZuKAmS4gTm90ZSBpdOKAmXMgdGhlIHNhbWUgY2FzZSBmb3IgUkZDNDI3MSA6DQoN CklmIHRoZSBVUERBVEUgbWVzc2FnZSBpcyByZWNlaXZlZCBmcm9tIGFuIGV4dGVybmFsIHBlZXIs IHRoZSBsb2NhbA0KICAgc3lzdGVtIE1BWSBjaGVjayB3aGV0aGVyIHRoZSBsZWZ0bW9zdCAod2l0 aCByZXNwZWN0IHRvIHRoZSBwb3NpdGlvbg0KICAgb2Ygb2N0ZXRzIGluIHRoZSBwcm90b2NvbCBt ZXNzYWdlKSBBUyBpbiB0aGUgQVNfUEFUSCBhdHRyaWJ1dGUgaXMNCiAgIGVxdWFsIHRvIHRoZSBh dXRvbm9tb3VzIHN5c3RlbSBudW1iZXIgb2YgdGhlIHBlZXIgdGhhdCBzZW50IHRoZQ0KICAgbWVz c2FnZS4NCg0KDQpOb3RlIHRoYXQgdGhlIHNhbWUgY2hhbGxlbmdlIG9mIGlkZW50aWZ5aW5nIHJv dXRlIHNlcnZlcnMgYXBwbGllcyBmb3Igb3RoZXIgYWRkcmVzcy1mYW1pbGllcy4NCk5vdGUgYWxz byB0aGF0IHRoZSByb3V0ZS1zZXJ2ZXIgaXRzZWxmIG1heSBlbmZvcmNlIHRoZSBydWxlLg0KDQpX aGF0IGFib3V0IGZvciBjbGFyaXR5Og0KDQogICBUaGUgb3JpZ2luYWwgQVNfUEFUSCB2YWxpZGF0 aW9uIHJ1bGUgKFtSRkM0MjcxXSBzZWN0aW9uIDYuMykgcmVtYWlucyBoZXJlYnkgc3RpbGwgb3B0 aW9uYWwNCiAgIChzZWN0aW9uIDQuMikgZm9yIEZsb3cgU3BlY2lmaWNhdGlvbiBBZGRyZXNzIEZh bWlseSAoY2hhbmdlcyBpbnRyb2R1Y2VkIGluIFtSRkM1NTc1XSBhcmUgY2FuY2VsbGVkKS4NCiAg IElmIHRoYXQgb3JpZ2luYWwgcnVsZSBpcyBub3QgZW5mb3JjZWQgZm9yIEZsb3cgU3BlY2lmaWNh dGlvbiBpdCBtYXkgaW50cm9kdWNlIHNvbWUgbmV3IHNlY3VyaXR5IHJpc2tzLg0KICAgQSBwZWVy IChvciBhIGNsaWVudCBvZiBhIHJvdXRlIHNlcnZlciBwZWVyKSBpbiBBUyBYIGNvdWxkIGFkdmVy dGlzZSBhIHJvZ3VlIEZsb3cNCiAgIFNwZWNpZmljYXRpb24gcm91dGUgd2hvc2UgZmlyc3QgQVMg aW4gQVNfUEFUSCB3YXMgWSAoYXNzdW1lIFkgaXMgdGhlDQogICBmaXJzdCBBUyBpbiB0aGUgQVNf UEFUSCBvZiB0aGUgYmVzdC1tYXRjaCB1bmljYXN0IHJvdXRlKS4gIFRoaXMgcmlzaw0KICAgaXMg aW1wb3NzaWJsZSB0byBwcmV2ZW50IGlmIHRoZSBGbG93IFNwZWNpZmljYXRpb24gcm91dGUgaXMg cmVjZWl2ZWQNCiAgIGZyb20gYSByb3V0ZSBzZXJ2ZXIgcGVlci4gIElmIHRoYXQgcGVlciBpcyBr bm93biBmb3IgYSBmYWN0IG5vdCB0byBiZQ0KICAgYSByb3V0ZSBzZXJ2ZXIsIHRoYXQgb3B0aW9u YWwgcnVsZSBTSE9VTEQgYmUgZW5mb3JjZWQgZm9yIEZsb3cNCiAgIFNwZWNpZmljYXRpb24gcm91 dGVzLiBOb3RlIHRoYXQgaWRlbnRpZnlpbmcgdGhvc2UgcGVlcnMgdGhhdCBhcmUgcm91dGUgc2Vy dmVycyBtYXkgc3VwcG9zZSBhbg0KICAgb3BlcmF0aW9uYWwgY2hhbGxlbmdlLiBJZiB0aGUgY29u ZGl0aW9uIG9mIHRoZSBwZWVyIGlzIHVua25vd24sIHRoZSBydWxlIFNIT1VMRCBub3QgYmUNCiAg IGVuZm9yY2VkLg0KDQogICBBIHJvdXRlIHNlcnZlciBpdHNlbGYgbWF5IGJlIGluIGEgZ29vZCBw b3NpdGlvbiB0byBlbmZvcmNlIHRoZSBBU19QQVRIIHZhbGlkYXRpb24gcnVsZSBkZXNjcmliZWQN CiAgaW4gdGhlIHByZXZpb3VzIHBhcmFncmFwaC4gSWYgYSByb3V0ZSBzZXJ2ZXIga25vd25zIGl0 4oCZcyBub3QgcGVlcmluZyB3aXRoIGFueSBvdGhlciByb3V0ZSBzZXJ2ZXIsDQogICBpdCBjYW4g ZW5mb3JjZSB0aGUgQVNfUEFUSCB2YWxpZGF0aW9uIHJ1bGUgYWNyb3NzIGFsbCBpdHMgcGVlcnMu IElmLCBpbiBhZGRpdGlvbiB0byB0aGF0LA0KICAgdGhlIHJvdXRlIHNlcnZlciBpcyB0cnVzdGVk LCB0aGUgc2VjdXJpdHkgdGhyZWF0IGRlc2NyaWJlZCBhYm92ZSBkaXNhcHBlYXJzLg0KDQoNCg0K QW55Ym9keSBmZWVsIGZyZWUgdG8gcmV3b3JkIHRoZSB0d28gcGFyYWdyYXBocyBhYm92ZSBpZiBp dCBoZWxwcyB0aGVtIGZvciBjbGFyaXR5Lg0KDQoNCg0KRWRpdG9yaWFsOg0KDQogICogICAiTGV0 J3MgY29uc2lkZXIgdGhlIHBhcnRpY3VsYXIgY2FzZSB3aGVyZSB0aGUgRmxvdyBTcGVjaWZpY2F0 aW9uIGlzIG9yaWdpbmF0ZWQgaW4gYW55IGxvY2F0aW9uIHdpdGhpbiB0aGUgc2FtZSBhdXRvbm9t b3VzIHN5c3RlbSB0aGFuIHRoZSBzcGVha2VyIHBlcmZvcm1pbmcgdGhlIHZhbGlkYXRpb24gKGZv ciBleGFtcGxlIGJ5IGEgY2VudHJhbGl6ZWQgQkdQIHJvdXRlIGNvbnRyb2xsZXIpLCBhbmQgdGhl IGJlc3QtbWF0Y2ggdW5pY2FzdCByb3V0ZSBpcyBvcmlnaW5hdGVkIGluIGFub3RoZXIgYXV0b25v bW91cyBzeXN0ZW0uIiAtIHNob3VsZCB0aGUgd29yZCAidGhhbiIgYmUgcmVwbGFjZWQgd2l0aCAi dGhhdCIgaGVyZT8NCltKVUFOXTogVGhhbmtzIGZvciBwb2ludGluZyB0aGF0IG91dC4gQSBmZXcg Z29vZ2xpbmcgdGVsbHMgbWUgdGhlIGV2ZW4gYmV0dGVyIGdyYW1tYXRpY2FsIGNob2ljZSB3b3Vs ZCBiZSDigJhzYW1lIGFz4oCZIGluIHRoaXMgY2FzZS4gSeKAmWxsIGJlIHVzaW5nIOKAmHNhbWUg YXPigJkgdW5sZXNzICB5b3UgZGlzYWdyZWUuDQoNCg0KICAqICAgSW4gdGhlIHNlY3VyaXR5IGNv bnNpZGVyYXRpb25zIHNlY3Rpb24sICJiZWNvbWVzIGhlcmVieSBvcHRpb25hbCIgY291bGQgcHJv YmFibHkgYmUgc2ltcGxpZmllZCB0byAiYmVjb21lcyBvcHRpb25hbCIgb3Igc2ltaWxhciwgYW5k ICJhY3R1YWxseSIgY291bGQgYmUgcmVtb3ZlZC4NCltKVUFOXTogIEhtbW0sIEkgdGhvdWdodCB0 aGF0IGl0IHdhcyBpbXBvcnRhbnQgdG8gZW1waGFzaXplIGl0IGJlY29tZXMgb3B0aW9uYWwgYmVj YXVzZSBvZiAqdGhpcyogZHJhZnQgcmVkZWZpbml0aW9uIG9mIHJ1bGVzLiBEb27igJl0IHlvdSB0 aGluayBpdOKAmXMgaW1wb3J0YW50PyAod2hhdGV2ZXIgd29yZGluZyB5b3Ugd2FudCB0byB1c2Up LiBSZWdhcmRsZXNzLCByZWZlciB0byBteSBuZXcgcmV3b3JkZWQgMiBwYXJhZ3JhcGhzIGFib3Zl IGZvciB0aGF0IHNlY3Rpb24gLg0KDQoNCg0KDQpUaGFua3MsDQotLSBNYWdudXMNCg0K --_000_DM6PR11MB3194503DF53A14C12FC749E4CD5B9DM6PR11MB3194namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0K CXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47 DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7 DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENo YXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZv bnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNv bG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3Qg RGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjE5MTY1NDcyNzk7DQoJbXNv LWxpc3QtdGVtcGxhdGUtaWRzOjExODk0OTE2NDI7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0K CW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxldmVs Mw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBs aXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0K CW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt c3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2lu Z2RpbmdzO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJ e21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh ZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIiBzdHlsZT0i d29yZC13cmFwOmJyZWFrLXdvcmQiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlRoYW5rcyBmb3IgeW91ciBjb21tZW50cywgTWFnbnVzPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPklubGluZS4uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBNYWdudXMgTnlzdHLDtm0gJmx0O21hZ251 c25AZ21haWwuY29tJmd0OyA8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBNYXkgMywgMjAyMSA2 OjQ0IEFNPGJyPg0KPGI+VG86PC9iPiBzZWNkaXJAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtaWRyLWJn cC1mbG93c3BlYy1vaWRAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gU2VjZGlyIHJldmll dyBvZiBkcmFmdC1pZXRmLWlkci1iZ3AtZmxvd3NwZWMtb2lkLTEzPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhcyBwYXJ0 IG9mIHRoZSBzZWN1cml0eSBkaXJlY3RvcmF0ZSdzIG9uZ29pbmcgZWZmb3J0IHRvIHJldmlldyBh bGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkIGJ5IHRoZSBJRVNHLiBUaGVzZSBjb21t ZW50cyB3ZXJlIHdyaXR0ZW4gcHJpbWFyaWx5IGZvciB0aGUgYmVuZWZpdCBvZiB0aGUgc2VjdXJp dHkgYXJlYSBkaXJlY3RvcnMuJm5ic3A7IERvY3VtZW50DQogZWRpdG9ycyBhbmQgV0cgY2hhaXJz IHNob3VsZCB0cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0IGxpa2UgYW55IG90aGVyIGxhc3QgY2Fs bCBjb21tZW50cy48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzICZxdW90O2EgbW9kaWZpY2F0aW9uIHRvIHRoZSB2YWxp ZGF0aW9uIHByb2NlZHVyZSBkZWZpbmVkIGZvciB0aGUgZGlzc2VtaW5hdGlvbg0KPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5vZiBCR1AgRmxvdyBT cGVjaWZpY2F0aW9ucy4mcXVvdDsgTW9yZSBzcGVjaWZpY2FsbHkuIHRoZSBtZW1vIGRlc2NyaWJl cyBhIG1lY2hhbmlzbSB3aGljaCByZWxheGVzJm5ic3A7IHRoZSBleGlzdGluZyB2YWxpZGF0aW9u IHJ1bGUgdGhhdCByZXF1aXJlcyBGbG93IFNwZWNpZmljYXRpb25zIHRvIGJlIG9yaWdpbmF0aW5n IGZyb20gdGhlIG9yaWdpbmF0b3Igb2YgdGhlIGJlc3QtbWF0Y2ggdW5pY2FzdCByb3V0ZSwgYW5k IG5vdw0KIGFsbG93cyBzdWNoIHNwZWNpZmljYXRpb25zIHRvIGJlIG9yaWdpbmF0ZWQgd2l0aGlu IHRoZSBzYW1lIEFTIGFzIHRoZSB2YWxpZGF0b3IuIEFzIGEgcmVzdWx0LiB0aGUgU2VjdXJpdHkg Q29uc2lkZXJhdGlvbnMgc2VjdGlvbiBkb2VzIGNhbGwgb3V0OiAmcXVvdDtUaGUgb3JpZ2luYWwg QVNfUEFUSCB2YWxpZGF0aW9uIHJ1bGUgKDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9yZmM0MjcxI3NlY3Rpb24tNi4zIj5bUkZDNDI3MV0gc2VjdGlvbiZuYnNwOzYuMzwvYT4p DQogYmVjb21lcyZuYnNwOyBoZXJlYnkgb3B0aW9uYWwgKDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWlkci1iZ3AtZmxvd3NwZWMtb2lkLTEzI3NlY3Rpb24t NC4yIj5zZWN0aW9uIDQuMjwvYT4pLiBJZiB0aGF0IG9yaWdpbmFsIHJ1bGUgaXMgYWN0dWFsbHkg bm90IGVuZm9yY2VkIGl0IG1heSBpbnRyb2R1Y2Ugc29tZSBzZWN1cml0eSByaXNrcy4gQSBwZWVy IChvciBhIGNsaWVudCBvZiBhIHJvdXRlIHNlcnZlciBwZWVyKQ0KIGluIEFTIFggY291bGQgYWR2 ZXJ0aXNlIGEgcm9ndWUgRmxvdyBTcGVjaWZpY2F0aW9uIHJvdXRlLi4uLiZxdW90OyBhbmQgJnF1 b3Q7SWYgdFt0aGUgb3JpZ2luYXRvciBvZiBhIHJ1bGVdIGlzIGtub3duIGZvciBhIGZhY3Qgbm90 IHRvIGJlIGEgcm91dGUgc2VydmVyLCB0aGF0IG9wdGlvbmFsIHJ1bGUgU0hPVUxEIGJlIGVuZm9y Y2VkIGZvciBGbG93IFNwZWNpZmljYXRpb24gcm91dGVzLiZxdW90OzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCBpcyBub3QgY2xlYXIgdG8g bWUgaG93IGEgdmFsaWRhdG9yIHdvdWxkIG5vdyAmcXVvdDtmb3IgYSBmYWN0JnF1b3Q7IHRoYXQg YSBwZWVyIGlzbid0IGEgcm91dGUgc2VydmVyLCBhbmQgdGh1cyB0aGF0IGl0IHdvdWxkIGhhdmUg dG8gZW5mb3JjZSB0aGUgbm93LW9wdGlvbmFsIHBhdGggdmFsaWRhdGlvbiBydWxlLiBJdCBzZWVt cyBzb21lIGNsYXJpdHkgb24gdGhpcyB3b3VsZCBiZSBnb29kIHN1Y2ggdGhhdCBpbXBsZW1lbnRh dGlvbnMNCiBoYXZlIGxlc3Mgb2YgYSByaXNrIG9mIGFjY2VwdGluZyBmbG93IHNwZWNpZmljYXRp b25zIGZyb20gdW5hdXRob3JpemVkIHBhcnRpZXMsIGV2ZW4gaWYgdGhleSBhcmUgb24gdGhlIHNh bWUgQVMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPltKVUFOXTogVGhp cyBwYXJhZ3JhcGggd2FzIG5vdCBpbnRlbmRlZCB0byBwcmVzc3VyZSB0aGUgb3BlcmF0b3IgdG8g a25vdyBpZiB0aGUgcGVlciB3YXMgYSByb3V0ZSBzZXJ2ZXIsIGl0IHdhcyBqdXN0IGEg4oCYaWbi gJkuIE5vdGUgaXTigJlzIHRoZSBzYW1lIGNhc2UgZm9yIFJGQzQyNzEgOjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+SWYgdGhlIFVQREFURSBtZXNzYWdlIGlz IHJlY2VpdmVkIGZyb20gYW4gZXh0ZXJuYWwgcGVlciwgdGhlIGxvY2FsPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNw OyZuYnNwOyBzeXN0ZW0gTUFZIGNoZWNrIHdoZXRoZXIgdGhlIGxlZnRtb3N0ICh3aXRoIHJlc3Bl Y3QgdG8gdGhlIHBvc2l0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBvZiBvY3RldHMgaW4gdGhl IHByb3RvY29sIG1lc3NhZ2UpIEFTIGluIHRoZSBBU19QQVRIIGF0dHJpYnV0ZSBpczxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr Ij4mbmJzcDsmbmJzcDsgZXF1YWwgdG8gdGhlIGF1dG9ub21vdXMgc3lzdGVtIG51bWJlciBvZiB0 aGUgcGVlciB0aGF0IHNlbnQgdGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBtZXNzYWdlLg0KPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPk5vdGUgdGhhdCB0aGUgc2FtZSBjaGFsbGVuZ2Ugb2YgaWRlbnRpZnlp bmcgcm91dGUgc2VydmVycyBhcHBsaWVzIGZvciBvdGhlciBhZGRyZXNzLWZhbWlsaWVzLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Tm90ZSBhbHNvIHRoYXQgdGhlIHJvdXRl LXNlcnZlciBpdHNlbGYgbWF5IGVuZm9yY2UgdGhlIHJ1bGUuPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPldoYXQgYWJvdXQgZm9yIGNsYXJpdHk6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgVGhlIG9yaWdpbmFsIEFTX1BBVEggdmFsaWRh dGlvbiBydWxlIChbUkZDNDI3MV0gc2VjdGlvbiA2LjMpIHJlbWFpbnMgaGVyZWJ5IHN0aWxsIG9w dGlvbmFsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyAoc2VjdGlvbiA0LjIpIGZvciBGbG93IFNwZWNp ZmljYXRpb24gQWRkcmVzcyBGYW1pbHkgKGNoYW5nZXMgaW50cm9kdWNlZCBpbiBbUkZDNTU3NV0g YXJlIGNhbmNlbGxlZCkuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7SWYgdGhhdCBvcmln aW5hbCBydWxlIGlzIG5vdCBlbmZvcmNlZCBmb3IgRmxvdyBTcGVjaWZpY2F0aW9uIGl0IG1heSBp bnRyb2R1Y2Ugc29tZSBuZXcgc2VjdXJpdHkgcmlza3MuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBB IHBlZXIgKG9yIGEgY2xpZW50IG9mIGEgcm91dGUgc2VydmVyIHBlZXIpIGluIEFTIFggY291bGQg YWR2ZXJ0aXNlIGEgcm9ndWUgRmxvdzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgU3BlY2lmaWNhdGlv biByb3V0ZSB3aG9zZSBmaXJzdCBBUyBpbiBBU19QQVRIIHdhcyBZIChhc3N1bWUgWSBpcyB0aGU8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjpibGFjayI+Jm5ic3A7Jm5ic3A7IGZpcnN0IEFTIGluIHRoZSBBU19QQVRIIG9mIHRoZSBiZXN0 LW1hdGNoIHVuaWNhc3Qgcm91dGUpLiZuYnNwOyBUaGlzIHJpc2s8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5i c3A7IGlzIGltcG9zc2libGUgdG8gcHJldmVudCBpZiB0aGUgRmxvdyBTcGVjaWZpY2F0aW9uIHJv dXRlIGlzIHJlY2VpdmVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBmcm9tIGEgcm91dGUgc2VydmVy IHBlZXIuJm5ic3A7IElmIHRoYXQgcGVlciBpcyBrbm93biBmb3IgYSBmYWN0IG5vdCB0byBiZTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OmJsYWNrIj4mbmJzcDsmbmJzcDsgYSByb3V0ZSBzZXJ2ZXIsIHRoYXQgb3B0aW9uYWwgcnVsZSBT SE9VTEQgYmUgZW5mb3JjZWQgZm9yIEZsb3c8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IFNwZWNpZmlj YXRpb24gcm91dGVzLiBOb3RlIHRoYXQgaWRlbnRpZnlpbmcgdGhvc2UgcGVlcnMgdGhhdCBhcmUg cm91dGUgc2VydmVycyBtYXkgc3VwcG9zZSBhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgb3BlcmF0 aW9uYWwgY2hhbGxlbmdlLiBJZiB0aGUgY29uZGl0aW9uIG9mIHRoZSBwZWVyIGlzIHVua25vd24s IHRoZSBydWxlIFNIT1VMRCBub3QgYmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGVuZm9yY2VkLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IEEgcm91dGUgc2VydmVyIGl0c2Vs ZiBtYXkgYmUgaW4gYSBnb29kIHBvc2l0aW9uIHRvIGVuZm9yY2UgdGhlIEFTX1BBVEggdmFsaWRh dGlvbiBydWxlIGRlc2NyaWJlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDtpbiB0aGUgcHJldmlvdXMg cGFyYWdyYXBoLiBJZiBhIHJvdXRlIHNlcnZlciBrbm93bnMgaXTigJlzIG5vdCBwZWVyaW5nIHdp dGggYW55IG90aGVyIHJvdXRlIHNlcnZlciw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGl0IGNhbiBl bmZvcmNlIHRoZSBBU19QQVRIIHZhbGlkYXRpb24gcnVsZSBhY3Jvc3MgYWxsIGl0cyBwZWVycy4g SWYsIGluIGFkZGl0aW9uIHRvIHRoYXQsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyB0aGUgcm91dGUg c2VydmVyIGlzIHRydXN0ZWQsIHRoZSBzZWN1cml0eSB0aHJlYXQgZGVzY3JpYmVkIGFib3ZlIGRp c2FwcGVhcnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Bbnlib2R5IGZlZWwgZnJlZSB0byByZXdvcmQgdGhl IHR3byBwYXJhZ3JhcGhzIGFib3ZlIGlmIGl0IGhlbHBzIHRoZW0gZm9yIGNsYXJpdHkuPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5FZGl0b3JpYWw6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8dWwgdHlw ZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8x Ij4NCiZxdW90O0xldCdzIGNvbnNpZGVyIHRoZSBwYXJ0aWN1bGFyIGNhc2Ugd2hlcmUgdGhlIEZs b3cgU3BlY2lmaWNhdGlvbiBpcyBvcmlnaW5hdGVkIGluIGFueSBsb2NhdGlvbiB3aXRoaW4gdGhl IHNhbWUgYXV0b25vbW91cyBzeXN0ZW0gdGhhbiB0aGUgc3BlYWtlciBwZXJmb3JtaW5nIHRoZSB2 YWxpZGF0aW9uIChmb3IgZXhhbXBsZSBieSBhIGNlbnRyYWxpemVkIEJHUCByb3V0ZSBjb250cm9s bGVyKSwgYW5kIHRoZSBiZXN0LW1hdGNoIHVuaWNhc3Qgcm91dGUNCiBpcyBvcmlnaW5hdGVkIGlu IGFub3RoZXIgYXV0b25vbW91cyBzeXN0ZW0uJnF1b3Q7IC0gc2hvdWxkIHRoZSB3b3JkICZxdW90 O3RoYW4mcXVvdDsgYmUgcmVwbGFjZWQgd2l0aCAmcXVvdDt0aGF0JnF1b3Q7IGhlcmU/PG86cD48 L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPltKVUFOXTogVGhhbmtzIGZv ciBwb2ludGluZyB0aGF0IG91dC4gQSBmZXcgZ29vZ2xpbmcgdGVsbHMgbWUgdGhlIGV2ZW4gYmV0 dGVyIGdyYW1tYXRpY2FsIGNob2ljZSB3b3VsZCBiZSDigJhzYW1lIGFz4oCZIGluIHRoaXMgY2Fz ZS4gSeKAmWxsIGJlIHVzaW5nIOKAmHNhbWUgYXPigJkgdW5sZXNzJm5ic3A7IHlvdSBkaXNhZ3Jl ZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0 OmwwIGxldmVsMSBsZm8xIj4NCkluIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9u LCAmcXVvdDtiZWNvbWVzIGhlcmVieSBvcHRpb25hbCZxdW90OyBjb3VsZCBwcm9iYWJseSBiZSBz aW1wbGlmaWVkIHRvICZxdW90O2JlY29tZXMgb3B0aW9uYWwmcXVvdDsgb3Igc2ltaWxhciwgYW5k ICZxdW90O2FjdHVhbGx5JnF1b3Q7IGNvdWxkIGJlIHJlbW92ZWQuPG86cD48L286cD48L2xpPjwv dWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPltKVUFOXTombmJzcDsgSG1tbSwgSSB0aG91Z2h0 IHRoYXQgaXQgd2FzIGltcG9ydGFudCB0byBlbXBoYXNpemUgaXQgYmVjb21lcyBvcHRpb25hbCBi ZWNhdXNlIG9mICo8Yj50aGlzPC9iPiogZHJhZnQgcmVkZWZpbml0aW9uIG9mIHJ1bGVzLiBEb27i gJl0IHlvdSB0aGluayBpdOKAmXMgaW1wb3J0YW50PyAod2hhdGV2ZXIgd29yZGluZw0KIHlvdSB3 YW50IHRvIHVzZSkuIFJlZ2FyZGxlc3MsIHJlZmVyIHRvIG15IG5ldyByZXdvcmRlZCAyIHBhcmFn cmFwaHMgYWJvdmUgZm9yIHRoYXQgc2VjdGlvbiAuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwcmU+PG86cD4mbmJzcDs8 L286cD48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzLCA8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0gTWFnbnVzPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_DM6PR11MB3194503DF53A14C12FC749E4CD5B9DM6PR11MB3194namp_-- From nobody Mon May 3 05:56:19 2021 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C3B403A102D; Mon, 3 May 2021 05:56:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Yaron Sheffer via Datatracker To: Cc: draft-ietf-lsr-isis-srv6-extensions.all@ietf.org, last-call@ietf.org, lsr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.28.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162004657373.13851.8347166444632264802@ietfa.amsl.com> Reply-To: Yaron Sheffer Date: Mon, 03 May 2021 05:56:13 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-lsr-isis-srv6-extensions-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2021 12:56:14 -0000 Reviewer: Yaron Sheffer Review result: Ready This document specifies extensions (TLVs, sub-TLVs etc.) to IS-IS in support of Segment Routing on IPv6. The document states that the security considerations are a union of security considerations from a bunch of predecessor document. This seems reasonable to me. Details: * The first sentence of the Abstract is missing a word, perhaps "architecture". * Introduction: typo: "This documents". * Capabilities: to allow for future extensibility, you should probably add "Implementations receiving this TLV MUST ignore any other bits that may be set in the Flags field". From nobody Mon May 3 07:28:12 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AEBD3A1600 for ; Mon, 3 May 2021 07:28:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lzacebalz5Rw for ; Mon, 3 May 2021 07:28:02 -0700 (PDT) Received: from mail-yb1-xb30.google.com (mail-yb1-xb30.google.com [IPv6:2607:f8b0:4864:20::b30]) (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 A9C943A1606 for ; Mon, 3 May 2021 07:28:02 -0700 (PDT) Received: by mail-yb1-xb30.google.com with SMTP id t94so7769422ybi.3 for ; Mon, 03 May 2021 07:28:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MKcJA1VOP18o+/XnWjpyB4AX4/R9tVAt6YYgvMO+YVE=; b=FU4arIgIDLCLJ/2V/KWtUDOKjC3h5KLI9NGpXVRlEsZ70b4C++MxZlBzx11SsX6PPN E/IFsbPrz7GHNSXAXqvz29zipLes6hyv3OVoh1ASBjj0tFaDRnLF4PNHz9YdQs1YaMIg /zdvF5WGB/lMCU418QS80IMm5Mu6l1DzSTzR0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MKcJA1VOP18o+/XnWjpyB4AX4/R9tVAt6YYgvMO+YVE=; b=VQNe9hylP8wFl4EokR/QrF54zP84F959mtEGuQR/TDF7QTRJ9SdYbNsAnMYCKvZdpQ BHpB4TGuqCa0iIBbsctWgHlOKnyLnkTREPsqNsX2x5+xceFoBYc+0w/0n6QLDVtDnQYQ eQp+uypIBchh3pcAq1dxfe8zV1wPeBomoZqW1H+n4aXZKKvFfRSmCfY0WPt3PROAm6ld vBUWb9VAcqc98u65k6eONU7PAgUCUYtvv8/f0fFmA/4eTxXy9Pw2fzYq1o0MwB6xJQ3D XiQuDSTCm6A7Ntz03SLuY3F7TG6GuMt/UjzBbdo61XSKZhYAlsnwf4fClwYKtMnKItzo 6l8w== X-Gm-Message-State: AOAM530K+Hno/9WFJ4+Q4QcgHkmw7CPsooquoPdffyyG3M6UbM6RbWC5 0/6L+u4Ku7pioIkEXZR4sxZf4tmUeZk8shmc+Tu55LuY7z4JBA== X-Google-Smtp-Source: ABdhPJy2RLe0tOFEXqR0XXhlXn2V81mkDsSEowt41O3Vgq50dQoTDQ5RMooYMDWu0c9s9tF6LyWN4JMaclbNNJ7pwxQ= X-Received: by 2002:a25:af06:: with SMTP id a6mr15926695ybh.364.1620052080206; Mon, 03 May 2021 07:28:00 -0700 (PDT) MIME-Version: 1.0 References: <161969840202.30267.8231145700644479792@ietfa.amsl.com> In-Reply-To: From: Kyle Rose Date: Mon, 3 May 2021 10:27:49 -0400 Message-ID: To: Randy Bush Cc: Kyle Rose via Datatracker , last-call@ietf.org, opsawg@ietf.org, draft-ietf-opsawg-finding-geofeeds.all@ietf.org, IETF SecDir Content-Type: multipart/alternative; boundary="000000000000c244f405c16dc46f" Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-opsawg-finding-geofeeds-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2021 14:28:08 -0000 --000000000000c244f405c16dc46f Content-Type: text/plain; charset="UTF-8" On Thu, Apr 29, 2021 at 3:56 PM Randy Bush wrote: > > The nits include a need for a thorough editorial pass prior to > submission to > > the RFC editor. For example: > > > > * The abstract should probably give the uninformed reader a bit more > > information about the overall geofeed ecosystem. * "utterly awesome", > "or > > whatever", "It would be polite" > > aha! the style directorate. we'll see how far it gets. maybe even > rfced still has a twinkle in their eye. :) > My point is simply that you should aim to submit the document in a form as close as possible to immediately publishable. Language that you and I and everyone else knows a priori is unsuitable for publication should get changed before submission. No reason to add busywork to the RFC editor's queue. > > I would also move the privacy discussion from section 2 "Geofeed > > Files" to a privacy considerations section, as that is where those > > concerned will look for that information. > > aha. a privacy section is a new fashion of which i was unaware. done. > thanks. > I've simply observed it as a best practice to compartmentalize that kind of analysis in a place that readers expect, rather than sprinkling it throughout normative parts of the document. > > This document appears to propose overlapping mechanisms for > > establishment of trust in geofeed data. As far as I can tell, geofeed > > data may be authenticated both by: > > > > * RPKI private key signature of a digest of a canonicalized form of the > > geofeed data file. * Web PKI via https URL for geofeed data file. > > not exactly. > > the web pki has no authority over IP address space ownership. Understood. I'm not suggesting the web PKI be used to authenticate IP address space ownership. I'm suggesting that the following chain would be sufficient: * RPKI authenticates the routing information, which includes the IP address space and the https URLs for each geofeed file. * Web PKI authenticates the data served at that URL. * Client verifies that the IP ranges in the geofeed data are contained within the (RPKI-authenticated) routing information. I.e., you are chaining trust from the RPKI explicitly to the (https) URL, and implicitly to the data served from that URL. The web PKI is used only to ensure that the data is not modified in transit. It is not used to authorize IP address space ownership: regardless of the PKI used to authenticate the geofeed data, the client still needs to cross-check the IP ranges in the geofeed data against the ownership in the RPKI-authenticated routing information. > it is only used to authenticate a *pointer* to the geofeed file. On the contrary, the pointer (i.e., the octet sequence making up the URL) is authenticated by RPKI in all cases. You're basically saying "Trust the data returned by the server at this URL." Which is a closed authentication chain if that URL is https by virtue of the corollary "Trust the web PKI to authenticate this server." > and the S in > https is just because we know folk will whine if the S is not there; > it's ietf fashion, similar to not working over ipv6 (or privacy > consideration sections:). Thanks for illustrating why the security area reviews all documents prior to publication, and why the security directorate exists: because protocol security properties are often subtle and not reducible to a checklist. > > * There appears to be no way to revoke previously-signed geofeed data > > except via rotation of the RPKI key pair. Using the web PKI and https > > is a countermeasure here by preventing impersonation of the geofeed > > host, but it's unclear what utility RPKI provides if web PKI is > > required to guarantee geofeed freshness. Metadata imposing a expiry > > on geofeed data authenticated by RPKI would serve the same function, > > at the cost of requiring the data to be refreshed regularly. > > validation of the signing certificate needs to ensure that it is part of > the current manifest and that the resources are covered by the RPKI > certificate. this handles revocation. > > but, if you want to go down the "how does revocation work in the rpki" > rabbit hole, you have to drink the 3779 validation koolaid, and that of > the "up-down" protocol, and have a look at manifests. not that i am > recommending going down this rabbit hole. > I did a bit of digging, and it looks like RPKI does have revocation at the certificate level, so there is at least a (potentially costly) path to doing this. > > * Is it always the case that RPKI private keys are protected by HSM, > > or is that simply a best practice? > > not at all. but, imiho, we should stay neutral on that. the example > > Identifying the private key associated with the certificate, and > getting the department with the Hardware Security Module (HSM) to > sign the CMS blob is left as an exercise for the implementor. > > was merely a cultural reference to the silos in a large LIR where > address space ownership, rpki signing, ... are often in a very separate > fiefdom from geo location folk. > I feel like this statement can be made in an implementation-neutral way, like "Signing workflows will vary and are out of scope for this document." > > * Why does the geofeed appendix not accommodate multiple signatures > > for distinct address ranges? The requirement that a geofeed file not > > be RPKI-signed in order to be shared by multiple INETNUM objects > > could be relieved were multiple signatures allowed. > > do we really want to start work on RFC5485-bis? but maybe russ has > better thoughts on this than i. > If signatures were detached, it would be trivial to have multiple. But that would complicate authentication for resources that are not immutable (e.g., inconsistent geofeed and signature files, something quite likely to happen with cacheable artifacts). So I wouldn't recommend that approach anyway. I guess my recommendation to simplify this would be twofold: * Mandate RPKI for routing information, including the geofeed data URLs (i.e., the sequence of octets that represents a URL). * Mandate the use of https (and therefore web PKI) for geofeed data (i.e., all URLs must be https://...) This eliminates the need for the complexity of RPKI signatures in geofeed data while ultimately rooting that information in an RPKI trust anchor. Kyle --000000000000c244f405c16dc46f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Apr 29, 2021 at 3:56 PM Randy Bush <randy@psg.com> wrote:
> The nits include a need for a thorough editor= ial pass prior to submission to
> the RFC editor. For example:
>
>=C2=A0 * The abstract should probably give the uninformed reader a bit = more
>=C2=A0 information about the overall geofeed ecosystem. * "utterly= awesome", "or
>=C2=A0 whatever", "It would be polite"

aha!=C2=A0 the style directorate.=C2=A0 we'll see how far it gets.=C2= =A0 maybe even
rfced still has a twinkle in their eye. :)

<= div>
My point is simp= ly that you should aim to submit the document in a form as close as possibl= e to immediately publishable. Language that you and I and everyone else kno= ws a priori is unsuitable for publication should get changed before submiss= ion. No reason to add busywork to the RFC editor's queue.
=C2=A0
> I would also move the privacy discussion from section 2 "Geofeed<= br> > Files" to a privacy considerations section, as that is where thos= e
> concerned will look for that information.

aha.=C2=A0 a privacy section is a new fashion of which i was unaware.=C2=A0= done.
thanks.

I've simply observed it as a best practice to c= ompartmentalize that kind of analysis in a place that readers expect, rathe= r than sprinkling it throughout normative parts of the document.
=C2=A0
> This document appears to propose overlapping mechanisms for
> establishment of trust in geofeed data. As far as I can tell, geofeed<= br> > data may be authenticated both by:
>
>=C2=A0 * RPKI private key signature of a digest of a canonicalized form= of the
>=C2=A0 geofeed data file. * Web PKI via https URL for geofeed data file= .

not exactly.

the web pki has no authority over IP address space ownership.

Understood. I= 'm not suggesting the web PKI be used to authenticate IP address space = ownership. I'm suggesting that the following chain would be sufficient:=

=C2=A0* RPKI authenticat= es the routing information, which includes the IP address space and the htt= ps URLs for each geofeed file.
=C2=A0* Web PKI authenticates the data served at that URL.<= /div>
=C2=A0* Client = verifies that the IP ranges in the geofeed data are contained within the (R= PKI-authenticated) routing information.

I.e., you are chaining trust from the RPKI explicitly to= the (https) URL, and implicitly to the data served from that URL. The web = PKI is used only to ensure that the data is not modified in transit. It is = not used to authorize IP address space ownership: regardless of the PKI use= d to authenticate the geofeed data, the client still needs to cross-check t= he IP ranges in the geofeed data against the ownership in the RPKI-authenti= cated routing information.

> =C2=A0 it is only used to authenticate a *pointer* to the geofeed file.
=
On the contrary, the pointer (i.e.= , the octet sequence making up the URL) is authenticated by RPKI in all cas= es. You're basically saying "Trust the data returned by the server= at this URL." Which is a closed authentication chain if that URL is h= ttps by virtue of the corollary "Trust the web PKI to authenticate thi= s server."
=C2=A0
=C2=A0 and the S in
https is just because we know folk will whine if the S is not there;
it's ietf fashion, similar to not working over ipv6 (or privacy
consideration sections:).

Thanks for illustrating why the secur= ity area reviews all documents prior to publication, and why the security d= irectorate exists: because protocol security properties are often subtle an= d not reducible to a checklist.
=C2=A0
>=C2=A0 * There appears to be no way to revoke previously-signed geofeed= data
>=C2=A0 except via rotation of the RPKI key pair. Using the web PKI and = https
>=C2=A0 is a countermeasure here by preventing impersonation of the geof= eed
>=C2=A0 host, but it's unclear what utility RPKI provides if web PKI= is
>=C2=A0 required to guarantee geofeed freshness. Metadata imposing a exp= iry
>=C2=A0 on geofeed data authenticated by RPKI would serve the same funct= ion,
>=C2=A0 at the cost of requiring the data to be refreshed regularly.

validation of the signing certificate needs to ensure that it is part of the current manifest and that the resources are covered by the RPKI
certificate.=C2=A0 this handles revocation.

but, if you want to go down the "how does revocation work in the rpki&= quot;
rabbit hole, you have to drink the 3779 validation koolaid, and that of
the "up-down" protocol, and have a look at manifests.=C2=A0 not t= hat i am
recommending going down this rabbit hole.

I did a bit of di= gging, and it looks like RPKI does have revocation at the certificate level= , so there is at least a (potentially costly) path to doing this.
=
=C2=A0
>=C2=A0 * Is it always the case that RPKI private keys are protected by = HSM,
>=C2=A0 or is that simply a best practice?

not at all.=C2=A0 but, imiho, we should stay neutral on that.=C2=A0 the exa= mple

=C2=A0 =C2=A0Identifying the private key associated with the certificate, a= nd
=C2=A0 =C2=A0getting the department with the Hardware Security Module (HSM)= to
=C2=A0 =C2=A0sign the CMS blob is left as an exercise for the implementor.<= br>
was merely a cultural reference to the silos in a large LIR where
address space ownership, rpki signing, ... are often in a very separate
fiefdom from geo location folk.

I feel like this statement = can be made in an implementation-neutral way, like "Signing workflows = will vary and are out of scope for this document."
=C2= =A0
>=C2=A0 * Why does the geofeed appendix not accommodate multiple signatu= res
>=C2=A0 for distinct address ranges? The requirement that a geofeed file= not
>=C2=A0 be RPKI-signed in order to be shared by multiple INETNUM objects=
>=C2=A0 could be relieved were multiple signatures allowed.

do we really want to start work on RFC5485-bis?=C2=A0 but maybe russ has
better thoughts on this than i.

If signatures were detached= , it would be trivial to have multiple. But that would complicate authentic= ation for resources that are not immutable (e.g., inconsistent geofeed and = signature files, something quite likely to happen with cacheable artifacts)= . So I wouldn't recommend that approach anyway. I guess my recommendati= on to simplify this would be twofold:

=C2=A0* Mandate RPKI for routing information, including the ge= ofeed data URLs (i.e., the sequence of octets that represents a URL).
=C2=A0* Mandate = the use of https (and therefore web PKI) for geofeed data (i.e., all URLs m= ust be https://...)

This = eliminates the need for the complexity of RPKI signatures in geofeed data w= hile ultimately rooting that information in an RPKI trust anchor.
=
Kyle

--000000000000c244f405c16dc46f-- From nobody Mon May 3 07:47:49 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 004BF3A16CF for ; Mon, 3 May 2021 07:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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=krose.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1u6TZb_asnoP for ; Mon, 3 May 2021 07:47:43 -0700 (PDT) Received: from mail-yb1-xb2d.google.com (mail-yb1-xb2d.google.com [IPv6:2607:f8b0:4864:20::b2d]) (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 EB5633A16CE for ; Mon, 3 May 2021 07:47:42 -0700 (PDT) Received: by mail-yb1-xb2d.google.com with SMTP id i4so7867387ybe.2 for ; Mon, 03 May 2021 07:47:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TM1ExMR3uQsX0XNn0dXNYzUQnU3irDMSq6J72eSfEa0=; b=nBbaFEHFZNnvPDJXSqwcVtEOq3Vzo3VSlynaeSe3WueIKLD2JmeoYYsWi6J1ClttXW 2coEiQ3ormDlrEjQU4QtZ9kLDKl/XCGVQmXiI9InjU9WXO3V+tgYzXO9toFA7zfzxRzL KcYLzJnXn/qfNpDt33xKRIBdOgl0xwCK15VIk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TM1ExMR3uQsX0XNn0dXNYzUQnU3irDMSq6J72eSfEa0=; b=GcKvSAJpYF7S4ODdDstRCpiY8dpIVZR4v6i9JEYkQtEa5KiHl45MhLu/oGxOi4n4xl /eVrKVcMsmdaoHIGTi7Zte9fpoFi0EW5uaKJoG1IPpyx2fgJS8mfA1TRfXbucd5KMNKc RdrKR3kOBr/OOym9CR54RM57uGBIncxNQkF+xfiCfWEAPVfiXs3vnjtOGMFo6CczyK4o s26nfUUWf6tgewKw4IpEaSEDKWvFczLS6FRXJpVPQ7JHO52bWGS4eNjdQPxgiPNT+2Qu PdugcEPiZxjDoNj0z2rK1NjnPK+cRdcoSOwkx2GTzKYyPmAooaZTjPVSCSblPhQvDlqF urXQ== X-Gm-Message-State: AOAM5329vV2Ah0aKuN/IPevR/Mdiz4TujXBuA/itqJeTx4zKIbuycBq1 /2ADeMdS/XEdyWBzVVqbV2VCebvKSqEJtfkIvH5OEA== X-Google-Smtp-Source: ABdhPJyYTFZZ4AEClKZ9myskEKeQw8mWnHUoSAeTETZllse4ucQc8hIhl5QOT1r7vF0f7cDafBrA1dSqYqeKWmFSwJ8= X-Received: by 2002:a25:f61f:: with SMTP id t31mr25797133ybd.9.1620053261285; Mon, 03 May 2021 07:47:41 -0700 (PDT) MIME-Version: 1.0 References: <161969840202.30267.8231145700644479792@ietfa.amsl.com> <809A05C9-8ABD-4D63-970D-D3F8A2277F28@vigilsec.com> In-Reply-To: <809A05C9-8ABD-4D63-970D-D3F8A2277F28@vigilsec.com> From: Kyle Rose Date: Mon, 3 May 2021 10:47:30 -0400 Message-ID: To: Russ Housley Cc: Randy Bush , IETF SecDir , Ops Area WG , draft-ietf-opsawg-finding-geofeeds.all@ietf.org, Last Call Content-Type: multipart/alternative; boundary="000000000000280c3105c16e0b4d" Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-opsawg-finding-geofeeds-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2021 14:47:48 -0000 --000000000000280c3105c16e0b4d Content-Type: text/plain; charset="UTF-8" On Mon, May 3, 2021 at 10:40 AM Russ Housley wrote: > > Understood. I'm not suggesting the web PKI be used to authenticate IP > address space ownership. I'm suggesting that the following chain would be > sufficient: > > * RPKI authenticates the routing information, which includes the IP > address space and the https URLs for each geofeed file. > * Web PKI authenticates the data served at that URL. > * Client verifies that the IP ranges in the geofeed data are contained > within the (RPKI-authenticated) routing information. > > > This is not quite right. It is true that theWebPKI provide authentication > and integrity when https:// is used, but this is not required. If http:// > were used, and the file was modified in transit by an attacker, the RPKI > signature check would fail. > Yes. Which is why I'm suggesting that you mandate https. I'm obviously not aware of the potential operational complications of doing so, as I don't work in this area. There may be good reasons why this is impractical. The tradeoff, however, is a more complex client ecosystem, which must accommodate two authentication methods instead of one. Kyle --000000000000280c3105c16e0b4d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, May 3, 2021 at 10:40 AM Russ Housley <housley@vigilsec.com> wrote:

Und= erstood. I'm not suggesting the web PKI be used to authenticate IP addr= ess space ownership. I'm suggesting that the following chain would be s= ufficient:

=C2=A0* RPKI authenticates the routing information, which includ= es the IP address space and the https URLs for each geofeed file.
=C2=A0* Web PKI authenticates the data served at = that URL.
=C2=A0* Client verifies that t= he IP ranges in the geofeed data are contained within the (RPKI-authenticat= ed) routing information.

This is not quite right.=C2=A0 It is true tha= t theWebPKI provide authentication and integrity when https:// is used, but= this is not required.=C2=A0 If http:// were used, and the file was modifie= d in transit by an attacker, the RPKI signature check would fail.

Yes. Which is why I'm suggesting that you mandate https.=

I'm obviously not aw= are of the potential operational complications of doing so, as I don't = work in this area. There may be good reasons why this is impractical. The t= radeoff, however, is a more complex client ecosystem, which must accommodat= e two authentication methods instead of one.
=C2=A0
Kyle

--000000000000280c3105c16e0b4d-- From nobody Mon May 3 07:49:11 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 023D63A16CE for ; Mon, 3 May 2021 07:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable 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 1M8wB6Qp2oVC for ; Mon, 3 May 2021 07:49:06 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBC993A176B for ; Mon, 3 May 2021 07:49:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id DDA54300BF2 for ; Mon, 3 May 2021 10:40:14 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id oWC4HAxYswsf for ; Mon, 3 May 2021 10:40:08 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 02503300B69; Mon, 3 May 2021 10:40:07 -0400 (EDT) From: Russ Housley Message-Id: <809A05C9-8ABD-4D63-970D-D3F8A2277F28@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_947E6C0E-C270-4882-8524-1B8655A8F570" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.20\)) Date: Mon, 3 May 2021 10:40:08 -0400 In-Reply-To: Cc: Randy Bush , IETF SecDir , Ops Area WG , draft-ietf-opsawg-finding-geofeeds.all@ietf.org, Last Call To: Kyle Rose References: <161969840202.30267.8231145700644479792@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.104.20) Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-opsawg-finding-geofeeds-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2021 14:49:07 -0000 --Apple-Mail=_947E6C0E-C270-4882-8524-1B8655A8F570 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Kyle: > > This document appears to propose overlapping mechanisms for > > establishment of trust in geofeed data. As far as I can tell, = geofeed > > data may be authenticated both by: > >=20 > > * RPKI private key signature of a digest of a canonicalized form of = the > > geofeed data file. * Web PKI via https URL for geofeed data file. >=20 > not exactly. >=20 > the web pki has no authority over IP address space ownership. >=20 > Understood. I'm not suggesting the web PKI be used to authenticate IP = address space ownership. I'm suggesting that the following chain would = be sufficient: >=20 > * RPKI authenticates the routing information, which includes the IP = address space and the https URLs for each geofeed file. > * Web PKI authenticates the data served at that URL. > * Client verifies that the IP ranges in the geofeed data are = contained within the (RPKI-authenticated) routing information. This is not quite right. It is true that theWebPKI provide = authentication and integrity when https:// is used, but this is not = required. If http:// were used, and the file was modified in transit by = an attacker, the RPKI signature check would fail. > I.e., you are chaining trust from the RPKI explicitly to the (https) = URL, and implicitly to the data served from that URL. The web PKI is = used only to ensure that the data is not modified in transit. It is not = used to authorize IP address space ownership: regardless of the PKI used = to authenticate the geofeed data, the client still needs to cross-check = the IP ranges in the geofeed data against the ownership in the = RPKI-authenticated routing information. My point is that there is no chaining of trust. Russ --Apple-Mail=_947E6C0E-C270-4882-8524-1B8655A8F570 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Kyle:

> This document appears to propose overlapping mechanisms for
> establishment of trust in geofeed data. As far as I can tell, = geofeed
> data may be authenticated both by:
>
>  * RPKI private key signature of a digest of a canonicalized = form of the
>  geofeed data file. * Web PKI via https URL for geofeed data = file.

not exactly.

the web pki has no authority over IP address space ownership.

Understood. I'm not suggesting the web PKI be = used to authenticate IP address space ownership. I'm suggesting that the = following chain would be sufficient:

 * RPKI = authenticates the routing information, which includes the IP address = space and the https URLs for each geofeed file.
 * Web PKI = authenticates the data served at that URL.
 * Client verifies that the IP = ranges in the geofeed data are contained within the (RPKI-authenticated) = routing information.

This is not quite right.  It is true = that theWebPKI provide authentication and integrity when https:// is = used, but this is not required.  If http:// were used, and the file = was modified in transit by an attacker, the RPKI signature check would = fail.

I.e., you are = chaining trust from the RPKI explicitly to the (https) URL, and = implicitly to the data served from that URL. The web PKI is used only to = ensure that the data is not modified in transit. It is not used to = authorize IP address space ownership: regardless of the PKI used to = authenticate the geofeed data, the client still needs to cross-check the = IP ranges in the geofeed data against the ownership in the = RPKI-authenticated routing = information.

My point is that there is no chaining of = trust.

Russ


= --Apple-Mail=_947E6C0E-C270-4882-8524-1B8655A8F570-- From nobody Mon May 3 08:34:06 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87E323A1880 for ; Mon, 3 May 2021 08:34:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 huAO-3FFinsb for ; Mon, 3 May 2021 08:33:59 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFCFD3A1884 for ; Mon, 3 May 2021 08:33:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 3140E300BD6 for ; Mon, 3 May 2021 11:28:28 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 2VGd9IIWhbmW for ; Mon, 3 May 2021 11:28:21 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 23616300259; Mon, 3 May 2021 11:28:21 -0400 (EDT) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_4945FB6F-E622-40BC-ADFB-8B430D7D2E8F" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.20\)) Date: Mon, 3 May 2021 11:28:21 -0400 In-Reply-To: Cc: Randy Bush , Last Call , Ops Area WG , draft-ietf-opsawg-finding-geofeeds.all@ietf.org, IETF SecDir To: Kyle Rose References: <161969840202.30267.8231145700644479792@ietfa.amsl.com> <809A05C9-8ABD-4D63-970D-D3F8A2277F28@vigilsec.com> X-Mailer: Apple Mail (2.3445.104.20) Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-opsawg-finding-geofeeds-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2021 15:34:05 -0000 --Apple-Mail=_4945FB6F-E622-40BC-ADFB-8B430D7D2E8F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On May 3, 2021, at 10:47 AM, Kyle Rose wrote: >=20 > On Mon, May 3, 2021 at 10:40 AM Russ Housley > wrote: >=20 >> Understood. I'm not suggesting the web PKI be used to authenticate IP = address space ownership. I'm suggesting that the following chain would = be sufficient: >>=20 >> * RPKI authenticates the routing information, which includes the IP = address space and the https URLs for each geofeed file. >> * Web PKI authenticates the data served at that URL. >> * Client verifies that the IP ranges in the geofeed data are = contained within the (RPKI-authenticated) routing information. >=20 > This is not quite right. It is true that theWebPKI provide = authentication and integrity when https:// is used, but this is not = required. If http:// were used, and the file was modified in transit by = an attacker, the RPKI signature check would fail. >=20 > Yes. Which is why I'm suggesting that you mandate https. I do not have a problem mandating the use of https:// for authentication = and integrity protection of the file. I think that is shown in the = examples. I am saying that doing so does not "chain" the trust models. Russ --Apple-Mail=_4945FB6F-E622-40BC-ADFB-8B430D7D2E8F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On May 3, 2021, at 10:47 AM, Kyle Rose <krose@krose.org> = wrote:

On Mon, May 3, 2021 at 10:40 AM Russ Housley <housley@vigilsec.com> wrote:

Understood. I'm not suggesting the = web PKI be used to authenticate IP address space ownership. I'm = suggesting that the following chain would be sufficient:

 * RPKI authenticates the = routing information, which includes the IP address space and the https = URLs for each geofeed file.
 * Web PKI authenticates the data served at that = URL.
 * Client = verifies that the IP ranges in the geofeed data are contained within the = (RPKI-authenticated) routing information.

This is not = quite right.  It is true that theWebPKI provide authentication and = integrity when https:// is used, but this is not required.  If = http:// were used, and the file was modified in transit by an attacker, = the RPKI signature check would fail.

Yes. Which is why I'm = suggesting that you mandate = https.

I do not have a problem mandating the use of https:// = for authentication and integrity protection of the file.  I think = that is shown in the examples.  I am saying that doing so does not = "chain" the trust models.

Russ

= --Apple-Mail=_4945FB6F-E622-40BC-ADFB-8B430D7D2E8F-- From nobody Mon May 3 08:44:38 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B3AC3A1999 for ; Mon, 3 May 2021 08:44:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aCuTNq5DdXcF for ; Mon, 3 May 2021 08:44:24 -0700 (PDT) Received: from mail-yb1-xb2c.google.com (mail-yb1-xb2c.google.com [IPv6:2607:f8b0:4864:20::b2c]) (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 AD39B3A199D for ; Mon, 3 May 2021 08:44:24 -0700 (PDT) Received: by mail-yb1-xb2c.google.com with SMTP id l7so8080344ybf.8 for ; Mon, 03 May 2021 08:44:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WAiJ6npuQ20wtgLss7VUDo4TDWIltcTMiVym0qfaPfM=; b=km/eQxK0K4PT5IGagohWsU3kwi5bOzBckOYFeOoI7n0lFKu/pvQB9KeI+dA8EiVyNd t64I3KasQQnaR5qTmO79p3hNl9OaseAvBlQRylad5KUxIPmcwxuCrTi3DrtSpdQl1WNb iHNnEC4mYT2/+FR6PdUj4VMYEtcqlIfpX3+YI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WAiJ6npuQ20wtgLss7VUDo4TDWIltcTMiVym0qfaPfM=; b=M4sv4rkuHnRHzri4gxQvydZsoMzV7IUjD5M6cKG8NnFpsLkY6Fw7zfpXEPrRQvx+mR 3QF3D0T8fRxgFRnhj+dD9DgXn8GfOxGAX8CBE5sBj02mabB+CVgPyk9c2DcJ+BwX+R8P FC593ChTMsZLuJ0D91zI02dnXOA5uYmU5om/aJeNxyJZB9dG9S0JaAJ18qzRYYQ1tNo3 ycxZOXC+P+KnZrw8pe7rGapmD87oPVn7DUw4aTzwYDXqLjPu1QeVVlj0X0dDT9HZ5klw J3aBXsEN0YuJ1nGtZnY3zaKxnodId4u9Rz6I4+kGIr3eIoOLtY2yuyLgKH9yjGdFCHNp /OWw== X-Gm-Message-State: AOAM533IGJz8FLeCQ057VTCG45b0D/Mjzs3LRdnaMXtx6mbOD1rrmlnh tj26rHFt+t/TPXf4m6KN/psuf27JHFe+VhPMU3F5kA== X-Google-Smtp-Source: ABdhPJzg1zBYRnDTnXhrcqMpx1phPiDXbkGjH/FAeehGNO+miNh0vBoLJp8LY1d3rPjuw0F4SifSRkJNtIecjCu2iJQ= X-Received: by 2002:a25:f61f:: with SMTP id t31mr26173740ybd.9.1620056663352; Mon, 03 May 2021 08:44:23 -0700 (PDT) MIME-Version: 1.0 References: <161969840202.30267.8231145700644479792@ietfa.amsl.com> <809A05C9-8ABD-4D63-970D-D3F8A2277F28@vigilsec.com> In-Reply-To: From: Kyle Rose Date: Mon, 3 May 2021 11:44:11 -0400 Message-ID: To: Russ Housley Cc: Randy Bush , Last Call , Ops Area WG , draft-ietf-opsawg-finding-geofeeds.all@ietf.org, IETF SecDir Content-Type: multipart/alternative; boundary="000000000000ef809805c16ed55f" Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-opsawg-finding-geofeeds-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2021 15:44:31 -0000 --000000000000ef809805c16ed55f Content-Type: text/plain; charset="UTF-8" On Mon, May 3, 2021, 11:28 AM Russ Housley wrote: > This is not quite right. It is true that theWebPKI provide authentication >> and integrity when https:// is used, but this is not required. If >> http:// were used, and the file was modified in transit by an attacker, >> the RPKI signature check would fail. >> > > Yes. Which is why I'm suggesting that you mandate https. > > > I do not have a problem mandating the use of https:// for authentication > and integrity protection of the file. I think that is shown in the > examples. I am saying that doing so does not "chain" the trust models. > Explain how an attacker could get a client to accept a forged geofeed data file authenticated as I have suggested, because I'm not seeing it. Kyle --000000000000ef809805c16ed55f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, May 3, 2021, 11:28 AM Russ Housley <housley@vigilsec.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
This is not quite right.=C2=A0 It is = true that theWebPKI provide authentication and integrity when https:// is u= sed, but this is not required.=C2=A0 If http:// were used, and the file was= modified in transit by an attacker, the RPKI signature check would fail.

Yes. Which is why I'm suggesting that you mandate ht= tps.

I do not have a pro= blem mandating the use of https:// for authentication and integrity protect= ion of the file.=C2=A0 I think that is shown in the examples.=C2=A0 I am sa= ying that doing so does not "chain" the trust models.
=

Explain ho= w an attacker could get a client to accept a forged geofeed data file authe= nticated as I have suggested, because I'm not seeing it.

Kyle
--000000000000ef809805c16ed55f-- From nobody Mon May 3 09:14:13 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A38373A1A9F for ; Mon, 3 May 2021 09:14:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 7OWET-gWLYCk for ; Mon, 3 May 2021 09:14:03 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A98B3A1ACF for ; Mon, 3 May 2021 09:14:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 0E0FB300BED for ; Mon, 3 May 2021 12:05:46 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 3HqUgtaexvFi for ; Mon, 3 May 2021 12:05:39 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id D1764300BE0; Mon, 3 May 2021 12:05:38 -0400 (EDT) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_7786BE36-6819-4952-83BC-462332B516A3" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.20\)) Date: Mon, 3 May 2021 12:05:39 -0400 In-Reply-To: Cc: Randy Bush , Last Call , Ops Area WG , draft-ietf-opsawg-finding-geofeeds.all@ietf.org, IETF SecDir To: Kyle Rose References: <161969840202.30267.8231145700644479792@ietfa.amsl.com> <809A05C9-8ABD-4D63-970D-D3F8A2277F28@vigilsec.com> X-Mailer: Apple Mail (2.3445.104.20) Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-opsawg-finding-geofeeds-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2021 16:14:09 -0000 --Apple-Mail=_7786BE36-6819-4952-83BC-462332B516A3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On May 3, 2021, at 11:44 AM, Kyle Rose wrote: >=20 > On Mon, May 3, 2021, 11:28 AM Russ Housley > wrote: >> This is not quite right. It is true that theWebPKI provide = authentication and integrity when https:// is used, but this is not = required. If http:// were used, and the file was modified in transit by = an attacker, the RPKI signature check would fail. >>=20 >> Yes. Which is why I'm suggesting that you mandate https. >=20 > I do not have a problem mandating the use of https:// for = authentication and integrity protection of the file. I think that is = shown in the examples. I am saying that doing so does not "chain" the = trust models. >=20 > Explain how an attacker could get a client to accept a forged geofeed = data file authenticated as I have suggested, because I'm not seeing it. We are not understanding each other. The RPKI signature will prevent = the relying party from accepting a modified file, regardless of the = means used to fetch it. For this reason, there is no need think about = the interaction of the RPKI and the WebPKI. No dependency is being = created. Russ --Apple-Mail=_7786BE36-6819-4952-83BC-462332B516A3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On May 3, 2021, at 11:44 AM, Kyle Rose <krose@krose.org> = wrote:

On Mon, May 3, 2021, 11:28 AM Russ = Housley <housley@vigilsec.com> wrote:
This is not quite right.  It is true that = theWebPKI provide authentication and integrity when https:// is used, = but this is not required.  If http:// were used, and the file was = modified in transit by an attacker, the RPKI signature check would = fail.

Yes. = Which is why I'm suggesting that you mandate = https.

I do not have a problem mandating the use of https:// = for authentication and integrity protection of the file.  I think = that is shown in the examples.  I am saying that doing so does not = "chain" the trust models.

Explain how = an attacker could get a client to accept a forged geofeed data file = authenticated as I have suggested, because I'm not seeing = it.

We are not = understanding each other.  The RPKI signature will prevent the = relying party from accepting a modified file, regardless of the means = used to fetch it.  For this reason, there is no need think about = the interaction of the RPKI and the WebPKI.  No dependency is being = created.

Russ

= --Apple-Mail=_7786BE36-6819-4952-83BC-462332B516A3-- From nobody Mon May 3 10:10:08 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EDCA3A1CB3; Mon, 3 May 2021 10:10:06 -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, SPF_HELO_NONE=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 YkEP1nIfjHRf; Mon, 3 May 2021 10:10:01 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 86D423A1CB4; Mon, 3 May 2021 10:10:00 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1ldc4x-000398-0e; Mon, 03 May 2021 17:09:55 +0000 Date: Mon, 03 May 2021 10:09:54 -0700 Message-ID: From: Randy Bush To: Kyle Rose Cc: last-call@ietf.org, opsawg@ietf.org, draft-ietf-opsawg-finding-geofeeds.all@ietf.org, IETF SecDir In-Reply-To: References: <161969840202.30267.8231145700644479792@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-opsawg-finding-geofeeds-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2021 17:10:06 -0000 just a quickie. i will try to get to the other stuff after $dayjobs assumptions that the rpki and the inetnum: are congruent in ip address space are quite unsafe, sad to say. the granularity of the rpki is not that of the inetnum: space. for a tragic example, among other things, in the arin (noam) region, most address space can not get rpki data for artificial political reasons[0]. and in a sane region, emea, if i am an LIR and get a /32 from ripe, and get an rpki cert for it; i can delegate a /56 to a customer with an inetnum: and sadly they tend not to get rpki certs, but have geoloc. geofeed adoption is being driven by social pressure, customers want their mtv and are loud about it. rpki adoption is driven by operator gossip, not money. these conditions will continue for years, though not as long as ipv6 take-up. the draft is deployable on today's internet with today's administrative and technical infrastructure. in fact, it is deployed and working. more later randy [0] - https://scholarship.law.upenn.edu/faculty_scholarship/2035/ From nobody Mon May 3 12:39:01 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 289083A0B8B; Mon, 3 May 2021 12:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 HIi_2J0zQdzB; Mon, 3 May 2021 12:38:55 -0700 (PDT) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (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 15A403A0B88; Mon, 3 May 2021 12:38:54 -0700 (PDT) Received: by mail-io1-xd36.google.com with SMTP id t21so5093375iob.2; Mon, 03 May 2021 12:38:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tTnpSz6trkJg0oZleNS6vrGc9GILDghoJzSpizOT0uo=; b=Yriy7gPH02Rbe8bQQN7Dp9bwcb0d0v4SC76IHR2WMqpf8xz+JaLwpcGxu59VIyMWr0 np0eUbR+LxmGoBnQAJd8pUTDs5aqlQLhaPyQg2NaYS0m27U6+WbtHG7OAWb5Ukf6RJp0 TyCWrjsFJ469c2WGlL/LCT67QOevPvrd9mnBPAw7MKkRm7bmJIk0xaBV0ILA4+54K1NL 4caNDHkA6dyX+eRPUeaLelDCYkMPk+r5LcXdFky9sW37PMFiXuClBHstti6wmlPEniC6 l1DrIs7r1TAkuZmiMF8wlZgw8x4JPHY7ph0jI0VIX75E6pG0yVhB5ip7UwDAwxPIraiQ ApsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tTnpSz6trkJg0oZleNS6vrGc9GILDghoJzSpizOT0uo=; b=mx6oWzR6levj6Pa5kxA/vhIWe/0E2DWPb4J4vXQhpJkj77t1YgXWksyeQwjsAp040g iFlwutSt+sr5NDCXeey+IRw40mtmbMWYMW9/c28dtjNQhbjLZ8YsLhbe6uZ2yv2cmzj3 13igk5gnW2wnSwt6qux8d6JkYnFAx+lx8vyodaWlT8CJJ0i9poYFxZgOwC7wkMOqurEj yhz6euyMNS0XIahH/DbE0/E1cOHkrVE2xq4JiFcojnA5EtDKDkm0UHk24+UTvar3ThVM YG/kp9XWEY369qcCHLNOki1zyAYRXa88jUqrrUm9YlGxOj4XsvKGqjflopBbZ/UWZAdN hwqg== X-Gm-Message-State: AOAM530LFt80owdrWHffEYDiIE5ep0Jnq+QtoJ0WF6R7eyTbGvJp9Kle RJnBR230dn3zE2hjkpqFMncEENWckaZ4Ywz/U/PCJ0WUDdI= X-Google-Smtp-Source: ABdhPJzn42EGVFDsbATXe/kMckW3ZwVKM15xZv8R9TIsj2Ym6Ok93t99U0/Y4yQfmrPRzC02i5Q86lzeI63iTp6ljoI= X-Received: by 2002:a6b:7f4a:: with SMTP id m10mr16164712ioq.70.1620070733578; Mon, 03 May 2021 12:38:53 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?Magnus_Nystr=C3=B6m?= Date: Mon, 3 May 2021 12:38:42 -0700 Message-ID: To: "Juan Alcaide (jalcaide)" Cc: "secdir@ietf.org" , "draft-ietf-idr-bgp-flowspec-oid@ietf.org" Content-Type: multipart/alternative; boundary="00000000000096097a05c1721cf6" Archived-At: Subject: Re: [secdir] Secdir review of draft-ietf-idr-bgp-flowspec-oid-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2021 19:39:00 -0000 --00000000000096097a05c1721cf6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Juan. For the editorial ones, agree on the first one and I think the second you could change to "with this memo, becomes optional." or similar. For the new text, perhaps I am misunderstanding something, but this sentence: Note that identifying those peers that are route servers may suppose an operational challenge. If the condition of the peer is unknown, the rule SHOULD not be enforced. Is it correctly understood, that you're saying that if a validator is unable to determine if the peer is a route server, they should not enforce the rule? If so, doesn't that mean "failing open, i.e., opening themselves to risk? Sorry if I misunderstand. On Mon, May 3, 2021 at 3:36 AM Juan Alcaide (jalcaide) wrote: > Thanks for your comments, Magnus > > > > Inline.. > > > > *From:* Magnus Nystr=C3=B6m > *Sent:* Monday, May 3, 2021 6:44 AM > *To:* secdir@ietf.org; draft-ietf-idr-bgp-flowspec-oid@ietf.org > *Subject:* Secdir review of draft-ietf-idr-bgp-flowspec-oid-13 > > > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the IESG. > These comments were written primarily for the benefit of the security are= a > directors. Document editors and WG chairs should treat these comments ju= st > like any other last call comments. > > > > This document describes "a modification to the validation procedure > defined for the dissemination > > of BGP Flow Specifications." More specifically. the memo describes a > mechanism which relaxes the existing validation rule that requires Flow > Specifications to be originating from the originator of the best-match > unicast route, and now allows such specifications to be originated within > the same AS as the validator. As a result. the Security Considerations > section does call out: "The original AS_PATH validation rule ([RFC4271] > section 6.3 ) becomes > hereby optional (section 4.2 > ). > If that original rule is actually not enforced it may introduce some > security risks. A peer (or a client of a route server peer) in AS X could > advertise a rogue Flow Specification route...." and "If t[the originator = of > a rule] is known for a fact not to be a route server, that optional rule > SHOULD be enforced for Flow Specification routes." > > > > It is not clear to me how a validator would now "for a fact" that a peer > isn't a route server, and thus that it would have to enforce the > now-optional path validation rule. It seems some clarity on this would be > good such that implementations have less of a risk of accepting flow > specifications from unauthorized parties, even if they are on the same AS= . > > > > [JUAN]: This paragraph was not intended to pressure the operator to know > if the peer was a route server, it was just a =E2=80=98if=E2=80=99. Note = it=E2=80=99s the same case > for RFC4271 : > > > > If the UPDATE message is received from an external peer, the local > > system MAY check whether the leftmost (with respect to the position > > of octets in the protocol message) AS in the AS_PATH attribute is > > equal to the autonomous system number of the peer that sent the > > message. > > > > > > Note that the same challenge of identifying route servers applies for > other address-families. > > Note also that the route-server itself may enforce the rule. > > > > What about for clarity: > > > > The original AS_PATH validation rule ([RFC4271] section 6.3) remains > hereby still optional > > (section 4.2) for Flow Specification Address Family (changes introduce= d > in [RFC5575] are cancelled). > > If that original rule is not enforced for Flow Specification it may > introduce some new security risks. > > A peer (or a client of a route server peer) in AS X could advertise a > rogue Flow > > Specification route whose first AS in AS_PATH was Y (assume Y is the > > first AS in the AS_PATH of the best-match unicast route). This risk > > is impossible to prevent if the Flow Specification route is received > > from a route server peer. If that peer is known for a fact not to be > > a route server, that optional rule SHOULD be enforced for Flow > > Specification routes. Note that identifying those peers that are route > servers may suppose an > > operational challenge. If the condition of the peer is unknown, the > rule SHOULD not be > > enforced. > > > > A route server itself may be in a good position to enforce the AS_PATH > validation rule described > > in the previous paragraph. If a route server knowns it=E2=80=99s not pe= ering > with any other route server, > > it can enforce the AS_PATH validation rule across all its peers. If, i= n > addition to that, > > the route server is trusted, the security threat described above > disappears. > > > > > > > > Anybody feel free to reword the two paragraphs above if it helps them for > clarity. > > > > > > > > Editorial: > > - "Let's consider the particular case where the Flow Specification is > originated in any location within the same autonomous system than the > speaker performing the validation (for example by a centralized BGP ro= ute > controller), and the best-match unicast route is originated in another > autonomous system." - should the word "than" be replaced with "that" h= ere? > > [JUAN]: Thanks for pointing that out. A few googling tells me the even > better grammatical choice would be =E2=80=98same as=E2=80=99 in this case= . I=E2=80=99ll be using > =E2=80=98same as=E2=80=99 unless you disagree. > > > > - In the security considerations section, "becomes hereby optional" > could probably be simplified to "becomes optional" or similar, and > "actually" could be removed. > > [JUAN]: Hmmm, I thought that it was important to emphasize it becomes > optional because of **this** draft redefinition of rules. Don=E2=80=99t y= ou think > it=E2=80=99s important? (whatever wording you want to use). Regardless, r= efer to my > new reworded 2 paragraphs above for that section . > > > > > > > > Thanks, > > -- Magnus > > > --=20 -- Magnus --00000000000096097a05c1721cf6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Juan.
For the editorial ones, agree = on the first one and I think the second you could change to "with this= memo, becomes optional." or similar.
For the new text, perh= aps I am misunderstanding something, but this sentence:=20

Note that identifying those peers that are route= servers may suppose an operational challenge. If the condition of the peer= is unknown, the rule SHOULD not be enforced.

Is it correctly unders= tood, that you're saying that if a validator is unable to determine if = the peer is a route server, they should not enforce the rule? If so, doesn&= #39;t that mean "failing open, i.e., opening themselves to risk? Sorry= if I misunderstand.



On Mon, May 3, 2021 at 3:36 AM Juan Alcaide (jalcaide) <jalcaide@cisco.com> wrote:

Thanks for your comments, Magnus

=C2=A0

Inline..

=C2=A0

From: Magnus Nystr=C3=B6m <magnusn@gmail.com>
Sent: Monday, May 3, 2021 6:44 AM
To: secdir@ietf= .org; draft-ietf-idr-bgp-flowspec-oid@ietf.org
Subject: Secdir review of draft-ietf-idr-bgp-flowspec-oid-13<= u>

=C2=A0

I have reviewed this document as part of the securit= y directorate's ongoing effort to review all IETF documents being proce= ssed by the IESG. These comments were written primarily for the benefit of = the security area directors.=C2=A0 Document editors and WG chairs should treat these comments just like any other last= call comments.

=C2=A0

This document describes "a modification to the = validation procedure defined for the dissemination

of BGP Flow Specifications." More specifically.= the memo describes a mechanism which relaxes=C2=A0 the existing validation= rule that requires Flow Specifications to be originating from the originat= or of the best-match unicast route, and now allows such specifications to be originated within the same AS as the vali= dator. As a result. the Security Considerations section does call out: &quo= t;The original AS_PATH validation rule ([RFC4271] section=C2=A06.3) becomes=C2=A0 hereby optional (section 4.2). If that original rule is actually not enforced it may introduce some s= ecurity risks. A peer (or a client of a route server peer) in AS X could advertise a rogue Flow Specification route...." and &qu= ot;If t[the originator of a rule] is known for a fact not to be a route ser= ver, that optional rule SHOULD be enforced for Flow Specification routes.&q= uot;

=C2=A0

It is not clear to me how a validator would now &quo= t;for a fact" that a peer isn't a route server, and thus that it w= ould have to enforce the now-optional path validation rule. It seems some c= larity on this would be good such that implementations have less of a risk of accepting flow specifications from unauthorized par= ties, even if they are on the same AS.

=C2=A0

[JUAN]: This paragraph was not intended to pressure = the operator to know if the peer was a route server, it was just a =E2=80= =98if=E2=80=99. Note it=E2=80=99s the same case for RFC4271 :=

=C2=A0

If the UPDATE message is received from an extern= al peer, the local

=C2=A0=C2=A0 system MAY check whether the leftmo= st (with respect to the position

=C2=A0=C2=A0 of octets in the protocol message) = AS in the AS_PATH attribute is

=C2=A0=C2=A0 equal to the autonomous system numb= er of the peer that sent the

=C2=A0=C2=A0 message.

=C2=A0

=C2=A0

Note that the same challenge of identifying route se= rvers applies for other address-families.

Note also that the route-server itself may enforce t= he rule.

=C2=A0

What about for clarity:

=C2=A0

=C2=A0=C2=A0 The original AS_PATH validation rul= e ([RFC4271] section 6.3) remains hereby still optional

=C2=A0=C2=A0 (section 4.2) for Flow Specificatio= n Address Family (changes introduced in [RFC5575] are cancelled).

=C2=A0=C2=A0=C2=A0If that original rule is not e= nforced for Flow Specification it may introduce some new security risks.=

=C2=A0=C2=A0 A peer (or a client of a route serv= er peer) in AS X could advertise a rogue Flow

=C2=A0=C2=A0 Specification route whose first AS = in AS_PATH was Y (assume Y is the

=C2=A0=C2=A0 first AS in the AS_PATH of the best= -match unicast route).=C2=A0 This risk

=C2=A0=C2=A0 is impossible to prevent if the Flo= w Specification route is received

=C2=A0=C2=A0 from a route server peer.=C2=A0 If = that peer is known for a fact not to be

=C2=A0=C2=A0 a route server, that optional rule = SHOULD be enforced for Flow

=C2=A0=C2=A0 Specification routes. Note that ide= ntifying those peers that are route servers may suppose an

=C2=A0=C2=A0 operational challenge. If the condi= tion of the peer is unknown, the rule SHOULD not be

=C2=A0=C2=A0 enforced.

=C2=A0

=C2=A0=C2=A0 A route server itself may be in a g= ood position to enforce the AS_PATH validation rule described=

=C2=A0=C2=A0in the previous paragraph. If a rout= e server knowns it=E2=80=99s not peering with any other route server,

=C2=A0=C2=A0 it can enforce the AS_PATH validati= on rule across all its peers. If, in addition to that,=

=C2=A0=C2=A0 the route server is trusted, the se= curity threat described above disappears.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

=C2=A0

Anybody feel free to reword the two paragraphs above= if it helps them for clarity.

=C2=A0

=C2=A0

=C2=A0

Editorial:

  • "Let's consider the particular case where the Flow Specification i= s originated in any location within the same autonomous system than the spe= aker performing the validation (for example by a centralized BGP route cont= roller), and the best-match unicast route is originated in another autonomous system." - should the word "= than" be replaced with "that" here?

[JUAN]: Thanks for pointing that out. A few googling= tells me the even better grammatical choice would be =E2=80=98same as=E2= =80=99 in this case. I=E2=80=99ll be using =E2=80=98same as=E2=80=99 unless= =C2=A0 you disagree.

=C2=A0

  • In the security considerations section, "becomes hereby optional"= could probably be simplified to "becomes optional" or similar, a= nd "actually" could be removed.

[JUAN]:=C2=A0 Hmmm, I thought that it was important = to emphasize it becomes optional because of *this* draft redefinitio= n of rules. Don=E2=80=99t you think it=E2=80=99s important? (whatever wordi= ng you want to use). Regardless, refer to my new reworded 2 paragraphs above = for that section .

=C2=A0

=C2=A0

=C2=A0

Thanks,

-- Magnus

=C2=A0



--
-- Magnus
--00000000000096097a05c1721cf6-- From nobody Mon May 3 17:17:59 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 155053A1A74; Mon, 3 May 2021 17:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.615 X-Spam-Level: X-Spam-Status: No, score=-9.615 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_NONE=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 header.b=OXpZvkzd; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=XhRZe9j6 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 gRYscPsp1BU3; Mon, 3 May 2021 17:17:51 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 958093A1A72; Mon, 3 May 2021 17:17:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=50468; q=dns/txt; s=iport; t=1620087471; x=1621297071; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=kRLLvlvM787LIzm3IrYi0IPoJCEpw/TwtYXCd7qtKZE=; b=OXpZvkzdMnBebSulM7xe5vN/kpAhwfZDwa9TPwy45awfezxHjEwEW0ua sZQUWZIfd0Lix0QTTJBiA5V8CH9BWlR8qg04j3E4fwvkiGWPxLJtkKCKF P5VQogN7otxwoomiNADbSryzauN3Zmg8lvoMX8mp8CHTW0+UIVg56Ecs6 g=; IronPort-PHdr: =?us-ascii?q?A9a23=3AoWB0uxS98aaoXo+4UeeThPBbStpso0/LVj590?= =?us-ascii?q?bIulq5Of6K//p/rIE3Y47B3gUTUWZnAg9pLjuPXt+brXmlTqZqCsXVXdptKW?= =?us-ascii?q?ldFjMgNhAUvDYaDDlGzN//laSE2XaEgHF9o9n22Kw5ZTcD5YVCBrXi77DpUE?= =?us-ascii?q?RL6ZkJ5I+3vEdvUiMK6n+m555zUZVBOgzywKbN/JRm7t0PfrM4T1IBjMa02j?= =?us-ascii?q?BDOpyggRg=3D=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AtFenP60f6Y2090uhRJ55lgqjBeB2eYIsi2?= =?us-ascii?q?QD101hICF9Wvez0+izgfUW0gL1gj4NWHcm3euNIrWEXGm0z/9IyKErF/OHUB?= =?us-ascii?q?P9sGWlaLtj44zr3iH6F0TFmNJ1/ZxLN5JzANiYNzdHpO7x6gWgDpIEyN6I7K?= =?us-ascii?q?iniY7lvghQZCtBApsQiDtRIACdD0FwWU1iDZ02CJKT6qN81kSdUF4Qadm2AW?= =?us-ascii?q?RAYvjbq7Tw5dzbSDMlJzpi0gmBiju09KX3eiL54j4yWy5CqI1SilTtvBf+4s?= =?us-ascii?q?yYwpSG4z/ak1Te9pFH3Obmo+EzePCkrugwBnHShh2zZIJnMofy/QwdhO208l?= =?us-ascii?q?4lnJ3tjn4bTr5OwkjcdG20vhfhsjOIuF1FhhOSqi77vVLZrcP0Xz48AcZa7L?= =?us-ascii?q?gpDyfx0VYqv913zctwrgSknqdXFh/JkWDc4NXFRnhR5zKJiEciiuIagjhjV5?= =?us-ascii?q?IfYtZq3PUi1X5Sea1weB7S2cQCKq1DHcvc7PFZfRexdHbCpFRix9SqQzAaAg?= =?us-ascii?q?qGalJqgL3U7xFm2FRCi2cIzs0WmXkNsLgnTYNf2ujCOqN00JlTU84ta75nDu?= =?us-ascii?q?tpe7r1NkX9BTb3dE6CK1XuE68Kf1jXrYTs3bkz7Oa2PLsF0YU1g5aEdF9Dr2?= =?us-ascii?q?Y9dwbPBKS1rd922yGIZF/4cSXmy8lY6ZQ8kKb7XqDXPSqKT01rnNCnp/kZH8?= =?us-ascii?q?3HS/e+MJ9bGJbYXC/TMLcM+ze7d4hZKHEYXsFQkM08QUiyrsXCLZCvtuGzSo?= =?us-ascii?q?eVGJPdVRIfHk/vCHoKWzb+YO9a6FqwZ3P+iB/NH3fkekn1+4NsALHXltJjjr?= =?us-ascii?q?QlB8lpiEw4mF657saEJXlpqaotZnZzJ7vhj+e8vmm5/WHB6m1zIRpDBkNJ4L?= =?us-ascii?q?HtOkk64DMiAgfRS/Iuqt+fcWdd0D+sPRlkVf7bFwZZuhBq466tNoeRwiojEt?= =?us-ascii?q?qjNWqfgxIo1Su3ZqZZvpfGydbue5s+AJpjZbd4Eh/TEQdp3Sxwrn1YVQMCTk?= =?us-ascii?q?jDNz/nhKm/lqYIDOXHe9QUunbyHedk7Vbk8WSVv4UGW2YSVT/Ga7/nvS8eAx?= =?us-ascii?q?5vwmBX34BaqryagjqrIXY4m40DQS1xQVXSJqlHAgSDbJhTgZbxdmhLPDy3rA?= =?us-ascii?q?3frQ0vcWz38EhXoWrtIUSvCKz2K2sYnGxE2aD3914xTEGhRgZbb3B3tpAVLx?= =?us-ascii?q?Wdhl96zfKLaq2v02GYd1sFxaUHPCvYZCYJSzketOyfxVqbni2PGm4hwYhrNu?= =?us-ascii?q?vBDK47e7WWwX+1LpaU/Jt2UsN87dJgNNr0tPUMXv/acwiJLCngA+dB4X3fml?= =?us-ascii?q?81fC11omIji/XmxVns63W5xmc2Bb7XLE59T78WZ9Ga4G6MfYfD7LxpydY0t/?= =?us-ascii?q?C3KGP/d5qPzrzWdSdKLlfLunGtJttY36x8rOY3rv9+DpPbWTzH2DVO2wg/Nt?= =?us-ascii?q?79kAcbTL5g6L7MN4dzd6UpCm5k10tskM7KIFogswTwDON7Z10rgnPBN96C4r?= =?us-ascii?q?bDq9MUcwW8jRq1PUPa/zxW/v/DUSfGyKUTDLgoJ39KLEc783Zv8Yq5BsLtIR?= =?us-ascii?q?Tvc/sG+lW0MnWwKuAADKeEHKgdtRZ87ZWDmfSNey/xxQDXun96L8t1ghKaaN?= =?us-ascii?q?L3BBjJH+hCt8G+MxCLhKCh5caoljf5STehcS0j9MR4XF1Vat4GkyUoiY08zz?= =?us-ascii?q?O7RaP2qF80ilc220ATqnf9noy9pHrBFU5IMQfFkoxbUDlaPH+Pl9nE+4GjpQ?= =?us-ascii?q?PAySkA34LCGkdWdsxPHNZVTpGfFVYdFfQt?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CBAABMkpBg/4sNJK1aGwEBAQEBAQE?= =?us-ascii?q?BBQEBARIBAQEDAwEBAYIGAwEBAQsBgSIwUQd3WjYxC4Q5g0gDhTmIcgOKM4U?= =?us-ascii?q?Bih2BQoERA1QLAQEBDQEBKggCBAEBhFACF4FkAiU3Bg4CBAEBDAEBBQEBAQI?= =?us-ascii?q?BBgRxE4VQDYZEAQEBBCMEBhMBATcBDwIBCBEEAQEhAQYDAgICHxEUCQgCBA4?= =?us-ascii?q?FCIJqgX5XAy8BAws+nTkCih96fzOBAYIEAQEGBASFQQ0LghMDBoE6AYJ4hAw?= =?us-ascii?q?BAYEThUYnHIFJQoEVQ4FfgQA+gh5CAQECAYFDAhorCYJhNoIrgVkQWwYBAWI?= =?us-ascii?q?BAyIZCAgGAoEFDAcqCDoOAQsNSZBEAYNeh3qDVokzkFc5WwqDEIl5jXOFWRC?= =?us-ascii?q?DVKFOl0WJaYMdj08KhGsCBAIEBQIOAQEGgSNHJIFZcBWDJFAXAg6OHwwWg06?= =?us-ascii?q?FFIVJcwI2AgYBCQEBAwl8iU0CAiQHgQcBMl0BAQ?= X-IronPort-AV: E=Sophos;i="5.82,271,1613433600"; d="scan'208,217";a="866152931" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 04 May 2021 00:17:49 +0000 Received: from mail.cisco.com (xbe-rcd-005.cisco.com [173.37.102.20]) by alln-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id 1440HnYS011746 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Tue, 4 May 2021 00:17:49 GMT Received: from xfe-aln-001.cisco.com (173.37.135.121) by xbe-rcd-005.cisco.com (173.37.102.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Mon, 3 May 2021 19:17:49 -0500 Received: from xfe-rcd-001.cisco.com (173.37.227.249) by xfe-aln-001.cisco.com (173.37.135.121) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Mon, 3 May 2021 19:17:48 -0500 Received: from NAM04-MW2-obe.outbound.protection.outlook.com (72.163.14.9) by xfe-rcd-001.cisco.com (173.37.227.249) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3 via Frontend Transport; Mon, 3 May 2021 19:17:48 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YE26XVs32YMKQVup3mWyHX1FZE30Sb2ikm8XMOuEa8VnkLziuNK93qqZ9qRYKogw88iZghHGrbmtScL+xr4uzvEjd5tuJkEdOssbcxU59GgLItij2G0WUPJqtTxsGdJ9VCczXThKMvT7fOI7wVQP5s3lTewDbfClG93Xxx+97XRGnH+ZAHouJKr1gSS2hFboYxJd91iAjrS0WBfsLbgT3asEJSOz1whch3NSTph27HYXc4MjcKLV7Bndmu49VN3L4AZa/ykNr1m1jigWvwNUi+2/vYY9ysAvwoVNGg/IeQGJNiWwdhTETTxfXY8NlXKnlpk8EYgpAxPA8LV3gxvNAg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kRLLvlvM787LIzm3IrYi0IPoJCEpw/TwtYXCd7qtKZE=; b=AFEf+HHNbtNchoAZcbajNEtOvhzXb4v+MTSuRmqiqrGsKMn3AJa11WCfkgD9xnWkBLaailHHfMwh8WhupajLPmLJciX4Gab0iaXXj9hq5MSf89pGRlGhzh0NPOe6KRHkikbFQizouYjOEQ3GZ//KqGXNDFY1nWMztMDFVPsdvpOtzdlf1q8iaYtS+ePXJDNdjVANPZMoghzZFU457VOJ1vBJxgINMdiA/fonN6jdYWTiceSfYtHarN6zjszy885FUqQuxj1gy1ATwRSmWto1FO53+j38FXaZBoG57IlobARqIBxxQj2oJF/2eAICe4q/tMFm/yVavDCz5dOkdgHvYQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kRLLvlvM787LIzm3IrYi0IPoJCEpw/TwtYXCd7qtKZE=; b=XhRZe9j6FdlWxGN3SdYAW2b51uVep8T0+bDXy4zPqKtCrzw3x+juMmDR9ecoTZ/17Gr8Hmsc0H06i030bRFfGSLhd5ElNo6St0GZwpshhcES0is6gKjwHYShdlHkdVwG+QVe/aJxGAFHGel3EOwJmSDXww0G6KN/otHyOFk8a28= Received: from DM6PR11MB3194.namprd11.prod.outlook.com (2603:10b6:5:5c::25) by DM6PR11MB4233.namprd11.prod.outlook.com (2603:10b6:5:14f::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4087.35; Tue, 4 May 2021 00:17:47 +0000 Received: from DM6PR11MB3194.namprd11.prod.outlook.com ([fe80::e4e0:cf18:7be1:8019]) by DM6PR11MB3194.namprd11.prod.outlook.com ([fe80::e4e0:cf18:7be1:8019%7]) with mapi id 15.20.4087.043; Tue, 4 May 2021 00:17:47 +0000 From: "Juan Alcaide (jalcaide)" To: =?utf-8?B?TWFnbnVzIE55c3Ryw7Zt?= CC: "secdir@ietf.org" , "draft-ietf-idr-bgp-flowspec-oid@ietf.org" Thread-Topic: Secdir review of draft-ietf-idr-bgp-flowspec-oid-13 Thread-Index: AQHXP9b+AhhGGu0YA0eUTG7ppR6g/arRhrnQgAChcQCAAEs4UA== Date: Tue, 4 May 2021 00:17:47 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [83.38.90.229] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c2ce23cf-c5da-4664-391d-08d90e920bcb x-ms-traffictypediagnostic: DM6PR11MB4233: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: unltvO590vOIY+CdsYV7jYqdaDdEHIbblRu36hir9VK4Q0J1W7gXRqqmPcbY423GGt59vX0VQfR9tI+TyctZOBlYUaiokoXM1tOCJtnj9Eq+qIO1EqMRA6UZJ5MjTUaDFuko85zz0MnJWlAmtiQCS9dOhVE93+nmRIA9zorWsJLpdrKFdHD3bcgrhLmuwfv1oQscO0M3vsayVE0IyBZMPOVmqDaDyWefCnXk2YNTQvBSg2i2wAf7Jgtv6OH138uHD2KvilWyMnqvRCNd7tGCoZrlLS1Uhnnn6OfqJeVnCL19Wkrd8TzOF2nF8EwClylfcfCv2yyHzWPyRZcM4IIS3/LJUaOYN3w2yEotDwa1I6LNzm0e3W4a1eK4uJYsl9zaTxAW0pihZrTIij+DngoVfgV+IE164kJ6OsR2L0GLjyKbv6CY7oxN71mIc3TksnM2qje10OtkJff4lhkAjGh7PH5vCshxV9Qsd6Pl+p6mqhYwpx2Pwj2gbHlg6NF0qkPSOTORXdio9eq11VdbVhzDwHX8G+Hf5lZGZwHORZa3EBSeLfkgyLNQNkfObzn/mncd+m+ldRiPEOtX90cRbobPsQpUmktYmuZKQpX/blrDd9YlAJcY1U7UyKDJuvMd/DbVWWaeiSTnWRSgj/vfR+uoVXSVGFs0AGj/tJZxOtbctp0mlehlCVPdy4Hn46OwlE/I x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR11MB3194.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(396003)(346002)(366004)(376002)(39860400002)(54906003)(64756008)(2906002)(66476007)(316002)(122000001)(38100700002)(5660300002)(76116006)(66946007)(66556008)(66446008)(26005)(4326008)(86362001)(66574015)(71200400001)(33656002)(52536014)(166002)(478600001)(6916009)(83380400001)(8936002)(7696005)(55016002)(53546011)(6506007)(8676002)(186003)(9686003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?UUdCRmd6dWNSSHdPVlVnUTdpQk5SSVdhTlpzMkU4U1p5YzAzUGZ5dkNYcHNp?= =?utf-8?B?KzFMb0IrK2FXSWNBdnluK0NTM0xTZnVjaE5PTjZ0MktNU1dEdHhlOEJhaG1E?= =?utf-8?B?em8rRGVnQnZZaVFsOWx5TmpIalNLQkhYbmF6aUw1ZHZuWXlTQS81d0gxWm1z?= =?utf-8?B?SkE2KzFhZzZRdW1LcnVuYzlYOHU0RWhWekdPektzR3ZaU2tQUStmSFBlY3Na?= =?utf-8?B?c2FWRGhWWlVlbUkzcWk5KzBoZ21VSm5wVklNTDd6cU9FMTFBRGExZEJVM0tF?= =?utf-8?B?R2Q5eHBBaUtZYnF2bFFWV3hWQWpveGZ3UHR0YU9yVFNqcE9oQVBOcm5MeGdL?= =?utf-8?B?YnJEL3BJWU9UdGxRb2JxWFFxZFdYcklEc3ljZlg2L2hxZTlhcjN5RFBITEdw?= =?utf-8?B?RGV1TlJmOW95NUZHaFRLa2NXQVVuQU91ZEwvb3hwY2lKbkh0REl4OVREOWxK?= =?utf-8?B?aEZzMHJCL0pKelJrcUNvZTFteFNjcElpTzJ1U1BwMStTRVhaYnJXWGdveWxM?= =?utf-8?B?ZDhVRTMrQWpoc25MYnJXN0dmN2tVR2VaVk92NUZQN2kyZURoTXVldEoxeGg1?= =?utf-8?B?TUg0SS9PZ3g5WUxTNG52ODlLd04zZmJSV2JDTElFQmZvLytmN3ljR1JqRUgz?= =?utf-8?B?TGthN0srczlXQ1FmOHQzN3cwOXl3Wm05U2VnZlBFRC9OWis0RllPMmtXd1Fk?= =?utf-8?B?bXE0anBtQVV3V3pUVG5KaERyRDdRV1hpZCtmUkYvS2ozUUgzRk4xdUx5MWJO?= =?utf-8?B?d1NPdHJlS0tGT0xOd2lWTzdHaTlpa1hEblcvRzBmRXVHRXpUbHRvQUdoUkZ2?= =?utf-8?B?dUcyNm1ON1AvVkFIOUUvalBaTGo0NjRjMkpyNCtROE9odWt2b083ajZ5M3pX?= =?utf-8?B?T1h1MFQ2RERja0hkcDJYcFZjQUNJTk5rUkFua3UzRU51a1AwSWVrK2YwK3dI?= =?utf-8?B?OGVwYjJUVFlzU0dFbnJiM1BTTjR2RGcrUVk4UmowQkNQbGx1T1A1OTU2RnlB?= =?utf-8?B?WS83SjNlZGFteE5YVU9nQmhiMW1SNmh5eW5kcTN1Vlo4RytscEc0TVg2MzVX?= =?utf-8?B?dHkxTVRiTzdDTjF6WEQ0bnNuMElaYUNoUmswVStWVzRtMFMzQkozQ2ZYTzYy?= =?utf-8?B?NU5sc0d3Uk42SW1GdE5WRWYxbVZ1M3l2QVJPZkpsNm9Oc2lENTBOeHNvWDFx?= =?utf-8?B?ZDhFQURVWWZKRnVCUlVaUjBVOGdRWDdET2crZjNLcHFuZjczTmN4cnVicmZX?= =?utf-8?B?NjgwR2dJVHBqTjRyanluNURpaTNab0ZuRjNoaXl6cVV2NC9KUGF5RnpLRWpy?= =?utf-8?B?Um5uaFRlOVpFbERkVTdjd1FsZVkvNHRhQ01HQW8xaGtOaXliZEJ1Y0UrZFJl?= =?utf-8?B?d0pOa1JGYlB2QUwybFlEWEdYMmRvTEZhRG5BdnBidExibWh6TVJVdkRTSTdI?= =?utf-8?B?NU5RaE5XWGxOcG5jWWtlTlZ0bVZDM2wydHR4WTZVUStaK0VpbmhuWC94Uisr?= =?utf-8?B?Y0hpaHhiT0gwYng4KzF6ZUNYRzRVZithRUpnMVNNYmZhend1RG9nSVY5bGVl?= =?utf-8?B?ZG9USTh2MDdLOHVjc1VIbzJKd29tcXZ3bVJVTUpvZFNJS1JlM1IrSEVWUHli?= =?utf-8?B?Wm1WdFVkNkZxMkNIOWdJQTBzcFcyMFJBeml0b2V2dzlScFlOQStmM2R0TVhI?= =?utf-8?B?R2ZZVDZmVVZia3ZKL0tuU2wzQmVneWp1aFFTWG5RY2xkaTJhL1V3dHgzSWx0?= =?utf-8?Q?swb2dlkXTVyv35ejCs=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR11MB3194CDD275DFB08A7CF91DBCCD5A9DM6PR11MB3194namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR11MB3194.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c2ce23cf-c5da-4664-391d-08d90e920bcb X-MS-Exchange-CrossTenant-originalarrivaltime: 04 May 2021 00:17:47.4808 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: KtauYpcHSHa9Zitd1dIZUWXnj05zc58/dnlskcCagoDTrFDCQXjpiy6Jm1+ARSz94SHf6sl+UksBaBM1hq8BeQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB4233 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.20, xbe-rcd-005.cisco.com X-Outbound-Node: alln-core-6.cisco.com Archived-At: Subject: Re: [secdir] Secdir review of draft-ietf-idr-bgp-flowspec-oid-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2021 00:17:57 -0000 --_000_DM6PR11MB3194CDD275DFB08A7CF91DBCCD5A9DM6PR11MB3194namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TWFnbnVzLA0KDQpZZXMsIHRoZXnigJlsbCBiZSBvcGVuaW5nIHRvIHJpc2suIEl04oCZcyB0aGUg cmlzayBkZXNjcmliZWQgaW4gdGhlIGRyYWZ0LiBCdXQgdGhpcyByaXNrIGlzIG5lY2Vzc2FyeSBm b3Igcm91dGUtc2VydmVycyB0byB3b3JrIHdpdGggZmxvd3NwZWMuIEFuZCBhcyBtZW50aW9uZWQs IHBlcmhhcHMgcm91dGUgc2VydmVycyBjYW4gYmUgY29uZmlndXJlZCB0byBhdm9pZCB0aGF0IHJp c2suDQoNCg0KSSB3YW50ZWQgdG8gdXNlIHRoZSB0ZXJtIOKAmHJlbWFpbuKAmSBpbnN0ZWFkIG9m IOKAmGJlY29tZeKAmS4uIFdlIHdlbnQgZnJvbSBSRkM0MjcxIChydWxlIG9wdGlvbmFsKSAtPiBS RkM4OTU1IChydWxlIG1hbmRhdG9yeSkgLT4gdGhpcyBkcmFmdCAocnVsZSBhZ2FpbiBvcHRpb25h bCkNCldvdWxkIHRoZSBiZWxvdyBtYWtlIHNlbnNlIChJIGNoYW5nZWQgdGhlIGZpcnN0IHNlbnRl bmNlKToNCg0KICAgVGhpcyBkb2N1bWVudCBtYWtlcyB0aGUgb3JpZ2luYWwgQVNfUEFUSCB2YWxp ZGF0aW9uIHJ1bGUgKFtSRkM0MjcxXSBzZWN0aW9uIDYuMykgYWdhaW4gb3B0aW9uYWwNCiAgIChz ZWN0aW9uIDQuMikgZm9yIEZsb3cgU3BlY2lmaWNhdGlvbiBBZGRyZXNzIEZhbWlseSAodGhlIHJ1 bGUgaXMgbm8gbG9uZ2VyIG1hbmRhdG9yeSBhcyBpdCB3YXMgc3BlY2lmaWVkIGJ5IFtSRkM4OTU1 XSkuDQogICBJZiB0aGF0IG9yaWdpbmFsIHJ1bGUgaXMgbm90IGVuZm9yY2VkIGZvciBGbG93IFNw ZWNpZmljYXRpb24gaXQgbWF5IGludHJvZHVjZSBzb21lIG5ldyBzZWN1cml0eSByaXNrcy4NCiAg IEEgcGVlciAob3IgYSBjbGllbnQgb2YgYSByb3V0ZSBzZXJ2ZXIgcGVlcikgaW4gQVMgWCBjb3Vs ZCBhZHZlcnRpc2UgYSByb2d1ZSBGbG93DQogICBTcGVjaWZpY2F0aW9uIHJvdXRlIHdob3NlIGZp cnN0IEFTIGluIEFTX1BBVEggd2FzIFkgKGFzc3VtZSBZIGlzIHRoZQ0KICAgZmlyc3QgQVMgaW4g dGhlIEFTX1BBVEggb2YgdGhlIGJlc3QtbWF0Y2ggdW5pY2FzdCByb3V0ZSkuICBUaGlzIHJpc2sN CiAgIGlzIGltcG9zc2libGUgdG8gcHJldmVudCBpZiB0aGUgRmxvdyBTcGVjaWZpY2F0aW9uIHJv dXRlIGlzIHJlY2VpdmVkDQogICBmcm9tIGEgcm91dGUgc2VydmVyIHBlZXIuICBJZiB0aGF0IHBl ZXIgaXMga25vd24gZm9yIGEgZmFjdCBub3QgdG8gYmUNCiAgIGEgcm91dGUgc2VydmVyLCB0aGF0 IG9wdGlvbmFsIHJ1bGUgU0hPVUxEIGJlIGVuZm9yY2VkIGZvciBGbG93DQogICBTcGVjaWZpY2F0 aW9uIHJvdXRlcy4gTm90ZSB0aGF0IGlkZW50aWZ5aW5nIHRob3NlIHBlZXJzIHRoYXQgYXJlIHJv dXRlIHNlcnZlcnMgbWF5IHN1cHBvc2UgYW4NCiAgIG9wZXJhdGlvbmFsIGNoYWxsZW5nZS4gSWYg dGhlIGNvbmRpdGlvbiBvZiB0aGUgcGVlciBpcyB1bmtub3duLCB0aGUgcnVsZSBTSE9VTEQgbm90 IGJlDQogICBlbmZvcmNlZC4NCg0KICAgQSByb3V0ZSBzZXJ2ZXIgaXRzZWxmIG1heSBiZSBpbiBh IGdvb2QgcG9zaXRpb24gdG8gZW5mb3JjZSB0aGUgQVNfUEFUSCB2YWxpZGF0aW9uIHJ1bGUgZGVz Y3JpYmVkDQogIGluIHRoZSBwcmV2aW91cyBwYXJhZ3JhcGguIElmIGEgcm91dGUgc2VydmVyIGtu b3ducyBpdOKAmXMgbm90IHBlZXJpbmcgd2l0aCBhbnkgb3RoZXIgcm91dGUgc2VydmVyLA0KICAg aXQgY2FuIGVuZm9yY2UgdGhlIEFTX1BBVEggdmFsaWRhdGlvbiBydWxlIGFjcm9zcyBhbGwgaXRz IHBlZXJzLiBJZiwgaW4gYWRkaXRpb24gdG8gdGhhdCwNCiAgIHRoZSByb3V0ZSBzZXJ2ZXIgaXMg dHJ1c3RlZCwgdGhlIHNlY3VyaXR5IHRocmVhdCBkZXNjcmliZWQgYWJvdmUgZGlzYXBwZWFycy4N Cg0KDQoNCg0KRnJvbTogTWFnbnVzIE55c3Ryw7ZtIDxtYWdudXNuQGdtYWlsLmNvbT4NClNlbnQ6 IE1vbmRheSwgTWF5IDMsIDIwMjEgOTozOSBQTQ0KVG86IEp1YW4gQWxjYWlkZSAoamFsY2FpZGUp IDxqYWxjYWlkZUBjaXNjby5jb20+DQpDYzogc2VjZGlyQGlldGYub3JnOyBkcmFmdC1pZXRmLWlk ci1iZ3AtZmxvd3NwZWMtb2lkQGlldGYub3JnDQpTdWJqZWN0OiBSZTogU2VjZGlyIHJldmlldyBv ZiBkcmFmdC1pZXRmLWlkci1iZ3AtZmxvd3NwZWMtb2lkLTEzDQoNClRoYW5rcyBKdWFuLg0KRm9y IHRoZSBlZGl0b3JpYWwgb25lcywgYWdyZWUgb24gdGhlIGZpcnN0IG9uZSBhbmQgSSB0aGluayB0 aGUgc2Vjb25kIHlvdSBjb3VsZCBjaGFuZ2UgdG8gIndpdGggdGhpcyBtZW1vLCBiZWNvbWVzIG9w dGlvbmFsLiIgb3Igc2ltaWxhci4NCkZvciB0aGUgbmV3IHRleHQsIHBlcmhhcHMgSSBhbSBtaXN1 bmRlcnN0YW5kaW5nIHNvbWV0aGluZywgYnV0IHRoaXMgc2VudGVuY2U6DQpOb3RlIHRoYXQgaWRl bnRpZnlpbmcgdGhvc2UgcGVlcnMgdGhhdCBhcmUgcm91dGUgc2VydmVycyBtYXkgc3VwcG9zZSBh biBvcGVyYXRpb25hbCBjaGFsbGVuZ2UuIElmIHRoZSBjb25kaXRpb24gb2YgdGhlIHBlZXIgaXMg dW5rbm93biwgdGhlIHJ1bGUgU0hPVUxEIG5vdCBiZSBlbmZvcmNlZC4NCklzIGl0IGNvcnJlY3Rs eSB1bmRlcnN0b29kLCB0aGF0IHlvdSdyZSBzYXlpbmcgdGhhdCBpZiBhIHZhbGlkYXRvciBpcyB1 bmFibGUgdG8gZGV0ZXJtaW5lIGlmIHRoZSBwZWVyIGlzIGEgcm91dGUgc2VydmVyLCB0aGV5IHNo b3VsZCBub3QgZW5mb3JjZSB0aGUgcnVsZT8gSWYgc28sIGRvZXNuJ3QgdGhhdCBtZWFuICJmYWls aW5nIG9wZW4sIGkuZS4sIG9wZW5pbmcgdGhlbXNlbHZlcyB0byByaXNrPyBTb3JyeSBpZiBJIG1p c3VuZGVyc3RhbmQuDQoNCg0KT24gTW9uLCBNYXkgMywgMjAyMSBhdCAzOjM2IEFNIEp1YW4gQWxj YWlkZSAoamFsY2FpZGUpIDxqYWxjYWlkZUBjaXNjby5jb208bWFpbHRvOmphbGNhaWRlQGNpc2Nv LmNvbT4+IHdyb3RlOg0KVGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLCBNYWdudXMNCg0KSW5saW5l Li4NCg0KRnJvbTogTWFnbnVzIE55c3Ryw7ZtIDxtYWdudXNuQGdtYWlsLmNvbTxtYWlsdG86bWFn bnVzbkBnbWFpbC5jb20+Pg0KU2VudDogTW9uZGF5LCBNYXkgMywgMjAyMSA2OjQ0IEFNDQpUbzog c2VjZGlyQGlldGYub3JnPG1haWx0bzpzZWNkaXJAaWV0Zi5vcmc+OyBkcmFmdC1pZXRmLWlkci1i Z3AtZmxvd3NwZWMtb2lkQGlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLWlkci1iZ3AtZmxvd3Nw ZWMtb2lkQGlldGYub3JnPg0KU3ViamVjdDogU2VjZGlyIHJldmlldyBvZiBkcmFmdC1pZXRmLWlk ci1iZ3AtZmxvd3NwZWMtb2lkLTEzDQoNCkkgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFz IHBhcnQgb2YgdGhlIHNlY3VyaXR5IGRpcmVjdG9yYXRlJ3Mgb25nb2luZyBlZmZvcnQgdG8gcmV2 aWV3IGFsbCBJRVRGIGRvY3VtZW50cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhlIElFU0cuIFRoZXNl IGNvbW1lbnRzIHdlcmUgd3JpdHRlbiBwcmltYXJpbHkgZm9yIHRoZSBiZW5lZml0IG9mIHRoZSBz ZWN1cml0eSBhcmVhIGRpcmVjdG9ycy4gIERvY3VtZW50IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBz aG91bGQgdHJlYXQgdGhlc2UgY29tbWVudHMganVzdCBsaWtlIGFueSBvdGhlciBsYXN0IGNhbGwg Y29tbWVudHMuDQoNClRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzICJhIG1vZGlmaWNhdGlvbiB0byB0 aGUgdmFsaWRhdGlvbiBwcm9jZWR1cmUgZGVmaW5lZCBmb3IgdGhlIGRpc3NlbWluYXRpb24NCm9m IEJHUCBGbG93IFNwZWNpZmljYXRpb25zLiIgTW9yZSBzcGVjaWZpY2FsbHkuIHRoZSBtZW1vIGRl c2NyaWJlcyBhIG1lY2hhbmlzbSB3aGljaCByZWxheGVzICB0aGUgZXhpc3RpbmcgdmFsaWRhdGlv biBydWxlIHRoYXQgcmVxdWlyZXMgRmxvdyBTcGVjaWZpY2F0aW9ucyB0byBiZSBvcmlnaW5hdGlu ZyBmcm9tIHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBiZXN0LW1hdGNoIHVuaWNhc3Qgcm91dGUsIGFu ZCBub3cgYWxsb3dzIHN1Y2ggc3BlY2lmaWNhdGlvbnMgdG8gYmUgb3JpZ2luYXRlZCB3aXRoaW4g dGhlIHNhbWUgQVMgYXMgdGhlIHZhbGlkYXRvci4gQXMgYSByZXN1bHQuIHRoZSBTZWN1cml0eSBD b25zaWRlcmF0aW9ucyBzZWN0aW9uIGRvZXMgY2FsbCBvdXQ6ICJUaGUgb3JpZ2luYWwgQVNfUEFU SCB2YWxpZGF0aW9uIHJ1bGUgKFtSRkM0MjcxXSBzZWN0aW9uIDYuMzxodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvcmZjNDI3MSNzZWN0aW9uLTYuMz4pIGJlY29tZXMgIGhlcmVieSBvcHRpb25h bCAoc2VjdGlvbiA0LjI8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtaWRy LWJncC1mbG93c3BlYy1vaWQtMTMjc2VjdGlvbi00LjI+KS4gSWYgdGhhdCBvcmlnaW5hbCBydWxl IGlzIGFjdHVhbGx5IG5vdCBlbmZvcmNlZCBpdCBtYXkgaW50cm9kdWNlIHNvbWUgc2VjdXJpdHkg cmlza3MuIEEgcGVlciAob3IgYSBjbGllbnQgb2YgYSByb3V0ZSBzZXJ2ZXIgcGVlcikgaW4gQVMg WCBjb3VsZCBhZHZlcnRpc2UgYSByb2d1ZSBGbG93IFNwZWNpZmljYXRpb24gcm91dGUuLi4uIiBh bmQgIklmIHRbdGhlIG9yaWdpbmF0b3Igb2YgYSBydWxlXSBpcyBrbm93biBmb3IgYSBmYWN0IG5v dCB0byBiZSBhIHJvdXRlIHNlcnZlciwgdGhhdCBvcHRpb25hbCBydWxlIFNIT1VMRCBiZSBlbmZv cmNlZCBmb3IgRmxvdyBTcGVjaWZpY2F0aW9uIHJvdXRlcy4iDQoNCkl0IGlzIG5vdCBjbGVhciB0 byBtZSBob3cgYSB2YWxpZGF0b3Igd291bGQgbm93ICJmb3IgYSBmYWN0IiB0aGF0IGEgcGVlciBp c24ndCBhIHJvdXRlIHNlcnZlciwgYW5kIHRodXMgdGhhdCBpdCB3b3VsZCBoYXZlIHRvIGVuZm9y Y2UgdGhlIG5vdy1vcHRpb25hbCBwYXRoIHZhbGlkYXRpb24gcnVsZS4gSXQgc2VlbXMgc29tZSBj bGFyaXR5IG9uIHRoaXMgd291bGQgYmUgZ29vZCBzdWNoIHRoYXQgaW1wbGVtZW50YXRpb25zIGhh dmUgbGVzcyBvZiBhIHJpc2sgb2YgYWNjZXB0aW5nIGZsb3cgc3BlY2lmaWNhdGlvbnMgZnJvbSB1 bmF1dGhvcml6ZWQgcGFydGllcywgZXZlbiBpZiB0aGV5IGFyZSBvbiB0aGUgc2FtZSBBUy4NCg0K W0pVQU5dOiBUaGlzIHBhcmFncmFwaCB3YXMgbm90IGludGVuZGVkIHRvIHByZXNzdXJlIHRoZSBv cGVyYXRvciB0byBrbm93IGlmIHRoZSBwZWVyIHdhcyBhIHJvdXRlIHNlcnZlciwgaXQgd2FzIGp1 c3QgYSDigJhpZuKAmS4gTm90ZSBpdOKAmXMgdGhlIHNhbWUgY2FzZSBmb3IgUkZDNDI3MSA6DQoN CklmIHRoZSBVUERBVEUgbWVzc2FnZSBpcyByZWNlaXZlZCBmcm9tIGFuIGV4dGVybmFsIHBlZXIs IHRoZSBsb2NhbA0KICAgc3lzdGVtIE1BWSBjaGVjayB3aGV0aGVyIHRoZSBsZWZ0bW9zdCAod2l0 aCByZXNwZWN0IHRvIHRoZSBwb3NpdGlvbg0KICAgb2Ygb2N0ZXRzIGluIHRoZSBwcm90b2NvbCBt ZXNzYWdlKSBBUyBpbiB0aGUgQVNfUEFUSCBhdHRyaWJ1dGUgaXMNCiAgIGVxdWFsIHRvIHRoZSBh dXRvbm9tb3VzIHN5c3RlbSBudW1iZXIgb2YgdGhlIHBlZXIgdGhhdCBzZW50IHRoZQ0KICAgbWVz c2FnZS4NCg0KDQpOb3RlIHRoYXQgdGhlIHNhbWUgY2hhbGxlbmdlIG9mIGlkZW50aWZ5aW5nIHJv dXRlIHNlcnZlcnMgYXBwbGllcyBmb3Igb3RoZXIgYWRkcmVzcy1mYW1pbGllcy4NCk5vdGUgYWxz byB0aGF0IHRoZSByb3V0ZS1zZXJ2ZXIgaXRzZWxmIG1heSBlbmZvcmNlIHRoZSBydWxlLg0KDQpX aGF0IGFib3V0IGZvciBjbGFyaXR5Og0KDQogICBUaGUgb3JpZ2luYWwgQVNfUEFUSCB2YWxpZGF0 aW9uIHJ1bGUgKFtSRkM0MjcxXSBzZWN0aW9uIDYuMykgcmVtYWlucyBoZXJlYnkgc3RpbGwgb3B0 aW9uYWwNCiAgIChzZWN0aW9uIDQuMikgZm9yIEZsb3cgU3BlY2lmaWNhdGlvbiBBZGRyZXNzIEZh bWlseSAoY2hhbmdlcyBpbnRyb2R1Y2VkIGluIFtSRkM1NTc1XSBhcmUgY2FuY2VsbGVkKS4NCiAg IElmIHRoYXQgb3JpZ2luYWwgcnVsZSBpcyBub3QgZW5mb3JjZWQgZm9yIEZsb3cgU3BlY2lmaWNh dGlvbiBpdCBtYXkgaW50cm9kdWNlIHNvbWUgbmV3IHNlY3VyaXR5IHJpc2tzLg0KICAgQSBwZWVy IChvciBhIGNsaWVudCBvZiBhIHJvdXRlIHNlcnZlciBwZWVyKSBpbiBBUyBYIGNvdWxkIGFkdmVy dGlzZSBhIHJvZ3VlIEZsb3cNCiAgIFNwZWNpZmljYXRpb24gcm91dGUgd2hvc2UgZmlyc3QgQVMg aW4gQVNfUEFUSCB3YXMgWSAoYXNzdW1lIFkgaXMgdGhlDQogICBmaXJzdCBBUyBpbiB0aGUgQVNf UEFUSCBvZiB0aGUgYmVzdC1tYXRjaCB1bmljYXN0IHJvdXRlKS4gIFRoaXMgcmlzaw0KICAgaXMg aW1wb3NzaWJsZSB0byBwcmV2ZW50IGlmIHRoZSBGbG93IFNwZWNpZmljYXRpb24gcm91dGUgaXMg cmVjZWl2ZWQNCiAgIGZyb20gYSByb3V0ZSBzZXJ2ZXIgcGVlci4gIElmIHRoYXQgcGVlciBpcyBr bm93biBmb3IgYSBmYWN0IG5vdCB0byBiZQ0KICAgYSByb3V0ZSBzZXJ2ZXIsIHRoYXQgb3B0aW9u YWwgcnVsZSBTSE9VTEQgYmUgZW5mb3JjZWQgZm9yIEZsb3cNCiAgIFNwZWNpZmljYXRpb24gcm91 dGVzLiBOb3RlIHRoYXQgaWRlbnRpZnlpbmcgdGhvc2UgcGVlcnMgdGhhdCBhcmUgcm91dGUgc2Vy dmVycyBtYXkgc3VwcG9zZSBhbg0KICAgb3BlcmF0aW9uYWwgY2hhbGxlbmdlLiBJZiB0aGUgY29u ZGl0aW9uIG9mIHRoZSBwZWVyIGlzIHVua25vd24sIHRoZSBydWxlIFNIT1VMRCBub3QgYmUNCiAg IGVuZm9yY2VkLg0KDQogICBBIHJvdXRlIHNlcnZlciBpdHNlbGYgbWF5IGJlIGluIGEgZ29vZCBw b3NpdGlvbiB0byBlbmZvcmNlIHRoZSBBU19QQVRIIHZhbGlkYXRpb24gcnVsZSBkZXNjcmliZWQN CiAgaW4gdGhlIHByZXZpb3VzIHBhcmFncmFwaC4gSWYgYSByb3V0ZSBzZXJ2ZXIga25vd25zIGl0 4oCZcyBub3QgcGVlcmluZyB3aXRoIGFueSBvdGhlciByb3V0ZSBzZXJ2ZXIsDQogICBpdCBjYW4g ZW5mb3JjZSB0aGUgQVNfUEFUSCB2YWxpZGF0aW9uIHJ1bGUgYWNyb3NzIGFsbCBpdHMgcGVlcnMu IElmLCBpbiBhZGRpdGlvbiB0byB0aGF0LA0KICAgdGhlIHJvdXRlIHNlcnZlciBpcyB0cnVzdGVk LCB0aGUgc2VjdXJpdHkgdGhyZWF0IGRlc2NyaWJlZCBhYm92ZSBkaXNhcHBlYXJzLg0KDQoNCg0K QW55Ym9keSBmZWVsIGZyZWUgdG8gcmV3b3JkIHRoZSB0d28gcGFyYWdyYXBocyBhYm92ZSBpZiBp dCBoZWxwcyB0aGVtIGZvciBjbGFyaXR5Lg0KDQoNCg0KRWRpdG9yaWFsOg0KDQogICogICAiTGV0 J3MgY29uc2lkZXIgdGhlIHBhcnRpY3VsYXIgY2FzZSB3aGVyZSB0aGUgRmxvdyBTcGVjaWZpY2F0 aW9uIGlzIG9yaWdpbmF0ZWQgaW4gYW55IGxvY2F0aW9uIHdpdGhpbiB0aGUgc2FtZSBhdXRvbm9t b3VzIHN5c3RlbSB0aGFuIHRoZSBzcGVha2VyIHBlcmZvcm1pbmcgdGhlIHZhbGlkYXRpb24gKGZv ciBleGFtcGxlIGJ5IGEgY2VudHJhbGl6ZWQgQkdQIHJvdXRlIGNvbnRyb2xsZXIpLCBhbmQgdGhl IGJlc3QtbWF0Y2ggdW5pY2FzdCByb3V0ZSBpcyBvcmlnaW5hdGVkIGluIGFub3RoZXIgYXV0b25v bW91cyBzeXN0ZW0uIiAtIHNob3VsZCB0aGUgd29yZCAidGhhbiIgYmUgcmVwbGFjZWQgd2l0aCAi dGhhdCIgaGVyZT8NCltKVUFOXTogVGhhbmtzIGZvciBwb2ludGluZyB0aGF0IG91dC4gQSBmZXcg Z29vZ2xpbmcgdGVsbHMgbWUgdGhlIGV2ZW4gYmV0dGVyIGdyYW1tYXRpY2FsIGNob2ljZSB3b3Vs ZCBiZSDigJhzYW1lIGFz4oCZIGluIHRoaXMgY2FzZS4gSeKAmWxsIGJlIHVzaW5nIOKAmHNhbWUg YXPigJkgdW5sZXNzICB5b3UgZGlzYWdyZWUuDQoNCg0KICAqICAgSW4gdGhlIHNlY3VyaXR5IGNv bnNpZGVyYXRpb25zIHNlY3Rpb24sICJiZWNvbWVzIGhlcmVieSBvcHRpb25hbCIgY291bGQgcHJv YmFibHkgYmUgc2ltcGxpZmllZCB0byAiYmVjb21lcyBvcHRpb25hbCIgb3Igc2ltaWxhciwgYW5k ICJhY3R1YWxseSIgY291bGQgYmUgcmVtb3ZlZC4NCltKVUFOXTogIEhtbW0sIEkgdGhvdWdodCB0 aGF0IGl0IHdhcyBpbXBvcnRhbnQgdG8gZW1waGFzaXplIGl0IGJlY29tZXMgb3B0aW9uYWwgYmVj YXVzZSBvZiAqdGhpcyogZHJhZnQgcmVkZWZpbml0aW9uIG9mIHJ1bGVzLiBEb27igJl0IHlvdSB0 aGluayBpdOKAmXMgaW1wb3J0YW50PyAod2hhdGV2ZXIgd29yZGluZyB5b3Ugd2FudCB0byB1c2Up LiBSZWdhcmRsZXNzLCByZWZlciB0byBteSBuZXcgcmV3b3JkZWQgMiBwYXJhZ3JhcGhzIGFib3Zl IGZvciB0aGF0IHNlY3Rpb24gLg0KDQoNCg0KDQpUaGFua3MsDQotLSBNYWdudXMNCg0KDQoNCi0t DQotLSBNYWdudXMNCg== --_000_DM6PR11MB3194CDD275DFB08A7CF91DBCCD5A9DM6PR11MB3194namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCWZvbnQtc2l6ZTox MS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHls ZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25z b2xhczt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBs eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0 O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICov DQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDozNTg3MDYwNjc7DQoJbXNvLWxpc3QtdGVtcGxhdGUt aWRzOi0xOTgzMjEyMzUyO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDou NWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw2 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2 ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6MTQ4ODY3 MDYzNzsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTI4ODcyNjk0NDt9DQpAbGlzdCBsMTpsZXZl bDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxl dmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwx OmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCm9sDQoJ e21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh ZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIiBzdHlsZT0i d29yZC13cmFwOmJyZWFrLXdvcmQiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPk1hZ251cyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WWVzLCB0aGV5 4oCZbGwgYmUgb3BlbmluZyB0byByaXNrLiBJdOKAmXMgdGhlIHJpc2sgZGVzY3JpYmVkIGluIHRo ZSBkcmFmdC4gQnV0IHRoaXMgcmlzayBpcyBuZWNlc3NhcnkgZm9yIHJvdXRlLXNlcnZlcnMgdG8g d29yayB3aXRoIGZsb3dzcGVjLiBBbmQgYXMgbWVudGlvbmVkLCBwZXJoYXBzIHJvdXRlIHNlcnZl cnMgY2FuIGJlIGNvbmZpZ3VyZWQgdG8gYXZvaWQgdGhhdCByaXNrLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgd2Fu dGVkIHRvIHVzZSB0aGUgdGVybSDigJhyZW1haW7igJkgaW5zdGVhZCBvZiDigJhiZWNvbWXigJku LiBXZSB3ZW50IGZyb20gUkZDNDI3MSAocnVsZSBvcHRpb25hbCkgLSZndDsgUkZDODk1NSAocnVs ZSBtYW5kYXRvcnkpIC0mZ3Q7IHRoaXMgZHJhZnQgKHJ1bGUgYWdhaW4gb3B0aW9uYWwpPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Xb3VsZCB0aGUgYmVsb3cgbWFrZSBzZW5z ZSAoSSBjaGFuZ2VkIHRoZSBmaXJzdCBzZW50ZW5jZSk6PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBUaGlzIGRvY3VtZW50IG1ha2Vz IHRoZSBvcmlnaW5hbCBBU19QQVRIIHZhbGlkYXRpb24gcnVsZSAoW1JGQzQyNzFdIHNlY3Rpb24g Ni4zKSBhZ2FpbiBvcHRpb25hbDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyAoc2VjdGlvbiA0LjIp IGZvciBGbG93IFNwZWNpZmljYXRpb24gQWRkcmVzcyBGYW1pbHkgKHRoZSBydWxlIGlzIG5vIGxv bmdlciBtYW5kYXRvcnkgYXMgaXQgd2FzIHNwZWNpZmllZA0KIGJ5IFtSRkM4OTU1XSkuIDwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwO0lmIHRoYXQgb3JpZ2luYWwgcnVsZSBpcyBub3QgZW5m b3JjZWQgZm9yIEZsb3cgU3BlY2lmaWNhdGlvbiBpdCBtYXkgaW50cm9kdWNlIHNvbWUgbmV3IHNl Y3VyaXR5IHJpc2tzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBBIHBlZXIgKG9yIGEgY2xpZW50 IG9mIGEgcm91dGUgc2VydmVyIHBlZXIpIGluIEFTIFggY291bGQgYWR2ZXJ0aXNlIGEgcm9ndWUg Rmxvdzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBTcGVjaWZpY2F0aW9uIHJvdXRlIHdob3NlIGZp cnN0IEFTIGluIEFTX1BBVEggd2FzIFkgKGFzc3VtZSBZIGlzIHRoZTwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNw OyZuYnNwOyBmaXJzdCBBUyBpbiB0aGUgQVNfUEFUSCBvZiB0aGUgYmVzdC1tYXRjaCB1bmljYXN0 IHJvdXRlKS4mbmJzcDsgVGhpcyByaXNrPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGlzIGltcG9z c2libGUgdG8gcHJldmVudCBpZiB0aGUgRmxvdyBTcGVjaWZpY2F0aW9uIHJvdXRlIGlzIHJlY2Vp dmVkPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGZyb20gYSByb3V0ZSBzZXJ2ZXIgcGVlci4mbmJz cDsgSWYgdGhhdCBwZWVyIGlzIGtub3duIGZvciBhIGZhY3Qgbm90IHRvIGJlPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+ Jm5ic3A7Jm5ic3A7IGEgcm91dGUgc2VydmVyLCB0aGF0IG9wdGlvbmFsIHJ1bGUgU0hPVUxEIGJl IGVuZm9yY2VkIGZvciBGbG93PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IFNwZWNpZmljYXRpb24g cm91dGVzLiBOb3RlIHRoYXQgaWRlbnRpZnlpbmcgdGhvc2UgcGVlcnMgdGhhdCBhcmUgcm91dGUg c2VydmVycyBtYXkgc3VwcG9zZSBhbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBvcGVyYXRpb25h bCBjaGFsbGVuZ2UuIElmIHRoZSBjb25kaXRpb24gb2YgdGhlIHBlZXIgaXMgdW5rbm93biwgdGhl IHJ1bGUgU0hPVUxEIG5vdCBiZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBlbmZvcmNlZC48L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgQSByb3V0ZSBzZXJ2ZXIgaXRz ZWxmIG1heSBiZSBpbiBhIGdvb2QgcG9zaXRpb24gdG8gZW5mb3JjZSB0aGUgQVNfUEFUSCB2YWxp ZGF0aW9uIHJ1bGUgZGVzY3JpYmVkPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7aW4gdGhlIHByZXZp b3VzIHBhcmFncmFwaC4gSWYgYSByb3V0ZSBzZXJ2ZXIga25vd25zIGl04oCZcyBub3QgcGVlcmlu ZyB3aXRoIGFueSBvdGhlciByb3V0ZSBzZXJ2ZXIsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGl0 IGNhbiBlbmZvcmNlIHRoZSBBU19QQVRIIHZhbGlkYXRpb24gcnVsZSBhY3Jvc3MgYWxsIGl0cyBw ZWVycy4gSWYsIGluIGFkZGl0aW9uIHRvIHRoYXQsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IHRo ZSByb3V0ZSBzZXJ2ZXIgaXMgdHJ1c3RlZCwgdGhlIHNlY3VyaXR5IHRocmVhdCBkZXNjcmliZWQg YWJvdmUgZGlzYXBwZWFycy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBNYWdudXMg TnlzdHLDtm0gJmx0O21hZ251c25AZ21haWwuY29tJmd0OyA8YnI+DQo8Yj5TZW50OjwvYj4gTW9u ZGF5LCBNYXkgMywgMjAyMSA5OjM5IFBNPGJyPg0KPGI+VG86PC9iPiBKdWFuIEFsY2FpZGUgKGph bGNhaWRlKSAmbHQ7amFsY2FpZGVAY2lzY28uY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gc2VjZGly QGlldGYub3JnOyBkcmFmdC1pZXRmLWlkci1iZ3AtZmxvd3NwZWMtb2lkQGlldGYub3JnPGJyPg0K PGI+U3ViamVjdDo8L2I+IFJlOiBTZWNkaXIgcmV2aWV3IG9mIGRyYWZ0LWlldGYtaWRyLWJncC1m bG93c3BlYy1vaWQtMTM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlRoYW5rcyBKdWFuLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Rm9yIHRoZSBlZGl0b3JpYWwgb25lcywgYWdyZWUgb24gdGhlIGZpcnN0IG9u ZSBhbmQgSSB0aGluayB0aGUgc2Vjb25kIHlvdSBjb3VsZCBjaGFuZ2UgdG8gJnF1b3Q7d2l0aCB0 aGlzIG1lbW8sIGJlY29tZXMgb3B0aW9uYWwuJnF1b3Q7IG9yIHNpbWlsYXIuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Gb3IgdGhlIG5ldyB0ZXh0 LCBwZXJoYXBzIEkgYW0gbWlzdW5kZXJzdGFuZGluZyBzb21ldGhpbmcsIGJ1dCB0aGlzIHNlbnRl bmNlOg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOmJsYWNrIj5Ob3RlIHRoYXQgaWRlbnRpZnlpbmcgdGhvc2UgcGVlcnMgdGhhdCBhcmUgcm91 dGUgc2VydmVycyBtYXkgc3VwcG9zZSBhbiBvcGVyYXRpb25hbCBjaGFsbGVuZ2UuIElmIHRoZSBj b25kaXRpb24NCiBvZiB0aGUgcGVlciBpcyB1bmtub3duLCB0aGUgcnVsZSBTSE9VTEQgbm90IGJl IGVuZm9yY2VkLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+SXMgaXQgY29ycmVjdGx5IHVuZGVyc3Rvb2QsIHRo YXQgeW91J3JlIHNheWluZyB0aGF0IGlmIGEgdmFsaWRhdG9yIGlzIHVuYWJsZSB0byBkZXRlcm1p bmUgaWYgdGhlIHBlZXIgaXMNCiBhIHJvdXRlIHNlcnZlciwgdGhleSBzaG91bGQgbm90IGVuZm9y Y2UgdGhlIHJ1bGU/IElmIHNvLCBkb2Vzbid0IHRoYXQgbWVhbiAmcXVvdDtmYWlsaW5nIG9wZW4s IGkuZS4sIG9wZW5pbmcgdGhlbXNlbHZlcyB0byByaXNrPyBTb3JyeSBpZiBJIG1pc3VuZGVyc3Rh bmQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24g TW9uLCBNYXkgMywgMjAyMSBhdCAzOjM2IEFNIEp1YW4gQWxjYWlkZSAoamFsY2FpZGUpICZsdDs8 YSBocmVmPSJtYWlsdG86amFsY2FpZGVAY2lzY28uY29tIj5qYWxjYWlkZUBjaXNjby5jb208L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGlu IDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGFua3MgZm9yIHlvdXIgY29tbWVudHMsIE1h Z251czxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SW5saW5lLi48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzoz LjBwdCAwaW4gMGluIDBpbjtib3JkZXItY29sb3I6Y3VycmVudGNvbG9yIGN1cnJlbnRjb2xvciI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPkZyb206PC9iPiBNYWdudXMgTnlzdHLDtm0gJmx0 OzxhIGhyZWY9Im1haWx0bzptYWdudXNuQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1hZ251 c25AZ21haWwuY29tPC9hPiZndDsNCjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIE1heSAzLCAy MDIxIDY6NDQgQU08YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzpzZWNkaXJAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5zZWNkaXJAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86 ZHJhZnQtaWV0Zi1pZHItYmdwLWZsb3dzcGVjLW9pZEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi Pg0KZHJhZnQtaWV0Zi1pZHItYmdwLWZsb3dzcGVjLW9pZEBpZXRmLm9yZzwvYT48YnI+DQo8Yj5T dWJqZWN0OjwvYj4gU2VjZGlyIHJldmlldyBvZiBkcmFmdC1pZXRmLWlkci1iZ3AtZmxvd3NwZWMt b2lkLTEzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSBoYXZlIHJl dmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgc2VjdXJpdHkgZGlyZWN0b3JhdGUn cyBvbmdvaW5nIGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nl c3NlZCBieSB0aGUgSUVTRy4gVGhlc2UgY29tbWVudHMgd2VyZSB3cml0dGVuIHByaW1hcmlseQ0K IGZvciB0aGUgYmVuZWZpdCBvZiB0aGUgc2VjdXJpdHkgYXJlYSBkaXJlY3RvcnMuJm5ic3A7IERv Y3VtZW50IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBzaG91bGQgdHJlYXQgdGhlc2UgY29tbWVudHMg anVzdCBsaWtlIGFueSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMuPG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhpcyBkb2N1bWVudCBkZXNjcmliZXMg JnF1b3Q7YSBtb2RpZmljYXRpb24gdG8gdGhlIHZhbGlkYXRpb24gcHJvY2VkdXJlIGRlZmluZWQg Zm9yIHRoZSBkaXNzZW1pbmF0aW9uDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+b2YgQkdQIEZsb3cgU3BlY2lmaWNhdGlvbnMuJnF1b3Q7IE1v cmUgc3BlY2lmaWNhbGx5LiB0aGUgbWVtbyBkZXNjcmliZXMgYSBtZWNoYW5pc20gd2hpY2ggcmVs YXhlcyZuYnNwOyB0aGUgZXhpc3RpbmcgdmFsaWRhdGlvbiBydWxlIHRoYXQgcmVxdWlyZXMgRmxv dyBTcGVjaWZpY2F0aW9ucyB0byBiZSBvcmlnaW5hdGluZyBmcm9tDQogdGhlIG9yaWdpbmF0b3Ig b2YgdGhlIGJlc3QtbWF0Y2ggdW5pY2FzdCByb3V0ZSwgYW5kIG5vdyBhbGxvd3Mgc3VjaCBzcGVj aWZpY2F0aW9ucyB0byBiZSBvcmlnaW5hdGVkIHdpdGhpbiB0aGUgc2FtZSBBUyBhcyB0aGUgdmFs aWRhdG9yLiBBcyBhIHJlc3VsdC4gdGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIHNlY3Rpb24g ZG9lcyBjYWxsIG91dDogJnF1b3Q7VGhlIG9yaWdpbmFsIEFTX1BBVEggdmFsaWRhdGlvbiBydWxl ICg8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNDI3MSNzZWN0aW9uLTYu MyIgdGFyZ2V0PSJfYmxhbmsiPltSRkM0MjcxXQ0KIHNlY3Rpb24mbmJzcDs2LjM8L2E+KSBiZWNv bWVzJm5ic3A7IGhlcmVieSBvcHRpb25hbCAoPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtaWRyLWJncC1mbG93c3BlYy1vaWQtMTMjc2VjdGlvbi00LjIiIHRh cmdldD0iX2JsYW5rIj5zZWN0aW9uIDQuMjwvYT4pLiBJZiB0aGF0IG9yaWdpbmFsIHJ1bGUgaXMg YWN0dWFsbHkgbm90IGVuZm9yY2VkIGl0IG1heSBpbnRyb2R1Y2Ugc29tZSBzZWN1cml0eSByaXNr cy4gQSBwZWVyIChvcg0KIGEgY2xpZW50IG9mIGEgcm91dGUgc2VydmVyIHBlZXIpIGluIEFTIFgg Y291bGQgYWR2ZXJ0aXNlIGEgcm9ndWUgRmxvdyBTcGVjaWZpY2F0aW9uIHJvdXRlLi4uLiZxdW90 OyBhbmQgJnF1b3Q7SWYgdFt0aGUgb3JpZ2luYXRvciBvZiBhIHJ1bGVdIGlzIGtub3duIGZvciBh IGZhY3Qgbm90IHRvIGJlIGEgcm91dGUgc2VydmVyLCB0aGF0IG9wdGlvbmFsIHJ1bGUgU0hPVUxE IGJlIGVuZm9yY2VkIGZvciBGbG93IFNwZWNpZmljYXRpb24gcm91dGVzLiZxdW90OzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SXQgaXMg bm90IGNsZWFyIHRvIG1lIGhvdyBhIHZhbGlkYXRvciB3b3VsZCBub3cgJnF1b3Q7Zm9yIGEgZmFj dCZxdW90OyB0aGF0IGEgcGVlciBpc24ndCBhIHJvdXRlIHNlcnZlciwgYW5kIHRodXMgdGhhdCBp dCB3b3VsZCBoYXZlIHRvIGVuZm9yY2UgdGhlIG5vdy1vcHRpb25hbCBwYXRoIHZhbGlkYXRpb24g cnVsZS4gSXQgc2VlbXMNCiBzb21lIGNsYXJpdHkgb24gdGhpcyB3b3VsZCBiZSBnb29kIHN1Y2gg dGhhdCBpbXBsZW1lbnRhdGlvbnMgaGF2ZSBsZXNzIG9mIGEgcmlzayBvZiBhY2NlcHRpbmcgZmxv dyBzcGVjaWZpY2F0aW9ucyBmcm9tIHVuYXV0aG9yaXplZCBwYXJ0aWVzLCBldmVuIGlmIHRoZXkg YXJlIG9uIHRoZSBzYW1lIEFTLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+W0pVQU5dOiBUaGlzIHBhcmFncmFwaCB3YXMgbm90IGludGVuZGVkIHRvIHByZXNzdXJl IHRoZSBvcGVyYXRvciB0byBrbm93IGlmIHRoZSBwZWVyIHdhcyBhIHJvdXRlIHNlcnZlciwgaXQg d2FzIGp1c3QgYSDigJhpZuKAmS4gTm90ZSBpdOKAmXMgdGhlIHNhbWUgY2FzZSBmb3IgUkZDNDI3 MSA6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+SWYg dGhlIFVQREFURSBtZXNzYWdlIGlzIHJlY2VpdmVkIGZyb20gYW4gZXh0ZXJuYWwgcGVlciwgdGhl IGxvY2FsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IHN5c3RlbSBNQVkgY2hlY2sgd2hldGhlciB0 aGUgbGVmdG1vc3QgKHdpdGggcmVzcGVjdCB0byB0aGUgcG9zaXRpb248L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJz cDsmbmJzcDsgb2Ygb2N0ZXRzIGluIHRoZSBwcm90b2NvbCBtZXNzYWdlKSBBUyBpbiB0aGUgQVNf UEFUSCBhdHRyaWJ1dGUgaXM8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgZXF1YWwgdG8gdGhlIGF1 dG9ub21vdXMgc3lzdGVtIG51bWJlciBvZiB0aGUgcGVlciB0aGF0IHNlbnQgdGhlPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFj ayI+Jm5ic3A7Jm5ic3A7IG1lc3NhZ2UuDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Tm90ZSB0 aGF0IHRoZSBzYW1lIGNoYWxsZW5nZSBvZiBpZGVudGlmeWluZyByb3V0ZSBzZXJ2ZXJzIGFwcGxp ZXMgZm9yIG90aGVyIGFkZHJlc3MtZmFtaWxpZXMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPk5vdGUgYWxzbyB0aGF0IHRoZSByb3V0ZS1zZXJ2ZXIgaXRzZWxmIG1heSBl bmZvcmNlIHRoZSBydWxlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+V2hhdCBhYm91dCBm b3IgY2xhcml0eTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJs YWNrIj4mbmJzcDsmbmJzcDsgVGhlIG9yaWdpbmFsIEFTX1BBVEggdmFsaWRhdGlvbiBydWxlIChb UkZDNDI3MV0gc2VjdGlvbiA2LjMpIHJlbWFpbnMgaGVyZWJ5IHN0aWxsIG9wdGlvbmFsPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpi bGFjayI+Jm5ic3A7Jm5ic3A7IChzZWN0aW9uIDQuMikgZm9yIEZsb3cgU3BlY2lmaWNhdGlvbiBB ZGRyZXNzIEZhbWlseSAoY2hhbmdlcyBpbnRyb2R1Y2VkIGluIFtSRkM1NTc1XSBhcmUgY2FuY2Vs bGVkKS4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwO0lmIHRoYXQgb3JpZ2luYWwgcnVs ZSBpcyBub3QgZW5mb3JjZWQgZm9yIEZsb3cgU3BlY2lmaWNhdGlvbiBpdCBtYXkgaW50cm9kdWNl IHNvbWUgbmV3IHNlY3VyaXR5IHJpc2tzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBBIHBlZXIg KG9yIGEgY2xpZW50IG9mIGEgcm91dGUgc2VydmVyIHBlZXIpIGluIEFTIFggY291bGQgYWR2ZXJ0 aXNlIGEgcm9ndWUgRmxvdzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBTcGVjaWZpY2F0aW9uIHJv dXRlIHdob3NlIGZpcnN0IEFTIGluIEFTX1BBVEggd2FzIFkgKGFzc3VtZSBZIGlzIHRoZTwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 YmxhY2siPiZuYnNwOyZuYnNwOyBmaXJzdCBBUyBpbiB0aGUgQVNfUEFUSCBvZiB0aGUgYmVzdC1t YXRjaCB1bmljYXN0IHJvdXRlKS4mbmJzcDsgVGhpcyByaXNrPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5i c3A7IGlzIGltcG9zc2libGUgdG8gcHJldmVudCBpZiB0aGUgRmxvdyBTcGVjaWZpY2F0aW9uIHJv dXRlIGlzIHJlY2VpdmVkPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGZyb20gYSByb3V0ZSBzZXJ2 ZXIgcGVlci4mbmJzcDsgSWYgdGhhdCBwZWVyIGlzIGtub3duIGZvciBhIGZhY3Qgbm90IHRvIGJl PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGEgcm91dGUgc2VydmVyLCB0aGF0IG9wdGlvbmFsIHJ1 bGUgU0hPVUxEIGJlIGVuZm9yY2VkIGZvciBGbG93PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IFNw ZWNpZmljYXRpb24gcm91dGVzLiBOb3RlIHRoYXQgaWRlbnRpZnlpbmcgdGhvc2UgcGVlcnMgdGhh dCBhcmUgcm91dGUgc2VydmVycyBtYXkgc3VwcG9zZSBhbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNw OyBvcGVyYXRpb25hbCBjaGFsbGVuZ2UuIElmIHRoZSBjb25kaXRpb24gb2YgdGhlIHBlZXIgaXMg dW5rbm93biwgdGhlIHJ1bGUgU0hPVUxEIG5vdCBiZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBl bmZvcmNlZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgQSByb3V0 ZSBzZXJ2ZXIgaXRzZWxmIG1heSBiZSBpbiBhIGdvb2QgcG9zaXRpb24gdG8gZW5mb3JjZSB0aGUg QVNfUEFUSCB2YWxpZGF0aW9uIHJ1bGUgZGVzY3JpYmVkPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7 aW4gdGhlIHByZXZpb3VzIHBhcmFncmFwaC4gSWYgYSByb3V0ZSBzZXJ2ZXIga25vd25zIGl04oCZ cyBub3QgcGVlcmluZyB3aXRoIGFueSBvdGhlciByb3V0ZSBzZXJ2ZXIsPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5i c3A7Jm5ic3A7IGl0IGNhbiBlbmZvcmNlIHRoZSBBU19QQVRIIHZhbGlkYXRpb24gcnVsZSBhY3Jv c3MgYWxsIGl0cyBwZWVycy4gSWYsIGluIGFkZGl0aW9uIHRvIHRoYXQsPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5i c3A7Jm5ic3A7IHRoZSByb3V0ZSBzZXJ2ZXIgaXMgdHJ1c3RlZCwgdGhlIHNlY3VyaXR5IHRocmVh dCBkZXNjcmliZWQgYWJvdmUgZGlzYXBwZWFycy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2si PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QW55 Ym9keSBmZWVsIGZyZWUgdG8gcmV3b3JkIHRoZSB0d28gcGFyYWdyYXBocyBhYm92ZSBpZiBpdCBo ZWxwcyB0aGVtIGZvciBjbGFyaXR5LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5FZGl0b3JpYWw6PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO21zby1saXN0OmwxIGxldmVsMSBsZm8xIj4NCiZxdW90O0xldCdzIGNvbnNp ZGVyIHRoZSBwYXJ0aWN1bGFyIGNhc2Ugd2hlcmUgdGhlIEZsb3cgU3BlY2lmaWNhdGlvbiBpcyBv cmlnaW5hdGVkIGluIGFueSBsb2NhdGlvbiB3aXRoaW4gdGhlIHNhbWUgYXV0b25vbW91cyBzeXN0 ZW0gdGhhbiB0aGUgc3BlYWtlciBwZXJmb3JtaW5nIHRoZSB2YWxpZGF0aW9uIChmb3IgZXhhbXBs ZSBieSBhIGNlbnRyYWxpemVkIEJHUCByb3V0ZSBjb250cm9sbGVyKSwgYW5kIHRoZSBiZXN0LW1h dGNoIHVuaWNhc3Qgcm91dGUNCiBpcyBvcmlnaW5hdGVkIGluIGFub3RoZXIgYXV0b25vbW91cyBz eXN0ZW0uJnF1b3Q7IC0gc2hvdWxkIHRoZSB3b3JkICZxdW90O3RoYW4mcXVvdDsgYmUgcmVwbGFj ZWQgd2l0aCAmcXVvdDt0aGF0JnF1b3Q7IGhlcmU/PG86cD48L286cD48L2xpPjwvdWw+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPltKVUFOXTogVGhhbmtzIGZvciBwb2ludGluZyB0aGF0IG91dC4g QSBmZXcgZ29vZ2xpbmcgdGVsbHMgbWUgdGhlIGV2ZW4gYmV0dGVyIGdyYW1tYXRpY2FsIGNob2lj ZSB3b3VsZCBiZSDigJhzYW1lIGFz4oCZIGluIHRoaXMgY2FzZS4gSeKAmWxsIGJlIHVzaW5nIOKA mHNhbWUgYXPigJkgdW5sZXNzJm5ic3A7IHlvdSBkaXNhZ3JlZS48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8dWwgdHlwZT0iZGlz YyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8yIj4NCklu IHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uLCAmcXVvdDtiZWNvbWVzIGhlcmVi eSBvcHRpb25hbCZxdW90OyBjb3VsZCBwcm9iYWJseSBiZSBzaW1wbGlmaWVkIHRvICZxdW90O2Jl Y29tZXMgb3B0aW9uYWwmcXVvdDsgb3Igc2ltaWxhciwgYW5kICZxdW90O2FjdHVhbGx5JnF1b3Q7 IGNvdWxkIGJlIHJlbW92ZWQuPG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPltKVUFOXTombmJzcDsgSG1tbSwgSSB0aG91Z2h0IHRoYXQgaXQgd2FzIGltcG9ydGFu dCB0byBlbXBoYXNpemUgaXQgYmVjb21lcyBvcHRpb25hbCBiZWNhdXNlIG9mICo8Yj50aGlzPC9i PiogZHJhZnQgcmVkZWZpbml0aW9uIG9mIHJ1bGVzLiBEb27igJl0IHlvdSB0aGluayBpdOKAmXMg aW1wb3J0YW50PyAod2hhdGV2ZXIgd29yZGluZw0KIHlvdSB3YW50IHRvIHVzZSkuIFJlZ2FyZGxl c3MsIHJlZmVyIHRvIG15IG5ldyByZXdvcmRlZCAyIHBhcmFncmFwaHMgYWJvdmUgZm9yIHRoYXQg c2VjdGlvbiAuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5UaGFua3MsDQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4tLSBNYWdudXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiciBjbGVhcj0iYWxs Ij4NCjxicj4NCi0tIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pi0tIE1hZ251czxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_DM6PR11MB3194CDD275DFB08A7CF91DBCCD5A9DM6PR11MB3194namp_-- From nobody Mon May 3 17:48:54 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 665593A1B9C; Mon, 3 May 2021 17:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 uMQR_MK8A2sb; Mon, 3 May 2021 17:48:48 -0700 (PDT) Received: from mail-il1-x12f.google.com (mail-il1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (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 65CE03A1B9A; Mon, 3 May 2021 17:48:48 -0700 (PDT) Received: by mail-il1-x12f.google.com with SMTP id r5so5062726ilb.2; Mon, 03 May 2021 17:48:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pT/h6J6vRe8muODiS6WbL47lo/kcdJCuKttVtEAhI78=; b=fsB4vowb57WuauWjWs9zWmzlYWmGgKwriSfvsocHXlR35L4jOctYisr+lTYTwQEcp9 IZHsk2ZFF+idqdDSEqcDSGPuvWJC3STD6roOS9bbdzo4Xf5hObDLXIOUZeFEdQbShwKV TOXyggsWk9hSjNxrOtQl5d45KuuU5hCg7BAuGsk7XMnFCeHwJn8HdfoVyOQllZjFxOT0 NmVe4vNky4kjx1BHiandFRjiwyXWtubWdKE5glYfq4Mm8AZsfMntzEo06yc22dX4Pxqm sqnFhCbotebaFlnSYaMjigsJ586f9RdHhUx2G4Nm+CPdjMoluQXKLs7b+KrE+EywMSgI 0aYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pT/h6J6vRe8muODiS6WbL47lo/kcdJCuKttVtEAhI78=; b=h6DkBz3qxIWH9gecqI6/2i1LiVi9/xU1SCart3g7WNc+7jn0PhJ5DSfEIbktWW9xoC q19fMzV9qCzR5nKWqTNU8cy710GDJPnFSTXY9iJ75wFhZZLhxoh3Sx9nkE3U+pzlAfyW MNwJfn/IdYggldWJILse77w05KaD6qo7TpcTa0GFAili2q4CFqjjCII+6Mh6u4RBmrxp rzfwGNSEcpQ2vmXknZg2ZBZc8POcwtHhlD+xltU5gYldIPQwo+9F9FpLgbLONi9ZP/SR o4fuBKJh6+qOYRpuqL1aKsWpEVZsayuvq5HTzh0HKCs6ZyBIhpiPk/Q1TM6BMQ8+nKP3 v6RA== X-Gm-Message-State: AOAM531NCZuDANNu/IV32lb6A4HIg8HiOWDWBId8g0nCs3x27fK2Hkz+ dRcbQo0QDfd4M2VnhO1nFo+BWh5emoxMUJJKZFv8T2mg X-Google-Smtp-Source: ABdhPJwOOKr1/ot58bBkUygm/kvlPVY0XAp/7zhPov7Nq+rmvMXVxFFsc/A7VIZSnp80HmJUJXZU3dCVtNO/WK2wuPI= X-Received: by 2002:a92:c6ca:: with SMTP id v10mr18586516ilm.97.1620089327013; Mon, 03 May 2021 17:48:47 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?Magnus_Nystr=C3=B6m?= Date: Mon, 3 May 2021 17:48:35 -0700 Message-ID: To: "Juan Alcaide (jalcaide)" Cc: "secdir@ietf.org" , "draft-ietf-idr-bgp-flowspec-oid@ietf.org" Content-Type: multipart/alternative; boundary="000000000000d753c005c1767015" Archived-At: Subject: Re: [secdir] Secdir review of draft-ietf-idr-bgp-flowspec-oid-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2021 00:48:54 -0000 --000000000000d753c005c1767015 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Juan, yes, to me this is at least clearer about the risk. At this point I leave it to the Security Area directors if they'd like to see any other modifications. Thanks! Magnus On Mon, May 3, 2021 at 5:17 PM Juan Alcaide (jalcaide) wrote: > Magnus, > > > > Yes, they=E2=80=99ll be opening to risk. It=E2=80=99s the risk described = in the draft. But > this risk is necessary for route-servers to work with flowspec. And as > mentioned, perhaps route servers can be configured to avoid that risk. > > > > > > I wanted to use the term =E2=80=98remain=E2=80=99 instead of =E2=80=98bec= ome=E2=80=99.. We went from > RFC4271 (rule optional) -> RFC8955 (rule mandatory) -> this draft (rule > again optional) > > Would the below make sense (I changed the first sentence): > > > > This document makes the original AS_PATH validation rule ([RFC4271] > section 6.3) again optional > > (section 4.2) for Flow Specification Address Family (the rule is no > longer mandatory as it was specified by [RFC8955]). > > If that original rule is not enforced for Flow Specification it may > introduce some new security risks. > > A peer (or a client of a route server peer) in AS X could advertise a > rogue Flow > > Specification route whose first AS in AS_PATH was Y (assume Y is the > > first AS in the AS_PATH of the best-match unicast route). This risk > > is impossible to prevent if the Flow Specification route is received > > from a route server peer. If that peer is known for a fact not to be > > a route server, that optional rule SHOULD be enforced for Flow > > Specification routes. Note that identifying those peers that are route > servers may suppose an > > operational challenge. If the condition of the peer is unknown, the > rule SHOULD not be > > enforced. > > > > A route server itself may be in a good position to enforce the AS_PATH > validation rule described > > in the previous paragraph. If a route server knowns it=E2=80=99s not pe= ering > with any other route server, > > it can enforce the AS_PATH validation rule across all its peers. If, i= n > addition to that, > > the route server is trusted, the security threat described above > disappears. > > > > > > > > > > *From:* Magnus Nystr=C3=B6m > *Sent:* Monday, May 3, 2021 9:39 PM > *To:* Juan Alcaide (jalcaide) > *Cc:* secdir@ietf.org; draft-ietf-idr-bgp-flowspec-oid@ietf.org > *Subject:* Re: Secdir review of draft-ietf-idr-bgp-flowspec-oid-13 > > > > Thanks Juan. > > For the editorial ones, agree on the first one and I think the second you > could change to "with this memo, becomes optional." or similar. > > For the new text, perhaps I am misunderstanding something, but this > sentence: > > Note that identifying those peers that are route servers may suppose an > operational challenge. If the condition of the peer is unknown, the rule > SHOULD not be enforced. > > Is it correctly understood, that you're saying that if a validator is > unable to determine if the peer is a route server, they should not enforc= e > the rule? If so, doesn't that mean "failing open, i.e., opening themselve= s > to risk? Sorry if I misunderstand. > > > > > > On Mon, May 3, 2021 at 3:36 AM Juan Alcaide (jalcaide) > wrote: > > Thanks for your comments, Magnus > > > > Inline.. > > > > *From:* Magnus Nystr=C3=B6m > *Sent:* Monday, May 3, 2021 6:44 AM > *To:* secdir@ietf.org; draft-ietf-idr-bgp-flowspec-oid@ietf.org > *Subject:* Secdir review of draft-ietf-idr-bgp-flowspec-oid-13 > > > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the IESG. > These comments were written primarily for the benefit of the security are= a > directors. Document editors and WG chairs should treat these comments ju= st > like any other last call comments. > > > > This document describes "a modification to the validation procedure > defined for the dissemination > > of BGP Flow Specifications." More specifically. the memo describes a > mechanism which relaxes the existing validation rule that requires Flow > Specifications to be originating from the originator of the best-match > unicast route, and now allows such specifications to be originated within > the same AS as the validator. As a result. the Security Considerations > section does call out: "The original AS_PATH validation rule ([RFC4271] > section 6.3 ) becomes > hereby optional (section 4.2 > ). > If that original rule is actually not enforced it may introduce some > security risks. A peer (or a client of a route server peer) in AS X could > advertise a rogue Flow Specification route...." and "If t[the originator = of > a rule] is known for a fact not to be a route server, that optional rule > SHOULD be enforced for Flow Specification routes." > > > > It is not clear to me how a validator would now "for a fact" that a peer > isn't a route server, and thus that it would have to enforce the > now-optional path validation rule. It seems some clarity on this would be > good such that implementations have less of a risk of accepting flow > specifications from unauthorized parties, even if they are on the same AS= . > > > > [JUAN]: This paragraph was not intended to pressure the operator to know > if the peer was a route server, it was just a =E2=80=98if=E2=80=99. Note = it=E2=80=99s the same case > for RFC4271 : > > > > If the UPDATE message is received from an external peer, the local > > system MAY check whether the leftmost (with respect to the position > > of octets in the protocol message) AS in the AS_PATH attribute is > > equal to the autonomous system number of the peer that sent the > > message. > > > > > > Note that the same challenge of identifying route servers applies for > other address-families. > > Note also that the route-server itself may enforce the rule. > > > > What about for clarity: > > > > The original AS_PATH validation rule ([RFC4271] section 6.3) remains > hereby still optional > > (section 4.2) for Flow Specification Address Family (changes introduce= d > in [RFC5575] are cancelled). > > If that original rule is not enforced for Flow Specification it may > introduce some new security risks. > > A peer (or a client of a route server peer) in AS X could advertise a > rogue Flow > > Specification route whose first AS in AS_PATH was Y (assume Y is the > > first AS in the AS_PATH of the best-match unicast route). This risk > > is impossible to prevent if the Flow Specification route is received > > from a route server peer. If that peer is known for a fact not to be > > a route server, that optional rule SHOULD be enforced for Flow > > Specification routes. Note that identifying those peers that are route > servers may suppose an > > operational challenge. If the condition of the peer is unknown, the > rule SHOULD not be > > enforced. > > > > A route server itself may be in a good position to enforce the AS_PATH > validation rule described > > in the previous paragraph. If a route server knowns it=E2=80=99s not pe= ering > with any other route server, > > it can enforce the AS_PATH validation rule across all its peers. If, i= n > addition to that, > > the route server is trusted, the security threat described above > disappears. > > > > > > > > Anybody feel free to reword the two paragraphs above if it helps them for > clarity. > > > > > > > > Editorial: > > - "Let's consider the particular case where the Flow Specification is > originated in any location within the same autonomous system than the > speaker performing the validation (for example by a centralized BGP ro= ute > controller), and the best-match unicast route is originated in another > autonomous system." - should the word "than" be replaced with "that" h= ere? > > [JUAN]: Thanks for pointing that out. A few googling tells me the even > better grammatical choice would be =E2=80=98same as=E2=80=99 in this case= . I=E2=80=99ll be using > =E2=80=98same as=E2=80=99 unless you disagree. > > > > - In the security considerations section, "becomes hereby optional" > could probably be simplified to "becomes optional" or similar, and > "actually" could be removed. > > [JUAN]: Hmmm, I thought that it was important to emphasize it becomes > optional because of **this** draft redefinition of rules. Don=E2=80=99t y= ou think > it=E2=80=99s important? (whatever wording you want to use). Regardless, r= efer to my > new reworded 2 paragraphs above for that section . > > > > > > > > Thanks, > > -- Magnus > > > > > > -- > > -- Magnus > --=20 -- Magnus --000000000000d753c005c1767015 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable --000000000000d753c005c1767015-- From nobody Tue May 4 01:15:28 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 896453A2AAC; Tue, 4 May 2021 01:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.599 X-Spam-Level: X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_NONE=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 JQy8640xO53C; Tue, 4 May 2021 01:15:16 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47D403A2AAA; Tue, 4 May 2021 01:15:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=869; q=dns/txt; s=iport; t=1620116109; x=1621325709; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=C5/9xwL/24ogBeZLPamKEKJWy+1OQ0MbMaTviUN8jVs=; b=El5LCvUMYRCZ+HE5VzptJ+LLEZFWT64T1HeEq8798yx0qmuC/VwfmOrx y6Pgkfgb/hyZD/DPiVJ6aOOglRP++/O5CjtmCInkAPiPw/lYFMQep2qUy eYxdZrMn+iyiUxNhp7ytsx1aG8Yp9E7JrzaFFL4QjAzU00JHqUYwYazTN Y=; X-IPAS-Result: =?us-ascii?q?A0BcAQBkAZFglxbLJq1aHAEBAQEBAQcBARIBAQQEAQFAg?= =?us-ascii?q?VeDeAEnEoR1iQSIQy0DnHwLAQEBDzQEAQGEUAKBfCY4EwIEAQEBAwIDAQEBA?= =?us-ascii?q?QEFAQEBAgEGBBQBAQEBAQEBAWiFXYZFAQUjFUEQCxIGAgImAgJJDgYBDAgBA?= =?us-ascii?q?YJtgwioNHqBMoEBhGGDUIFEgRAqiWiDeEOBSUKBFCiCez6HWYJhBIFVgVUBA?= =?us-ascii?q?1eBXwUqGZEhjSKdGYMag0WZXAUIBSKUUZBSlTCfBYUFgWshgVszGggbFYMlT?= =?us-ascii?q?xkOjjiONj8DZwIGCgEBAwmNDwEB?= IronPort-HdrOrdr: A9a23:Both2KoGqSOPlL2PuMsWDPIaV5tiL9V00zAX/kB9WHVpW+aT/v rDoN0w0xjohDENHFQpnt6dMKeNKEmskqJdy48XILukQU3ao2OuNo5v9s/PxDfnFi34+IdmpM FdWoJ5D8D9CkU/sNbi7GCDYrId6fSO7azAv4fj5lh3SwUCUc9dxid/Tj2WC0hnADRBbKBJca a0wupii36edW8MbsK9b0N1PdTrg9HQjprpbVonKncciTWmtj+j5L7kHxXw5H53OA9n+rss/X PIlAb0/MyY3M2T8APW1GPY8v1t8ufJ990rPqGxo/QOJi6pogilY5kJYczggBkF5Mey9V0tjN 7A5zAnMsgb0QKoQkiF5T3wxgLnzDEir0XH9Gbdq37ircvlLQhKcvZ8uQ== X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.82,271,1613433600"; d="scan'208";a="35644042" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 04 May 2021 08:15:04 +0000 Received: from [10.60.140.52] (ams-ppsenak-nitro3.cisco.com [10.60.140.52]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTP id 1448F4uM028473; Tue, 4 May 2021 08:15:04 GMT To: Yaron Sheffer , secdir@ietf.org Cc: draft-ietf-lsr-isis-srv6-extensions.all@ietf.org, last-call@ietf.org, lsr@ietf.org References: <162004657373.13851.8347166444632264802@ietfa.amsl.com> From: Peter Psenak Message-ID: Date: Tue, 4 May 2021 10:15:04 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <162004657373.13851.8347166444632264802@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Outbound-SMTP-Client: 10.60.140.52, ams-ppsenak-nitro3.cisco.com X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-lsr-isis-srv6-extensions-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2021 08:15:21 -0000 Hi Yaron, thanks for your comments I'll address them in the next version of the document. thanks, Peter On 03/05/2021 14:56, Yaron Sheffer via Datatracker wrote: > Reviewer: Yaron Sheffer > Review result: Ready > > This document specifies extensions (TLVs, sub-TLVs etc.) to IS-IS in support of > Segment Routing on IPv6. > > The document states that the security considerations are a union of security > considerations from a bunch of predecessor document. This seems reasonable to > me. > > Details: > > * The first sentence of the Abstract is missing a word, perhaps "architecture". > > * Introduction: typo: "This documents". > > * Capabilities: to allow for future extensibility, you should probably add > "Implementations receiving this TLV MUST ignore any other bits that may be set > in the Flags field". > > > > From nobody Tue May 4 06:37:06 2021 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C2313A0AEB; Tue, 4 May 2021 06:36:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Stefan Santesson via Datatracker To: Cc: draft-ietf-netmod-geo-location.all@ietf.org, last-call@ietf.org, netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.28.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162013541639.17486.6337995181999610136@ietfa.amsl.com> Reply-To: Stefan Santesson Date: Tue, 04 May 2021 06:36:56 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-netmod-geo-location-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2021 13:36:57 -0000 Reviewer: Stefan Santesson Review result: Ready I can't offer expertise view on YANG models or GeoLocation. The document seems however well written and the security considerations section seems reasonable. From nobody Tue May 4 15:12:02 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52FB03A1738; Tue, 4 May 2021 15:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=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 84bHXN3ooEwo; Tue, 4 May 2021 15:11:39 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 CE85F3A1739; Tue, 4 May 2021 15:11:33 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1le3GN-0007PA-Mh; Tue, 04 May 2021 22:11:31 +0000 Date: Tue, 04 May 2021 15:11:30 -0700 Message-ID: From: Randy Bush To: Kyle Rose Cc: Kyle Rose via Datatracker , last-call@ietf.org, opsawg@ietf.org, draft-ietf-opsawg-finding-geofeeds.all@ietf.org, IETF SecDir In-Reply-To: References: <161969840202.30267.8231145700644479792@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-opsawg-finding-geofeeds-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2021 22:11:44 -0000 kyle, was it you who was wondering about the ops community process and progress getting this draft implemented? as part of the RIPE process, the RIPE/NCC, who has to actually implement this stuff, issues an impact report. i thought it might be informative. randy From: Edward Shryane via db-wg Subject: Re: [db-wg] New NWI for geofeed? To: denis walker Cc: Database WG Date: Tue, 4 May 2021 22:35:56 +0200 Hello Denis, Colleagues, Following is the impact analysis for the implementation of the "geofeed:" attribute in the RIPE database, based on the problem statement below and the draft RFC: https://tools.ietf.org/html/draft-ymbk-opsawg-finding-geofeeds I will ask our Legal team to conduct a full impact analysis of the implementation plan. Please reply with corrections or suggestions. Regards Ed Shryane RIPE NCC Impact Analysis for Implementing the "geofeed:" Attribute ============================================================ "geoloc:" Attribute ---------------------- Implementing the "geofeed:" attribute does not affect the "geoloc:" attribute. No decision has been taken on the future of the "geoloc:" attribute, a review can be done at a later date. "remarks:" Attribute ----------------------- Existing "remarks:" attributes in INETNUM or INET6NUM object types containing a "geofeed: url" value will not be automatically converted to a "geofeed:" attribute. The implementation will validate that an INETNUM or INET6NUM object may contain at most a single geofeed reference, either a "remarks:" attribute *or* a "geofeed:" attribute. More than one will result in an error on update. Any "remarks:" attributes in other object types will not be validated for geofeed references. "geofeed:" Attribute ----------------------- The "geofeed:" attribute will be added to the INETNUM and INET6NUM object types. It will be an optional, singly occurring attribute. The attribute value must consist only of a well-formed URL. Any other content in the attribute value will result in a syntax error. "geofeed:" URL ----------------- The URL in the "geofeed:" attribute will be validated that it is well-formed (i.e. syntactically correct). The URL must use the ASCII character set only (in the RIPE database, non-Latin-1 characters will be substituted with a '?' character). Non-ASCII characters in the URL host name must be converted to ASCII using Punycode in advance (before updating the RIPE database). Non-ASCII characters in the URL path must be converted using Percent-encoding in advance. Only the HTTPS protocol is supported in the URL, otherwise an error is returned. The reachability of the URL will not be checked. The content of the URL will not be validated. Database dump and Split files ---------------------------------- The "geofeed:" attribute will be included in the nightly database dump and split files. NRTM -------- The "geofeed:" attribute will be included in INETNUM and INET6NUM objects in the NRTM stream. Whois Queries ----------------- The "geofeed:" attribute will appear by default in (filtered) INETNUM and INET6NUM objects in Whois query responses, no additional query flag will be needed. RDAP ------------- The "geofeed:" attribute will not appear in RDAP responses. A separate RDAP profile will be needed to extend the response format to include geofeed. This can be implemented at a later date. Documentation --------------- The RIPE database documentation will be updated, including the inet(6)num object templates and attribute description (with a reference to the IETF draft document). Other RIRs ------------- There is currently no coordinated plan to implement "geofeed:" across regions. Other RIRs may implement "geofeed:" at a later date. Legal Review --------------- An initial review by the RIPE NCC Legal team found that geofeed data may qualify as personal data, and before introducing the "geofeed:" attribute a full impact analysis of its implementation would have to be conducted by the RIPE NCC. ----- > On 12 Apr 2021, at 17:59, denis walker via db-wg wrote: > > Colleagues > > ** corrected version getting the attribute names right ** > > The chairs agree that there is a consensus to set up an NWI to create > the "geofeed:" attribute in the RIPE Database. We therefore ask the > RIPE NCC to set up "NWI-13 Create a "geofeed:" attribute in the RIPE > Database" Using the 'Problem statement' below. After the RIPE NCC > completes it's impact analysis we can finalise the 'Solution > definition'. The RIPE NCC can address any of the questions raised in > this discussion that they feel are relevant to the basic creation of > this attribute. > > cheers > denis > co-chair DB-WG > > > Problem statement > > Associating an approximate physical location with an IP address has > proven to be a challenge to solve within the current constraints of > the RIPE Database. Over the years the community has chosen to consider > addresses in the RIPE Database to relate to entities in the assignment > process itself, not the subsequent actual use of IP addresses after > assignment. > > The working group is asked to consider whether the RIPE Database can > be used as a springboard for parties wishing to correlate geographical > information with IP addresses by allowing structured references in the > RIPE Database towards information outside the RIPE Database which > potentially helps answer Geo IP Location queries > > The IETF is currently discussing an update to RPSL to add a new > attribute "geofeed: url". The url will reference a csv file containing > location data. Some users have already started to make use of this > feature via the "remarks: geofeed: url". It is never a good idea to > try to overload structured data into the free format "remarks:" > attribute. This has been done in the past, for example with abuse > contact details before we introduced the "abuse-c:" attribute. There > is no way to regulate what database users put into "remarks:" > attributes. So even if the new "geofeed:" attribute is not agreed, the > url data will still be included in the RIPE Database. > > Currently there are 24,408 INETNUM and 516,354 INET6NUM objects > containing a "geoloc" attribute in the database. These have 7,731 > distinct values in the INETNUMs and 1,045 distinct values in the > INET6NUMs. There are about 150 objects in the RIPE Database with a > "remarks: geoloc url" attribute. > From nobody Wed May 5 04:58:49 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 052363A12FD for ; Wed, 5 May 2021 04:58:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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=krose.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KLWudYnwpMNT for ; Wed, 5 May 2021 04:58:41 -0700 (PDT) Received: from mail-yb1-xb2f.google.com (mail-yb1-xb2f.google.com [IPv6:2607:f8b0:4864:20::b2f]) (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 C9D483A12F7 for ; Wed, 5 May 2021 04:58:41 -0700 (PDT) Received: by mail-yb1-xb2f.google.com with SMTP id m9so2295471ybm.3 for ; Wed, 05 May 2021 04:58:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XUZYMTvTtLyRiP4az3qB8O9VFmgEnP3KF4qwJYe3RuU=; b=YR3jZjTl6XvltOJk19c1DJPthQs4JKi2KcLQyt47FlYiesygldwFhLcNzT55lth1Du oFwjbqQsNG71pvbrqcsaiSJfVZdPf0+/IFRpDQEeu4OvnY1UMtdyokRhvCfzb70Q7H+d U1Y0WhfvGW0jM5GlU8UwPEGbkUJ+ZmtwUqHFY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XUZYMTvTtLyRiP4az3qB8O9VFmgEnP3KF4qwJYe3RuU=; b=H5u1IJFfE/6YJeKA48QtmPmgNklfBM/sQqG0RSSaizsgPh1SBtJWKCADvjo+geZbCp WcXXkUcB4nbCESQaQcQIMv2UiwGljazQlBHgLALkgZVo5Q30S5WshYQkfMl0uuC7Hw4p 0TKqJymSLhHvLd4Iv02VNDqjWCqMrQUnbOBb+xsBQhJTe30ooT2WwUAOfOyxITYxt1b6 7aT9jp9IiM5ltYeiuuFKG7Vz6M7tyZpU3hLLwieyohkTGBXPLurg2xbSkn4QbqRiHaid cFHg021HUfU6M+p3uXIUx2Yvc45fZHSj6ZvyS7X6zjWttNEIoMU1TG3Om+bFz1ijoGrS kt3w== X-Gm-Message-State: AOAM533YX0Cg718wbYTHEsTtrVt1RcZcXLImVgmZLWAKYB9GtzsjcqrQ O5HfKQlttMFdpwTiCuup2AnVIkFhtjb0HWFz4A45IA== X-Google-Smtp-Source: ABdhPJxEjMuTEn4fVoO8ihionW3L3yU0NitEqZR00aa6T0l8p56+IoHS218A9jwXZnUlcrOsfq44Gs76TiWCUaJQNuc= X-Received: by 2002:a25:cacd:: with SMTP id a196mr5146110ybg.296.1620215920014; Wed, 05 May 2021 04:58:40 -0700 (PDT) MIME-Version: 1.0 References: <161969840202.30267.8231145700644479792@ietfa.amsl.com> <809A05C9-8ABD-4D63-970D-D3F8A2277F28@vigilsec.com> In-Reply-To: From: Kyle Rose Date: Wed, 5 May 2021 07:58:29 -0400 Message-ID: To: Russ Housley Cc: Randy Bush , Last Call , Ops Area WG , draft-ietf-opsawg-finding-geofeeds.all@ietf.org, IETF SecDir Content-Type: multipart/alternative; boundary="0000000000005f54af05c193ea1e" Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-opsawg-finding-geofeeds-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2021 11:58:47 -0000 --0000000000005f54af05c193ea1e Content-Type: text/plain; charset="UTF-8" On Mon, May 3, 2021 at 12:05 PM Russ Housley wrote: > Explain how an attacker could get a client to accept a forged geofeed data > file authenticated as I have suggested, because I'm not seeing it. > > > We are not understanding each other. The RPKI signature will prevent the > relying party from accepting a modified file, regardless of the means used > to fetch it. For this reason, there is no need think about the interaction > of the RPKI and the WebPKI. No dependency is being created. > I believe I understand entirely what you're saying. And I do not disagree with your conclusion. In the case of RPKI-signed geofeed data files, using https is unnecessary for integrity because the RPKI trust chain is authoritative for the response body and is sufficient to establish its authenticity. The only reason I can think of to require https for presumed-public geofeed data is if the mere fact of fetching it reveals something about the behavior of individual end users; this is true if CPE were to fetch the data, for instance, rather than the geo-authorization logic at the provider. If so, I think it worthwhile to explain this in the privacy considerations section. Pivoting for a second, are you intending to support the case in which a provider has adopted RPKI but has no intention of signing these files? I.e., the hybrid case I alluded to, in which the routing data feed is protected (along with the geofeed URL) but the geofeeds themselves are not signed? If so, then web PKI integrity (i.e., being able to trust that the data at the https geofeed URL is controlled by the same entity that controls the routing data) is still required to prevent forgery. Kyle --0000000000005f54af05c193ea1e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, May 3, 2021 at 12:05 PM Russ Housley <housley@vigilsec.com> wrote:
Explain how an attacker could get a client to accept a forged geofeed = data file authenticated as I have suggested, because I'm not seeing it.=

We are not understanding each= other.=C2=A0 The RPKI signature will prevent the relying party from accept= ing a modified file, regardless of the means used to fetch it.=C2=A0 For th= is reason, there is no need think about the interaction of the RPKI and the= WebPKI.=C2=A0 No dependency is being created.

I be= lieve I understand entirely what you're saying. And I do not disagree w= ith your conclusion. In the case of RPKI-signed geofeed data files, using h= ttps is unnecessary for integrity because the RPKI trust chain is authorita= tive for the response body and is sufficient to establish its authenticity.= The only reason I can think of to require https for presumed-public geofee= d data is if the mere fact of fetching it reveals something about the behav= ior of individual end users; this is true if CPE were to fetch the data, fo= r instance, rather than the geo-authorization logic at the provider. If so,= I think it worthwhile to explain this in the privacy considerations sectio= n.

Pivo= ting for a second, are you intending to support the case in which a provide= r has adopted RPKI but has no intention of signing these files? I.e., the h= ybrid case I alluded to, in which the routing data feed is protected (along= with the geofeed URL) but the geofeeds themselves are not signed? If so, t= hen web PKI integrity (i.e., being able to trust that the data at the https= geofeed URL is controlled by the same entity that controls the routing dat= a) is still required to prevent forgery.

Kyle

--0000000000005f54af05c193ea1e-- From nobody Wed May 5 07:39:02 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F5673A0F2E; Wed, 5 May 2021 07:38:51 -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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=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 YB6awzER7M_v; Wed, 5 May 2021 07:38:48 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 53AC93A0F0E; Wed, 5 May 2021 07:38:48 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1leIfk-0001Dj-DA; Wed, 05 May 2021 14:38:44 +0000 Date: Wed, 05 May 2021 07:38:43 -0700 Message-ID: From: Randy Bush To: Kyle Rose Cc: Russ Housley , Last Call , Ops Area WG , draft-ietf-opsawg-finding-geofeeds.all@ietf.org, IETF SecDir In-Reply-To: References: <161969840202.30267.8231145700644479792@ietfa.amsl.com> <809A05C9-8ABD-4D63-970D-D3F8A2277F28@vigilsec.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-opsawg-finding-geofeeds-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2021 14:38:52 -0000 > Pivoting for a second, are you intending to support the case in which > a provider has adopted RPKI but has no intention of signing these > files? unfortunately, this will be common for a while. methods for signing with keys from the rpki are baroque at the moment, with two documents draft-ietf-sidrops-rpki-rta-00 draft-spaghetti-sidrops-rpki-rsc-03 proposing means. > If so, then web PKI integrity (i.e., being able to trust that the data > at the https geofeed URL is controlled by the same entity that > controls the routing data) is still required to prevent forgery. the draft does require tls for the temporary remarks: based url. it will be fixed to do so for the geofeed: url. the web pki is not associated with ip address space control/ownership. web pki is based on control of domain name space. the two are quite unrelated. randy From nobody Wed May 5 07:49:20 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 335863A1041; Wed, 5 May 2021 07:49:18 -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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=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 MTO6LJSFaujf; Wed, 5 May 2021 07:49:16 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 8E4483A103C; Wed, 5 May 2021 07:49:16 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1leIps-0001FH-AC; Wed, 05 May 2021 14:49:12 +0000 Date: Wed, 05 May 2021 07:49:11 -0700 Message-ID: From: Randy Bush To: Kyle Rose Cc: Russ Housley , Last Call , Ops Area WG , draft-ietf-opsawg-finding-geofeeds.all@ietf.org, IETF SecDir In-Reply-To: References: <161969840202.30267.8231145700644479792@ietfa.amsl.com> <809A05C9-8ABD-4D63-970D-D3F8A2277F28@vigilsec.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-opsawg-finding-geofeeds-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2021 14:49:18 -0000 > the web pki is not associated with ip address space control/ownership. > web pki is based on control of domain name space. the two are quite > unrelated. note that the rpsl, the inetnum: objects, are not well secured and authenticated. this is a bit embarrassing. and, in some regions, the lack of authentication is notorious. hence the hack to use the well-authenticated rpki to sign those data covered by it for those concerned with real authenticity. randy From nobody Wed May 5 07:51:24 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85F503A105C for ; Wed, 5 May 2021 07:51:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uj5LrBGgZAmg for ; Wed, 5 May 2021 07:51:11 -0700 (PDT) Received: from mail-yb1-xb33.google.com (mail-yb1-xb33.google.com [IPv6:2607:f8b0:4864:20::b33]) (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 EC5FB3A104D for ; Wed, 5 May 2021 07:51:08 -0700 (PDT) Received: by mail-yb1-xb33.google.com with SMTP id l7so2987415ybf.8 for ; Wed, 05 May 2021 07:51:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dO5xLjVnXlwK/Imj7zDgebqyz8RkkotEQKP/M9PQNwo=; b=hY6zUCLBXUZwDlsts54QOBXUG8yeHjevJi3mIghRfREf+/HbvCGL+LNfj1AbcJAZMH bn97daVsBWutihvRXHE4E/mf4i+4vtQVimboupLcTy5rl4Nwqz+7dLIYq/I/QcyQZaTD vgeeaKo9P0Xz2y9kgQBPLLSzSWEVj0lm5BPQ0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dO5xLjVnXlwK/Imj7zDgebqyz8RkkotEQKP/M9PQNwo=; b=o9pt8UMLlW8ssHIoHd2AB5uCvvsQajjGqf2ZazmAiKZjzcEurTuskR+09KAREVCVh1 Wy56EzvqPHseoiPSw65l6GYC43CmG7CQFA7QQPpMp87FgmVDCQwVw1uZDpaplrKUvqyC uXY90Qmux2j/VnVmuwe/olp2mOatyBXMcA9vOuCH+bYT9I87skivHO5a1zPo6szlLSDZ tsZ8oJtCX+mSDPLNsXHwrlgSpOuLCxoh98utMq36rkul8sNiFyQHHPFd8Ovd90kHzQqo s+OvWE8l7v0qgL7hrWpLq3wz/tUe1Ytz8T6JEWgrwgKXmttWQJRTzcQrG5d8kE8PuJnh FA6A== X-Gm-Message-State: AOAM532RzJJ7gRyWhQARvUzxYq0IMhfO8zYn+jm7kJlSUw+12qZK/pl7 C0s7B0fcR3CMSk1tMFV/qN4Xg6AgwvDMpqeEsilqhA== X-Google-Smtp-Source: ABdhPJyGYbEdcDuZiXimv5sgSj9aRSd1KtWJnHSwzHg06dX2exVuZ2QiGKbX7s3CBrHZkL4qkPy9mSe69hNNVgMsfU8= X-Received: by 2002:a25:af06:: with SMTP id a6mr31118788ybh.364.1620226266827; Wed, 05 May 2021 07:51:06 -0700 (PDT) MIME-Version: 1.0 References: <161969840202.30267.8231145700644479792@ietfa.amsl.com> <809A05C9-8ABD-4D63-970D-D3F8A2277F28@vigilsec.com> In-Reply-To: From: Kyle Rose Date: Wed, 5 May 2021 10:50:55 -0400 Message-ID: To: Randy Bush Cc: Russ Housley , Last Call , Ops Area WG , draft-ietf-opsawg-finding-geofeeds.all@ietf.org, IETF SecDir Content-Type: multipart/alternative; boundary="0000000000001724f105c19653a7" Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-opsawg-finding-geofeeds-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2021 14:51:22 -0000 --0000000000001724f105c19653a7 Content-Type: text/plain; charset="UTF-8" On Wed, May 5, 2021 at 10:38 AM Randy Bush wrote: > > Pivoting for a second, are you intending to support the case in which > > a provider has adopted RPKI but has no intention of signing these > > files? > > unfortunately, this will be common for a while. methods for signing > with keys from the rpki are baroque at the moment, with two documents > draft-ietf-sidrops-rpki-rta-00 > draft-spaghetti-sidrops-rpki-rsc-03 > proposing means. > Noted. > > If so, then web PKI integrity (i.e., being able to trust that the data > > at the https geofeed URL is controlled by the same entity that > > controls the routing data) is still required to prevent forgery. > > the draft does require tls for the temporary remarks: based url. it > will be fixed to do so for the geofeed: url. > > the web pki is not associated with ip address space control/ownership. > web pki is based on control of domain name space. the two are quite > unrelated. > I still don't understand how this is relevant. I'm not asserting otherwise, and never have been. Let me try again: what are you suggesting would be basing its trust of geofeed IP ranges on the web PKI? Aren't the valid ranges for an AS specified in the RPKI-protected routing data feed (where RPKI is available)? Kyle --0000000000001724f105c19653a7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, May 5, 2021 at 10:38 AM Randy Bush <randy@psg.com> wrote:
> Pivoting for a second, are y= ou intending to support the case in which
> a provider has adopted RPKI but has no intention of signing these
> files?

unfortunately, this will be common for a while.=C2=A0 methods for signing with keys from the rpki are baroque at the moment, with two documents
=C2=A0 =C2=A0draft-ietf-sidrops-rpki-rta-00
=C2=A0 =C2=A0draft-spaghetti-sidrops-rpki-rsc-03
proposing means.

Noted.
> If so, then web PKI integrity (i.e., being able to trust that the data=
> at the https geofeed URL is controlled by the same entity that
> controls the routing data) is still required to prevent forgery.

the draft does require tls for the temporary remarks: based url.=C2=A0 it will be fixed to do so for the geofeed: url.

the web pki is not associated with ip address space control/ownership.
web pki is based on control of domain name space.=C2=A0 the two are quite unrelated.

I still don't understand how this is relevan= t. I'm not asserting otherwise, and never have been. Let me try again: = what are you suggesting would be basing its trust of geofeed IP ranges on t= he web PKI? Aren't the valid ranges for an AS specified in the RPKI-pro= tected routing data feed (where RPKI is available)?
Kyle
--0000000000001724f105c19653a7-- From nobody Wed May 5 07:54:29 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 375163A113E for ; Wed, 5 May 2021 07:54:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5KlyuqMdoAWD for ; Wed, 5 May 2021 07:54:17 -0700 (PDT) Received: from mail-yb1-xb2c.google.com (mail-yb1-xb2c.google.com [IPv6:2607:f8b0:4864:20::b2c]) (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 648CE3A1186 for ; Wed, 5 May 2021 07:54:10 -0700 (PDT) Received: by mail-yb1-xb2c.google.com with SMTP id v39so3037777ybd.4 for ; Wed, 05 May 2021 07:54:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iZSvuX9TFT2rAF6Duu/jYGuQnhitFbbAucUF/EEWiPI=; b=KA5J9Q4IB5LeHePMirACiJi1qqg9s0I2wo5b2U5q5qocSrcKxMuK4xyft9Y34LFStY EkfA51EXDK9A/gZ6vIWKnAHTNBml9yArkU1bt+hPZvgoidqYfvxUWjL2WuhXgXRD25XA as7j9+juNLVnBQpgI/Iy47Vvcdcih3iePfues= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iZSvuX9TFT2rAF6Duu/jYGuQnhitFbbAucUF/EEWiPI=; b=dK+eIBARcgUs/4Y09uBOO3T0FF/aPlxF7zGIGrxMPfOcxZxZv6KrWt0HwIVMBr0Ggf Gz2uwqsASRhIkYGyFegoUJCS4jytC+/rBRgGjmYrBUrD93hDuH1qOMuZqmtxwn+nzQOz W9o/GAFcnCF9HBm/pwI6jkCg5nw02sMSVuI8vHLX+MISgHyoLcepsN7Z8UvHsX+FLkZm ui5wkUcF6O7Od1NPk+H6ph8up3N/zvPwLnACFlB+F3UxfvxmthEuOS891iiFQcbYhI6y Tw+mb1aYLbBv65r4LWr7Mkwqkc2CEjJ9qiRBL2dz04RB7lVbhJgyz35G062xjMHFP3wJ CSdA== X-Gm-Message-State: AOAM5330ewJasS04XjFRCsUCCI+cmskrx9vndI0gTZ36uux8Ni/81gJw FBow5ntvHk0YlaMWdFgHj6wcyBj18BaQJkAM9l+8Yg== X-Google-Smtp-Source: ABdhPJxTx8/ZsR2rxmVoKHuuVbGESzApHiMOy+Gn9SjkkPhzFddHta08oqpMtgXcOUJ5xSydBnq6zZhqjFVJPleGzJk= X-Received: by 2002:a25:cacd:: with SMTP id a196mr6380085ybg.296.1620226448790; Wed, 05 May 2021 07:54:08 -0700 (PDT) MIME-Version: 1.0 References: <161969840202.30267.8231145700644479792@ietfa.amsl.com> <809A05C9-8ABD-4D63-970D-D3F8A2277F28@vigilsec.com> In-Reply-To: From: Kyle Rose Date: Wed, 5 May 2021 10:53:57 -0400 Message-ID: To: Randy Bush Cc: Russ Housley , Last Call , Ops Area WG , draft-ietf-opsawg-finding-geofeeds.all@ietf.org, IETF SecDir Content-Type: multipart/alternative; boundary="000000000000efac7b05c1965d22" Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-opsawg-finding-geofeeds-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2021 14:54:28 -0000 --000000000000efac7b05c1965d22 Content-Type: text/plain; charset="UTF-8" On Wed, May 5, 2021 at 10:49 AM Randy Bush wrote: > > the web pki is not associated with ip address space control/ownership. > > web pki is based on control of domain name space. the two are quite > > unrelated. > > note that the rpsl, the inetnum: objects, are not well secured and > authenticated. this is a bit embarrassing. and, in some regions, > the lack of authentication is notorious. > Okay, now we're getting somewhere. Do you say this because RPKI is not employed universally, or because the inetnum: objects are somehow not covered by RPKI? > hence the hack to use the well-authenticated rpki to sign those data > covered by it for those concerned with real authenticity. > How does a client know that an IP range specified in the geodata feed is valid under a given RPKI signature? I.e., that the given AS has authority over that IP range? Kyle --000000000000efac7b05c1965d22 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, May 5, 2021 at 10:49 AM Randy Bush <randy@psg.com> wrote:
> the web pki is not associated with ip address= space control/ownership.
> web pki is based on control of domain name space.=C2=A0 the two are qu= ite
> unrelated.

note that the rpsl, the inetnum: objects, are not well secured and
authenticated.=C2=A0 this is a bit embarrassing.=C2=A0 and, in some regions= ,
the lack of authentication is notorious.

Okay, now we'r= e getting somewhere. Do you say this because RPKI is not employed universal= ly, or because the inetnum: objects are somehow not covered by RPKI?
=C2=A0
hence the hack to use the well-authenticated rpki to sign those data
covered by it for those concerned with real authenticity.
<= div>
How do= es a client know that an IP range specified in the geodata feed is valid un= der a given RPKI signature? I.e., that the given AS has authority over that= IP range?

=
Kyle
=
--000000000000efac7b05c1965d22-- From nobody Wed May 5 08:03:30 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E48F3A0B63; Wed, 5 May 2021 06:30:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1620221433; bh=Kxjp+MbK7hxGz3ZgIipAIRkTWQ0ewjehhtKDkvWMSaI=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Reply-To; b=UWHqmMqMzVYCGsyiXHmMMyeoIqUWIGW7/dg1mA62p5PUsg4uE4vgLlhpN0FCSw1nO HRXYqINWScUDzAsJFuKPsL2CNARHRmFaHfE6Bv3bCtrBz9lLdw1BF9yNUyJPaeuAyT cPLWjcGIpQstzJEce7yL63xLF3gHSBITFyPhYoZA= X-Mailbox-Line: From new-work-bounces@ietf.org Wed May 5 06:30:29 2021 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 463603A0AA6; Wed, 5 May 2021 06:30:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1620221428; bh=Kxjp+MbK7hxGz3ZgIipAIRkTWQ0ewjehhtKDkvWMSaI=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Reply-To; b=loYMNhOV5LaSjQBQpQIfEKV03var86x9CjgdU8SNtpxrjJ8ooTBjgKNRqWbXh8Psz 7IxJmYKAqqYZLEh3Pc7H0l/s9OC650wmpNQGIRY/KUZ9ImU0D1H1lLqFcBzHU9qbWX a/0YsnACOO5zzBRliQEsNqms3mgklAV3xm5B1XBA= X-Original-To: new-work@ietf.org Delivered-To: new-work@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 463513A09EC for ; Wed, 5 May 2021 06:30:21 -0700 (PDT) MIME-Version: 1.0 From: The IESG To: X-Test-IDTracker: no X-IETF-IDTracker: 7.28.0 Auto-Submitted: auto-generated Precedence: bulk MIME-Version: 1.0 Reply_to: Message-ID: <162022142126.14275.6550713361356923880@ietfa.amsl.com> Date: Wed, 05 May 2021 06:30:21 -0700 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Reply-To: iesg@ietf.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Wed, 05 May 2021 08:03:29 -0700 Subject: [secdir] [new-work] WG Review: Limited Additional Mechanisms for PKIX and SMIME (lamps) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2021 13:30:39 -0000 The Limited Additional Mechanisms for PKIX and SMIME (lamps) WG in the Security Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by 2021-05-15. Limited Additional Mechanisms for PKIX and SMIME (lamps) ----------------------------------------------------------------------- Current status: Active WG Chairs: Russ Housley Tim Hollebeek Assigned Area Director: Roman Danyliw Security Area Directors: Benjamin Kaduk Roman Danyliw Mailing list: Address: spasm@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/spasm Archive: https://mailarchive.ietf.org/arch/browse/spasm/ Group page: https://datatracker.ietf.org/group/lamps/ Charter: https://datatracker.ietf.org/doc/charter-ietf-lamps/ The PKIX and S/MIME Working Groups have been closed for some time. Some updates have been proposed to the X.509 certificate documents produced by the PKIX Working Group and the electronic mail security documents produced by the S/MIME Working Group. The LAMPS (Limited Additional Mechanisms for PKIX and SMIME) Working Group is chartered to make updates where there is a known constituency interested in real deployment and there is at least one sufficiently well specified approach to the update so that the working group can sensibly evaluate whether to adopt a proposal. The LAMPS WG is now tackling these topics: 1. Specify the use of short-lived X.509 certificates for which no revocation information is made available by the Certification Authority. Short-lived certificates have a lifespan that is shorter than the time needed to detect, report, and distribute revocation information. As a result, revoking short-lived certificates is unnecessary and pointless. 2. Update the specification for the cryptographic protection of email headers -- both for signatures and encryption -- to improve the implementation situation with respect to privacy, security, usability and interoperability in cryptographically-protected electronic mail. Most current implementations of cryptographically-protected electronic mail protect only the body of the message, which leaves significant room for attacks against otherwise-protected messages. 3. The Certificate Management Protocol (CMP) is specified in RFC 4210, and it offers a vast range of certificate management options. CMP is currently being used in many different industrial environments, but it needs to be tailored to the specific needs of such machine-to-machine scenarios and communication among PKI management entities. The LAMPS WG will develop a "lightweight" profile of CMP to more efficiently support of these environments and better facilitate interoperable implementation, while preserving cryptographic algorithm agility. In addition, necessary updates and clarifications to CMP will be specified in a separate document. This work will be coordinated with the LWIG WG. 4. Provide concrete guidance for implementers of email user agents to promote interoperability of end-to-end cryptographic protection of email messages. This may include guidance about the generation, interpretation, and handling of protected messages; management of the relevant certificates; documentation of how to avoid common failure modes; strategies for deployment in a mixed environment; as well as test vectors and examples that can be used by implementers and interoperability testing. The resulting robust consensus among email user agent implementers is expected to provide more usable and useful cryptographic security for email users. 5. Recent progress in the development of quantum computers pose a threat to widely deployed public key algorithms. As a result, there is a need to prepare for a day when cryptosystems such as RSA, Diffie-Hellman, ECDSA, ECDH, and EdDSA cannot be depended upon in the PKIX and S/MIME protocols. 5.a. The US National Institute of Standards and Technology (NIST) has a Post-Quantum Cryptography (PQC) effort to produce one or more quantum-resistant public-key cryptographic algorithm standards. The LAMPS WG will specify the use of these new PQC public key algorithms with the PKIX certificates and the Cryptographic Message Syntax (CMS). These specifications will use object identifiers for the new algorithms that are assigned by NIST. 5.b. NIST and other organizations are developing standards for post-quantum cryptographic (PQC) algorithms that that will be secure even if large-scale quantum computers are ever developed. However, a lengthy transition from today's public key algorithms to PQC public key algorithms is expected; time will be needed to gain full confidence in the new PQC public key algorithms. 5.b.i. The LAMPS WG will specify formats, identifiers, enrollment, and operational practices for "hybrid key establishment" that combines the shared secret values one or more traditional key-establishment algorithm and one or more NIST PQC key-establishment algorithm or a PQC key-establishment algorithm vetted by the CFRG. The shared secret values will be combined using HKDF (see RFC 5869), one of the key derivation functions in NIST SP 800-56C, or a key derivation function vetted by the CFRG. 5.b.ii. The LAMPS WG will specify formats, identifiers, enrollment, and operational practices for "dual signature" that combine one or more traditional signature algorithm with one or more NIST PQC signature algorithm or a PQC algorithm vetted by the CFRG. In addition, the LAMPS WG may investigate other updates to documents produced by the PKIX and S/MIME WG. The LAMPS WG may produce clarifications where needed, but the LAMPS WG shall not adopt anything beyond clarifications without rechartering. Milestones: May 2021 - Adopt a draft for end-to-end email user agent guidance Jul 2021 - Adopt a draft for short-lived certificate conventions Oct 2021 - Adopt draft for PQC KEM public keys in PKIX certificates Oct 2021 - Adopt draft for PQC KEM algorithms in CMS Nov 2021 - Header protection conventions sent to IESG for standards track publication Dec 2021 - CMP updates sent to IESG for standards track publication Dec 2021 - Lightweight CMP profile sent to IESG for informational publication Dec 2021 - Adopt draft for PQC signatures in PKIX certificates Dec 2021 - Adopt draft for PQC signatures in CMS Dec 2021 - Adopt draft for public keys for hybrid key establishment in PKIX certificates Dec 2021 - Adopt draft for hybrid key establishment in CMS Dec 2021 - Adopt draft for dual signatures in PKIX certificates Dec 2021 - Adopt draft for dual signature in CMS Dec 2021 - CMP algorithms sent to IESG for standards track publication Mar 2022 - Short-lived certificate conventions sent to IESG for BCP publication Jul 2022 - End-to-end email user agent guidance sent to IESG for informational publication _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Wed May 5 08:32:56 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A90C23A157F; Wed, 5 May 2021 08:32:51 -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, SPF_HELO_NONE=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 1mc3B3kHyryB; Wed, 5 May 2021 08:32:49 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 F0DCF3A14C2; Wed, 5 May 2021 08:32:35 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1leJVn-0001QA-Hx; Wed, 05 May 2021 15:32:31 +0000 Date: Wed, 05 May 2021 08:32:28 -0700 Message-ID: From: Randy Bush To: Kyle Rose Cc: Russ Housley , Last Call , Ops Area WG , draft-ietf-opsawg-finding-geofeeds.all@ietf.org, IETF SecDir In-Reply-To: References: <161969840202.30267.8231145700644479792@ietfa.amsl.com> <809A05C9-8ABD-4D63-970D-D3F8A2277F28@vigilsec.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-opsawg-finding-geofeeds-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2021 15:32:55 -0000 [ excuse typos; minor hand surgery ] > Aren't the valid ranges for an AS specified in the RPKI-protected > routing data feed (where RPKI is available)? not really, on a number of dimensions first, have a look at draft-ietf-sidrops-rpki-has-no-identity i suggest we not drag ASs into this; they are orthogonal to address space ownership. e.g. someone owns a /24, but creates a ROA to authorize AS42, their upstream, to actually originate the prefix. i.e. ASs do not 'own' address space, the RPKI enables, through ROAs, for address space owners to authorize ASs to announce a (possibly improper) subset of the owner's address space. and inetnum:s are quite disjoint from ASs. heck, i have loaned 198.133.206.0/24 to be used by a north macedonian exchange point (not joking). also, neither the RPSL nor the RPKI invert to enumerate the address space announced by an AS. operators and researchers use the current bgp tables from routers, route views, or ripe/ris if we want today's map. > How does a client know that an IP range specified in the geodata feed > is valid under a given RPKI signature? the rpki is formally authoritative for ip space ownership. in a sense, the rpki was created to rigorously fill the gap left by the lack of authenticity of RPSL. the signature in the geofeed file can be 3779 validated to the trust anchor of the RIR (it should be to the IANA, but the RIRs are at war with the IANA). and the IANA is the ultimate authority for address space, and through it the RIRs. > I.e., that the given AS has authority over that IP range? again, let's not drag ASs in here. they are not ip space owners. the complexity of this space is embarrassing. sorry. i hope this helps. willing to chat on zoom or whatever. randy From nobody Thu May 6 00:33:53 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5830D3A15CC; Thu, 6 May 2021 00:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, 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=ripe.net 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 QseIQz2G8UhQ; Thu, 6 May 2021 00:33:38 -0700 (PDT) Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (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 5E1BC3A15C7; Thu, 6 May 2021 00:33:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ripe.net; s=s1-ripe-net; h=Content-Type:MIME-Version:Date:Message-ID:From:Cc:To: Subject; bh=8YhuoSdwWukVTBbvmff/NI1p2YTcgEDWQG5FnYBXE1Y=; b=dpL55NVDp89I6+UAR RT8ZheNTIApKs3BXH+DzeHvfTXYQOS2oYeLWzx0SlQppKpAYDvTJc1ipMrUJm77R8ukkvHjY61gck MAWPEt67nfYaZSw4S1CoiQlZ6T6zysPpNZeJ5MMydOgpbSu28X0afN64TjPW9m697P/5PWZzygVzD tlE7KlgkbeOz6AVrUoFp/fT+olYyK6ZG0QkF6KQ5ilpBBXwNuSElheLFkwQSNwOegv8CYqKKv/fqM x14HNx4rBri8NolLdLy6n2MO0CKuy3w2GU0LU5yYmY2UOXx/fUWo23H0NoYlgyJfhuKbJambfiaZg HeR+FkUM1W0vJd4qw==; Received: from allealle.ripe.net ([193.0.23.12]:38718) by mahimahi.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1leYVm-0001Ey-TG; Thu, 06 May 2021 09:33:30 +0200 Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:1200::299]) by allealle.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94) (envelope-from ) id 1leYVm-0004xa-Q3; Thu, 06 May 2021 09:33:30 +0200 To: Randy Bush , Kyle Rose Cc: Last Call , Ops Area WG , draft-ietf-opsawg-finding-geofeeds.all@ietf.org, Russ Housley , IETF SecDir References: <161969840202.30267.8231145700644479792@ietfa.amsl.com> <809A05C9-8ABD-4D63-970D-D3F8A2277F28@vigilsec.com> From: Robert Kisteleki Organization: RIPE NCC Message-ID: <74e0fe76-19a6-72ba-1352-106e1b8559ca@ripe.net> Date: Thu, 6 May 2021 09:33:30 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-ACL-Warn: Delaying message X-RIPE-Signature: 72e00e6d7601fa19264e98abc238a2743cf5f2e142defc052f96900d7aeadc4e Archived-At: Subject: Re: [secdir] [OPSAWG] [Last-Call] Secdir last call review of draft-ietf-opsawg-finding-geofeeds-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2021 07:33:44 -0000 On 2021-05-05 16:49, Randy Bush wrote: >> the web pki is not associated with ip address space control/ownership. >> web pki is based on control of domain name space. the two are quite >> unrelated. > > note that the rpsl, the inetnum: objects, are not well secured and > authenticated. this is a bit embarrassing. and, in some regions, > the lack of authentication is notorious. > > hence the hack to use the well-authenticated rpki to sign those data > covered by it for those concerned with real authenticity. > > randy (somewhat shameless plug) there is https://tools.ietf.org/html/rfc7909 that could be of assistance here. Robert From nobody Thu May 6 02:06:49 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84C353A1927; Thu, 6 May 2021 02:06:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=armh.onmicrosoft.com header.b=sgaqqUWg; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=sgaqqUWg 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 p5vxkfrOABii; Thu, 6 May 2021 02:06:43 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60085.outbound.protection.outlook.com [40.107.6.85]) (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 C972D3A190A; Thu, 6 May 2021 02:06:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=X+nZX2jPWURfObUzs3fHBUpXXGtF3FWZrX2BeNg9rao=; b=sgaqqUWg4gMV+lXKNt6b0bNUd7xywRWvKbNAyjSn5MV7Qrd1uHsZV8KDrow6PyGz9cL9x4IsXXPphrAY7NCrDJ8MaFrv+wTtRt2qH6IEFXXsDUaVMg5HIvzSiXaG4IJoPkYvG71CmEUAGoeKm8u9FuW4SWfA+T0n94mIH9e+6x8= Received: from AM7PR02CA0010.eurprd02.prod.outlook.com (2603:10a6:20b:100::20) by VI1PR0802MB2526.eurprd08.prod.outlook.com (2603:10a6:800:b5::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4065.25; Thu, 6 May 2021 09:06:38 +0000 Received: from AM5EUR03FT004.eop-EUR03.prod.protection.outlook.com (2603:10a6:20b:100:cafe::7) by AM7PR02CA0010.outlook.office365.com (2603:10a6:20b:100::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4108.25 via Frontend Transport; Thu, 6 May 2021 09:06:38 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by AM5EUR03FT004.mail.protection.outlook.com (10.152.16.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4108.25 via Frontend Transport; Thu, 6 May 2021 09:06:38 +0000 Received: ("Tessian outbound 6c4b4bc1cefb:v91"); Thu, 06 May 2021 09:06:38 +0000 X-CR-MTA-TID: 64aa7808 Received: from fbcce93529ce.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 2B1F9937-4FE7-4D44-8B36-7AA55F1F2CAE.1; Thu, 06 May 2021 09:06:32 +0000 Received: from EUR05-DB8-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id fbcce93529ce.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Thu, 06 May 2021 09:06:32 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UhEAEDl/YRZqMlBw7MAWCYjr+FnNjY37FKrjzFsV72mDMzAVNSqwFepe+BAo/MqZ5ZMWmgDtM0QC0ozmo8fA7O0NILjGzIFJfoFJLlcZsGMgNpUVgricmADpRD9u8FbRr7Vpd6jenDaY7kPk/83agan2qOPU8SmLz2+88J+qzU/jUNmCrwkWAftVqy1bkExD+CPImgcGe6GYLl4Zc+jSawAA8rU1ik2BRlqLFzq6wHsVLefkr69TDvxbp9tyOREqoqyCh622AO89l9Op21iCeQaHw52AL5VEj4tVdwVWgk5zev4nKgvT++d/R0GeEeZvmNqTeVCuljM3ut1vtTbbZA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=X+nZX2jPWURfObUzs3fHBUpXXGtF3FWZrX2BeNg9rao=; b=knWhYhlkpMVyC7qHxftH4/NJlvRNamQC3IrYadMFslJ/P8ja58eM1/hqB9XC35CDiJtqz6MAEJeRow/4mu2LEp/obdAH0wK8HlMJmyUHYHtRpDEq2wiJ6eRW9dprVxm3iFntz6nj/gQ4BmR//4ttscT2xWgspZZk0ru59bofenQRVc7WXlfE1twfzev/ynvcjTO6GNKApBIg4Q+DoiyNfdG61J2HGLquP9xeSvCzvbOA3VR5A9TO7BEgTmQn8OxDsABmNYt4JTpCOAhJq++7Bc++FKV7VFSM/vSx0pcxlbytKOZRwHobzbWrYO4A7IGjCmZhqDfAy+Ul8hLsJuSL2g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=X+nZX2jPWURfObUzs3fHBUpXXGtF3FWZrX2BeNg9rao=; b=sgaqqUWg4gMV+lXKNt6b0bNUd7xywRWvKbNAyjSn5MV7Qrd1uHsZV8KDrow6PyGz9cL9x4IsXXPphrAY7NCrDJ8MaFrv+wTtRt2qH6IEFXXsDUaVMg5HIvzSiXaG4IJoPkYvG71CmEUAGoeKm8u9FuW4SWfA+T0n94mIH9e+6x8= Received: from VI1PR08MB2639.eurprd08.prod.outlook.com (2603:10a6:802:25::13) by VI1PR08MB4128.eurprd08.prod.outlook.com (2603:10a6:803:e9::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4108.25; Thu, 6 May 2021 09:06:31 +0000 Received: from VI1PR08MB2639.eurprd08.prod.outlook.com ([fe80::99ef:85aa:3465:475e]) by VI1PR08MB2639.eurprd08.prod.outlook.com ([fe80::99ef:85aa:3465:475e%7]) with mapi id 15.20.4108.027; Thu, 6 May 2021 09:06:30 +0000 From: Hannes Tschofenig To: Benjamin Kaduk , Daniel Franke CC: "draft-ietf-tls-dtls-connection-id.all@ietf.org" , "secdir@ietf.org" Thread-Topic: [secdir] Secdir last call review of draft-ietf-tls-dtls-connection-id-11 Thread-Index: AQHXN41cUEQ7EEAJ/0K7cRzfE/t7PKrPqiWAgAaTahA= Date: Thu, 6 May 2021 09:06:30 +0000 Message-ID: References: <161910581603.10398.13918665853904033223@ietfa.amsl.com> <20210502043549.GF79563@kduck.mit.edu> In-Reply-To: <20210502043549.GF79563@kduck.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: 45238133A67836488E59F0FCD43E0274.0 x-checkrecipientchecked: true Authentication-Results-Original: mit.edu; dkim=none (message not signed) header.d=none;mit.edu; dmarc=none action=none header.from=arm.com; x-originating-ip: [80.92.114.2] x-ms-publictraffictype: Email X-MS-Office365-Filtering-Correlation-Id: 85cd486b-797d-44ef-ec61-08d9106e41c9 x-ms-traffictypediagnostic: VI1PR08MB4128:|VI1PR0802MB2526: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:9508;OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: 0CtIgLFXIEftSvqIqd+mTVoVbKeW2jgKD25g5k3xEWf6ZdlvHkVku4y0rSjbLblK/v8VtkpSIVZpz5Zdn+QDbXgHoV5eVn0l+/HJM2Dq8D2e5/9i4ZzK+B+q2PYDOLVm7LzirEDlqhIh2mTnWX7DKuIAxvIbXixziM9D6X6Xqdk44JiKqA7umRsLmrdDB2N7z3WSsHrBoP09H+cZybdcG86eYu/6bI27Z6l+0T9OObg5sB3Nvz8llTt+C6E1/tNeFZCL//xaWwdgCboUvmj+HNXNDnZoVISNE9Jg/Ln6g+2aUjRJfZRb7Er3npI5n+G/29/ltS6YPgAMGrKX9s2VVgrLyfSAMQsepUio+CHj384ZNjOeTECOuZlNpyiCY9mMEkS6/Urb2R3F+iHpoRxZMw8/6BHUtYOi/ZsxOCn/ozaOJjb0GnE3aePSFIMDSMxNzepRmsRd3HbfJC15dlxrpnR+9VjZtOiiChCuPKvBhw2wG219aTqIeDuLXWMn3laLFhLIDnb0yZT/HFri/vIwAOr3HYTROgT5TfOTkmJo0N+GX87spE1BztDELT1867ZJy1b6tS/pdBwzMeJFwU3sbOsd59ZAa6+7PZfN6pJRIll7ZOWxZm4NJNE0wbGkqdKnl2iTDs/JIQpNHqDMM1IDA4kMj57qyX/P93kab7dIqJndz0/0D4GVU3Kix3NdqdGV X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR08MB2639.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(396003)(136003)(346002)(376002)(39860400002)(76116006)(316002)(66946007)(55016002)(110136005)(83380400001)(122000001)(33656002)(86362001)(4326008)(38100700002)(54906003)(66476007)(66556008)(66446008)(9686003)(478600001)(64756008)(7696005)(2906002)(52536014)(8676002)(186003)(966005)(71200400001)(6506007)(8936002)(26005)(5660300002)(53546011); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?Tk9BTC9WdGhxdGFuL1l5NnhmZ3Y4RjZrMFZFNkxMUTAweFQ2VXNRTE9VbVdz?= =?utf-8?B?ME9OMEdnd0xrcll5MWluSmZZSXUweVRwZDVaSzlqVFFVbUtmanAxUVNRWEwr?= =?utf-8?B?TUNsMFFtT0FXSXczbm44bUJNeVJlbEVHR0RDU25DU1pTZENtRU1YUUx0MVZ4?= =?utf-8?B?ZWd2SllHbFJieDJDTnNCTTU4SzY4RzJNSW0zWmFldldLSFdsTzdTWVFKWk0x?= =?utf-8?B?SVg0U3lUSmZiS3B2aFMvakluL2dlTkZidGFHeEF3ZU5CSFRXQ05zcXZoUVZT?= =?utf-8?B?aEpYNE12SjEvQkNTaFZkWHhZUE1iZFIwdjFkbmhPVDNzUHNsclNGTXZwR29Y?= =?utf-8?B?S3lVTmo0NlZmMGVYeG9iV1kxZ3JKSTUyL2NFbkI4WFdLMngzSGQzbUtSYitK?= =?utf-8?B?UjR5VGRCaS9yVFBHS2hvVTh3K0JtTjNOVm4rNGlLVUIvWDVibFBoeU1XRGkw?= =?utf-8?B?bFRCQytqSUlkZk9CaEFTMkFIengrUUkvdXFmNDY1UDd5YlZPRVJvQ3FlQXRx?= =?utf-8?B?N1RMN0xNdlArTjJRanVzNzBiYmFZZHR4TFl3TlRqOWRuSnZjYU5aNDZsMVZw?= =?utf-8?B?VjJnRWpETERLcldydFNmVW1rdXRwelBub0VDaGoveEZWTjJZMVZyUXV5aWps?= =?utf-8?B?cDc5czZBVDlOZzl1M1JCL1FUNWp3TTI2Vi9waS96MkN5b0lLOFFEeHFkek1V?= =?utf-8?B?cmRBWFlJZEorZkJZYlhlREFFYXhUWmhSL0JrM25nYW44UEt1dVlQSUVpQ3hQ?= =?utf-8?B?aVk0emhENmFaTjhuNnJ5UXZhSHVzUlk0MnB4c0lkcEw4NXV4TGplTmY3NnNQ?= =?utf-8?B?YzArYmVSM2tHMzg4KzlTaG5TNU1SMVZSVmpjYnVlQVhDYTFnSjNNckZGVEI0?= =?utf-8?B?NnpwaGZTUHc0VzlHRGFZV0hLMXBTM2dZNCtqeVpXczNoRFdxVmU2TW10clA0?= =?utf-8?B?WUUzUmNUTlcwcm15bU8xSzVETytMbnYyM1o1QituYnBTN3NiRkxRMW1yYm55?= =?utf-8?B?TzlVZGx1d3VlZXI0dVpzWm9peEZIUTE2NDNXenpqNlhPMUZOUjU3SHdNOG1D?= =?utf-8?B?Z29wNlFsNW5kcWRMUHRORTlKSmxQTDNoRGlQS2VrZllrSGYzRk1XWmtaTW95?= =?utf-8?B?Z0x0Um5TYVJPZEZFYjBwTWxqSllRMDJaTWNsT29paU9pWlNSOVRqSUN5bzda?= =?utf-8?B?RmZZWEtxMCtaUGs3a0RUY1RjbzU5NkwzeUNLL2hCL0p2YkRMdDV0cWVmcjRp?= =?utf-8?B?bXhhclhHLzFSdmxyN3NRMDF2QUxWd1JkaVhvZnVTbzBOcVVpSkc3SG1QM0Ry?= =?utf-8?B?aFlDenBSMjBoMzhRaGM0U005c0lKT3hSaUk0WVRHNzhGQStDT2YzT1RhZ3BO?= =?utf-8?B?RTFtc3RBV0tFMzAxdVArZUdBWU1VUzNrNnY4Ym9aaXVaS3p3QmRmazNBazRx?= =?utf-8?B?OE1JTzdabFd2NVZacm5wckY0MlNYL0F0bVYyNEVjT2hKdG5GRlZ5Y0JTRlFk?= =?utf-8?B?Rml0Y3NyeE5IUnBVSU9VTkxReDNBSU9YSTNuekVuRDdUbzNicFl2LzhIRU5W?= =?utf-8?B?YWt5d1kxdUp2VTJlUUZsUzJCK3grUk5hWmQ4N09ObTFjM05xVUhCUnRYV2RE?= =?utf-8?B?SmZLS3Q3dktXRnlFWkU0NTcwbHJOT0RkSjFySGxIVGs4MTY3YlpmOERpOGta?= =?utf-8?B?U3NvSG5oazZtMGtaOGZueW1JbWpST2MvWi82NDF6anVwVFhDREZxRXAzaVE5?= =?utf-8?Q?Cmc/byoAlWyeZpUhJE=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB4128 Original-Authentication-Results: mit.edu; dkim=none (message not signed) header.d=none;mit.edu; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT004.eop-EUR03.prod.protection.outlook.com X-MS-Office365-Filtering-Correlation-Id-Prvs: 98351e0a-a3ea-4989-f5d8-08d9106e3d41 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: CyFr5O8/yF4sYq6K8HuXbZ6Q1vEko7V8/Vai86eKJHK2YCp61T2nVVMNBO0uyBnURuPUQL37XrH2wGB7WqNpgAc3JtbUksWx8cPABoHuMB1DN0K11P/INxPxvMZ7coZYeP6HjTFuS+43iSpqglzA8l68fxKa9ZpkQVSq9QztCGUJwLtzMwdDoqQzKSGsBBmk/GrkpoI9vRCMFWu0xzZxCtsOLDUtNueYs0Qd6zdoD09Tmh4/AtnLVKLFPB6XDZttKFBOYnJsHWr5UViYhIrfaMTDvqtHZ9oO7ceRaaK5iehQE7qsNu2+iqeVl7uAt2UccDBAnumSUUus5qmYfihE/ebmJQUPlyevn3O3Hamf0WpU9155QS/KnF1nrmgVDX/+SS4Dtq+t9UUoUrLPk9ePE5sh/sh39oX1Dygv4izpeiW/KJw2m66AM67dckIQCUQNgMYV3UYBmkrSl7RhDz0nO/NLkd6TjXaTd8O9AuxH0cVmjNWpgnm1bzcbSNS47lYqrXrpgma1bfl7IdUjfUtOVki1iflKAPO7Tzh0eDmMHx/0qO7ISmk4xK/1VKuTABOHmAIVttZVK6OY+rLYZvnlraeTMI+CphVh3BGNVjWbzeNbuUYrP5fVjzH19/fCK7vfw75kxqyAPkxil2d5RgRulNVjvtLgf+b51sEnQg+BWNl6dgMRWjJYXBZ7jTpLJEExh80qUSVJmNKF5zQXAHim2fTilCrhXDrTsW6MFkD3XWM= X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFS:(4636009)(346002)(136003)(396003)(376002)(39860400002)(46966006)(36840700001)(8676002)(316002)(55016002)(8936002)(7696005)(81166007)(36860700001)(82310400003)(54906003)(52536014)(2906002)(5660300002)(83380400001)(966005)(4326008)(478600001)(33656002)(9686003)(336012)(356005)(26005)(186003)(47076005)(6506007)(82740400003)(53546011)(86362001)(70586007)(70206006)(450100002)(110136005); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 May 2021 09:06:38.5085 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 85cd486b-797d-44ef-ec61-08d9106e41c9 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: AM5EUR03FT004.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0802MB2526 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-tls-dtls-connection-id-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2021 09:06:48 -0000 SGkgQmVuLCBIaSBEYW5pZWwsDQoNClRoZXJlIGlzIGN1cnJlbnRseSBhIGNhbGwgZm9yIGFkb3B0 aW9uIG9mIGRyYWZ0LXRzY2hvZmVuaWctdGxzLWR0bHMtcnJjIGJlY2F1c2UgdGhlIFRMUyBncm91 cCBkZWNpZGVkIGVhcmxpZXIgdG8gY29uc2lkZXIgYWRvcHRpb24gYWZ0ZXIgdGhlIGNvbXBsZXRp b24gb2YgZHJhZnQtaWV0Zi10bHMtZHRscy1jb25uZWN0aW9uLWlkLTExICYgRFRMUyAxLjMgZ2l2 ZW4gdGhhdCB0aGVyZSBhcmUgYXBwbGljYXRpb24gc3BlY2lmaWMgbWVjaGFuaXNtcyB0aGFuIGNh biBwcm92aWRlIHRoZSBzYW1lIGZ1bmN0aW9uYWxpdHkuIE9mIGNvdXJzZSwgYXMgRGFuaWVsIG1l bnRpb25lZCBiZWxvdywgdGhlcmUgYXJlIHByZWZlcmVuY2VzIGluIHRoZSBkZXNpZ24gb2YgY29t bXVuaWNhdGlvbiBzZWN1cml0eSB0aGF0IHBsYXkgYSByb2xlIGhlcmUuIEluIHRoZSBJRVRGIElv VCBjb21tdW5pdHkgd2UgaGF2ZSBzZWVuIGZvbGtzIHdobyBwcmVmZXIgdG8gZG8gdGhpbmdzIGF0 IHRoZSBhcHBsaWNhdGlvbiBsYXllciAoQ29BUCBpbiBwYXJ0aWN1bGFyKSBhbmQgdGhlbiB0aGVy ZSBhcmUgZm9sa3Mgd2hvIHdhbnQgdG8gZGVzaWduIGEgc29sdXRpb24gYXMgbG93IGluIHRoZSBz dGFjayBhcyBwb3NzaWJsZS4NCg0KSW4gYW55IGNhc2UsIHdlIGhhdmUgaW1wbGVtZW50ZWQgdGhl IDEuMiBDSUQgc29sdXRpb24gYW5kIHVzZSBhcHBsaWNhdGlvbiBsYXllciBSUkNzLiBBcyBhIGNv LWF1dGhvciBvZiB0aGUgLSBkdGxzLXJyYyBJIGFsc28gd2FudCB0byBzZWUgYSBnZW5lcmljIHNv bHV0aW9uIGF0IHRoZSBEVExTIGxheWVyLg0KDQpDaWFvDQpIYW5uZXMNCg0KDQotLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogc2VjZGlyIDxzZWNkaXItYm91bmNlc0BpZXRmLm9yZz4g T24gQmVoYWxmIE9mIEJlbmphbWluIEthZHVrDQpTZW50OiBTdW5kYXksIE1heSAyLCAyMDIxIDY6 MzYgQU0NClRvOiBEYW5pZWwgRnJhbmtlIDxkYWZyYW5rZUBha2FtYWkuY29tPg0KQ2M6IGRyYWZ0 LWlldGYtdGxzLWR0bHMtY29ubmVjdGlvbi1pZC5hbGxAaWV0Zi5vcmc7IHNlY2RpckBpZXRmLm9y Zw0KU3ViamVjdDogUmU6IFtzZWNkaXJdIFNlY2RpciBsYXN0IGNhbGwgcmV2aWV3IG9mIGRyYWZ0 LWlldGYtdGxzLWR0bHMtY29ubmVjdGlvbi1pZC0xMQ0KDQpIaSBEYW5pZWwsDQoNClRoYW5rcyBm b3IgdGhlIHJldmlldy4NCg0KVGhlcmUgd2FzIHNvbWUgZWZmb3J0IHRvd2FyZHMgYSByZXR1cm4t cm91dGFiaWxpdHkgY2hlY2sgYXQgdGhlIERUTFMgbGF5ZXIsIGluIGRyYWZ0LXRzY2hvZmVuaWct dGxzLWR0bHMtcnJjLCBidXQgd2Ugc2VlbSB0byBoYXZlIGZhaWxlZCB0byBmb2xsb3cgdXAgYWZ0 ZXIgdGhlIGFkb3B0aW9uIGNhbGwgd2FzIGlzc3VlZC4NCg0KSSd2ZSBwaW5nZWQgdGhlIGNoYWly cyB0byBjaGVjayBvbiBpdHMgcHJvZ3Jlc3MuDQoNCi1CZW4NCg0KT24gVGh1LCBBcHIgMjIsIDIw MjEgYXQgMDg6MzY6NTZBTSAtMDcwMCwgRGFuaWVsIEZyYW5rZSB2aWEgRGF0YXRyYWNrZXIgd3Jv dGU6DQo+IFJldmlld2VyOiBEYW5pZWwgRnJhbmtlDQo+IFJldmlldyByZXN1bHQ6IFJlYWR5DQo+ DQo+IEkgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlIHNlY3VyaXR5 IGRpcmVjdG9yYXRlJ3MNCj4gb25nb2luZyBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRGIGRvY3Vt ZW50cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhlDQo+IElFU0cuICBUaGVzZSBjb21tZW50cyB3ZXJl IHdyaXR0ZW4gcHJpbWFyaWx5IGZvciB0aGUgYmVuZWZpdCBvZiB0aGUgc2VjdXJpdHkgYXJlYSBk aXJlY3RvcnMuDQo+ICBEb2N1bWVudCBlZGl0b3JzIGFuZCBXRyBjaGFpcnMgc2hvdWxkIHRyZWF0 IHRoZXNlIGNvbW1lbnRzIGp1c3QgbGlrZQ0KPiBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRz Lg0KPg0KPiBBcG9sb2dpZXMgZm9yIHRoZSBhYnNvbHV0ZSBsYXN0LW1pbnV0ZSByZXZpZXc7IEkg b3Zlcmxvb2tlZCB1bnRpbCBqdXN0DQo+IG5vdyB0aGF0IHRoaXMgaGFkIGJlZW4gYXNzaWduZWQg YSB0ZWxlY2hhdCBkYXRlLg0KPg0KPiBUaGlzIGRvY3VtZW50IGlzIFJlYWR5LiBJIGRvIGhhdmUg c29tZSBjb25jZXJucyDigJQgaW4gcGFydGljdWxhciBJDQo+IHRoaW5rIHJlbHlpbmcgb24gYXBw bGljYXRpb24tbGF5ZXIgbWVhc3VyZXMgdG8gcHJldmVudCBhbXBsaWZpZWQNCj4gcmVmbGVjdGlv biBhdHRhY2tzIGlzIGEgYml0IGR1YmlvdXMg4oCUIGJ1dCB0aGVzZSBoYXZlIGJlZW4gZGViYXRl ZCB0bw0KPiBkZWF0aCBhbHJlYWR5LCB0aGUgaXNzdWVzIGFyZSB3ZWxsLWNhcHR1cmVkIGluIHRo ZSBkb2N1bWVudCwgYW5kIEkgZG9uJ3QgdGhpbmsgSSBoYXZlIGFueXRoaW5nIG5ldyB0byBhZGQu DQo+DQo+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpzZWNkaXIgbWFpbGluZyBsaXN0DQpzZWNkaXJAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc2VjZGlyDQp3aWtpOiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcv YXJlYS9zZWMvdHJhYy93aWtpL1NlY0RpclJldmlldw0KSU1QT1JUQU5UIE5PVElDRTogVGhlIGNv bnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFs IGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQg cmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5v dCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBh bnkgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1 bS4gVGhhbmsgeW91Lg0K From nobody Thu May 6 07:36:40 2021 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AB743A2475; Thu, 6 May 2021 07:36:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Rich Salz via Datatracker To: Cc: avt@ietf.org, draft-ietf-avtcore-multi-party-rtt-mix.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.28.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162031178943.8783.4063437681950995450@ietfa.amsl.com> Reply-To: Rich Salz Date: Thu, 06 May 2021 07:36:29 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-avtcore-multi-party-rtt-mix-16 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2021 14:36:30 -0000 Reviewer: Rich Salz Review result: Ready This review is for the benefit of the Security AD's. Nobody else should read this. Or, if you read it, treat it as any other last call review :) I know very little about WebRTC, AVT, etc. I thought Section 1.2, summary of the alternatives, was great. I wish more documents did this kind of thing. And similar for all of section 2. The details in Section 3 about how to comply seem very clear. If I were implementing this, I could use easily use this as a checklist and test suite. Section 3.19 is the most important one for transport security. Not knowing the operating environments, it seems reasonable. The security considerations seems a little scant, given the opportunity for privacy concerns of participants and for intruders to disrupt calls. Is it common that the mixer is a trusted entity? A statement on that either way would be useful. From nobody Thu May 6 12:06:07 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AB803A2D2A for ; Thu, 6 May 2021 12:06:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.655 X-Spam-Level: X-Spam-Status: No, score=-0.655 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=1.242, SPF_HELO_NONE=0.001, 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=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 Rcisgxe23W9z for ; Thu, 6 May 2021 12:05:54 -0700 (PDT) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::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 40EEF3A2D46 for ; Thu, 6 May 2021 12:05:50 -0700 (PDT) Received: by mail-lj1-x231.google.com with SMTP id b7so8444360ljr.4 for ; Thu, 06 May 2021 12:05:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nQhATGOK4xcs82Ibvj+CAktWsbbFKv5940kZq6MGUbY=; b=VD3FGEx6A6/JPyIglLKgHZplzlQyfAQXmF53LvoVMgHQZBr1PB68AEOxF0Qceq8Cci Iy7QQjUldeuH0ngxbQoqwWdGWSWwD9m+T/HCMcW2KLv9LxIpiqaSMsTyHQtbay32Rqj4 2Vw2lWwgogqhcopxXIYtlNKPP5LaWKW3lPiGlLcsv2Q3CACkEmy/rlWlS0z9qhLnff91 sI5pfdmn9L0TVo7wKgduUqvg2p44l4opXbp7guKqoQi+ictNYiC1V9lFCsa973ryzxdq 55GgDOhSlBDobQ6qwyD3KVoqpUfWYvORwnE6N1qVhEeDDufy/LKZNc9m8nPNryNR6jmT b5Dg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nQhATGOK4xcs82Ibvj+CAktWsbbFKv5940kZq6MGUbY=; b=D+brikLqZu2BgaDnT4MM48DQR8ef9Fr9QvTnc3MWDu68kiS5DJ7eWZQauGPPd3u7Hd GJQwRsfJoWpqfLMZvP9YHO7st0XzfpELSTeYrxpOUJx3SEt5zgqLm3IzdGIn9FgPdGrE rjHahfzqKODnv8bgB++VO3zQUvLpYWuhM6r9o9/dQwv1eTub0HrqVa3T8+VZYM1K/M2X mbfyCbfVOyw/L3UsDd0GrYwLCKCsbcSp4QNWmZhO1ChJEAov1InQmUNjO8FR1Tk4OVTq 1jqb7grGwtu9lszzxwa+ST875QRfGghpD4wGg4/XaK4OTXRj1sc2Ee+Ot4AOR/qW7sZ9 3Tlg== X-Gm-Message-State: AOAM531y4d/pqqcMrRc6YKyhFX2ls5KT+0hLdLirnp6pbQSWEJTuFYJA 6xgI0OANSBHhdtVk+C66DAj9eeiLIzBeO0PgLewOWw== X-Google-Smtp-Source: ABdhPJw3FZ6bIOIbLivMdMD5CTnVZyZCBE9iooWoBTXR9u844J8LdozyYgBhiv58KXTyqxrrKaGtssNcT5zgM0aUi7w= X-Received: by 2002:a2e:9a14:: with SMTP id o20mr4780888lji.309.1620327947520; Thu, 06 May 2021 12:05:47 -0700 (PDT) MIME-Version: 1.0 References: <161969840202.30267.8231145700644479792@ietfa.amsl.com> <809A05C9-8ABD-4D63-970D-D3F8A2277F28@vigilsec.com> In-Reply-To: From: Warren Kumari Date: Thu, 6 May 2021 15:05:11 -0400 Message-ID: To: Kyle Rose Cc: Randy Bush , Russ Housley , Last Call , Ops Area WG , draft-ietf-opsawg-finding-geofeeds.all@ietf.org, IETF SecDir Content-Type: multipart/alternative; boundary="000000000000bb5c7a05c1adff00" Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-opsawg-finding-geofeeds-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2021 19:06:06 -0000 --000000000000bb5c7a05c1adff00 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable [ Top-post ] Hi there all, I must admit that I've managed to lose the plot here -- I've read, and reread the threads, and am confused/think people may be talking past each other (or that I'm just not understanding...) I'm trying to understand what the actual issue / confusion is; perhaps a concrete example will help. One of the IETF meeting network ranges is 31.130.224.0/20. This network moves to wherever the IETF meeting is, and so we publish a geofeeds format file: $ whois 31.130.224.0 % IANA WHOIS server % for more information on IANA, visit http://www.iana.org % This query returned 1 object refer: whois.ripe.net inetnum: 31.0.0.0 - 31.255.255.255 organisation: RIPE NCC status: ALLOCATED whois: whois.ripe.net changed: 2010-05 source: IANA # whois.ripe.net inetnum: 31.130.224.0 - 31.130.239.255 netname: ietf-meeting-network descr: IETF Meeting Network country: CH org: ORG-IS136-RIPE admin-c: IED11-RIPE tech-c: IETF-RIPE status: ASSIGNED PI mnt-by: RIPE-NCC-END-MNT mnt-by: IETF-MNT mnt-by: netnod-mnt mnt-routes: ietf-mnt mnt-domains: ietf-mnt created: 2011-05-10T10:10:10Z last-modified: 2020-11-16T17:48:30Z source: RIPE # Filtered remarks: Geofeed https://noc.ietf.org/geo/google.csv sponsoring-org: ORG-NIE1-RIPE ... The geofeed file is served from the machine called 'noc.ietf.org', which happens to be hosted in a rack in Dallas, using some unrelated IP space provided by Randy (198.180.152.0/24). When the IETF meeting finishes, one of the NOC people logs in and updates the content of the file to list the next meeting location (so that the geo-providers will update their locations). Note that whoever does this likely doesn't have easy access to the RPKI keys - it's quite common for different sets of people to be publishing/updating the geo info than the routing security people. Geolocation providers can get the IRR information, and follow the URL to grab the file. Note that the URL is hosted on completely different IP space, and the cert is whatever the cert for that machine happens to be. This could be hosted on any name/any address/etc. We specify HTTPS (instead of HTTP) because it's best practice, not because of any sort of correlation, etc. I'm unclear if I'm missing something, or if people are talking past each other, or what. W On Wed, May 5, 2021 at 10:54 AM Kyle Rose wrote: > On Wed, May 5, 2021 at 10:49 AM Randy Bush wrote: > >> > the web pki is not associated with ip address space control/ownership. >> > web pki is based on control of domain name space. the two are quite >> > unrelated. >> >> note that the rpsl, the inetnum: objects, are not well secured and >> authenticated. this is a bit embarrassing. and, in some regions, >> the lack of authentication is notorious. >> > > Okay, now we're getting somewhere. Do you say this because RPKI is not > employed universally, or because the inetnum: objects are somehow not > covered by RPKI? > > >> hence the hack to use the well-authenticated rpki to sign those data >> covered by it for those concerned with real authenticity. >> > > How does a client know that an IP range specified in the geodata feed is > valid under a given RPKI signature? I.e., that the given AS has authority > over that IP range? > > Kyle > --=20 The computing scientist=E2=80=99s main challenge is not to get confused by = the complexities of his own making. -- E. W. Dijkstra --000000000000bb5c7a05c1adff00 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
[ Top-post ]

Hi there all,

= I must admit that I've managed to lose the plot here -- I've read, = and reread the threads, and am confused/think people may be talking past ea= ch other (or that I'm just not understanding...)

I'm trying to unders= tand what the actual issue / confusion is; perhaps a concrete example will = help.

One of the IETF meeting network ranges is=C2=A031.130.224.0/20. This network moves to whe= rever the IETF meeting is, and so we publish a geofeeds format file:=C2=A0<= /div>

$ = whois 31.130.224.0
% IANA WHOIS serve= r
% for more information on IANA, visit=C2=A0http://www.iana.org
% This query returned 1 = object

refer: =C2=A0 =C2=A0 =C2=A0 =C2=A0whois.ripe.net

inetnum: =C2=A0 =C2=A0 = =C2=A031.0.0.0 - 31.255.255.255
organisation: RIPE NCC
status: =C2=A0= =C2=A0 =C2=A0 ALLOCATED

whois: =C2=A0 =C2=A0 =C2=A0 =C2=A0whois.ripe.net

cha= nged: =C2=A0 =C2=A0 =C2=A02010-05
source: =C2=A0 =C2=A0 =C2=A0 IANA
<= br>#=C2=A0whois.ripe.n= et

inetnum: =C2=A0 =C2=A0 =C2=A0 =C2=A031.130.224.0 - 31.130.239= .255
netname: =C2=A0 =C2=A0 =C2=A0 =C2=A0ietf-meeting-network
descr: = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IETF Meeting Network
country: =C2=A0 = =C2=A0 =C2=A0 =C2=A0CH
org: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ORG= -IS136-RIPE
admin-c: =C2=A0 =C2=A0 =C2=A0 =C2=A0IED11-RIPE
tech-c: = =C2=A0 =C2=A0 =C2=A0 =C2=A0 IETF-RIPE
status: =C2=A0 =C2=A0 =C2=A0 =C2= =A0 ASSIGNED PI
mnt-by: =C2=A0 =C2=A0 =C2=A0 =C2=A0 RIPE-NCC-END-MNT
= mnt-by: =C2=A0 =C2=A0 =C2=A0 =C2=A0 IETF-MNT
mnt-by: =C2=A0 =C2=A0 =C2= =A0 =C2=A0 netnod-mnt
mnt-routes: =C2=A0 =C2=A0 ietf-mnt
mnt-domains:= =C2=A0 =C2=A0ietf-mnt
created: =C2=A0 =C2=A0 =C2=A0 =C2=A02011-05-10T10= :10:10Z
last-modified: =C2=A02020-11-16T17:48:30Z
source: =C2=A0 =C2= =A0 =C2=A0 =C2=A0 RIPE # Filtered
remarks: =C2=A0 =C2=A0 =C2=A0 =C2=A0Ge= ofeed=C2=A0https://noc.ietf.org/geo/google.csv
sponsoring-org: ORG-NIE1-RIPE<= br>
...


The geofeed file is served from the machine called 'noc.ietf.org', which happens to= be hosted in a rack in Dallas, using some unrelated IP space provided by R= andy (198.180.152.0/2= 4).

When the IETF meeting finishes, one of the NOC people logs in and upd= ates the content of the file to list the next meeting location (so that the= geo-providers will update their locations). Note that whoever does this li= kely doesn't have easy access to the RPKI keys - it's quite common = for different=C2=A0sets of people to be publishing/updating the geo info th= an the routing security people.

Geolocation providers can get the IRR informa= tion, and follow the URL to grab the file. Note that the URL is hosted on c= ompletely different=C2=A0IP space, and the cert is whatever the cert for th= at machine happens to be. This could be hosted on any name/any address/etc.= We specify HTTPS (instead of HTTP) because it's best practice, not bec= ause of any sort of correlation, etc.=C2=A0

I'm unclear if I'm missin= g something, or if people are talking past each other, or what.

W



On Wed, May 5, 2021 at 10:54 AM Kyle Rose <krose@krose.org> wrote:
On Wed, May 5, 2021 at 10:49 AM Randy Bush &= lt;randy@psg.com>= wrote:
> the= web pki is not associated with ip address space control/ownership.
> web pki is based on control of domain name space.=C2=A0 the two are qu= ite
> unrelated.

note that the rpsl, the inetnum: objects, are not well secured and
authenticated.=C2=A0 this is a bit embarrassing.=C2=A0 and, in some regions= ,
the lack of authentication is notorious.

Okay, now we'r= e getting somewhere. Do you say this because RPKI is not employed universal= ly, or because the inetnum: objects are somehow not covered by RPKI?
=C2=A0
hence the hack to use the well-authenticated rpki to sign those data
covered by it for those concerned with real authenticity.
<= div>
How do= es a client know that an IP range specified in the geodata feed is valid un= der a given RPKI signature? I.e., that the given AS has authority over that= IP range?

=
Kyle
=


--
The computing scientist=E2=80= =99s main challenge is not to get confused by the
complexities of his ow= n making.
=C2=A0 -- E. W. Dijkstra
--000000000000bb5c7a05c1adff00-- From nobody Fri May 7 09:13:46 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 854B43A247C; Fri, 7 May 2021 09:13:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, 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=akamai.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 meQ8KrkRYTEp; Fri, 7 May 2021 09:13:30 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 F096E3A2011; Fri, 7 May 2021 09:13:29 -0700 (PDT) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 147GAuH2024379; Fri, 7 May 2021 17:13:18 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=w41SML2WKPuzLx0i4h8GB9h5GgKDHeqButvIQIh0oLE=; b=LhZ1RC1qJhrZW2+3/BrjvumTFVPkOER2XILjptDba66ZKFAhv/vBq0SukZRdqCfqnUd3 dOOj8+g+2T0RlPRjUOCOlIIMzZcrpx9dM2MwvYc6TbS9E1aAR/TSlK//nhSpkVk1f37M An76xuzELvMjqPEMhDlggRXokpqnulU/X/AEFwscnzV+/m1wTZDDVGfxdHGvBBxDJ8RI RlTXkPvKYf9wqDiEQSxrBQCQOfwJ5WduipnocSUde0PAvsOZFr9a/gGJOObC2NJf4M+T CZOrV4RwLXSwsnuU/MwgSQcqE9UAWkXyrU8iEy2tfEl5fyHqpT80FZU26B/oPNGji/Wc fA== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 38csrf6tvb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 07 May 2021 17:13:18 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.1.2/8.16.1.2) with SMTP id 147G58U9014099; Fri, 7 May 2021 12:13:16 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint1.akamai.com with ESMTP id 38ct85334m-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 07 May 2021 12:13:16 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 7 May 2021 12:13:16 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1497.012; Fri, 7 May 2021 12:13:15 -0400 From: "Salz, Rich" To: =?utf-8?B?R3VubmFyIEhlbGxzdHLDtm0=?= , "secdir@ietf.org" CC: "last-call@ietf.org" , "draft-ietf-avtcore-multi-party-rtt-mix.all@ietf.org" , "avt@ietf.org" Thread-Topic: [AVTCORE] Secdir last call review of draft-ietf-avtcore-multi-party-rtt-mix-16 Thread-Index: AQHXQ1gFdwCZnyD0G0WItRsxVbOVjKrYMRSA Date: Fri, 7 May 2021 16:13:15 +0000 Message-ID: References: <162031178943.8783.4063437681950995450@ietfa.amsl.com> <683ac9fe-b68f-3041-fff4-c26fef3767a8@ghaccess.se> In-Reply-To: <683ac9fe-b68f-3041-fff4-c26fef3767a8@ghaccess.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.49.21050201 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.27.164.43] Content-Type: multipart/alternative; boundary="_000_FF68D2FB7E524CBD9B632E787F1B8B47akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-05-07_06:2021-05-06, 2021-05-07 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 adultscore=0 phishscore=0 mlxlogscore=999 spamscore=0 bulkscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2105070109 X-Proofpoint-ORIG-GUID: hZwiAkU_VmG7q8b9O0WyIT0TKnH7GiGI X-Proofpoint-GUID: hZwiAkU_VmG7q8b9O0WyIT0TKnH7GiGI X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-05-07_06:2021-05-06, 2021-05-07 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 impostorscore=0 lowpriorityscore=0 clxscore=1011 adultscore=0 suspectscore=0 phishscore=0 mlxscore=0 mlxlogscore=999 priorityscore=1501 spamscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2105070109 X-Agari-Authentication-Results: mx.akamai.com; spf=${SPFResult} (sender IP is 184.51.33.18) smtp.mailfrom=rsalz@akamai.com smtp.helo=prod-mail-ppoint1 Archived-At: Subject: Re: [secdir] [AVTCORE] Secdir last call review of draft-ietf-avtcore-multi-party-rtt-mix-16 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2021 16:13:36 -0000 --_000_FF68D2FB7E524CBD9B632E787F1B8B47akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciB0aGUgZXhwbGFuYXRpb24gYW5kIHVwZGF0ZS4gIFlvdXIgdXBkYXRlZCBkcmFm dCBhZGRyZXNzZXMgbXkgY29uY2VybnMuICBQZXJoYXBzIDMuOSBzaG91bGQgaGF2ZSBhIGZvcndh cmQgbGluayB0byBTZWMgMTENCg0KRnJvbTogR3VubmFyIEhlbGxzdHLDtm0gPGd1bm5hci5oZWxs c3Ryb21AZ2hhY2Nlc3Muc2U+DQpEYXRlOiBGcmlkYXksIE1heSA3LCAyMDIxIGF0IDExOjQ1IEFN DQpUbzogUmljaCBTYWx6IDxyc2FsekBha2FtYWkuY29tPiwgInNlY2RpckBpZXRmLm9yZyIgPHNl Y2RpckBpZXRmLm9yZz4NCkNjOiAibGFzdC1jYWxsQGlldGYub3JnIiA8bGFzdC1jYWxsQGlldGYu b3JnPiwgImRyYWZ0LWlldGYtYXZ0Y29yZS1tdWx0aS1wYXJ0eS1ydHQtbWl4LmFsbEBpZXRmLm9y ZyIgPGRyYWZ0LWlldGYtYXZ0Y29yZS1tdWx0aS1wYXJ0eS1ydHQtbWl4LmFsbEBpZXRmLm9yZz4s ICJhdnRAaWV0Zi5vcmciIDxhdnRAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0FWVENPUkVdIFNl Y2RpciBsYXN0IGNhbGwgcmV2aWV3IG9mIGRyYWZ0LWlldGYtYXZ0Y29yZS1tdWx0aS1wYXJ0eS1y dHQtbWl4LTE2DQoNCg0KUmljaCwNCg0KVGhhbmtzIGZvciB0aGUgcmV2aWV3Lg0KDQpJIGFtIGNv bXBvc2luZyBhIG5ldyB2ZXJzaW9uIGJlY2F1c2Ugb2YgdGhlIEdlbi1BUlQgcmV2aWV3LCBhbmQg d2FudCB0byBwcm9wb3NlIGNoYW5nZXMgdG8gc2F0aXNmeSB5b3VyIGNvbW1lbnRzLg0KDQpZb3Ug YXNrIGlmIGl0IGlzIGNvbW1vbiB0byBoYXZlIHRoZSBtaXhlcnMgYmVpbmcgdHJ1c3RlZC4NCg0K SW4gdGhlIGV4cGVjdGVkIGZpcnN0IGltcGxlbWVudGF0aW9uIGVudmlyb25tZW50cyBmb3IgdGhp cyBkcmFmdCwgaXQgaXMuIFRoYXQgaXMgaW4gZW1lcmdlbmN5IHNlcnZpY2UgbmV0d29ya3MuIEFs c28gaW4gcGVyc29uYWwgY29tbXVuaWNhdGlvbiBzZXJ2aWNlcyBpdCBpcy4NCg0KVGhlIGZpcnN0 IGltcGxlbWVudGF0aW9uIGVudmlyb25tZW50cyBhcmUgYWxzbyBleHBlY3RlZCB0byB1c2UgdGhl IFNJUCBjZW50cmFsaXplZCBjb25mZXJlbmNlIG1vZGVsIChSRkMgNDM1MyBldGMuKSB3aGVyZSBh bGwgbWVkaWEgYXJlIGV4cGVjdGVkIHRvIGJlIG1peGVkIGNlbnRyYWxseS4gVGh1cyB0aGUgc2Vj dXJpdHkgYXNwZWN0cyB3b3VsZCBiZSBzaW1pbGFyIGZvciBhdWRpbywgdmlkZW8gYW5kIHJlYWwt dGltZSB0ZXh0Lg0KDQpJIGhhdmUgdHJpZWQgdG8gZWxhYm9yYXRlIGEgYml0IG1vcmUgb24gdGhp cyBpbiBhIG1vZGlmaWVkIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHNlY3Rpb24sIGN1cnJlbnRs eSBsb29raW5nIGxpa2UgdGhpcyBhbmQgYmVpbmcgcmVhZHkgZm9yIHN1Ym1pc3Npb24gdG9nZXRo ZXIgd2l0aCB0aGUgY2hhbmdlcyBiZWNhdXNlIG9mIHRoZSBHZW4tQVJUIHJldmlldy4gV291bGQg dGhpcyBzYXRpc2Z5IHlvdXIgY29uY2VybnM/DQoNCi0tLS0tLS0tUHJvcG9zZWQgc2VjdXJpdHkg Y29uY2VybnMtLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoxMS4gIFNlY3VyaXR5IENvbnNpZGVyYXRp b25zDQoNCg0KDQogICBUaGUgUlRQLW1peGVyIG1vZGVsIHJlcXVpcmVzIHRoZSBtaXhlciB0byBi ZSBhbGxvd2VkIHRvIGRlY3J5cHQsDQoNCiAgIHBhY2ssIGFuZCBlbmNyeXB0IHNlY3VyZWQgdGV4 dCBmcm9tIHRoZSBjb25mZXJlbmNlIHBhcnRpY2lwYW50cy4NCg0KICAgVGhlcmVmb3JlIHRoZSBt aXhlciBuZWVkcyB0byBiZSB0cnVzdGVkIHRvIGFjaGlldmUgc2VjdXJpdHkgaW4NCg0KICAgY29u ZmlkZW50aWFsaXR5IGFuZCBpbnRlZ3JpdHkuICBUaGlzIHNpdHVhdGlvbiBpcyBzaW1pbGFyIHRv IHRoZQ0KDQogICBzaXR1YXRpb24gZm9yIGhhbmRsaW5nIGF1ZGlvIGFuZCB2aWRlbyBtZWRpYSBp biBjZW50cmFsaXplZCBtaXhlcnMuDQoNCg0KDQogICBUaGUgcmVxdWlyZW1lbnQgdG8gdHJhbnNm ZXIgaW5mb3JtYXRpb24gYWJvdXQgdGhlIHVzZXIgaW4gUlRDUA0KDQogICByZXBvcnRzIGluIFNE RVMsIENOQU1FLCBhbmQgTkFNRSBmaWVsZHMsIGFuZCBpbiBjb25mZXJlbmNlDQoNCiAgIG5vdGlm aWNhdGlvbnMsIGZvciBjcmVhdGlvbiBvZiBsYWJlbHMgbWF5IGhhdmUgcHJpdmFjeSBjb25jZXJu cyBhcw0KDQogICBhbHJlYWR5IHN0YXRlZCBpbiBSRkMgMzU1MCBbUkZDMzU1MF0sIGFuZCBtYXkg YmUgcmVzdHJpY3RlZCBmb3INCg0KICAgcHJpdmFjeSByZWFzb25zLiAgVGhlIHJlY2VpdmluZyB1 c2VyIHdpbGwgdGhlbiBnZXQgYSBtb3JlIHN5bWJvbGljDQoNCiAgIGxhYmVsIGZvciB0aGUgc291 cmNlLg0KDQoNCg0KICAgUGFydGljaXBhbnRzIHdpdGggbWFsaWNpb3VzIGludGVudGlvbnMgbWF5 IGFwcGVhciBhbmQgZS5nLiwgZGlzdHVyYg0KDQogICB0aGUgbXVsdGlwYXJ0eSBzZXNzaW9uIGJ5 IGVtaXR0aW5nIGEgY29udGludW91cyBmbG93IG9mIHRleHQuICBUaGV5DQoNCiAgIG1heSBhbHNv IHNlbmQgdGV4dCB0aGF0IGFwcGVhcnMgdG8gb3JpZ2luYXRlIGZyb20gb3RoZXIgcGFydGljaXBh bnRzLg0KDQogICBDb3VudGVyYWN0aW9ucyBzaG91bGQgYmUgdG8gcmVxdWlyZSBzZWN1cmUgc2ln bmFsaW5nLCBtZWRpYSBhbmQNCg0KICAgYXV0aGVudGljYXRpb24sIGFuZCB0byBwcm92aWRlIGhp Z2hlciBsZXZlbCBjb25mZXJlbmNlIGZ1bmN0aW9ucw0KDQogICBlLmcuLCBmb3IgYmxvY2tpbmcs IG11dGluZywgYW5kIGV4cGVsbGluZyBwYXJ0aWNpcGFudHMuDQoNCg0KDQogICBGdXJ0aGVyIHNl Y3VyaXR5IGNvbnNpZGVyYXRpb25zIHNwZWNpZmljIGZvciB0aGlzIGFwcGxpY2F0aW9uIGFyZQ0K DQogICBzcGVjaWZpZWQgaW4gU2VjdGlvbiAzLjE5Lg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg0KDQpSZWdhcmRzDQoNCg0K DQpHdW5uYXINCg0KLS0NCg0KR3VubmFyIEhlbGxzdHLDtm0NCg0KR0hBY2Nlc3MNCg0KZ3VubmFy LmhlbGxzdHJvbUBnaGFjY2Vzcy5zZTxtYWlsdG86Z3VubmFyLmhlbGxzdHJvbUBnaGFjY2Vzcy5z ZT4NCkRlbiAyMDIxLTA1LTA2IGtsLiAxNjozNiwgc2tyZXYgUmljaCBTYWx6IHZpYSBEYXRhdHJh Y2tlcjoNCg0KUmV2aWV3ZXI6IFJpY2ggU2Fseg0KDQpSZXZpZXcgcmVzdWx0OiBSZWFkeQ0KDQoN Cg0KVGhpcyByZXZpZXcgaXMgZm9yIHRoZSBiZW5lZml0IG9mIHRoZSBTZWN1cml0eSBBRCdzLiBO b2JvZHkgZWxzZSBzaG91bGQgcmVhZA0KDQp0aGlzLiBPciwgaWYgeW91IHJlYWQgaXQsIHRyZWF0 IGl0IGFzIGFueSBvdGhlciBsYXN0IGNhbGwgcmV2aWV3IDopDQoNCg0KDQpJIGtub3cgdmVyeSBs aXR0bGUgYWJvdXQgV2ViUlRDLCBBVlQsIGV0Yy4NCg0KDQoNCkkgdGhvdWdodCBTZWN0aW9uIDEu Miwgc3VtbWFyeSBvZiB0aGUgYWx0ZXJuYXRpdmVzLCB3YXMgZ3JlYXQuIEkgd2lzaCBtb3JlDQoN CmRvY3VtZW50cyBkaWQgdGhpcyBraW5kIG9mIHRoaW5nLiBBbmQgc2ltaWxhciBmb3IgYWxsIG9m IHNlY3Rpb24gMi4gVGhlIGRldGFpbHMNCg0KaW4gU2VjdGlvbiAzIGFib3V0IGhvdyB0byBjb21w bHkgc2VlbSB2ZXJ5IGNsZWFyLiBJZiBJIHdlcmUgaW1wbGVtZW50aW5nIHRoaXMsDQoNCkkgY291 bGQgdXNlIGVhc2lseSB1c2UgdGhpcyBhcyBhIGNoZWNrbGlzdCBhbmQgdGVzdCBzdWl0ZS4gU2Vj dGlvbiAzLjE5IGlzIHRoZQ0KDQptb3N0IGltcG9ydGFudCBvbmUgZm9yIHRyYW5zcG9ydCBzZWN1 cml0eS4gTm90IGtub3dpbmcgdGhlIG9wZXJhdGluZw0KDQplbnZpcm9ubWVudHMsIGl0IHNlZW1z IHJlYXNvbmFibGUuDQoNCg0KDQpUaGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2VlbXMgYSBs aXR0bGUgc2NhbnQsIGdpdmVuIHRoZSBvcHBvcnR1bml0eSBmb3INCg0KcHJpdmFjeSBjb25jZXJu cyBvZiBwYXJ0aWNpcGFudHMgYW5kIGZvciBpbnRydWRlcnMgdG8gZGlzcnVwdCBjYWxscy4gSXMg aXQNCg0KY29tbW9uIHRoYXQgdGhlIG1peGVyIGlzIGEgdHJ1c3RlZCBlbnRpdHk/IEEgc3RhdGVt ZW50IG9uIHRoYXQgZWl0aGVyIHdheSB3b3VsZA0KDQpiZSB1c2VmdWwuDQoNCg0KDQoNCg0KDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkF1ZGlv L1ZpZGVvIFRyYW5zcG9ydCBDb3JlIE1haW50ZW5hbmNlDQoNCmF2dEBpZXRmLm9yZzxtYWlsdG86 YXZ0QGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2F2 dDxodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6L3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2F2dF9fOyEhR2p2VHpfdmshQ2hOUF80QzhfLUlHOWxFcS1MRGw5MzB3OWk5YjhH WUlscGNGb0JwMW5VSzdMR3hPNzhRMGhYeXFyN1FUJD4NCg0KLS0NCg0KR3VubmFyIEhlbGxzdHLD tm0NCg0KR0hBY2Nlc3MNCg0KZ3VubmFyLmhlbGxzdHJvbUBnaGFjY2Vzcy5zZTxtYWlsdG86Z3Vu bmFyLmhlbGxzdHJvbUBnaGFjY2Vzcy5zZT4NCg== --_000_FF68D2FB7E524CBD9B632E787F1B8B47akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <9F27AD31ABB79646BFA5A7DB4EB6C620@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFz Ow0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hh ciI7DQoJbWFyZ2luOjBpbjsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToi SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6IkNvbnNvbGFzIixz ZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBs eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0 O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0K CW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1V UyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSIgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3Jk Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFu a3MgZm9yIHRoZSBleHBsYW5hdGlvbiBhbmQgdXBkYXRlLiZuYnNwOyBZb3VyIHVwZGF0ZWQgZHJh ZnQgYWRkcmVzc2VzIG15IGNvbmNlcm5zLiZuYnNwOyBQZXJoYXBzIDMuOSBzaG91bGQgaGF2ZSBh IGZvcndhcmQgbGluayB0byBTZWMgMTE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6 YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29s b3I6YmxhY2siPkd1bm5hciBIZWxsc3Ryw7ZtICZsdDtndW5uYXIuaGVsbHN0cm9tQGdoYWNjZXNz LnNlJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5GcmlkYXksIE1heSA3LCAyMDIxIGF0IDExOjQ1IEFN PGJyPg0KPGI+VG86IDwvYj5SaWNoIFNhbHogJmx0O3JzYWx6QGFrYW1haS5jb20mZ3Q7LCAmcXVv dDtzZWNkaXJAaWV0Zi5vcmcmcXVvdDsgJmx0O3NlY2RpckBpZXRmLm9yZyZndDs8YnI+DQo8Yj5D YzogPC9iPiZxdW90O2xhc3QtY2FsbEBpZXRmLm9yZyZxdW90OyAmbHQ7bGFzdC1jYWxsQGlldGYu b3JnJmd0OywgJnF1b3Q7ZHJhZnQtaWV0Zi1hdnRjb3JlLW11bHRpLXBhcnR5LXJ0dC1taXguYWxs QGlldGYub3JnJnF1b3Q7ICZsdDtkcmFmdC1pZXRmLWF2dGNvcmUtbXVsdGktcGFydHktcnR0LW1p eC5hbGxAaWV0Zi5vcmcmZ3Q7LCAmcXVvdDthdnRAaWV0Zi5vcmcmcXVvdDsgJmx0O2F2dEBpZXRm Lm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtBVlRDT1JFXSBTZWNkaXIgbGFzdCBj YWxsIHJldmlldyBvZiBkcmFmdC1pZXRmLWF2dGNvcmUtbXVsdGktcGFydHktcnR0LW1peC0xNjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cD5SaWNoLDxvOnA+PC9vOnA+PC9wPg0K PHA+VGhhbmtzIGZvciB0aGUgcmV2aWV3LjxvOnA+PC9vOnA+PC9wPg0KPHA+SSBhbSBjb21wb3Np bmcgYSBuZXcgdmVyc2lvbiBiZWNhdXNlIG9mIHRoZSBHZW4tQVJUIHJldmlldywgYW5kIHdhbnQg dG8gcHJvcG9zZSBjaGFuZ2VzIHRvIHNhdGlzZnkgeW91ciBjb21tZW50cy4NCjxvOnA+PC9vOnA+ PC9wPg0KPHA+WW91IGFzayBpZiBpdCBpcyBjb21tb24gdG8gaGF2ZSB0aGUgbWl4ZXJzIGJlaW5n IHRydXN0ZWQuIDxvOnA+PC9vOnA+PC9wPg0KPHA+SW4gdGhlIGV4cGVjdGVkIGZpcnN0IGltcGxl bWVudGF0aW9uIGVudmlyb25tZW50cyBmb3IgdGhpcyBkcmFmdCwgaXQgaXMuIFRoYXQgaXMgaW4g ZW1lcmdlbmN5IHNlcnZpY2UgbmV0d29ya3MuIEFsc28gaW4gcGVyc29uYWwgY29tbXVuaWNhdGlv biBzZXJ2aWNlcyBpdCBpcy48bzpwPjwvbzpwPjwvcD4NCjxwPlRoZSBmaXJzdCBpbXBsZW1lbnRh dGlvbiBlbnZpcm9ubWVudHMgYXJlIGFsc28gZXhwZWN0ZWQgdG8gdXNlIHRoZSBTSVAgY2VudHJh bGl6ZWQgY29uZmVyZW5jZSBtb2RlbCAoUkZDIDQzNTMgZXRjLikgd2hlcmUgYWxsIG1lZGlhIGFy ZSBleHBlY3RlZCB0byBiZSBtaXhlZCBjZW50cmFsbHkuIFRodXMgdGhlIHNlY3VyaXR5IGFzcGVj dHMgd291bGQgYmUgc2ltaWxhciBmb3IgYXVkaW8sIHZpZGVvIGFuZCByZWFsLXRpbWUgdGV4dC4N CjxvOnA+PC9vOnA+PC9wPg0KPHA+SSBoYXZlIHRyaWVkIHRvIGVsYWJvcmF0ZSBhIGJpdCBtb3Jl IG9uIHRoaXMgaW4gYSBtb2RpZmllZCBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uLCBj dXJyZW50bHkgbG9va2luZyBsaWtlIHRoaXMgYW5kIGJlaW5nIHJlYWR5IGZvciBzdWJtaXNzaW9u IHRvZ2V0aGVyIHdpdGggdGhlIGNoYW5nZXMgYmVjYXVzZSBvZiB0aGUgR2VuLUFSVCByZXZpZXcu IFdvdWxkIHRoaXMgc2F0aXNmeSB5b3VyIGNvbmNlcm5zPzxvOnA+PC9vOnA+PC9wPg0KPHA+LS0t LS0tLS1Qcm9wb3NlZCBzZWN1cml0eSBjb25jZXJucy0tLS0tLS0tLS0tLS0tLS0tLS0tPG86cD48 L286cD48L3A+DQo8cHJlIHN0eWxlPSJmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7Zm9u dC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiAyO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dz OiAyOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt0ZXh0LWRlY29yYXRpb24tdGhpY2tu ZXNzOiBpbml0aWFsO3RleHQtZGVjb3JhdGlvbi1zdHlsZTogaW5pdGlhbDt0ZXh0LWRlY29yYXRp b24tY29sb3I6IGluaXRpYWw7b3ZlcmZsb3ctd3JhcDogYnJlYWstd29yZDt3aGl0ZS1zcGFjZTpw cmUtd3JhcDt3b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjExLiZu YnNwOyBTZWN1cml0eSBDb25zaWRlcmF0aW9uczxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy ZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBUaGUgUlRQLW1p eGVyIG1vZGVsIHJlcXVpcmVzIHRoZSBtaXhlciB0byBiZSBhbGxvd2VkIHRvIGRlY3J5cHQsPG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5i c3A7Jm5ic3A7IHBhY2ssIGFuZCBlbmNyeXB0IHNlY3VyZWQgdGV4dCBmcm9tIHRoZSBjb25mZXJl bmNlIHBhcnRpY2lwYW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgVGhlcmVmb3JlIHRoZSBtaXhlciBuZWVkcyB0 byBiZSB0cnVzdGVkIHRvIGFjaGlldmUgc2VjdXJpdHkgaW48bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgY29uZmlkZW50 aWFsaXR5IGFuZCBpbnRlZ3JpdHkuJm5ic3A7IFRoaXMgc2l0dWF0aW9uIGlzIHNpbWlsYXIgdG8g dGhlPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+Jm5ic3A7Jm5ic3A7IHNpdHVhdGlvbiBmb3IgaGFuZGxpbmcgYXVkaW8gYW5kIHZpZGVvIG1l ZGlhIGluIGNlbnRyYWxpemVkIG1peGVycy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgVGhlIHJlcXVpcmVt ZW50IHRvIHRyYW5zZmVyIGluZm9ybWF0aW9uIGFib3V0IHRoZSB1c2VyIGluIFJUQ1A8bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsm bmJzcDsgcmVwb3J0cyBpbiBTREVTLCBDTkFNRSwgYW5kIE5BTUUgZmllbGRzLCBhbmQgaW4gY29u ZmVyZW5jZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPiZuYnNwOyZuYnNwOyBub3RpZmljYXRpb25zLCBmb3IgY3JlYXRpb24gb2YgbGFiZWxz IG1heSBoYXZlIHByaXZhY3kgY29uY2VybnMgYXM8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw cmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgYWxyZWFkeSBzdGF0ZWQg aW4gUkZDIDM1NTAgW1JGQzM1NTBdLCBhbmQgbWF5IGJlIHJlc3RyaWN0ZWQgZm9yPG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5i c3A7IHByaXZhY3kgcmVhc29ucy4mbmJzcDsgVGhlIHJlY2VpdmluZyB1c2VyIHdpbGwgdGhlbiBn ZXQgYSBtb3JlIHN5bWJvbGljPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGxhYmVsIGZvciB0aGUgc291cmNlLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PiZuYnNwOyZuYnNwOyBQYXJ0aWNpcGFudHMgd2l0aCBtYWxpY2lvdXMgaW50ZW50aW9ucyBtYXkg YXBwZWFyIGFuZCBlLmcuLCBkaXN0dXJiPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IHRoZSBtdWx0aXBhcnR5IHNlc3Np b24gYnkgZW1pdHRpbmcgYSBjb250aW51b3VzIGZsb3cgb2YgdGV4dC4mbmJzcDsgVGhleTxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNw OyZuYnNwOyBtYXkgYWxzbyBzZW5kIHRleHQgdGhhdCBhcHBlYXJzIHRvIG9yaWdpbmF0ZSBmcm9t IG90aGVyIHBhcnRpY2lwYW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgQ291bnRlcmFjdGlvbnMgc2hvdWxkIGJl IHRvIHJlcXVpcmUgc2VjdXJlIHNpZ25hbGluZywgbWVkaWEgYW5kPG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGF1dGhl bnRpY2F0aW9uLCBhbmQgdG8gcHJvdmlkZSBoaWdoZXIgbGV2ZWwgY29uZmVyZW5jZSBmdW5jdGlv bnM8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij4mbmJzcDsmbmJzcDsgZS5nLiwgZm9yIGJsb2NraW5nLCBtdXRpbmcsIGFuZCBleHBlbGxpbmcg cGFydGljaXBhbnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBGdXJ0aGVyIHNlY3VyaXR5IGNvbnNpZGVy YXRpb25zIHNwZWNpZmljIGZvciB0aGlzIGFwcGxpY2F0aW9uIGFyZTxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBzcGVj aWZpZWQgaW4gU2VjdGlvbiAzLjE5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw cmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5SZWdhcmRzPG86cD48L286cD48L3NwYW4+PC9w cmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wcmU+DQo8cD5HdW5uYXI8bzpwPjwvbzpwPjwvcD4NCjxwcmU+LS0gPG86cD48L286cD48 L3ByZT4NCjxwcmU+R3VubmFyIEhlbGxzdHLDtm08bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5HSEFj Y2VzczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Im1haWx0bzpndW5uYXIuaGVsbHN0 cm9tQGdoYWNjZXNzLnNlIj5ndW5uYXIuaGVsbHN0cm9tQGdoYWNjZXNzLnNlPC9hPjxvOnA+PC9v OnA+PC9wcmU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RGVuIDIwMjEtMDUtMDYga2wu IDE2OjM2LCBza3JldiBSaWNoIFNhbHogdmlhIERhdGF0cmFja2VyOjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxwcmU+UmV2aWV3ZXI6IFJpY2ggU2FsejxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PlJldmlldyByZXN1bHQ6IFJlYWR5PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8 L286cD48L3ByZT4NCjxwcmU+VGhpcyByZXZpZXcgaXMgZm9yIHRoZSBiZW5lZml0IG9mIHRoZSBT ZWN1cml0eSBBRCdzLiBOb2JvZHkgZWxzZSBzaG91bGQgcmVhZDxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPnRoaXMuIE9yLCBpZiB5b3UgcmVhZCBpdCwgdHJlYXQgaXQgYXMgYW55IG90aGVyIGxhc3Qg Y2FsbCByZXZpZXcgOik8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwv cHJlPg0KPHByZT5JIGtub3cgdmVyeSBsaXR0bGUgYWJvdXQgV2ViUlRDLCBBVlQsIGV0Yy48bzpw PjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5JIHRob3Vn aHQgU2VjdGlvbiAxLjIsIHN1bW1hcnkgb2YgdGhlIGFsdGVybmF0aXZlcywgd2FzIGdyZWF0LiBJ IHdpc2ggbW9yZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmRvY3VtZW50cyBkaWQgdGhpcyBraW5k IG9mIHRoaW5nLiBBbmQgc2ltaWxhciBmb3IgYWxsIG9mIHNlY3Rpb24gMi4gVGhlIGRldGFpbHM8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5pbiBTZWN0aW9uIDMgYWJvdXQgaG93IHRvIGNvbXBseSBz ZWVtIHZlcnkgY2xlYXIuIElmIEkgd2VyZSBpbXBsZW1lbnRpbmcgdGhpcyw8bzpwPjwvbzpwPjwv cHJlPg0KPHByZT5JIGNvdWxkIHVzZSBlYXNpbHkgdXNlIHRoaXMgYXMgYSBjaGVja2xpc3QgYW5k IHRlc3Qgc3VpdGUuIFNlY3Rpb24gMy4xOSBpcyB0aGU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5t b3N0IGltcG9ydGFudCBvbmUgZm9yIHRyYW5zcG9ydCBzZWN1cml0eS4gTm90IGtub3dpbmcgdGhl IG9wZXJhdGluZzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmVudmlyb25tZW50cywgaXQgc2VlbXMg cmVhc29uYWJsZS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJl Pg0KPHByZT5UaGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2VlbXMgYSBsaXR0bGUgc2NhbnQs IGdpdmVuIHRoZSBvcHBvcnR1bml0eSBmb3I8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5wcml2YWN5 IGNvbmNlcm5zIG9mIHBhcnRpY2lwYW50cyBhbmQgZm9yIGludHJ1ZGVycyB0byBkaXNydXB0IGNh bGxzLiBJcyBpdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmNvbW1vbiB0aGF0IHRoZSBtaXhlciBp cyBhIHRydXN0ZWQgZW50aXR5PyBBIHN0YXRlbWVudCBvbiB0aGF0IGVpdGhlciB3YXkgd291bGQ8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5iZSB1c2VmdWwuPG86cD48L286cD48L3ByZT4NCjxwcmU+ PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxw cmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5BdWRpby9WaWRl byBUcmFuc3BvcnQgQ29yZSBNYWludGVuYW5jZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhy ZWY9Im1haWx0bzphdnRAaWV0Zi5vcmciPmF2dEBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT48YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6L3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2F2dF9fOyEhR2p2VHpfdmshQ2hOUF80QzhfLUlHOWxF cS1MRGw5MzB3OWk5YjhHWUlscGNGb0JwMW5VSzdMR3hPNzhRMGhYeXFyN1FUJCI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hdnQ8L2E+PG86cD48L286cD48L3ByZT4NCjwv YmxvY2txdW90ZT4NCjxwcmU+LS0gPG86cD48L286cD48L3ByZT4NCjxwcmU+R3VubmFyIEhlbGxz dHLDtm08bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5HSEFjY2VzczxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPjxhIGhyZWY9Im1haWx0bzpndW5uYXIuaGVsbHN0cm9tQGdoYWNjZXNzLnNlIj5ndW5uYXIu aGVsbHN0cm9tQGdoYWNjZXNzLnNlPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_FF68D2FB7E524CBD9B632E787F1B8B47akamaicom_-- From nobody Fri May 7 11:15:37 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68D873A2CC2; Fri, 7 May 2021 11:15:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.433 X-Spam-Level: X-Spam-Status: No, score=-1.433 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net 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 ZZe_vNrYetmi; Fri, 7 May 2021 11:15:26 -0700 (PDT) Received: from mail-ssdrsserver2.hosting.co.uk (mail-ssdrsserver2.hosting.co.uk [185.185.85.90]) (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 967CB3A2CBF; Fri, 7 May 2021 11:15:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:Cc:From:References:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=1vHPgDu2PuT8lebqOYaQa3fuG+8Hq2eR8oCNDWs1tV0=; b=k28eaoqfljnyqNUtGMAy7ptcbi YZhcRxQohr6o80iFHlinB8mkDfvU0N+QmkTngQzW0WTYv/Jxj8iaLrqBWRXCvaTeKxqJVYunNCdwM GXt2zQBvVGEIwZwRRrR1R3Rrdino5S5V0wKVyLSYluEfAxMvgnHhp7RLFRAWy9B6q5Cu25mDMugb9 +2c/0kqQPesU/+Oxyuvf3HqvJED45XKpTm5nmZq9XM71CxD1rvxPPIpC3aDk+Hos+hv6UYwKBsolF pd5xOGiHbNgx4C0ham24XxWi7EfxNLMe+9pmNovT0+yzGYw+Vd9UzKvaYsqer6VZwwqqgG+w2qN34 ixVQaYCQ==; Received: from 67.153.238.178.in-addr.arpa ([178.238.153.67]:34382 helo=[192.168.1.11]) by ssdrsserver2.hosting.co.uk with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1lf50Y-0002zz-TI; Fri, 07 May 2021 19:15:24 +0100 To: "Scott G. Kelly" References: <1618272203.965227355@apps.rackspace.com> From: Bob Briscoe Cc: draft-ietf-tcpm-accurate-ecn.all@ietf.org, "iesg@ietf.org" , "secdir@ietf.org" Message-ID: <16c048ca-e027-a1bb-0d06-22260f87139b@bobbriscoe.net> Date: Fri, 7 May 2021 19:15:22 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <1618272203.965227355@apps.rackspace.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ssdrsserver2.hosting.co.uk X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: ssdrsserver2.hosting.co.uk: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: ssdrsserver2.hosting.co.uk: in@bobbriscoe.net X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-tcpm-accurate-ecn-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2021 18:15:31 -0000 Scott, A belated thank you for your review. Sorry, I've been head down preparing a draft for an interim in another WG on Monday, which I just submitted. On 13/04/2021 01:03, Scott G. Kelly wrote: > I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. > > The summary of the review is Almost Ready. > > The title of this draft is, "More Accurate ECN Feedback in TCP". The document specifies a scheme (abbreviated AccECN) to provide more than one feedback signal per RTT in the TCP header. It does this by allocating a reserved header bit that was previously used for the ECN-Nonce (which has now been declared historic), and it overloads the two existing ECN flags in the TCP header. > > I'm not a TCP or ECN expert, so please take my comments with a proverbial grain of salt. Thinking about this strictly as a security geek, I see three places where this scheme could be tampered with: the sender, the receiver, and the network in between them. > > The security considerations section starts off by pointing out that there will be consequences to tampering by a middlebox (the network in between), and it describes the impact as limited. > > A malicious sender is not described, and I'm not sure that any such thing reasonably exists, but I did wonder about this. [BB] A malicious sender is not described because the scope of AccECN is purely about changes to TCP's feedback protocol between Data Receiver and Data Sender. Malicious senders can ignore TCP feedback. So it doesn't matter what we say when we update a feedback spec if malicious senders can ignore the feedback anyway. Incidentally, AFAIK, the only approach that has ever addressed the problem of ensuring the sender responds correctly to congestion feedback is the IETF's Congestion Exposure (ConEx) protocol, which the draft already cites in two contexts (both because ConEx also ensures the receiver has to feed back congestion indications honestly, and because ConEx needs AccECN to work correctly). Do you think I ought to add this point to the Security Considerations? > > A malicious receiver (who might be motivated to interfere with AccECN in order to increase its own throughput at the expense of others) is described, and the reader is referred to section 5.3, which describes 3 different potential mitigations for this. There is also mention of the fact that the receiver might simply omit the option, pretending it had been stripped by a middlebox, but there is no known consequence (other than downgrading to plain ECN). > > There is a TODO in the security considerations which must be addressed (referring to a potential covert channel), and that's why the review summary is "Almost Ready". I suggest that the security AD might want someone both TCP and security expertise to evaluate this. [BB] There might have been something lost in translation when the request for a SECDIR review was placed. The text in curly braces here was intended to be a message to the SECDIR reviewer about what we were most seeking guidance on. But I think you're right when you say this needs someone with both TCP and Security expertise (I have both, but I'm an author). I think the tcpm chairs have this in hand - I don't think you need to do anything further. Thank you again. Bob > > > --Scott > > -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ From nobody Sat May 8 08:10:11 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A83C3A2732; Fri, 7 May 2021 08:45:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=egensajt.se 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 OeGRcKfDI8sJ; Fri, 7 May 2021 08:45:46 -0700 (PDT) Received: from smtp.egensajt.se (smtp.egensajt.se [193.42.159.246]) (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 39F193A2707; Fri, 7 May 2021 08:45:46 -0700 (PDT) Received: from [192.168.2.137] (h77-53-37-81.cust.a3fiber.se [77.53.37.81]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: gunnar.hellstrom@ghaccess.se) by smtp.egensajt.se (Postfix) with ESMTPSA id 2F951202E6; Fri, 7 May 2021 17:45:29 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=egensajt.se; s=dkim; t=1620402329; bh=aBAHJDy+SfWScR2XtSA1GJ6pB+95raK69GMCkTtfhsw=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=NKM/TJTI+6DaWJQ5aa01JNOgl2OaHWNLzJGQ5ATHxwaTVYADubGr75moPTCrWd1yG bZ9L0LzvaCrqbFXOe59eSvMQGNQtNT4Qreazb8bWdoaiAOjvJ+XN8x03PXgsZBGzr2 SvSMIIJ6JzgcZ12sGojRuWJvZl5DJx8HHkckr2q0= To: Rich Salz , secdir@ietf.org Cc: last-call@ietf.org, draft-ietf-avtcore-multi-party-rtt-mix.all@ietf.org, avt@ietf.org References: <162031178943.8783.4063437681950995450@ietfa.amsl.com> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <683ac9fe-b68f-3041-fff4-c26fef3767a8@ghaccess.se> Date: Fri, 7 May 2021 17:45:28 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: <162031178943.8783.4063437681950995450@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------CE9D9C7C43DF755520DB6DEC" Content-Language: sv Archived-At: X-Mailman-Approved-At: Sat, 08 May 2021 08:10:08 -0700 Subject: Re: [secdir] [AVTCORE] Secdir last call review of draft-ietf-avtcore-multi-party-rtt-mix-16 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2021 15:46:02 -0000 This is a multi-part message in MIME format. --------------CE9D9C7C43DF755520DB6DEC Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Rich, Thanks for the review. I am composing a new version because of the Gen-ART review, and want to propose changes to satisfy your comments. You ask if it is common to have the mixers being trusted. In the expected first implementation environments for this draft, it is. That is in emergency service networks. Also in personal communication services it is. The first implementation environments are also expected to use the SIP centralized conference model (RFC 4353 etc.) where all media are expected to be mixed centrally. Thus the security aspects would be similar for audio, video and real-time text. I have tried to elaborate a bit more on this in a modified security considerations section, currently looking like this and being ready for submission together with the changes because of the Gen-ART review. Would this satisfy your concerns? --------Proposed security concerns-------------------- 11. Security Considerations The RTP-mixer model requires the mixer to be allowed to decrypt, pack, and encrypt secured text from the conference participants. Therefore the mixer needs to be trusted to achieve security in confidentiality and integrity. This situation is similar to the situation for handling audio and video media in centralized mixers. The requirement to transfer information about the user in RTCP reports in SDES, CNAME, and NAME fields, and in conference notifications, for creation of labels may have privacy concerns as already stated in RFC 3550 [RFC3550], and may be restricted for privacy reasons. The receiving user will then get a more symbolic label for the source. Participants with malicious intentions may appear and e.g., disturb the multiparty session by emitting a continuous flow of text. They may also send text that appears to originate from other participants. Counteractions should be to require secure signaling, media and authentication, and to provide higher level conference functions e.g., for blocking, muting, and expelling participants. Further security considerations specific for this application are specified in Section 3.19. ---------------------------------------------------------- Regards Gunnar -- Gunnar Hellstrm GHAccess gunnar.hellstrom@ghaccess.se Den 2021-05-06 kl. 16:36, skrev Rich Salz via Datatracker: > Reviewer: Rich Salz > Review result: Ready > > This review is for the benefit of the Security AD's. Nobody else should read > this. Or, if you read it, treat it as any other last call review :) > > I know very little about WebRTC, AVT, etc. > > I thought Section 1.2, summary of the alternatives, was great. I wish more > documents did this kind of thing. And similar for all of section 2. The details > in Section 3 about how to comply seem very clear. If I were implementing this, > I could use easily use this as a checklist and test suite. Section 3.19 is the > most important one for transport security. Not knowing the operating > environments, it seems reasonable. > > The security considerations seems a little scant, given the opportunity for > privacy concerns of participants and for intruders to disrupt calls. Is it > common that the mixer is a trusted entity? A statement on that either way would > be useful. > > > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt -- Gunnar Hellstrm GHAccess gunnar.hellstrom@ghaccess.se --------------CE9D9C7C43DF755520DB6DEC Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Rich,

Thanks for the review.

I am composing a new version because of the Gen-ART review, and want to propose changes to satisfy your comments.

You ask if it is common to have the mixers being trusted.

In the expected first implementation environments for this draft, it is. That is in emergency service networks. Also in personal communication services it is.

The first implementation environments are also expected to use the SIP centralized conference model (RFC 4353 etc.) where all media are expected to be mixed centrally. Thus the security aspects would be similar for audio, video and real-time text.

I have tried to elaborate a bit more on this in a modified security considerations section, currently looking like this and being ready for submission together with the changes because of the Gen-ART review. Would this satisfy your concerns?

--------Proposed security concerns--------------------

11.  Security Considerations

   The RTP-mixer model requires the mixer to be allowed to decrypt,
   pack, and encrypt secured text from the conference participants.
   Therefore the mixer needs to be trusted to achieve security in
   confidentiality and integrity.  This situation is similar to the
   situation for handling audio and video media in centralized mixers.

   The requirement to transfer information about the user in RTCP
   reports in SDES, CNAME, and NAME fields, and in conference
   notifications, for creation of labels may have privacy concerns as
   already stated in RFC 3550 [RFC3550], and may be restricted for
   privacy reasons.  The receiving user will then get a more symbolic
   label for the source.

   Participants with malicious intentions may appear and e.g., disturb
   the multiparty session by emitting a continuous flow of text.  They
   may also send text that appears to originate from other participants.
   Counteractions should be to require secure signaling, media and
   authentication, and to provide higher level conference functions
   e.g., for blocking, muting, and expelling participants.

   Further security considerations specific for this application are
   specified in Section 3.19.
----------------------------------------------------------

Regards

Gunnar

-- 
Gunnar Hellstrm
GHAccess
gunnar.hellstrom@ghaccess.se
Den 2021-05-06 kl. 16:36, skrev Rich Salz via Datatracker:
Reviewer: Rich Salz
Review result: Ready

This review is for the benefit of the Security AD's. Nobody else should read
this. Or, if you read it, treat it as any other last call review :)

I know very little about WebRTC, AVT, etc.

I thought Section 1.2, summary of the alternatives, was great. I wish more
documents did this kind of thing. And similar for all of section 2. The details
in Section 3 about how to comply seem very clear. If I were implementing this,
I could use easily use this as a checklist and test suite. Section 3.19 is the
most important one for transport security. Not knowing the operating
environments, it seems reasonable.

The security considerations seems a little scant, given the opportunity for
privacy concerns of participants and for intruders to disrupt calls. Is it
common that the mixer is a trusted entity? A statement on that either way would
be useful.



_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org
https://www.ietf.org/mailman/listinfo/avt

-- 
Gunnar Hellstrm
GHAccess
gunnar.hellstrom@ghaccess.se
--------------CE9D9C7C43DF755520DB6DEC-- From nobody Sat May 8 08:10:14 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71D813A2C4E; Fri, 7 May 2021 10:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=egensajt.se 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 GKwFCak5VoQK; Fri, 7 May 2021 10:47:22 -0700 (PDT) Received: from smtp.egensajt.se (smtp.egensajt.se [194.68.80.251]) (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 3865B3A2BA0; Fri, 7 May 2021 10:47:10 -0700 (PDT) Received: from [192.168.2.137] (h77-53-37-81.cust.a3fiber.se [77.53.37.81]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: gunnar.hellstrom@ghaccess.se) by smtp.egensajt.se (Postfix) with ESMTPSA id D93E620FCE; Fri, 7 May 2021 19:47:03 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=egensajt.se; s=dkim; t=1620409624; bh=LrxfdhLdvbtUJPrmV3MRQsGshTyHa78jfRq+Fpkt+Qk=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=EeF8HbVVbRJbsIDk2s692m1ogKaLQvNW5w0ME7GNkjqQIbK0lveHm297T7NvHNqdv iCWGIGem5/wG2UACuCRLni58xK91je4VVdftgFq7CgZUeCd0wYhs24g86v9+RhMWBV Mf2JFBpQIr7ARkdrr1LfXakfYx3W83AQ2/DFaCG4= To: "Salz, Rich" , "secdir@ietf.org" Cc: "last-call@ietf.org" , "draft-ietf-avtcore-multi-party-rtt-mix.all@ietf.org" , "avt@ietf.org" References: <162031178943.8783.4063437681950995450@ietfa.amsl.com> <683ac9fe-b68f-3041-fff4-c26fef3767a8@ghaccess.se> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: Date: Fri, 7 May 2021 19:47:03 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------7BEBB1A4AD841BC0FF469135" Content-Language: sv Archived-At: X-Mailman-Approved-At: Sat, 08 May 2021 08:10:08 -0700 Subject: Re: [secdir] [AVTCORE] Secdir last call review of draft-ietf-avtcore-multi-party-rtt-mix-16 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2021 17:47:27 -0000 This is a multi-part message in MIME format. --------------7BEBB1A4AD841BC0FF469135 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Thanks. I have added this sentence to section 3.19 " Further general security considerations are covered in    Section 11." Regards Gunnar Hellstrom -- Gunnar Hellström GHAccess gunnar.hellstrom@ghaccess.se Den 2021-05-07 kl. 18:13, skrev Salz, Rich: > > Thanks for the explanation and update. Your updated draft addresses my > concerns.  Perhaps 3.9 should have a forward link to Sec 11 > > *From: *Gunnar Hellström > *Date: *Friday, May 7, 2021 at 11:45 AM > *To: *Rich Salz , "secdir@ietf.org" > *Cc: *"last-call@ietf.org" , > "draft-ietf-avtcore-multi-party-rtt-mix.all@ietf.org" > , "avt@ietf.org" > > *Subject: *Re: [AVTCORE] Secdir last call review of > draft-ietf-avtcore-multi-party-rtt-mix-16 > > Rich, > > Thanks for the review. > > I am composing a new version because of the Gen-ART review, and want > to propose changes to satisfy your comments. > > You ask if it is common to have the mixers being trusted. > > In the expected first implementation environments for this draft, it > is. That is in emergency service networks. Also in personal > communication services it is. > > The first implementation environments are also expected to use the SIP > centralized conference model (RFC 4353 etc.) where all media are > expected to be mixed centrally. Thus the security aspects would be > similar for audio, video and real-time text. > > I have tried to elaborate a bit more on this in a modified security > considerations section, currently looking like this and being ready > for submission together with the changes because of the Gen-ART > review. Would this satisfy your concerns? > > --------Proposed security concerns-------------------- > > 11.  Security Considerations >    The RTP-mixer model requires the mixer to be allowed to decrypt, >    pack, and encrypt secured text from the conference participants. >    Therefore the mixer needs to be trusted to achieve security in >    confidentiality and integrity.  This situation is similar to the >    situation for handling audio and video media in centralized mixers. >    The requirement to transfer information about the user in RTCP >    reports in SDES, CNAME, and NAME fields, and in conference >    notifications, for creation of labels may have privacy concerns as >    already stated in RFC 3550 [RFC3550], and may be restricted for >    privacy reasons.  The receiving user will then get a more symbolic >    label for the source. >    Participants with malicious intentions may appear and e.g., disturb >    the multiparty session by emitting a continuous flow of text.  They >    may also send text that appears to originate from other participants. >    Counteractions should be to require secure signaling, media and >    authentication, and to provide higher level conference functions >    e.g., for blocking, muting, and expelling participants. >    Further security considerations specific for this application are >    specified in Section 3.19. > ---------------------------------------------------------- > Regards > > Gunnar > > -- > Gunnar Hellström > GHAccess > gunnar.hellstrom@ghaccess.se > > Den 2021-05-06 kl. 16:36, skrev Rich Salz via Datatracker: > > Reviewer: Rich Salz > > Review result: Ready > > This review is for the benefit of the Security AD's. Nobody else should read > > this. Or, if you read it, treat it as any other last call review :) > > I know very little about WebRTC, AVT, etc. > > I thought Section 1.2, summary of the alternatives, was great. I wish more > > documents did this kind of thing. And similar for all of section 2. The details > > in Section 3 about how to comply seem very clear. If I were implementing this, > > I could use easily use this as a checklist and test suite. Section 3.19 is the > > most important one for transport security. Not knowing the operating > > environments, it seems reasonable. > > The security considerations seems a little scant, given the opportunity for > > privacy concerns of participants and for intruders to disrupt calls. Is it > > common that the mixer is a trusted entity? A statement on that either way would > > be useful. > > _______________________________________________ > > Audio/Video Transport Core Maintenance > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt > > -- > Gunnar Hellström > GHAccess > gunnar.hellstrom@ghaccess.se -- Gunnar Hellström GHAccess gunnar.hellstrom@ghaccess.se --------------7BEBB1A4AD841BC0FF469135 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Thanks.

I have added this sentence to section 3.19

" Further general security considerations are covered in
   Section 11."

Regards

Gunnar Hellstrom

-- 
Gunnar Hellström
GHAccess
gunnar.hellstrom@ghaccess.se


Den 2021-05-07 kl. 18:13, skrev Salz, Rich:

Thanks for the explanation and update.  Your updated draft addresses my concerns.  Perhaps 3.9 should have a forward link to Sec 11

 

From: Gunnar Hellström <gunnar.hellstrom@ghaccess.se>
Date: Friday, May 7, 2021 at 11:45 AM
To: Rich Salz <rsalz@akamai.com>, "secdir@ietf.org" <secdir@ietf.org>
Cc: "last-call@ietf.org" <last-call@ietf.org>, "draft-ietf-avtcore-multi-party-rtt-mix.all@ietf.org" <draft-ietf-avtcore-multi-party-rtt-mix.all@ietf.org>, "avt@ietf.org" <avt@ietf.org>
Subject: Re: [AVTCORE] Secdir last call review of draft-ietf-avtcore-multi-party-rtt-mix-16

 

Rich,

Thanks for the review.

I am composing a new version because of the Gen-ART review, and want to propose changes to satisfy your comments.

You ask if it is common to have the mixers being trusted.

In the expected first implementation environments for this draft, it is. That is in emergency service networks. Also in personal communication services it is.

The first implementation environments are also expected to use the SIP centralized conference model (RFC 4353 etc.) where all media are expected to be mixed centrally. Thus the security aspects would be similar for audio, video and real-time text.

I have tried to elaborate a bit more on this in a modified security considerations section, currently looking like this and being ready for submission together with the changes because of the Gen-ART review. Would this satisfy your concerns?

--------Proposed security concerns--------------------

11.  Security Considerations
 
   The RTP-mixer model requires the mixer to be allowed to decrypt,
   pack, and encrypt secured text from the conference participants.
   Therefore the mixer needs to be trusted to achieve security in
   confidentiality and integrity.  This situation is similar to the
   situation for handling audio and video media in centralized mixers.
 
   The requirement to transfer information about the user in RTCP
   reports in SDES, CNAME, and NAME fields, and in conference
   notifications, for creation of labels may have privacy concerns as
   already stated in RFC 3550 [RFC3550], and may be restricted for
   privacy reasons.  The receiving user will then get a more symbolic
   label for the source.
 
   Participants with malicious intentions may appear and e.g., disturb
   the multiparty session by emitting a continuous flow of text.  They
   may also send text that appears to originate from other participants.
   Counteractions should be to require secure signaling, media and
   authentication, and to provide higher level conference functions
   e.g., for blocking, muting, and expelling participants.
 
   Further security considerations specific for this application are
   specified in Section 3.19.
----------------------------------------------------------
 
Regards
 

Gunnar

-- 
Gunnar Hellström
GHAccess
gunnar.hellstrom@ghaccess.se

Den 2021-05-06 kl. 16:36, skrev Rich Salz via Datatracker:

Reviewer: Rich Salz
Review result: Ready
 
This review is for the benefit of the Security AD's. Nobody else should read
this. Or, if you read it, treat it as any other last call review :)
 
I know very little about WebRTC, AVT, etc.
 
I thought Section 1.2, summary of the alternatives, was great. I wish more
documents did this kind of thing. And similar for all of section 2. The details
in Section 3 about how to comply seem very clear. If I were implementing this,
I could use easily use this as a checklist and test suite. Section 3.19 is the
most important one for transport security. Not knowing the operating
environments, it seems reasonable.
 
The security considerations seems a little scant, given the opportunity for
privacy concerns of participants and for intruders to disrupt calls. Is it
common that the mixer is a trusted entity? A statement on that either way would
be useful.
 
 
 
_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org
https://www.ietf.org/mailman/listinfo/avt
-- 
Gunnar Hellström
GHAccess
gunnar.hellstrom@ghaccess.se
-- 
Gunnar Hellström
GHAccess
gunnar.hellstrom@ghaccess.se
--------------7BEBB1A4AD841BC0FF469135-- From nobody Sat May 8 08:10:21 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E82153A312E for ; Fri, 7 May 2021 13:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=egensajt.se 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 1klrQmj-hn9G for ; Fri, 7 May 2021 13:17:54 -0700 (PDT) Received: from smtp.egensajt.se (smtp.egensajt.se [193.42.159.246]) (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 EF02A3A312C for ; Fri, 7 May 2021 13:17:53 -0700 (PDT) Received: from [192.168.2.137] (h77-53-37-81.cust.a3fiber.se [77.53.37.81]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: gunnar.hellstrom@ghaccess.se) by smtp.egensajt.se (Postfix) with ESMTPSA id 553B7202E6; Fri, 7 May 2021 22:17:52 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=egensajt.se; s=dkim; t=1620418672; bh=0Pp4ywdnwWFFgURU+dZFIJ3pbudjiBVNJsmNHcxKdMQ=; h=Subject:From:To:References:Date:In-Reply-To:From; b=Flt0mAnlXALTb2/vJ5QlYcV0GfH3Alt71b0ZXfcNJo1rNGnMA/Ec0uNogetR/DjK3 /qO3vDWW7GETqaQXoqSAZYl/FNJIaOxveDHVyVE8n9IQfl6uJYYSxlyaihDfNpBUPa vOTDivziftl69YRWCV/D/1ebIM1OKQX5LLd8GyzI= From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= To: "Salz, Rich" , "secdir@ietf.org" References: <162031178943.8783.4063437681950995450@ietfa.amsl.com> <683ac9fe-b68f-3041-fff4-c26fef3767a8@ghaccess.se> Message-ID: <2a8b488f-6389-38ca-037e-b68346420382@ghaccess.se> Date: Fri, 7 May 2021 22:17:51 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------E7673B1337E22B409EE9CB7B" Content-Language: sv Archived-At: X-Mailman-Approved-At: Sat, 08 May 2021 08:10:08 -0700 Subject: Re: [secdir] [AVTCORE] Secdir last call review of draft-ietf-avtcore-multi-party-rtt-mix-16 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2021 20:17:59 -0000 This is a multi-part message in MIME format. --------------E7673B1337E22B409EE9CB7B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Version -17 of the draft is submitted, with intention to have all Genart and Secdir review comments resolved. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-multi-party-rtt-mix/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-avtcore-multi-party-rtt-mix-17.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-multi-party-rtt-mix-17 Best Regards Gunnar -- Gunnar Hellström GHAccess gunnar.hellstrom@ghaccess.se Den 2021-05-07 kl. 19:47, skrev Gunnar Hellström: > > Thanks. > > I have added this sentence to section 3.19 > > " Further general security considerations are covered in >    Section 11." > > Regards > > Gunnar Hellstrom > > -- > Gunnar Hellström > GHAccess > gunnar.hellstrom@ghaccess.se > > > Den 2021-05-07 kl. 18:13, skrev Salz, Rich: >> >> Thanks for the explanation and update. Your updated draft addresses >> my concerns.  Perhaps 3.9 should have a forward link to Sec 11 >> >> *From: *Gunnar Hellström >> *Date: *Friday, May 7, 2021 at 11:45 AM >> *To: *Rich Salz , "secdir@ietf.org" >> *Cc: *"last-call@ietf.org" , >> "draft-ietf-avtcore-multi-party-rtt-mix.all@ietf.org" >> , "avt@ietf.org" >> >> *Subject: *Re: [AVTCORE] Secdir last call review of >> draft-ietf-avtcore-multi-party-rtt-mix-16 >> >> Rich, >> >> Thanks for the review. >> >> I am composing a new version because of the Gen-ART review, and want >> to propose changes to satisfy your comments. >> >> You ask if it is common to have the mixers being trusted. >> >> In the expected first implementation environments for this draft, it >> is. That is in emergency service networks. Also in personal >> communication services it is. >> >> The first implementation environments are also expected to use the >> SIP centralized conference model (RFC 4353 etc.) where all media are >> expected to be mixed centrally. Thus the security aspects would be >> similar for audio, video and real-time text. >> >> I have tried to elaborate a bit more on this in a modified security >> considerations section, currently looking like this and being ready >> for submission together with the changes because of the Gen-ART >> review. Would this satisfy your concerns? >> >> --------Proposed security concerns-------------------- >> >> 11.  Security Considerations >>    The RTP-mixer model requires the mixer to be allowed to decrypt, >>    pack, and encrypt secured text from the conference participants. >>    Therefore the mixer needs to be trusted to achieve security in >>    confidentiality and integrity.  This situation is similar to the >>    situation for handling audio and video media in centralized mixers. >>    The requirement to transfer information about the user in RTCP >>    reports in SDES, CNAME, and NAME fields, and in conference >>    notifications, for creation of labels may have privacy concerns as >>    already stated in RFC 3550 [RFC3550], and may be restricted for >>    privacy reasons.  The receiving user will then get a more symbolic >>    label for the source. >>    Participants with malicious intentions may appear and e.g., disturb >>    the multiparty session by emitting a continuous flow of text.  They >>    may also send text that appears to originate from other participants. >>    Counteractions should be to require secure signaling, media and >>    authentication, and to provide higher level conference functions >>    e.g., for blocking, muting, and expelling participants. >>    Further security considerations specific for this application are >>    specified in Section 3.19. >> ---------------------------------------------------------- >> Regards >> >> Gunnar >> >> -- >> Gunnar Hellström >> GHAccess >> gunnar.hellstrom@ghaccess.se >> >> Den 2021-05-06 kl. 16:36, skrev Rich Salz via Datatracker: >> >> Reviewer: Rich Salz >> >> Review result: Ready >> >> This review is for the benefit of the Security AD's. Nobody else should read >> >> this. Or, if you read it, treat it as any other last call review :) >> >> I know very little about WebRTC, AVT, etc. >> >> I thought Section 1.2, summary of the alternatives, was great. I wish more >> >> documents did this kind of thing. And similar for all of section 2. The details >> >> in Section 3 about how to comply seem very clear. If I were implementing this, >> >> I could use easily use this as a checklist and test suite. Section 3.19 is the >> >> most important one for transport security. Not knowing the operating >> >> environments, it seems reasonable. >> >> The security considerations seems a little scant, given the opportunity for >> >> privacy concerns of participants and for intruders to disrupt calls. Is it >> >> common that the mixer is a trusted entity? A statement on that either way would >> >> be useful. >> >> _______________________________________________ >> >> Audio/Video Transport Core Maintenance >> >> avt@ietf.org >> >> https://www.ietf.org/mailman/listinfo/avt >> >> -- >> Gunnar Hellström >> GHAccess >> gunnar.hellstrom@ghaccess.se > -- > Gunnar Hellström > GHAccess > gunnar.hellstrom@ghaccess.se -- Gunnar Hellström GHAccess gunnar.hellstrom@ghaccess.se --------------E7673B1337E22B409EE9CB7B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Version -17 of the draft is submitted, with intention to have all Genart and Secdir review comments resolved.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-avtcore-multi-party-rtt-mix/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-avtcore-multi-party-rtt-mix-17.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-multi-party-rtt-mix-17


Best Regards

Gunnar

-- 
Gunnar Hellström
GHAccess
gunnar.hellstrom@ghaccess.se
Den 2021-05-07 kl. 19:47, skrev Gunnar Hellström:

Thanks.

I have added this sentence to section 3.19

" Further general security considerations are covered in
   Section 11."

Regards

Gunnar Hellstrom

-- 
Gunnar Hellström
GHAccess
gunnar.hellstrom@ghaccess.se


Den 2021-05-07 kl. 18:13, skrev Salz, Rich:

Thanks for the explanation and update.  Your updated draft addresses my concerns.  Perhaps 3.9 should have a forward link to Sec 11

 

From: Gunnar Hellström <gunnar.hellstrom@ghaccess.se>
Date: Friday, May 7, 2021 at 11:45 AM
To: Rich Salz <rsalz@akamai.com>, "secdir@ietf.org" <secdir@ietf.org>
Cc: "last-call@ietf.org" <last-call@ietf.org>, "draft-ietf-avtcore-multi-party-rtt-mix.all@ietf.org" <draft-ietf-avtcore-multi-party-rtt-mix.all@ietf.org>, "avt@ietf.org" <avt@ietf.org>
Subject: Re: [AVTCORE] Secdir last call review of draft-ietf-avtcore-multi-party-rtt-mix-16

 

Rich,

Thanks for the review.

I am composing a new version because of the Gen-ART review, and want to propose changes to satisfy your comments.

You ask if it is common to have the mixers being trusted.

In the expected first implementation environments for this draft, it is. That is in emergency service networks. Also in personal communication services it is.

The first implementation environments are also expected to use the SIP centralized conference model (RFC 4353 etc.) where all media are expected to be mixed centrally. Thus the security aspects would be similar for audio, video and real-time text.

I have tried to elaborate a bit more on this in a modified security considerations section, currently looking like this and being ready for submission together with the changes because of the Gen-ART review. Would this satisfy your concerns?

--------Proposed security concerns--------------------

11.  Security Considerations
 
   The RTP-mixer model requires the mixer to be allowed to decrypt,
   pack, and encrypt secured text from the conference participants.
   Therefore the mixer needs to be trusted to achieve security in
   confidentiality and integrity.  This situation is similar to the
   situation for handling audio and video media in centralized mixers.
 
   The requirement to transfer information about the user in RTCP
   reports in SDES, CNAME, and NAME fields, and in conference
   notifications, for creation of labels may have privacy concerns as
   already stated in RFC 3550 [RFC3550], and may be restricted for
   privacy reasons.  The receiving user will then get a more symbolic
   label for the source.
 
   Participants with malicious intentions may appear and e.g., disturb
   the multiparty session by emitting a continuous flow of text.  They
   may also send text that appears to originate from other participants.
   Counteractions should be to require secure signaling, media and
   authentication, and to provide higher level conference functions
   e.g., for blocking, muting, and expelling participants.
 
   Further security considerations specific for this application are
   specified in Section 3.19.
----------------------------------------------------------
 
Regards
 

Gunnar

-- 
Gunnar Hellström
GHAccess
gunnar.hellstrom@ghaccess.se

Den 2021-05-06 kl. 16:36, skrev Rich Salz via Datatracker:

Reviewer: Rich Salz
Review result: Ready
 
This review is for the benefit of the Security AD's. Nobody else should read
this. Or, if you read it, treat it as any other last call review :)
 
I know very little about WebRTC, AVT, etc.
 
I thought Section 1.2, summary of the alternatives, was great. I wish more
documents did this kind of thing. And similar for all of section 2. The details
in Section 3 about how to comply seem very clear. If I were implementing this,
I could use easily use this as a checklist and test suite. Section 3.19 is the
most important one for transport security. Not knowing the operating
environments, it seems reasonable.
 
The security considerations seems a little scant, given the opportunity for
privacy concerns of participants and for intruders to disrupt calls. Is it
common that the mixer is a trusted entity? A statement on that either way would
be useful.
 
 
 
_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org
https://www.ietf.org/mailman/listinfo/avt
-- 
Gunnar Hellström
GHAccess
gunnar.hellstrom@ghaccess.se
-- 
Gunnar Hellström
GHAccess
gunnar.hellstrom@ghaccess.se
-- 
Gunnar Hellström
GHAccess
gunnar.hellstrom@ghaccess.se
--------------E7673B1337E22B409EE9CB7B-- From nobody Sat May 8 08:32:32 2021 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E81243A1C12 for ; Sat, 8 May 2021 08:32:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 7.28.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <162048795086.5482.12496022226874008574@ietfa.amsl.com> Date: Sat, 08 May 2021 08:32:30 -0700 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 May 2021 15:32:31 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2021-05-20 Reviewer LC end Draft Tina Tsou 2021-05-03 draft-ietf-idr-eag-distribution Dacheng Zhang 2021-05-03 draft-ietf-idr-eag-distribution Last calls: Reviewer LC end Draft John Bradley 2021-03-16 draft-ietf-idr-bgp-ls-registry Shaun Cooley 2021-02-25 draft-ietf-v6ops-ipv6-ehs-packet-drops Alan DeKok 2021-03-24 draft-ietf-cbor-tags-oid Daniel Gillmor 2021-03-26 draft-ietf-lamps-crmf-update-algs Phillip Hallam-Baker 2019-12-13 draft-ietf-ace-oauth-authz Steve Hanna 2021-03-22 draft-ietf-regext-secure-authinfo-transfer Leif Johansson None draft-ietf-netconf-crypto-types Aanchal Malhotra None draft-ietf-opsawg-l3sm-l3nm Catherine Meadows 2021-04-14 draft-ietf-ntp-interleaved-modes Kathleen Moriarty 2021-04-27 draft-ietf-bess-mvpn-msdp-sa-interoperation Russ Mundy 2021-04-20 draft-ietf-dprive-xfr-over-tls Sandra Murphy R2021-04-05 draft-ietf-dmarc-psd Sandra Murphy 2020-10-15 draft-ietf-tls-external-psk-importer Yoav Nir 2021-04-28 draft-ietf-core-new-block Rifaat Shekh-Yusef 2021-05-21 draft-ietf-payload-vp9 Melinda Shore 2021-05-17 draft-ietf-payload-rtp-jpegxs Carl Wallace R2020-08-26 draft-ietf-stir-cert-delegation Carl Wallace R2021-02-22 draft-ietf-tcpm-2140bis Samuel Weiler 2021-02-22 draft-ietf-tls-dtls13 Brian Weis 2021-02-19 draft-ietf-lamps-cms-aes-gmac-alg Klaas Wierenga 2020-12-02 draft-ietf-core-echo-request-tag Klaas Wierenga 2020-05-26 draft-ietf-kitten-krb-spake-preauth Paul Wouters 2020-09-08 draft-ietf-i2nsf-capability-data-model Liang Xia 2021-03-17 draft-ietf-core-sid Early review requests: Reviewer Due Draft Paul Wouters 2021-02-19 draft-ietf-idr-bgp-ls-app-specific-attr Next in the reviewer rotation: Valery Smyslov Robert Sparks Tina Tsou Sean Turner Loganaden Velvindron Mališa Vučinić Carl Wallace Samuel Weiler Brian Weis Klaas Wierenga From nobody Mon May 10 06:28:19 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87B943A1CBC; Mon, 10 May 2021 06:28:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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=hs-esslingen.de 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 U9fCUhIcniau; Mon, 10 May 2021 06:28:08 -0700 (PDT) Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F1223A1CB7; Mon, 10 May 2021 06:28:07 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 3696025A15; Mon, 10 May 2021 15:28:05 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1620653285; bh=qdMR+1qyvRCqlxRBitFuavTNO5IxkOE19jOfZ+AhJHg=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=F/0AqCEIHZbekbNXsj1LpU+uBLrHxDwQlWZeiTDQ5ufypF9v5PUZhmQp3Ysh1cLG9 kXj2FjOIfCxyk5cnhmdK22MwSBin6Ptyiz6xNNyl5Ns9HRivqRxPzdGz7InBqEKar7 lmvD8Rx4M2l0SFUpBZEe0MD3v1gxjbYqpqBGi4Lo= X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pMDsph9HI4Ir; Mon, 10 May 2021 15:28:04 +0200 (CEST) Received: from rznt8201.rznt.rzdir.fht-esslingen.de (rznt8201.hs-esslingen.de [134.108.48.164]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Mon, 10 May 2021 15:28:04 +0200 (CEST) Received: from rznt8202.rznt.rzdir.fht-esslingen.de (134.108.48.165) by rznt8201.rznt.rzdir.fht-esslingen.de (134.108.48.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Mon, 10 May 2021 15:28:04 +0200 Received: from rznt8202.rznt.rzdir.fht-esslingen.de ([fe80::aca4:171a:3ee1:57e0]) by rznt8202.rznt.rzdir.fht-esslingen.de ([fe80::aca4:171a:3ee1:57e0%3]) with mapi id 15.01.2176.012; Mon, 10 May 2021 15:28:04 +0200 From: "Scharf, Michael" To: Bob Briscoe , "Scott G. Kelly" CC: "draft-ietf-tcpm-accurate-ecn.all@ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Thread-Topic: secdir review of draft-ietf-tcpm-accurate-ecn-14 Thread-Index: AQHXL/hxkNxGdyvgLEmc/kmdguza0arYWGsAgASCrFA= Date: Mon, 10 May 2021 13:28:04 +0000 Message-ID: <1c48d71fab214a218f7289def3c75b09@hs-esslingen.de> References: <1618272203.965227355@apps.rackspace.com> <16c048ca-e027-a1bb-0d06-22260f87139b@bobbriscoe.net> In-Reply-To: <16c048ca-e027-a1bb-0d06-22260f87139b@bobbriscoe.net> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.140.248] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-tcpm-accurate-ecn-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2021 13:28:13 -0000 PiA+IEknbSBub3QgYSBUQ1Agb3IgRUNOIGV4cGVydCwgc28gcGxlYXNlIHRha2UgbXkgY29tbWVu dHMgd2l0aCBhIHByb3ZlcmJpYWwNCj4gZ3JhaW4gb2Ygc2FsdC4gVGhpbmtpbmcgYWJvdXQgdGhp cyBzdHJpY3RseSBhcyBhIHNlY3VyaXR5IGdlZWssIEkgc2VlIHRocmVlIHBsYWNlcw0KPiB3aGVy ZSB0aGlzIHNjaGVtZSBjb3VsZCBiZSB0YW1wZXJlZCB3aXRoOiB0aGUgc2VuZGVyLCB0aGUgcmVj ZWl2ZXIsIGFuZA0KPiB0aGUgbmV0d29yayBpbiBiZXR3ZWVuIHRoZW0uDQo+ID4NCj4gPiBUaGUg c2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2VjdGlvbiBzdGFydHMgb2ZmIGJ5IHBvaW50aW5nIG91 dCB0aGF0IHRoZXJlIHdpbGwNCj4gYmUgY29uc2VxdWVuY2VzIHRvIHRhbXBlcmluZyBieSBhIG1p ZGRsZWJveCAodGhlIG5ldHdvcmsgaW4gYmV0d2VlbiksDQo+IGFuZCBpdCBkZXNjcmliZXMgdGhl IGltcGFjdCBhcyBsaW1pdGVkLg0KPiA+DQo+ID4gQSBtYWxpY2lvdXMgc2VuZGVyIGlzIG5vdCBk ZXNjcmliZWQsIGFuZCBJJ20gbm90IHN1cmUgdGhhdCBhbnkgc3VjaCB0aGluZw0KPiByZWFzb25h Ymx5IGV4aXN0cywgYnV0IEkgZGlkIHdvbmRlciBhYm91dCB0aGlzLg0KPiANCj4gW0JCXSBBIG1h bGljaW91cyBzZW5kZXIgaXMgbm90IGRlc2NyaWJlZCBiZWNhdXNlIHRoZSBzY29wZSBvZiBBY2NF Q04gaXMNCj4gcHVyZWx5IGFib3V0IGNoYW5nZXMgdG8gVENQJ3MgZmVlZGJhY2sgcHJvdG9jb2wg YmV0d2VlbiBEYXRhIFJlY2VpdmVyDQo+IGFuZCBEYXRhIFNlbmRlci4gTWFsaWNpb3VzIHNlbmRl cnMgY2FuIGlnbm9yZSBUQ1AgZmVlZGJhY2suIFNvIGl0DQo+IGRvZXNuJ3QgbWF0dGVyIHdoYXQg d2Ugc2F5IHdoZW4gd2UgdXBkYXRlIGEgZmVlZGJhY2sgc3BlYyBpZiBtYWxpY2lvdXMNCj4gc2Vu ZGVycyBjYW4gaWdub3JlIHRoZSBmZWVkYmFjayBhbnl3YXkuDQoNCkp1c3QgYSBxdWljayBub3Rl IG9uIHRlcm1pbm9sb2d5OiBGb3IgZGF0YSB0cmFuc2ZlcnMgZnJvbSBhICJkYXRhIHNlbmRlciIg dG8gYSAiZGF0YSByZWNlaXZlciIsIHRoZSBtYWxpY2lvdXMgInNlbmRlciIgb2YgdGhlIFRDUCBv cHRpb24gd291bGQgYmUgdGhlICJkYXRhIHJlY2VpdmVyIi4NCg0KU28sIGEgYmV0dGVyIHBocmFz aW5nIG1pZ2h0IGJlOg0KDQogICIuLi4gbWFsaWNpb3VzICpkYXRhKiBzZW5kZXJzIGNhbiBpZ25v cmUgdGhlIGZlZWRiYWNrIGFueXdheS4iDQoNCldoZW4gbG9va2luZyBhdCB0aGUgVENQIG9wdGlv biwgYSBiaXQgb2YgY2FyZSBtYXkgYmUgbmVlZGVkIHdobyBpcyBzZW5kaW5nIHdoYXQgKGFuZCBm b3Igd2hhdCBwdXJwb3NlKS4NCg0KTWljaGFlbA0KDQo= From nobody Mon May 10 07:22:33 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 749F43A1E6E; Mon, 10 May 2021 07:22:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.434 X-Spam-Level: X-Spam-Status: No, score=-1.434 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net 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 Qu3syb0V-HO8; Mon, 10 May 2021 07:22:22 -0700 (PDT) Received: from mail-ssdrsserver2.hosting.co.uk (mail-ssdrsserver2.hosting.co.uk [185.185.85.90]) (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 9DE913A1E46; Mon, 10 May 2021 07:22:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=mRXgkpMDlUR6XFN+ey7Q5/M4D0qhOwdeHQSXoU4g1/M=; b=vYQiUTlI8thiVdgOnsnM2vuP5t DcJZjN+N/EgVT50Dd2+CEOeLo9vjs90JsPuyPVPrbux+FaS73QY1plyA7IwQ4EedGUc3EbPo9yheE 9UPK8TE0K6OF+igrPa3nrBL1hw8C8hgWpfmQNDZvH1YfAwd219sSYXfPJDRokyS6EggebI+gumOtc tnVWFzwP3dhxnmHmgui6qfy2V87EStqB4nEDD0qKftSh2fVUrSrlY0z92hZJT4eXjHlzsdpR40Xa8 CWQQPPEJdkSojFEGEtX26+AKg+diqJnHgt1eAnAga0nLsRlIkjr1PpoczVmS4OXMpS1wS0M1PwRx0 f48hq5Dw==; Received: from 67.153.238.178.in-addr.arpa ([178.238.153.67]:37554 helo=[192.168.1.9]) by ssdrsserver2.hosting.co.uk with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1lg6nZ-0003Q0-62; Mon, 10 May 2021 15:22:15 +0100 To: "Scharf, Michael" , "Scott G. Kelly" Cc: "draft-ietf-tcpm-accurate-ecn.all@ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" References: <1618272203.965227355@apps.rackspace.com> <16c048ca-e027-a1bb-0d06-22260f87139b@bobbriscoe.net> <1c48d71fab214a218f7289def3c75b09@hs-esslingen.de> From: Bob Briscoe Message-ID: <3c644f7c-b7aa-3011-1efe-eed04af98e8e@bobbriscoe.net> Date: Mon, 10 May 2021 15:22:13 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <1c48d71fab214a218f7289def3c75b09@hs-esslingen.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ssdrsserver2.hosting.co.uk X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: ssdrsserver2.hosting.co.uk: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: ssdrsserver2.hosting.co.uk: in@bobbriscoe.net X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-tcpm-accurate-ecn-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2021 14:22:28 -0000 Michael, see [BB2] On 10/05/2021 14:28, Scharf, Michael wrote: >>> I'm not a TCP or ECN expert, so please take my comments with a proverbial >> grain of salt. Thinking about this strictly as a security geek, I see three places >> where this scheme could be tampered with: the sender, the receiver, and >> the network in between them. >>> The security considerations section starts off by pointing out that there will >> be consequences to tampering by a middlebox (the network in between), >> and it describes the impact as limited. >>> A malicious sender is not described, and I'm not sure that any such thing >> reasonably exists, but I did wonder about this. >> >> [BB] A malicious sender is not described because the scope of AccECN is >> purely about changes to TCP's feedback protocol between Data Receiver >> and Data Sender. Malicious senders can ignore TCP feedback. So it >> doesn't matter what we say when we update a feedback spec if malicious >> senders can ignore the feedback anyway. > Just a quick note on terminology: For data transfers from a "data sender" to a "data receiver", the malicious "sender" of the TCP option would be the "data receiver". > > So, a better phrasing might be: > > "... malicious *data* senders can ignore the feedback anyway." > > When looking at the TCP option, a bit of care may be needed who is sending what (and for what purpose). [BB2] Thx. Also, in the Sec Consids section, we were careful to specify "Data rx/tx" except in one case, which I've fixed as well. Bob > > Michael > -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ From nobody Wed May 12 14:02:11 2021 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 089AA3A15BC; Wed, 12 May 2021 14:02:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Rifaat Shekh-Yusef via Datatracker To: Cc: avt@ietf.org, draft-ietf-payload-vp9.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162085332298.31523.1409717156510655857@ietfa.amsl.com> Reply-To: Rifaat Shekh-Yusef Date: Wed, 12 May 2021 14:02:03 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-payload-vp9-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2021 21:02:03 -0000 Reviewer: Rifaat Shekh-Yusef Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document describes an RTP payload format for the VP9 video codec. The security consideration section lists a number of RTP documents that deal with the RTP protocol and its security. The section also highlights that the application is the one that is responsible for securing the media. The security consideration section also discusses the potential impact of a corrupted RTP payload on the receiver and indicates that this is unlikely to pose a denial of service threat. This seems reasonable to me. From nobody Thu May 13 06:54:12 2021 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E9D83A0945 for ; Thu, 13 May 2021 06:54:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 7.29.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <162091404210.27390.17294419735531791841@ietfa.amsl.com> Date: Thu, 13 May 2021 06:54:02 -0700 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2021 13:54:11 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2021-05-20 Reviewer LC end Draft Kathleen Moriarty 2021-04-27 draft-ietf-bess-mvpn-msdp-sa-interoperation Magnus Nystrom R2021-05-05 draft-ietf-idr-bgp-flowspec-oid Tina Tsou 2021-05-03 draft-ietf-idr-eag-distribution Dacheng Zhang 2021-05-03 draft-ietf-idr-eag-distribution Last calls: Reviewer LC end Draft John Bradley 2021-03-16 draft-ietf-idr-bgp-ls-registry Shaun Cooley 2021-02-25 draft-ietf-v6ops-ipv6-ehs-packet-drops Alan DeKok 2021-03-24 draft-ietf-cbor-tags-oid Daniel Gillmor 2021-03-26 draft-ietf-lamps-crmf-update-algs Phillip Hallam-Baker 2019-12-13 draft-ietf-ace-oauth-authz Steve Hanna 2021-03-22 draft-ietf-regext-secure-authinfo-transfer Leif Johansson None draft-ietf-netconf-crypto-types Aanchal Malhotra None draft-ietf-opsawg-l3sm-l3nm Catherine Meadows 2021-04-14 draft-ietf-ntp-interleaved-modes Kathleen Moriarty 2021-04-27 draft-ietf-bess-mvpn-msdp-sa-interoperation Russ Mundy 2021-04-20 draft-ietf-dprive-xfr-over-tls Sandra Murphy R2021-04-05 draft-ietf-dmarc-psd Sandra Murphy 2020-10-15 draft-ietf-tls-external-psk-importer Yoav Nir 2021-04-28 draft-ietf-core-new-block Magnus Nystrom R2021-05-05 draft-ietf-idr-bgp-flowspec-oid Melinda Shore 2021-05-17 draft-ietf-payload-rtp-jpegxs Valery Smyslov 2021-05-24 draft-ietf-dnsop-iana-class-type-yang Robert Sparks 2021-05-24 draft-ietf-bmwg-evpntest Carl Wallace R2020-08-26 draft-ietf-stir-cert-delegation Carl Wallace R2021-02-22 draft-ietf-tcpm-2140bis Samuel Weiler 2021-02-22 draft-ietf-tls-dtls13 Brian Weis 2021-02-19 draft-ietf-lamps-cms-aes-gmac-alg Klaas Wierenga 2020-12-02 draft-ietf-core-echo-request-tag Klaas Wierenga 2020-05-26 draft-ietf-kitten-krb-spake-preauth Paul Wouters 2020-09-08 draft-ietf-i2nsf-capability-data-model Liang Xia 2021-03-17 draft-ietf-core-sid Early review requests: Reviewer Due Draft Sean Turner 2021-06-30 draft-ietf-anima-constrained-voucher Paul Wouters 2021-02-19 draft-ietf-idr-bgp-ls-app-specific-attr Next in the reviewer rotation: Loganaden Velvindron Mališa Vučinić Carl Wallace Samuel Weiler Brian Weis Klaas Wierenga Paul Wouters Liang Xia Dacheng Zhang Derek Atkins From nobody Fri May 14 00:58:25 2021 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9344C3A2831; Fri, 14 May 2021 00:58:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Valery Smyslov via Datatracker To: Cc: dnsop@ietf.org, draft-ietf-dnsop-iana-class-type-yang.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162097908855.2706.8929577886925875788@ietfa.amsl.com> Reply-To: Valery Smyslov Date: Fri, 14 May 2021 00:58:08 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-dnsop-iana-class-type-yang-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2021 07:58:17 -0000 Reviewer: Valery Smyslov Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document defines how IANA assigned values in two DNS registries (DNS CLASSes and Resource Record TYPEs) are to be translated into YANG enumerations, so that they can be later used in defining YANG modules modelling DNS configuration. The document introduces no new technology or protocol and only defines a one-to-one translation of IANA assigned values to YANG enumerations. Nits: I think that RFC 8174 should also be referenced (along with RFC 2119). From nobody Fri May 14 03:32:36 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 226343A2DCE for ; Fri, 14 May 2021 03:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhoundsoftware.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 d52grik5xzJe for ; Fri, 14 May 2021 03:32:26 -0700 (PDT) Received: from mail-qv1-xf2b.google.com (mail-qv1-xf2b.google.com [IPv6:2607:f8b0:4864:20::f2b]) (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 AEC653A2DD0 for ; Fri, 14 May 2021 03:32:26 -0700 (PDT) Received: by mail-qv1-xf2b.google.com with SMTP id ee9so4903753qvb.8 for ; Fri, 14 May 2021 03:32:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware.com; s=google; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :mime-version:content-transfer-encoding; bh=D+lZkxEcUnbSNmfhT8bTIwoY+ysBghVt27K5fCarnzk=; b=MiltEGHFBtV2ArSvlVw6NZiNj/VrR1rSdhqbbiiLeLaD/B3SOHfN+4OiZ2sIh1yKnM efTDbYv9fuiYOKNndT307C6BuayVUZQgxT+L4Bg3QPX9BJzWsE2jJme5DqQm2x8gjaRB WWpRggv4szIiPHy5sbJT/mYPaOGmlKmVP4gQ4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:mime-version:content-transfer-encoding; bh=D+lZkxEcUnbSNmfhT8bTIwoY+ysBghVt27K5fCarnzk=; b=a+bxFgjyE0R0tbA4BhNq7MYzFzdSPn6jXkOxmFDQeZcKRUsjCh4yP2n4LFLNpXlVd5 uc7O1X8Ba8UHM2eKVd2rV2QZwg9choloje26Ax7fyKsbpocD/j8urbVWV/jE3apW1rE2 j/uPHEbCGHLikf+gJD3njFwAMow06Jm27ENonUFVTukiGi6wTJkWOSSV8kLkNLs/tPpw ssQh0lzpxHbbw+53Vw4IX2yjeAXL3NSLzyHD0qyaJbn5+tavFYY+E/lMQUIBtniP6mP6 8Zm9gBxajGPXsfgXA0wawGDJo9AywAnHOXaW5lOjncaerUuCE3vudIEp+9sHcGsIOY9Q DV8w== X-Gm-Message-State: AOAM530EXXbPkcZ5mss2qtTRKLDgiML5Dm4pXZb08785L0BiRPIBFns0 RymGv7f/QiZ0IuwfzuVF+7DiP/y+abrc2j5w X-Google-Smtp-Source: ABdhPJysLAlMxb2lynxQjWV+Pzg3yrouL0cbN5o5o38iOxI5KzBknYoU/ZCMBW3t7c9Z8qt9Flg3Dg== X-Received: by 2002:a05:6214:11ab:: with SMTP id u11mr12133269qvv.32.1620988344334; Fri, 14 May 2021 03:32:24 -0700 (PDT) Received: from [192.168.2.17] (pool-108-18-106-102.washdc.fios.verizon.net. [108.18.106.102]) by smtp.gmail.com with ESMTPSA id n17sm4518392qke.14.2021.05.14.03.32.23 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 May 2021 03:32:23 -0700 (PDT) User-Agent: Microsoft-MacOutlook/16.49.21050901 Date: Fri, 14 May 2021 06:32:23 -0400 From: Carl Wallace To: CC: , Message-ID: <5210316D-E025-4896-94CB-70AFF89E4B32@redhoundsoftware.com> Thread-Topic: secdir review of draft-ietf-stir-cert-delegation-04 Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: Subject: [secdir] secdir review of draft-ietf-stir-cert-delegation-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2021 10:32:31 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes how authority over telephone numbers and related identifiers can be delegated from a parent certificate to a subordinate certificate. I previously reviewed -03 last summer. The text that was the focus on my primary concern in the previous review remains in section 4.1 with regard to affirming a TNAuthList is encompassed by its ancestors: "This might be performed at the time the delegate certificate is issued, or at the time that a verification service receives an inbound call, or potentially both. It is generally desirable to offload as much of this as possible to the certification process, as verification occurs during call setup and thus additional network dips could lead to perceptible delay, whereas certification happens outside of call processing as a largely administrative function." Some new language has been added to the Security Considerations section that states "(h)ow encompassing is policed is therefore a matter outside the scope of this document." I don't think the question is so much how it is policed, which would seem to be a nod to something like CT, but how it is used to affirm "legitimate spoofing". I don't see how a verifier can know whether or not a check has been performed or not. That the primary information used to perform the check can be external to the certificate with no binding to the certificate, no replay protections, limited origin authentication/integrity, etc. heightens the need to know that the values being relied upon are true, i.e., that they pass the encompassing check. Aside from this and not noted last time, some guidance regarding caching of external TNAuthLists and on verifying the HTTPS certificate may be warranted, given the importance of the external mechanism. From nobody Fri May 14 05:42:34 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 319CA3A180F; Fri, 14 May 2021 05:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 UikFj0NIXjtd; Fri, 14 May 2021 05:42:19 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 C56253A318D; Fri, 14 May 2021 05:42:15 -0700 (PDT) Received: from localhost (unknown [IPv6:2a01:5e0:29:ffff:fc73:fa64:57e6:2115]) by mail.nic.cz (Postfix) with ESMTPSA id 8BC90140AF4; Fri, 14 May 2021 14:42:11 +0200 (CEST) From: Ladislav Lhotka To: Valery Smyslov , secdir@ietf.org Cc: dnsop@ietf.org, draft-ietf-dnsop-iana-class-type-yang.all@ietf.org, last-call@ietf.org In-Reply-To: <162097908855.2706.8929577886925875788@ietfa.amsl.com> References: <162097908855.2706.8929577886925875788@ietfa.amsl.com> Date: Fri, 14 May 2021 14:42:10 +0200 Message-ID: <87zgwxlc65.fsf@nic.cz> MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.102.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-dnsop-iana-class-type-yang-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2021 12:42:25 -0000 Valery Smyslov via Datatracker writes: > Reviewer: Valery Smyslov > Review result: Ready > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > The document defines how IANA assigned values in two DNS registries > (DNS CLASSes and Resource Record TYPEs) are to be translated into > YANG enumerations, so that they can be later used in defining > YANG modules modelling DNS configuration. > > The document introduces no new technology or protocol > and only defines a one-to-one translation of IANA assigned values > to YANG enumerations. > > Nits: > I think that RFC 8174 should also be referenced (along with RFC 2119). > Updated, thanks. Lada > -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Fri May 14 15:27:36 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B81E33A4254; Fri, 14 May 2021 15:27:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MAY_BE_FORGED=0.846, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 iDzOq7gDwX5f; Fri, 14 May 2021 15:27:24 -0700 (PDT) Received: from mta8.iomartmail.com (mta8.iomartmail.com [62.128.193.158]) (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 E37BB3A4252; Fri, 14 May 2021 15:27:22 -0700 (PDT) Received: from vs2.iomartmail.com (vs2.iomartmail.com [10.12.10.123]) by mta8.iomartmail.com (8.14.4/8.14.4) with ESMTP id 14EMRL1p023277; Fri, 14 May 2021 23:27:21 +0100 Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id DDB0D22044; Fri, 14 May 2021 23:27:19 +0100 (BST) Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs2.iomartmail.com (Postfix) with ESMTPS id C829322042; Fri, 14 May 2021 23:27:19 +0100 (BST) Received: from LAPTOPK7AS653V (65.151.51.84.dyn.plus.net [84.51.151.65] (may be forged)) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id 14EMRIKB026115 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 14 May 2021 23:27:19 +0100 Reply-To: From: "Adrian Farrel" To: "'Benjamin Kaduk'" , Cc: , , , References: <161954068804.26944.17229787113752757407@ietfa.amsl.com> <20210514204939.GT79563@kduck.mit.edu> In-Reply-To: <20210514204939.GT79563@kduck.mit.edu> Date: Fri, 14 May 2021 23:27:18 +0100 Organization: Old Dog Consulting Message-ID: <0bc601d74910$4d5e2980$e81a7c80$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQGfhifcib3FN4xzIVKSV+cLoH6O6AHhpPORq0Pwi2A= X-Originating-IP: 84.51.151.65 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-26158.003 X-TM-AS-Result: No--14.594-10.0-31-10 X-imss-scan-details: No--14.594-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-26158.003 X-TMASE-Result: 10--14.594000-10.000000 X-TMASE-MatchedRID: yebcs53SkkCWfDtBOz4q23FPUrVDm6jtXUj+PNjK1CdqVUf9uFDF77pw 13cpdYiJ/JaizffSpx5RtfXoTDaXPezxNaI2BL2holVO7uyOCDVPnKxAOPp4Wb0/f33kf9Glvnw 7ZHJ1DYYkG+UY2925NvbE9hfTw1eynZzvVk+DChsD2WXLXdz+ARSDigi5VOU4u6MsHJ4FQbsZSo o/qXcOYwJ+6mz26lKe/X+ZXsL37qNuhaARsScJxrhijfgSVFJ1j0jXY9STMgEgcEd8uJSjxMuqg 1GEYpai7miCDRooc+//r5gkcWVinwWjWKO5zae3exVKHJlPnb+UUZS7sMHOGPkuQv9PIVnNwKZn 0gfq1S9e94WXino6Vh6nlH/P8z5H6sRuS6yGtfS3RxL+7EfzsKVjgXyvS9c/f2dEskHXJhDNMek K6/5CVHVFbUF/FpHRcLqAjziI0ICE6GalAjvSeYPe0oBVRFzqGwKs3RUcsbjc+SicUxUH2fNaEi m+BfVwW0x8QuGBj889BExxfLcaQrD+pPA6qyNrcI7vRACwF0IpA2ExuipmWr+Z3Zp2Td1EWFKSj ziASXKVAyuXyaQ1poucwSE+eOjH5+QQ0CmE7ka3qEXNc7Ck+eMN8V7dEb9VVQ8e/B1BvGji6BdQ hTPL+huK7sMmZXPxmUiQ1kGSNgaJRB8rkHg4zbSlePUaQB97vMRNh9hLjFkINpIFnbd6mqWZBcT XbSNOuuDlOjqV6B8UE0GosBGBG00JYny2Na55hL+1W6GVmJs8lvugAFiFPx9W4auM/sn0YEFgyG mAA+CNMcuIWrGqGQfiO+cO1L/KaDAi8sBNMoFQlMmlBevIRZuTdmBzA9G/DMq3z/Y/gtUgBwKKR He+r4cnipngwgWSwTajsXuavK3WJCVUaEgnkuJzacyD9+O7+q3tgwYJvsQ= X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-bess-datacenter-gateway-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2021 22:27:29 -0000 Hi Ben, Apologies and especially to Daniel. > I don't see any responses to this review in the mailarchive. It looks like > it was even sent before the end of the IETF LC, so I'm pretty = surprised > that there was no response. (I'm particularly interested in the last > question about the security considerations.) I think I read as far as... > Reviewer: Daniel Migault > Review result: Ready >=20 > Hi, >=20 > Review result: Ready ...and stopped. No issues, no nits, come back to the clarifications = later. Sigh. Well, it is "later" so I'm on target. > I reviewed this document as part of the Security Directorate's ongoing effort > to review all IETF documents being processed by the IESG. =A0These = comments were > written primarily for the benefit of the Security Area Directors. =A0However, in > this case these comments mostly reflect some question to clarify my = own > understanding. Document authors, document editors, and WG chairs = should treat > these comments just like any other IETF Last Call comments. >=20 > Yours, > Daniel >=20 > Just to clarify my understanding of Fig 1. BGP usually selects the = best route, > so if AS1-AS2 is the best, none=A0of the traffic will go through AS3. However > even in this configuration AS2 will select one of the GW and all = traffic will > go only to one of the GW1 or GW2. The Add-Path might be able to distinguishes > between AS1-AS2 and AS3 but AS1-AS2 cannot be subdivided between two = paths one > that would terminates in GW1 and another that would terminates at GW2. Right.=20 What you stated is exactly the problem that we needed to resolve with = this document. The document explains the problem. And, as you note (and the draft notes) Add-Path is only a solution in = some cases, but not in general. > I am not sure following acronyms may be expanded as well as AFI/SAFI = being > described with text as opposed to their values. I let you decide = whether that > is needed or not. You're right. Mysteriously, AFI/SAFI are not listed as well-known at https://www.rfc-editor.org/materials/abbrev.expansion.txt 1. I'll update the draft 2. I'll ping the RPC > OLD: > =A0An IPv4 or IPv6 NLRI containing one of the GW's loopback addresses > =A0 =A0 =A0 (that is, with an AFI/SAFI pair that is one of 1/1, 2/1, = 1/4, or > =A0 =A0 =A0 2/4). >=20 > NEW > =A0An IPv4 or IPv6 Network Layer Reachability Information (NLRI) = [RFC4760] > containing one of the GW's loopback addresses (that is, with an = Address Family > Number (AFI)/ Subsequent Address Family (SAFI) pair that is one of IPv4/NLRI > used for unicast forwarding (1/1), IPv6/NLRI used for unicast = forwarding > (2/1), IPv4/NLRI with MPLS Labels (1/4), or IPv6/NLRI with MPLS = Labels (2/4)). OK. Something like that will go in. > Security consideration: >=20 > When the information is shared between the domains, I am wondering if = the > information is encrypted or if the communication appears in clear = text. If no > encryption is used, that information is actually not limited to the = two domains > but to anyone on path can read it. If that is the case, information provided by > the Egress SR domain to the Ingress SR Domain seems to me transiting through > the backbone which makes the information pretty much public. I am wondering if > I am missing something. Maybe the current text in Section 8 is not clear enough on this point. = Or rather, it in oblique in its approach to this issue. You are right on exactly this. It is the same problem as in a VPN - information about the sites at the edge of the network is carried across = the network in BGP messages. Those messages could reveal the information = unless they are protected. BGP is (of course) carried over TCP, and TCP can be protected. This is = being clarified in answer to one of the points John Scudder raised in his = review. Thanks, Adrian From nobody Mon May 17 20:09:59 2021 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C8E3F3A1AD2; Mon, 17 May 2021 20:09:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Magnus Nystrom via Datatracker To: Cc: draft-ietf-idr-bgp-flowspec-oid.all@ietf.org, idr@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162130739076.21940.5228836987347937240@ietfa.amsl.com> Reply-To: Magnus Nystrom Date: Mon, 17 May 2021 20:09:50 -0700 Archived-At: Subject: [secdir] Secdir telechat review of draft-ietf-idr-bgp-flowspec-oid-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2021 03:09:51 -0000 Reviewer: Magnus Nystrom Review result: Has Nits I was asked to re-review -14 after my review of -13. I'd like to thank the authors for making updates based on my review of -13. The only additional suggestion I have is to ad a clarifying statement after the sentence "If the condition of the peer is unknown, the rule SHOULD not be enforced" along the lines of "As mentioned above, this does represent a security risk." From nobody Tue May 18 03:04:33 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 395BB3A15EB for ; Tue, 18 May 2021 03:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 iXPkocZX8pGn for ; Tue, 18 May 2021 03:04:26 -0700 (PDT) Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (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 5CE0C3A15E7 for ; Tue, 18 May 2021 03:04:26 -0700 (PDT) Received: from imap.open-xchange.com (imap.open-xchange.com [84.81.54.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx4.open-xchange.com (Postfix) with ESMTPSA id C692C6A0DC; Tue, 18 May 2021 12:04:24 +0200 (CEST) Received: from plato ([84.81.54.175]) by imap.open-xchange.com with ESMTPSA id /YjOLyiRo2CxHQAA3c6Kzw (envelope-from ); Tue, 18 May 2021 12:04:24 +0200 Message-ID: <02781d07a6a65dd350a49a53566842f36ee486f3.camel@powerdns.com> From: Peter van Dijk To: "Konda, Tirumaleswar Reddy" , "secdir@ietf.org" Date: Tue, 18 May 2021 12:04:24 +0200 In-Reply-To: References: Organization: PowerDNS.COM B.V. Content-Type: multipart/alternative; boundary="=-s25EbwE2q39i3XGy0fY/" User-Agent: Evolution 3.30.5-1.1 MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] [DNSOP] Secdir last call review of draft-ietf-dnsop-nsec-ttl-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2021 10:04:31 -0000 --=-s25EbwE2q39i3XGy0fY/ Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Mon, 2021-05-03 at 09:46 +0000, Konda, Tirumaleswar Reddy wrote: > > > Reviewer: Tirumaleswar Reddy > Review result: Ready > > I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These reviews are primarily for the benefit of the Security ADs. Document editors and WG chairs > should treat these comments just like any other last call comments. > > > > > I think the Security Considerations section is adequate in its coverage to address the attack not handled in a number of RFCs the document will update. > Thank you! Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ --=-s25EbwE2q39i3XGy0fY/ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
On Mon,= 2021-05-03 at 09:46 +0000, Konda, Tirumaleswar Reddy wrote:

Reviewer: Tirumaleswar Reddy

Review result: Ready

 

I have reviewed this document as part of the securit= y directorate's ongoing effort to review all IETF documents being processed= by the  IESG.  These reviews are primarily for the benefit of th= e Security ADs. Document editors and WG chairs should treat these comments just like any other last call comments.

I think the Security Considerations section is ad= equate in its coverage to address the attack not handled in a number of RFC= s the document will update.


Thank you!

=
Kind regards,
= --
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
--=-s25EbwE2q39i3XGy0fY/-- From nobody Tue May 18 11:31:56 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E7343A1CA0; Tue, 18 May 2021 11:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.596 X-Spam-Level: X-Spam-Status: No, score=-9.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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 header.b=IFvfjOYU; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=AYcubKBY 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 8AsKGZY8q9qc; Tue, 18 May 2021 11:31:49 -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 C9F713A1B5D; Tue, 18 May 2021 11:31:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1570; q=dns/txt; s=iport; t=1621362708; x=1622572308; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=lB4jsZw4ZMnY/U55d3WLDjSrHNX+cQIUwXMwetbjz90=; b=IFvfjOYU+QwQ1mtQShwxb+zeR56gzESTNaQWQx0VFSsYWX42qesgU5of UpP6LuxHgPr1mzkAPIBbi/rdFsYgm6AksKFHy+vFa9eAXh9qnw9YISbLR 247qTtX8TYm9Bw+OPZgsoTLuFqKgelKXJdIjKAaZgLhq4iTx1vGWIb9/z s=; X-IPAS-Result: =?us-ascii?q?A0AHAADVBqRgmIUNJK1aGwEBAQEBAQEBBQEBARIBAQEDA?= =?us-ascii?q?wEBAUCBQwYBAQELAYFSUYFYNjELhDyDSAOEWWCIdgOZaoEugSUDVAsBAQENA?= =?us-ascii?q?QE/AgQBAYRPAheBXQIlNAkOAgQBAQEBAwIDAQEBAQUBAQUBAQECAQYEFAEBA?= =?us-ascii?q?QEBAQEBaIVQDYZEAQEBBCMRDAEBNwELBAIBCBEEAQEDAiYCAgIwFQgIAgQBD?= =?us-ascii?q?QUIgmmCVgMvAQOeJAKKH3qBMoEBggcBAQYEBIUfGIITCYEQKgGCeoQOhlonH?= =?us-ascii?q?IFJRIFYgl8+hCsagxU2gi2BWIFWBEOBDxl6DA2Ue6cMCoMWmAWFWxGlPpU3p?= =?us-ascii?q?AcCAgICBAUCDgEBBoFUOIFbcBWDJFAXAg6OHwwNCYNOil1zOAIGCgEBAwl8i?= =?us-ascii?q?wMBgRABAQ?= IronPort-PHdr: A9a23:AaE49xfRf615hlWV7Ml7PkZNlGM/r4qcDmcuAtIPhLdHc6Dl9JPnb wTT5vRo2VnOW4iTq/dJkPHfvK2oX2scqY2Av3YPfN0pNVcFhMwakhZmDJuDDkv2f/HvZi0+W s9FUQwt83SyK0MAHsH4ahXbqWGz6jhHHBL5OEJ1K+35F5SUgd6w0rW5+obYZENDgz/uCY4= IronPort-HdrOrdr: A9a23:ordju6iGRxt1wHUQoGGBhfthrXBQXw913DAbv31ZSRFFG/FwyP rOoB1L73HJYWgqN03IwerwR5VpQRvnhPlICPoqTMmftW7dySqVxeBZnMXfKljbexEWmdQtrp uIH5IObeEYSGIK8foSgzPIU+rIouP3ipxA7N22pxwGIG0aCNAD0+46MHfnLqQcfnghOXNNLu vl2iMxnUvYRZ14VLXeOlA1G8z44/HbnpPvZhALQzQ97hOVsD+u4LnmVzCFwxY3SVp0sPQf2F mAtza8yrSosvm9xBOZ/XTU9Y5qlNzozcYGLNCQi/ISNi7nhm+TFcZcsvy5zXUISdOUmREXee r30lEd1gNImirsl1SO0F/QMs/boW4TAjHZuASlaDDY0L3ErXoBerp8bMRiA0HkA45KhqAh7E qNtFjp6qa/RCmw7xjV9pzGUQpnmVGzpmdnmekPj2ZHWY9bc7NJq5cDlXklXavoMRiKo7zPKt MeRv00JcwmB29yZEqp8lWHAObcFkjbOy32DXTqlvblpwS+rUoJhnfwnvZv60vo3KhNPKWsyd 60QJhVqA== X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.82,310,1613433600"; d="scan'208";a="740719731" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 18 May 2021 18:31:47 +0000 Received: from mail.cisco.com (xbe-rcd-005.cisco.com [173.37.102.20]) by alln-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 14IIVlZs019616 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Tue, 18 May 2021 18:31:47 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xbe-rcd-005.cisco.com (173.37.102.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.792.15; Tue, 18 May 2021 13:31:46 -0500 Received: from xfe-rcd-005.cisco.com (173.37.227.253) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Tue, 18 May 2021 14:31:45 -0400 Received: from NAM02-DM3-obe.outbound.protection.outlook.com (72.163.14.9) by xfe-rcd-005.cisco.com (173.37.227.253) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Tue, 18 May 2021 13:31:45 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=biTvIuexJ6WmOyyT+gFfjyoGvc7SvRC7v58VWPOST7JhsROoxKD+Wb4UnX1WY5MeXs/lQ3lgswaY8LPyL+PjfbmbR9rShF/UAUK/nzyPl65Digu7JUi4NOmSO7D7Zc1tzdjv/xeUGcNuTjNJVl2oQmER8s9b3nk0unBFTaqzrOM7e0ZoAlSjHb9Qof/0+mT4lFyRapkEmdWyK4IhvVDhfUxhzXdgZWO/SKDp8TvWhvOApFGHtsjxwVIujs6QvxBTfnjZPzax32gyKwHbESPGuDiKsJq970L0QuaVysNCo22LKgyal8RXnAzTwwLTXNbZ0ax/wZquYNxsTBW7tijeiw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lB4jsZw4ZMnY/U55d3WLDjSrHNX+cQIUwXMwetbjz90=; b=cQj2XU++uzm3JbSq2jdaivPu6Lx8fS5Hedwy1d6cXYlZswCY5W1AgmuLoADNhoIbCij7Cl/SYLCt3Q4wDNwLH5USMBB93Zrwds9ZcEwMUBXHSPyZpOT9e15+HMZbJMcInSuHSVnx3C5SlG0cE+yiCWOSdq+9O6K7Vg5lCP0xbemNsWDd/iG5Bl5WhZ7P/mf9mRGoHnCqVMXrq9N/COFkPGOd5oXQFQXcyaUp4L8okgdXO081lJopVBq774WoX60vBfiZ+Grbkw8WOfq5tgtjLg42WjMfEENLacSUBN2UWQ7c5+/pZdZ2P2UIMQovR0FYD+Up9WhavwjyhCCFrR742w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lB4jsZw4ZMnY/U55d3WLDjSrHNX+cQIUwXMwetbjz90=; b=AYcubKBYr2dwDCHrVWkGqnEgTJpy/0JFVJC5KHnn9+BW7h4J/7prsnAzH3/v7gM6rVLvzJoxIkTrYsKDjeoK8d4kUxWA5rKaRTALquXu6bPvQdVLRrna7w/jX6wonFd9YQNMDXJ8Uu8FtzjR5wjJ8HQRzudpXLjuar9jAnM/1M4= Received: from BL1PR11MB5416.namprd11.prod.outlook.com (2603:10b6:208:319::22) by BL1PR11MB5239.namprd11.prod.outlook.com (2603:10b6:208:31a::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4129.26; Tue, 18 May 2021 18:31:44 +0000 Received: from BL1PR11MB5416.namprd11.prod.outlook.com ([fe80::95e1:5bbb:188a:1aed]) by BL1PR11MB5416.namprd11.prod.outlook.com ([fe80::95e1:5bbb:188a:1aed%7]) with mapi id 15.20.4129.031; Tue, 18 May 2021 18:31:44 +0000 From: "Juan Alcaide (jalcaide)" To: Magnus Nystrom , "secdir@ietf.org" CC: "draft-ietf-idr-bgp-flowspec-oid.all@ietf.org" , "idr@ietf.org" , "last-call@ietf.org" Thread-Topic: Secdir telechat review of draft-ietf-idr-bgp-flowspec-oid-14 Thread-Index: AQHXS5NNB9w8FFwMXUKOXI3DxAHAdarpkMQw Date: Tue, 18 May 2021 18:31:44 +0000 Message-ID: References: <162130739076.21940.5228836987347937240@ietfa.amsl.com> In-Reply-To: <162130739076.21940.5228836987347937240@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [83.38.90.229] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 32699b3c-f5c3-4a18-8ea0-08d91a2b306d x-ms-traffictypediagnostic: BL1PR11MB5239: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: cZmjeKuUlMzNnsCnB+LXe+sHIVeqdOZkNKRat4o99irlZIT/v+Vjl8c5CljJ3XupJ+JDnoFDUSLAf7NURIDd+MRDuxhQJ4Ur4eXK62D6Oh1+GGzkJGIMeNiVHpnG95/BxiB1UjCa8s0uqZlJUSenwdeZbgr41x4ey68OBS4R0his50Rwo/3OCokDDqaHwJdQxePSb+ZcbKS1p++0YJdKywVUOFQ2ydO5B9+JyZfOJET0qdgVpZXZ1V03mA7fRuHGSIc132M5dbkcjHLM1OcdwAP/prKG9ALNFaDOWVk/toHFtWWbivpHK73u3zsXyFam9JdLp80xcSnXYEvxJS29oW6TNe8tKr2nv21m5BWWdYmHJDEtFfbP2dMA0R+KikYyrodwr1YSxdp2o3msl3IKeO6LV8nEWm0a5yXnVUyDF2ubvcbydwcYZlg04/o7bHCJeS+3fWdMVZLVkbEtPEOHjKD46TJtGth6/m4qufdTp13SIk+ksQonUACTTBNjPZ8vv2kZ7M8xn2qHa/98xJGYhV/HMt3oTi/dqcGmesu1SARRLor++0MfScbhKFYIofj8uImkhTqrCueLSKZoBOh+0YdhI5qh499IDJ5Fw8lqUUY= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL1PR11MB5416.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(376002)(346002)(39860400002)(396003)(366004)(136003)(4326008)(55016002)(9686003)(6506007)(53546011)(186003)(33656002)(38100700002)(122000001)(316002)(5660300002)(2906002)(478600001)(52536014)(110136005)(54906003)(8676002)(83380400001)(8936002)(26005)(7696005)(66946007)(66446008)(76116006)(64756008)(66556008)(66476007)(71200400001)(86362001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?K3htWjlVTFJvSnZmcmtaRnJZZUF6R0tIQlhxWGlHOTRhcGpEK3VsTDlDQ1FC?= =?utf-8?B?cDU3dTEwdUkzTHczaXNiTWZvRC9xMWUrek5wc21wVWxTUDZxNmJRMGdhK0Ni?= =?utf-8?B?dVY5aE4rOFYveHNHMlprT2ZLODg4UmJpNkoyVTl6SGFEeGduellMT29zNzhG?= =?utf-8?B?VndqTDhPRVBmeXp3MkdEeWhYU2ptZXIrenNSMzM1UCt2aWFoaUpSYVRmd2lY?= =?utf-8?B?dmxVR0swYzF6eERNT0pJZlVwbm5KeWR3N2I2SGtkZzhRSXdMVnBXQXpLUEVN?= =?utf-8?B?S3RxQTc0NXR2NEZnd0VtTi85eTFZb2F6dnRIcEpHVmxud2o2S3hBUWY0c0JL?= =?utf-8?B?OFBLb1p3c0xQNlNZNmpzNFRtSERuNDFxWFlKcXhjK05vcnB2bXo0bklyZVhH?= =?utf-8?B?WkdhSGRGbEFCRVhDL2tQOVl6V3U1REROcTBqSkNtVDd0UlBFMzNzRVBGMmlU?= =?utf-8?B?YzZJMW96Q1JvMkJPckRCbXcyNUVnZFFtYVdkdDRIalU1djN2cyt3VWM4SHRn?= =?utf-8?B?UE5RdDgwTFcycWJhYzVsS1hIc0NtYVpFQW1iK2FFREdBTk1sd2Rtd29IbElz?= =?utf-8?B?OEJTSGkrdEZhdUdveVZpMXJBOUR1dmhwWEhndTR3d2NaZFh3VEUwT0V0RnlL?= =?utf-8?B?TkxLMFU4VzdFcVBGUEFueEZJMnJZbUhoQSsyVnY5M2lKOHBDR0ZyaWg2VjMx?= =?utf-8?B?aWxnWDRVTEJFU1BVZGlJazhxUFJJQWZMSkE5VGs5VlNKMWgzOFRMK0UzeXJW?= =?utf-8?B?ejBzb0NMVUFGVnpwSDVaNFlUbS9TMFhsVjgvWFkvUE54ZEtVallBT0s1OTdY?= =?utf-8?B?WFRGWEFDenU3RWpFaUZwYUM0TFBtS1FEY05xU1o2NDg4NnlTMUE2ZmwybjB3?= =?utf-8?B?UEdqcVdXYkd1QWdDN0ZaUUREY2ZZVEtPVmRnVmhBVmd6SUNTUEYyZzVMbWZx?= =?utf-8?B?Uy9lZjJ2bUlJNTE1YUYxa0grNndEM0pDWUtxa2dIZ3daaGVkcXI3TUdVb2Rq?= =?utf-8?B?TjlDb1lwN0RPZ203bTAvR3d5eVpSVi8wbzV2Wk1HeUd3SWxQamIvU25IdUEz?= =?utf-8?B?d2w2Z3A5MlpwQ3ozSlRJK1VNL2hreHZqM0l5djF1Y0dmYnVndVovbmZ6d2NE?= =?utf-8?B?ZVRqMzhna3c0LzRnSXdPVEdxcjRVQkVxRHJEclRZWDRFN1ErKzVSenp4WVJD?= =?utf-8?B?WTJyUWkyUldoeUgybUFCN0hNUzlETFNJY0ZLNE50WFIrOUQ4Nm5QUnJlQ1RX?= =?utf-8?B?Y1NmNmNJZC9VeVZJdWZLR0F2T2NBaFIvT3pRMW13YzFXNlVnWDYyR2ZVRUE5?= =?utf-8?B?RXBRYllzUzducGVPU2hNRnFIRTVhb3U0OUtzWXFVd2NiUzFBODMwV2t5RnhW?= =?utf-8?B?WWw5aGcvN0tMMEY0U2FJdDVnajB3TUlSOEZNa3BhYVg4cWlKT3hoUEY5OVRU?= =?utf-8?B?SUkvK285cE9yWUdEck1zV0hDb3VnQjVYRmhhd1BWcnlRL015THlObml4WmxK?= =?utf-8?B?QUxSK1FMcm03MThVRFYyNVo0dno5bzJDZWV6dkNGSjV2RHI1R1I3cnUraWpy?= =?utf-8?B?KzhNWlo3OGwyZWZ1cjVCWVJvTlpsd3JtdGR4N2JIZFUzcFpTSFp4QUY2U1Ar?= =?utf-8?B?aFJGSXNxM1lWZGI4aE55YWNuTkU3dklicXBVc3AyTlJlRk96Mkh6S1Y1M3RO?= =?utf-8?B?REtkaWpZRWg5aFZ4SUd4SWtXSmZMMjEzNVhPWDl4R3R0eldhNnBENWRCYVpI?= =?utf-8?Q?yeSFwWa79/ycPaDc8s=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BL1PR11MB5416.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 32699b3c-f5c3-4a18-8ea0-08d91a2b306d X-MS-Exchange-CrossTenant-originalarrivaltime: 18 May 2021 18:31:44.6982 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: DzOQ5J0kQNMQ9SKnPvvXcMqdldWhW6M/bIQ37yASvx2uMaPXnL0lpjlPlUWl1cbVks+nDGPUT/nHMnpZ2KkJ7w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL1PR11MB5239 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.20, xbe-rcd-005.cisco.com X-Outbound-Node: alln-core-11.cisco.com Archived-At: Subject: Re: [secdir] Secdir telechat review of draft-ietf-idr-bgp-flowspec-oid-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2021 18:31:54 -0000 VGhhbmtzIE1hZ251cywNCg0KQmFzZWQgb24gc2V2ZXJhbCBmZWVkYmFjaywgSSBwbGFuIHRvIG1v ZGlmeSB0aGF0IHBhcmFncmFwaCBhczoNCg0KIg0KICAgSWYgY29uZmlndXJhdGlvbiAob3Igb3Ro ZXIgbWVhbnMgYmV5b25kIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50KSANCmluZGljYXRlcyB0 aGF0IHRoZSBwZWVyIGlzIG5vdCBhIHJvdXRlIHNlcnZlciwgdGhhdCBvcHRpb25hbCBydWxlIA0K U0hPVUxEIGJlIGVuZm9yY2VkLiBJZiB0aGUgaW5kaWNhdGlvbiBpcyB0aGF0IHRoZSBwZWVyIGlz IG5vdCBhIHJvdXRlIHNlcnZlciBvciB0aGVyZSBpcyBubyBjb25jbHVzaXZlIGluZGljYXRpb24s IHRoYXQgb3B0aW9uYWwgcnVsZSBTSE9VTEQgTk9UIGJlIGVuZm9yY2VkLg0KIg0KDQpIb3BlIGl0 J3MgZ29vZA0KDQotSg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTWFnbnVz IE55c3Ryb20gdmlhIERhdGF0cmFja2VyIDxub3JlcGx5QGlldGYub3JnPiANClNlbnQ6IFR1ZXNk YXksIE1heSAxOCwgMjAyMSA1OjEwIEFNDQpUbzogc2VjZGlyQGlldGYub3JnDQpDYzogZHJhZnQt aWV0Zi1pZHItYmdwLWZsb3dzcGVjLW9pZC5hbGxAaWV0Zi5vcmc7IGlkckBpZXRmLm9yZzsgbGFz dC1jYWxsQGlldGYub3JnDQpTdWJqZWN0OiBTZWNkaXIgdGVsZWNoYXQgcmV2aWV3IG9mIGRyYWZ0 LWlldGYtaWRyLWJncC1mbG93c3BlYy1vaWQtMTQNCg0KUmV2aWV3ZXI6IE1hZ251cyBOeXN0cm9t DQpSZXZpZXcgcmVzdWx0OiBIYXMgTml0cw0KDQpJIHdhcyBhc2tlZCB0byByZS1yZXZpZXcgLTE0 IGFmdGVyIG15IHJldmlldyBvZiAtMTMuIEknZCBsaWtlIHRvIHRoYW5rIHRoZSBhdXRob3JzIGZv ciBtYWtpbmcgdXBkYXRlcyBiYXNlZCBvbiBteSByZXZpZXcgb2YgLTEzLiBUaGUgb25seSBhZGRp dGlvbmFsIHN1Z2dlc3Rpb24gSSBoYXZlIGlzIHRvIGFkIGEgY2xhcmlmeWluZyBzdGF0ZW1lbnQg YWZ0ZXIgdGhlIHNlbnRlbmNlICJJZiB0aGUgY29uZGl0aW9uIG9mIHRoZSBwZWVyIGlzIHVua25v d24sIHRoZSBydWxlIFNIT1VMRCBub3QgYmUgZW5mb3JjZWQiIGFsb25nIHRoZSBsaW5lcyBvZiAi QXMgbWVudGlvbmVkIGFib3ZlLCB0aGlzIGRvZXMgcmVwcmVzZW50IGEgc2VjdXJpdHkgcmlzay4i DQoNCg0K From nobody Tue May 18 13:16:09 2021 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2451D3A0889; Tue, 18 May 2021 13:16:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Paul Wouters via Datatracker To: Cc: draft-ietf-i2nsf-capability-data-model.all@ietf.org, i2nsf@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162136896309.19274.13384213577960243417@ietfa.amsl.com> Reply-To: Paul Wouters Date: Tue, 18 May 2021 13:16:03 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-i2nsf-capability-data-model-16 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2021 20:16:03 -0000 Reviewer: Paul Wouters Review result: Has Nits I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review Has Nits The issues that Michael Scharf raised regarding TOS have been addressed. Thank you. I have no items that are serious issues, just some comments that you may take into consideration for a minor update. Nits: The privacy section talks about a trade-off between privacy and security. But I do not understand what trade-off is meant. The document does not seem to make any trade-off. It just defines capabilities that can be used, some of which might process private material. But the trade-offs of that are really at the protocol level (like they did use TLS or IPsec or why not). I dont think describing technical capabilities is a trade-off of security vs privacy. Perhaps the section could talk about the discovery and/or usage of capabilities and that those capabilities handling private information should attempt to report their usage/findings/events underst conditions that preserve the privacy (eg require TLS or IPsec between SG and NSF ?) The Security section talks about layers that "can use" SSH or TLS for security. I'm not sure why it does not say SHOULD or MUST ? I would rewrite "need to be tightly secured and monitored" to "MUST be tightly secured, monitored and audited". Section 3.1 states: These capabilities MAY have their access control restricted by a policy; In light of the other recommendations in the Security Section, I think this MAY should really be a SHOULD or even MUST. Alternatively, perhaps say "Some of these capabilities SHOULD" ? From nobody Tue May 18 18:19:59 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C042A3A180B; Tue, 18 May 2021 18:19:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HK_NAME_FM_MR_MRS=1.498, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 GObuQ-UXiqJ9; Tue, 18 May 2021 18:19:48 -0700 (PDT) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::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 9CAD83A1809; Tue, 18 May 2021 18:19:44 -0700 (PDT) Received: by mail-lj1-x233.google.com with SMTP id o8so13664125ljp.0; Tue, 18 May 2021 18:19:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5h4CdaBnSN9xQoJ7sxharQH8D0NTjwe6DFPZsOXi1OQ=; b=tDkPqIhhzSOMdHdNz8QQapoJYAnjOnE7G9NaS4qNL8c+KP+uf31w0A2w7lkbyAWScT BYfWQG9Jvqav7npZaz1qyK8IHP3+QWaq0LuyrBVE+f/9LxK9ECZ7bVWyw0yohcRZCVIy MXLSz90a2zxlXpARCtss7HT3+74rrvr1i9kVbdra7XCu5Cj8KoXbxd5UgMG1KlRvphbE RyXKCnTPr9vmxnfd494G12Rs7yE7Sq/2kf9VFLgiiYxAYBCA0xYJeIwjmSMYNYw0nDyN c4mTrgtL2Ze6HY1v3gEaKMtM+jbteW8LANYZwxDvx/Vq/RrOOG/loDRtrxnHF4S3jZTJ miTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5h4CdaBnSN9xQoJ7sxharQH8D0NTjwe6DFPZsOXi1OQ=; b=s/nTWRVBS28vYs+5H8d+/FDfjkhEzP2OgO6WE3z7YTHgA+iCOyRrzZKSUTzOaFIL73 owGATQiHjRMswfe7oArejQ9ZjVNXh1nnUPESU6KCBjico92984VwseLF/O3GCKB7uccH y6Y00N5WSqbqXeuInSKMzqkF50Ns8BJA99/tlR+4q/tuabsHzaIyltv/+dkR8CVOhU4P lfrPP8Cu1X49H32PsIqqMYJaEff1aTf7S9xZQZAC2HUiDixNWCzcmh/j9UKoMYxQKxLf 3uYAdYICrV0nfUGRkLsKfLcL6L+dixzHdYew7EXAPXxFmb+PUGccns2pgz+irFO/wb2s x25w== X-Gm-Message-State: AOAM533W511TnBAhGy6gn8Hrrk9AVTfstAbD4Omw4WgObOOSw7l3WWc0 rHT7lsnnO6bHk4VLED22yhOptfUKH5L1Lc2ZKgg= X-Google-Smtp-Source: ABdhPJxSKvUOMEw7nUoZdQO8xFn+OEzFyl/D89izUzH8z2WvsydU4zIGjDvdWT/AxHg0GYLUisAiyqDGPel718Mflio= X-Received: by 2002:a2e:b0d6:: with SMTP id g22mr2009337ljl.349.1621387177600; Tue, 18 May 2021 18:19:37 -0700 (PDT) MIME-Version: 1.0 References: <162136896309.19274.13384213577960243417@ietfa.amsl.com> In-Reply-To: <162136896309.19274.13384213577960243417@ietfa.amsl.com> From: "Mr. Jaehoon Paul Jeong" Date: Wed, 19 May 2021 10:19:02 +0900 Message-ID: To: Paul Wouters Cc: secdir@ietf.org, draft-ietf-i2nsf-capability-data-model.all@ietf.org, "i2nsf@ietf.org" , Last Call , Patrick Lingga , skku-iotlab-members , "Mr. Jaehoon Paul Jeong" Content-Type: multipart/alternative; boundary="000000000000c3aa6a05c2a49eb7" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-i2nsf-capability-data-model-16 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 May 2021 01:19:51 -0000 --000000000000c3aa6a05c2a49eb7 Content-Type: text/plain; charset="UTF-8" Hi Paul, I will address your comments on the Security Section. Thanks for your valuable comments to improve our draft. Best Regards, Paul Jeong On Wed, May 19, 2021 at 5:16 AM Paul Wouters via Datatracker < noreply@ietf.org> wrote: > Reviewer: Paul Wouters > Review result: Has Nits > > I have reviewed this document as part of the security directorate's > ongoing > effort to review all IETF documents being processed by the IESG. These > comments were written primarily for the benefit of the security area > directors. > Document editors and WG chairs should treat these comments just like any > other > last call comments. > > The summary of the review Has Nits > > The issues that Michael Scharf raised regarding TOS have been addressed. > Thank > you. I have no items that are serious issues, just some comments that you > may > take into consideration for a minor update. > > Nits: > > The privacy section talks about a trade-off between privacy and security. > But I > do not understand what trade-off is meant. The document does not seem to > make > any trade-off. It just defines capabilities that can be used, some of which > might process private material. But the trade-offs of that are really at > the > protocol level (like they did use TLS or IPsec or why not). I dont think > describing technical capabilities is a trade-off of security vs privacy. > Perhaps the section could talk about the discovery and/or usage of > capabilities > and that those capabilities handling private information should attempt to > report their usage/findings/events underst conditions that preserve the > privacy > (eg require TLS or IPsec between SG and NSF ?) > > The Security section talks about layers that "can use" SSH or TLS for > security. > I'm not sure why it does not say SHOULD or MUST ? I would rewrite "need to > be > tightly secured and monitored" to "MUST be tightly secured, monitored and > audited". > > Section 3.1 states: > > These capabilities MAY have their access control restricted by a > policy; > > In light of the other recommendations in the Security Section, I think > this MAY > should really be a SHOULD or even MUST. Alternatively, perhaps say "Some of > these capabilities SHOULD" ? > > > > > > > --000000000000c3aa6a05c2a49eb7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Paul,
I will address your comments on the Security = Section.

Thanks for your valuable comments=C2=A0to= improve our draft.

Best Regards,
Paul J= eong

On Wed, May 19, 2021 at 5:16 AM Paul Wouters via Datatracker <= noreply@ietf.org> wrote:
Reviewer: Paul Wouters<= br> Review result: Has Nits

I have reviewed this document as part of the security directorate's=C2= =A0 ongoing
effort to review all IETF documents being processed by the=C2=A0 IESG.=C2= =A0 These
comments were written primarily for the benefit of the security area direct= ors.
=C2=A0Document editors and WG chairs should treat these comments just like = any other
last call comments.

The summary of the review Has Nits

The issues that=C2=A0 Michael Scharf raised regarding TOS have been address= ed. Thank
you. I have no items that are serious issues, just some comments that you m= ay
take into consideration for a minor update.

Nits:

The privacy section talks about a trade-off between privacy and security. B= ut I
do not understand what trade-off is meant. The document does not seem to ma= ke
any trade-off. It just defines capabilities that can be used, some of which=
might process private material. But the trade-offs of that are really at th= e
protocol level (like they did use TLS or IPsec or why not). I dont think describing technical capabilities is a trade-off of security vs privacy. Perhaps the section could talk about the discovery and/or usage of capabili= ties
and that those capabilities handling private information should attempt to<= br> report their usage/findings/events underst conditions that preserve the pri= vacy
(eg require TLS or IPsec between SG and NSF ?)

The Security section talks about layers that "can use" SSH or TLS= for security.
I'm not sure why it does not say SHOULD or MUST ? I would rewrite "= ;need to be
tightly secured and monitored" to "MUST be tightly secured, monit= ored and
audited".

Section 3.1 states:

=C2=A0 =C2=A0 These capabilities MAY have their access control restricted b= y a policy;

In light of the other recommendations in the Security Section, I think this= MAY
should really be a SHOULD or even MUST. Alternatively, perhaps say "So= me of
these capabilities SHOULD" ?






--000000000000c3aa6a05c2a49eb7-- From nobody Thu May 20 14:45:57 2021 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C04D3A0857 for ; Thu, 20 May 2021 14:45:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 7.29.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <162154715522.12498.10704178372674664918@ietfa.amsl.com> Date: Thu, 20 May 2021 14:45:55 -0700 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 May 2021 21:45:55 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2021-05-20 Reviewer LC end Draft Kathleen Moriarty 2021-04-27 draft-ietf-bess-mvpn-msdp-sa-interoperation Tina Tsou 2021-05-03 draft-ietf-idr-eag-distribution Dacheng Zhang 2021-05-03 draft-ietf-idr-eag-distribution Last calls: Reviewer LC end Draft John Bradley 2021-03-16 draft-ietf-idr-bgp-ls-registry Shaun Cooley 2021-02-25 draft-ietf-v6ops-ipv6-ehs-packet-drops Alan DeKok 2021-03-24 draft-ietf-cbor-tags-oid Daniel Gillmor 2021-03-26 draft-ietf-lamps-crmf-update-algs Phillip Hallam-Baker 2019-12-13 draft-ietf-ace-oauth-authz Steve Hanna 2021-03-22 draft-ietf-regext-secure-authinfo-transfer Christian Huitema R2021-06-01 draft-ietf-dtn-bpsec-default-sc Leif Johansson None draft-ietf-netconf-crypto-types Aanchal Malhotra None draft-ietf-opsawg-l3sm-l3nm Catherine Meadows 2021-04-14 draft-ietf-ntp-interleaved-modes Kathleen Moriarty 2021-04-27 draft-ietf-bess-mvpn-msdp-sa-interoperation Russ Mundy 2021-04-20 draft-ietf-dprive-xfr-over-tls Sandra Murphy R2021-04-05 draft-ietf-dmarc-psd Sandra Murphy 2020-10-15 draft-ietf-tls-external-psk-importer Yoav Nir 2021-04-28 draft-ietf-core-new-block Melinda Shore 2021-05-17 draft-ietf-payload-rtp-jpegxs Robert Sparks 2021-05-24 draft-ietf-bmwg-evpntest Carl Wallace R2021-02-22 draft-ietf-tcpm-2140bis Samuel Weiler 2021-02-22 draft-ietf-tls-dtls13 Brian Weis 2021-02-19 draft-ietf-lamps-cms-aes-gmac-alg Klaas Wierenga 2020-12-02 draft-ietf-core-echo-request-tag Klaas Wierenga 2020-05-26 draft-ietf-kitten-krb-spake-preauth Liang Xia 2021-03-17 draft-ietf-core-sid Early review requests: Reviewer Due Draft Sean Turner 2021-06-30 draft-ietf-anima-constrained-voucher Loganaden Velvindron 2021-06-11 draft-ietf-masque-ip-proxy-reqs Paul Wouters 2021-02-19 draft-ietf-idr-bgp-ls-app-specific-attr Next in the reviewer rotation: Mališa Vučinić Carl Wallace Samuel Weiler Brian Weis Klaas Wierenga Paul Wouters Liang Xia Dacheng Zhang Derek Atkins John Bradley From nobody Thu May 20 19:35:34 2021 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E4F83A0FEC; Thu, 20 May 2021 19:35:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Paul Wouters via Datatracker To: Cc: draft-ietf-idr-bgp-ls-app-specific-attr.all@ietf.org, idr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.30.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162156453202.16583.7878225218187327569@ietfa.amsl.com> Reply-To: Paul Wouters Date: Thu, 20 May 2021 19:35:32 -0700 Archived-At: Subject: [secdir] Secdir early review of draft-ietf-idr-bgp-ls-app-specific-attr-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 May 2021 02:35:32 -0000 Reviewer: Paul Wouters Review result: Has Nits I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is Has Nits In section 3 it lists 1092 as "TE Metric" but RFC 7522 lists it as "TE Default Metric". And 1116 is listed as "Unidirectional link delay variation" but RFC 8571 lists it as "Unidirectional Delay Variation". And 1117 shows "packet loss" vs "link loss". There are more subtle differences. Maybe ensure these terms are synced up better, unless there is a reason these terms are different/updated ? Link attributes that do not have application-specific semantics SHOULD NOT be advertised within the ASLA TLV. Is there a reason why this is SHOULD NOT and not MUST NOT? In other words, do you have an example of where the SHOULD NOT would not apply? And if so, should that be mentioned here? Same for the following SHOULD case, In section 4, "[RFC8920] " appears without an actual link. It's either missing the xref target, or there is a bug in rendering the xml to html? grammar nit: CURRENT: They were originally defined PROPOSED: These were originally defined From nobody Fri May 21 05:17:23 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AA243A0AE7; Fri, 21 May 2021 05:17:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.595 X-Spam-Level: X-Spam-Status: No, score=-9.595 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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 header.b=Oa/1gdyB; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=kmeNbn3N 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 Z1I38J8mOJPj; Fri, 21 May 2021 05:17:11 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 744E33A0AE1; Fri, 21 May 2021 05:17:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2788; q=dns/txt; s=iport; t=1621599431; x=1622809031; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=+84T9kkp7R5mVYI70Wp0re45N1MM5fOzAfivBgbrVV4=; b=Oa/1gdyBCt7Cs8VxNAZ+xAvEa3am6s9WCJSXmELaQ81KAHaPRNO3F/7T mKU6T2ZwA0gndZwIavh3/gTqdgRwT7AcJFYcSO2oiSG6lkvMDKlqrDZ+H OjTez8PK4xasz+eNhh+qPvh+jxKyeHqdsAYoEcjkn1FFIboeiJ5uBfdGn c=; X-IPAS-Result: =?us-ascii?q?A0A7AABfpKdgl4MNJK1aGgEBAQEBAQEBAQEDAQEBARIBA?= =?us-ascii?q?QEBAgIBAQEBQIFXgVNRgVg2MQuEPYNIA4U5iHcDgQ2YbIJTA1QLAQEBDQEBP?= =?us-ascii?q?wIEAQGETwIXgWcCJTgTAgQBAQEBAwIDAQEBAQUBAQUBAQECAQYEFAEBAQEBA?= =?us-ascii?q?QEBaIVoDYZEAQEBBCMRDAEBNwELBAIBCBEEAQEDAiYCAgIwFQgIAgQBDQUIg?= =?us-ascii?q?mmCVgMvAU2dTgKKH3qBMoEBggcBAQYEBIU4GIITCYEQKgGCeoQOhlonHIFJR?= =?us-ascii?q?IEVQ4IpNj6ERYMVNoItgkQGAjwmAQMNNg4iMAcoGXoBGJR8pgmBDAqDF5gSh?= =?us-ascii?q?WARg1qLGZZXlTqfNoRiAgQCBAUCDgEBBoEjSCKBW3AVgyRQFwIOjh8Zg1eKX?= =?us-ascii?q?XM4AgYKAQEDCXyHQQGBEAEB?= IronPort-PHdr: A9a23:eVbbmRJqahsO596ZUNmcuXsyDhhOgF28FggS6pM7kPRFe/fr85fjO RnZ4vNgxB/MUJ7A4v1Jw+zRr+j7WGMG7JrA1RJKcJFFWxIfz8lDmQsmDZ2DDk3yMOWsZCVpV MhHXUVuqne8N0UdEc3iZlrU93u16zNaGhj2OQdvYOrvHYuHhMWs3Of08JrWMG11 IronPort-Data: A9a23:jEBVDaIgKATOb6+RFE+Rr5UlxSXFcZb7ZxGr2PjKsXjdYENS1WdWz 2ZJXj2OMq6ONmX0edlwOY2zoB8B65ODnYdmTFQd+CA2RRqmiyZq6fd1j6vUF3nPRiEWZBs/t 63yUjRDRSwNZie0Si2FatANllEhk/HSLlbAILScYHkpGFU9EH5JZS9LwobVvKY52bBVPCvV0 T/Ci5W31IiNgmMc3so8sspvmTs31BjAkGpwUm8WOZiniGTje0w9V/rzE00ew0zQGeG4FsbiL wrKISrQEmnxp3/BAfv9+lr3n9FjrrP6ZWCzZnRqt6eKhAJQpxFqlYACCrkmVQBSzDm3wdVKx 4AY3XCwYV9B0qzkkeAZVVxTFDtzePQA877cKn/5usuWp6HEWyKzmLM1UgdvZstBob8f7WJmr ZT0LBgOYwyKgf6ey7OgQe4qjcMmRCXuFNxG5yA5kW6BV57KR7jxHImW4v1z4QwCrfhqEOzyS uUTWz1wOUGojxpnYwdLV81WcP2TrnjzaRVZpU6b460t7AD7wBZ43qSoMdfJdJmLSd8QlEmA4 2bdum3hGlQBLNGUyDSE+TelmvPV2yr/XKoTGaG2sPlwjzW73WEYBBwMfVq2vff/jVSxM/pHI lEQ0iwpraEu7wqgR7HAswaQqXqAuFsXXMBdVrR84wCWwa2S6AGcboQZctJfQNo8ps4LHXsM7 2HKpe+uAHtjjuOQcn3Io994sgiO1TgpwX4qPHFeFFFUsoi6+OnfnTqUFY4ySv7dYsndXGCun WzX8EDSkp1O1aY2O7OHEUcrat5GjrHNSgMzjuk8dj34tlsjDGJJinDB1LQ2xf9EKIDcRV6bs T1d8yR/0AzsJczW/MBuaLxQdF1M2xpjGGaN6bKIN8J+nwlBA1b5IehtDMhWfS+FyPronAMFh meN5Gu9A7cNZROXgVNfOOpd9uxzl/G7TIS5PhwqRoQePvCdizNrDAk3NRLPgAgBYWAHkLo0P t+gYN2wAHMBYZmLPxLnGrdBgOND+8zK/kuOFMuT50n2jtKjiIu9FO5t3K2mNbhpsstpYWz9r r5iCid940UOCLGhOnGPr+b+7zkidBAGOHw/kOQPHsbrH+asMDhJ5yP5qV/5R7FYog== IronPort-HdrOrdr: A9a23:S+20dK0NMM4KlQckIKCZGQqjBWdyeYIsimQD101hICG9Lfb4qy n+ppomPEHP5wr5AEtQ5uxpOMG7MBThHO1OkPcs1NCZLUjbUQqTXc9fBO7ZowEIdBeOjdK1uZ 0QFpSWTeeAcWSS7vyKoDVQcexQuuVvmZrA7Yy1ohsdLnAJV0gj1XYFNu/xKDwReOAyP+tAKH Pq3Ls/m9PPQwVyUu2LQl0+G8TTrdzCk5zrJTQcAQQ81QWIhTS0rJbnDhmxxH4lInBy6IZn1V KAvx3y562lvf3+4ATbzXXv45Nfn8ak4sdfBfaLltMeJlzX+0SVjcVaKvi/VQIO0aaSAWUR4Z /xStAbTp1OAkbqDyWISN3WqlHdOXgVmiTfIBSj8AreSITCNUIH4ox69Nhkmt+z0Tt9gDm6u5 g7gl5x/qAnfi/ojWDz4cPFWAptkVfxqX0+kfQLh3gaSocGbqRNxLZvsX+9Pa1wVx4S0rpXWt WGzfusksq+emnqI0wxflMfiOBEe05DUStubnJyzvB94gIm1UyRlXFosfD3tk1wg67VZaM0ld j5Dg== X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.82,319,1613433600"; d="scan'208";a="715914702" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 21 May 2021 12:17:10 +0000 Received: from mail.cisco.com (xbe-rcd-007.cisco.com [173.37.102.22]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 14LCH91r025945 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Fri, 21 May 2021 12:17:09 GMT Received: from xfe-rcd-005.cisco.com (173.37.227.253) by xbe-rcd-007.cisco.com (173.37.102.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Fri, 21 May 2021 07:17:09 -0500 Received: from xfe-aln-004.cisco.com (173.37.135.124) by xfe-rcd-005.cisco.com (173.37.227.253) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Fri, 21 May 2021 07:17:09 -0500 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (173.37.151.57) by xfe-aln-004.cisco.com (173.37.135.124) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Fri, 21 May 2021 07:17:09 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SmTH7sJ5vC7nR21/ifyPRjfH4f0XhJVHOUY+kVNQPTlajjHP6AoXkDbg61ko4af8qx6fwrnsCEhgWpE4rhjifzdXLLq2jq/s5j96AkGTFO0zjRkicAnjiatuZN/1sjSq+QXRr3IuYO585kP44VDGlKyKCdvKEowSqGtcCo6ISrh5c7ofko4EtsfQM1lQw0OmYEW87MBla709hCgEFJgbhXGfnAgOjwxrviRMRZ9Sz8gMRAlvC/wzxAmbgfx3Sjj355JDBbi8pWx76F+k29Ox2VNB4EEK3yxKNDYvAKvKGLR1HvFOG5TNv0sZGClSyfCXOy8PfCH4vECcPzpuS3fmLA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+84T9kkp7R5mVYI70Wp0re45N1MM5fOzAfivBgbrVV4=; b=eg60zikvULjFfl4Sc9IfBfKTJURy5NQSk6Xzy7DWwCKsFrbugUw0kYTIfyDHuRq1xzCLBCeO76xaJCLEMX9uoeQ/1V/cHL7XGFMpxUQ2RMLrEosJpvJJhJH3jeQYJ/KnF1SMiFUTg30/XyhgSq7hvzGScGn+mkRZ7bpdiXQ5a6H2v3QG2pFIPTAQwUnf4mRFzmZ9KG/JDft4x4O+BnpTbRGqOsIl5Qc80MPBJjo7FI2KjB2hY3RlbDHdR7AXguHWg2XLfqEOUjHBENN99eRTW7aeEXWgP5Vpv2r8x6SJi102IOHuogSTysWLnAqG9/9vgfo+aT2ya+REY1e+CP+HpA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+84T9kkp7R5mVYI70Wp0re45N1MM5fOzAfivBgbrVV4=; b=kmeNbn3NCdU+DJzBkxRgUOsWfwC4UFKHkZcQAbG1RWnc/o1LKrcJfDs0GOfKH26NpDGFWxMsVitB57XNXbBJxegoC8jvgUF9iKz5uXDzpIsEQZctbbMhK+3kNamcZB/x3AwKtM6tf5TJdDdnv9uPx/NkkBnNR0BLaa7CkJNjzB4= Received: from MW3PR11MB4570.namprd11.prod.outlook.com (2603:10b6:303:5f::22) by MW3PR11MB4697.namprd11.prod.outlook.com (2603:10b6:303:2c::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4129.26; Fri, 21 May 2021 12:17:07 +0000 Received: from MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::592f:2e19:cf5b:a0f5]) by MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::592f:2e19:cf5b:a0f5%5]) with mapi id 15.20.4129.035; Fri, 21 May 2021 12:17:07 +0000 From: "Ketan Talaulikar (ketant)" To: Paul Wouters , "secdir@ietf.org" CC: "draft-ietf-idr-bgp-ls-app-specific-attr.all@ietf.org" , "idr@ietf.org" Thread-Topic: Secdir early review of draft-ietf-idr-bgp-ls-app-specific-attr-05 Thread-Index: AQHXTeoF2VcqF++be0S0jVpGL2lZn6rtZUcg Date: Fri, 21 May 2021 12:17:07 +0000 Message-ID: References: <162156453202.16583.7878225218187327569@ietfa.amsl.com> In-Reply-To: <162156453202.16583.7878225218187327569@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: nohats.ca; dkim=none (message not signed) header.d=none;nohats.ca; dmarc=none action=none header.from=cisco.com; x-originating-ip: [72.163.220.23] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c0b1a543-c351-419f-0fee-08d91c525a24 x-ms-traffictypediagnostic: MW3PR11MB4697: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ndE2Z/65GSMrgRDeRgdVLxneLMJJh3wepY3Oo+WWk3sMt96VaecPtpWP7bcEhAipCh7wbXZ05WqlW76gZdO5XEuCNFqGGARMb7cZ5maHkIkngTUwo0qg052vMslT+JrZEwNBHvxk0Pset5x00k8/WJCs/HfdSBfpJsUaKYHN2fXJvwJ6sV3lMkI2s4z940rGgizQJEERXivkIDYEDzXUYIl2hqzqfnF8LzmZqQ01w/2FLiCOB07qOgjQILcsVVXgB2r8uZAsZ3YqXcqLaWu9hLU1OxHtpO5mncja3l86amBVkfUK9ehX0iGGPU3mS2VyItF/1x4m9R/y/doCosiydLzxX6H3hKinFvY1L6Sn0jzbj0fUVMIE9rwSRNlZ+yeMQns5FXT8mFmu0YW+1beiipaorDfywE/OkZbeWHGcAaV9CyQYO41gEdx8yS8Mi4xed6A4bBjzmFvJQCQjKZnaBLjn/fbOpl+Hv3IR+RsexYMbYSCEwBJNyGvWDBduMhJbcNqCrlwafpoQMpLYygmlLC96DwTbGxxqBcNeL4cFEfvc86fHo7vRoeCq4CC+tdi82K8Ph8i8k7bOFa7wTYkL9qTyP78jXM+bzLM+uwbnq8E= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW3PR11MB4570.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(136003)(376002)(39860400002)(366004)(396003)(38100700002)(122000001)(7696005)(86362001)(33656002)(8936002)(54906003)(26005)(4326008)(71200400001)(53546011)(76116006)(6506007)(110136005)(83380400001)(478600001)(8676002)(316002)(5660300002)(55016002)(2906002)(52536014)(66446008)(64756008)(66556008)(9686003)(66476007)(66946007)(186003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?TnovdGZRelpsU2FZcndNTE52MTBWUVdhVVJRNTBqemtsZkRHcGVOenRCYlJL?= =?utf-8?B?djQ4OEc1RFF6VUtJSjVFbW5ZdThDVnkraWxES3BVaVBHY2tsa01aL1hHMjBC?= =?utf-8?B?V0RrVUI5aWlMRHBsVjQ1NHJzV0w2Zkh5anE4K0U1TlRZR1VzZTlQQnlwYlNK?= =?utf-8?B?QWFYSVYxbzB3dFhDRVI1QnRFbUc2eVVVUm04enZ2YnM1SmR3ZEJibnF3SXd6?= =?utf-8?B?QmdMeThObUFPMFdNMGhEZU15YTFScE12bitoUWNDUWZzb2htQklhUjQvdnJP?= =?utf-8?B?UWpoMUwwL1pNM3FPeVYrWUFIeW5sTVBLdnpzVktRY2xKUGVOUERzbmlJcFhp?= =?utf-8?B?VUFuV3ZMRXZGb25ReUp3dVUxTUNIbWluTEljZVVwWDNQZjRuOXRVV3VGWlhN?= =?utf-8?B?R04zNzRwdndrTCtnbUNJc1ozd1h0cTVrd0daNXZWcllQUXRlUjM5aTdvSXli?= =?utf-8?B?U1FncVhjU3VGMm5lUkxUSE1RTXVpM1JXQldnV29JWDRlMXdvanlSa0tBV2Vm?= =?utf-8?B?UitmU3FyTk9OU08yVWlDeFZEZ0tQRWhqZDRVcFh5cGtKK0xLcHpGUkU2aEkv?= =?utf-8?B?dklTUWhQYW9oWEFFTEx4S0RvM3RCNU95OXVyZDlxMHdlNkl0bDZocVQ1Lzk0?= =?utf-8?B?UHowWE1QclQzM051L3Zqb05IeGhVZWFYWnZSMnFFb1dqeGpsc1NtYTJBOTIv?= =?utf-8?B?M2NNMzh6Y25rL3lRV1l5TXJCc2hLbzVsbGhDQ1VYR2g1UjhVc3g2SEhrcVNw?= =?utf-8?B?SkJqaUVUZFltUkh0TkwzRUZ5dU9wdWNuMzRhWHlQLzAzdmRJV1BSeHZsTlVH?= =?utf-8?B?dDAvVHAzb3NjK2R6c3pJYkFjeUpoMFNtaGg4dEljTC85OFpoREJhQXV3UG1I?= =?utf-8?B?dHBJbDcwRUxUZ1RaQkJPUkUyd21yQXU4LzNYV3RYNy9sYUp2MVF6cmhQSG1Z?= =?utf-8?B?d2hxNllUOWlqelZrVGt2bitydVhGYjNIN0dXMjBmM2o1bVlhWStQS3hCNlVK?= =?utf-8?B?dHlzS3VYSk55Q3hKNDRtcHIrQ09KOFpLSmdpWU1NbmMrWVlQcVN3RGFZTHM3?= =?utf-8?B?bThZZ2ZCaDFIeUtWWVVLVVNwYkQ1ODdvLzhKa0FQT3pxSTBFV1JZdHZpREFh?= =?utf-8?B?SWFDQzFHcmpUVFdqT2VDQkltRSsrTERYb2VMZ2hXTExYbFNxOU8yaG90QkMz?= =?utf-8?B?bTR1U0o5Ui82Z1FXV21EdzdGMFpxOVdoQVZYOHJPek9QcW11RU5CN1E2cWly?= =?utf-8?B?VVpzb3dPWXFlQVlQQ2pmWlhGVjk0Vndka0Zid2NCUWE0YjlhRFAxMk1QMWlj?= =?utf-8?B?UG12VFFEdlZIc0dpZk5odERpeHpabDYybFozanZJamJjazVTTWtWNTZNNVRj?= =?utf-8?B?SnpXRmZtUWphUTFOWU9OaHZCcUh5b1h2QmVPOTU4dWJwZis1MUlKLzFTWUMz?= =?utf-8?B?QThoa3VIQ1YwUmxkMmpibHZBRzRVSWpzRlZiZFZOeElPRWwwNk5xS1RNeVpR?= =?utf-8?B?NGl1ZlNCV09UdElkajlrSHF3OUdCYlgzVCtIbWNEU1I1aVk2RmZZQUJjT0JH?= =?utf-8?B?b1VCN0RFemN2dVIvMkRKOVcrSUN6cWJzTUNSbFZKSUVrZVhTSGgxQXhCVHQw?= =?utf-8?B?dEdVOWtKMGZCNGpyYTBwa2pmOWh0OVpMRmNnRmZGSVoyd1RVVHYrQ002N0xG?= =?utf-8?B?TEREL0daZU80VEJRL29CQm5KVUw1QUJZUlNqbHRSY1UxZ0ptZS9tNzN0Ti9a?= =?utf-8?Q?QMm7KiOvBVyMxFwLdtyCkjmdQEGqJT2LdNQWluu?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MW3PR11MB4570.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c0b1a543-c351-419f-0fee-08d91c525a24 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 May 2021 12:17:07.2962 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 5LxyX0gbwe2CcLJw5n1I/stBXgiuiTyfJvmLxEctzjIB9EgIRfWBH5uuOaCLMvN4pGzxPpgumjII3MJzXx6KXA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW3PR11MB4697 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.22, xbe-rcd-007.cisco.com X-Outbound-Node: alln-core-1.cisco.com Archived-At: Subject: Re: [secdir] Secdir early review of draft-ietf-idr-bgp-ls-app-specific-attr-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 May 2021 12:17:18 -0000 SGkgUGF1bCwNCg0KVGhhbmtzIGZvciB5b3VyIHJldmlldyBhbmQgcGxlYXNlIGNoZWNrIGlubGlu ZSBiZWxvdyBmb3IgcmVzcG9uc2VzLg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJv bTogUGF1bCBXb3V0ZXJzIHZpYSBEYXRhdHJhY2tlciA8bm9yZXBseUBpZXRmLm9yZz4gDQpTZW50 OiAyMSBNYXkgMjAyMSAwODowNg0KVG86IHNlY2RpckBpZXRmLm9yZw0KQ2M6IGRyYWZ0LWlldGYt aWRyLWJncC1scy1hcHAtc3BlY2lmaWMtYXR0ci5hbGxAaWV0Zi5vcmc7IGlkckBpZXRmLm9yZw0K U3ViamVjdDogU2VjZGlyIGVhcmx5IHJldmlldyBvZiBkcmFmdC1pZXRmLWlkci1iZ3AtbHMtYXBw LXNwZWNpZmljLWF0dHItMDUNCg0KUmV2aWV3ZXI6IFBhdWwgV291dGVycw0KUmV2aWV3IHJlc3Vs dDogSGFzIE5pdHMNCg0KSSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0 aGUgc2VjdXJpdHkgZGlyZWN0b3JhdGUncyAgb25nb2luZyBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJ RVRGIGRvY3VtZW50cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhlICBJRVNHLiAgVGhlc2UgY29tbWVu dHMgd2VyZSB3cml0dGVuIHByaW1hcmlseSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlICBzZWN1cml0 eSBhcmVhIGRpcmVjdG9ycy4gIERvY3VtZW50IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBzaG91bGQg dHJlYXQgIHRoZXNlIGNvbW1lbnRzIGp1c3QgbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1l bnRzLg0KDQpUaGUgc3VtbWFyeSBvZiB0aGUgcmV2aWV3IGlzIEhhcyBOaXRzDQoNCkluIHNlY3Rp b24gMyBpdCBsaXN0cyAxMDkyIGFzICJURSBNZXRyaWMiIGJ1dCBSRkMgNzUyMiBsaXN0cyBpdCBh cyAiVEUgRGVmYXVsdCBNZXRyaWMiLiBBbmQgMTExNiBpcyBsaXN0ZWQgYXMgIlVuaWRpcmVjdGlv bmFsIGxpbmsgZGVsYXkgdmFyaWF0aW9uIiBidXQgUkZDDQo4NTcxIGxpc3RzIGl0IGFzICJVbmlk aXJlY3Rpb25hbCBEZWxheSBWYXJpYXRpb24iLiBBbmQgMTExNyBzaG93cyAicGFja2V0IGxvc3Mi DQp2cyAibGluayBsb3NzIi4gVGhlcmUgYXJlIG1vcmUgc3VidGxlIGRpZmZlcmVuY2VzLiAgTWF5 YmUgZW5zdXJlIHRoZXNlIHRlcm1zIGFyZSBzeW5jZWQgdXAgYmV0dGVyLCB1bmxlc3MgdGhlcmUg aXMgYSByZWFzb24gdGhlc2UgdGVybXMgYXJlIGRpZmZlcmVudC91cGRhdGVkID8NCltLVF0gR29v ZCBjYXRjaCEgRml4ZWQgdGhlbSBhbGwuDQoNCiAgICAgIExpbmsgYXR0cmlidXRlcyB0aGF0IGRv IG5vdCBoYXZlIGFwcGxpY2F0aW9uLXNwZWNpZmljIHNlbWFudGljcyBTSE9VTEQNCiAgICAgIE5P VCBiZSBhZHZlcnRpc2VkIHdpdGhpbiB0aGUgQVNMQSBUTFYuDQoNCklzIHRoZXJlIGEgcmVhc29u IHdoeSB0aGlzIGlzIFNIT1VMRCBOT1QgYW5kIG5vdCBNVVNUIE5PVD8gSW4gb3RoZXIgd29yZHMs IGRvIHlvdSBoYXZlIGFuIGV4YW1wbGUgb2Ygd2hlcmUgdGhlIFNIT1VMRCBOT1Qgd291bGQgbm90 IGFwcGx5PyBBbmQgaWYgc28sIHNob3VsZCB0aGF0IGJlIG1lbnRpb25lZCBoZXJlPyANClNhbWUg Zm9yIHRoZSBmb2xsb3dpbmcgU0hPVUxEIGNhc2UsDQpbS1RdIFRoaW5raW5nIG92ZXIgaXQgbm93 LCBJIGRvIG5vdCBzZWUgYSByZWFzb24gZm9yIHRoZSBTSE9VTEQuIFdpbGwgY2hhbmdlIGl0IHRv IE1VU1QgdW5sZXNzIHNvbWVvbmUgYmVsaWV2ZXMgaXQgbmVlZHMgdG8gc3RheSBhcyBpdCBpcy4N Cg0KSW4gc2VjdGlvbiA0LCAiW1JGQzg5MjBdICIgYXBwZWFycyB3aXRob3V0IGFuIGFjdHVhbCBs aW5rLiBJdCdzIGVpdGhlciBtaXNzaW5nIHRoZSB4cmVmIHRhcmdldCwgb3IgdGhlcmUgaXMgYSBi dWcgaW4gcmVuZGVyaW5nIHRoZSB4bWwgdG8gaHRtbD8NCltLVF0gTG9va3MgbGlrZSBhbiB4bWwy cmZjIHJlbmRlcmluZyBpc3N1ZS4NCg0KZ3JhbW1hciBuaXQ6DQpDVVJSRU5UOiAgVGhleSB3ZXJl IG9yaWdpbmFsbHkgZGVmaW5lZA0KUFJPUE9TRUQ6IFRoZXNlIHdlcmUgb3JpZ2luYWxseSBkZWZp bmVkDQpbS1RdIEFjay4NCg0KVGhhbmtzLA0KS2V0YW4NCg0KDQoNCg0K From nobody Fri May 21 16:41:28 2021 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B2D893A0CFB; Fri, 21 May 2021 16:41:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Phillip Hallam-Baker via Datatracker To: Cc: ace@ietf.org, draft-ietf-ace-oauth-authz.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.30.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162164047967.4459.16040288658397288714@ietfa.amsl.com> Reply-To: Phillip Hallam-Baker Date: Fri, 21 May 2021 16:41:19 -0700 Archived-At: Subject: [secdir] Secdir telechat review of draft-ietf-ace-oauth-authz-41 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 May 2021 23:41:20 -0000 Reviewer: Phillip Hallam-Baker Review result: Ready This draft was previously reviewed by Steve Kent for the -27 version. My review therefore mostly consists of checking that the changes recommended have been made and that no new issues have arisen. Note that contrary to the data in the tracker, I was not given the assignment in 2019. If you decide that you want to use OAUTH for authorization security for Internet of Things, this is a reasonable approach to take. This is not a simple proposition or for the fainthearted. OAuth is built around the various constraints of the browser world to which the constraints of being a constrained device are added. The issues raised by Steve have all been addressed as far as I can see. It looks good to go but since it is a security spec, ADs should still take note. From nobody Fri May 21 17:57:37 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D9103A077C; Fri, 21 May 2021 17:57:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 54PE9snHJ5kd; Fri, 21 May 2021 17:57:26 -0700 (PDT) Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (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 2E16A3A0799; Fri, 21 May 2021 17:57:23 -0700 (PDT) Received: by mail-qk1-x72f.google.com with SMTP id q10so21661128qkc.5; Fri, 21 May 2021 17:57:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GSgqCnOGf3q02VbhxCxBsG8YW+g6uAk6jnML3rr0xJk=; b=nSb/PyRtCAci1z+67slf2UJg7B7M0xY6eC+0stzHYWBZLMlhEiL3vIVbJa5GzpFvQi XlAuPpYvJ/z4HIHr80y1vRF9KkhKgaTSqqpdf0y6bedpMH/BrXmf2nTWjBumTeJ1fKM4 huFLlHIObTdOYbR51IQ0Ayo3Ds5wn6zQsBoLOmgb3KPoV9jbvoxL6KR3AzcKJ4gu9xsR 5SSF7PJpdvqeBjaPBZlo2NDHcrn3ZfMdUMa/IFcg+BT7zO33OV62RWgITAZPnZiQga27 d9YhdoS8FryWb6a9YQkhNqFZky95VdYZ8MzOwKQJWTF35CMmOW5X8e+7OPyqaP9bfUHE 9W/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GSgqCnOGf3q02VbhxCxBsG8YW+g6uAk6jnML3rr0xJk=; b=l2IQ2AX0aI8hmvsFJHZZR3xStFmzGE6NY0Cg/Lbcxql1RllsvT7fa4TR4lATkG1kCr mCpdIHsImx3Eod43Pcyrw/UQcP4xDNuBMlui9gYfk0ec5yivRRci3cwGIFSbMmJZy+Bz cv+IzF6isL7pqqPMwRKnVICN7xwpuNKPgTPk88C1Z1Ao2/mVweaHc4Pnipf1a1954W/C L3u555AKASdvCSVW/zxly72dM6Y5owux3Mkdc54CK9unhKsB9TOBaPEpkvIkXTOGzTKe LEr2jGG4hbNgCWUe0+4wRxapXxFRpD6XUooerbMRttvNU2zMNRff7VbH+PWRf35xqsNw UMYw== X-Gm-Message-State: AOAM531Ml4jnJHKxk5d2/E39TyCYTcaS/qPlDS4sshTHiShZJAZe0zU8 c69csF5dkDxUmO8GvzCruAXl8SzeOVzqt27K4KM= X-Google-Smtp-Source: ABdhPJxs87vDW6w+aaadQL60+YQok34FfExtRM4Re/redix2mMKKomv3e18QtT1oGKO0i7+z/3JgVVvD7MlKSdeelI4= X-Received: by 2002:a37:ae81:: with SMTP id x123mr15388599qke.251.1621645041435; Fri, 21 May 2021 17:57:21 -0700 (PDT) MIME-Version: 1.0 References: <162164047967.4459.16040288658397288714@ietfa.amsl.com> In-Reply-To: <162164047967.4459.16040288658397288714@ietfa.amsl.com> From: Daniel Migault Date: Fri, 21 May 2021 20:57:10 -0400 Message-ID: To: Phillip Hallam-Baker Cc: secdir@ietf.org, last-call@ietf.org, draft-ietf-ace-oauth-authz.all@ietf.org, Ace Wg Content-Type: multipart/alternative; boundary="000000000000a5885605c2e0a897" Archived-At: Subject: Re: [secdir] [Ace] Secdir telechat review of draft-ietf-ace-oauth-authz-41 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 May 2021 00:57:29 -0000 --000000000000a5885605c2e0a897 Content-Type: text/plain; charset="UTF-8" Thanks Phillip for the review. Yours, Daniel On Fri, May 21, 2021 at 7:41 PM Phillip Hallam-Baker via Datatracker < noreply@ietf.org> wrote: > Reviewer: Phillip Hallam-Baker > Review result: Ready > > This draft was previously reviewed by Steve Kent for the -27 version. My > review > therefore mostly consists of checking that the changes recommended have > been > made and that no new issues have arisen. Note that contrary to the data in > the > tracker, I was not given the assignment in 2019. > > If you decide that you want to use OAUTH for authorization security for > Internet of Things, this is a reasonable approach to take. This is not a > simple > proposition or for the fainthearted. OAuth is built around the various > constraints of the browser world to which the constraints of being a > constrained device are added. > > The issues raised by Steve have all been addressed as far as I can see. It > looks good to go but since it is a security spec, ADs should still take > note. > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > -- Daniel Migault Ericsson --000000000000a5885605c2e0a897 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Phillip for the review.=C2=A0

Yo= urs,=C2=A0
Daniel

On Fri, May 21, 2021 at 7:41 PM Phillip Hallam-Ba= ker via Datatracker <noreply@ietf.or= g> wrote:
Reviewer: Phillip Hallam-Baker
Review result: Ready

This draft was previously reviewed by Steve Kent for the -27 version. My re= view
therefore mostly consists of checking that the changes recommended have bee= n
made and that no new issues have arisen. Note that contrary to the data in = the
tracker, I was not given the assignment in 2019.

If you decide that you want to use OAUTH for authorization security for
Internet of Things, this is a reasonable approach to take. This is not a si= mple
proposition or for the fainthearted. OAuth is built around the various
constraints of the browser world to which the constraints of being a
constrained device are added.

The issues raised by Steve have all been addressed as far as I can see. It<= br> looks good to go but since it is a security spec, ADs should still take not= e.


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


--
Daniel Migault
Ericsson
--000000000000a5885605c2e0a897-- From nobody Sat May 22 08:28:29 2021 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 205133A10F1; Sat, 22 May 2021 08:28:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Sparks via Datatracker To: Cc: bmwg@ietf.org, draft-ietf-bmwg-evpntest.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.30.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162169730408.30071.8159768796287685820@ietfa.amsl.com> Reply-To: Robert Sparks Date: Sat, 22 May 2021 08:28:24 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-bmwg-evpntest-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 May 2021 15:28:24 -0000 Reviewer: Robert Sparks Review result: Has Nits I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document is essentially ready for publication as an Informational RFC, but with nits. Document reviewed: draft-ietf-bmwg-evpntest-07 This document describes a set of lab-environment characterization tests to be performed on isolated networks. The document has basic formatting issues (line and page length) that should be addressed before submission for publication as an RFC. The document does not discuss how the use of any of the mechanisms discussed in RFC7432 (and the RFCs it relies on) for improving the security characteristics of the protocols in use would affect the measurements being made, though it seems to suggest that the lab mimic production configuration. Perhaps that could be stated more clearly. From nobody Mon May 24 07:45:46 2021 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 421103A2B21; Mon, 24 May 2021 07:45:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Loganaden Velvindron via Datatracker To: Cc: draft-ietf-masque-ip-proxy-reqs.all@ietf.org, masque@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.30.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162186754016.23166.6832667526146023583@ietfa.amsl.com> Reply-To: Loganaden Velvindron Date: Mon, 24 May 2021 07:45:40 -0700 Archived-At: Subject: [secdir] Secdir early review of draft-ietf-masque-ip-proxy-reqs-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2021 14:45:40 -0000 Reviewer: Loganaden Velvindron Review result: Has Nits I'm reviewing the document as part of the Security Directorate (SECDIR). -Wireguard is mentioned in section 2.2 but there is no link to the design of the wireguard protocol. -In section 3.9, there are no mention of techniques such as padding to mitigate the impact of traffic analysis. My understanding is that this is out of scope of the current Internet Draft. From nobody Mon May 24 13:13:40 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC4923A34B7; Mon, 24 May 2021 13:13:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, 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 spAKJiYTfnJq; Mon, 24 May 2021 13:13:30 -0700 (PDT) Received: from mail-yb1-xb30.google.com (mail-yb1-xb30.google.com [IPv6:2607:f8b0:4864:20::b30]) (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 82E483A34B6; Mon, 24 May 2021 13:13:29 -0700 (PDT) Received: by mail-yb1-xb30.google.com with SMTP id d14so31816702ybe.3; Mon, 24 May 2021 13:13:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TeqAQxtMuhmMC7C1dPP7ZpdtYQ1Xs7B69tzaUUGVXxs=; b=osW+FjcLsjYb5T3qHRKMNirNrXYFmtwQqvvedW98DTHaipYSL9LDIUJ+fB6N7ROpzE 6k3GMS6OXGEsVJAeHojl933AFi7vCGR+WbCRMvAcdcXZZbDGoU4mp37q5jpjrf+rQZgM qYiQWVkiBHx7pITNyH2DriQ7KrZ/D7lF7D04hahmMzu8OXPLDVnKGlOfYBqaLl1Vq7hE SrOyw5S273ghkcCH6TKFy1jfvbAfm+/Az3qQiHZ93vzx+l6+PmjDdRZid4ONUI41VMV6 JnwM8A3ojdPQuO/3c0+AFFR2/5RIcJlfbLWySgAkPuxzkbAvwpPb1NU1ug1QyePWKF90 lQvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TeqAQxtMuhmMC7C1dPP7ZpdtYQ1Xs7B69tzaUUGVXxs=; b=LDBQZ7BTNHpaOXnRok2T98Y+qsHuTPXszmY7JlZL/PZE4zjp/lyFlhMG3EXmUV37Z9 /cKea+i8nyWBmG/W9/n6sH4scmWIj6P+/I5gJD2WZ7qMHaYYcxMeTp7OVXTW3Gv7ZE/1 RN6eZ7NncpoqCOcYQO3oBHWZDRbZHEvyDVOugCOP7+v3imtk76Q+Mak/xOVyU2hWU0YQ PsPUIJ8BB+VpFi56T3lmdWvPa/52q9f9hMHXXjjE2RhrxfzV+tP6vMAGtHG2Vr+NRJSs hF4XHG77PO86/ivGIfBWcAhVR2sH4U855dvutrKUJ/3P0IUgwZdw7QGAIf7jQZw+wlgA UbOQ== X-Gm-Message-State: AOAM532rulK1b8Cn6XKG6D7aHwwI91ySj6yr8VWNyVAigXD80CobdMdF qT82ZSneD2x7JUdiVAXahVeIBjMHoPpbh6EIGE8= X-Google-Smtp-Source: ABdhPJxcTz6sdmAOCNMeqhOw1fHfaknR7J40hmwNANO19E/SyLJifaVaOOPwMdu4XIHVKOLiImyfIOBBIk9bmVSgeV8= X-Received: by 2002:a25:7745:: with SMTP id s66mr18188084ybc.302.1621887207934; Mon, 24 May 2021 13:13:27 -0700 (PDT) MIME-Version: 1.0 References: <162164047967.4459.16040288658397288714@ietfa.amsl.com> In-Reply-To: From: Phillip Hallam-Baker Date: Mon, 24 May 2021 16:13:18 -0400 Message-ID: To: Daniel Migault Cc: secdir@ietf.org, last-call@ietf.org, draft-ietf-ace-oauth-authz.all@ietf.org, Ace Wg Content-Type: multipart/alternative; boundary="000000000000e510f005c3190a35" Archived-At: Subject: Re: [secdir] [Ace] Secdir telechat review of draft-ietf-ace-oauth-authz-41 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2021 20:13:35 -0000 --000000000000e510f005c3190a35 Content-Type: text/plain; charset="UTF-8" I am strongly minded to suggest a spinning plates model of security. Remember the vaudeville act with plates spinning on a stick, the performer gets one, two, five, ten going. And each time he adds a plate they have to go back to give one of the plates he started earlier another push. Well... I think this is at the very limit of the number of plates I can spin. On Fri, May 21, 2021 at 8:57 PM Daniel Migault wrote: > Thanks Phillip for the review. > > Yours, > Daniel > > On Fri, May 21, 2021 at 7:41 PM Phillip Hallam-Baker via Datatracker < > noreply@ietf.org> wrote: > >> Reviewer: Phillip Hallam-Baker >> Review result: Ready >> >> This draft was previously reviewed by Steve Kent for the -27 version. My >> review >> therefore mostly consists of checking that the changes recommended have >> been >> made and that no new issues have arisen. Note that contrary to the data >> in the >> tracker, I was not given the assignment in 2019. >> >> If you decide that you want to use OAUTH for authorization security for >> Internet of Things, this is a reasonable approach to take. This is not a >> simple >> proposition or for the fainthearted. OAuth is built around the various >> constraints of the browser world to which the constraints of being a >> constrained device are added. >> >> The issues raised by Steve have all been addressed as far as I can see. It >> looks good to go but since it is a security spec, ADs should still take >> note. >> >> >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace >> > > > -- > Daniel Migault > Ericsson > -- Website: http://hallambaker.com/ --000000000000e510f005c3190a35 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I a= m strongly minded to suggest a spinning plates model of security.

Remember the vaudeville act with p= lates spinning=C2=A0on a stick, the performer gets one, two, five, ten goin= g. And each time he adds a plate they have to go back to give one of the pl= ates he started earlier another push.

Well... I think this is at the= very limit of the number of plates I can spin.




On Fri, May 21, 2021 at 8:57 PM Daniel Migault <<= a href=3D"mailto:mglt.ietf@gmail.com">mglt.ietf@gmail.com> wrote:
T= hanks Phillip for the review.=C2=A0

Yours,=C2=A0
Dani= el

On Fri, May 21, 2021 at 7:41 PM Phillip Hallam-Baker via Datatracke= r <noreply@ietf.or= g> wrote:
Reviewer: Phillip Hallam-Baker
Review result: Ready

This draft was previously reviewed by Steve Kent for the -27 version. My re= view
therefore mostly consists of checking that the changes recommended have bee= n
made and that no new issues have arisen. Note that contrary to the data in = the
tracker, I was not given the assignment in 2019.

If you decide that you want to use OAUTH for authorization security for
Internet of Things, this is a reasonable approach to take. This is not a si= mple
proposition or for the fainthearted. OAuth is built around the various
constraints of the browser world to which the constraints of being a
constrained device are added.

The issues raised by Steve have all been addressed as far as I can see. It<= br> looks good to go but since it is a security spec, ADs should still take not= e.


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


--
Daniel Migault
Ericsson


--
Website: http://hallambaker.com/
--000000000000e510f005c3190a35-- From nobody Tue May 25 08:53:03 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A8C93A19D2; Tue, 25 May 2021 00:59:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1621929599; bh=F3yoSN5m4u4j7CA5hALXKeBiUAzPcucI7TAjsJzhQz0=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=DvCHCvEecSKV/hiethDiCTaf4eaHKv5p8dU6gONYcdj8RrctL6cxBbcHDeSVfD3ZX 8hc+Yyy04tmiPj32sHS8o1DgoXPyiqyGFdo/FlOhdkZo4uE0l5wkJPmm8UWU21H11s 3tgTRhwXCsOW9mdR0ZnrdYegKqNP9Ay4JfyQ6cFM= X-Mailbox-Line: From new-work-bounces@ietf.org Tue May 25 00:59:58 2021 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F77F3A19CA; Tue, 25 May 2021 00:59:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1621929598; bh=F3yoSN5m4u4j7CA5hALXKeBiUAzPcucI7TAjsJzhQz0=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=hfMP+xyeLf0aqJDz8NR/UHkDraNxzKd5SwwehBOlbjsh74eJJyC+JGVcTRtaREWvq AlWQgRYSP+CMNtfxqk32nCr8s2BkoA6LJ76KF7h+HbWgLftky3z9we6YzaUEphBUJQ 4CN+KOMUp449cgpSHBlUVj1llvV1sWLrzG1wmiGA= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A2773A19CA for ; Tue, 25 May 2021 00:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.905 X-Spam-Level: X-Spam-Status: No, score=-4.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.998, HK_RANDOM_FROM=0.998, RCVD_IN_DNSWL_HI=-5, 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 MVZdrL9rqy7I for ; Tue, 25 May 2021 00:59:55 -0700 (PDT) Received: from raoul.w3.org (raoul.w3.org [128.30.52.128]) (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 497A53A19C9 for ; Tue, 25 May 2021 00:59:55 -0700 (PDT) Received: from [85.203.23.94] (helo=jiaxueyuandeMacBook-Pro.local) by raoul.w3.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1llRyj-0004HF-EC for new-work@ietf.org; Tue, 25 May 2021 07:59:54 +0000 To: new-work@ietf.org From: xueyuan Message-ID: Date: Tue, 25 May 2021 15:59:48 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 Content-Language: en-US Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Precedence: list Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Tue, 25 May 2021 08:53:02 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: Media Working Group (until 2021-06-22/23) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 May 2021 08:00:02 -0000 SGVsbG8sCgpUb2RheSBXM0MgQWR2aXNvcnkgQ29tbWl0dGVlIFJlcHJlc2VudGF0aXZlcyByZWNl aXZlZCBhIFByb3Bvc2FsCnRvIHJldmlldyBhIGRyYWZ0IGNoYXJ0ZXIgZm9yIHRoZSBNZWRpYSBX b3JraW5nIEdyb3VwOgogwqAgaHR0cHM6Ly93d3cudzMub3JnLzIwMjEvMDUvY2hhcnRlci1tZWRp YS13Zy5odG1sCgpBcyBwYXJ0IG9mIGVuc3VyaW5nIHRoYXQgdGhlIGNvbW11bml0eSBpcyBhd2Fy ZSBvZiBwcm9wb3NlZCB3b3JrCmF0IFczQywgdGhpcyBkcmFmdCBjaGFydGVyIGlzIHB1YmxpYyBk dXJpbmcgdGhlIEFkdmlzb3J5CkNvbW1pdHRlZSByZXZpZXcgcGVyaW9kLgoKVzNDIGludml0ZXMg cHVibGljIGNvbW1lbnRzIHRocm91Z2ggMDM6NTkgVVRDIG9uIDIzIEp1bmUgMjAyMQooMjM6NTks IEVhc3Rlcm4gdGltZSBvbiAyMiBKdW5lKSBvbiB0aGUgcHJvcG9zZWQgY2hhcnRlci4KUGxlYXNl IHNlbmQgY29tbWVudHMgdG8gcHVibGljLW5ldy13b3JrQHczLm9yZywKd2hpY2ggaGFzIGEgcHVi bGljIGFyY2hpdmU6CiDCoCBodHRwOi8vbGlzdHMudzMub3JnL0FyY2hpdmVzL1B1YmxpYy9wdWJs aWMtbmV3LXdvcmsvCgpPdGhlciB0aGFuIGNvbW1lbnRzIHNlbnQgaW4gZm9ybWFsIHJlc3BvbnNl cyBieSBXM0MgQWR2aXNvcnkKQ29tbWl0dGVlIFJlcHJlc2VudGF0aXZlcywgVzNDIGNhbm5vdCBn dWFyYW50ZWUgYSByZXNwb25zZSB0bwpjb21tZW50cy4gSWYgeW91IHdvcmsgZm9yIGEgVzNDIE1l bWJlciBbMV0sIHBsZWFzZSBjb29yZGluYXRlCnlvdXIgY29tbWVudHMgd2l0aCB5b3VyIEFkdmlz b3J5IENvbW1pdHRlZSBSZXByZXNlbnRhdGl2ZS4gRm9yCmV4YW1wbGUsIHlvdSBtYXkgd2lzaCB0 byBtYWtlIHB1YmxpYyBjb21tZW50cyB2aWEgdGhpcyBsaXN0IGFuZApoYXZlIHlvdXIgQWR2aXNv cnkgQ29tbWl0dGVlIFJlcHJlc2VudGF0aXZlIHJlZmVyIHRvIGl0IGZyb20gaGlzCm9yIGhlciBm b3JtYWwgcmV2aWV3IGNvbW1lbnRzLgoKVGhlIGdyb3VwJ3MgY3VycmVudCBjaGFydGVyIGlzIGV4 dGVuZGVkIHVudGlsIDMwIEp1bmUgdG8gYWNjb21tb2RhdGUKdGhlIGNoYXJ0ZXIgcmV2aWV3IHBl cmlvZC4KIMKgIGh0dHBzOi8vd3d3LnczLm9yZy8yMDE5LzA1L21lZGlhLXdnLWNoYXJ0ZXIuaHRt bAoKSWYgeW91IHNob3VsZCBoYXZlIGFueSBxdWVzdGlvbnMgb3IgbmVlZCBmdXJ0aGVyIGluZm9y bWF0aW9uLCBwbGVhc2UKY29udGFjdCBGcmFuY29pcyBEYW91c3QsIFRlYW0gQ29udGFjdCBmb3Ig dGhlIE1lZGlhIFdvcmtpbmcgR3JvdXAsCmF0IDxmZEB3My5vcmc+LgoKVGhhbmsgeW91LAoKWHVl eXVhbiBKaWEswqAgVzNDIE1hcmtldGluZyAmIENvbW11bmljYXRpb25zCgpbMV0gaHR0cDovL3d3 dy53My5vcmcvQ29uc29ydGl1bS9NZW1iZXIvTGlzdAoKX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18KbmV3LXdvcmsgbWFpbGluZyBsaXN0Cm5ldy13b3JrQGll dGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV3LXdvcmsK From nobody Tue May 25 09:21:48 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFC6F3A13E7; Tue, 25 May 2021 09:21:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NONE=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 rNYed789wqL9; Tue, 25 May 2021 09:21:37 -0700 (PDT) Received: from xyz.hosed.xyz (xyz.hosed.xyz [71.114.67.91]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F9443A13E3; Tue, 25 May 2021 09:21:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xyz.hosed.xyz (Postfix) with ESMTP id AE11813C1D86; Tue, 25 May 2021 12:21:32 -0400 (EDT) X-Virus-Scanned: Debian amavisd-new at xyz.hosed.xyz Received: from xyz.hosed.xyz ([127.0.0.1]) by localhost (xyz.hosed.xyz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3gKoMHHDA3F7; Tue, 25 May 2021 12:21:32 -0400 (EDT) Received: from [172.16.12.111] (c-73-71-250-98.hsd1.ca.comcast.net [73.71.250.98]) by xyz.hosed.xyz (Postfix) with ESMTPSA id 1D09713C09A8; Tue, 25 May 2021 12:21:32 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) From: Sarah Banks In-Reply-To: <162169730408.30071.8159768796287685820@ietfa.amsl.com> Date: Tue, 25 May 2021 09:21:31 -0700 Cc: secdir@ietf.org, bmwg@ietf.org, draft-ietf-bmwg-evpntest.all@ietf.org, last-call@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <7AFEE702-7731-45A2-85E9-5DAFA936033E@encrypted.net> References: <162169730408.30071.8159768796287685820@ietfa.amsl.com> To: Robert Sparks X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-bmwg-evpntest-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 May 2021 16:21:39 -0000 Hi Robert, Thank you for your review, and your comments. The authors are = reviewing the feedback and will update with accepted changes shortly. Thank you, Sarah (Doc Shepherd) > On May 22, 2021, at 8:28 AM, Robert Sparks via Datatracker = wrote: >=20 > Reviewer: Robert Sparks > Review result: Has Nits >=20 > I have reviewed this document as part of the security directorate's = ongoing > effort to review all IETF documents being processed by the IESG. These = comments > were written primarily for the benefit of the security area directors. = Document > editors and WG chairs should treat these comments just like any other = last call > comments. >=20 > This document is essentially ready for publication as an Informational = RFC, but > with nits. >=20 > Document reviewed: draft-ietf-bmwg-evpntest-07 >=20 > This document describes a set of lab-environment characterization = tests to be > performed on isolated networks. >=20 > The document has basic formatting issues (line and page length) that = should be > addressed before submission for publication as an RFC. >=20 > The document does not discuss how the use of any of the mechanisms = discussed in > RFC7432 (and the RFCs it relies on) for improving the security = characteristics > of the protocols in use would affect the measurements being made, = though it > seems to suggest that the lab mimic production configuration. Perhaps = that > could be stated more clearly. >=20 From nobody Wed May 26 21:43:07 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3F603A07A9; Wed, 26 May 2021 21:42:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=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 J2WP0YvRNxmp; Wed, 26 May 2021 21:42:51 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 987873A07A8; Wed, 26 May 2021 21:42:50 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 14R4geiU017682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 27 May 2021 00:42:45 -0400 Date: Wed, 26 May 2021 21:42:40 -0700 From: Benjamin Kaduk To: Donald Eastlake Cc: mohamed.boucadair@orange.com, "iesg@ietf.org" , "last-call@ietf.org" , "draft-ietf-dots-rfc8782-bis.all@ietf.org" , secdir Message-ID: <20210527044240.GT32395@kduck.mit.edu> References: <23514_1616507505_6059F271_23514_186_1_787AE7BB302AE849A7480A190F8B93303535A427@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Archived-At: Subject: Re: [secdir] SECDIR Review draft-ietf-dots-rfc8782-bis-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2021 04:42:57 -0000 Hi Donald, First off, thanks for the review, and thanks to Med for the updates in response. Continuing inline... On Sat, Mar 27, 2021 at 11:42:56PM -0400, Donald Eastlake wrote: > Hi, > > Thanks for adopting so many of my suggestions. > > See below where I have trimmed to points where we disagree that I > think I have something to add. > > On Tue, Mar 23, 2021 at 9:51 AM wrote: > > Hi Donald, > > > >... > > > > De : Donald Eastlake [mailto:d3e3e3@gmail.com] > > Envoyé : mardi 23 mars 2021 05:53 > > À : iesg@ietf.org; last-call@ietf.org > > Cc : draft-ietf-dots-rfc8782-bis.all@ietf.org; secdir > > Objet : SECDIR Review draft-ietf-dots-rfc8782-bis-05 > > > > ... > > > > Minor Issues / Nits: > > > >... > > > > General/Global: All six occurrences of "as a reminder" should be > > deleted from the draft. They just add useless words. > > > > [Med] Except the one about IPv4/IPv6, those were added to address comments that we received in the past. I prefer to maintain them. > > Perhaps I was not clear. I have no problem with the substantive > material you have included AFTER the words "as a reminder,". I was > mearly suggesting that the literal three word sequence "as a reminder" > is three superfluous words that should be removed. Thanks for reiterating the intent of the suggestion. I think I am okay leaving them in for now, and seeing if the rest of the IESG has an opinion. > > > > ... > > > > Section 4.4.1: > > > > The following draft text uses "the trailing "=" " which implies that a > > base 64 encoding ends with exactly one equal sign. But I believe there > > can be zero, one, or two equal signs. I suggest the following: > > OLD > > The truncated output is > > base64url encoded (Section 5 of [RFC4648]) with the trailing > > "=" removed from the encoding, and the resulting value used as > > the 'cuid'. > > NEW > > The truncated output is > > base64url encoded (Section 5 of [RFC4648]) with any trailing > > equal signs ("=") removed from the encoding, and the > > resulting value used as the 'cuid'. > > > > [Med] We meant “any trailing”. Fixed by updating to “two trailing "="” > > That still seems wrong to me. The initial wording ("the trainling > "="") implied exactly one equal sign. The new wording ("the two > training "="") implies exactly two equal signs. But there can be zero, > one, or two. If you mean "any training "="", which would be good, why > don't you say that (or, alternatively, "all trailing")? In this case the quantity in question is always a 16-byte binary quantity that's being base64-encoded, so there always will be two padding characters to remove. > > > >... > > > > Section 7.3: Since the PMTU can change and could be lower that the > > values suggested to be assumed in the first paragraph of Section 7.3, > > it is essentially impossible to conform to the first sentence as > > written. I suggest the following change: > > OLD > > To avoid DOTS signal message fragmentation and the subsequent > > decreased probability of message delivery, DOTS agents MUST ensure > > that the DTLS record fits within a single datagram. > > > > [Med] We are echoing the following from Section 4.1.1 of 6347: > > > > “Each DTLS record MUST fit within a single datagram.” > > I don't agree that you are "echoing" RFC 6347. If you were, you would say > > "To avoid DOTS signal message fragmentation and the subsequent > decreased probability of message delivery, the DTLS records MUST fit > within a single datagram." > > If you had said that, I would not have complained. It is a true > statement of the bad effects DTLS records not fitting in a datagram. I think I see your point. Since RFC 6347 already has a "MUST fit" requirement, we could just rely on that and avoid using new normative language (I think your point is that "MUST ensure" is not something that can reliably be achieved, since the DOTS agent may not know about MTU changes). Perhaps we can say something like: To avoid DOTS signal message fragmentation and the subsequent decreased probability of message delivery, the DLTS records need to fit within a single datagram [RFC6347]. > > NEW > > To avoid DOTS signal message fragmentation and the subsequent > > decreased probability of message delivery, DOTS agents MUST NOT > > send datagrams exceeding the limits discussed in this Section. > > > > ... > > > > The way this sentence talks about moving around "mitigation efficacy" > > reads very strangely to me. I suggest the following re-wording: > > OLD > > A compromised DOTS client can collude with a DDoS attacker to send > > mitigation request for a target resource, get the mitigation efficacy > > from the DOTS server, and convey the mitigation efficacy to the DDoS > > attacker to possibly change the DDoS attack strategy. > > NEW > > A compromised DOTS client can be commanded by a DDoS attacker to > > abuse mitigation requests for a target resource. This could use the > > "mitigation" abilities of the DOTS server for the benefit of the > > attacker possibly leading to a changed and more effective DDoS > > attack strategy. > > > > [Med] Thanks. I prefer the OLD wording. > > I think I understand what you mean by "efficacy" more clearly now but > I still think you should fix the grammar by changing "request" in the > 2nd line to "requests" (or, if you really mean this to be singular, > change the wording to "a mitigation request"). (I think it's supposed to be singular. Yes, there's a cardinality mismatch.) Thanks again, Ben From nobody Thu May 27 05:48:44 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BC5F3A0474; Thu, 27 May 2021 05:48:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=orange.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 RhwrjRPEzxdZ; Thu, 27 May 2021 05:48:30 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.41]) (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 12AAF3A07A5; Thu, 27 May 2021 05:48:29 -0700 (PDT) Received: from opfedar05.francetelecom.fr (unknown [xx.xx.xx.7]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id 4FrSKl11n2z307V; Thu, 27 May 2021 14:48:27 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1622119707; bh=FW7fze/Trdxcfrtcw5YYIlvBxUP7mYDA3pL2xoQPNlw=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=i2aBOR0LF6PKG7Wbim1hcbZWb1Iv2qmoFeKTT/z8qcZxxaVWSD6qPaK9vcbgAyqyT mzAdo1DNuZeeiLfOk8GFEgofBjj70SOYIwMxWQh/6KOVpTPah4qMBdFhSGwOrzz1Sf 2/TR+uobYB8U6ANUnxI6jPe9ytvvbCJtXUQ+SvCNLFDF4Bc1QxjDBr7VO2y2weoToF KYJB3dDQFsa2uLY7lr5xRxc3EGIDG91m2Tan00tUuGAYU/B3EdcU4pOf7nJc/8tUit Z3jIeJmaTtt8TUE+jD6iIkRiYqyTJiKFsWDnu6A0y2GLjr7JZgEl6zERF7bekYOUlr BltItCv8xdGjA== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.67]) by opfedar05.francetelecom.fr (ESMTP service) with ESMTP id 4FrSKk6jpjz2xC2; Thu, 27 May 2021 14:48:26 +0200 (CEST) From: To: Benjamin Kaduk , Donald Eastlake CC: "iesg@ietf.org" , "last-call@ietf.org" , "draft-ietf-dots-rfc8782-bis.all@ietf.org" , secdir Thread-Topic: SECDIR Review draft-ietf-dots-rfc8782-bis-05 Thread-Index: AQHXUrLBvjlmu5Go1ESl3QN76YQQ7Kr3R18A Date: Thu, 27 May 2021 12:48:26 +0000 Message-ID: <25321_1622119706_60AF951A_25321_425_1_787AE7BB302AE849A7480A190F8B93303538FF1F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <23514_1616507505_6059F271_23514_186_1_787AE7BB302AE849A7480A190F8B93303535A427@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20210527044240.GT32395@kduck.mit.edu> In-Reply-To: <20210527044240.GT32395@kduck.mit.edu> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] SECDIR Review draft-ietf-dots-rfc8782-bis-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2021 12:48:36 -0000 SGkgQmVuLCBEb25hbGQsIA0KDQpJIHRoaW5rIHRoaXMgaXMgbm93IGZpeGVkIGluOiANCg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwxPWRyYWZ0LWlldGYtZG90cy1yZmM4NzgyLWJp cy0wNiZ1cmwyPWRyYWZ0LWlldGYtZG90cy1yZmM4NzgyLWJpcy0wNyANCg0KQ2hlZXJzLA0KTWVk DQoNCj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IEJlbmphbWluIEthZHVr IFttYWlsdG86a2FkdWtAbWl0LmVkdV0NCj4gRW52b3nDqcKgOiBqZXVkaSAyNyBtYWkgMjAyMSAw Njo0Mw0KPiDDgMKgOiBEb25hbGQgRWFzdGxha2UgPGQzZTNlM0BnbWFpbC5jb20+DQo+IENjwqA6 IEJPVUNBREFJUiBNb2hhbWVkIFRHSS9PTE4gPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+ Ow0KPiBpZXNnQGlldGYub3JnOyBsYXN0LWNhbGxAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtZG90cy1y ZmM4NzgyLQ0KPiBiaXMuYWxsQGlldGYub3JnOyBzZWNkaXIgPHNlY2RpckBpZXRmLm9yZz4NCj4g T2JqZXTCoDogUmU6IFNFQ0RJUiBSZXZpZXcgZHJhZnQtaWV0Zi1kb3RzLXJmYzg3ODItYmlzLTA1 DQo+IA0KPiBIaSBEb25hbGQsDQo+IA0KPiBGaXJzdCBvZmYsIHRoYW5rcyBmb3IgdGhlIHJldmll dywgYW5kIHRoYW5rcyB0byBNZWQgZm9yIHRoZSB1cGRhdGVzDQo+IGluIHJlc3BvbnNlLiAgQ29u dGludWluZyBpbmxpbmUuLi4NCj4gDQo+IE9uIFNhdCwgTWFyIDI3LCAyMDIxIGF0IDExOjQyOjU2 UE0gLTA0MDAsIERvbmFsZCBFYXN0bGFrZSB3cm90ZToNCj4gPiBIaSwNCj4gPg0KPiA+IFRoYW5r cyBmb3IgYWRvcHRpbmcgc28gbWFueSBvZiBteSBzdWdnZXN0aW9ucy4NCj4gPg0KPiA+IFNlZSBi ZWxvdyB3aGVyZSBJIGhhdmUgdHJpbW1lZCB0byBwb2ludHMgd2hlcmUgd2UgZGlzYWdyZWUgdGhh dCBJDQo+ID4gdGhpbmsgSSBoYXZlIHNvbWV0aGluZyB0byBhZGQuDQo+ID4NCj4gPiBPbiBUdWUs IE1hciAyMywgMjAyMSBhdCA5OjUxIEFNIDxtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPg0K PiB3cm90ZToNCj4gPiA+IEhpIERvbmFsZCwNCj4gPiA+DQo+ID4gPi4uLg0KPiA+ID4NCj4gPiA+ IERlIDogRG9uYWxkIEVhc3RsYWtlIFttYWlsdG86ZDNlM2UzQGdtYWlsLmNvbV0gRW52b3nDqSA6 IG1hcmRpIDIzDQo+ID4gPiBtYXJzIDIwMjEgMDU6NTMgw4AgOiBpZXNnQGlldGYub3JnOyBsYXN0 LWNhbGxAaWV0Zi5vcmcgQ2MgOg0KPiA+ID4gZHJhZnQtaWV0Zi1kb3RzLXJmYzg3ODItYmlzLmFs bEBpZXRmLm9yZzsgc2VjZGlyDQo+IDxzZWNkaXJAaWV0Zi5vcmc+DQo+ID4gPiBPYmpldCA6IFNF Q0RJUiBSZXZpZXcgZHJhZnQtaWV0Zi1kb3RzLXJmYzg3ODItYmlzLTA1DQo+ID4gPg0KPiA+ID4g Li4uDQo+ID4gPg0KPiA+ID4gTWlub3IgSXNzdWVzIC8gTml0czoNCj4gPiA+DQo+ID4gPi4uLg0K PiA+ID4NCj4gPiA+IEdlbmVyYWwvR2xvYmFsOiBBbGwgc2l4IG9jY3VycmVuY2VzIG9mICJhcyBh IHJlbWluZGVyIiBzaG91bGQgYmUNCj4gPiA+IGRlbGV0ZWQgZnJvbSB0aGUgZHJhZnQuIFRoZXkg anVzdCBhZGQgdXNlbGVzcyB3b3Jkcy4NCj4gPiA+DQo+ID4gPiBbTWVkXSBFeGNlcHQgdGhlIG9u ZSBhYm91dCBJUHY0L0lQdjYsIHRob3NlIHdlcmUgYWRkZWQgdG8gYWRkcmVzcw0KPiBjb21tZW50 cyB0aGF0IHdlIHJlY2VpdmVkIGluIHRoZSBwYXN0LiBJIHByZWZlciB0byBtYWludGFpbiB0aGVt Lg0KPiA+DQo+ID4gUGVyaGFwcyBJIHdhcyBub3QgY2xlYXIuIEkgaGF2ZSBubyBwcm9ibGVtIHdp dGggdGhlIHN1YnN0YW50aXZlDQo+ID4gbWF0ZXJpYWwgeW91IGhhdmUgaW5jbHVkZWQgQUZURVIg dGhlIHdvcmRzICJhcyBhIHJlbWluZGVyLCIuIEkgd2FzDQo+ID4gbWVhcmx5IHN1Z2dlc3Rpbmcg dGhhdCB0aGUgbGl0ZXJhbCB0aHJlZSB3b3JkIHNlcXVlbmNlICJhcyBhDQo+IHJlbWluZGVyIg0K PiA+IGlzIHRocmVlIHN1cGVyZmx1b3VzIHdvcmRzIHRoYXQgc2hvdWxkIGJlIHJlbW92ZWQuDQo+ IA0KPiBUaGFua3MgZm9yIHJlaXRlcmF0aW5nIHRoZSBpbnRlbnQgb2YgdGhlIHN1Z2dlc3Rpb24u DQo+IEkgdGhpbmsgSSBhbSBva2F5IGxlYXZpbmcgdGhlbSBpbiBmb3Igbm93LCBhbmQgc2VlaW5n IGlmIHRoZSByZXN0IG9mDQo+IHRoZSBJRVNHIGhhcyBhbiBvcGluaW9uLg0KPiANCj4gPiA+DQo+ ID4gPiAuLi4NCj4gPiA+DQo+ID4gPiBTZWN0aW9uIDQuNC4xOg0KPiA+ID4NCj4gPiA+IFRoZSBm b2xsb3dpbmcgZHJhZnQgdGV4dCB1c2VzICJ0aGUgdHJhaWxpbmcgIj0iICIgd2hpY2ggaW1wbGll cw0KPiB0aGF0DQo+ID4gPiBhIGJhc2UgNjQgZW5jb2RpbmcgZW5kcyB3aXRoIGV4YWN0bHkgb25l IGVxdWFsIHNpZ24uIEJ1dCBJDQo+IGJlbGlldmUNCj4gPiA+IHRoZXJlIGNhbiBiZSB6ZXJvLCBv bmUsIG9yIHR3byBlcXVhbCBzaWducy4gSSBzdWdnZXN0IHRoZQ0KPiBmb2xsb3dpbmc6DQo+ID4g PiBPTEQNCj4gPiA+ICAgICAgICAgIFRoZSB0cnVuY2F0ZWQgb3V0cHV0IGlzDQo+ID4gPiAgICAg ICAgICBiYXNlNjR1cmwgZW5jb2RlZCAoU2VjdGlvbiA1IG9mIFtSRkM0NjQ4XSkgd2l0aCB0aGUN Cj4gdHJhaWxpbmcNCj4gPiA+ICAgICAgICAgICI9IiByZW1vdmVkIGZyb20gdGhlIGVuY29kaW5n LCBhbmQgdGhlIHJlc3VsdGluZyB2YWx1ZQ0KPiB1c2VkIGFzDQo+ID4gPiAgICAgICAgICB0aGUg J2N1aWQnLg0KPiA+ID4gTkVXDQo+ID4gPiAgICAgICAgICBUaGUgdHJ1bmNhdGVkIG91dHB1dCBp cw0KPiA+ID4gICAgICAgICAgYmFzZTY0dXJsIGVuY29kZWQgKFNlY3Rpb24gNSBvZiBbUkZDNDY0 OF0pIHdpdGggYW55DQo+IHRyYWlsaW5nDQo+ID4gPiAgICAgICAgICBlcXVhbCBzaWducyAoIj0i KSByZW1vdmVkIGZyb20gdGhlIGVuY29kaW5nLCBhbmQgdGhlDQo+ID4gPiAgICAgICAgICByZXN1 bHRpbmcgdmFsdWUgdXNlZCBhcyB0aGUgJ2N1aWQnLg0KPiA+ID4NCj4gPiA+IFtNZWRdIFdlIG1l YW50IOKAnGFueSB0cmFpbGluZ+KAnS4gRml4ZWQgYnkgdXBkYXRpbmcgdG8g4oCcdHdvIHRyYWls aW5nDQo+ICI9IuKAnQ0KPiA+DQo+ID4gVGhhdCBzdGlsbCBzZWVtcyB3cm9uZyB0byBtZS4gVGhl IGluaXRpYWwgd29yZGluZyAoInRoZSB0cmFpbmxpbmcNCj4gPiAiPSIiKSBpbXBsaWVkIGV4YWN0 bHkgb25lIGVxdWFsIHNpZ24uIFRoZSBuZXcgd29yZGluZyAoInRoZSB0d28NCj4gPiB0cmFpbmlu ZyAiPSIiKSBpbXBsaWVzIGV4YWN0bHkgdHdvIGVxdWFsIHNpZ25zLiBCdXQgdGhlcmUgY2FuIGJl DQo+IHplcm8sDQo+ID4gb25lLCBvciB0d28uIElmIHlvdSBtZWFuICJhbnkgdHJhaW5pbmcgIj0i Iiwgd2hpY2ggd291bGQgYmUgZ29vZCwNCj4gd2h5DQo+ID4gZG9uJ3QgeW91IHNheSB0aGF0IChv ciwgYWx0ZXJuYXRpdmVseSwgImFsbCB0cmFpbGluZyIpPw0KPiANCj4gSW4gdGhpcyBjYXNlIHRo ZSBxdWFudGl0eSBpbiBxdWVzdGlvbiBpcyBhbHdheXMgYSAxNi1ieXRlIGJpbmFyeQ0KPiBxdWFu dGl0eSB0aGF0J3MgYmVpbmcgYmFzZTY0LWVuY29kZWQsIHNvIHRoZXJlIGFsd2F5cyB3aWxsIGJl IHR3bw0KPiBwYWRkaW5nIGNoYXJhY3RlcnMgdG8gcmVtb3ZlLg0KPiANCj4gPiA+DQo+ID4gPi4u Lg0KPiA+ID4NCj4gPiA+IFNlY3Rpb24gNy4zOiBTaW5jZSB0aGUgUE1UVSBjYW4gY2hhbmdlIGFu ZCBjb3VsZCBiZSBsb3dlciB0aGF0DQo+IHRoZQ0KPiA+ID4gdmFsdWVzIHN1Z2dlc3RlZCB0byBi ZSBhc3N1bWVkIGluIHRoZSBmaXJzdCBwYXJhZ3JhcGggb2YgU2VjdGlvbg0KPiA+ID4gNy4zLCBp dCBpcyBlc3NlbnRpYWxseSBpbXBvc3NpYmxlIHRvIGNvbmZvcm0gdG8gdGhlIGZpcnN0DQo+IHNl bnRlbmNlDQo+ID4gPiBhcyB3cml0dGVuLiBJIHN1Z2dlc3QgdGhlIGZvbGxvd2luZyBjaGFuZ2U6 DQo+ID4gPiBPTEQNCj4gPiA+ICAgIFRvIGF2b2lkIERPVFMgc2lnbmFsIG1lc3NhZ2UgZnJhZ21l bnRhdGlvbiBhbmQgdGhlIHN1YnNlcXVlbnQNCj4gPiA+ICAgIGRlY3JlYXNlZCBwcm9iYWJpbGl0 eSBvZiBtZXNzYWdlIGRlbGl2ZXJ5LCBET1RTIGFnZW50cyBNVVNUDQo+IGVuc3VyZQ0KPiA+ID4g ICAgdGhhdCB0aGUgRFRMUyByZWNvcmQgZml0cyB3aXRoaW4gYSBzaW5nbGUgZGF0YWdyYW0uDQo+ ID4gPg0KPiA+ID4gW01lZF0gV2UgYXJlIGVjaG9pbmcgdGhlIGZvbGxvd2luZyBmcm9tIFNlY3Rp b24gNC4xLjEgb2YgNjM0NzoNCj4gPiA+DQo+ID4gPiDigJxFYWNoIERUTFMgcmVjb3JkIE1VU1Qg Zml0IHdpdGhpbiBhIHNpbmdsZSBkYXRhZ3JhbS7igJ0NCj4gPg0KPiA+IEkgZG9uJ3QgYWdyZWUg dGhhdCB5b3UgYXJlICJlY2hvaW5nIiBSRkMgNjM0Ny4gSWYgeW91IHdlcmUsIHlvdQ0KPiB3b3Vs ZA0KPiA+IHNheQ0KPiA+DQo+ID4gIlRvIGF2b2lkIERPVFMgc2lnbmFsIG1lc3NhZ2UgZnJhZ21l bnRhdGlvbiBhbmQgdGhlIHN1YnNlcXVlbnQNCj4gPiBkZWNyZWFzZWQgcHJvYmFiaWxpdHkgb2Yg bWVzc2FnZSBkZWxpdmVyeSwgdGhlIERUTFMgcmVjb3JkcyBNVVNUDQo+IGZpdA0KPiA+IHdpdGhp biBhIHNpbmdsZSBkYXRhZ3JhbS4iDQo+ID4NCj4gPiBJZiB5b3UgaGFkIHNhaWQgdGhhdCwgSSB3 b3VsZCBub3QgaGF2ZSBjb21wbGFpbmVkLiBJdCBpcyBhIHRydWUNCj4gPiBzdGF0ZW1lbnQgb2Yg dGhlIGJhZCBlZmZlY3RzIERUTFMgcmVjb3JkcyBub3QgZml0dGluZyBpbiBhDQo+IGRhdGFncmFt Lg0KPiANCj4gSSB0aGluayBJIHNlZSB5b3VyIHBvaW50LiAgU2luY2UgUkZDIDYzNDcgYWxyZWFk eSBoYXMgYSAiTVVTVCBmaXQiDQo+IHJlcXVpcmVtZW50LCB3ZSBjb3VsZCBqdXN0IHJlbHkgb24g dGhhdCBhbmQgYXZvaWQgdXNpbmcgbmV3IG5vcm1hdGl2ZQ0KPiBsYW5ndWFnZSAoSSB0aGluayB5 b3VyIHBvaW50IGlzIHRoYXQgIk1VU1QgZW5zdXJlIiBpcyBub3Qgc29tZXRoaW5nDQo+IHRoYXQg Y2FuIHJlbGlhYmx5IGJlIGFjaGlldmVkLCBzaW5jZSB0aGUgRE9UUyBhZ2VudCBtYXkgbm90IGtu b3cNCj4gYWJvdXQgTVRVIGNoYW5nZXMpLiAgUGVyaGFwcyB3ZSBjYW4gc2F5IHNvbWV0aGluZyBs aWtlOg0KPiANCj4gICBUbyBhdm9pZCBET1RTIHNpZ25hbCBtZXNzYWdlIGZyYWdtZW50YXRpb24g YW5kIHRoZSBzdWJzZXF1ZW50DQo+ICAgZGVjcmVhc2VkIHByb2JhYmlsaXR5IG9mIG1lc3NhZ2Ug ZGVsaXZlcnksIHRoZSBETFRTIHJlY29yZHMgbmVlZCB0bw0KPiAgIGZpdCB3aXRoaW4gYSBzaW5n bGUgZGF0YWdyYW0gW1JGQzYzNDddLg0KPiANCj4gDQo+ID4gPiBORVcNCj4gPiA+ICAgIFRvIGF2 b2lkIERPVFMgc2lnbmFsIG1lc3NhZ2UgZnJhZ21lbnRhdGlvbiBhbmQgdGhlIHN1YnNlcXVlbnQN Cj4gPiA+ICAgIGRlY3JlYXNlZCBwcm9iYWJpbGl0eSBvZiBtZXNzYWdlIGRlbGl2ZXJ5LCBET1RT IGFnZW50cyBNVVNUDQo+IE5PVA0KPiA+ID4gICAgc2VuZCBkYXRhZ3JhbXMgZXhjZWVkaW5nIHRo ZSBsaW1pdHMgZGlzY3Vzc2VkIGluIHRoaXMgU2VjdGlvbi4NCj4gPiA+DQo+ID4gPiAuLi4NCj4g PiA+DQo+ID4gPiBUaGUgd2F5IHRoaXMgc2VudGVuY2UgdGFsa3MgYWJvdXQgbW92aW5nIGFyb3Vu ZCAibWl0aWdhdGlvbg0KPiBlZmZpY2FjeSINCj4gPiA+IHJlYWRzIHZlcnkgc3RyYW5nZWx5IHRv IG1lLiBJIHN1Z2dlc3QgdGhlIGZvbGxvd2luZyByZS13b3JkaW5nOg0KPiA+ID4gT0xEDQo+ID4g PiAgICBBIGNvbXByb21pc2VkIERPVFMgY2xpZW50IGNhbiBjb2xsdWRlIHdpdGggYSBERG9TIGF0 dGFja2VyIHRvDQo+IHNlbmQNCj4gPiA+ICAgIG1pdGlnYXRpb24gcmVxdWVzdCBmb3IgYSB0YXJn ZXQgcmVzb3VyY2UsIGdldCB0aGUgbWl0aWdhdGlvbg0KPiBlZmZpY2FjeQ0KPiA+ID4gICAgZnJv bSB0aGUgRE9UUyBzZXJ2ZXIsIGFuZCBjb252ZXkgdGhlIG1pdGlnYXRpb24gZWZmaWNhY3kgdG8N Cj4gdGhlIEREb1MNCj4gPiA+ICAgIGF0dGFja2VyIHRvIHBvc3NpYmx5IGNoYW5nZSB0aGUgRERv UyBhdHRhY2sgc3RyYXRlZ3kuDQo+ID4gPiBORVcNCj4gPiA+ICAgIEEgY29tcHJvbWlzZWQgRE9U UyBjbGllbnQgY2FuIGJlIGNvbW1hbmRlZCBieSBhIEREb1MgYXR0YWNrZXINCj4gdG8NCj4gPiA+ ICAgIGFidXNlIG1pdGlnYXRpb24gcmVxdWVzdHMgZm9yIGEgdGFyZ2V0IHJlc291cmNlLiBUaGlz IGNvdWxkDQo+IHVzZSB0aGUNCj4gPiA+ICAgICJtaXRpZ2F0aW9uIiBhYmlsaXRpZXMgb2YgdGhl IERPVFMgc2VydmVyIGZvciB0aGUgYmVuZWZpdCBvZg0KPiB0aGUNCj4gPiA+ICAgIGF0dGFja2Vy IHBvc3NpYmx5IGxlYWRpbmcgdG8gYSBjaGFuZ2VkIGFuZCBtb3JlIGVmZmVjdGl2ZSBERG9TDQo+ ID4gPiAgICBhdHRhY2sgc3RyYXRlZ3kuDQo+ID4gPg0KPiA+ID4gW01lZF0gVGhhbmtzLiBJIHBy ZWZlciB0aGUgT0xEIHdvcmRpbmcuDQo+ID4NCj4gPiBJIHRoaW5rIEkgdW5kZXJzdGFuZCB3aGF0 IHlvdSBtZWFuIGJ5ICJlZmZpY2FjeSIgbW9yZSBjbGVhcmx5IG5vdw0KPiBidXQNCj4gPiBJIHN0 aWxsIHRoaW5rIHlvdSBzaG91bGQgZml4IHRoZSBncmFtbWFyIGJ5IGNoYW5naW5nICJyZXF1ZXN0 IiBpbg0KPiB0aGUNCj4gPiAybmQgbGluZSB0byAicmVxdWVzdHMiIChvciwgaWYgeW91IHJlYWxs eSBtZWFuIHRoaXMgdG8gYmUgc2luZ3VsYXIsDQo+ID4gY2hhbmdlIHRoZSB3b3JkaW5nIHRvICJh IG1pdGlnYXRpb24gcmVxdWVzdCIpLg0KPiANCj4gKEkgdGhpbmsgaXQncyBzdXBwb3NlZCB0byBi ZSBzaW5ndWxhci4gIFllcywgdGhlcmUncyBhIGNhcmRpbmFsaXR5DQo+IG1pc21hdGNoLikNCj4g DQo+IFRoYW5rcyBhZ2FpbiwNCj4gDQo+IEJlbg0KCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2Vz IHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRl bnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZm dXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6 IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhw ZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMg bWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApP cmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFs dGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBh dHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1h dGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlz dHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhh dmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVy IGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBt YXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2 ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK From nobody Thu May 27 07:26:25 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A742B3A0FC7; Thu, 27 May 2021 07:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 97mu2E7TMU-H; Thu, 27 May 2021 07:26:11 -0700 (PDT) Received: from mail-il1-x12a.google.com (mail-il1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) (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 8823C3A0FB9; Thu, 27 May 2021 07:26:10 -0700 (PDT) Received: by mail-il1-x12a.google.com with SMTP id z1so454769ils.0; Thu, 27 May 2021 07:26:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=TkdNopaE2rNhPGekYrHfBmqUSkr/tf+vtB2LZpYlqFM=; b=vZnrTWzckVTbElNyXozTEqZLoME7rHNcPea/RQkTg8s0TVII3fUZLr80AKqGzr0kPO GCS6JbTK+I9noF9s0usLcNmCc/R7QTvq1n5ZDRawoeNxHVooPytRFrH+eyuyQhe3r4Bu JRGcdLQ6Yhuv5ulHhbN1u8UEaFF8klKiwOGVFGg45m51bBSTKVPJahHjR3Np3mFY7iS8 1YU1cCxpoWg4r/exhThbklMfjpve1ZMkcWjf59UDmKWd72IPvFJ/ci9tQMDs7m8OgBV4 2n1siXjoPfmWsOfIOelStdcv36C3SPscCrAgLhhfTVEl0amL4CkSQOMixbmr7fKCNXiS QxLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=TkdNopaE2rNhPGekYrHfBmqUSkr/tf+vtB2LZpYlqFM=; b=A+ajtCaQIx42WZfv0cjw8huJJ5m5EaEQez4T+pwmOh5V/hPulrcc25UM/3ARmb9MIs zg/PocLiA/lYpiPRxgeo1w5LyKgoYWhey6Ko1PDm6q59fV+5xDsLNRVwfXBxdlKY/IOU ItUFJ/SraZIKM6LciVswGqI75nnih5X98dDv39B/byPMKQOl0RAdTDO+8YjVZLk9oy0Y fQUdEEiGWGGrAgkulBAv+eh8Ri+rVVJWeu5YgUAQUNacK0tsSrVuM0bCpLYmrrEq3tpz oCGgv7q8XQnBaMra4RuszWIhGQWdwNu9nv3dagonlGvmiQFfBG4+Ure1n4LY4iHw3H5F FTfw== X-Gm-Message-State: AOAM530JydSJD3W44Uwoic52O6KttLKT+/cSK/M21rguSAcaY2GfMqWJ /lMNaFmp9NTJ9pqd+jtT7okEDcej5PN0rkZwx40= X-Google-Smtp-Source: ABdhPJyFLm2J9teMEpI7Dj5CF6qJKetIJPtnrJW/FDFJ+l5chDiHpkcBOMWCYTUXJeihvlw2hi/r7W/kbo7v6Z2208c= X-Received: by 2002:a92:6b05:: with SMTP id g5mr3210326ilc.40.1622125568473; Thu, 27 May 2021 07:26:08 -0700 (PDT) MIME-Version: 1.0 References: <23514_1616507505_6059F271_23514_186_1_787AE7BB302AE849A7480A190F8B93303535A427@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20210527044240.GT32395@kduck.mit.edu> <25321_1622119706_60AF951A_25321_425_1_787AE7BB302AE849A7480A190F8B93303538FF1F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <25321_1622119706_60AF951A_25321_425_1_787AE7BB302AE849A7480A190F8B93303538FF1F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: Donald Eastlake Date: Thu, 27 May 2021 10:25:57 -0400 Message-ID: To: mohamed.boucadair@orange.com Cc: Benjamin Kaduk , "iesg@ietf.org" , "last-call@ietf.org" , "draft-ietf-dots-rfc8782-bis.all@ietf.org" , secdir Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [secdir] SECDIR Review draft-ietf-dots-rfc8782-bis-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2021 14:26:16 -0000 Hi Med, Thanks for the additional changes. I consider all my comments to have been adequately addressed. Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com On Thu, May 27, 2021 at 8:48 AM wrote: > > Hi Ben, Donald, > > I think this is now fixed in: > > https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-dots-rfc8782-bis-06&url2= =3Ddraft-ietf-dots-rfc8782-bis-07 > > Cheers, > Med > > > -----Message d'origine----- > > De : Benjamin Kaduk [mailto:kaduk@mit.edu] > > Envoy=C3=A9 : jeudi 27 mai 2021 06:43 > > =C3=80 : Donald Eastlake > > Cc : BOUCADAIR Mohamed TGI/OLN ; > > iesg@ietf.org; last-call@ietf.org; draft-ietf-dots-rfc8782- > > bis.all@ietf.org; secdir > > Objet : Re: SECDIR Review draft-ietf-dots-rfc8782-bis-05 > > > > Hi Donald, > > > > First off, thanks for the review, and thanks to Med for the updates > > in response. Continuing inline... > > > > On Sat, Mar 27, 2021 at 11:42:56PM -0400, Donald Eastlake wrote: > > > Hi, > > > > > > Thanks for adopting so many of my suggestions. > > > > > > See below where I have trimmed to points where we disagree that I > > > think I have something to add. > > > > > > On Tue, Mar 23, 2021 at 9:51 AM > > wrote: > > > > Hi Donald, > > > > > > > >... > > > > > > > > De : Donald Eastlake [mailto:d3e3e3@gmail.com] Envoy=C3=A9 : mardi = 23 > > > > mars 2021 05:53 =C3=80 : iesg@ietf.org; last-call@ietf.org Cc : > > > > draft-ietf-dots-rfc8782-bis.all@ietf.org; secdir > > > > > > Objet : SECDIR Review draft-ietf-dots-rfc8782-bis-05 > > > > > > > > ... > > > > > > > > Minor Issues / Nits: > > > > > > > >... > > > > > > > > General/Global: All six occurrences of "as a reminder" should be > > > > deleted from the draft. They just add useless words. > > > > > > > > [Med] Except the one about IPv4/IPv6, those were added to address > > comments that we received in the past. I prefer to maintain them. > > > > > > Perhaps I was not clear. I have no problem with the substantive > > > material you have included AFTER the words "as a reminder,". I was > > > mearly suggesting that the literal three word sequence "as a > > reminder" > > > is three superfluous words that should be removed. > > > > Thanks for reiterating the intent of the suggestion. > > I think I am okay leaving them in for now, and seeing if the rest of > > the IESG has an opinion. > > > > > > > > > > ... > > > > > > > > Section 4.4.1: > > > > > > > > The following draft text uses "the trailing "=3D" " which implies > > that > > > > a base 64 encoding ends with exactly one equal sign. But I > > believe > > > > there can be zero, one, or two equal signs. I suggest the > > following: > > > > OLD > > > > The truncated output is > > > > base64url encoded (Section 5 of [RFC4648]) with the > > trailing > > > > "=3D" removed from the encoding, and the resulting value > > used as > > > > the 'cuid'. > > > > NEW > > > > The truncated output is > > > > base64url encoded (Section 5 of [RFC4648]) with any > > trailing > > > > equal signs ("=3D") removed from the encoding, and the > > > > resulting value used as the 'cuid'. > > > > > > > > [Med] We meant =E2=80=9Cany trailing=E2=80=9D. Fixed by updating to= =E2=80=9Ctwo trailing > > "=3D"=E2=80=9D > > > > > > That still seems wrong to me. The initial wording ("the trainling > > > "=3D"") implied exactly one equal sign. The new wording ("the two > > > training "=3D"") implies exactly two equal signs. But there can be > > zero, > > > one, or two. If you mean "any training "=3D"", which would be good, > > why > > > don't you say that (or, alternatively, "all trailing")? > > > > In this case the quantity in question is always a 16-byte binary > > quantity that's being base64-encoded, so there always will be two > > padding characters to remove. > > > > > > > > > >... > > > > > > > > Section 7.3: Since the PMTU can change and could be lower that > > the > > > > values suggested to be assumed in the first paragraph of Section > > > > 7.3, it is essentially impossible to conform to the first > > sentence > > > > as written. I suggest the following change: > > > > OLD > > > > To avoid DOTS signal message fragmentation and the subsequent > > > > decreased probability of message delivery, DOTS agents MUST > > ensure > > > > that the DTLS record fits within a single datagram. > > > > > > > > [Med] We are echoing the following from Section 4.1.1 of 6347: > > > > > > > > =E2=80=9CEach DTLS record MUST fit within a single datagram.=E2=80= =9D > > > > > > I don't agree that you are "echoing" RFC 6347. If you were, you > > would > > > say > > > > > > "To avoid DOTS signal message fragmentation and the subsequent > > > decreased probability of message delivery, the DTLS records MUST > > fit > > > within a single datagram." > > > > > > If you had said that, I would not have complained. It is a true > > > statement of the bad effects DTLS records not fitting in a > > datagram. > > > > I think I see your point. Since RFC 6347 already has a "MUST fit" > > requirement, we could just rely on that and avoid using new normative > > language (I think your point is that "MUST ensure" is not something > > that can reliably be achieved, since the DOTS agent may not know > > about MTU changes). Perhaps we can say something like: > > > > To avoid DOTS signal message fragmentation and the subsequent > > decreased probability of message delivery, the DLTS records need to > > fit within a single datagram [RFC6347]. > > > > > > > > NEW > > > > To avoid DOTS signal message fragmentation and the subsequent > > > > decreased probability of message delivery, DOTS agents MUST > > NOT > > > > send datagrams exceeding the limits discussed in this Section. > > > > > > > > ... > > > > > > > > The way this sentence talks about moving around "mitigation > > efficacy" > > > > reads very strangely to me. I suggest the following re-wording: > > > > OLD > > > > A compromised DOTS client can collude with a DDoS attacker to > > send > > > > mitigation request for a target resource, get the mitigation > > efficacy > > > > from the DOTS server, and convey the mitigation efficacy to > > the DDoS > > > > attacker to possibly change the DDoS attack strategy. > > > > NEW > > > > A compromised DOTS client can be commanded by a DDoS attacker > > to > > > > abuse mitigation requests for a target resource. This could > > use the > > > > "mitigation" abilities of the DOTS server for the benefit of > > the > > > > attacker possibly leading to a changed and more effective DDoS > > > > attack strategy. > > > > > > > > [Med] Thanks. I prefer the OLD wording. > > > > > > I think I understand what you mean by "efficacy" more clearly now > > but > > > I still think you should fix the grammar by changing "request" in > > the > > > 2nd line to "requests" (or, if you really mean this to be singular, > > > change the wording to "a mitigation request"). > > > > (I think it's supposed to be singular. Yes, there's a cardinality > > mismatch.) > > > > Thanks again, > > > > Ben > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. > > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > From nobody Thu May 27 13:46:51 2021 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 312E23A0FEC for ; Thu, 27 May 2021 13:46:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 7.30.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <162214840851.8458.10896314607204442739@ietfa.amsl.com> Date: Thu, 27 May 2021 13:46:49 -0700 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2021 20:46:49 -0000 Had to skip several reviewers this time as they still have earlier reviews not completed at this time, and there is no point of assigning them another one of they have not finished the previous ones. It seems to be that those having last name at the end of alphabet are not that good at doing reviews... Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2021-06-03 Reviewer LC end Draft Dan Harkins R2021-03-22 draft-ietf-6man-spring-srv6-oam For telechat 2021-06-17 Reviewer LC end Draft Derek Atkins 2021-06-10 draft-ietf-httpbis-cache Mališa Vučinić 2021-06-10 draft-ietf-httpbis-semantics Paul Wouters 2021-06-10 draft-ietf-httpbis-messaging Last calls: Reviewer LC end Draft Derek Atkins 2021-06-10 draft-ietf-httpbis-cache John Bradley 2021-03-16 draft-ietf-idr-bgp-ls-registry Nancy Cam-Winget 2021-06-08 draft-ietf-oauth-par Shaun Cooley 2021-02-25 draft-ietf-v6ops-ipv6-ehs-packet-drops Alan DeKok 2021-03-24 draft-ietf-cbor-tags-oid Linda Dunbar 2021-06-07 draft-ietf-drip-reqs Donald Eastlake 2021-06-07 draft-ietf-dnsop-rfc7816bis Shawn Emery 2021-06-07 draft-ietf-perc-dtls-tunnel Daniel Gillmor 2021-03-26 draft-ietf-lamps-crmf-update-algs Phillip Hallam-Baker 2021-06-10 draft-ietf-stir-enhance-rfc8226 Steve Hanna 2021-03-22 draft-ietf-regext-secure-authinfo-transfer Dan Harkins R2021-03-22 draft-ietf-6man-spring-srv6-oam Christian Huitema R2021-06-01 draft-ietf-dtn-bpsec-default-sc Leif Johansson None draft-ietf-netconf-crypto-types Aanchal Malhotra None draft-ietf-opsawg-l3sm-l3nm Catherine Meadows 2021-04-14 draft-ietf-ntp-interleaved-modes Kathleen Moriarty 2021-04-27 draft-ietf-bess-mvpn-msdp-sa-interoperation Russ Mundy 2021-04-20 draft-ietf-dprive-xfr-over-tls Sandra Murphy R2021-04-05 draft-ietf-dmarc-psd Sandra Murphy 2020-10-15 draft-ietf-tls-external-psk-importer Yoav Nir 2021-04-28 draft-ietf-core-new-block Melinda Shore 2021-05-17 draft-ietf-payload-rtp-jpegxs Mališa Vučinić 2021-06-10 draft-ietf-httpbis-semantics Carl Wallace R2021-02-22 draft-ietf-tcpm-2140bis Samuel Weiler 2021-02-22 draft-ietf-tls-dtls13 Brian Weis 2021-02-19 draft-ietf-lamps-cms-aes-gmac-alg Klaas Wierenga 2020-12-02 draft-ietf-core-echo-request-tag Klaas Wierenga 2020-05-26 draft-ietf-kitten-krb-spake-preauth Paul Wouters 2021-06-10 draft-ietf-httpbis-messaging Liang Xia 2021-03-17 draft-ietf-core-sid Early review requests: Reviewer Due Draft Stephen Farrell 2021-06-21 draft-ietf-idr-bgpls-srv6-ext Daniel Franke 2021-06-30 draft-ietf-anima-constrained-voucher Tina Tsou 2021-02-15 draft-ietf-idr-eag-distribution Dacheng Zhang 2020-12-07 draft-ietf-idr-eag-distribution Next in the reviewer rotation: Daniel Gillmor Phillip Hallam-Baker Steve Hanna Dan Harkins Russ Housley Christian Huitema Leif Johansson Charlie Kaufman Scott Kelly Tero Kivinen From nobody Fri May 28 11:23:44 2021 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 870EC3A3105; Fri, 28 May 2021 11:23:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Christian Huitema via Datatracker To: Cc: draft-ietf-dtn-bpsec-default-sc.all@ietf.org, dtn@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.30.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162222621650.3936.204909667434697510@ietfa.amsl.com> Reply-To: Christian Huitema Date: Fri, 28 May 2021 11:23:36 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-dtn-bpsec-default-sc-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 May 2021 18:23:37 -0000 Reviewer: Christian Huitema Review result: Ready I reviewed draft-ietf-dtn-bpsec-default-sc-02 as part of an early security review requested by the transport AD. This is the follow-up last call review of draft-ietf-dtn-bpsec-default-sc-07. The draft is ready, although I would prefer to see somechanges in the encoding of AEAD tags as explained below. The changes in draft-07 address most of the points I made in the early review. The small nit concerning a reference in the table of BIB-HMAC-SHA2 Security Parameters is fixed and the implementation of AEAD algorithms is easy to read. I appreciate that the draft now contains an entire appendix describing examples of messages, their clear-text encoding and the result of authentication and encryption. This probably required significant effort, and it does address my suggestion to add test vectors in order to manage implementation complexity. I could just say that the draft is ready, except for one addition that I find a bit spurious. The description of AES-GCM states that "the authentication tag produced by the GCM mode of AES is not considered part of the cipher text itself", and that "the authentication tag is expected to be carried in the BCB-AES-GCM security block". The statement is not technically false, but the separation of message and tag goes against the design of many AEAD implementations, in which the application provides the crypto API with a clear text of some length, and retrieves a cipher text of a different length, including the tag. Separating that tag and moving it to a different location is yet another way to introduce complexity. That complexity can probably still be managed for AES-GCM, but the general trend is to implement encryption and authentication in a single operation. I fully expect that new encryption algorithms will continue that trend, and may well do away with the formal separation between ciphertext and tag. Recognizing that encryption and authentication are not separable would simplify the DTN bundle protocol. From nobody Fri May 28 14:52:38 2021 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B29093A371D; Fri, 28 May 2021 14:52:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Derek Atkins via Datatracker To: Cc: draft-ietf-httpbis-cache.all@ietf.org, ietf-http-wg@w3.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.30.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162223875566.24167.937107986015412919@ietfa.amsl.com> Reply-To: Derek Atkins Date: Fri, 28 May 2021 14:52:35 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-httpbis-cache-16 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 May 2021 21:52:36 -0000 Reviewer: Derek Atkins Review result: Ready Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving security requirements and considerations in IETF drafts. Comments not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: * Ready to Publish Details: * N/A -derek From nobody Sun May 30 16:55:14 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C45393A1A02; Sun, 30 May 2021 16:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 HpwXhvF5Maqp; Sun, 30 May 2021 16:55:07 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 5A8623A1A01; Sun, 30 May 2021 16:55:07 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 14UNsxJT013239 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 30 May 2021 19:55:03 -0400 Date: Sun, 30 May 2021 16:54:58 -0700 From: Benjamin Kaduk To: Phillip Hallam-Baker Cc: secdir@ietf.org, ace@ietf.org Message-ID: <20210530235458.GE32395@kduck.mit.edu> References: <162164047967.4459.16040288658397288714@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <162164047967.4459.16040288658397288714@ietfa.amsl.com> Archived-At: Subject: Re: [secdir] Secdir telechat review of draft-ietf-ace-oauth-authz-41 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 May 2021 23:55:09 -0000 Thanks, Phill. I really appreciate having another set of eyes go over the changes in the draft and cross-referencing against the review comments -- it makes me a lot more confident that we're in good shape now. -Ben On Fri, May 21, 2021 at 04:41:19PM -0700, Phillip Hallam-Baker via Datatracker wrote: > Reviewer: Phillip Hallam-Baker > Review result: Ready > > This draft was previously reviewed by Steve Kent for the -27 version. My review > therefore mostly consists of checking that the changes recommended have been > made and that no new issues have arisen. Note that contrary to the data in the > tracker, I was not given the assignment in 2019. > > If you decide that you want to use OAUTH for authorization security for > Internet of Things, this is a reasonable approach to take. This is not a simple > proposition or for the fainthearted. OAuth is built around the various > constraints of the browser world to which the constraints of being a > constrained device are added. > > The issues raised by Steve have all been addressed as far as I can see. It > looks good to go but since it is a security spec, ADs should still take note. > >
Thanks Juan, yes, to me this is at least = clearer about the risk. At this point I leave it to the Security Area direc= tors if they'd like to see any other modifications.

Thanks!
Magnus

On Mon, May 3, 2021 at 5:17 P= M Juan Alcaide (jalcaide) <jalcaid= e@cisco.com> wrote:

Magnus,

=C2=A0

Yes, they=E2=80=99ll be opening to risk. It=E2=80=99= s the risk described in the draft. But this risk is necessary for route-ser= vers to work with flowspec. And as mentioned, perhaps route servers can be = configured to avoid that risk.

=C2=A0

=C2=A0

I wanted to use the term =E2=80=98remain=E2=80=99 in= stead of =E2=80=98become=E2=80=99.. We went from RFC4271 (rule optional) -&= gt; RFC8955 (rule mandatory) -> this draft (rule again optional)<= u>

Would the below make sense (I changed the first sent= ence):

=C2=A0

=C2=A0=C2=A0 This document makes the original AS= _PATH validation rule ([RFC4271] section 6.3) again optional<= u>

=C2=A0=C2=A0 (section 4.2) for Flow Specificatio= n Address Family (the rule is no longer mandatory as it was specified by [RFC8955]).

=C2=A0=C2=A0=C2=A0If that original rule is not e= nforced for Flow Specification it may introduce some new security risks.

=C2=A0=C2=A0 A peer (or a client of a route serv= er peer) in AS X could advertise a rogue Flow

=C2=A0=C2=A0 Specification route whose first AS = in AS_PATH was Y (assume Y is the

=C2=A0=C2=A0 first AS in the AS_PATH of the best= -match unicast route).=C2=A0 This risk

=C2=A0=C2=A0 is impossible to prevent if the Flo= w Specification route is received

=C2=A0=C2=A0 from a route server peer.=C2=A0 If = that peer is known for a fact not to be

=C2=A0=C2=A0 a route server, that optional rule = SHOULD be enforced for Flow

=C2=A0=C2=A0 Specification routes. Note that ide= ntifying those peers that are route servers may suppose an=

=C2=A0=C2=A0 operational challenge. If the condi= tion of the peer is unknown, the rule SHOULD not be

=C2=A0=C2=A0 enforced.

=C2=A0

=C2=A0=C2=A0 A route server itself may be in a g= ood position to enforce the AS_PATH validation rule described=

=C2=A0=C2=A0in the previous paragraph. If a rout= e server knowns it=E2=80=99s not peering with any other route server,

=C2=A0=C2=A0 it can enforce the AS_PATH validati= on rule across all its peers. If, in addition to that,=

=C2=A0=C2=A0 the route server is trusted, the se= curity threat described above disappears.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

From: Magnus Nystr=C3=B6m <magnusn@gmail.com>
Sent: Monday, May 3, 2021 9:39 PM
To: Juan Alcaide (jalcaide) <jalcaide@cisco.com>
Cc: secdir@ietf= .org; draft-ietf-idr-bgp-flowspec-oid@ietf.org
Subject: Re: Secdir review of draft-ietf-idr-bgp-flowspec-oid-13<= /u>

=C2=A0

Thanks Juan.

For the editorial ones, agree on the first one and I= think the second you could change to "with this memo, becomes optiona= l." or similar.

For the new text, perhaps I am misunderstanding some= thing, but this sentence:

Note that identifying those peers that are route= servers may suppose an operational challenge. If the condition of the peer is unknown, the rule SHOULD not be enforced.<= /u>

Is it correctly understood, that you're= saying that if a validator is unable to determine if the peer is a route server, they should not enforce the rule? If so, doesn't that = mean "failing open, i.e., opening themselves to risk? Sorry if I misun= derstand.

=C2=A0

=C2=A0

On Mon, May 3, 2021 at 3:36 AM Juan Alcaide (jalcaid= e) <jalcaide@cis= co.com> wrote:

Thanks for your comments, Magnus

=C2=A0

Inline..

=C2=A0

From: Magnus Nystr=C3=B6m <magnusn@gmail.com>
Sent: Monday, May 3, 2021 6:44 AM
To: secdir@ietf= .org; draft-ietf-idr-bgp-flowspec-oid@ietf.org
Subject: Secdir review of draft-ietf-idr-bgp-flowspec-oid-13<= u>

=C2=A0

I have reviewed this document as part of the securit= y directorate's ongoing effort to review all IETF documents being proce= ssed by the IESG. These comments were written primarily for the benefit of the security area directors.=C2=A0 Document editors and= WG chairs should treat these comments just like any other last call commen= ts.

=C2=A0

This document describes "a modification to the = validation procedure defined for the dissemination

of BGP Flow Specifications." More specifically.= the memo describes a mechanism which relaxes=C2=A0 the existing validation= rule that requires Flow Specifications to be originating from the originator of the best-match unicast route, and now allows such specif= ications to be originated within the same AS as the validator. As a result.= the Security Considerations section does call out: "The original AS_P= ATH validation rule ([RFC4271] section=C2=A06.3) becomes=C2=A0 hereby optional (section 4.2). If that original rule is actually not enforced i= t may introduce some security risks. A peer (or a client of a route server peer) in AS X could advertise a rogue Flow Spec= ification route...." and "If t[the originator of a rule] is known= for a fact not to be a route server, that optional rule SHOULD be enforced= for Flow Specification routes."

=C2=A0

It is not clear to me how a validator would now &quo= t;for a fact" that a peer isn't a route server, and thus that it w= ould have to enforce the now-optional path validation rule. It seems some clarity on this would be good such that implementations have less of = a risk of accepting flow specifications from unauthorized parties, even if = they are on the same AS.

=C2=A0

[JUAN]: This paragraph was not intended to pressure = the operator to know if the peer was a route server, it was just a =E2=80= =98if=E2=80=99. Note it=E2=80=99s the same case for RFC4271 :=

=C2=A0

If the UPDATE message is received from an extern= al peer, the local

=C2=A0=C2=A0 system MAY check whether the leftmo= st (with respect to the position

=C2=A0=C2=A0 of octets in the protocol message) = AS in the AS_PATH attribute is

=C2=A0=C2=A0 equal to the autonomous system numb= er of the peer that sent the

=C2=A0=C2=A0 message.

=C2=A0

=C2=A0

Note that the same challenge of identifying route se= rvers applies for other address-families.

Note also that the route-server itself may enforce t= he rule.

=C2=A0

What about for clarity:

=C2=A0

=C2=A0=C2=A0 The original AS_PATH validation rul= e ([RFC4271] section 6.3) remains hereby still optional

=C2=A0=C2=A0 (section 4.2) for Flow Specificatio= n Address Family (changes introduced in [RFC5575] are cancelled).

=C2=A0=C2=A0=C2=A0If that original rule is not e= nforced for Flow Specification it may introduce some new security risks.

=C2=A0=C2=A0 A peer (or a client of a route serv= er peer) in AS X could advertise a rogue Flow

=C2=A0=C2=A0 Specification route whose first AS = in AS_PATH was Y (assume Y is the

=C2=A0=C2=A0 first AS in the AS_PATH of the best= -match unicast route).=C2=A0 This risk

=C2=A0=C2=A0 is impossible to prevent if the Flo= w Specification route is received

=C2=A0=C2=A0 from a route server peer.=C2=A0 If = that peer is known for a fact not to be

=C2=A0=C2=A0 a route server, that optional rule = SHOULD be enforced for Flow

=C2=A0=C2=A0 Specification routes. Note that ide= ntifying those peers that are route servers may suppose an=

=C2=A0=C2=A0 operational challenge. If the condi= tion of the peer is unknown, the rule SHOULD not be

=C2=A0=C2=A0 enforced.

=C2=A0

=C2=A0=C2=A0 A route server itself may be in a g= ood position to enforce the AS_PATH validation rule described=

=C2=A0=C2=A0in the previous paragraph. If a rout= e server knowns it=E2=80=99s not peering with any other route server,

=C2=A0=C2=A0 it can enforce the AS_PATH validati= on rule across all its peers. If, in addition to that,=

=C2=A0=C2=A0 the route server is trusted, the se= curity threat described above disappears.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

=C2=A0

Anybody feel free to reword the two paragraphs above= if it helps them for clarity.

=C2=A0

=C2=A0

=C2=A0

Editorial:

  • "Let's consider the particular case where the Flow Specification i= s originated in any location within the same autonomous system than the spe= aker performing the validation (for example by a centralized BGP route cont= roller), and the best-match unicast route is originated in another autonomous system." - should the word "= than" be replaced with "that" here?

[JUAN]: Thanks for pointing that out. A few googling= tells me the even better grammatical choice would be =E2=80=98same as=E2= =80=99 in this case. I=E2=80=99ll be using =E2=80=98same as=E2=80=99 unless= =C2=A0 you disagree.

=C2=A0

  • In the security considerations section, "becomes hereby optional"= could probably be simplified to "becomes optional" or similar, a= nd "actually" could be removed.

[JUAN]:=C2=A0 Hmmm, I thought that it was important = to emphasize it becomes optional because of *this* draft redefinitio= n of rules. Don=E2=80=99t you think it=E2=80=99s important? (whatever wordi= ng you want to use). Regardless, refer to my new reworded 2 paragraphs above = for that section .

=C2=A0

=C2=A0

=C2=A0

Thanks,

-- Magnus

=C2=A0



--

-- Magnus



--
-- Magnus