From nobody Mon Oct 2 05:41:10 2017 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 3804B1345EA for ; Mon, 2 Oct 2017 05:41:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 4nXI29jMO_Fs for ; Mon, 2 Oct 2017 05:41:03 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9D5D1345F8 for ; Mon, 2 Oct 2017 05:41:00 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id k123so1482658qke.3 for ; Mon, 02 Oct 2017 05:41:00 -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=PtBR7xog8LtQDYWaqiCzQv12ijwOKjK7NsD/P9DFHD0=; b=L2nNAi6pb5yrsGNOPxeQERQqElb2JvZbuswkrhWyIS3rIfC4ywKYtU/qnce+JqDoRz ZQffWqzusR5F50JsFQsWEvJHqRPitptCa+wwBjzY77h9Udi+EYS3fk8KUCmzJekjCtOl PjRB0wY/Wgb1ddn8UFjpVRw55IxiWxgpWK6Ec= 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=PtBR7xog8LtQDYWaqiCzQv12ijwOKjK7NsD/P9DFHD0=; b=siUAtt/GDIKfks0jUakKYI7hDHpSIVWpNn/1hE2Wvuv8o0cOhmSXKfuoNCnGs6UiTA fJI8OBZ7d4reFN/u2Xo5DRr/35l1A2LPa0yTKXmZ/s65HsfzrC/SiD2WLG7GnSNNiC10 JUb64vekV642YcpTAsWz5KFl/ti/2vODOYgz0pdd2DT7F8jPwRyyWfepteQUFJAZ6K+e CzB7yCFjPC1BgWHOhqI5Z7ZZRn3HkZ5ugBxW2XpfWs5/0RIrXZuogmWQ4B3F+3h/00mS bGxuKJXOcca1harXZgFLdZYkgazUjQGC91HLDIWEjhqdUAKNg6/WpTQMWCGVKUZoP6K4 i8rw== X-Gm-Message-State: AMCzsaWI2vAWTJMABjYLtif2WornPV1C5d7VqMPdVwfyV0SLlnbCeJmZ TXI5f6V682GiYe9tNr9N4zsmsw== X-Google-Smtp-Source: AOwi7QCSxr/z3ffaYxs96nnFZLUONd8EdLT03yOyO0vU17sCqd/FNFUvemg9xyKIlKFYyeDT4gTkyQ== X-Received: by 10.55.201.135 with SMTP id m7mr9904079qkl.97.1506948059586; Mon, 02 Oct 2017 05:40:59 -0700 (PDT) Received: from [192.168.2.27] (pool-173-66-76-215.washdc.fios.verizon.net. [173.66.76.215]) by smtp.googlemail.com with ESMTPSA id c188sm6195096qkg.55.2017.10.02.05.40.55 (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 02 Oct 2017 05:40:59 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.7.6.170621 Date: Mon, 02 Oct 2017 08:40:50 -0400 From: Carl Wallace To: CC: , "iesg@ietf.org" Message-ID: Thread-Topic: secdir review of draft-ietf-nvo3-mcast-framework Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: Subject: [secdir] secdir review of draft-ietf-nvo3-mcast-framework X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Oct 2017 12:41:04 -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. The summary of the review is Ready. The draft provides additional detail for handling multi-cast vs the material in RFC7365 and RFC8014. The draft references RFC8014 for Security Considerations content, which in turn reference RFC7365. This seems fine (though I was surprised the additional depth of detail on multi-cast did not generate any additional detail in the security considerations section). From nobody Wed Oct 4 00:49:18 2017 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 BF58813306F; Wed, 4 Oct 2017 00:49:16 -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_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] 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 ahutnP0Cpwre; Wed, 4 Oct 2017 00:49:15 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (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 5C18113295C; Wed, 4 Oct 2017 00:49:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.42,477,1500933600"; d="scan'208,217";a="239664657" Received: from demeter.inrialpes.fr ([194.199.28.3]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Oct 2017 09:48:31 +0200 From: Vincent Roca Content-Type: multipart/alternative; boundary="Apple-Mail=_F477EB85-9715-4A3A-BBD8-F415662B0F8C" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <79DA00BE-AA86-44AC-89B0-FA03CABDF519@inria.fr> Date: Wed, 4 Oct 2017 09:48:31 +0200 To: IESG , secdir@ietf.org, draft-ietf-curdle-rsa-sha2.all@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [secdir] Secdir review of draft-ietf-curdle-rsa-sha2-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 07:49:17 -0000 --Apple-Mail=_F477EB85-9715-4A3A-BBD8-F415662B0F8C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello, I have reviewed this document as part of the security directorate=E2=80=99= 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. Summary: Ready with nits The document is well written and security considerations appropriate. However I have a comment. The document includes reference [800-131A <>]: NIST Special Publication 800-131A, January 2011. Looking at the NIST web site, this reference is now superseded by: NIST Special Publication 800-131A Rev. 1, November 2015 As I understand, the new version should be referenced instead of the = original one. Since this revision includes new, updated recommendations on when a = given algorithm is considered deprecated, this may impact a little bit the = document. Cheers, Vincent= --Apple-Mail=_F477EB85-9715-4A3A-BBD8-F415662B0F8C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello,

I have reviewed this = document as part of the security directorate=E2=80=99s 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.

Summary: = Ready with nits

The = document is well written and security considerations = appropriate.
However I have a comment.

The document includes = reference [800-131A]:
NIST = Special Publication 800-131A, January 2011.
Looking = at the NIST web site, this reference is now superseded by:
= NIST Special Publication 800-131A Rev. 1, November 2015
As I understand, the new version should be = referenced instead of the original one.

Since this revision includes new, = updated recommendations on when a given
algorithm = is considered deprecated, this may impact a little bit the = document.

Cheers,

   Vincent
= --Apple-Mail=_F477EB85-9715-4A3A-BBD8-F415662B0F8C-- From nobody Wed Oct 4 15:08:47 2017 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 8EA051344D7; Wed, 4 Oct 2017 15:08:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Melinda Shore To: Cc: draft-ietf-rtgwg-uloop-delay.all@ietf.org, ietf@ietf.org, rtgwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150715491656.6673.6134344241640965386@ietfa.amsl.com> Date: Wed, 04 Oct 2017 15:08:36 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-rtgwg-uloop-delay-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 22:08:36 -0000 Reviewer: Melinda Shore Review result: Has Nits This document describes a mechanism to mitigate against failures stemming from the formation of "microloops" during a re-routing convergence, as described in RFC 5715. Modulo some mechanical problems with language usage (i.e. grammatical errors) and some missing definitions, the document clearly describes the problem it is addressing and the proposed solution. The security considerations section is very clear about why the authors believe no new attacks are introduced by this mechanism, and it is credible Sections 4 and 5 represent the core of the document and are very clear - a very nice piece of specification. It would be helpful to have a terminology section, or to expand some of the acronyms in-line (LFA, for example). For some reason the grammatical errors are clustered towards the front of the document but there are many scattered throughout: Section 1, first paragraph singular/plural mismatch: "Based on network analysis, local failure make up a significant portion of the micro-forwarding loops" Section 1, second paragraph unidiomatic use of "the topology" Section 2, first paragraph unidiomatic use of "high damages" Section 2.1, first paragraph needs an article on "IGP shortcut" Same paragraph, doesn't need an article on "the router C" Same paragraph, "nexthop" should be two words Item 1 in 2.1, needs an article before "preprogrammed FRR path", also run-on sentence needs to be split or a conjunction inserted Item 3 in 2.1, "no more" should be "no longer", and "encapsulate anymore" should be "does not continue to encapsulate" Section 2.1, last paragraph: "The protection enabled by fast-reroute is working perfectly, but ensures a protection, by definition, only until the PLR has converged." is somewhat unclear Section 3, third paragraph: first comma is unnecessary. Also, "local only" should be "local-only" Section 8.2, first paragraph: "associating timing" should be "associated timing". Also in section 8.2, the message chart header is separated from the actual contents by a page break, and that should be remedied Section 8.3, first paragraph: "that happens" should be "that happen". Also, "without further delaying route insertion" would be more idiomatic than "without delaying route insertion anymore" Section 9.1, throughout: "nexthop" should be "next hop" Section 9.1, first bullet item: "only have one" should be "only has one" (or "has only one") Section 10: "a good behavior" should be "good behavior" From nobody Thu Oct 5 03:53:59 2017 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 63A4013214D for ; Thu, 5 Oct 2017 03:53:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Tero Kivinen To: X-Test-IDTracker: no X-IETF-IDTracker: 6.63.0 Auto-Submitted: auto-generated Precedence: bulk Reply-to: secdir-secretary@mit.edu Message-ID: <150720083840.1286.9131028851567485128.idtracker@ietfa.amsl.com> Date: Thu, 05 Oct 2017 03:53:58 -0700 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Oct 2017 10:53:58 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2017-10-12 Reviewer LC end Draft Stephen Farrell 2017-10-06 draft-ietf-mpls-spring-lsp-ping-11 Joseph Salowey R2017-10-11 draft-ietf-opsawg-service-model-explained-04 Takeshi Takahashi 2017-10-04 draft-ietf-lisp-sec-13 Tina Tsou 2017-10-03 draft-ietf-rtgwg-routing-types-15 Tom Yu 2017-07-25 draft-ietf-lamps-rfc5280-i18n-update-03 For telechat 2017-10-26 Reviewer LC end Draft Derek Atkins 2017-10-16 draft-ietf-bier-mpls-encapsulation-09 John Bradley None draft-ietf-acme-acme-07 Daniel Franke None draft-ietf-i2nsf-framework-07 Ólafur Guðmundsson 2017-10-13 draft-ietf-uta-email-deep-09 Dacheng Zhang 2017-10-13 draft-ietf-mile-rolie-10 Last calls: Reviewer LC end Draft Shaun Cooley 2017-10-11 draft-ietf-grow-bgp-gshut-11 Alan DeKok 2017-10-09 draft-ietf-tsvwg-ieee-802-11-09 Donald Eastlake 2017-10-09 draft-ietf-oauth-discovery-07 Shawn Emery 2017-10-09 draft-ietf-curdle-pkix-06 Daniel Gillmor 2017-10-17 draft-ietf-sidrops-bgpsec-rollover-02 Phillip Hallam-Baker 2017-10-13 draft-ietf-ospf-segment-routing-extensions-19 Phillip Hallam-Baker 2017-08-11 draft-ietf-rtcweb-jsep-23 Steve Hanna 2017-10-12 draft-ietf-sunset4-ipv6-ietf-01 Dan Harkins 2017-10-12 draft-ietf-dnssd-hybrid-07 Paul Hoffman 2017-10-12 draft-ietf-anima-voucher-05 Russ Housley 2017-10-12 draft-ietf-anima-prefix-management-05 Russ Mundy 2017-09-14 draft-spinosa-urn-lex-11 Tim Polk 2017-09-11 draft-ietf-kitten-rfc5653bis-05 Tom Yu 2017-09-28 draft-ietf-ippm-alt-mark-12 Tom Yu 2017-02-20 draft-ietf-slim-negotiating-human-language-13 Early review requests: Reviewer Due Draft Daniel Gillmor 2016-02-01 draft-ietf-rtcweb-security-08 Christian Huitema 2017-10-18 draft-ietf-lwig-crypto-sensors-04 Next in the reviewer rotation: Leif Johansson Benjamin Kaduk Charlie Kaufman Scott Kelly Stephen Kent Tero Kivinen Watson Ladd Ben Laurie Barry Leiba Chris Lonvick From nobody Thu Oct 5 13:16:14 2017 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 BF0AC134315; Thu, 5 Oct 2017 13:15:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Russ Housley To: Cc: draft-ietf-anima-prefix-management.all@ietf.org, ietf@ietf.org, anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150723455673.6154.11287987531699991961@ietfa.amsl.com> Date: Thu, 05 Oct 2017 13:15:56 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-anima-prefix-management-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Oct 2017 20:15:57 -0000 Reviewer: Russ Housley Review result: Has Issues I 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 authors, document editors, and WG chairs should treat these comments just like any other IETF Last Call comments. Document: draft-ietf-anima-prefix-management-05 Reviewer: Russ Housley Review Date: 2017-10-05 IETF LC End Date: 2017-10-12 IESG Telechat date: Unknown Summary: Has Issues I did not review the state machines in detail. I assume that others that are far more familiar with PIM have done s detailed review of them. No Major Concerns Minor Concerns This document uses "DHCPv6-PD" and "DHCPv6 PD". At first, I was going to recommend picking one spelling. However, RFC 3633 does not define either of these. So, some explanation is needed in addition to being consistent. In Section 3, the document says that roles can be locally defined. If I properly understood the rest of the document, this is just a indirect way to state the prefix size. If I got that right, it would help to explain this to the reader as soon as possible. In Section 3.2.1, please give some examples of device identities. Are we talking about a serial number or something else? In Section 4.1, the document says: It should decide the length of the requested prefix and request it by the mechanism described in Section 6. However, Section 6 talks about: ... Thus it would be possible to apply an intended policy for every device in a simple way, without traditional configuration files. I do not see how the mechanisms in Section 6 increases the allocation for a single router. It seems to increase the allocation to all routers with a particular role. Nits Throughout the document, I find that "administrator(s)" grabs my attention. I suggest that "administrators" would be better for the reader. In Section 1, please spell out the first use of "ASA". In Section 3.1: s/with minimum efforts/with minimum effort/ From nobody Thu Oct 5 16:01:43 2017 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 AB5C613432F; Thu, 5 Oct 2017 16:01:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Paul Hoffman To: Cc: draft-ietf-anima-voucher.all@ietf.org, ietf@ietf.org, anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150724449566.3167.10676079841422142298@ietfa.amsl.com> Date: Thu, 05 Oct 2017 16:01:35 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-anima-voucher-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Oct 2017 23:01:36 -0000 Reviewer: Paul Hoffman Review result: Ready The protocol described here is a YANG module signed with PKCS#7 1.5. The use of the signed information described sounds fine, and the reference to PKCS#7 1.5 (RFC 2315) and the subparts was complete and clear. From nobody Thu Oct 5 18:21:15 2017 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 A73DB133226; Thu, 5 Oct 2017 18:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 QoRSRbH2cTKT; Thu, 5 Oct 2017 18:21:13 -0700 (PDT) Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67B5613320B; Thu, 5 Oct 2017 18:21:13 -0700 (PDT) Received: by mail-pg0-x22e.google.com with SMTP id p5so9156657pgn.7; Thu, 05 Oct 2017 18:21:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=TiDHaVB+6LbQtkYH0DzJqGNjYt0vvgYTan7/tPyjlR0=; b=GLbt2jc14YJu1BC7Mt1r5ZZzCnhoW7E/zj4RNF1fZJrMjbbZVmg4/+yHgbPx7BAC1a XDnbj08XNe1dCS0HD9iSwYJvkkFIz6VtKOjOOgKMjSctXndbbYJngKpUwKRusLmndp6p 3l82J0dvMf/EhoBBq8cZZo1iAuBtLf4GkLL8SFqXNlVBdeH/xeX+8K5PFEefomL/+clf X2aTo2NGtoWRZutNzkujdj+Xxx646i62XfcOjn/MK5lSOSChYuQN5cUQinyKBDiQkjVs 43I4xRJEHzRIOEwFQ4Ua+PRjm2e4OWabipzL7tDdsnmGOrr3b+L5fL16aY2stq3vlF7Q NyUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=TiDHaVB+6LbQtkYH0DzJqGNjYt0vvgYTan7/tPyjlR0=; b=pQagclvBZMci0hLo1VBH7dSWzs+Nnm6u8n1XeATSK+NPgiOQG8bEpx1tOIGk9dzfyM K+b/aEDrH2XKQty9Q8EqZY8v7CUfDvYLrijiwZ8yYJaiAPAN6z5Fq3zGxeBYiggzW1ko Mu9BAbG/7DJMTszFTdIXsE1+lReKUFiTtTpioKdPKqVDn5lotGOW4Rpn2OhwusWqlch8 fiGpV+gTBsKpEYtlrakpNH841AUHvp3eEpBudMMHEdHcZVkweYxJpfSHskxkcEERkla6 TSBaV4Q8WjbokeDthv027Ik6hRF3YoxZuQCtYs+WyTu1TGhfPPjfwovX6Ey1XnGELMX1 bElA== X-Gm-Message-State: AMCzsaWGGm8sZM9BOrs9L6CZCMkviihJeNJczidCn+xuiehn52C423Df x3ATZdoPP+/Ou5AFBxei3dcF8Q== X-Google-Smtp-Source: AOwi7QAzwDAMmQcJT2rIShJQdibaEseMXO34HBxVwM7nX2wNo/Czy3sr+wxjfcrMmKrcPLtKmj27Rg== X-Received: by 10.84.218.131 with SMTP id r3mr437255pli.271.1507252872640; Thu, 05 Oct 2017 18:21:12 -0700 (PDT) Received: from ?IPv6:2406:e007:6d3c:1:28cc:dc4c:9703:6781? ([2406:e007:6d3c:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id k67sm286655pga.46.2017.10.05.18.21.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Oct 2017 18:21:11 -0700 (PDT) To: Russ Housley , secdir@ietf.org Cc: draft-ietf-anima-prefix-management.all@ietf.org, anima@ietf.org References: <150723455673.6154.11287987531699991961@ietfa.amsl.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <7ced8d26-61c8-be72-ff49-68051cb07607@gmail.com> Date: Fri, 6 Oct 2017 14:21:18 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <150723455673.6154.11287987531699991961@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-anima-prefix-management-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 01:21:14 -0000 Thnaks Russ, all valid comments. We'll take care of them at the end of Last Call. Regards Brian On 06/10/2017 09:15, Russ Housley wrote: > Reviewer: Russ Housley > Review result: Has Issues > > I 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 authors, document editors, and WG chairs should > treat these comments just like any other IETF Last Call comments. > > Document: draft-ietf-anima-prefix-management-05 > Reviewer: Russ Housley > Review Date: 2017-10-05 > IETF LC End Date: 2017-10-12 > IESG Telechat date: Unknown > > Summary: Has Issues > > I did not review the state machines in detail. I assume that others > that are far more familiar with PIM have done s detailed review of them. > > > No Major Concerns > > > Minor Concerns > > This document uses "DHCPv6-PD" and "DHCPv6 PD". At first, I was going > to recommend picking one spelling. However, RFC 3633 does not define > either of these. So, some explanation is needed in addition to being > consistent. > > In Section 3, the document says that roles can be locally defined. If > I properly understood the rest of the document, this is just a indirect > way to state the prefix size. If I got that right, it would help to > explain this to the reader as soon as possible. > > In Section 3.2.1, please give some examples of device identities. Are > we talking about a serial number or something else? > > In Section 4.1, the document says: > > It should decide the length of the requested prefix and request it by > the mechanism described in Section 6. > > However, Section 6 talks about: > > ... Thus it would be possible to apply an > intended policy for every device in a simple way, without traditional > configuration files. > > I do not see how the mechanisms in Section 6 increases the allocation > for a single router. It seems to increase the allocation to all routers > with a particular role. > > > Nits > > Throughout the document, I find that "administrator(s)" grabs my > attention. I suggest that "administrators" would be better for the > reader. > > In Section 1, please spell out the first use of "ASA". > > In Section 3.1: s/with minimum efforts/with minimum effort/ > > > From nobody Fri Oct 6 05:35:21 2017 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 BC7181349A5; Fri, 6 Oct 2017 05:35:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Phillip Hallam-Baker To: Cc: draft-ietf-rtcweb-jsep.all@ietf.org, rtcweb@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150729330872.6204.16821957868857533343@ietfa.amsl.com> Date: Fri, 06 Oct 2017 05:35:08 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-rtcweb-jsep-23 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 12:35:09 -0000 Reviewer: Phillip Hallam-Baker Review result: Ready Given the design constraints in which the protocol operates, it is hard to see how this could be done differently. I have two sets of security concerns. One is that implementations need to be designed so as to avoid buffer overrun conditions and also to prevent such conditions leading to a breach. Compression formats such as are inevitably used in video and image applications tend to make promiscuous use of nested length encoding formats that commonly lead to security vulnerabilities. This document does not have such a warning, having a reference on most of the security issues, a warning on this issue should appear in: https://tools.ietf.org/html/draft-ietf-rtcweb-security-08 The other security concern is that giving control over the host browser to run pretty much arbitrary code was always going to be a security disaster but there isn't much that can be done at this point. From nobody Fri Oct 6 07:35:14 2017 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 4ACCC1342E9; Fri, 6 Oct 2017 07:35:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Stephen Farrell To: Cc: mpls@ietf.org, draft-ietf-mpls-spring-lsp-ping.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150730050726.13161.17866745423154681018@ietfa.amsl.com> Date: Fri, 06 Oct 2017 07:35:07 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-mpls-spring-lsp-ping-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 14:35:07 -0000 Reviewer: Stephen Farrell Review result: Ready Hiya, The document describes yet another variant of ping and traceroute for MPLS, which is fine. The security considerations text is probably right in saying there's no big delta here vs. RFC 8029. I do have one query: The "protocol" field in the requests here seems like it's maybe a new thing, that wasn't in 8029 (or at least wasn't clearly there from my fairly uninformed read:-). That's defined as: Set to 1, if the Responder MUST perform FEC validation using OSPF as IGP protocol. Set to 2, if the Responder MUST perform Egress FEC validation using ISIS as IGP protocol. I don't know what's required for those validation steps, nor if there's any chance that doing such validation could form a new DoS vector, or if it could (interestingly) affect the interpretation of the information in the responses (say if validation can affect response timing in some weird way), so this is just to check if there's anything more to be said about that. I assume the authors' answer will be that implementers of this will know what validation means here, that it's no big deal as a DoS vector and that the timing effects are not a problem. If so, that's probably fine, but it might be good to verify that. Cheers, S. From nobody Fri Oct 6 07:40:56 2017 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 A04DE1349DD; Fri, 6 Oct 2017 07:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=juniper.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 ZBKmz4ZO4n7x; Fri, 6 Oct 2017 07:40:53 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0118.outbound.protection.outlook.com [104.47.32.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BF701342E9; Fri, 6 Oct 2017 07:40:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Y36y4FGDtdJVFf6bpV/Gni+eL4sCiflS/f/KDwZMbFA=; b=SuG10aYMkHBI9kaMIxkQgA/jsfsBgejsrRu55k4CEOTT2qdGOE9AwUpFvHpk/3H6FO0JgOz1vuwXBRZLbMwxmdkrkRCpvnV5O0aX4RDqjDv0KpMm8nvn2NOkdTtlGNcX49bvOQACwlelvTs9hVorVDH+T1cUiiXWkPL9GbGtZuk= Received: from tokolowicz-sslvpn-nc.jnpr.net (66.129.241.14) by SN2PR05MB2510.namprd05.prod.outlook.com (2603:10b6:804:13::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Fri, 6 Oct 2017 14:40:47 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: "John G. Scudder" In-Reply-To: Date: Fri, 6 Oct 2017 10:40:41 -0400 Cc: stefano previdi , "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-idr-bgp-prefix-sid.all@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <13FD5BC6-69AD-46F1-8767-DE11740A49A0@juniper.net> References: <150071889993.20425.5273428383173596948@ietfa.amsl.com> <6A05B578-F8DE-4197-97B8-82886089782B@previdi.net> To: "Brian Weis (bew)" X-Mailer: Apple Mail (2.3273) X-Originating-IP: [66.129.241.14] X-ClientProxiedBy: MWHPR1401CA0009.namprd14.prod.outlook.com (2603:10b6:301:4b::19) To SN2PR05MB2510.namprd05.prod.outlook.com (2603:10b6:804:13::19) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 47d36bc0-2a6a-42ec-f052-08d50cc83c81 X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:SN2PR05MB2510; X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2510; 3:XlWp/T5zt2d4V/rKUYvkVwkcdvWINIgAs0P1wfjCIn+x8FPfTRXicAcm144K47im2c3EmdlCa1DHdSGaf1pNtrMJrIG1wmR4DGP5drt4EbhRyZcuaUQO2eSUnnqQNkQP9oUbW24nC7iK21GROjx+agKhYJ8qRaL01kPS2rnv9jrUlNpnuI2aoAQRCOr5tiZG3PFPJqkno5/aVfk88WvY+ancblaVPwrYKIN1Rv19luo4fcDnBGezF7lcgJtmfXKm; 25:KlG3irpvMzAl0AB/nQiTtvCFY2XE3dJKRVi6ubeRpANFaLjg3MaLcDOLqfGLDozPX6PH4C1gOGo7M293ZN6XIc+uxu9R3rNAjcu8vkQ9GxrTNLXbGFg8yxrGLiI7UGqU7hh66aXcSfR2yKnEDnof8lOGMDPr2FZ5YfjyojC/fVWP84GMZSbzPtgpTxVWJ/VJ4byivRtSJdXs5v1pyIpTcqTSMW/8eInq9L0uS53nTzAK8mTAd8Lzu+qBYllAc70EbFKwemG7cl147P4KxFyswlXn6cQXmbMMUbqPvLOcHckXlAsb/Mc3b0ttt14n2uhmX2oKSwFnE8RbOv5y8nrQyw==; 31:nE950yOa4N3d+tqTEXWx4hahnDEuUb5b1UMQtBKNRM81xAcafdJj5OJGmGpySp/Y0cbEuvsukH0wvcnTM/xhyiOoLoXZc7F14SjaPA9Qj3dkgd0P5XeDDXFtIr6LzLcPTMElq1TbyX+aluuvDtJ+ZUOKYs2AnV8dtbq4kaErCvIdcNDx/JLGyGLnW2a81k75aVOs8AOj/hkoNdDfMRtuCTbYirRScNhpJvpV/zoVQnE= X-MS-TrafficTypeDiagnostic: SN2PR05MB2510: Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2510; 20:UK9yTU4TmYIrRmN0VuE+pqY+lX8KDh2MhUnZoa1TsutkHDogFVjC2ECXGroAg3KusNxQ4LbIp+bKH9ch7csGk8CeYeSVABRh4IdOKdf0kmkNNA1yHWKtYvjpuZJF9fbWS6Pq308zN2Fa1xkwES0bZ6AsxfrbbkAZm3rc+W+vtuFLHA5gZPbZc6qxFM9OQXwWrPNt73JwiQqLIMRC2k04F0dJpk9dqzG4vPz3hjZQXqhtDwHfzkHaePAfZNz4SHK7hFkIfK91PSImGkfugqQorEamlXif6FH/qELR/jXFzIOjxt59uMPR9+Ov33kRSu1cnpvvLTpV/9c5f6UMhKTM+yQT9c6gC764RPD24T+5QCOD2nUtx8YzWX+JZyUbGNy35P+u5HXgMNTijXTqczK0LKwqoxQhMp261dPmAJhtFc8juiLU2PLPzFvs80JRSLTF9lPtXfAfWRlmziynhvtDXpii55Sp3F62N3QxDhslx2kLbvwOi0vieaHkm6svjfFqFzZ7tID3cQhmIVYy7oFmzfIao0zr0AWNsQwYuDxWSHj95/2FTxl95Osu2HMPh2/vins2YVnQrIbMbkf4O8cUDzkk/CnpAW9tuNtp3X87EtU= X-Exchange-Antispam-Report-Test: UriScan:(192374486261705)(100405760836317)(95692535739014); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(12181511122)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(3002001)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123560025)(20161123564025)(20161123558100)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:SN2PR05MB2510; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:SN2PR05MB2510; X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2510; 4:J+T1ejz11IM/mPXcns2a8eUC+VGDLtRq7WQN/TbtGe6IytZYmVXdgKjcYANqRYIBtLaGdGiUKFc5OUkA07kkdp0DJeYRUuAhFNNsSoPArRnSrY6PMEr1gKgXH5A6g66S6f1T2sMn/HN2PrhgNeoCLLrlG8RaPWNZLR4NCW7n0GkUPAiSiDEj/ezPed0uG1uU2HdeAq1fGZx8AG6AAF9nCjRLLF8zgdOy8K1TvTF1d10+OHm/iJv+0mIVMt8/MzDO2Pc7mQdSDmp7kWIFoU+PmH18nnKGdlvVtsoQalteX31QrAihU4hJYY7WKgTDPyeAMda2gpAyXX99qvpG2poK/6IAsAinTDbVQ6GeB5Dox31gHfb/9PlHD9pL2iLxPIHX X-Forefront-PRVS: 0452022BE1 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(376002)(39860400002)(346002)(24454002)(189002)(377454003)(51914003)(252514010)(199003)(23676002)(4326008)(305945005)(6512007)(36756003)(6916009)(2950100002)(83716003)(69596002)(8676002)(53546010)(16526018)(2906002)(50226002)(81156014)(5660300001)(8936002)(81166006)(68736007)(8746002)(7736002)(316002)(50466002)(106356001)(82746002)(33656002)(230783001)(54906003)(229853002)(53416004)(6486002)(6666003)(105586002)(101416001)(86362001)(66066001)(53936002)(6506006)(97736004)(50986999)(25786009)(57306001)(76176999)(189998001)(3846002)(6116002)(47776003)(478600001)(6246003)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN2PR05MB2510; H:tokolowicz-sslvpn-nc.jnpr.net; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtTTjJQUjA1TUIyNTEwOzIzOkdGSStsMTVWTnN3R1V6TkhKb1hrVExtZ0xx?= =?utf-8?B?WHV3aUdUUTQ3VFpPQVNIaFNzbmh2TExiWVJwNWdtRytiL0xqdTE3dDFFVEpw?= =?utf-8?B?ZE9BN3VlbnE5cllUeHhPa0pJRGcrZ3gvZTdlS3pBNmJHUjZkWEQ5ZUdadmxp?= =?utf-8?B?eHE3THFhc2xjaDIwamovYzJHR2VyOFgxTytybVE3TmhkbitaTE05a0ZzdVpT?= =?utf-8?B?ZVY5Zm95NnR0ZjAvQUZkby9EWGZkN2c5NTNpYyt0TWh5U2tGZ0lBUFhZMTQx?= =?utf-8?B?azU1S3FiK3JyUjJueTNHTlFocHEvM3d1UVoydUNFcmVGK3UxVmpJcGRhdEo3?= =?utf-8?B?UDhkZ3ZuSHE1b1dFZlNCbnhCSGp0eEJSVnMxVlRmaExxTWQvdFBSSUxTQ1da?= =?utf-8?B?TnhZRnl1RVZ4ZFdiUXJYNy9ZOVYxVGw5eHJaYkw0RVZqUkY1aDNoTEN3cjl0?= =?utf-8?B?Nlp3ZVJ5bzhVbU83MHF0SXlzTjhvdEdqZVdWVVdqa1VzN0wxQVRnVGtUaFo5?= =?utf-8?B?ZHZKRlV3N3FCVjRFS2g4Ly9wTFZZdzNxZWtuOUxad1FwYmswS1VrVUE2VVlZ?= =?utf-8?B?Q0dWall0dlB4Y2FuM0lUR0ZwaUZLUU1tUHBGek1PdjZOVnRNTkJBdjFIK21z?= =?utf-8?B?aXFBckFwVU1NOGRxK0hhYTF4aHdVa0cyQUk0TU5OYVVFUWxTNEZzOVJKUCtp?= =?utf-8?B?ejFYVEZ3MEtUUzZKc2t1OFFzd0p5ZUxWa2dXTzlRZ1hvSjF4TXdRS2ZISGlJ?= =?utf-8?B?YW54RFllZ3g1YmhDSFlpaGVHMFFtK2I2c0trK0tOcFFsc0t4NEJCY3huZFlu?= =?utf-8?B?bzBEdlFZUHlCV1pWbFhzakRmQU8zRFQ4T2d2b2pGQWw0NUJVKzdxMndDMDhr?= =?utf-8?B?L2VIZG9hbEJ1L29ISmtNMzRzbTM3VnpSU24ycmhKMWYwWnVwRWsxUkd0L0Ns?= =?utf-8?B?b3JVK3RjN1VCQUFENFpURmEwTFB0OGFkMUhIYWQ5WmMwU3JTVjZGdTlsVk80?= =?utf-8?B?NWorSXFSOFhDMXdXN3MxSSs4dzl0NTc2bGJxdnpCNjZVUXU2SFBxQkxKUlJj?= =?utf-8?B?MzZaOW00TCtMeEoyUUNMWDlHOWd5dVcvd252UUFuSWI1VGtSSkUxek9mZG1E?= =?utf-8?B?Mk1hRUFBeEpVSUdsRnBFakhMUlVZZEUxdzlqZXF2SitpRTBxZEJDcERjVjBY?= =?utf-8?B?TjEvWVNBTVI2UnVHY3VBWU9odzNyOUl5UEVKNDNtZ3Fsc0RnZTlPUi9qaHRt?= =?utf-8?B?dHBYWWJoelVzb2V6RzRlWUVROGc1ODNPOG5DNDRrVzcyaHgyWUlVWnUvYzZK?= =?utf-8?B?YW1GeWdmK1JWV1YvSFJQdm53T3lPWUxGcFRhME94NElxWlg5TUFXVDV0eEVO?= =?utf-8?B?SFl5V1FnRjVHRzdvNkFwMXdTSHpVT0g4djJYRy9HV0VuTUhHVXJxbHI5QjND?= =?utf-8?B?SmNLaTVGUkthTzhDTnlEYWxuTDU0MnpYdDJ1cGN1SWdEanNBbi94di9ETmhh?= =?utf-8?B?R0k5SXhUVmlnM1pWTFBVaHZCNkFqODZuK3NTby9qUlFDVnl1cmpETTVFNDln?= =?utf-8?B?bVVSK3FJOVlFV2dqNHNENlZIOEM2Y2NPZGU1YUE3WVVGVWZCbE9xZlFXNWJ0?= =?utf-8?B?VkppU0xiS29YUm5CbmlTTnk1dVRzNGhFcnJhWjZUTkhvOG9mM3JlUW9nRTQz?= =?utf-8?B?RmFLZWc3Yy9rN2pKYytUTWMyc0ttckdOeGlyREJuTTZJZzIvNkxWY2x5K0tT?= =?utf-8?B?N3MrR0NGbFhQQm1JNGlkZXlxT2l4SWdhYXZ6aGx0N0loT3N0NC9URXlTdTZU?= =?utf-8?B?di9VMzhjWXEyWlRNdmlVUUJsYTU0VU5IWFIxaU9NbEE2TS82NWdGZkdUaFhI?= =?utf-8?Q?Uu7QnhzpanI=3D?= X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2510; 6:yOlgv7s20vVIU8CRK7IzOokP+AfD5Q42z+gQhAZupqd045oeqm7N8z/sYRpYiQtyIHBCBawGmKaTE9wu6T0vfNmms/aG+MAMjPNhUOZ/r0hqrFGJ6uwgAwqWd2zjxJQMgje96xGDHtodfNqafuEu0EAvLHGf4s0I6TRhnrGIK6G4nYa2LieSKRo/MMTHbw1kcX3QLQJ2ZTDY6E8wN+i9GFO+DDqVB6Q8EeMnSDGdEUmbcndF+rcpr3xoS/5P8PkB0SJCMGn3tXH7uk1xjGB5svGFdcqIuSfRwPuLVg3DbJ/wEEfUg2L8CkXFYpLTz3eVFm7fmOlTW4OV6JSKr9qx8g==; 5:SlcszQcNxIGfYumnK0olPNf+D0ohrGCks3Og62TZ8exeoWdrt+FJ08BJKpUooKRvtFxOuJLXNAmdQfscDP9UXXMKYTc47OqLyHAUt/wHADDlfMmSWoZM0aEjfKn6yKLasxXuP9R4H3/Oe4m3bv7iOQ==; 24:5zanpy5/orY9EaWbXFuhA2h5+AdCNq749E+Opm4G4WEMyz3+wzLCPWgmWPWfZLjSQMg5Jn8lpE0OQc6Npf86+xKryM4+zZvWw6zq0zJ6a20=; 7:ceHImxWmCykv8rrrY/NSJlC0yLqBFCKUqhdcCNplZQLRJUgsMV0Dn8gNLfEwadldjgRUy8L6aOoaHWeBq/kNW3sKJWYB26UxCEORgGdHhoN22XBUrlUZjMC9YLBUeerL8h+gVV/sqzt2iq7iC3xKr9wDRpaJVcTNsIXTfEiaH6N4/Ss67EmT4nrT5ANYmGHFm5kr4FQM2Pz6xk0TgUPqmIcHcpJriUlGKwMd7vWL/yk= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Oct 2017 14:40:47.8434 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR05MB2510 Archived-At: Subject: Re: [secdir] Secdir early review of draft-ietf-idr-bgp-prefix-sid-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 14:40:56 -0000 Hi Brian and Stefano, I'm glad Stefano's comments satisfy Brian. It seems to me that this = clarification would be worth adding to a new revision of the draft: >> (c) Security Considerations speaks of limiting BGP Prefix-SID within = a >> =E2=80=9Cdomain=E2=80=9D. Is that intending to say an =E2=80=9CSR = domain=E2=80=9D? >=20 > More generally, by domain we intend the set of AS under control of the = same organization/operator. Seems as though the other nits were addressed with no change needed, or = that's my understanding of the consensus between Brian and Stefano. Stefano or other authors, can you either make the minor revision = indicated, or reply that you don't plan to? Thanks, --John > On Aug 4, 2017, at 7:46 PM, Brian Weis (bew) wrote: >=20 > Hi Stefano, >=20 > Thanks for your notes below, which make sense to me. I don=E2=80=99t = have any more comments.=20 >=20 > Brian >=20 >> On Jul 26, 2017, at 6:18 AM, stefano previdi = wrote: >>=20 >> Hi Brian, >>=20 >> thanks for the review. Some comments here below. >>=20 >>=20 >>> On Jul 22, 2017, at 12:21 PM, Brian Weis wrote: >>>=20 >>> Reviewer: Brian Weis >>> 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 describes a BGP extension to signal the BGP Prefix-SID = use with >>> Segment Routing. as well as the rules to originate, receive and = handle error >>> conditions. The BGP extension defines a new type of BGP path = attribute passed >>> within BGP, and does not change the security considerations of the = BGP protocol >>> itself. >>>=20 >>> I consider this document =E2=80=9Cready with nits=E2=80=9D. >>>=20 >>> The Security Considerations section reasonably states that the use = of this BGP >>> attribute =E2=80=9Cinherits the security considerations=E2=80=9D of = the BGP-4 RFC as well as >>> the RFC defining how labels are carried in BGP-4. As an aside, those = documents >>> are quite old. For example, RFC 4271 says that the TCP-MD5 option is = required >>> to implement for authentication, but this has been replaced by a = much stronger >>> authentication method (TCP-AO). It would be nice if we had newer = security >>> considerations for BGP-4 but that advice doesn=E2=80=99t belong in = this document. >>>=20 >>> The Security Considerations might have said something about the how = an AS would >>> protect itself against a peer sending the Prefix-SID attribute = across AS >>> boundaries, but that text is contained in useful places elsewhere in = the >>> document and seems sufficient. >>>=20 >>> I have only one nit, which is some confusion regarding scoping of = the SID. The >>> document clearly states that a SID has a limited scope within the = network,=20 >>> which is important because outside of that scope an SID value would = have a >>> different meaning. This is a security consideration, because = accepting a SID >>> in the wrong scope could possibly cause a security issue if packets = are >>> forwarded to the wrong identity (e.g, the packets were intended for = a firewall >>> within the AS, not a service outside of the AS). >>>=20 >>> (a) Section 5.1 says it should not be advertised outside of an AS = unless >>> =E2=80=9Cexplicitly configured to do so=E2=80=9D. It would be nice = if the conditions for >>> explicitly configuring the SID to be advertised outside of the AS = were >>> mentioned here. >>=20 >>=20 >> usually we don=E2=80=99t define these condition because they are = related to each individual operator policy. What we want to be sure of = is that any compliant implementation, by default, will not propagate the = attribute outside the AS. >>=20 >> Under which conditions propagation is allowed is a local matter of = the operator and how it is effectively achieved is a matter of local = implementation. >>=20 >>=20 >>> (b) The last paragraph of Section 8 says it is applicable within an = SR Domain >>> (i.e., more than an AS), and Security Considerations says something = similar. >>>=20 >>> (c) Security Considerations speaks of limiting BGP Prefix-SID within = a >>> =E2=80=9Cdomain=E2=80=9D. Is that intending to say an =E2=80=9CSR = domain=E2=80=9D? >>=20 >>=20 >> More generally, by domain we intend the set of AS under control of = the same organization/operator. >>=20 >>> I suspect whether an SID should be advertised outside of the AS = depends on >>> whether an AS is part of an =E2=80=9CSR domain=E2=80=9D or not, and = that there's likely never a >>> good case to advertise it outside of an AS unless it is part of an = "SR domain". >>> But it would be good if there was some text clarifying the = conditions when it >>> is reasonable to share an SID between ASes. >>=20 >>=20 >> Well, I=E2=80=99m not sure that would be a good idea because the = conditions may vary over time and we will never be exhaustive anyway. >> Thanks. >> s. >>=20 >>=20 >>>=20 >>=20 >=20 > --=20 > Brian Weis > Security, CSG, Cisco Systems > Telephone: +1 408 526 4796 > Email: bew@cisco.com >=20 From nobody Fri Oct 6 10:00:28 2017 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 0C85A134AD6; Fri, 6 Oct 2017 10:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VFwz2Vu0ltzs; Fri, 6 Oct 2017 10:00:25 -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 2B6D3134A4E; Fri, 6 Oct 2017 10:00:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7650; q=dns/txt; s=iport; t=1507309223; x=1508518823; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=CkbHCVgQC0eZ3x7NINH+yzDPMLNP088vLBrLWkJeBL0=; b=IVShVm0N2FqJaFWRby20jdt+daNYaUUb/m5MZZXiUfStv4tk5ksZnGDY u6pB+VdIUvg/lqSWAGM71q8hl3Ij4jeygKfMEPuXg4RdvHwtV2eYSPrvb xXPrZGSTREell4huwB3RyqXv+e4ZN12y8jh2wFJPg3pQq81lfLM1j7E11 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C7AAA/ttdZ/4YNJK1SBgMZAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGDXYFSJweDc4ofj2iBVCKWLw6CBAqFOwIahAY/GAECAQEBAQE?= =?us-ascii?q?BAWsohRgBAQEBAgEjETMSBQsCAQgYAgImAgICMBUQAgQOBYooCKQ1gieLKgEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAR2BDoIfggKDOysLgnOEUQEIAwcBNgomgkwvgjI?= =?us-ascii?q?FoTMClGOTCpUsAhEZAYE4AR84gQMLeBVbAYUHARuBZ3aGeg8YgQyBEAEBAQ?= X-IronPort-AV: E=Sophos;i="5.42,484,1500940800"; d="scan'208";a="13049610" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Oct 2017 17:00:00 +0000 Received: from XCH-RTP-005.cisco.com (xch-rtp-005.cisco.com [64.101.220.145]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v96H00q5027274 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 6 Oct 2017 17:00:00 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-005.cisco.com (64.101.220.145) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 6 Oct 2017 12:59:59 -0400 Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1320.000; Fri, 6 Oct 2017 12:59:59 -0400 From: "Brian Weis (bew)" To: "John G. Scudder" CC: stefano previdi , "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-idr-bgp-prefix-sid.all@ietf.org" Thread-Topic: Secdir early review of draft-ietf-idr-bgp-prefix-sid-06 Thread-Index: AQHTBhG4pVaqk4yamk2QE/uj/S+OEKJ1LtWAgGJqQICAACb8gA== Date: Fri, 6 Oct 2017 16:59:59 +0000 Message-ID: <303570DA-82F1-4540-BB05-61DC879A18A7@cisco.com> References: <150071889993.20425.5273428383173596948@ietfa.amsl.com> <6A05B578-F8DE-4197-97B8-82886089782B@previdi.net> <13FD5BC6-69AD-46F1-8767-DE11740A49A0@juniper.net> In-Reply-To: <13FD5BC6-69AD-46F1-8767-DE11740A49A0@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.191.171] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] Secdir early review of draft-ietf-idr-bgp-prefix-sid-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 17:00:27 -0000 SGkgSm9obiwNCg0KSnVzdCB0byBjb25maXJtLCB5ZXMgSSB3YXMgZmluZCB3aXRoIFN0ZWZhbm/i gJlzIHJlc3BvbnNlIGFzIHRvIHdoeSBubyBjaGFuZ2VzIHdlcmUgbmVlZGVkLg0KDQpCcmlhbg0K DQoNCj4gT24gT2N0IDYsIDIwMTcsIGF0IDc6NDAgQU0sIEpvaG4gRy4gU2N1ZGRlciA8amdzQGp1 bmlwZXIubmV0PiB3cm90ZToNCj4gDQo+IEhpIEJyaWFuIGFuZCBTdGVmYW5vLA0KPiANCj4gSSdt IGdsYWQgU3RlZmFubydzIGNvbW1lbnRzIHNhdGlzZnkgQnJpYW4uIEl0IHNlZW1zIHRvIG1lIHRo YXQgdGhpcyBjbGFyaWZpY2F0aW9uIHdvdWxkIGJlIHdvcnRoIGFkZGluZyB0byBhIG5ldyByZXZp c2lvbiBvZiB0aGUgZHJhZnQ6DQo+IA0KPj4+IChjKSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBz cGVha3Mgb2YgbGltaXRpbmcgQkdQIFByZWZpeC1TSUQgd2l0aGluIGENCj4+PiDigJxkb21haW7i gJ0uIElzIHRoYXQgaW50ZW5kaW5nIHRvIHNheSBhbiDigJxTUiBkb21haW7igJ0/DQo+PiANCj4+ IE1vcmUgZ2VuZXJhbGx5LCBieSBkb21haW4gd2UgaW50ZW5kIHRoZSBzZXQgb2YgQVMgdW5kZXIg Y29udHJvbCBvZiB0aGUgc2FtZSBvcmdhbml6YXRpb24vb3BlcmF0b3IuDQo+IA0KPiBTZWVtcyBh cyB0aG91Z2ggdGhlIG90aGVyIG5pdHMgd2VyZSBhZGRyZXNzZWQgd2l0aCBubyBjaGFuZ2UgbmVl ZGVkLCBvciB0aGF0J3MgbXkgdW5kZXJzdGFuZGluZyBvZiB0aGUgY29uc2Vuc3VzIGJldHdlZW4g QnJpYW4gYW5kIFN0ZWZhbm8uDQoNCj4gDQo+IFN0ZWZhbm8gb3Igb3RoZXIgYXV0aG9ycywgY2Fu IHlvdSBlaXRoZXIgbWFrZSB0aGUgbWlub3IgcmV2aXNpb24gaW5kaWNhdGVkLCBvciByZXBseSB0 aGF0IHlvdSBkb24ndCBwbGFuIHRvPw0KPiANCj4gVGhhbmtzLA0KPiANCj4gLS1Kb2huDQo+IA0K Pj4gT24gQXVnIDQsIDIwMTcsIGF0IDc6NDYgUE0sIEJyaWFuIFdlaXMgKGJldykgPGJld0BjaXNj by5jb20+IHdyb3RlOg0KPj4gDQo+PiBIaSBTdGVmYW5vLA0KPj4gDQo+PiBUaGFua3MgZm9yIHlv dXIgbm90ZXMgYmVsb3csIHdoaWNoIG1ha2Ugc2Vuc2UgdG8gbWUuIEkgZG9u4oCZdCBoYXZlIGFu eSBtb3JlIGNvbW1lbnRzLiANCj4+IA0KPj4gQnJpYW4NCj4+IA0KPj4+IE9uIEp1bCAyNiwgMjAx NywgYXQgNjoxOCBBTSwgc3RlZmFubyBwcmV2aWRpIDxzdGVmYW5vQHByZXZpZGkubmV0PiB3cm90 ZToNCj4+PiANCj4+PiBIaSBCcmlhbiwNCj4+PiANCj4+PiB0aGFua3MgZm9yIHRoZSByZXZpZXcu IFNvbWUgY29tbWVudHMgaGVyZSBiZWxvdy4NCj4+PiANCj4+PiANCj4+Pj4gT24gSnVsIDIyLCAy MDE3LCBhdCAxMjoyMSBQTSwgQnJpYW4gV2VpcyA8YmV3QGNpc2NvLmNvbT4gd3JvdGU6DQo+Pj4+ IA0KPj4+PiBSZXZpZXdlcjogQnJpYW4gV2Vpcw0KPj4+PiBSZXZpZXcgcmVzdWx0OiBIYXMgTml0 cw0KPj4+PiANCj4+Pj4gSSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0 aGUgc2VjdXJpdHkgZGlyZWN0b3JhdGUncyBvbmdvaW5nDQo+Pj4+IGVmZm9ydCB0byByZXZpZXcg YWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUgSUVTRy4gVGhlc2UgY29t bWVudHMNCj4+Pj4gd2VyZSB3cml0dGVuIHByaW1hcmlseSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhl IHNlY3VyaXR5IGFyZWEgZGlyZWN0b3JzLiBEb2N1bWVudA0KPj4+PiBlZGl0b3JzIGFuZCBXRyBj aGFpcnMgc2hvdWxkIHRyZWF0IHRoZXNlIGNvbW1lbnRzIGp1c3QgbGlrZSBhbnkgb3RoZXIgbGFz dCBjYWxsDQo+Pj4+IGNvbW1lbnRzLg0KPj4+PiANCj4+Pj4gVGhpcyBkb2N1bWVudCBkZXNjcmli ZXMgYSBCR1AgZXh0ZW5zaW9uIHRvIHNpZ25hbCB0aGUgQkdQIFByZWZpeC1TSUQgdXNlIHdpdGgN Cj4+Pj4gU2VnbWVudCBSb3V0aW5nLiAgYXMgd2VsbCBhcyB0aGUgcnVsZXMgdG8gb3JpZ2luYXRl LCByZWNlaXZlIGFuZCBoYW5kbGUgZXJyb3INCj4+Pj4gY29uZGl0aW9ucy4gVGhlIEJHUCBleHRl bnNpb24gZGVmaW5lcyBhIG5ldyB0eXBlIG9mIEJHUCBwYXRoIGF0dHJpYnV0ZSBwYXNzZWQNCj4+ Pj4gd2l0aGluIEJHUCwgYW5kIGRvZXMgbm90IGNoYW5nZSB0aGUgc2VjdXJpdHkgY29uc2lkZXJh dGlvbnMgb2YgdGhlIEJHUCBwcm90b2NvbA0KPj4+PiBpdHNlbGYuDQo+Pj4+IA0KPj4+PiBJIGNv bnNpZGVyIHRoaXMgZG9jdW1lbnQg4oCccmVhZHkgd2l0aCBuaXRz4oCdLg0KPj4+PiANCj4+Pj4g VGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIHNlY3Rpb24gcmVhc29uYWJseSBzdGF0ZXMgdGhh dCB0aGUgdXNlIG9mIHRoaXMgQkdQDQo+Pj4+IGF0dHJpYnV0ZSDigJxpbmhlcml0cyB0aGUgc2Vj dXJpdHkgY29uc2lkZXJhdGlvbnPigJ0gb2YgdGhlIEJHUC00IFJGQyBhcyB3ZWxsIGFzDQo+Pj4+ IHRoZSBSRkMgZGVmaW5pbmcgaG93IGxhYmVscyBhcmUgY2FycmllZCBpbiBCR1AtNC4gQXMgYW4g YXNpZGUsIHRob3NlIGRvY3VtZW50cw0KPj4+PiBhcmUgcXVpdGUgb2xkLiBGb3IgZXhhbXBsZSwg UkZDIDQyNzEgc2F5cyB0aGF0IHRoZSBUQ1AtTUQ1IG9wdGlvbiBpcyByZXF1aXJlZA0KPj4+PiB0 byBpbXBsZW1lbnQgZm9yIGF1dGhlbnRpY2F0aW9uLCBidXQgdGhpcyBoYXMgYmVlbiByZXBsYWNl ZCBieSBhIG11Y2ggc3Ryb25nZXINCj4+Pj4gYXV0aGVudGljYXRpb24gbWV0aG9kIChUQ1AtQU8p LiBJdCB3b3VsZCBiZSBuaWNlIGlmIHdlIGhhZCBuZXdlciBzZWN1cml0eQ0KPj4+PiBjb25zaWRl cmF0aW9ucyBmb3IgQkdQLTQgYnV0IHRoYXQgYWR2aWNlIGRvZXNu4oCZdCBiZWxvbmcgaW4gdGhp cyBkb2N1bWVudC4NCj4+Pj4gDQo+Pj4+IFRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBtaWdo dCBoYXZlIHNhaWQgc29tZXRoaW5nIGFib3V0IHRoZSBob3cgYW4gQVMgd291bGQNCj4+Pj4gcHJv dGVjdCBpdHNlbGYgYWdhaW5zdCBhIHBlZXIgc2VuZGluZyB0aGUgUHJlZml4LVNJRCBhdHRyaWJ1 dGUgYWNyb3NzIEFTDQo+Pj4+IGJvdW5kYXJpZXMsIGJ1dCB0aGF0IHRleHQgaXMgY29udGFpbmVk IGluIHVzZWZ1bCBwbGFjZXMgZWxzZXdoZXJlIGluIHRoZQ0KPj4+PiBkb2N1bWVudCBhbmQgc2Vl bXMgc3VmZmljaWVudC4NCj4+Pj4gDQo+Pj4+IEkgaGF2ZSBvbmx5IG9uZSBuaXQsIHdoaWNoIGlz IHNvbWUgY29uZnVzaW9uIHJlZ2FyZGluZyBzY29waW5nIG9mIHRoZSBTSUQuIFRoZQ0KPj4+PiBk b2N1bWVudCBjbGVhcmx5IHN0YXRlcyB0aGF0IGEgU0lEIGhhcyBhIGxpbWl0ZWQgc2NvcGUgd2l0 aGluIHRoZSBuZXR3b3JrLCANCj4+Pj4gd2hpY2ggaXMgaW1wb3J0YW50IGJlY2F1c2Ugb3V0c2lk ZSBvZiB0aGF0IHNjb3BlIGFuIFNJRCB2YWx1ZSB3b3VsZCBoYXZlIGENCj4+Pj4gZGlmZmVyZW50 IG1lYW5pbmcuIFRoaXMgaXMgYSBzZWN1cml0eSAgY29uc2lkZXJhdGlvbiwgYmVjYXVzZSBhY2Nl cHRpbmcgYSBTSUQNCj4+Pj4gaW4gdGhlIHdyb25nIHNjb3BlIGNvdWxkIHBvc3NpYmx5IGNhdXNl IGEgc2VjdXJpdHkgaXNzdWUgaWYgcGFja2V0cyBhcmUNCj4+Pj4gZm9yd2FyZGVkIHRvIHRoZSB3 cm9uZyBpZGVudGl0eSAoZS5nLCB0aGUgcGFja2V0cyB3ZXJlIGludGVuZGVkIGZvciBhIGZpcmV3 YWxsDQo+Pj4+IHdpdGhpbiB0aGUgQVMsIG5vdCBhIHNlcnZpY2Ugb3V0c2lkZSBvZiB0aGUgQVMp Lg0KPj4+PiANCj4+Pj4gKGEpIFNlY3Rpb24gNS4xIHNheXMgaXQgc2hvdWxkIG5vdCBiZSBhZHZl cnRpc2VkIG91dHNpZGUgb2YgYW4gQVMgdW5sZXNzDQo+Pj4+IOKAnGV4cGxpY2l0bHkgY29uZmln dXJlZCB0byBkbyBzb+KAnS4gSXQgd291bGQgYmUgbmljZSBpZiB0aGUgY29uZGl0aW9ucyBmb3IN Cj4+Pj4gZXhwbGljaXRseSBjb25maWd1cmluZyB0aGUgU0lEIHRvIGJlIGFkdmVydGlzZWQgb3V0 c2lkZSBvZiB0aGUgQVMgd2VyZQ0KPj4+PiBtZW50aW9uZWQgaGVyZS4NCj4+PiANCj4+PiANCj4+ PiB1c3VhbGx5IHdlIGRvbuKAmXQgZGVmaW5lIHRoZXNlIGNvbmRpdGlvbiBiZWNhdXNlIHRoZXkg YXJlIHJlbGF0ZWQgdG8gZWFjaCBpbmRpdmlkdWFsIG9wZXJhdG9yIHBvbGljeS4gV2hhdCB3ZSB3 YW50IHRvIGJlIHN1cmUgb2YgaXMgdGhhdCBhbnkgY29tcGxpYW50IGltcGxlbWVudGF0aW9uLCBi eSBkZWZhdWx0LCB3aWxsIG5vdCBwcm9wYWdhdGUgdGhlIGF0dHJpYnV0ZSBvdXRzaWRlIHRoZSBB Uy4NCj4+PiANCj4+PiBVbmRlciB3aGljaCBjb25kaXRpb25zIHByb3BhZ2F0aW9uIGlzIGFsbG93 ZWQgaXMgYSBsb2NhbCBtYXR0ZXIgb2YgdGhlIG9wZXJhdG9yIGFuZCBob3cgaXQgaXMgZWZmZWN0 aXZlbHkgYWNoaWV2ZWQgaXMgYSBtYXR0ZXIgb2YgbG9jYWwgaW1wbGVtZW50YXRpb24uDQo+Pj4g DQo+Pj4gDQo+Pj4+IChiKSBUaGUgbGFzdCBwYXJhZ3JhcGggb2YgU2VjdGlvbiA4IHNheXMgaXQg aXMgYXBwbGljYWJsZSB3aXRoaW4gYW4gU1IgRG9tYWluDQo+Pj4+IChpLmUuLCBtb3JlIHRoYW4g YW4gQVMpLCBhbmQgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgc2F5cyBzb21ldGhpbmcgc2ltaWxh ci4NCj4+Pj4gDQo+Pj4+IChjKSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBzcGVha3Mgb2YgbGlt aXRpbmcgQkdQIFByZWZpeC1TSUQgd2l0aGluIGENCj4+Pj4g4oCcZG9tYWlu4oCdLiBJcyB0aGF0 IGludGVuZGluZyB0byBzYXkgYW4g4oCcU1IgZG9tYWlu4oCdPw0KPj4+IA0KPj4+IA0KPj4+IE1v cmUgZ2VuZXJhbGx5LCBieSBkb21haW4gd2UgaW50ZW5kIHRoZSBzZXQgb2YgQVMgdW5kZXIgY29u dHJvbCBvZiB0aGUgc2FtZSBvcmdhbml6YXRpb24vb3BlcmF0b3IuDQo+Pj4gDQo+Pj4+IEkgc3Vz cGVjdCB3aGV0aGVyIGFuIFNJRCBzaG91bGQgYmUgYWR2ZXJ0aXNlZCBvdXRzaWRlIG9mIHRoZSBB UyBkZXBlbmRzIG9uDQo+Pj4+IHdoZXRoZXIgYW4gQVMgaXMgcGFydCBvZiBhbiDigJxTUiBkb21h aW7igJ0gb3Igbm90LCBhbmQgdGhhdCB0aGVyZSdzIGxpa2VseSBuZXZlciBhDQo+Pj4+IGdvb2Qg Y2FzZSB0byBhZHZlcnRpc2UgaXQgb3V0c2lkZSBvZiBhbiBBUyB1bmxlc3MgaXQgaXMgcGFydCBv ZiBhbiAiU1IgZG9tYWluIi4NCj4+Pj4gQnV0IGl0IHdvdWxkIGJlIGdvb2QgaWYgdGhlcmUgd2Fz IHNvbWUgdGV4dCBjbGFyaWZ5aW5nICB0aGUgY29uZGl0aW9ucyB3aGVuIGl0DQo+Pj4+IGlzIHJl YXNvbmFibGUgdG8gc2hhcmUgYW4gU0lEIGJldHdlZW4gQVNlcy4NCj4+PiANCj4+PiANCj4+PiBX ZWxsLCBJ4oCZbSBub3Qgc3VyZSB0aGF0IHdvdWxkIGJlIGEgZ29vZCBpZGVhIGJlY2F1c2UgdGhl IGNvbmRpdGlvbnMgbWF5IHZhcnkgb3ZlciB0aW1lIGFuZCB3ZSB3aWxsIG5ldmVyIGJlIGV4aGF1 c3RpdmUgYW55d2F5Lg0KPj4+IFRoYW5rcy4NCj4+PiBzLg0KPj4+IA0KPj4+IA0KPj4+PiANCj4+ PiANCj4+IA0KPj4gLS0gDQo+PiBCcmlhbiBXZWlzDQo+PiBTZWN1cml0eSwgQ1NHLCBDaXNjbyBT eXN0ZW1zDQo+PiBUZWxlcGhvbmU6ICsxIDQwOCA1MjYgNDc5Ng0KPj4gRW1haWw6IGJld0BjaXNj by5jb20NCj4+IA0KPiANCg0KLS0gDQpCcmlhbiBXZWlzDQpTZWN1cml0eSwgQ1NHLCBDaXNjbyBT eXN0ZW1zDQpUZWxlcGhvbmU6ICsxIDQwOCA1MjYgNDc5Ng0KRW1haWw6IGJld0BjaXNjby5jb20N Cg0K From nobody Fri Oct 6 21:31:04 2017 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 A87BF126CB6; Fri, 6 Oct 2017 21:31:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=denisbider.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 A0nWQkdMUo6c; Fri, 6 Oct 2017 21:31:00 -0700 (PDT) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67C58126BF3; Fri, 6 Oct 2017 21:31:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=denisbider.com; s=mail; h=from:subject:date:message-id:to:mime-version:content-type:in-reply-to: references; bh=SsKjoBoApTF5jvdZsNYJSIFGLGZnDRucGlUaHRlEyJg=; b=j+lAI3toM/kpj8OEwRTTX7lTJ0CqlBB13rxXJk5JQ72X1bN087zFrAkYSCZVjdMwqmBRmRtU9vUsc yI1m1EFtUtsPtSMOzpItf6I6ztqGRqXyP63C6nryEEHCkijISr94yM41GJo37ID6NUTMl1wpVA0zno SKaau738soG2qvvjmp9j15JSxo7CM3Ff8RZspEuxtdrxMQEk/ivC8CkT1FAlF3mVvDh0j+yjPHIx8/ t78d8Gtj4vFy74wPpYDMHrRCHEB/XKRGwcLQDFmqyBmTYF5xnK2RQKSZNy3HCLslX3TkTjoD5X4/i4 7V0Ybmu2dFwiI9JCb748G/sWqBlpPxw== X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com with ESMTPSA (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)); Sat, 7 Oct 2017 05:30:41 +0100 Message-ID: <0E8A85F9FEC545F481ADC9A15D814749@Khan> From: "denis bider \(Bitvise\)" To: "Vincent Roca" , "IESG" , , References: <79DA00BE-AA86-44AC-89B0-FA03CABDF519@inria.fr> In-Reply-To: <79DA00BE-AA86-44AC-89B0-FA03CABDF519@inria.fr> Date: Fri, 6 Oct 2017 23:30:45 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_024D_01D33EFB.21F4C880" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Subject: Re: [secdir] Secdir review of draft-ietf-curdle-rsa-sha2-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Oct 2017 04:31:02 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_024D_01D33EFB.21F4C880 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Vincent, thank you for the finding. I have updated the document. :-) denis From: Vincent Roca=20 Sent: Wednesday, October 4, 2017 02:48 To: IESG ; secdir@ietf.org ; draft-ietf-curdle-rsa-sha2.all@ietf.org=20 Cc: Vincent Roca=20 Subject: Secdir review of draft-ietf-curdle-rsa-sha2-10 Hello, I have reviewed this document as part of the security = directorate=E2=80=99s 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. Summary: Ready with nits=20 The document is well written and security considerations appropriate. However I have a comment. The document includes reference [800-131A]: NIST Special Publication 800-131A, January 2011. Looking at the NIST web site, this reference is now superseded by: NIST Special Publication 800-131A Rev. 1, November 2015 As I understand, the new version should be referenced instead of the = original one. Since this revision includes new, updated recommendations on when a = given algorithm is considered deprecated, this may impact a little bit the = document. Cheers, Vincent ------=_NextPart_000_024D_01D33EFB.21F4C880 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Vincent,
 
thank you for the finding. I have updated the document. :-)
 
denis
 
 
Sent: Wednesday, October 4, 2017 02:48
To: IESG ; secdir@ietf.org ; draft-ietf-curdle= -rsa-sha2.all@ietf.org=20
Subject: Secdir review of=20 draft-ietf-curdle-rsa-sha2-10
 
Hello,

I=20 have reviewed this document as part of the security = directorate=E2=80=99s=20 ongoing
effort to review all IETF documents being processed by the = IESG.=20 These
comments were written primarily for the benefit of the security = area
directors.  Document editors and WG chairs should treat = these=20 comments just
like any other last call comments.

Summary: = Ready with=20 nits=20
 
The document is well written and security considerations = appropriate.
However I have a comment.
 
The document includes reference [800-131A]:
NIST = Special=20 Publication 800-131A, January 2011.
Looking at the NIST web site, this reference is now superseded = by:
NIST = Special=20 Publication 800-131A Rev. 1, November 2015
As I understand, the new version should be referenced instead of = the=20 original one.
 
Since this revision includes new, updated recommendations on when a = given
algorithm is considered deprecated, this may impact a little bit = the=20 document.
 
Cheers,
 
   = Vincent
------=_NextPart_000_024D_01D33EFB.21F4C880-- From nobody Sat Oct 7 08:48:54 2017 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 4B3A613495E; Sat, 7 Oct 2017 08:48:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=infineon.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 ss6Prf1pJedV; Sat, 7 Oct 2017 08:48:46 -0700 (PDT) Received: from smtp11.infineon.com (smtp11.infineon.com [IPv6:2a00:18f0:1e00:4::5]) (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 5E00113495C; Sat, 7 Oct 2017 08:48:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=infineon.com; i=@infineon.com; q=dns/txt; s=IFXMAIL; t=1507391326; x=1538927326; h=from:to:subject:date:message-id:mime-version; bh=Brhbj9/nX+YmWO00BGW2zrdrsOBiZQtMOD+Br5ZsIS8=; b=JgJRJOx4KSunkHf/Lv/nzDi2/tyBeDcTODiutdik9yfRVq4nri1E9Qp4 HXn62qb6U+IZYezwSUISrIQYJ2m7zvsTVidIy+UNUdTs3OlwCHtAmxg5j inVAdB/+vr0m2+K6P0lU08BYjWu3FdU/z6ZXuwYDmbEuCoUsHP0BiZzWm s=; X-SBRS: None Received: from unknown (HELO mucxv003.muc.infineon.com) ([172.23.11.20]) by smtp11.infineon.com with ESMTP/TLS/AES256-GCM-SHA384; 07 Oct 2017 17:48:43 +0200 Received: from MUCSE706.infineon.com (mucse706.infineon.com [172.23.7.80]) by mucxv003.muc.infineon.com (Postfix) with ESMTPS; Sat, 7 Oct 2017 17:48:43 +0200 (CEST) Received: from MUCSE703.infineon.com (172.23.7.73) by MUCSE706.infineon.com (172.23.7.80) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.669.32; Sat, 7 Oct 2017 17:48:43 +0200 Received: from MUCSE707.infineon.com (172.23.7.81) by MUCSE703.infineon.com (172.23.7.73) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.669.32; Sat, 7 Oct 2017 17:48:43 +0200 Received: from MUCSE707.infineon.com ([172.23.106.27]) by MUCSE707.infineon.com ([172.23.106.27]) with mapi id 15.01.0669.032; Sat, 7 Oct 2017 17:48:42 +0200 From: To: , , Thread-Topic: Secdir last call review of draft-ietf-sunset4-ipv6-ietf-01 Thread-Index: AdM/ghbQ8KSz/K3jTp+5m7DVA0m3Xg== Date: Sat, 7 Oct 2017 15:48:42 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.23.8.247] Content-Type: multipart/alternative; boundary="_000_bd0f24bfca544357af0d76eec70ed462infineoncom_" MIME-Version: 1.0 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-sunset4-ipv6-ietf-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Oct 2017 15:48:47 -0000 --_000_bd0f24bfca544357af0d76eec70ed462infineoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Reviewer: Steve Hanna Review result: Ready This document states that the IETF will stop working on IPv4, with certain = exceptions. While this document is controversial and concerns have been exp= ressed regarding the wisdom of adopting it, I don't see any security concer= ns related to adopting it. In fact, the document clearly states that "the I= ETF needs to continue to update IPv4-only protocols and features for vital = operational or security issues." Therefore, I don't foresee any security is= sues related to adopting the document. --_000_bd0f24bfca544357af0d76eec70ed462infineoncom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Reviewer: Steve Hanna

Review result: Ready

 

This document states tha= t the IETF will stop working on IPv4, with certain exceptions. While this d= ocument is controversial and concerns have been expressed regarding the wis= dom of adopting it, I don’t see any security concerns related to adopting it. In fact, the document clearly st= ates that “the IETF needs to continue to update IPv4-only protocols a= nd features for vital operational or security issues.” Therefore, I d= on’t foresee any security issues related to adopting the document.

 =

--_000_bd0f24bfca544357af0d76eec70ed462infineoncom_-- From nobody Sat Oct 7 19:22:29 2017 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 24981133085; Sat, 7 Oct 2017 19:22:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, 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 tq5hjdexzSLz; Sat, 7 Oct 2017 19:22:19 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5EF6132944; Sat, 7 Oct 2017 19:22:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 51A8F7C3243; Sun, 8 Oct 2017 04:22:14 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UeBkjCEruGCx; Sun, 8 Oct 2017 04:22:12 +0200 (CEST) Received: from [192.168.8.111] (149-222-232.connect.netcom.no [178.232.222.149]) by mork.alvestrand.no (Postfix) with ESMTPSA id 502407C0D41; Sun, 8 Oct 2017 04:22:12 +0200 (CEST) To: Phillip Hallam-Baker , secdir@ietf.org Cc: draft-ietf-rtcweb-jsep.all@ietf.org, rtcweb@ietf.org, ietf@ietf.org References: <150729330872.6204.16821957868857533343@ietfa.amsl.com> From: Harald Alvestrand Message-ID: <3a37950b-676c-05bd-f400-0bd84beacd1b@alvestrand.no> Date: Sun, 8 Oct 2017 04:22:11 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <150729330872.6204.16821957868857533343@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-rtcweb-jsep-23 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Oct 2017 02:22:21 -0000 On 10/06/2017 02:35 PM, Phillip Hallam-Baker wrote: > Reviewer: Phillip Hallam-Baker > Review result: Ready > > Given the design constraints in which the protocol operates, it is hard= to see > how this could be done differently. > > I have two sets of security concerns. One is that implementations need = to be > designed so as to avoid buffer overrun conditions and also to prevent s= uch > conditions leading to a breach. Compression formats such as are inevita= bly used > in video and image applications tend to make promiscuous use of nested = length > encoding formats that commonly lead to security vulnerabilities. > > This document does not have such a warning, having a reference on most = of the > security issues, a warning on this issue should appear in: > https://tools.ietf.org/html/draft-ietf-rtcweb-security-08 > > The other security concern is that giving control over the host browser= to run > pretty much arbitrary code was always going to be a security disaster b= ut there > isn't much that can be done at this point. > Participant pushback, I'm neither a WG chair or a document editor: Was this intended as a review of a different document? The concern about compression formats seems to be something that belongs in compression format specifications, such as those referenced by PAYLOAD et al. As such, it would reasonably belong in -rtcweb-security, which pulls in security concerns from a number of fields. The generic concern about running Javascript in the browser seems to belong to rtcweb-overview if it belongs anywhere except in a generic architecture critique of the browser ecosystem. If there are concerns specific to JSEP, and the handling of SDP that is described in JSEP, it seems appropriate to document them here. Generic architectural issues and common security best practices don't seem to have the right home in this document. --=20 Surveillance is pervasive. Go Dark. From nobody Sat Oct 7 20:19:02 2017 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 046B4133078; Sat, 7 Oct 2017 20:18:55 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 x41vmVNkXSAS; Sat, 7 Oct 2017 20:18:52 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CB321342E1; Sat, 7 Oct 2017 20:18:52 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id q4so17369091oic.7; Sat, 07 Oct 2017 20:18:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lx+A0lkljzweP+G5+OilpW8DEDlFKejkf5LHEdXup6c=; b=EESgRA3Zr5kLAXWqC+yQwsPfOv6zirWKbDzo3QrnqaOoou3vcRU1tMkwZNPnBa72p4 RA+gL5Sd1/tCzq+k0P79qgeGgrGSJXGJrneqMY3qlKsZQ1fAYENEpO9FbqPj1g+AQhYT 4oLsg8Di6MeXpWl9+y0je98SnpsTusdzlloyIUsuY5oN1wqNHJWEYVNM6AKOERIDXduc 9tv5htEL9jsFm80qpRkOIe9dkCT2k63R4es+e1T+Cu2ACawQ5/wj/4qxh//+tu7PwyIx QkePZc6yJRjIXYH3sjWWtEsKXG57iKbhIejJmh41GiNzRlQoBJPOeXQ6NWfm5yEnF8s/ gozw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lx+A0lkljzweP+G5+OilpW8DEDlFKejkf5LHEdXup6c=; b=shSaJcsLHad0MIot9AZf+q9XEGB7LrTmf/z0dZkAZSin8fGXc7JMI21Ecif3EEwpMx HBx7ZGbyrlh0pNO+CbNJvmOu2HxmGGV0gkrEHFVKWWPROL5/zyDLa2eL3vZVF6FphVRX NxGlfXQsg5vkc7AvqZi0WtSIlYu+FyJFY/97BeAf0iqWO6qZR68pIpB+kP1VcjJRlJ+S sCblncZMbR05WiJKsM9hEjcAqfQtJySq7BIexK7Y0ll6qfDXk61L09X+h7FV1CquxYWe dMt8meZwbR42tA9gLTGUw8W5hJMMmxvVv3wCjZSuZfIKxQehBYtaDLP60y5T0Od9BmRn 6dFw== X-Gm-Message-State: AMCzsaVuLSMPg4ASTBgeOJER+Ha3D3uBcKQY7m87PL3C3639+cnmZsiN 6DFTkJKqli2/sKF+cnxu+fDBa4TfIxOXGCjXMlk= X-Google-Smtp-Source: AOwi7QAbnhNYHDAyax1uc6/u5Ob0c7PGLUZFc9UY5uEpfoK2MVDTQyq5DshoEjrm2fpXV50JYJYuXJgFs8d+GHRqEgI= X-Received: by 10.157.17.6 with SMTP id g6mr4021245ote.305.1507432731823; Sat, 07 Oct 2017 20:18:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.80.42 with HTTP; Sat, 7 Oct 2017 20:18:51 -0700 (PDT) In-Reply-To: <3a37950b-676c-05bd-f400-0bd84beacd1b@alvestrand.no> References: <150729330872.6204.16821957868857533343@ietfa.amsl.com> <3a37950b-676c-05bd-f400-0bd84beacd1b@alvestrand.no> From: Phillip Hallam-Baker Date: Sat, 7 Oct 2017 23:18:51 -0400 Message-ID: To: Harald Alvestrand Cc: "secdir@ietf.org" , draft-ietf-rtcweb-jsep.all@ietf.org, "rtcweb@ietf.org" , IETF Discussion Mailing List Content-Type: multipart/alternative; boundary="001a1146208680d4c9055b00882a" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-rtcweb-jsep-23 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Oct 2017 03:18:55 -0000 --001a1146208680d4c9055b00882a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Oct 7, 2017 at 10:22 PM, Harald Alvestrand wrote: > On 10/06/2017 02:35 PM, Phillip Hallam-Baker wrote: > > Reviewer: Phillip Hallam-Baker > > Review result: Ready > > > > Given the design constraints in which the protocol operates, it is hard > to see > > how this could be done differently. > > > > I have two sets of security concerns. One is that implementations need > to be > > designed so as to avoid buffer overrun conditions and also to prevent > such > > conditions leading to a breach. Compression formats such as are > inevitably used > > in video and image applications tend to make promiscuous use of nested > length > > encoding formats that commonly lead to security vulnerabilities. > > > > This document does not have such a warning, having a reference on most > of the > > security issues, a warning on this issue should appear in: > > https://tools.ietf.org/html/draft-ietf-rtcweb-security-08 > > > > The other security concern is that giving control over the host browser > to run > > pretty much arbitrary code was always going to be a security disaster > but there > > isn't much that can be done at this point. > > > Participant pushback, I'm neither a WG chair or a document editor: > > > Was this intended as a review of a different document? > =E2=80=8BNo, I just didn't have any comments on the security considerations= in this one as they are handled in rtcweb-security. and that is the place to address the one addressable concern I did have. The concern about compression formats seems to be something that belongs > in compression format specifications, such as those referenced by > PAYLOAD et al. As such, it would reasonably belong in -rtcweb-security, > which pulls in security concerns from a number of fields. > =E2=80=8BThat is where I suggested it go. =E2=80=8B > The generic concern about running Javascript in the browser seems to > belong to rtcweb-overview if it belongs anywhere except in a generic > architecture critique of the browser ecosystem. > =E2=80=8BI wasn't suggesting a change. Just pointing out that we are dealin= g with the =E2=80=8Battack model in which the attacker has control of a turing com= plete mechanism in the communication channel. Given that one of the authors is a Security AD, just pointing out that is the set of vectors that would cause me most concern. > If there are concerns specific to JSEP, and the handling of SDP that is > described in JSEP, it seems appropriate to document them here. Generic > architectural issues and common security best practices don't seem to > have the right home in this document. > > -- > Surveillance is pervasive. Go Dark. > > > --=20 Website: http://hallambaker.com/ --001a1146208680d4c9055b00882a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Sat, Oc= t 7, 2017 at 10:22 PM, Harald Alvestrand <harald@alvestrand.no><= /span> wrote:
On 10/06/2017 02:35 PM, Phillip Hallam-Baker wrote:
> Reviewer: Phillip Hallam-Baker
> Review result: Ready
>
> Given the design constraints in which the protocol operates, it is har= d to see
> how this could be done differently.
>
> I have two sets of security concerns. One is that implementations need= to be
> designed so as to avoid buffer overrun conditions and also to prevent = such
> conditions leading to a breach. Compression formats such as are inevit= ably used
> in video and image applications tend to make promiscuous use of nested= length
> encoding formats that commonly lead to security vulnerabilities.
>
> This document does not have such a warning, having a reference on most= of the
> security issues, a warning on this issue should appear in:
> https://tools.ietf.org/html/draft= -ietf-rtcweb-security-08
>
> The other security concern is that giving control over the host browse= r to run
> pretty much arbitrary code was always going to be a security disaster = but there
> isn't much that can be done at this point.
>
Participant pushback, I'm neither a WG chair or a document = editor:


Was this intended as a review of a different document?

=E2= =80=8BNo, I just didn't have any comments on the security consideration= s in this one as they are handled in rtcweb-security. and that is the place= to address the one addressable concern I did have.



The concern about compression formats seems to be something that belongs in compression format specifications, such as those referenced by
PAYLOAD et al. As such, it would reasonably belong in -rtcweb-security,
which pulls in security concerns from a number of fields.
<= div>
=E2=80= =8BThat is where I suggested it go.
=E2=80=8B
The generic concern about running Javascript in the browser seems to
belong to rtcweb-overview if it belongs anywhere except in a generic
architecture critique of the browser ecosystem.

=E2=80=8BI = wasn't suggesting a change. Just pointing out that we are dealing with = the =E2=80=8Battack model in which the attacker has control of a turing com= plete mechanism in the communication channel. Given that one of the authors= is a Security AD, just pointing out that is the set of vectors that would = cause me most concern.

=C2=A0
If there are concerns specific to JSEP, and the handling of SDP that is
described in JSEP, it seems appropriate to document them here. Generic
architectural issues and common security best practices don't seem to have the right home in this document.

--
Surveillance is pervasive. Go Dark.





--
Website= : http://hallambaker.= com/
--001a1146208680d4c9055b00882a-- From nobody Sun Oct 8 00:50:05 2017 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 117EF134D51; Sun, 8 Oct 2017 00:49:48 -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, HTML_MESSAGE=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 IlRav9wpTFCC; Sun, 8 Oct 2017 00:49:45 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9032134C42; Sun, 8 Oct 2017 00:49:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 104187C09FC; Sun, 8 Oct 2017 09:49:43 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OQ1vgOWDi6_p; Sun, 8 Oct 2017 09:49:41 +0200 (CEST) Received: from [192.168.8.103] (149-222-232.connect.netcom.no [178.232.222.149]) by mork.alvestrand.no (Postfix) with ESMTPSA id 7C38D7C03BD; Sun, 8 Oct 2017 09:49:40 +0200 (CEST) Date: Sun, 08 Oct 2017 09:49:30 +0200 User-Agent: K-9 Mail for Android In-Reply-To: References: <150729330872.6204.16821957868857533343@ietfa.amsl.com> <3a37950b-676c-05bd-f400-0bd84beacd1b@alvestrand.no> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----VFWW9V971VU85Q8MQZY4R6WTQGWAJY" Content-Transfer-Encoding: 7bit To: ietf@ietf.org,Phillip Hallam-Baker CC: draft-ietf-rtcweb-jsep.all@ietf.org, "rtcweb@ietf.org" , IETF Discussion Mailing List , "secdir@ietf.org" From: Harald Alvestrand Message-ID: Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-rtcweb-jsep-23 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Oct 2017 07:49:48 -0000 ------VFWW9V971VU85Q8MQZY4R6WTQGWAJY Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ok, sounds like we're in agreement on what needs to be done to this documen= t based on the review (nothing)=2E Good=2E Den 8=2E oktober 2017 05:18:51 CEST, skrev Phillip Hallam-Baker : >On Sat, Oct 7, 2017 at 10:22 PM, Harald Alvestrand > >wrote: > >> On 10/06/2017 02:35 PM, Phillip Hallam-Baker wrote: >> > Reviewer: Phillip Hallam-Baker >> > Review result: Ready >> > >> > Given the design constraints in which the protocol operates, it is >hard >> to see >> > how this could be done differently=2E >> > >> > I have two sets of security concerns=2E One is that implementations >need >> to be >> > designed so as to avoid buffer overrun conditions and also to >prevent >> such >> > conditions leading to a breach=2E Compression formats such as are >> inevitably used >> > in video and image applications tend to make promiscuous use of >nested >> length >> > encoding formats that commonly lead to security vulnerabilities=2E >> > >> > This document does not have such a warning, having a reference on >most >> of the >> > security issues, a warning on this issue should appear in: >> > https://tools=2Eietf=2Eorg/html/draft-ietf-rtcweb-security-08 >> > >> > The other security concern is that giving control over the host >browser >> to run >> > pretty much arbitrary code was always going to be a security >disaster >> but there >> > isn't much that can be done at this point=2E >> > >> Participant pushback, I'm neither a WG chair or a document editor: >> >> >> Was this intended as a review of a different document? >> > >=E2=80=8BNo, I just didn't have any comments on the security consideratio= ns in >this >one as they are handled in rtcweb-security=2E and that is the place to >address the one addressable concern I did have=2E > > > >The concern about compression formats seems to be something that >belongs >> in compression format specifications, such as those referenced by >> PAYLOAD et al=2E As such, it would reasonably belong in >-rtcweb-security, >> which pulls in security concerns from a number of fields=2E >> > >=E2=80=8BThat is where I suggested it go=2E >=E2=80=8B > >> The generic concern about running Javascript in the browser seems to >> belong to rtcweb-overview if it belongs anywhere except in a generic >> architecture critique of the browser ecosystem=2E >> > >=E2=80=8BI wasn't suggesting a change=2E Just pointing out that we are de= aling >with >the =E2=80=8Battack model in which the attacker has control of a turing >complete >mechanism in the communication channel=2E Given that one of the authors >is a >Security AD, just pointing out that is the set of vectors that would >cause >me most concern=2E > > > >> If there are concerns specific to JSEP, and the handling of SDP that >is >> described in JSEP, it seems appropriate to document them here=2E >Generic >> architectural issues and common security best practices don't seem to >> have the right home in this document=2E >> >> -- >> Surveillance is pervasive=2E Go Dark=2E >> >> >> > > >--=20 >Website: http://hallambaker=2Ecom/ --=20 Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E ------VFWW9V971VU85Q8MQZY4R6WTQGWAJY Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ok, sounds like we're in agreement on what nee= ds to be done to this document based on the review (nothing)=2E Good=2E
=
Den 8=2E oktober 2017 05:18:51 CEST, skrev P= hillip Hallam-Baker <hallam@gmail=2Ecom>:

On Sa= t, Oct 7, 2017 at 10:22 PM, Harald Alvestrand <harald@alvestrand=2Eno= > wrote:
On 10/06/2017 02:35 PM, Phillip Hallam-Baker wrot= e:
> Reviewer: Phillip Hallam-Baker
> Review result: Ready
>
> Given the design constraints in which the protocol operates, it is ha= rd to see
> how this could be done differently=2E
>
> I have two sets of security concerns=2E One is that implementations n= eed to be
> designed so as to avoid buffer overrun conditions and also to prevent= such
> conditions leading to a breach=2E Compression formats such as are ine= vitably used
> in video and image applications tend to make promiscuous use of neste= d length
> encoding formats that commonly lead to security vulnerabilities=2E >
> This document does not have such a warning, having a reference on mos= t of the
> security issues, a warning on this issue should appear in:
> https://tools=2Eietf=2Eorg/html/<= wbr />draft-ietf-rtcweb-security-08
>
> The other security concern is that giving control over the host brows= er to run
> pretty much arbitrary code was always going to be a security disaster= but there
> isn't much that can be done at this point=2E
>
Participant pushback, I'm neither a WG chair or a document edi= tor:


Was this intended as a review of a different document?
<= div>
=E2=80=8BNo, I just didn't have any comments on the security consideration= s in this one as they are handled in rtcweb-security=2E and that is the pla= ce to address the one addressable concern I did have=2E



The concern about compression formats seems to be something that belongs in compression format specifications, such as those referenced by
PAYLOAD et al=2E As such, it would reasonably belong in -rtcweb-security,<= br /> which pulls in security concerns from a number of fields=2E

=E2=80=8BThat is where I suggested it go=2E
=E2=80=8B
The generic concern about running Javascript in the browser seems to
belong to rtcweb-overview if it belongs anywhere except in a generic
architecture critique of the browser ecosystem=2E
<= br />
=E2= =80=8BI wasn't suggesting a change=2E Just pointing out that we are dealing= with the =E2=80=8Battack model in which the attacker has control of a turi= ng complete mechanism in the communication channel=2E Given that one of the= authors is a Security AD, just pointing out that is the set of vectors tha= t would cause me most concern=2E

 
If there are concerns specific to JSEP, and the handling of SDP that is described in JSEP, it seems appropriate to document them here=2E Generic architectural issues and common security best practices don't seem to
have the right home in this document=2E

--
Surveillance is pervasive=2E Go Dark=2E





--
Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E ------VFWW9V971VU85Q8MQZY4R6WTQGWAJY-- From nobody Mon Oct 9 08:55:22 2017 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 45CC0134E73; Mon, 9 Oct 2017 08:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.398 X-Spam-Level: X-Spam-Status: No, score=-5.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 IPOX_ame9fxW; Mon, 9 Oct 2017 08:55:18 -0700 (PDT) Received: from relais-inet.orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F27F8134EF6; Mon, 9 Oct 2017 08:53:40 -0700 (PDT) Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id A825240375; Mon, 9 Oct 2017 17:53:39 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.57]) by opfednr00.francetelecom.fr (ESMTP service) with ESMTP id 73B691A0082; Mon, 9 Oct 2017 17:53:39 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM23.corporate.adroot.infra.ftgroup ([fe80::787e:db0c:23c4:71b3%19]) with mapi id 14.03.0361.001; Mon, 9 Oct 2017 17:53:39 +0200 From: To: David Mandelberg CC: "draft-ietf-ospf-encapsulation-cap.all@ietf.org" , "secdir@ietf.org" , "Acee Lindem (acee)" , Alia Atlas Thread-Topic: secdir review of draft-ietf-ospf-encapsulation-cap-06 Thread-Index: AQHTHpv/cOgvm+rnt0qxeBuvpFWeWaK0xaZggAAJ/YCAANdoUIAFhL03gADEpyD//+kaAIAAJRXggAAP/YCAAFoggIAfgRjA Date: Mon, 9 Oct 2017 15:53:38 +0000 Message-ID: <14732_1507564419_59DB9B83_14732_456_1_53C29892C857584299CBF5D05346208A478A7539@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <475c78dc-c872-8795-2d99-81b28df97aed@mandelberg.org> <3691_1505412243_59BAC493_3691_229_1_53C29892C857584299CBF5D05346208A47872C5B@OPEXCLILM21.corporate.adroot.infra.ftgroup> <2597_1505460712_59BB81E8_2597_399_1_53C29892C857584299CBF5D05346208A4787384B@OPEXCLILM21.corporate.adroot.infra.ftgroup> <656e7eb8-1bbe-5f9c-e3b6-f0bbc23737db@mandelberg.org> <12465_1505725711_59BF8D0F_12465_296_1_53C29892C857584299CBF5D05346208A478787B1@OPEXCLILM21.corporate.adroot.infra.ftgroup> <5ee2e3cf-4034-f9e6-4fca-92ceb57a65c5@mandelberg.org> <11040_1505805523_59C0C4D3_11040_226_4_53C29892C857584299CBF5D05346208A4787AC94@OPEXCLILM21.corporate.adroot.infra.ftgroup> <27250_1505808909_59C0D20D_27250_468_2_53C29892C857584299CBF5D05346208A4787AEEC@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A478A7539OPEXCLILM21corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-ospf-encapsulation-cap-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Oct 2017 15:55:21 -0000 --_000_53C29892C857584299CBF5D05346208A478A7539OPEXCLILM21corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 W3JlbW92aW5nIHRoZSBpZXNnIHRvIGxpbWl0IHNwYW1taW5nLCBhZGRpbmcgQWxpYSAocmVzcG9u c2libGUgQUQpXQ0KDQoNCg0KSGkgRGF2aWQsDQoNCg0KDQpTb3JyeSB0byBjb21lIGJhY2sgb24g dGhpcyBkcmFmdCAzIHdlZWtzIGFmdGVyIG91ciBsYXRlc3QgZW1haWwsIGJ1dCBhIGxhdGUgY29t bWVudCBpcyBsaWtlbHkgdG8gY2hhbmdlIGEgc2VudGVuY2UgaW4gdGhlIGRyYWZ0Lg0KDQpBcyB3 ZSBoYWQgZGlzY3Vzc2VkIHRoYXQgc2VudGVuY2UgZHVyaW5nIHlvdXIgc2VjZGlyIHJldmlldywg SSBmZWVsIHRoYXQgaXQgd291bGQgYmUgaG9uZXN0IHRvIGNvbWUgYmFjayB0byB5b3UgdG8gcmVw b3J0IHRoYXQgY2hhbmdlLCBldmVuIGlmIEkgZG9u4oCZdCBmZWVsIHRoZSBjaGFuZ2UgaXMgcHJv YmxlbWF0aWMuDQoNCg0KDQpQcm9wb3NlZCAyIGNoYW5nZXMgYXJlIHRoZSBmb2xsb3dpbmc6DQoN CsKnIE9wZXJhdGlvbg0KDQpPTEQ6DQoNCkEgdHVubmVsIE1VU1QgTk9UIGJlIHVzZWQgaWYgdGhl cmUgaXMgbm8gcm91dGUgdG93YXJkIHRoZSBJUCBhZGRyZXNzIHNwZWNpZmllZCBpbiB0aGUgRW5k cG9pbnQgU3ViLVRMViAoU2VlIDx4cmVmIHRhcmdldD0iRW5kcG9pbnRUTFYiLz4pDQoNCm9yIGlm IHRoZSByb3V0ZSBpcyBub3QgYWR2ZXJ0aXNlZCBieSB0aGUgcm91dGVyIGFkdmVydGlzaW5nIHRo aXMgVHVubmVsIFN1Yi1UTFYuDQoNCg0KDQpORVc6DQoNCkEgdHVubmVsIE1VU1QgTk9UIGJlIHVz ZWQgaWYgdGhlcmUgaXMgbm8gcm91dGUgdG93YXJkIHRoZSBJUCBhZGRyZXNzIHNwZWNpZmllZCBp biB0aGUgRW5kcG9pbnQgU3ViLVRMViAoU2VlIDx4cmVmIHRhcmdldD0iRW5kcG9pbnRUTFYiLz4p DQoNCm9yIGlmIHRoZSByb3V0ZSBpcyBub3QgYWR2ZXJ0aXNlZCBpbiB0aGUgc2FtZSBPU1BGIGRv bWFpbi4NCg0KDQoNCg0KDQo9PQ0KDQpUaGUgcmVhc29uIGlzIHRoYXQgaW4gbXVsdGktYXJlYSBP U1BGIGRlcGxveW1lbnRzLCB0aGUgVHVubmVsIFN1Yi1UTFYgbWF5IGJlIGZsb29kZWQgZG9tYWlu LXdpZGUgd2hpbGUgdGhlIElQIHByZWZpeCBtYXkgbm90LiBIZW5jZSBib3RoIGFkdmVydGlzZW1l bnRzIHdvdWxkIG5vdCBjb21lIGZyb20gdGhlIHNhbWUgcm91dGVyLg0KDQo9PQ0KDQoNCg0KDQoN CsKnc2VjdXJpdHkNCg0KT0xEOiAgSXQgcHJvaGliaXRzIGEgZGVzdGluYXRpb24gb3V0c2lkZSBv ZiB0aGUgT1NQRiBkb21haW4gYW5kIGFsc28gdG8gb3RoZXIgcm91dGVycyB3aXRoaW4gdGhlIGRv bWFpbi4NCg0KTkVXOiBJdCBwcm9oaWJpdHMgYSBkZXN0aW5hdGlvbiBvdXRzaWRlIG9mIHRoZSBP U1BGIGRvbWFpbi4NCg0KDQoNCg0KDQo9PT0NCg0KQXMgYSBjb25zZXF1ZW5jZSwgdGhpcyBzbGln aHRseSBpbmNyZWFzZXMgdGhlIGNhcGFiaWxpdGllcyBhbmQgaGVuY2UgdGhlIHNlY3VyaXR5IGlt cGxpY2F0aW9ucy4gSG93ZXZlciwgdGhpcyBzdGlsbCByZXN0cmljdHMgdGhlIHVzZSBvZiB0dW5u ZWwgd2hvc2UgZGVzdGluYXRpb24gaXMgd2l0aGluIHRoZSBPU1BGIGRvbWFpbiAoaS5lLiBub3Qg SW50ZXJuZXQgd2lkZSkgd2hpY2ggd2FzIHlvdXIgb3JpZ2luYWwgY29uY2Vybi4gUGx1cyBJTU8s IGFzc3VtaW5nIHRoYXQgYW4gYXR0YWNrZXIgY2FuIGNvbnRyb2wgdGhlIE9TUEYgYWR2ZXJ0aXNl bWVudCBpcyBhbHJlYWR5IGEgc2lnbmlmaWNhbnQgYXNzdW1wdGlvbi4NCg0KPT09DQoNCg0KDQpC b3R0b20gbGluZSwgSSBiZWxpZXZlIHRoZSBjaGFuZ2UgaXMgcXVpdGUgc21hbGwgZnJvbSBhIHNl Y3VyaXR5IHN0YW5kcG9pbnQsIGJ1dCB3YW50ZWQgdG8gZG91YmxlIGNoZWNrIHdpdGggeW91Lg0K DQoNCg0KVGhhbmtzLA0KDQpCZXN0IHJlZ2FyZHMsDQoNCi0tQnJ1bm8NCg0KDQoNCj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0KPiBGcm9tOiBEYXZpZCBNYW5kZWxiZXJnIFttYWlsdG86 ZGF2aWRAbWFuZGVsYmVyZy5vcmddDQoNCj4gU2VudDogVHVlc2RheSwgU2VwdGVtYmVyIDE5LCAy MDE3IDY6MjQgUE0NCg0KPiBUbzogQWNlZSBMaW5kZW0gKGFjZWUpOyBERUNSQUVORSBCcnVubyBJ TVQvT0xOOyBSb2JlcnQgUmFzenVrDQoNCj4gQ2M6IGllc2dAaWV0Zi5vcmc7IGRyYWZ0LWlldGYt b3NwZi1lbmNhcHN1bGF0aW9uLWNhcC5hbGxAaWV0Zi5vcmc7IHNlY2RpckBpZXRmLm9yZw0KDQo+ IFN1YmplY3Q6IFJlOiBzZWNkaXIgcmV2aWV3IG9mIGRyYWZ0LWlldGYtb3NwZi1lbmNhcHN1bGF0 aW9uLWNhcC0wNg0KDQo+DQoNCiA+IExvb2tzIGdvb2QgdG8gbWUgdG9vLg0KDQo+DQoNCiA+IE9u IDA5LzE5LzIwMTcgMDc6MDEgQU0sIEFjZWUgTGluZGVtIChhY2VlKSB3cm90ZToNCg0KPiA+IEhp IEJydW5vLCBSb2JlcnQsDQoNCj4gPg0KDQo+ID4gU291bmRzIGdvb2QgdG8gbWUuIE9uZSBuaXQg 4oCTIHJlcGxhY2Ug4oCcZS5nLiDigJwgd2l0aCDigJwsIGUuZy4sIOKAnCBpbiB0aGUNCg0KPiA+ IGFkZGVkIHRleHQuDQoNCj4gPiBUaGFua3MsDQoNCj4gPiBBY2VlDQoNCj4gPg0KDQo+ID4gRnJv bTogQnJ1bm8gRGVjcmFlbmUgPGJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb20NCg0KPiA+IDxtYWls dG86YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbT4+DQoNCj4gPiBEYXRlOiBUdWVzZGF5LCBTZXB0 ZW1iZXIgMTksIDIwMTcgYXQgNDoxNSBBTQ0KDQo+ID4gVG86IFJvYmVydCBSYXN6dWsgPHJvYmVy dEByYXN6dWsubmV0IDxtYWlsdG86cm9iZXJ0QHJhc3p1ay5uZXQ8bWFpbHRvOnJvYmVydEByYXN6 dWsubmV0JTIwJTNjbWFpbHRvOnJvYmVydEByYXN6dWsubmV0Pj4+DQoNCj4gPiBDYzogVGhlIElF U0cgPGllc2dAaWV0Zi5vcmcgPG1haWx0bzppZXNnQGlldGYub3JnPG1haWx0bzppZXNnQGlldGYu b3JnJTIwJTNjbWFpbHRvOmllc2dAaWV0Zi5vcmc+Pj4sIERhdmlkIE1hbmRlbGJlcmcNCg0KPiA+ IDxkYXZpZEBtYW5kZWxiZXJnLm9yZyA8bWFpbHRvOmRhdmlkQG1hbmRlbGJlcmcub3JnPG1haWx0 bzpkYXZpZEBtYW5kZWxiZXJnLm9yZyUyMCUzY21haWx0bzpkYXZpZEBtYW5kZWxiZXJnLm9yZz4+ PiwNCg0KPiA+ICJkcmFmdC1pZXRmLW9zcGYtZW5jYXBzdWxhdGlvbi1jYXAuYWxsQGlldGYub3Jn DQoNCj4gPiA8bWFpbHRvOmRyYWZ0LWlldGYtb3NwZi1lbmNhcHN1bGF0aW9uLWNhcC5hbGxAaWV0 Zi5vcmc+Ig0KDQo+ID4gPGRyYWZ0LWlldGYtb3NwZi1lbmNhcHN1bGF0aW9uLWNhcC5hbGxAaWV0 Zi5vcmcNCg0KPiA+IDxtYWlsdG86ZHJhZnQtaWV0Zi1vc3BmLWVuY2Fwc3VsYXRpb24tY2FwLmFs bEBpZXRmLm9yZz4+LA0KDQo+ID4gInNlY2RpckBpZXRmLm9yZyA8bWFpbHRvOnNlY2RpckBpZXRm Lm9yZz48bWFpbHRvOnNlY2RpckBpZXRmLm9yZyUyMCUzY21haWx0bzpzZWNkaXJAaWV0Zi5vcmcl M2U+IiA8c2VjZGlyQGlldGYub3JnDQoNCj4gPiA8bWFpbHRvOnNlY2RpckBpZXRmLm9yZz4+DQoN Cj4gPiBTdWJqZWN0OiBSRTogc2VjZGlyIHJldmlldyBvZiBkcmFmdC1pZXRmLW9zcGYtZW5jYXBz dWxhdGlvbi1jYXAtMDYNCg0KPiA+IFJlc2VudC1Gcm9tOiA8YWxpYXMtYm91bmNlc0BpZXRmLm9y ZyA8bWFpbHRvOmFsaWFzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmFsaWFzLWJvdW5jZXNAaWV0 Zi5vcmclMjAlM2NtYWlsdG86YWxpYXMtYm91bmNlc0BpZXRmLm9yZz4+Pg0KDQo+ID4gUmVzZW50 LVRvOiBYaWFvaHUgWHUgPHh1eGlhb2h1QGh1YXdlaS5jb20gPG1haWx0bzp4dXhpYW9odUBodWF3 ZWkuY29tPG1haWx0bzp4dXhpYW9odUBodWF3ZWkuY29tJTIwJTNjbWFpbHRvOnh1eGlhb2h1QGh1 YXdlaS5jb20+Pj4sDQoNCj4gPiBCcnVubyBEZWNyYWVuZSA8YnJ1bm8uZGVjcmFlbmVAb3Jhbmdl LmNvbQ0KDQo+ID4gPG1haWx0bzpicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tPj4sIFJvYmVydCBS YXN6dWsgPHJvYmVydEByYXN6dWsubmV0DQoNCj4gPiA8bWFpbHRvOnJvYmVydEByYXN6dWsubmV0 Pj4sIEx1aXMgQ29udHJlcmFzDQoNCj4gPiA8bHVpc21pZ3VlbC5jb250cmVyYXNtdXJpbGxvQHRl bGVmb25pY2EuY29tDQoNCj4gPiA8bWFpbHRvOmx1aXNtaWd1ZWwuY29udHJlcmFzbXVyaWxsb0B0 ZWxlZm9uaWNhLmNvbT4+LCBMdWF5IEphbGlsDQoNCj4gPiA8bHVheS5qYWxpbEB2ZXJpem9uLmNv bSA8bWFpbHRvOmx1YXkuamFsaWxAdmVyaXpvbi5jb208bWFpbHRvOmx1YXkuamFsaWxAdmVyaXpv bi5jb20lMjAlM2NtYWlsdG86bHVheS5qYWxpbEB2ZXJpem9uLmNvbT4+PiwgQWNlZSBMaW5kZW0N Cg0KPiA+IDxhY2VlQGNpc2NvLmNvbSA8bWFpbHRvOmFjZWVAY2lzY28uY29tPG1haWx0bzphY2Vl QGNpc2NvLmNvbSUyMCUzY21haWx0bzphY2VlQGNpc2NvLmNvbT4+PiwgPGFrckBjaXNjby5jb20N Cg0KPiA+IDxtYWlsdG86YWtyQGNpc2NvLmNvbT4+LCA8YXJldGFuYUBjaXNjby5jb20gPG1haWx0 bzphcmV0YW5hQGNpc2NvLmNvbTxtYWlsdG86YXJldGFuYUBjaXNjby5jb20lMjAlM2NtYWlsdG86 YXJldGFuYUBjaXNjby5jb20+Pj4sDQoNCj4gPiBEZWJvcmFoIEJydW5nYXJkIDxkYjM1NDZAYXR0 LmNvbSA8bWFpbHRvOmRiMzU0NkBhdHQuY29tPG1haWx0bzpkYjM1NDZAYXR0LmNvbSUyMCUzY21h aWx0bzpkYjM1NDZAYXR0LmNvbT4+PiwgQWxpYSBBdGxhcw0KDQo+ID4gPGFrYXRsYXNAZ21haWwu Y29tIDxtYWlsdG86YWthdGxhc0BnbWFpbC5jb208bWFpbHRvOmFrYXRsYXNAZ21haWwuY29tJTIw JTNjbWFpbHRvOmFrYXRsYXNAZ21haWwuY29tPj4+LCBBY2VlIExpbmRlbQ0KDQo+ID4gPGFjZWVA Y2lzY28uY29tIDxtYWlsdG86YWNlZUBjaXNjby5jb208bWFpbHRvOmFjZWVAY2lzY28uY29tJTIw JTNjbWFpbHRvOmFjZWVAY2lzY28uY29tPj4+DQoNCj4gPiBSZXNlbnQtRGF0ZTogVHVlc2RheSwg U2VwdGVtYmVyIDE5LCAyMDE3IGF0IDQ6MTUgQU0NCg0KPiA+DQoNCj4gPiAgICAgKkZyb206KnJy YXN6dWtAZ21haWwuY29tIDxtYWlsdG86cnJhc3p1a0BnbWFpbC5jb20+DQoNCj4gPiAgICAgW21h aWx0bzpycmFzenVrQGdtYWlsLmNvbV0gKk9uIEJlaGFsZiBPZiAqUm9iZXJ0IFJhc3p1aw0KDQo+ ID4NCg0KPiA+ICAgICBQbGVhc2UgcmVwbGFjZSBBUyB3aXRoIEFkbWluaXN0cmF0aXZlIERvbWFp bi4NCg0KPiA+DQoNCj4gPiAgICAgW0JydW5vXSBJIHJlcGxhY2VkIEFTIHdpdGgg4oCcT1NQRiBk b21haW7igJ0gYXMgaW5kZWVkLCBBUyBpcyBhIEJHUCB0ZXJtDQoNCj4gPiAgICAgcmF0aGVyIHRo YW4gYW4gT1NQRiBvbmUuIEFuZCBhcyB5b3Ugbm90ZSwgaW4gc29tZSBjYXNlcywgdGhlIEFTIGFu ZA0KDQo+ID4gICAgIHRoZSBJR1AgZG9tYWluIG1heSBiZSBkaWZmZXJlbnQuIFRoYW5rcy4NCg0K PiA+DQoNCj4gPiAgICAgSWYgSSBoYXZlIHRocmVlIEFTZXMgdGhlcmUgc2hvdWxkIGJlIG5vIGFy dGlmaWNpYWwgbGltaXRzDQoNCj4gPiAgICAgcHJvaGliaXRpbmcgZW5jYXAgdG8gbXkgY2VudHJh bCBjb2xsZWN0b3IuDQoNCj4gPg0KDQo+ID4gICAgIFtCcnVub10NCg0KPiA+DQoNCj4gPiAgICAg SWYgeW91ciBjZW50cmFsIGNvbGxlY3RvciBpcyBwYXJ0IG9mIHRoZSBPU1BGIGRvbWFpbiBvZiB0 aGUNCg0KPiA+ICAgICBlbmNhcHN1bGF0b3IsIHRoZXJlIGlzIG5vIHByb2JsZW0uDQoNCj4gPg0K DQo+ID4gICAgIE90aGVyd2lzZSwgaWYgdGhlIHJvdXRlIHRvIHlvdXIgY2VudHJhbCBjb2xsZWN0 b3IgaXMgYWR2ZXJ0aXNlZCBpbg0KDQo+ID4gICAgIE9TUEYgYnkgdGhlIGRlY2Fwc3VsYXRvciwg dGhlcmUgaXMgbm8gcHJvYmxlbS4NCg0KPiA+DQoNCj4gPiAgICAgT3RoZXJ3aXNlLCBpZiB0aGUg cm91dGUgdG8geW91ciBjZW50cmFsIGNvbGxlY3RvciBpcyBhZHZlcnRpc2VkIGluDQoNCj4gPiAg ICAgQkdQLCB0aGVuIGRyYWZ0LWlldGYtaWRyLXR1bm5lbC1lbmNhcHMgaXMgcHJvYmFibHkgdGhl IHJpZ2h0IHRvb2wuDQoNCj4gPg0KDQo+ID4gICAgIC0tQnJ1bm8NCg0KPiA+DQoNCj4gPiAgICAg VGh4DQoNCj4gPg0KDQo+ID4gICAgIFINCg0KPiA+DQoNCj4gPiAgICAgT24gU2VwIDE5LCAyMDE3 IDA4OjE4LCA8YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbQ0KDQo+ID4gICAgIDxtYWlsdG86YnJ1 bm8uZGVjcmFlbmVAb3JhbmdlLmNvbT4+IHdyb3RlOg0KDQo+ID4NCg0KPiA+ICAgICA+IEZyb206 IERhdmlkIE1hbmRlbGJlcmcgW21haWx0bzpkYXZpZEBtYW5kZWxiZXJnLm9yZyA8bWFpbHRvOmRh dmlkQG1hbmRlbGJlcmcub3JnPjxtYWlsdG86ZGF2aWRAbWFuZGVsYmVyZy5vcmclMjAlM2NtYWls dG86ZGF2aWRAbWFuZGVsYmVyZy5vcmclM2U+XQ0KDQo+ID4gICAgICAgPiBTZW50OiBNb25kYXks IFNlcHRlbWJlciAxOCwgMjAxNyA5OjMwIFBNDQoNCj4gPiAgICAgPg0KDQo+ID4gICAgICAgPiBP biAwOS8xOC8yMDE3IDA1OjA4IEFNLCBicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tPG1haWx0bzpi cnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tPg0KDQo+ID4gICAgIDxtYWlsdG86YnJ1bm8uZGVjcmFl bmVAb3JhbmdlLmNvbT4gd3JvdGU6DQoNCj4gPiAgICAgICA+ID4gICA+IChjKSBpcyB0aGUgb25l IHRoYXQgSSB0aGluayBpcyB3b3J0aCBsb29raW5nIGludG8uIEUuZy4sDQoNCj4gPiAgICAgZG9l cyB0aGlzIG5ldw0KDQo+ID4gICAgICAgPiA+ICAgPiBleHRlbnNpb24gbWFrZSBpdCBlYXNpZXIg Zm9yIGFuIGF0dGFja2VyIHRvIHJvdXRlIGEgcGFja2V0DQoNCj4gPiAgICAgYWNyb3NzIEFTDQoN Cj4gPiAgICAgICA+ID4gICA+IGJvdW5kYXJpZXMsIGJ5IHNldHRpbmcgYSB0dW5uZWwgZW5kcG9p bnQgb3V0c2lkZSBvZiB0aGUNCg0KPiA+ICAgICBPU1BGLXJvdXRlZCBuZXR3b3JrPw0KDQo+ID4g ICAgICAgPiA+DQoNCj4gPiAgICAgICA+ID4gTm8uIFRoZSBmb2xsb3dpbmcgdGV4dCBhbHJlYWR5 IHByb2hpYml0cyBldmVuIG1vcmUgdGhhbiB0aGlzOg0KDQo+ID4gICAgICAgPiA+DQoNCj4gPiAg ICAgICA+ID4gIiAgQSB0dW5uZWwgTVVTVCBOT1QgYmUNCg0KPiA+ICAgICAgID4gPiAgICAgICAg dXNlZCBpZiB0aGVyZSBpcyBubyByb3V0ZSB0b3dhcmQgdGhlIElQIGFkZHJlc3MNCg0KPiA+ICAg ICBzcGVjaWZpZWQgaW4gdGhlDQoNCj4gPiAgICAgICA+ID4gICAgICAgIEVuZHBvaW50IFN1Yi1U TFYgKFNlZSA8eHJlZiB0YXJnZXQ9IkVuZHBvaW50VExWIi8+KSBvcg0KDQo+ID4gICAgIGlmIHRo ZSByb3V0ZSBpcw0KDQo+ID4gICAgICAgPiA+ICAgICAgICBub3QgYWR2ZXJ0aXNlZCBieSB0aGUg cm91dGVyIGFkdmVydGlzaW5nIHRoaXMgVHVubmVsDQoNCj4gPiAgICAgU3ViLVRMVi4iDQoNCj4g PiAgICAgICA+ID4NCg0KPiA+ICAgICAgID4gPiAtIEJ5IGRlZmluaXRpb24sIHRoaXMgVHVubmVs IFN1Yi1UTFYgaXMgYWR2ZXJ0aXNlZCBpbiBPU1BGDQoNCj4gPiAgICAgaS5lLiBmcm9tIHdpdGhp biB0aGUgQVMuDQoNCj4gPiAgICAgICA+ID4gLSBUaGUgdGV4dCBhbHNvIHByb2hpYml0cyBzZXR0 aW5nIGEgdHVubmVsIGVuZHBvaW50IHRvIGFub3RoZXINCg0KPiA+ICAgICByb3V0ZXIgd2l0aGlu IHRoZSBBUy4NCg0KPiA+ICAgICAgID4gPg0KDQo+ID4gICAgICAgPiA+DQoNCj4gPiAgICAgICA+ ID4gVGhhdCBiZWluZyBzYWlkLCB3aXRoaW4gdGhlIEFTLCB0aGUgcG9pbnQgImMiIHN0aWxsIGFw cGxpZXMuDQoNCj4gPiAgICAgICA+ID4gSG93ZXZlciwgdGhpbmtpbmcgdHdpY2UsIHRoZSBwcm9i YWJpbGl0eSBpcyBldmVuIG1vcmUgbGltaXRlZC4NCg0KPiA+ICAgICBJbmRlZWQsIG9uZSBjYW4g b25seSBhZHZlcnRpc2UgYQ0KDQo+ID4gICAgICAgPiB0dW5uZWwgdG8gaXRzZWxmLiBBc3N1bWlu ZyB0aGF0IHRoZSB0aGlyZCBwYXJ0eSBjYW4ndCBjb250cm9sDQoNCj4gPiAgICAgdGhlIHdob2xl IHJvdXRpbmcgdG9wb2xvZ3kgKGkuZS4gcm91dGluZw0KDQo+ID4gICAgICAgPiBhZHZlcnRpc2Vt ZW50IGZyb20gbW9zdCBjb3JlIHJvdXRlcnMpLCBpdCBjYW5ub3QgY29udHJvbCB0aGUNCg0KPiA+ ICAgICBwYXRoIGZvbGxvd2VkIGJ5IHRoZSB0dW5uZWwuIEhlbmNlIGl0DQoNCj4gPiAgICAgICA+ IHdvdWxkIG5lZWQgdG8gaGF2ZSBtb25pdG9yaW5nIGNhcGFiaWxpdGllcyBvbiBzcGVjaWZpYyBs aW5rcw0KDQo+ID4gICAgIHRoYXQgaXQgY2Fubm90IGNob29zZS4gKHRoZSBsaW5rIG9uDQoNCj4g PiAgICAgICA+IHRoZSBwYXRoIHRvIGl0c2VsZikuDQoNCj4gPiAgICAgICA+ID4gUGx1cyB0aGlz IHJpc2sgaXMgbm90IG5ldywgYXMgdGhlIHRoaXJkIHBhcnR5IGNvdWxkIGFscmVhZHkNCg0KPiA+ ICAgICBhZHZlcnRpc2UgdGhlIGRlc3RpbmF0aW9uIElQIGFkZHJlc3Mgb2YNCg0KPiA+ICAgICAg ID4gdGhlIHBhY2tldHMgKG9yIG9mIHRoZSBCR1AgTmV4dC1ob3Agb2YgdGhlIEJHUCByb3V0ZSBt YXRjaGluZw0KDQo+ID4gICAgIHRoZSBwYWNrZXQgZGVzdGluYXRpb24pLCB3aXRob3V0DQoNCj4g PiAgICAgICA+IHVzaW5nIGFueSB0dW5uZWwuDQoNCj4gPiAgICAgICA+ID4gSW4gY29uY2x1c2lv biwgYWx0aG91Z2ggSSBjb3VsZCBiZSB3cm9uZywgSSdtIG5vdCBzZWVpbmcgc3VjaA0KDQo+ID4g ICAgIG5ldyByaXNrLiAoYWdhaW4sIGFzc3VtaW5nIHRoYXQNCg0KPiA+ICAgICAgID4gYSB0aGly ZCBwYXJ0eSBjYW4gbW9kaWZ5IHRoZSBPU1BGIHJvdXRpbmcgaXMgYSBiaWcgYXNzdW1wdGlvbiku DQoNCj4gPiAgICAgICA+ID4NCg0KPiA+ICAgICAgID4gPiBCdXQgdGhlIGRpc2N1c3Npb24gd2Fz IHVzZWZ1bCwgdGhhbmtzIGZvciB0aGUgY29tbWVudHMuDQoNCj4gPiAgICAgICA+DQoNCj4gPiAg ICAgICA+IFRoYXQgZXhwbGFuYXRpb24gaXMgZ3JlYXQsIHRoYW5rIHlvdS4gSSBoYWRuJ3QgcmVh bGl6ZWQgdGhlDQoNCj4gPiAgICAgaW1wbGljYXRpb25zDQoNCj4gPiAgICAgICA+IG9mIHRoZSBw YXJhZ3JhcGggeW91IHF1b3RlZCwgd2hlbiBJIGluaXRpYWxseSByZWFkIGl0LiBJJ20gY29udmlu Y2VkDQoNCj4gPiAgICAgICA+IHRoYXQgdGhlcmUgaXNuJ3QgYSBzZWN1cml0eSBpc3N1ZSBoZXJl LCBidXQgaXQgd291bGQgYmUgbmljZSB0bw0KDQo+ID4gICAgIHNlZSB5b3VyDQoNCj4gPiAgICAg ICA+IGV4cGxhbmF0aW9uIGluIHRoZSBkb2N1bWVudCBpdHNlbGYsIGlmIGl0J3Mgbm90IGFscmVh ZHkgb2J2aW91cyB0bw0KDQo+ID4gICAgICAgPiBhbnlib2R5IHdobyBrbm93cyBPU1BGIGJldHRl ciB0aGFuIEkgZG8uDQoNCj4gPg0KDQo+ID4gICAgIEkndmUganVzdCBhZGRlZCB0aGUgZm9sbG93 aW5nIHRleHQgaW4gdGhlIHNlY3VyaXR5IHNlY3Rpb24gb2YgbXkNCg0KPiA+ICAgICBsb2NhbCB2 ZXJzaW9uOg0KDQo+ID4gICAgICJXZSBub3RlIHRoYXQgdGhlIGxhc3QgcGFyYWdyYXBoIG9mIDx4 cmVmIHRhcmdldD0iT3BlcmF0aW9uIi8+DQoNCj4gPiAgICAgZm9yYmlkIHRoZSBlc3RhYmxpc2ht ZW50IG9mIGEgdHVubmVsIHRvd2FyZCBhcmJpdHJhcnkgZGVzdGluYXRpb25zLg0KDQo+ID4gICAg IEl0IHByb2hpYml0cyBhIGRlc3RpbmF0aW9uIG91dHNpZGUgb2YgdGhlIEF1dG9ub21vdXMgU3lz dGVtIGFuZCBhbHNvDQoNCj4gPiAgICAgdG8gb3RoZXIgcm91dGVycyB3aXRoaW4gdGhlIEFTLiBU aGlzIGF2b2lkIHRoYXQgYSB0aGlyZC1wYXJ0eQ0KDQo+ID4gICAgIGdhaW5pbmcgYWNjZXNzIHRv IGFuIE9TUEYgcm91dGVyIGJlIGFibGUgdG8gc2VuZCB0aGUgdHJhZmZpYyB0bw0KDQo+ID4gICAg IG90aGVyIGRlc3RpbmF0aW9ucywgZm9yIGUuZy4gaW5zcGVjdGlvbiBwdXJwb3Nlcy4gIg0KDQo+ ID4NCg0KPiA+ICAgICBGZWVsIGZyZWUgdG8gY29tbWVudC9wcm9wb3NlIG90aGVyIHRleHQuDQoN Cj4gPg0KDQo+ID4gICAgIFNpbmNlIEkndmUganVzdCBwdWJsaXNoZWQgLTA4IGEgZmV3IGhvdXJz IGFnbywgSSdsbCBwcm9iYWJseSBkZWxheQ0KDQo+ID4gICAgIHRoZSB1cGxvYWQgb2YgdGhpcyBu ZXcgdXBkYXRlLg0KDQo+ID4NCg0KPiA+ICAgICAtLUJydW5vDQoNCj4gPg0KDQo+ID4NCg0KPiA+ ICAgICAgID4gLS0NCg0KPiA+ICAgICAgID4gRnJlZWxhbmNlIGN5YmVyIHNlY3VyaXR5IGNvbnN1 bHRhbnQsIHNvZnR3YXJlIGRldmVsb3BlciwgYW5kIG1vcmUNCg0KPiA+ICAgICAgID4gaHR0cHM6 Ly9kYXZpZC5tYW5kZWxiZXJnLm9yZy8NCg0KPiA+DQoNCj4gPg0KDQo+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQoNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cg0KPiA+DQoNCj4gPiAgICAgQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVu dCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zDQoNCj4gPiAgICAgY29uZmlkZW50aWVsbGVzIG91 IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMNCg0KPiA+ICAgICBwYXMgZXRyZSBkaWZm dXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cw0KDQo+ ID4gICAgIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25h bGVyDQoNCj4gPiAgICAgYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxl cyBwaWVjZXMgam9pbnRlcy4gTGVzDQoNCj4gPiAgICAgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBl dGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLA0KDQo+ID4gICAgIE9yYW5nZSBkZWNsaW5l IHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLA0KDQo+ID4g ICAgIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0KDQo+ID4NCg0KPiA+ICAgICBUaGlzIG1l c3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3INCg0K PiA+ICAgICBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBs YXc7DQoNCj4gPiAgICAgdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNv cGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQoNCj4gPiAgICAgSWYgeW91IGhhdmUgcmVjZWl2 ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyDQoNCj4gPiAg ICAgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCg0KPiA+ICAg ICBBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNz YWdlcyB0aGF0DQoNCj4gPiAgICAgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNp ZmllZC4NCg0KPiA+ICAgICBUaGFuayB5b3UuDQoNCj4gPg0KDQo+ID4NCg0KPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQoNCj4gPg0KDQo+ID4gICAgIENlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBl dXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UNCg0KPiBw cml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jDQoNCj4gPiAgICAgcGFzIGV0cmUgZGlmZnVz ZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiBy ZWN1IGNlIG1lc3NhZ2UgcGFyDQoNCj4gZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcg0KDQo+ ID4gICAgIGEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2Vz IGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50DQoNCj4gc3VzY2VwdGli bGVzIGQnYWx0ZXJhdGlvbiwNCg0KPiA+ICAgICBPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25z YWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4g TWVyY2kuDQoNCj4gPg0KDQo+ID4gICAgIFRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRz IG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQN Cg0KPiBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsNCg0KPiA+ICAgICB0aGV5IHNob3VsZCBub3Qg YmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4NCg0K PiA+ICAgICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ug bm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kDQoNCj4gaXRzIGF0 dGFjaG1lbnRzLg0KDQo+ID4gICAgIEFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlz IG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLA0KDQo+IGNo YW5nZWQgb3IgZmFsc2lmaWVkLg0KDQo+ID4gICAgIFRoYW5rIHlvdS4NCg0KPiA+DQoNCj4NCg0K ID4NCg0KID4gLS0NCg0KPiBGcmVlbGFuY2UgY3liZXIgc2VjdXJpdHkgY29uc3VsdGFudCwgc29m dHdhcmUgZGV2ZWxvcGVyLCBhbmQgbW9yZQ0KDQo+IGh0dHBzOi8vZGF2aWQubWFuZGVsYmVyZy5v cmcvDQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBj b250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMg ZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVz IHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJl dXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFp bnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0 YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3Bv bnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmll LiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNv bmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3Rl ZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQg d2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGlu IGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2Ug YW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMg bm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQg b3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo= --_000_53C29892C857584299CBF5D05346208A478A7539OPEXCLILM21corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlRleHRlIGJydXQgQ2FyIjsN CgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOmJsYWNrOw0KCW1z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwg ZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiJUZXh0ZSBkZSBidWxsZXMgQ2FyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2Vy aWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCnNwYW4uVGV4dGVicnV0Q2FyDQoJ e21zby1zdHlsZS1uYW1lOiJUZXh0ZSBicnV0IENhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCW1zby1zdHlsZS1saW5rOiJUZXh0ZSBicnV0IjsNCglmb250LWZhbWlseToiQXJpYWwiLCJz YW5zLXNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpzcGFuLlRleHRlZGVidWxsZXNDYXINCgl7bXNv LXN0eWxlLW5hbWU6IlRleHRlIGRlIGJ1bGxlcyBDYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazoiVGV4dGUgZGUgYnVsbGVzIjsNCglmb250LWZhbWlseToiVGFo b21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw b3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0 IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgODguNXB0IDcwLjg1cHQgODguNXB0O30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv Pg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFu Zz0iRlIiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp b24xIj4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5bcmVtb3Zp bmcgdGhlIGllc2cgdG8gbGltaXQgc3BhbW1pbmcsIGFkZGluZyBBbGlhIChyZXNwb25zaWJsZSBB RCldPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5IaSBEYXZpZCw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0i RU4tVVMiPlNvcnJ5IHRvIGNvbWUgYmFjayBvbiB0aGlzIGRyYWZ0IDMgd2Vla3MgYWZ0ZXIgb3Vy IGxhdGVzdCBlbWFpbCwgYnV0IGEgbGF0ZSBjb21tZW50IGlzIGxpa2VseSB0byBjaGFuZ2UgYSBz ZW50ZW5jZSBpbiB0aGUgZHJhZnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPkFzIHdlIGhhZCBkaXNjdXNzZWQgdGhhdCBz ZW50ZW5jZSBkdXJpbmcgeW91ciBzZWNkaXIgcmV2aWV3LCBJIGZlZWwgdGhhdCBpdCB3b3VsZCBi ZSBob25lc3QgdG8gY29tZSBiYWNrIHRvIHlvdSB0byByZXBvcnQgdGhhdCBjaGFuZ2UsIGV2ZW4g aWYgSSBkb27igJl0IGZlZWwgdGhlIGNoYW5nZSBpcyBwcm9ibGVtYXRpYy48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g bGFuZz0iRU4tVVMiPlByb3Bvc2VkIDIgY2hhbmdlcyBhcmUgdGhlIGZvbGxvd2luZzo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1V UyI+wqcgT3BlcmF0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9MRDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+QSB0dW5uZWwgTVVTVCBOT1Qg YmUgdXNlZCBpZiB0aGVyZSBpcyBubyByb3V0ZSB0b3dhcmQgdGhlIElQIGFkZHJlc3Mgc3BlY2lm aWVkIGluIHRoZSBFbmRwb2ludCBTdWItVExWIChTZWUgJmx0O3hyZWYgdGFyZ2V0PSZxdW90O0Vu ZHBvaW50VExWJnF1b3Q7LyZndDspPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPm9yIGlmIHRoZSByb3V0ZSBpcyBub3QgYWR2 ZXJ0aXNlZCA8c3BhbiBzdHlsZT0iYmFja2dyb3VuZDp5ZWxsb3c7bXNvLWhpZ2hsaWdodDp5ZWxs b3ciPg0KYnkgdGhlIHJvdXRlciBhZHZlcnRpc2luZyB0aGlzIFR1bm5lbCBTdWItVExWLjwvc3Bh bj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPk5FVzo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+QSB0dW5uZWwgTVVTVCBO T1QgYmUgdXNlZCBpZiB0aGVyZSBpcyBubyByb3V0ZSB0b3dhcmQgdGhlIElQIGFkZHJlc3Mgc3Bl Y2lmaWVkIGluIHRoZSBFbmRwb2ludCBTdWItVExWIChTZWUgJmx0O3hyZWYgdGFyZ2V0PSZxdW90 O0VuZHBvaW50VExWJnF1b3Q7LyZndDspPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPm9yIGlmIHRoZSByb3V0ZSBpcyBub3Qg YWR2ZXJ0aXNlZCA8c3BhbiBzdHlsZT0iYmFja2dyb3VuZDp5ZWxsb3c7bXNvLWhpZ2hsaWdodDp5 ZWxsb3ciPg0KaW4gdGhlIHNhbWUgT1NQRiBkb21haW48L3NwYW4+LjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPj09PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoZSByZWFzb24gaXMgdGhhdCBp biBtdWx0aS1hcmVhIE9TUEYgZGVwbG95bWVudHMsIHRoZSBUdW5uZWwgU3ViLVRMViBtYXkgYmUg Zmxvb2RlZCBkb21haW4td2lkZSB3aGlsZSB0aGUgSVAgcHJlZml4IG1heSBub3QuIEhlbmNlIGJv dGggYWR2ZXJ0aXNlbWVudHMgd291bGQgbm90IGNvbWUgZnJvbSB0aGUgc2FtZSByb3V0ZXIuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0i RU4tVVMiPj09PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+wqdzZWN1 cml0eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu IGxhbmc9IkVOLVVTIj5PTEQ6Jm5ic3A7IEl0IHByb2hpYml0cyBhIGRlc3RpbmF0aW9uIG91dHNp ZGUgb2YgdGhlIE9TUEYgZG9tYWluDQo8c3BhbiBzdHlsZT0iYmFja2dyb3VuZDp5ZWxsb3c7bXNv LWhpZ2hsaWdodDp5ZWxsb3ciPmFuZCBhbHNvIHRvIG90aGVyIHJvdXRlcnMgd2l0aGluIHRoZSBk b21haW4uPC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5ORVc6IEl0IHByb2hpYml0cyBhIGRlc3RpbmF0aW9uIG91 dHNpZGUgb2YgdGhlIE9TUEYgZG9tYWluLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFu Zz0iRU4tVVMiPj09PTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5BcyBhIGNvbnNlcXVlbmNlLCB0aGlzIHNsaWdodGx5IGlu Y3JlYXNlcyB0aGUgY2FwYWJpbGl0aWVzIGFuZCBoZW5jZSB0aGUgc2VjdXJpdHkgaW1wbGljYXRp b25zLiBIb3dldmVyLCB0aGlzIHN0aWxsIHJlc3RyaWN0cyB0aGUgdXNlIG9mIHR1bm5lbCB3aG9z ZSBkZXN0aW5hdGlvbiBpcyB3aXRoaW4gdGhlIE9TUEYgZG9tYWluIChpLmUuIG5vdCBJbnRlcm5l dCB3aWRlKSB3aGljaA0KIHdhcyB5b3VyIG9yaWdpbmFsIGNvbmNlcm4uIFBsdXMgSU1PLCBhc3N1 bWluZyB0aGF0IGFuIGF0dGFja2VyIGNhbiBjb250cm9sIHRoZSBPU1BGIGFkdmVydGlzZW1lbnQg aXMgYWxyZWFkeSBhIHNpZ25pZmljYW50IGFzc3VtcHRpb24uPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPj09PTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBsYW5nPSJFTi1VUyI+Qm90dG9tIGxpbmUsIEkgYmVsaWV2ZSB0aGUgY2hhbmdlIGlzIHF1 aXRlIHNtYWxsIGZyb20gYSBzZWN1cml0eSBzdGFuZHBvaW50LCBidXQgd2FudGVkIHRvIGRvdWJs ZSBjaGVjayB3aXRoIHlvdS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoYW5rcyw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1V UyI+QmVzdCByZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4tLUJydW5vPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVT Ij4mZ3Q7IDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1 YWdlOkZSIj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g bGFuZz0iRU4tVVMiPjwvc3Bhbj4mZ3Q7IDxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFn ZTpGUiI+DQpGcm9tOiBEYXZpZCBNYW5kZWxiZXJnIFttYWlsdG86ZGF2aWRAbWFuZGVsYmVyZy5v cmddPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPHNwYW4gc3R5bGU9 Im1zby1mYXJlYXN0LWxhbmd1YWdlOkZSIj5TZW50OiBUdWVzZGF5LCBTZXB0ZW1iZXIgMTksIDIw MTcgNjoyNCBQTTwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDxzcGFu IHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpGUiI+VG86IEFjZWUgTGluZGVtIChhY2VlKTsg REVDUkFFTkUgQnJ1bm8gSU1UL09MTjsgUm9iZXJ0IFJhc3p1azwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpG UiI+Q2M6IGllc2dAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtb3NwZi1lbmNhcHN1bGF0aW9uLWNhcC5h bGxAaWV0Zi5vcmc7IHNlY2RpckBpZXRmLm9yZzwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7IDxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpGUiI+U3ViamVj dDogUmU6IHNlY2RpciByZXZpZXcgb2YgZHJhZnQtaWV0Zi1vc3BmLWVuY2Fwc3VsYXRpb24tY2Fw LTA2PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jmd0OyBMb29rcyBnb29kIHRvIG1lIHRvby48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZuYnNwOyZndDsgT24gMDkvMTkvMjAxNyAwNzowMSBBTSwgQWNlZSBMaW5kZW0gKGFjZWUpIHdy b3RlOjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyBIaSBCcnVubywgUm9i ZXJ0LDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OzwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgJmd0OyBTb3VuZHMgZ29vZCB0byBtZS4gT25lIG5pdCDigJMg cmVwbGFjZSDigJxlLmcuIOKAnCB3aXRoIOKAnCwgZS5nLiwg4oCcIGluIHRoZTwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyBhZGRlZCB0ZXh0LjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgJmd0OyBUaGFua3MsPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyAmZ3Q7IEFjZWU8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDs8 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgRnJvbTogQnJ1bm8gRGVjcmFl bmUgJmx0O2JydW5vLmRlY3JhZW5lQG9yYW5nZS5jb208L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7ICZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzpicnVuby5kZWNyYWVuZUBvcmFuZ2Uu Y29tIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2s7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPm1haWx0 bzpicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tPC9zcGFuPjwvYT4mZ3Q7Jmd0OzwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyBEYXRlOiBUdWVzZGF5LCBTZXB0ZW1iZXIgMTks IDIwMTcgYXQgNDoxNSBBTTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyBU bzogUm9iZXJ0IFJhc3p1ayAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJvYmVydEByYXN6dWsubmV0JTIw JTNjbWFpbHRvOnJvYmVydEByYXN6dWsubmV0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2s7dGV4 dC1kZWNvcmF0aW9uOm5vbmUiPnJvYmVydEByYXN6dWsubmV0ICZsdDttYWlsdG86cm9iZXJ0QHJh c3p1ay5uZXQ8L3NwYW4+PC9hPiZndDsmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0OyAmZ3Q7IENjOiBUaGUgSUVTRyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmllc2dAaWV0Zi5vcmcl MjAlM2NtYWlsdG86aWVzZ0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrO3RleHQt ZGVjb3JhdGlvbjpub25lIj5pZXNnQGlldGYub3JnICZsdDttYWlsdG86aWVzZ0BpZXRmLm9yZzwv c3Bhbj48L2E+Jmd0OyZndDssIERhdmlkIE1hbmRlbGJlcmc8L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7ICZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzpkYXZpZEBtYW5kZWxiZXJnLm9y ZyUyMCUzY21haWx0bzpkYXZpZEBtYW5kZWxiZXJnLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrO3RleHQtZGVjb3JhdGlvbjpub25lIj5kYXZpZEBtYW5kZWxiZXJnLm9yZyAmbHQ7bWFpbHRv OmRhdmlkQG1hbmRlbGJlcmcub3JnPC9zcGFuPjwvYT4mZ3Q7Jmd0Oyw8L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJnF1b3Q7ZHJhZnQtaWV0Zi1vc3BmLWVuY2Fwc3VsYXRp b24tY2FwLmFsbEBpZXRmLm9yZzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0 OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtb3NwZi1lbmNhcHN1bGF0aW9uLWNhcC5h bGxAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjazt0ZXh0LWRlY29yYXRpb246bm9u ZSI+bWFpbHRvOmRyYWZ0LWlldGYtb3NwZi1lbmNhcHN1bGF0aW9uLWNhcC5hbGxAaWV0Zi5vcmc8 L3NwYW4+PC9hPiZndDsmcXVvdDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZn dDsgJmx0O2RyYWZ0LWlldGYtb3NwZi1lbmNhcHN1bGF0aW9uLWNhcC5hbGxAaWV0Zi5vcmc8L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzpk cmFmdC1pZXRmLW9zcGYtZW5jYXBzdWxhdGlvbi1jYXAuYWxsQGlldGYub3JnIj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2s7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPm1haWx0bzpkcmFmdC1pZXRmLW9z cGYtZW5jYXBzdWxhdGlvbi1jYXAuYWxsQGlldGYub3JnPC9zcGFuPjwvYT4mZ3Q7Jmd0Oyw8L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJnF1b3Q7PGEgaHJlZj0ibWFpbHRv OnNlY2RpckBpZXRmLm9yZyUyMCUzY21haWx0bzpzZWNkaXJAaWV0Zi5vcmclM2UiPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjazt0ZXh0LWRlY29yYXRpb246bm9uZSI+c2VjZGlyQGlldGYub3JnICZs dDttYWlsdG86c2VjZGlyQGlldGYub3JnJmd0Ozwvc3Bhbj48L2E+JnF1b3Q7ICZsdDtzZWNkaXJA aWV0Zi5vcmc8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmx0OzxhIGhy ZWY9Im1haWx0bzpzZWNkaXJAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjazt0ZXh0 LWRlY29yYXRpb246bm9uZSI+bWFpbHRvOnNlY2RpckBpZXRmLm9yZzwvc3Bhbj48L2E+Jmd0OyZn dDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgU3ViamVjdDogUkU6IHNl Y2RpciByZXZpZXcgb2YgZHJhZnQtaWV0Zi1vc3BmLWVuY2Fwc3VsYXRpb24tY2FwLTA2PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7IFJlc2VudC1Gcm9tOiAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmFsaWFzLWJvdW5jZXNAaWV0Zi5vcmclMjAlM2NtYWlsdG86YWxpYXMtYm91bmNl c0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrO3RleHQtZGVjb3JhdGlvbjpub25l Ij5hbGlhcy1ib3VuY2VzQGlldGYub3JnICZsdDttYWlsdG86YWxpYXMtYm91bmNlc0BpZXRmLm9y Zzwvc3Bhbj48L2E+Jmd0OyZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZn dDsgUmVzZW50LVRvOiBYaWFvaHUgWHUgJmx0OzxhIGhyZWY9Im1haWx0bzp4dXhpYW9odUBodWF3 ZWkuY29tJTIwJTNjbWFpbHRvOnh1eGlhb2h1QGh1YXdlaS5jb20iPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjazt0ZXh0LWRlY29yYXRpb246bm9uZSI+eHV4aWFvaHVAaHVhd2VpLmNvbSAmbHQ7bWFp bHRvOnh1eGlhb2h1QGh1YXdlaS5jb208L3NwYW4+PC9hPiZndDsmZ3Q7LDwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgJmd0OyBCcnVubyBEZWNyYWVuZSAmbHQ7YnJ1bm8uZGVjcmFl bmVAb3JhbmdlLmNvbTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb20iPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjazt0ZXh0LWRlY29yYXRpb246bm9uZSI+bWFpbHRvOmJydW5vLmRlY3JhZW5lQG9y YW5nZS5jb208L3NwYW4+PC9hPiZndDsmZ3Q7LCBSb2JlcnQgUmFzenVrICZsdDtyb2JlcnRAcmFz enVrLm5ldDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnJvYmVydEByYXN6dWsubmV0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2s7dGV4 dC1kZWNvcmF0aW9uOm5vbmUiPm1haWx0bzpyb2JlcnRAcmFzenVrLm5ldDwvc3Bhbj48L2E+Jmd0 OyZndDssIEx1aXMgQ29udHJlcmFzPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAm Z3Q7ICZsdDtsdWlzbWlndWVsLmNvbnRyZXJhc211cmlsbG9AdGVsZWZvbmljYS5jb208L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzpsdWlz bWlndWVsLmNvbnRyZXJhc211cmlsbG9AdGVsZWZvbmljYS5jb20iPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjazt0ZXh0LWRlY29yYXRpb246bm9uZSI+bWFpbHRvOmx1aXNtaWd1ZWwuY29udHJlcmFz bXVyaWxsb0B0ZWxlZm9uaWNhLmNvbTwvc3Bhbj48L2E+Jmd0OyZndDssIEx1YXkgSmFsaWw8L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzps dWF5LmphbGlsQHZlcml6b24uY29tJTIwJTNjbWFpbHRvOmx1YXkuamFsaWxAdmVyaXpvbi5jb20i PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjazt0ZXh0LWRlY29yYXRpb246bm9uZSI+bHVheS5qYWxp bEB2ZXJpem9uLmNvbSAmbHQ7bWFpbHRvOmx1YXkuamFsaWxAdmVyaXpvbi5jb208L3NwYW4+PC9h PiZndDsmZ3Q7LCBBY2VlIExpbmRlbTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFjZWVAY2lzY28uY29tJTIwJTNjbWFpbHRvOmFjZWVA Y2lzY28uY29tIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2s7dGV4dC1kZWNvcmF0aW9uOm5vbmUi PmFjZWVAY2lzY28uY29tICZsdDttYWlsdG86YWNlZUBjaXNjby5jb208L3NwYW4+PC9hPiZndDsm Z3Q7LCAmbHQ7YWtyQGNpc2NvLmNvbTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFrckBjaXNjby5jb20iPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjazt0ZXh0LWRlY29yYXRpb246bm9uZSI+bWFpbHRvOmFrckBjaXNjby5jb208L3NwYW4+ PC9hPiZndDsmZ3Q7LCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFyZXRhbmFAY2lzY28uY29tJTIwJTNj bWFpbHRvOmFyZXRhbmFAY2lzY28uY29tIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2s7dGV4dC1k ZWNvcmF0aW9uOm5vbmUiPmFyZXRhbmFAY2lzY28uY29tDQogJmx0O21haWx0bzphcmV0YW5hQGNp c2NvLmNvbTwvc3Bhbj48L2E+Jmd0OyZndDssPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0OyAmZ3Q7IERlYm9yYWggQnJ1bmdhcmQgJmx0OzxhIGhyZWY9Im1haWx0bzpkYjM1NDZAYXR0 LmNvbSUyMCUzY21haWx0bzpkYjM1NDZAYXR0LmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr O3RleHQtZGVjb3JhdGlvbjpub25lIj5kYjM1NDZAYXR0LmNvbSAmbHQ7bWFpbHRvOmRiMzU0NkBh dHQuY29tPC9zcGFuPjwvYT4mZ3Q7Jmd0OywgQWxpYSBBdGxhczwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsgJmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFrYXRsYXNAZ21haWwuY29t JTIwJTNjbWFpbHRvOmFrYXRsYXNAZ21haWwuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2s7 dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmFrYXRsYXNAZ21haWwuY29tICZsdDttYWlsdG86YWthdGxh c0BnbWFpbC5jb208L3NwYW4+PC9hPiZndDsmZ3Q7LCBBY2VlIExpbmRlbTwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgJmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFjZWVAY2lzY28u Y29tJTIwJTNjbWFpbHRvOmFjZWVAY2lzY28uY29tIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2s7 dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmFjZWVAY2lzY28uY29tICZsdDttYWlsdG86YWNlZUBjaXNj by5jb208L3NwYW4+PC9hPiZndDsmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyAmZ3Q7IFJlc2VudC1EYXRlOiBUdWVzZGF5LCBTZXB0ZW1iZXIgMTksIDIwMTcgYXQgNDoxNSBB TTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OzwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAqRnJvbToqcnJh c3p1a0BnbWFpbC5jb20gJmx0OzxhIGhyZWY9Im1haWx0bzpycmFzenVrQGdtYWlsLmNvbSI+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrO3RleHQtZGVjb3JhdGlvbjpub25lIj5tYWlsdG86cnJhc3p1 a0BnbWFpbC5jb208L3NwYW4+PC9hPiZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgWzxhIGhyZWY9Im1haWx0bzpycmFzenVr QGdtYWlsLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrO3RleHQtZGVjb3JhdGlvbjpub25l Ij5tYWlsdG86cnJhc3p1a0BnbWFpbC5jb208L3NwYW4+PC9hPl0gKk9uIEJlaGFsZiBPZiAqUm9i ZXJ0IFJhc3p1azwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OzwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBQ bGVhc2UgcmVwbGFjZSBBUyB3aXRoIEFkbWluaXN0cmF0aXZlIERvbWFpbi48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgW0JydW5vXSBJIHJlcGxhY2VkIEFTIHdp dGgg4oCcT1NQRiBkb21haW7igJ0gYXMgaW5kZWVkLCBBUyBpcyBhIEJHUCB0ZXJtPC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJh dGhlciB0aGFuIGFuIE9TUEYgb25lLiBBbmQgYXMgeW91IG5vdGUsIGluIHNvbWUgY2FzZXMsIHRo ZSBBUyBhbmQ8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgdGhlIElHUCBkb21haW4gbWF5IGJlIGRpZmZlcmVudC4gVGhhbmtzLjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OzwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsgJmd0OyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtJZiBJIGhhdmUgdGhy ZWUgQVNlcyB0aGVyZSBzaG91bGQgYmUgbm8gYXJ0aWZpY2lhbCBsaW1pdHM8L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcHJvaGli aXRpbmcgZW5jYXAgdG8gbXkgY2VudHJhbCBjb2xsZWN0b3IuPC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyAmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFtCcnVub108L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7ICZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgSWYgeW91ciBjZW50cmFsIGNvbGxlY3RvciBpcyBwYXJ0IG9m IHRoZSBPU1BGIGRvbWFpbiBvZiB0aGU8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZW5jYXBzdWxhdG9yLCB0aGVyZSBpcyBubyBw cm9ibGVtLjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OzwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBPdGhl cndpc2UsIGlmIHRoZSByb3V0ZSB0byB5b3VyIGNlbnRyYWwgY29sbGVjdG9yIGlzIGFkdmVydGlz ZWQgaW48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgT1NQRiBieSB0aGUgZGVjYXBzdWxhdG9yLCB0aGVyZSBpcyBubyBwcm9ibGVt LjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OzwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBPdGhlcndpc2Us IGlmIHRoZSByb3V0ZSB0byB5b3VyIGNlbnRyYWwgY29sbGVjdG9yIGlzIGFkdmVydGlzZWQgaW48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgQkdQLCB0aGVuIGRyYWZ0LWlldGYtaWRyLXR1bm5lbC1lbmNhcHMgaXMgcHJvYmFibHkg dGhlIHJpZ2h0IHRvb2wuPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IC0tQnJ1bm88L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDs8L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg VGh4PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFI8L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgT24gU2VwIDE5LCAyMDE3IDA4 OjE4LCAmbHQ7YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbTwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7PGEgaHJlZj0ibWFp bHRvOmJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjazt0 ZXh0LWRlY29yYXRpb246bm9uZSI+bWFpbHRvOmJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb208L3Nw YW4+PC9hPiZndDsmZ3Q7IHdyb3RlOjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmZ3Q7IEZyb206IERhdmlkIE1hbmRlbGJlcmcgWzxhIGhyZWY9Im1haWx0bzpk YXZpZEBtYW5kZWxiZXJnLm9yZyUyMCUzY21haWx0bzpkYXZpZEBtYW5kZWxiZXJnLm9yZyUzZSI+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrO3RleHQtZGVjb3JhdGlvbjpub25lIj5tYWlsdG86ZGF2 aWRAbWFuZGVsYmVyZy5vcmcgJmx0O21haWx0bzpkYXZpZEBtYW5kZWxiZXJnLm9yZyZndDs8L3Nw YW4+PC9hPl08L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBTZW50OiBNb25kYXksIFNlcHRlbWJlciAx OCwgMjAxNyA5OjMwIFBNPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBPbiAwOS8x OC8yMDE3IDA1OjA4IEFNLCA8YSBocmVmPSJtYWlsdG86YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNv bSI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2s7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmJydW5v LmRlY3JhZW5lQG9yYW5nZS5jb208L3NwYW4+PC9hPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsgJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7PGEgaHJlZj0ibWFpbHRv OmJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjazt0ZXh0 LWRlY29yYXRpb246bm9uZSI+bWFpbHRvOmJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb208L3NwYW4+ PC9hPiZndDsgd3JvdGU6PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyZuYnNwOyZuYnNwOyAm Z3Q7IChjKSBpcyB0aGUgb25lIHRoYXQgSSB0aGluayBpcyB3b3J0aCBsb29raW5nIGludG8uIEUu Zy4sPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IGRvZXMgdGhpcyBuZXc8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7 Jm5ic3A7ICZndDsgZXh0ZW5zaW9uIG1ha2UgaXQgZWFzaWVyIGZvciBhbiBhdHRhY2tlciB0byBy b3V0ZSBhIHBhY2tldDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBhY3Jvc3MgQVM8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7 Jm5ic3A7Jm5ic3A7ICZndDsgYm91bmRhcmllcywgYnkgc2V0dGluZyBhIHR1bm5lbCBlbmRwb2lu dCBvdXRzaWRlIG9mIHRoZTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBPU1BGLXJvdXRlZCBuZXR3b3JrPzwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmZ3Q7ICZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IE5vLiBUaGUgZm9sbG93 aW5nIHRleHQgYWxyZWFkeSBwcm9oaWJpdHMgZXZlbiBtb3JlIHRoYW4gdGhpczo8L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJmd0OyAmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyAmcXVvdDsmbmJz cDsgQSB0dW5uZWwgTVVTVCBOT1QgYmU8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHVzZWQgaWYgdGhlcmUgaXMgbm8g cm91dGUgdG93YXJkIHRoZSBJUCBhZGRyZXNzPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNwZWNpZmllZCBpbiB0aGU8L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IEVuZHBvaW50IFN1Yi1UTFYgKFNlZSAmbHQ7eHJlZiB0YXJnZXQ9JnF1b3Q7RW5kcG9p bnRUTFYmcXVvdDsvJmd0Oykgb3I8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaWYgdGhlIHJvdXRlIGlzPC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsgJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBu b3QgYWR2ZXJ0aXNlZCBieSB0aGUgcm91dGVyIGFkdmVydGlzaW5nIHRoaXMgVHVubmVsPC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IFN1Yi1UTFYuJnF1b3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OzwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmZ3Q7ICZndDsgLSBCeSBkZWZpbml0aW9uLCB0aGlzIFR1bm5lbCBTdWItVExWIGlzIGFk dmVydGlzZWQgaW4gT1NQRjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpLmUuIGZyb20gd2l0aGluIHRoZSBBUy48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJmd0OyAmZ3Q7IC0gVGhlIHRleHQgYWxzbyBwcm9oaWJpdHMgc2V0dGluZyBhIHR1 bm5lbCBlbmRwb2ludCB0byBhbm90aGVyPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJvdXRlciB3aXRoaW4gdGhlIEFTLjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZndDsgJmd0OyBUaGF0IGJlaW5nIHNhaWQsIHdpdGhpbiB0aGUgQVMsIHRo ZSBwb2ludCAmcXVvdDtjJnF1b3Q7IHN0aWxsIGFwcGxpZXMuPC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZn dDsgJmd0OyBIb3dldmVyLCB0aGlua2luZyB0d2ljZSwgdGhlIHByb2JhYmlsaXR5IGlzIGV2ZW4g bW9yZSBsaW1pdGVkLjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBJbmRlZWQsIG9uZSBjYW4gb25seSBhZHZlcnRpc2UgYTwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmZ3Q7IHR1bm5lbCB0byBpdHNlbGYuIEFzc3VtaW5nIHRoYXQgdGhlIHRo aXJkIHBhcnR5IGNhbid0IGNvbnRyb2w8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhlIHdob2xlIHJvdXRpbmcgdG9wb2xvZ3kg KGkuZS4gcm91dGluZzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IGFkdmVydGlzZW1lbnQgZnJvbSBt b3N0IGNvcmUgcm91dGVycyksIGl0IGNhbm5vdCBjb250cm9sIHRoZTwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBwYXRoIGZvbGxv d2VkIGJ5IHRoZSB0dW5uZWwuIEhlbmNlIGl0PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgd291bGQg bmVlZCB0byBoYXZlIG1vbml0b3JpbmcgY2FwYWJpbGl0aWVzIG9uIHNwZWNpZmljIGxpbmtzPC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHRoYXQgaXQgY2Fubm90IGNob29zZS4gKHRoZSBsaW5rIG9uPC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZndDsgdGhlIHBhdGggdG8gaXRzZWxmKS48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAmZ3Q7IFBs dXMgdGhpcyByaXNrIGlzIG5vdCBuZXcsIGFzIHRoZSB0aGlyZCBwYXJ0eSBjb3VsZCBhbHJlYWR5 PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IGFkdmVydGlzZSB0aGUgZGVzdGluYXRpb24gSVAgYWRkcmVzcyBvZjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7IHRoZSBwYWNrZXRzIChvciBvZiB0aGUgQkdQIE5leHQtaG9wIG9mIHRoZSBC R1Agcm91dGUgbWF0Y2hpbmc8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhlIHBhY2tldCBkZXN0aW5hdGlvbiksIHdpdGhvdXQ8 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJmd0OyB1c2luZyBhbnkgdHVubmVsLjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmZ3Q7ICZndDsgSW4gY29uY2x1c2lvbiwgYWx0aG91Z2ggSSBjb3VsZCBiZSB3cm9uZywgSSdt IG5vdCBzZWVpbmcgc3VjaDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBuZXcgcmlzay4gKGFnYWluLCBhc3N1bWluZyB0aGF0PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZndDsgYSB0aGlyZCBwYXJ0eSBjYW4gbW9kaWZ5IHRoZSBPU1BGIHJv dXRpbmcgaXMgYSBiaWcgYXNzdW1wdGlvbikuPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmd0Ozwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZndDsgQnV0IHRoZSBkaXNjdXNzaW9uIHdhcyB1c2VmdWws IHRoYW5rcyBmb3IgdGhlIGNvbW1lbnRzLjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZndDsgVGhhdCBleHBsYW5hdGlvbiBpcyBncmVhdCwgdGhhbmsgeW91LiBJIGhh ZG4ndCByZWFsaXplZCB0aGU8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsm bmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7aW1wbGljYXRpb25zPC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZn dDsgb2YgdGhlIHBhcmFncmFwaCB5b3UgcXVvdGVkLCB3aGVuIEkgaW5pdGlhbGx5IHJlYWQgaXQu IEknbSBjb252aW5jZWQ8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyB0aGF0IHRoZXJlIGlzbid0IGEg c2VjdXJpdHkgaXNzdWUgaGVyZSwgYnV0IGl0IHdvdWxkIGJlIG5pY2UgdG88L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc2VlIHlv dXI8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBleHBsYW5hdGlvbiBpbiB0aGUgZG9jdW1lbnQgaXRz ZWxmLCBpZiBpdCdzIG5vdCBhbHJlYWR5IG9idmlvdXMgdG88L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0 OyBhbnlib2R5IHdobyBrbm93cyBPU1BGIGJldHRlciB0aGFuIEkgZG8uPC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEkndmUganVzdCBhZGRlZCB0aGUgZm9sbG93 aW5nIHRleHQgaW4gdGhlIHNlY3VyaXR5IHNlY3Rpb24gb2YgbXk8L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbG9jYWwgdmVyc2lv bjo8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJnF1b3Q7V2Ugbm90ZSB0aGF0IHRoZSBsYXN0IHBhcmFncmFwaCBvZiAmbHQ7eHJl ZiB0YXJnZXQ9JnF1b3Q7T3BlcmF0aW9uJnF1b3Q7LyZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZm9yYmlkIHRoZSBlc3Rh Ymxpc2htZW50IG9mIGEgdHVubmVsIHRvd2FyZCBhcmJpdHJhcnkgZGVzdGluYXRpb25zLjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBJdCBwcm9oaWJpdHMgYSBkZXN0aW5hdGlvbiBvdXRzaWRlIG9mIHRoZSBBdXRvbm9tb3VzIFN5 c3RlbSBhbmQgYWxzbzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB0byBvdGhlciByb3V0ZXJzIHdpdGhpbiB0aGUgQVMuIFRoaXMg YXZvaWQgdGhhdCBhIHRoaXJkLXBhcnR5PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyAmZ3Q7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwO2dhaW5pbmcgYWNjZXNzIHRvIGFuIE9TUEYg cm91dGVyIGJlIGFibGUgdG8gc2VuZCB0aGUgdHJhZmZpYyB0bzwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsgJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBvdGhlciBkZXN0aW5h dGlvbnMsIGZvciBlLmcuIGluc3BlY3Rpb24gcHVycG9zZXMuICZxdW90OzwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgJmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBGZWVsIGZyZWUgdG8gY29tbWVudC9wcm9w b3NlIG90aGVyIHRleHQuPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IFNpbmNlIEkndmUganVzdCBwdWJsaXNoZWQgLTA4IGEgZmV3IGhvdXJzIGFnbywgSSdsbCBw cm9iYWJseSBkZWxheTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZuYnNw OyZuYnNwOyZuYnNwOyAmbmJzcDt0aGUgdXBsb2FkIG9mIHRoaXMgbmV3IHVwZGF0ZS48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS1CcnVubzwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsgJmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IC0tPC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZn dDsgRnJlZWxhbmNlIGN5YmVyIHNlY3VyaXR5IGNvbnN1bHRhbnQsIHNvZnR3YXJlIGRldmVsb3Bl ciwgYW5kIG1vcmU8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyA8YSBocmVmPSJodHRwczovL2Rhdmlk Lm1hbmRlbGJlcmcub3JnLyI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrO3RleHQtZGVjb3JhdGlv bjpub25lIj5odHRwczovL2RhdmlkLm1hbmRlbGJlcmcub3JnLzwvc3Bhbj48L2E+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyAmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7ICZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1 dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNvbmZpZGVudGllbGxlcyBvdSBw cml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHBhcyBldHJlIGRpZmZ1c2VzLCBl eHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzPC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGF2ZXog cmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyPC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGEg bCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMu IExlczwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2Fs dGVyYXRpb24sPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IE9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNl IG1lc3NhZ2UgYSBldGUgYWx0ZXJlLDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDs8L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhpcyBtZXNzYWdl IGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yPC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHBy aXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzs8L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg dGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1 dGhvcmlzYXRpb24uPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJy b3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlcjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsgJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhbmQgZGVsZXRlIHRoaXMgbWVzc2Fn ZSBhbmQgaXRzIGF0dGFjaG1lbnRzLjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9y YW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGhhdmUgYmVlbiBtb2Rp ZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoYW5rIHlvdS48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7ICZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsgJmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50 IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jPC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0 aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhcjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhIGwnZXhw ZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMg bWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiw8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgT3JhbmdlIGRlY2xpbmUgdG91 dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3Ug ZmFsc2lmaWUuIE1lcmNpLjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0Ozwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRl bnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzs8L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhleSBzaG91bGQg bm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24u PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBu b3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQ8L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IGl0cyBhdHRhY2htZW50cy48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQXMgZW1haWxzIG1h eSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZl IGJlZW4gbW9kaWZpZWQsPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBjaGFuZ2Vk IG9yIGZhbHNpZmllZC48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhhbmsgeW91LjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsgJmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jmd0OyA8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mbmJzcDsmZ3Q7IC0tPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBGcmVl bGFuY2UgY3liZXIgc2VjdXJpdHkgY29uc3VsdGFudCwgc29mdHdhcmUgZGV2ZWxvcGVyLCBhbmQg bW9yZTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPGEgaHJlZj0iaHR0cHM6Ly9k YXZpZC5tYW5kZWxiZXJnLm9yZy8iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjazt0ZXh0LWRlY29y YXRpb246bm9uZSI+aHR0cHM6Ly9kYXZpZC5tYW5kZWxiZXJnLm9yZy88L3NwYW4+PC9hPjwvcD4N CjwvZGl2Pg0KPFBSRT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBw ZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZp bGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBv dSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2Ug cGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0 cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9u aXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91 dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3Ug ZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNv bnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUg cHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9y IGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMg ZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMg bWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9y YW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwg Y2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KPC9QUkU+PC9ib2R5Pg0KPC9odG1sPg0K --_000_53C29892C857584299CBF5D05346208A478A7539OPEXCLILM21corp_-- From nobody Mon Oct 9 17:01:46 2017 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 74D0A1320C9; Mon, 9 Oct 2017 17:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zZwzZf9haQRq; Mon, 9 Oct 2017 17:01:36 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5183E120720; Mon, 9 Oct 2017 17:01:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3938; q=dns/txt; s=iport; t=1507593696; x=1508803296; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=bOMMiPHyHXylwm8a6kZnUGRicHjn2sGVHtX7r5RqMZA=; b=RH9NPAR3HkGmapy4KBs4ZzBfNtRy7wDHoR35eZEL9eV1pX0rfETkDe1z YPfKBwln/feXsbCKZ9sgnf8Mck9rYFLyoVajFIXgxh2y0PivpgIw15HDv nisUXHPqvJvfRtbI1njpk4wiAUboEROFCgG8AUGW5bbXFrn6OKOL6RhnJ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D7AQAyDdxZ/5RdJa1chHFuJweDc7I4g?= =?us-ascii?q?hIKhTsCGoQgPxgDAQEBAQEBAWsohRkBBSMRRQULAgEIGAICKgIwFRACBA4FijA?= =?us-ascii?q?Qp26CJ4tUBYEOgh+CAoFRghULgj41iEaCMgWhNQKHXI0JghSFb4N+hwqVLQIRG?= =?us-ascii?q?QGBOAEfOIEOeBVbAYcKd4VELIEFgRABAQE?= X-IronPort-AV: E=Sophos;i="5.42,502,1500940800"; d="scan'208";a="308667405" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Oct 2017 00:00:31 +0000 Received: from XCH-RTP-016.cisco.com (xch-rtp-016.cisco.com [64.101.220.156]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v9A00Uut002350 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 10 Oct 2017 00:00:31 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-016.cisco.com (64.101.220.156) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 9 Oct 2017 20:00:30 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1320.000; Mon, 9 Oct 2017 20:00:30 -0400 From: "Carlos Pignataro (cpignata)" To: Stephen Farrell CC: "secdir@ietf.org" , mpls , "draft-ietf-mpls-spring-lsp-ping.all@ietf.org" , "ietf@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-mpls-spring-lsp-ping-11 Thread-Index: AQHTPrBSI1p/j3GTGEeyOcbEmYYd56LcezoA Date: Tue, 10 Oct 2017 00:00:30 +0000 Message-ID: References: <150730050726.13161.17866745423154681018@ietfa.amsl.com> In-Reply-To: <150730050726.13161.17866745423154681018@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.116.133] Content-Type: text/plain; charset="utf-8" Content-ID: <8E1A4A5A8D42104184186D31E8743A2A@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-mpls-spring-lsp-ping-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 00:01:38 -0000 SGksIFN0ZXBoZW4sDQoNClRoYW5rcyBmb3IgdGhlIHJldmlldywgcGxlYXNlIHNlZSBpbmxpbmUu DQoNCj4gT24gT2N0IDYsIDIwMTcsIGF0IDEwOjM1IEFNLCBTdGVwaGVuIEZhcnJlbGwgPHN0ZXBo ZW4uZmFycmVsbEBjcy50Y2QuaWU+IHdyb3RlOg0KPiANCj4gUmV2aWV3ZXI6IFN0ZXBoZW4gRmFy cmVsbA0KPiBSZXZpZXcgcmVzdWx0OiBSZWFkeQ0KPiANCg0KVGhhbmtzIQ0KDQo+IA0KPiBIaXlh LA0KPiANCj4gVGhlIGRvY3VtZW50IGRlc2NyaWJlcyB5ZXQgYW5vdGhlciB2YXJpYW50IG9mIHBp bmcgYW5kIHRyYWNlcm91dGUgZm9yIA0KPiBNUExTLCB3aGljaCBpcyBmaW5lLiBUaGUgc2VjdXJp dHkgY29uc2lkZXJhdGlvbnMgdGV4dCBpcyBwcm9iYWJseSByaWdodA0KPiBpbiBzYXlpbmcgdGhl cmUncyBubyBiaWcgZGVsdGEgaGVyZSB2cy4gUkZDIDgwMjkuDQo+IA0KPiBJIGRvIGhhdmUgb25l IHF1ZXJ5Og0KPiANCj4gVGhlICJwcm90b2NvbCIgZmllbGQgaW4gdGhlIHJlcXVlc3RzIGhlcmUg c2VlbXMgbGlrZSBpdCdzIG1heWJlIGEgbmV3DQo+IHRoaW5nLCB0aGF0IHdhc24ndCBpbiA4MDI5 IChvciBhdCBsZWFzdCB3YXNuJ3QgY2xlYXJseSB0aGVyZSBmcm9tIG15DQo+IGZhaXJseSB1bmlu Zm9ybWVkIHJlYWQ6LSkuDQoNClRoZSBpZGVhIG9mIHRoZSDigJxQcm90b2NvbOKAnSBmaWVsZCBl eGlzdHMgZnJvbSBSRkMgODAyOSwgYm90aCBpbXBsaWNpdGx5IGFuZCBleHBsaWNpdGx5Lg0KDQpG aXJzdCwgYXMgcGFydCBvZiB0aGUgRG93bnN0cmVhbSBpbmZvcm1hdGlvbiBhcyBwZXI6DQpodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjODAyOSNzZWN0aW9uLTMuNC4xLjINCg0KVGhhdCBp biB0dXJuIGdldHMgdXBkYXRlZCBieSB0aGlzIHdpdGggT1NQRiBhbmQgSVNJUzoNCmh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1wbHMtc3ByaW5nLWxzcC1waW5nLTExI3Nl Y3Rpb24tNg0KDQpTZWNvbmQsIHdpdGhpbiBhIHJlcXVlc3QsIGl0IGlzIGltcGxpZWQgaW4gdGhl IHR5cGUgb2YgVGFyZ2V0IEZFQyBTdGFjayAoVEZTKSDigJQgc2VlIHRoZSBUYWJsZSBvZiBDb250 ZW50cyBvZiBSRkMgODAyOSwgU2VjdGlvbnMgMy4yLlggKExEUCwgUlNWUCwgQkdQLCBldGMuKQ0K DQpUaGlzIHNwZWMgYWRkcyBURlNlcyB0aGF0IGFsbG93IGRpZmZlcmVudCBwcm90b2NvbHMsIHNv IGl0IGlzIGV4cGxpY2l0bHkgbm93IGFzIGVpdGhlciBPU1BGIG9yIElTSVMuIFRoZSBhbHRlcm5h dGl2ZSB3YXMgdG8gc2VwYXJhdGUgdGhlc2UgaW50byB0d28gVEZTZXMgYW5kIGhhdmUgdGhlIHBy b3RvY29sIGFzIGltcGxpY2l0LCBidXQgc2luY2UgdGhlIGFyZSBtdXR1YWxseSBleGNsdXNpdmUg YW5kIGRpc3RyaWJ1dGUgdGhlIHNhbWUgVEZTIGluZm8sIGl0IG1ha2VzIG1vcmUgc2Vuc2UgdG8g dXNlIGEgc2luZ2xlIFRGUyB3aXRoIGEgcHJvdG9jb2wgZmllbGQuDQpodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1tcGxzLXNwcmluZy1sc3AtcGluZy0xMSNzZWN0aW9uLTUu MQ0KDQpTby4uLg0KDQo+IFRoYXQncyBkZWZpbmVkIGFzOg0KPiANCj4gICAgICBTZXQgdG8gMSwg aWYgdGhlIFJlc3BvbmRlciBNVVNUIHBlcmZvcm0gRkVDIHZhbGlkYXRpb24gdXNpbmcgT1NQRg0K PiAgICAgIGFzIElHUCBwcm90b2NvbC4gIFNldCB0byAyLCBpZiB0aGUgUmVzcG9uZGVyIE1VU1Qg cGVyZm9ybSBFZ3Jlc3MNCj4gICAgICBGRUMgdmFsaWRhdGlvbiB1c2luZyBJU0lTIGFzIElHUCBw cm90b2NvbC4NCj4gDQo+IEkgZG9uJ3Qga25vdyB3aGF0J3MgcmVxdWlyZWQgZm9yIHRob3NlIHZh bGlkYXRpb24gc3RlcHMsIG5vciBpZiB0aGVyZSdzIA0KPiBhbnkgY2hhbmNlIHRoYXQgZG9pbmcg c3VjaCB2YWxpZGF0aW9uIGNvdWxkIGZvcm0gYSBuZXcgRG9TIHZlY3RvciwNCg0KVGhpcyBpcyB1 c2VkIG9ubHkgdG8gdmFsaWRhdGUgdGhhdCB0aGUgRkVDIHdhcyBhZHZlcnRpc2VkIGJ5IHRoYXQg cHJvdG9jb2wsIHNhbWUgYXMgcHJldmlvdXMgVEZTZXMgYnkgTERQIG9yIEJHUCBvciBSU1ZQLg0K DQo+IG9yIGlmIGl0IGNvdWxkIChpbnRlcmVzdGluZ2x5KSBhZmZlY3QgdGhlIGludGVycHJldGF0 aW9uIG9mIHRoZSBpbmZvcm1hdGlvbiANCj4gaW4gdGhlIHJlc3BvbnNlcyAoc2F5IGlmIHZhbGlk YXRpb24gY2FuIGFmZmVjdCByZXNwb25zZSB0aW1pbmcgaW4gc29tZQ0KPiB3ZWlyZCB3YXkpLA0K DQpOb3BlLCBpdCBkb2VzIG5vdCwgYXMgcGVyIGRldGFpbGVkIGV4cGxhbmF0aW9uIGFib3ZlLg0K DQo+IHNvIHRoaXMgaXMganVzdCB0byBjaGVjayBpZiB0aGVyZSdzIGFueXRoaW5nIG1vcmUgdG8g YmUgc2FpZA0KPiBhYm91dCB0aGF0LiBJIGFzc3VtZSB0aGUgYXV0aG9ycycgYW5zd2VyIHdpbGwg YmUgdGhhdCBpbXBsZW1lbnRlcnMNCj4gb2YgdGhpcyB3aWxsIGtub3cgd2hhdCB2YWxpZGF0aW9u IG1lYW5zIGhlcmUsIHRoYXQgaXQncyBubyBiaWcgZGVhbCBhcw0KPiBhIERvUyB2ZWN0b3IgYW5k IHRoYXQgdGhlIHRpbWluZyBlZmZlY3RzIGFyZSBub3QgYSBwcm9ibGVtLg0KDQpUaGF0IGlzIGNv cnJlY3QuIEJ1dCB3ZSBkbyBub3Qgb25seSBzYXkg4oCcbm8gYmlnZ2llLCB3ZSBrbm93IHdoYXQg aXQgbWVhbnPigJ0sIEkgYW0gZGV0YWlsaW5nIHRoZSByZWFzb25zIHdoeSB0aGlzIGlzIHNvLg0K DQo+IElmIHNvLA0KPiB0aGF0J3MgcHJvYmFibHkgZmluZSwgYnV0IGl0IG1pZ2h0IGJlIGdvb2Qg dG8gdmVyaWZ5IHRoYXQuDQo+IA0KDQpIb3BlZnVsbHksIHZlcmlmaWVkLg0KDQpUaGFua3MgYWdh aW4sIFN0ZXBoZW4gZm9yIHRoZSBzZWN1cml0eSByZXZpZXcuDQoNCuKAlCBDYXJsb3MuDQoNCj4g Q2hlZXJzLA0KPiBTLg0KPiANCj4gDQoNCg== From nobody Mon Oct 9 19:46:41 2017 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 5F7C113431D for ; Mon, 9 Oct 2017 19:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 x9PYYMxbKPab for ; Mon, 9 Oct 2017 19:46:36 -0700 (PDT) Received: from sonic304-37.consmr.mail.gq1.yahoo.com (sonic304-37.consmr.mail.gq1.yahoo.com [98.137.68.218]) (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 9DB4A132153 for ; Mon, 9 Oct 2017 19:46:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1507603596; bh=W1Wu5J2041JGpgRN/jql1WFvLa122yoCA88p29N0gBg=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=s4RH5+CfFvykayHr0xvB+UZDs5THHWgETs2DdelxfydgC6V3t/GcNL8jDrO9Cuz60l/tQFTAjbraPCe3ITLjErGKiTuIPWZ29wj18YL5hdKgriEAN++M2tYcqFDuZBvnKbY70ZPk6sQXzHyLSypCrt8/HRJEIVD6RgUeNs/32C/MDIw+f6/T3+R2oQN4hTny19TI05QbACbJwky+debJwZo4IMz5D1j1L3DTwh2H19l5H95O4BBrbchm4FI6tYLePjL31PtglEWFg4exrfdcOuul7h/K5IoLuoVODtjjiiBqjlBzvxObzsV2EJSjBdeYArtRfC3gwIlZVQYp6eBaMg== X-YMail-OSG: vHNQ5IAVM1lK7xx1pi5aNQeFFDVzhgAqKHxRgkVshYgQJW78ePnctynOFHlxgwM yfjZP.erK.QCGkUyzBwfVuRdkQsOTgqLLsAincG8Bcxi_8GYhw7mO8kKafYP.HzLJe54c7.fUJRU ZC13ZSGi9qzrT5VAmXbnv76E2c95c2UCfao2H7X79VzzU6pMxS0INdbLj33wJH6t4wIKmLkBMxSK UMDysYzsJqnoZVw1zL1bAWt2.x8WhaTg1qYAV9.3JNhffqxLG0UNwYqRMhlp427yH9dKDScFJndm sdFtptVW3M235MnFaM0hpvpzgme1kLZ2LHMPtmtCC.I3EahoTDD1H0v9UhEPsoHf7ixhX1FYTomv PkIboVSc7wHV4q_rHjWVc4.thgWyta4lCyLn3TJKip2UXPoFskZCSOX5ebo9mRn2dt_.nuWAoEnx U65xzehm_4wjfiDaYmukzlu557pVB4juFY8YbLvKNKl7HDX6b1hq1SLcG8Rdb3TPAB.zsO7xiyMB T7WqVQ5LB_rJGu_k- Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Tue, 10 Oct 2017 02:46:36 +0000 Received: from [127.0.0.1] by smtp114.sbc.mail.ne1.yahoo.com with NNFMP; 10 Oct 2017 02:46:32 -0000 X-Yahoo-Newman-Id: 24816.31996.bm@smtp114.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: vHNQ5IAVM1lK7xx1pi5aNQeFFDVzhgAqKHxRgkVshYgQJW7 8ePnctynOFHlxgwMyfjZP.erK.QCGkUyzBwfVuRdkQsOTgqLLsAincG8Bcxi _8GYhw7mO8kKafYP.HzLJe54c7.fUJRUZC13ZSGi9qzrT5VAmXbnv76E2c95 c2UCfao2H7X79VzzU6pMxS0INdbLj33wJH6t4wIKmLkBMxSKUMDysYzsJqno ZVw1zL1bAWt2.x8WhaTg1qYAV9.3JNhffqxLG0UNwYqRMhlp427yH9dKDScF JndmsdFtptVW3M235MnFaM0hpvpzgme1kLZ2LHMPtmtCC.I3EahoTDD1H0v9 UhEPsoHf7ixhX1FYTomvPkIboVSc7wHV4q_rHjWVc4.thgWyta4lCyLn3TJK ip2UXPoFskZCSOX5ebo9mRn2dt_.nuWAoEnxU65xzehm_4wjfiDaYmukzlu5 57pVB4juFY8YbLvKNKl7HDX6b1hq1SLcG8Rdb3TPAB.zsO7xiyMBT7WqVQ5L B_rJGu_k- X-Yahoo-SMTP: 4kJJK.qswBDPuwyc5wW.BPAQqNXdy5j09UNyeAS0pyOQ708- Received: from [192.168.1.152] (DD-WRT [192.168.1.1]) by uriel.mandelberg.org (Postfix) with ESMTPSA id CA0A31C608F; Mon, 9 Oct 2017 22:46:30 -0400 (EDT) To: bruno.decraene@orange.com Cc: "draft-ietf-ospf-encapsulation-cap.all@ietf.org" , "secdir@ietf.org" , "Acee Lindem (acee)" , Alia Atlas References: <475c78dc-c872-8795-2d99-81b28df97aed@mandelberg.org> <2597_1505460712_59BB81E8_2597_399_1_53C29892C857584299CBF5D05346208A4787384B@OPEXCLILM21.corporate.adroot.infra.ftgroup> <656e7eb8-1bbe-5f9c-e3b6-f0bbc23737db@mandelberg.org> <12465_1505725711_59BF8D0F_12465_296_1_53C29892C857584299CBF5D05346208A478787B1@OPEXCLILM21.corporate.adroot.infra.ftgroup> <5ee2e3cf-4034-f9e6-4fca-92ceb57a65c5@mandelberg.org> <11040_1505805523_59C0C4D3_11040_226_4_53C29892C857584299CBF5D05346208A4787AC94@OPEXCLILM21.corporate.adroot.infra.ftgroup> <27250_1505808909_59C0D20D_27250_468_2_53C29892C857584299CBF5D05346208A4787AEEC@OPEXCLILM21.corporate.adroot.infra.ftgroup> <14732_1507564419_59DB9B83_14732_456_1_53C29892C857584299CBF5D05346208A478A7539@OPEXCLILM21.corporate.adroot.infra.ftgroup> From: David Mandelberg Message-ID: Date: Mon, 9 Oct 2017 22:46:28 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <14732_1507564419_59DB9B83_14732_456_1_53C29892C857584299CBF5D05346208A478A7539@OPEXCLILM21.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-ospf-encapsulation-cap-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 02:46:39 -0000 Thanks for checking, that looks good. On 10/09/2017 11:53 AM, bruno.decraene@orange.com wrote: > [removing the iesg to limit spamming, adding Alia (responsible AD)] >=20 > Hi David, >=20 > Sorry to come back on this draft 3 weeks after our latest email, but a=20 > late comment is likely to change a sentence in the draft. >=20 > As we had discussed that sentence during your secdir review, I feel tha= t=20 > it would be honest to come back to you to report that change, even if I= =20 > don=E2=80=99t feel the change is problematic. >=20 > Proposed 2 changes are the following: >=20 > =C2=A7 Operation >=20 > OLD: >=20 > A tunnel MUST NOT be used if there is no route toward the IP address=20 > specified in the Endpoint Sub-TLV (See ) >=20 > or if the route is not advertised by the router advertising this Tunnel= =20 > Sub-TLV. >=20 > NEW: >=20 > A tunnel MUST NOT be used if there is no route toward the IP address=20 > specified in the Endpoint Sub-TLV (See ) >=20 > or if the route is not advertised in the same OSPF domain. >=20 > =3D=3D >=20 > The reason is that in multi-area OSPF deployments, the Tunnel Sub-TLV=20 > may be flooded domain-wide while the IP prefix may not. Hence both=20 > advertisements would not come from the same router. >=20 > =3D=3D >=20 > =C2=A7security >=20 > OLD:=C2=A0 It prohibits a destination outside of the OSPF domain and al= so to=20 > other routers within the domain. >=20 > NEW: It prohibits a destination outside of the OSPF domain. >=20 > =3D=3D=3D >=20 > As a consequence, this slightly increases the capabilities and hence th= e=20 > security implications. However, this still restricts the use of tunnel=20 > whose destination is within the OSPF domain (i.e. not Internet wide)=20 > which was your original concern. Plus IMO, assuming that an attacker ca= n=20 > control the OSPF advertisement is already a significant assumption. >=20 > =3D=3D=3D >=20 > Bottom line, I believe the change is quite small from a security=20 > standpoint, but wanted to double check with you. >=20 > Thanks, >=20 > Best regards, >=20 > --Bruno >=20 >> -----Original Message----- >=20 > > From: David Mandelberg [mailto:david@mandelberg.org] >=20 > > Sent: Tuesday, September 19, 2017 6:24 PM >=20 > > To: Acee Lindem (acee); DECRAENE Bruno IMT/OLN; Robert Raszuk >=20 > > Cc: iesg@ietf.org; draft-ietf-ospf-encapsulation-cap.all@ietf.org;=20 > secdir@ietf.org >=20 > > Subject: Re: secdir review of draft-ietf-ospf-encapsulation-cap-06 >=20 > > >=20 > =C2=A0> Looks good to me too. >=20 > > >=20 > =C2=A0> On 09/19/2017 07:01 AM, Acee Lindem (acee) wrote: >=20 > > > Hi Bruno, Robert, >=20 > > > >=20 > > > Sounds good to me. One nit =E2=80=93 replace =E2=80=9Ce.g. =E2=80=9C= with =E2=80=9C, e.g., =E2=80=9C in the >=20 > > > added text. >=20 > > > Thanks, >=20 > > > Acee >=20 > > > >=20 > > > From: Bruno Decraene =20 > > > > >=20 > > > Date: Tuesday, September 19, 2017 at 4:15 AM >=20 > > > To: Robert Raszuk >> >=20 > > > Cc: The IESG >>, David Mandelberg >=20 > > > >>, >=20 > > > "draft-ietf-ospf-encapsulation-cap.all@ietf.org >=20 > > > " >=20 > > > =20 > > > >, >=20 > > > "secdir@ietf.org =20 > " =20 > > > > >=20 > > > Subject: RE: secdir review of draft-ietf-ospf-encapsulation-cap-06 >=20 > > > Resent-From: >> >=20 > > > Resent-To: Xiaohu Xu >>, >=20 > > > Bruno Decraene =20 > > > >, Robert Raszuk =20 > > > >, Luis Contreras >=20 > > > =20 > > > >, Luay Jalil >=20 > > > >>,=20 > Acee Lindem >=20 > > > >>, =20 > > > >, >>, >=20 > > > Deborah Brungard >>, Alia Atlas >=20 > > > >>, Acee Lindem >=20 > > > >> >=20 > > > Resent-Date: Tuesday, September 19, 2017 at 4:15 AM >=20 > > > >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0 *From:*rraszuk@gmail.com >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0 [mailto:rraszuk@gmail.com] *On Behalf Of *= Robert Raszuk >=20 > > > >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0 Please replace AS with Administrative Doma= in. >=20 > > > >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0 [Bruno] I replaced AS with =E2=80=9COSPF d= omain=E2=80=9D as indeed, AS is a BGP=20 > term >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0 rather than an OSPF one. And as you note, = in some cases, the AS and >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0 the IGP domain may be different. Thanks. >=20 > > > >=20 > > > =C2=A0=C2=A0=C2=A0=C2=A0If I have three ASes there should be no ar= tificial limits >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0 prohibiting encap to my central collector. >=20 > > > >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0 [Bruno] >=20 > > > >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0 If your central collector is part of the O= SPF domain of the >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0 encapsulator, there is no problem. >=20 > > > >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0 Otherwise, if the route to your central co= llector is advertised in >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0 OSPF by the decapsulator, there is no prob= lem. >=20 > > > >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0 Otherwise, if the route to your central co= llector is advertised in >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0 BGP, then draft-ietf-idr-tunnel-encaps is = probably the right tool. >=20 > > > >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0 --Bruno >=20 > > > >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0 Thx >=20 > > > >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0 R >=20 > > > >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0 On Sep 19, 2017 08:18, =20 > > >=C2=A0=C2=A0=C2=A0=C2=A0 > wrote: >=20 > > > >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0 > From: David Mandelberg [mailto:david@man= delberg.org=20 > =20 > ] >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Sent: Monday, September 18, = 2017 9:30 PM >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0 > >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > On 09/18/2017 05:08 AM, brun= o.decraene@orange.com=20 > >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0 wrote: >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0=C2=A0 > (c) is the o= ne that I think is worth looking into. E.g., >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0 does this new >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0=C2=A0 > extension ma= ke it easier for an attacker to route a=20 > packet >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0 across AS >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0=C2=A0 > boundaries, = by setting a tunnel endpoint outside of the >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0 OSPF-routed network? >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > No. The following text alr= eady prohibits even more than this: >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > "=C2=A0 A tunnel MUST NOT = be >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 used if there is no route toward the IP address >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0 specified in the >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 Endpoint Sub-TLV (See ) or >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0 if the route is >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 not advertised by the router advertising this Tunnel >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0 Sub-TLV." >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > - By definition, this Tunn= el Sub-TLV is advertised in OSPF >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0 i.e. from within the AS. >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > - The text also prohibits = setting a tunnel endpoint to=20 > another >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0 router within the AS. >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > That being said, within th= e AS, the point "c" still applies. >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > However, thinking twice, t= he probability is even more=20 > limited. >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0 Indeed, one can only advertise a >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > tunnel to itself. Assuming t= hat the third party can't control >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0 the whole routing topology (i.e. routing >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > advertisement from most core= routers), it cannot control the >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0 path followed by the tunnel. Hence it >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > would need to have monitorin= g capabilities on specific links >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0 that it cannot choose. (the link on >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > the path to itself). >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > Plus this risk is not new,= as the third party could already >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0 advertise the destination IP address of >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > the packets (or of the BGP N= ext-hop of the BGP route matching >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0 the packet destination), without >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > using any tunnel. >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > In conclusion, although I = could be wrong, I'm not seeing such >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0 new risk. (again, assuming that >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > a third party can modify the= OSPF routing is a big assumption). >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > But the discussion was use= ful, thanks for the comments. >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > That explanation is great, t= hank you. I hadn't realized the >=20 > > >=C2=A0=C2=A0 =C2=A0=C2=A0implications >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > of the paragraph you quoted,= when I initially read it. I'm=20 > convinced >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > that there isn't a security = issue here, but it would be nice to >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0 see your >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > explanation in the document = itself, if it's not already=20 > obvious to >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > anybody who knows OSPF bette= r than I do. >=20 > > > >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0 I've just added the following text in the = security section of my >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0 local version: >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0 "We note that the last paragraph of >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0 forbid the establishment of a tunnel towar= d arbitrary destinations. >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0 It prohibits a destination outside of the = Autonomous System and=20 > also >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0 to other routers within the AS. This avoid= that a third-party >=20 > > >=C2=A0 =C2=A0=C2=A0=C2=A0gaining access to an OSPF router be able t= o send the traffic to >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0 other destinations, for e.g. inspection pu= rposes. " >=20 > > > >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0 Feel free to comment/propose other text. >=20 > > > >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0 Since I've just published -08 a few hours = ago, I'll probably delay >=20 > > >=C2=A0=C2=A0=C2=A0 =C2=A0the upload of this new update. >=20 > > > >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0 --Bruno >=20 > > > >=20 > > > >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > -- >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Freelance cyber security con= sultant, software developer,=20 > and more >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > https://david.mandelberg.org= / >=20 > > > >=20 > > > >=20 > >=20 > _______________________________________________________________________= ______ >=20 > > ____________________________________________ >=20 > > > >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0 Ce message et ses pieces jointes peuvent c= ontenir des informations >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0 confidentielles ou privilegiees et ne doiv= ent donc >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0 pas etre diffuses, exploites ou copies san= s autorisation. Si vous >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0 avez recu ce message par erreur, veuillez = le signaler >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0 a l'expediteur et le detruire ainsi que le= s pieces jointes. Les >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0 messages electroniques etant susceptibles = d'alteration, >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0 Orange decline toute responsabilite si ce = message a ete altere, >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0 deforme ou falsifie. Merci. >=20 > > > >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0 This message and its attachments may conta= in confidential or >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0 privileged information that may be protect= ed by law; >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0 they should not be distributed, used or co= pied without=20 > authorisation. >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0 If you have received this email in error, = please notify the sender >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0 and delete this message and its attachment= s. >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0 As emails may be altered, Orange is not li= able for messages that >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0 have been modified, changed or falsified. >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0 Thank you. >=20 > > > >=20 > > > >=20 > >=20 > _______________________________________________________________________= ______ >=20 > > ____________________________________________ >=20 > > > >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0 Ce message et ses pieces jointes peuvent c= ontenir des=20 > informations confidentielles ou >=20 > > privilegiees et ne doivent donc >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0 pas etre diffuses, exploites ou copies san= s autorisation. Si=20 > vous avez recu ce message par >=20 > > erreur, veuillez le signaler >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0 a l'expediteur et le detruire ainsi que le= s pieces jointes. Les=20 > messages electroniques etant >=20 > > susceptibles d'alteration, >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0 Orange decline toute responsabilite si ce = message a ete altere,=20 > deforme ou falsifie. Merci. >=20 > > > >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0 This message and its attachments may conta= in confidential or=20 > privileged information that >=20 > > may be protected by law; >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0 they should not be distributed, used or co= pied without=20 > authorisation. >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0 If you have received this email in error, = please notify the=20 > sender and delete this message and >=20 > > its attachments. >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0 As emails may be altered, Orange is not li= able for messages=20 > that have been modified, >=20 > > changed or falsified. >=20 > > >=C2=A0=C2=A0=C2=A0=C2=A0 Thank you. >=20 > > > >=20 > > >=20 > =C2=A0> >=20 > =C2=A0> -- >=20 > > Freelance cyber security consultant, software developer, and more >=20 > > https://david.mandelberg.org/ >=20 > _______________________________________________________________________= __________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations conf= identielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les message= s electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme= ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged= information 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 = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have b= een modified, changed or falsified. > Thank you. >=20 --=20 Freelance cyber security consultant, software developer, and more https://david.mandelberg.org/ From nobody Tue Oct 10 07:58:51 2017 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 89CB5134E3C; Tue, 10 Oct 2017 07:58:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Takeshi Takahashi To: Cc: draft-ietf-lisp-sec.all@ietf.org, ietf@ietf.org, lisp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150764751351.13466.15119625109787574982@ietfa.amsl.com> Date: Tue, 10 Oct 2017 07:58:33 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-lisp-sec-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 14:58:34 -0000 Reviewer: Takeshi Takahashi 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. I would say this document is ready with nits, but the nits are very minor. [comments that require chages to the current draft] 1. I guess the authors mix up "reply" and "replay" in Section 6.6. "Reply attacks" could be "Replay attacks". [comments that does not necessarily require changes to the current draft] 2. The security aspect of LISP is addressed not only in this draft but also in RFC6830 and in RFC7835. If I understood correctly, LISP-SEC addressed a part of the threats mentioned in RFC7835. Then, it would be nice if the authors could clarify what types of further threats that are not mentioned in LISP-SEC still exist by referring to RFC6830 and RFC7835. 3. DOS/DDoS was mentioned in the introduction section, but it was not discussed in the later sections. It would be nice if the authors could address DoS/DDoS issues as well. From nobody Tue Oct 10 08:32:28 2017 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 1AA71135278; Tue, 10 Oct 2017 08:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 aP2WkK1jlvYh; Tue, 10 Oct 2017 08:32:18 -0700 (PDT) Received: from relais-inet.orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B31C135182; Tue, 10 Oct 2017 08:19:43 -0700 (PDT) Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id D13136066B; Tue, 10 Oct 2017 17:19:41 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.61]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id AFDA040064; Tue, 10 Oct 2017 17:19:41 +0200 (CEST) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM7E.corporate.adroot.infra.ftgroup ([fe80::b91c:ea2c:ac8a:7462%19]) with mapi id 14.03.0361.001; Tue, 10 Oct 2017 17:19:41 +0200 From: To: Melinda Shore , "secdir@ietf.org" CC: "draft-ietf-rtgwg-uloop-delay.all@ietf.org" , "ietf@ietf.org" , "rtgwg@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-rtgwg-uloop-delay-06 Thread-Index: AQHTPV1VzX8aY9/LTUuBhYq0tjqJGaLdO3xA Date: Tue, 10 Oct 2017 15:19:40 +0000 Message-ID: <16282_1507648781_59DCE50D_16282_164_1_9E32478DFA9976438E7A22F69B08FF921EA860EE@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: <150715491656.6673.6134344241640965386@ietfa.amsl.com> In-Reply-To: <150715491656.6673.6134344241640965386@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-rtgwg-uloop-delay-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 15:32:20 -0000 SGksDQoNClRoYW5rcyBmb3IgeW91ciByZXZpZXcuDQpUaGUgdjA3IEkganVzdCBwb3N0ZWQgYWRk cmVzc2VzIHlvdXIgY29tbWVudHMuDQoNCkJyZ2RzLA0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQpGcm9tOiBNZWxpbmRhIFNob3JlIFttYWlsdG86bWVsaW5kYS5zaG9yZUBnbWFpbC5j b21dIA0KU2VudDogVGh1cnNkYXksIE9jdG9iZXIgMDUsIDIwMTcgMDA6MDkNClRvOiBzZWNkaXJA aWV0Zi5vcmcNCkNjOiBkcmFmdC1pZXRmLXJ0Z3dnLXVsb29wLWRlbGF5LmFsbEBpZXRmLm9yZzsg aWV0ZkBpZXRmLm9yZzsgcnRnd2dAaWV0Zi5vcmcNClN1YmplY3Q6IFNlY2RpciBsYXN0IGNhbGwg cmV2aWV3IG9mIGRyYWZ0LWlldGYtcnRnd2ctdWxvb3AtZGVsYXktMDYNCg0KUmV2aWV3ZXI6IE1l bGluZGEgU2hvcmUNClJldmlldyByZXN1bHQ6IEhhcyBOaXRzDQoNClRoaXMgZG9jdW1lbnQgZGVz Y3JpYmVzIGEgbWVjaGFuaXNtIHRvIG1pdGlnYXRlIGFnYWluc3QgZmFpbHVyZXMgc3RlbW1pbmcg ZnJvbSB0aGUgZm9ybWF0aW9uIG9mICJtaWNyb2xvb3BzIiBkdXJpbmcgYSByZS1yb3V0aW5nIGNv bnZlcmdlbmNlLCBhcyBkZXNjcmliZWQgaW4gUkZDIDU3MTUuICBNb2R1bG8gc29tZSBtZWNoYW5p Y2FsIHByb2JsZW1zIHdpdGggbGFuZ3VhZ2UgdXNhZ2UgKGkuZS4NCmdyYW1tYXRpY2FsIGVycm9y cykgYW5kIHNvbWUgbWlzc2luZyBkZWZpbml0aW9ucywgdGhlIGRvY3VtZW50IGNsZWFybHkgZGVz Y3JpYmVzIHRoZSBwcm9ibGVtIGl0IGlzIGFkZHJlc3NpbmcgYW5kIHRoZSBwcm9wb3NlZCBzb2x1 dGlvbi4NCg0KVGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHNlY3Rpb24gaXMgdmVyeSBjbGVh ciBhYm91dCB3aHkgdGhlIGF1dGhvcnMgYmVsaWV2ZSBubyBuZXcgYXR0YWNrcyBhcmUgaW50cm9k dWNlZCBieSB0aGlzIG1lY2hhbmlzbSwgYW5kIGl0IGlzIGNyZWRpYmxlDQoNClNlY3Rpb25zIDQg YW5kIDUgcmVwcmVzZW50IHRoZSBjb3JlIG9mIHRoZSBkb2N1bWVudCBhbmQgYXJlIHZlcnkgY2xl YXIgLSBhIHZlcnkgbmljZSBwaWVjZSBvZiBzcGVjaWZpY2F0aW9uLg0KDQpJdCB3b3VsZCBiZSBo ZWxwZnVsIHRvIGhhdmUgYSB0ZXJtaW5vbG9neSBzZWN0aW9uLCBvciB0byBleHBhbmQgc29tZSBv ZiB0aGUgYWNyb255bXMgaW4tbGluZSAoTEZBLCBmb3IgZXhhbXBsZSkuDQoNCkZvciBzb21lIHJl YXNvbiB0aGUgZ3JhbW1hdGljYWwgZXJyb3JzIGFyZSBjbHVzdGVyZWQgdG93YXJkcyB0aGUgZnJv bnQgb2YgdGhlIGRvY3VtZW50IGJ1dCB0aGVyZSBhcmUgbWFueSBzY2F0dGVyZWQgdGhyb3VnaG91 dDoNCg0KU2VjdGlvbiAxLCBmaXJzdCBwYXJhZ3JhcGggc2luZ3VsYXIvcGx1cmFsIG1pc21hdGNo OiAiQmFzZWQgb24gbmV0d29yayBhbmFseXNpcywgbG9jYWwgZmFpbHVyZSBtYWtlIHVwIGEgc2ln bmlmaWNhbnQgcG9ydGlvbiBvZiB0aGUgbWljcm8tZm9yd2FyZGluZyBsb29wcyINCg0KU2VjdGlv biAxLCBzZWNvbmQgcGFyYWdyYXBoIHVuaWRpb21hdGljIHVzZSBvZiAidGhlIHRvcG9sb2d5Ig0K DQpTZWN0aW9uIDIsIGZpcnN0IHBhcmFncmFwaCB1bmlkaW9tYXRpYyB1c2Ugb2YgImhpZ2ggZGFt YWdlcyINCg0KU2VjdGlvbiAyLjEsIGZpcnN0IHBhcmFncmFwaCBuZWVkcyBhbiBhcnRpY2xlIG9u ICJJR1Agc2hvcnRjdXQiDQoNClNhbWUgcGFyYWdyYXBoLCBkb2Vzbid0IG5lZWQgYW4gYXJ0aWNs ZSBvbiAidGhlIHJvdXRlciBDIg0KDQpTYW1lIHBhcmFncmFwaCwgIm5leHRob3AiIHNob3VsZCBi ZSB0d28gd29yZHMNCg0KSXRlbSAxIGluIDIuMSwgbmVlZHMgYW4gYXJ0aWNsZSBiZWZvcmUgInBy ZXByb2dyYW1tZWQgRlJSIHBhdGgiLCBhbHNvIHJ1bi1vbiBzZW50ZW5jZSBuZWVkcyB0byBiZSBz cGxpdCBvciBhIGNvbmp1bmN0aW9uIGluc2VydGVkDQoNCkl0ZW0gMyBpbiAyLjEsICJubyBtb3Jl IiBzaG91bGQgYmUgIm5vIGxvbmdlciIsIGFuZCAiZW5jYXBzdWxhdGUgYW55bW9yZSINCnNob3Vs ZCBiZSAiZG9lcyBub3QgY29udGludWUgdG8gZW5jYXBzdWxhdGUiDQoNClNlY3Rpb24gMi4xLCBs YXN0IHBhcmFncmFwaDogIlRoZSBwcm90ZWN0aW9uIGVuYWJsZWQgYnkgZmFzdC1yZXJvdXRlIGlz IHdvcmtpbmcgcGVyZmVjdGx5LCBidXQgZW5zdXJlcyBhIHByb3RlY3Rpb24sIGJ5IGRlZmluaXRp b24sIG9ubHkgdW50aWwgdGhlIFBMUiBoYXMgY29udmVyZ2VkLiIgaXMgc29tZXdoYXQgdW5jbGVh cg0KDQpTZWN0aW9uIDMsIHRoaXJkIHBhcmFncmFwaDogZmlyc3QgY29tbWEgaXMgdW5uZWNlc3Nh cnkuICBBbHNvLCAibG9jYWwgb25seSINCnNob3VsZCBiZSAibG9jYWwtb25seSINCg0KU2VjdGlv biA4LjIsIGZpcnN0IHBhcmFncmFwaDogImFzc29jaWF0aW5nIHRpbWluZyIgc2hvdWxkIGJlICJh c3NvY2lhdGVkIHRpbWluZyIuDQoNCkFsc28gaW4gc2VjdGlvbiA4LjIsIHRoZSBtZXNzYWdlIGNo YXJ0IGhlYWRlciBpcyBzZXBhcmF0ZWQgZnJvbSB0aGUgYWN0dWFsIGNvbnRlbnRzIGJ5IGEgcGFn ZSBicmVhaywgYW5kIHRoYXQgc2hvdWxkIGJlIHJlbWVkaWVkDQoNClNlY3Rpb24gOC4zLCBmaXJz dCBwYXJhZ3JhcGg6ICJ0aGF0IGhhcHBlbnMiIHNob3VsZCBiZSAidGhhdCBoYXBwZW4iLiAgQWxz bywgIndpdGhvdXQgZnVydGhlciBkZWxheWluZyByb3V0ZSBpbnNlcnRpb24iIHdvdWxkIGJlIG1v cmUgaWRpb21hdGljIHRoYW4gIndpdGhvdXQgZGVsYXlpbmcgcm91dGUgaW5zZXJ0aW9uIGFueW1v cmUiDQoNClNlY3Rpb24gOS4xLCB0aHJvdWdob3V0OiAibmV4dGhvcCIgc2hvdWxkIGJlICJuZXh0 IGhvcCINCg0KU2VjdGlvbiA5LjEsIGZpcnN0IGJ1bGxldCBpdGVtOiAib25seSBoYXZlIG9uZSIg c2hvdWxkIGJlICJvbmx5IGhhcyBvbmUiIChvciAiaGFzIG9ubHkgb25lIikNCg0KU2VjdGlvbiAx MDogImEgZ29vZCBiZWhhdmlvciIgc2hvdWxkIGJlICJnb29kIGJlaGF2aW9yIg0KDQoKX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f XwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMg aW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVu dCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jp c2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6 IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMg cGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRp YmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNp IGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRo aXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBv ciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRo ZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRo b3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVh c2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRh Y2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBm b3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVk LgpUaGFuayB5b3UuCgo= From nobody Wed Oct 11 21:02:11 2017 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 D608E134322; Wed, 11 Oct 2017 21:02:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, 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 JDU114lBf0IQ; Wed, 11 Oct 2017 21:02:08 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (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 79995126DFE; Wed, 11 Oct 2017 21:02:08 -0700 (PDT) X-AuditID: 12074422-0f7ff70000007316-00-59dee93fb60d Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 3C.D0.29462.F39EED95; Thu, 12 Oct 2017 00:02:07 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id v9C426Uw006347; Thu, 12 Oct 2017 00:02:06 -0400 Received: from localhost (nyc-02.triskelion.com [162.243.175.178]) (authenticated bits=0) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v9C424Ic029873; Thu, 12 Oct 2017 00:02:05 -0400 From: Taylor Yu To: iesg@ietf.org, secdir@ietf.org, draft-ietf-lamps-rfc5280-i18n-update.all@ietf.org Date: Thu, 12 Oct 2017 04:02:04 +0000 Message-ID: Lines: 26 MIME-Version: 1.0 Content-Type: text/plain X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrEIsWRmVeSWpSXmKPExsUixCmqrWv/8l6kwb4ZChbzn99msZjxZyKz xYeFD1kcmD2WLPnJFMAYxWWTkpqTWZZapG+XwJVx7+UR5oIzHBX9706xNjC+Y+ti5OSQEDCR uPJsKmMXIxeHkMBiJomNF2axQDgbGSUmT5rFBOF8Y5SYt/kFexcjBwebgJzE5VvBIN0iAnES +1f3sYLYwgJ2Ejf3TWEHsVkEVCX2TO0Bs3kFbCQ6L/Ywg9g8ApwSL09uZISIC0qcnPmEBcRm FpCQOPjiBfMERp5ZSFKzkKQWMDKtYpRNya3SzU3MzClOTdYtTk7My0st0jXVy80s0UtNKd3E CAoYdhelHYwT/3kdYhTgYFTi4X2hdS9SiDWxrLgy9xCjJAeTkijvtXtAIb6k/JTKjMTijPii 0pzU4kOMEhzMSiK8/ruAcrwpiZVVqUX5MClpDhYlcd5tQbsihQTSE0tSs1NTC1KLYLIyHBxK ErwnnwM1ChalpqdWpGXmlCCkmTg4QYbzAA1/DlLDW1yQmFucmQ6RP8VozLHp5t0/TBwbvj/4 wyTEkpeflyolzlsEUioAUppRmgc3DRT1iz6v3/SKURzoOWGIgTzAhAE37xXQKiagVaJpd0BW lSQipKQaGCcYZrwvX51peLql91fQpmBe8fs5bqwX5v+ou5Ylk1o6/9eS6aEfF+xrj+u6tCM2 JGTHss6Om2bit2bEFD28090eczkoOuhPYMhh61Va+1JjXjdf9D7pnsVrsUT3+Ikj/1yb9Lrq Mi92tC3hOiW9oO3IKk7OR+y7T6x85BwhP+3sd/+zvndX7lBiKc5INNRiLipOBACAPJuV1QIA AA== Archived-At: Subject: [secdir] secdir review of draft-ietf-lamps-rfc5280-i18n-update X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Oct 2017 04:02:10 -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. The summary of the review is: Ready with Nits. This seems to be a useful incremental improvement to RFC 5280. The Security Considerations seem reasonable. The nits are minor and can likely be resolved as part of the RFC Editor process. Nits: * RFC3492 is listed as an Informative reference but section 2.3 (which modifies section 7.2 of RFC5280) is normative text that refers to it. (though not using an RFC2199 keyword) Arguably this might be OK because I think other normative references in this document transitively cite RFC3492. * RFC3629 is listed as an Informative reference but the new text in section 2.4 (which modifies section 7.5 of RFC5280) appears to refer to it normatively (about BOMs). Best regards, -Taylor From nobody Thu Oct 12 00:34:23 2017 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 03BDF133072 for ; Thu, 12 Oct 2017 00:34:22 -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] 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 p0ByBWsala6k for ; Thu, 12 Oct 2017 00:34:21 -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 F2355133052 for ; Thu, 12 Oct 2017 00:34:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 48E2A3005A6 for ; Thu, 12 Oct 2017 03:34:20 -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 zh257SWsVlAw for ; Thu, 12 Oct 2017 03:34:18 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id B538B3004BC; Thu, 12 Oct 2017 03:34:18 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: Date: Thu, 12 Oct 2017 03:34:17 -0400 Cc: IESG , IETF SecDir , draft-ietf-lamps-rfc5280-i18n-update.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Taylor Yu X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-lamps-rfc5280-i18n-update X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Oct 2017 07:34:22 -0000 Okay. Thanks for the review. I will move the references to the = normative list. Russ > On Oct 12, 2017, at 12:02 AM, Taylor Yu wrote: >=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 > The summary of the review is: Ready with Nits. >=20 > This seems to be a useful incremental improvement to RFC 5280. The > Security Considerations seem reasonable. The nits are minor and can > likely be resolved as part of the RFC Editor process. >=20 > Nits: >=20 > * RFC3492 is listed as an Informative reference but section 2.3 (which > modifies section 7.2 of RFC5280) is normative text that refers to it. > (though not using an RFC2199 keyword) Arguably this might be OK > because I think other normative references in this document > transitively cite RFC3492. >=20 > * RFC3629 is listed as an Informative reference but the new text in > section 2.4 (which modifies section 7.5 of RFC5280) appears to refer > to it normatively (about BOMs). >=20 > Best regards, > -Taylor From nobody Thu Oct 12 02:56:37 2017 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 97FA613445B for ; Thu, 12 Oct 2017 02:56:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Tero Kivinen To: X-Test-IDTracker: no X-IETF-IDTracker: 6.63.1 Auto-Submitted: auto-generated Precedence: bulk Reply-to: secdir-secretary@mit.edu Message-ID: <150780219661.16723.9415533921461774872.idtracker@ietfa.amsl.com> Date: Thu, 12 Oct 2017 02:56:36 -0700 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Oct 2017 09:56:37 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2017-10-12 Reviewer LC end Draft Watson Ladd R2017-06-06 draft-ietf-v6ops-unique-ipv6-prefix-per-host-12 Joseph Salowey R2017-10-11 draft-ietf-opsawg-service-model-explained-04 Tina Tsou 2017-10-03 draft-ietf-rtgwg-routing-types-16 For telechat 2017-10-26 Reviewer LC end Draft Derek Atkins 2017-10-16 draft-ietf-bier-mpls-encapsulation-09 Daniel Franke 2017-10-25 draft-ietf-i2nsf-framework-08 Ólafur Guðmundsson 2017-10-13 draft-ietf-uta-email-deep-09 Leif Johansson 2017-10-25 draft-ietf-netconf-rfc6536bis-06 Benjamin Kaduk 2017-10-25 draft-ietf-lime-yang-connectionless-oam-methods-09 Charlie Kaufman 2017-10-25 draft-ietf-lime-yang-connectionless-oam-11 Stephen Kent 2017-10-19 draft-ietf-tcpinc-tcpcrypt-07 Watson Ladd 2017-10-19 draft-ietf-tcpinc-tcpeno-10 Ben Laurie 2017-10-23 draft-ietf-rmcat-scream-cc-11 Tom Yu 2017-09-28 draft-ietf-ippm-alt-mark-12 Dacheng Zhang 2017-10-13 draft-ietf-mile-rolie-10 For telechat 2017-11-30 Reviewer LC end Draft John Bradley None draft-ietf-acme-acme-07 Alan DeKok 2017-10-09 draft-ietf-tsvwg-ieee-802-11-09 Scott Kelly 2017-10-24 draft-ietf-dhc-relay-port-06 Last calls: Reviewer LC end Draft Shaun Cooley 2017-10-11 draft-ietf-grow-bgp-gshut-11 Donald Eastlake 2017-10-09 draft-ietf-oauth-discovery-07 Shawn Emery 2017-10-09 draft-ietf-curdle-pkix-06 Daniel Gillmor 2017-10-17 draft-ietf-sidrops-bgpsec-rollover-02 Phillip Hallam-Baker 2017-10-13 draft-ietf-ospf-segment-routing-extensions-19 Dan Harkins 2017-10-12 draft-ietf-dnssd-hybrid-07 Tero Kivinen 2017-10-23 draft-schaad-curdle-oid-registry-02 Russ Mundy 2017-09-14 draft-spinosa-urn-lex-11 Tim Polk 2017-09-11 draft-ietf-kitten-rfc5653bis-05 Tom Yu 2017-02-20 draft-ietf-slim-negotiating-human-language-13 Early review requests: Reviewer Due Draft Daniel Gillmor 2016-02-01 draft-ietf-rtcweb-security-08 Christian Huitema 2017-10-18 draft-ietf-lwig-crypto-sensors-04 Next in the reviewer rotation: Barry Leiba Chris Lonvick David Mandelberg Catherine Meadows Alexey Melnikov Daniel Migault Matthew Miller Adam Montville Russ Mundy Sandra Murphy From nobody Thu Oct 12 09:55:55 2017 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 35CFC124F57 for ; Thu, 12 Oct 2017 09:55:49 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 afGaeciTqm1t for ; Thu, 12 Oct 2017 09:55:43 -0700 (PDT) Received: from omr-a008e.mx.aol.com (omr-a008e.mx.aol.com [204.29.186.51]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEDE513453E for ; Thu, 12 Oct 2017 09:55:42 -0700 (PDT) Received: from mtaout-mcc01.mx.aol.com (mtaout-mcc01.mx.aol.com [172.26.253.77]) by omr-a008e.mx.aol.com (Outbound Mail Relay) with ESMTP id A9C253800046; Thu, 12 Oct 2017 12:55:41 -0400 (EDT) Received: from iMac.fios-router.home (pool-173-48-69-73.bstnma.fios.verizon.net [173.48.69.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mtaout-mcc01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id B64B03800009A; Thu, 12 Oct 2017 12:55:40 -0400 (EDT) To: secdir@ietf.org, david.black@dell.com, krose@krose.org, ietf@kuehlewind.net From: Stephen Kent Cc: bittau@google.com, M.Handley@cs.ucl.ac.uk, dbg@scs.stanford.edu, dm@uun.org, eric.smith@kestrel.edu, sqs@sourcegraph.com Message-ID: Date: Thu, 12 Oct 2017 12:55:40 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------98C5D1EC086395F0BE510D0E" Content-Language: en-US x-aol-global-disposition: G x-aol-sid: 3039ac1afd4d59df9e8c14ed X-AOL-IP: 173.48.69.73 Archived-At: Subject: [secdir] SECDIR review of draft-ietf-t cpinc-tcpcrypt-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Oct 2017 16:55:49 -0000 This is a multi-part message in MIME format. --------------98C5D1EC086395F0BE510D0E Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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. This document is the specification for tcpcrypt, which is targeted to be an Experimental RFC. It is generally very well written, but it could benefit from a few edits, as noted below. The introduction (section 2) is brief and well written, stating the goals for the design. Section 3 is much longer, providing a detailed description of the protocol. (Although the description is characterized as “abstract” it is very detailed, with only format details deferred to Section 4.) This section also is generally well-written. In 3.2 I suggest including a forward pointer to the IANA Considerations section, since that section describes how future TEPs may be added to the list in Table 2. In 3.5 the text says: When two hosts have previously negotiated a tcpcrypt session, either host may initiate session resumption regardless of which host was the active opener or played the "A" role in the previous session. It’s not clear to me in what time frame this comment is meant to apply, e.g., if two hosts established a tcpcrypt session a week ago, is this comment still supposed to be applicable? Some clarification here would be useful. The end of this section establishes a requirement for an interface to enable an application to control session caching. Are interfaces of this sort commonly provided to applications by an OS? If so, an example would be useful; if not, the authors should acknowledge that this requirement may be problematic, i.e., applications may require modification to make use of the mandated interface. In 3.6 the mention Table 3 also should refer to IANA Considerations, since that section describes how additions algorithms may be added. The last sentence of 3.7 should be broken into several sentences; it is currently 7 lines long! Section 3.8 describes a fairly complicated set of constraintsassociated with rekeying, some of which are inter-related. It might help to have a table here to describe how these constraints interact, e.g., when TCP-mandated retransmission takes place in the context of a rekey. I suggest the following editorial changes in section 3: … assigns different roles to -> … assigns the roles to the two hosts … ephemeral public keys for hosts A and B -> … ephemeral public key agreement keys for hosts A and B … whose length depends -> … the length of which depends … whose integer value -> … the integer value of which … security of the AEAD algorithm -> … security of every AEAD algorithm Section 4 describes the byte-level encoding for the data structures described in Section 3, as part of the tcpcrypt specification. In 4.1 found the description of the “ignored” data the INIT1_ and INIT2_ messages to be a bit confusing. I had to reread the descriptions to figure out that this was the authors’ way of saying that data beyond the end of the message (as indicated by the message_len field) is to be ignored upon reception. I don’t think the graphics used here are a great way to explain this. Section 6 defines the initial set of AEAD algorithms supported by tcpcrypt, in Table 2. Each algorithm is assigned a value in the 1-255 range, a much smaller range of values that used in protocols like TLS. The text in Section 7 might need to remind readers that this will argue against the registration of “vanity” AEAD algorithms for tcpcrypt. Security Considerations are described in Section 8. I found the phrase “Most implementations will rely on system-wide pseudo-random generators…” to be a bit confusing, because the ambiguity of the word “system” here. I presume this really refers to a single device in mots cases, e.g., a laptop, desktop, smartphone, right? I suggest a reference to RFC 4086 might be a good substitute for much of the text at the beginning of this section. I’d like the authors to provide a rationale for the advice: “…limit the lifetime of the private parameters, ideally to no more than two minutes.” This seems a bit arbitrary to me. Suggested editorial changes to Section 8: … is one on which -> is one for which … without guessing the content of the resumption identifier, -> without successfully guessing the value of the resumption identifier, Thus, tcpcrypt specifies a way … -> To counter this threat, tcpcrypt specifies a way … --------------98C5D1EC086395F0BE510D0E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

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.

 

This document is the specification for tcpcrypt, which is targeted to be an Experimental RFC. It is generally very well written, but it could benefit from a few edits, as noted below.

 

The introduction (section 2) is brief and well written, stating the goals for the design.

 

Section 3 is much longer, providing a detailed description of the protocol. (Although the description is characterized as “abstract” it is very detailed, with only format details deferred to Section 4.) This section also is generally well-written.

 

In 3.2 I suggest including a forward pointer to the IANA Considerations section, since that section describes how future TEPs may be added to the list in Table 2.

 

In 3.5 the text says:

     When two hosts have previously negotiated a tcpcrypt session,

     either host may initiate session resumption regardless of which

     host was the active opener or played the "A" role in the

     previous session.

It’s not clear to me in what time frame this comment is meant to apply, e.g., if two hosts established a tcpcrypt session a week ago, is this comment still supposed to be applicable? Some clarification here would be useful. The end of this section establishes a requirement for an interface to enable an application to control session caching. Are interfaces of this sort commonly provided to applications by an OS? If so, an example would be useful; if not, the authors should acknowledge that this requirement may be problematic, i.e., applications may require modification to make use of the mandated interface.

 

 

In 3.6 the mention Table 3 also should refer to IANA Considerations, since that section describes how additions algorithms may be added.

 

The last sentence of 3.7 should be broken into several sentences; it is currently 7 lines long!

 

Section 3.8 describes a fairly complicated set of constraints  associated with rekeying, some of which are inter-related. It might help to have a table here to describe how these constraints interact, e.g., when TCP-mandated retransmission takes place in the context of a rekey.

 

I suggest the following editorial changes in section 3:

 

… assigns different roles to -> … assigns the roles to the two hosts

 

… ephemeral public keys for hosts A and B -> … ephemeral public key agreement keys for hosts A and B

 

… whose length depends -> … the length of which depends

 

… whose integer value -> … the integer value of which

 

… security of the AEAD algorithm -> … security of every AEAD algorithm

 

Section 4 describes the byte-level encoding for the data structures described in Section 3, as part of the tcpcrypt specification. In 4.1 found the description of the “ignored” data the INIT1_ and INIT2_ messages to be a bit confusing. I had to reread the descriptions to figure out that this was the authors’ way of saying that data beyond the end of the message (as indicated by the message_len field) is to be ignored upon reception. I don’t think the graphics used here are a great way to explain this.

 

Section 6 defines the initial set of AEAD algorithms supported by tcpcrypt, in Table 2. Each algorithm is assigned a value in the 1-255 range, a much smaller range of values that used in protocols like TLS. The text in Section 7 might need to remind readers that this will argue against the registration of “vanity” AEAD algorithms for tcpcrypt.

 

Security Considerations are described in Section 8. I found the phrase “Most implementations will rely on system-wide pseudo-random generators…” to be a bit confusing, because the ambiguity of the word “system” here. I presume this really refers to a single device in mots cases, e.g., a laptop, desktop, smartphone, right? I suggest a reference to RFC 4086 might be a good substitute for much of the text at the beginning of this section.

 

I’d like the authors to provide a rationale for the advice: “…limit the lifetime of the private parameters, ideally to no more than two minutes.” This seems a bit arbitrary to me.

 

 

Suggested editorial changes to Section 8:

 

… is one on which -> is one for which

 

… without guessing the content of the resumption identifier, -> without successfully guessing the value of the resumption identifier,

 

Thus, tcpcrypt specifies a way … -> To counter this threat, tcpcrypt specifies a way …

--------------98C5D1EC086395F0BE510D0E-- From nobody Thu Oct 12 10:20:14 2017 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 1FE3413453E; Thu, 12 Oct 2017 10:20:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joseph Salowey To: Cc: opsawg@ietf.org, iesg@ietf.org, draft-ietf-opsawg-service-model-explained.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150782881408.16793.934516939914088050@ietfa.amsl.com> Date: Thu, 12 Oct 2017 10:20:14 -0700 Archived-At: Subject: [secdir] Secdir telechat review of draft-ietf-opsawg-service-model-explained-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Oct 2017 17:20:14 -0000 Reviewer: Joseph Salowey Review result: Ready Document revision addressed my comments. From nobody Thu Oct 12 14:56:58 2017 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 D9E6A1321A0; Thu, 12 Oct 2017 14:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6W5RZrN5FUbL; Thu, 12 Oct 2017 14:56:40 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00753132FB1; Thu, 12 Oct 2017 14:56:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7464; q=dns/txt; s=iport; t=1507845400; x=1509055000; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=HMnTWf8TmjKEd4/+nehE8qSq3JBHWoKTMaZBjy8oZKs=; b=KhDm0E0pglpdJLXRMcW8ySiduUQ2VY5jrWtuM2gUYDkA+ebl2zRUXcNx Xl9wXDaSrscDykRYZom3bqOsopAQueMdP2foqYXY1ZnzB6+khCjdcHCo6 KCYG39YX3sSCcwQ5rMD5HIqK+3Y1tQqbXgd331WU+FQfl/xTNTmD9xFkb Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CbAAAN5N9Z/40NJK1VBgMZAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGDXYFSJweDc4ofjzKBdpYvDoIECoU7AhqEJT8YAQIBAQEBAQE?= =?us-ascii?q?BayiFHgEFIxEzEhACAQgYAgImAgICMBUQAgQBDQWKHqtwgieLOwEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAR2BDoIfggeBUYFqK4J/hFIBCAMHATYKJoJML4IyBaFEApR?= =?us-ascii?q?oDJMElT4CERkBgTgBHziBAwt4FVsBhQcBG4FndokTDxiBDIERAQEB?= X-IronPort-AV: E=Sophos;i="5.43,368,1503360000"; d="scan'208";a="305319231" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Oct 2017 21:56:38 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v9CLucJ6017311 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 12 Oct 2017 21:56:38 GMT Received: from xch-rcd-019.cisco.com (173.37.102.29) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 12 Oct 2017 16:56:37 -0500 Received: from xch-rcd-019.cisco.com ([173.37.102.29]) by XCH-RCD-019.cisco.com ([173.37.102.29]) with mapi id 15.00.1320.000; Thu, 12 Oct 2017 16:56:37 -0500 From: "Arjun Sreekantiah (asreekan)" To: "John G. Scudder" , "Brian Weis (bew)" CC: stefano previdi , "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-idr-bgp-prefix-sid.all@ietf.org" , "Gaurav Dawra (gdawra)" Thread-Topic: Secdir early review of draft-ietf-idr-bgp-prefix-sid-06 Thread-Index: AQHTAtRSCuBzILjiK0OIovgMdDR4U6JmcY0AgA7UdgCAYmpQgIAJcoSA Date: Thu, 12 Oct 2017 21:56:37 +0000 Message-ID: References: <150071889993.20425.5273428383173596948@ietfa.amsl.com> <6A05B578-F8DE-4197-97B8-82886089782B@previdi.net> <13FD5BC6-69AD-46F1-8767-DE11740A49A0@juniper.net> In-Reply-To: <13FD5BC6-69AD-46F1-8767-DE11740A49A0@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.15.1.160411 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.154.161.199] Content-Type: text/plain; charset="utf-8" Content-ID: <5C471B932F10164D81143DF31568733A@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] Secdir early review of draft-ietf-idr-bgp-prefix-sid-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Oct 2017 21:56:42 -0000 Sm9obiwNCldlIHdpbGwgbWFrZSB0aGUgbWlub3IgcmV2aXNpb24geW91IHN1Z2dlc3QgYmVsb3cg YW5kIHJlLXBvc3QgdGhlIGRyYWZ0LiAgDQoNClRoYW5rcywNCkFyanVuDQoNCg0KDQoNCk9uIDEw LzYvMTcsIDc6NDAgQU0sICJKb2huIEcuIFNjdWRkZXIiIDxqZ3NAanVuaXBlci5uZXQ+IHdyb3Rl Og0KDQo+SGkgQnJpYW4gYW5kIFN0ZWZhbm8sDQo+DQo+SSdtIGdsYWQgU3RlZmFubydzIGNvbW1l bnRzIHNhdGlzZnkgQnJpYW4uIEl0IHNlZW1zIHRvIG1lIHRoYXQgdGhpcyBjbGFyaWZpY2F0aW9u IHdvdWxkIGJlIHdvcnRoIGFkZGluZyB0byBhIG5ldyByZXZpc2lvbiBvZiB0aGUgZHJhZnQ6DQo+ DQo+Pj4gKGMpIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIHNwZWFrcyBvZiBsaW1pdGluZyBCR1Ag UHJlZml4LVNJRCB3aXRoaW4gYQ0KPj4+IOKAnGRvbWFpbuKAnS4gSXMgdGhhdCBpbnRlbmRpbmcg dG8gc2F5IGFuIOKAnFNSIGRvbWFpbuKAnT8NCj4+IA0KPj4gTW9yZSBnZW5lcmFsbHksIGJ5IGRv bWFpbiB3ZSBpbnRlbmQgdGhlIHNldCBvZiBBUyB1bmRlciBjb250cm9sIG9mIHRoZSBzYW1lIG9y Z2FuaXphdGlvbi9vcGVyYXRvci4NCj4NCj5TZWVtcyBhcyB0aG91Z2ggdGhlIG90aGVyIG5pdHMg d2VyZSBhZGRyZXNzZWQgd2l0aCBubyBjaGFuZ2UgbmVlZGVkLCBvciB0aGF0J3MgbXkgdW5kZXJz dGFuZGluZyBvZiB0aGUgY29uc2Vuc3VzIGJldHdlZW4gQnJpYW4gYW5kIFN0ZWZhbm8uDQo+DQo+ U3RlZmFubyBvciBvdGhlciBhdXRob3JzLCBjYW4geW91IGVpdGhlciBtYWtlIHRoZSBtaW5vciBy ZXZpc2lvbiBpbmRpY2F0ZWQsIG9yIHJlcGx5IHRoYXQgeW91IGRvbid0IHBsYW4gdG8/DQo+DQo+ VGhhbmtzLA0KPg0KPi0tSm9obg0KPg0KPj4gT24gQXVnIDQsIDIwMTcsIGF0IDc6NDYgUE0sIEJy aWFuIFdlaXMgKGJldykgPGJld0BjaXNjby5jb20+IHdyb3RlOg0KPj4gDQo+PiBIaSBTdGVmYW5v LA0KPj4gDQo+PiBUaGFua3MgZm9yIHlvdXIgbm90ZXMgYmVsb3csIHdoaWNoIG1ha2Ugc2Vuc2Ug dG8gbWUuIEkgZG9u4oCZdCBoYXZlIGFueSBtb3JlIGNvbW1lbnRzLiANCj4+IA0KPj4gQnJpYW4N Cj4+IA0KPj4+IE9uIEp1bCAyNiwgMjAxNywgYXQgNjoxOCBBTSwgc3RlZmFubyBwcmV2aWRpIDxz dGVmYW5vQHByZXZpZGkubmV0PiB3cm90ZToNCj4+PiANCj4+PiBIaSBCcmlhbiwNCj4+PiANCj4+ PiB0aGFua3MgZm9yIHRoZSByZXZpZXcuIFNvbWUgY29tbWVudHMgaGVyZSBiZWxvdy4NCj4+PiAN Cj4+PiANCj4+Pj4gT24gSnVsIDIyLCAyMDE3LCBhdCAxMjoyMSBQTSwgQnJpYW4gV2VpcyA8YmV3 QGNpc2NvLmNvbT4gd3JvdGU6DQo+Pj4+IA0KPj4+PiBSZXZpZXdlcjogQnJpYW4gV2Vpcw0KPj4+ PiBSZXZpZXcgcmVzdWx0OiBIYXMgTml0cw0KPj4+PiANCj4+Pj4gSSBoYXZlIHJldmlld2VkIHRo aXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgc2VjdXJpdHkgZGlyZWN0b3JhdGUncyBvbmdvaW5n DQo+Pj4+IGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3Nl ZCBieSB0aGUgSUVTRy4gVGhlc2UgY29tbWVudHMNCj4+Pj4gd2VyZSB3cml0dGVuIHByaW1hcmls eSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlIHNlY3VyaXR5IGFyZWEgZGlyZWN0b3JzLiBEb2N1bWVu dA0KPj4+PiBlZGl0b3JzIGFuZCBXRyBjaGFpcnMgc2hvdWxkIHRyZWF0IHRoZXNlIGNvbW1lbnRz IGp1c3QgbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsDQo+Pj4+IGNvbW1lbnRzLg0KPj4+PiANCj4+ Pj4gVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBCR1AgZXh0ZW5zaW9uIHRvIHNpZ25hbCB0aGUg QkdQIFByZWZpeC1TSUQgdXNlIHdpdGgNCj4+Pj4gU2VnbWVudCBSb3V0aW5nLiAgYXMgd2VsbCBh cyB0aGUgcnVsZXMgdG8gb3JpZ2luYXRlLCByZWNlaXZlIGFuZCBoYW5kbGUgZXJyb3INCj4+Pj4g Y29uZGl0aW9ucy4gVGhlIEJHUCBleHRlbnNpb24gZGVmaW5lcyBhIG5ldyB0eXBlIG9mIEJHUCBw YXRoIGF0dHJpYnV0ZSBwYXNzZWQNCj4+Pj4gd2l0aGluIEJHUCwgYW5kIGRvZXMgbm90IGNoYW5n ZSB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgb2YgdGhlIEJHUCBwcm90b2NvbA0KPj4+PiBp dHNlbGYuDQo+Pj4+IA0KPj4+PiBJIGNvbnNpZGVyIHRoaXMgZG9jdW1lbnQg4oCccmVhZHkgd2l0 aCBuaXRz4oCdLg0KPj4+PiANCj4+Pj4gVGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIHNlY3Rp b24gcmVhc29uYWJseSBzdGF0ZXMgdGhhdCB0aGUgdXNlIG9mIHRoaXMgQkdQDQo+Pj4+IGF0dHJp YnV0ZSDigJxpbmhlcml0cyB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnPigJ0gb2YgdGhlIEJH UC00IFJGQyBhcyB3ZWxsIGFzDQo+Pj4+IHRoZSBSRkMgZGVmaW5pbmcgaG93IGxhYmVscyBhcmUg Y2FycmllZCBpbiBCR1AtNC4gQXMgYW4gYXNpZGUsIHRob3NlIGRvY3VtZW50cw0KPj4+PiBhcmUg cXVpdGUgb2xkLiBGb3IgZXhhbXBsZSwgUkZDIDQyNzEgc2F5cyB0aGF0IHRoZSBUQ1AtTUQ1IG9w dGlvbiBpcyByZXF1aXJlZA0KPj4+PiB0byBpbXBsZW1lbnQgZm9yIGF1dGhlbnRpY2F0aW9uLCBi dXQgdGhpcyBoYXMgYmVlbiByZXBsYWNlZCBieSBhIG11Y2ggc3Ryb25nZXINCj4+Pj4gYXV0aGVu dGljYXRpb24gbWV0aG9kIChUQ1AtQU8pLiBJdCB3b3VsZCBiZSBuaWNlIGlmIHdlIGhhZCBuZXdl ciBzZWN1cml0eQ0KPj4+PiBjb25zaWRlcmF0aW9ucyBmb3IgQkdQLTQgYnV0IHRoYXQgYWR2aWNl IGRvZXNu4oCZdCBiZWxvbmcgaW4gdGhpcyBkb2N1bWVudC4NCj4+Pj4gDQo+Pj4+IFRoZSBTZWN1 cml0eSBDb25zaWRlcmF0aW9ucyBtaWdodCBoYXZlIHNhaWQgc29tZXRoaW5nIGFib3V0IHRoZSBo b3cgYW4gQVMgd291bGQNCj4+Pj4gcHJvdGVjdCBpdHNlbGYgYWdhaW5zdCBhIHBlZXIgc2VuZGlu ZyB0aGUgUHJlZml4LVNJRCBhdHRyaWJ1dGUgYWNyb3NzIEFTDQo+Pj4+IGJvdW5kYXJpZXMsIGJ1 dCB0aGF0IHRleHQgaXMgY29udGFpbmVkIGluIHVzZWZ1bCBwbGFjZXMgZWxzZXdoZXJlIGluIHRo ZQ0KPj4+PiBkb2N1bWVudCBhbmQgc2VlbXMgc3VmZmljaWVudC4NCj4+Pj4gDQo+Pj4+IEkgaGF2 ZSBvbmx5IG9uZSBuaXQsIHdoaWNoIGlzIHNvbWUgY29uZnVzaW9uIHJlZ2FyZGluZyBzY29waW5n IG9mIHRoZSBTSUQuIFRoZQ0KPj4+PiBkb2N1bWVudCBjbGVhcmx5IHN0YXRlcyB0aGF0IGEgU0lE IGhhcyBhIGxpbWl0ZWQgc2NvcGUgd2l0aGluIHRoZSBuZXR3b3JrLCANCj4+Pj4gd2hpY2ggaXMg aW1wb3J0YW50IGJlY2F1c2Ugb3V0c2lkZSBvZiB0aGF0IHNjb3BlIGFuIFNJRCB2YWx1ZSB3b3Vs ZCBoYXZlIGENCj4+Pj4gZGlmZmVyZW50IG1lYW5pbmcuIFRoaXMgaXMgYSBzZWN1cml0eSAgY29u c2lkZXJhdGlvbiwgYmVjYXVzZSBhY2NlcHRpbmcgYSBTSUQNCj4+Pj4gaW4gdGhlIHdyb25nIHNj b3BlIGNvdWxkIHBvc3NpYmx5IGNhdXNlIGEgc2VjdXJpdHkgaXNzdWUgaWYgcGFja2V0cyBhcmUN Cj4+Pj4gZm9yd2FyZGVkIHRvIHRoZSB3cm9uZyBpZGVudGl0eSAoZS5nLCB0aGUgcGFja2V0cyB3 ZXJlIGludGVuZGVkIGZvciBhIGZpcmV3YWxsDQo+Pj4+IHdpdGhpbiB0aGUgQVMsIG5vdCBhIHNl cnZpY2Ugb3V0c2lkZSBvZiB0aGUgQVMpLg0KPj4+PiANCj4+Pj4gKGEpIFNlY3Rpb24gNS4xIHNh eXMgaXQgc2hvdWxkIG5vdCBiZSBhZHZlcnRpc2VkIG91dHNpZGUgb2YgYW4gQVMgdW5sZXNzDQo+ Pj4+IOKAnGV4cGxpY2l0bHkgY29uZmlndXJlZCB0byBkbyBzb+KAnS4gSXQgd291bGQgYmUgbmlj ZSBpZiB0aGUgY29uZGl0aW9ucyBmb3INCj4+Pj4gZXhwbGljaXRseSBjb25maWd1cmluZyB0aGUg U0lEIHRvIGJlIGFkdmVydGlzZWQgb3V0c2lkZSBvZiB0aGUgQVMgd2VyZQ0KPj4+PiBtZW50aW9u ZWQgaGVyZS4NCj4+PiANCj4+PiANCj4+PiB1c3VhbGx5IHdlIGRvbuKAmXQgZGVmaW5lIHRoZXNl IGNvbmRpdGlvbiBiZWNhdXNlIHRoZXkgYXJlIHJlbGF0ZWQgdG8gZWFjaCBpbmRpdmlkdWFsIG9w ZXJhdG9yIHBvbGljeS4gV2hhdCB3ZSB3YW50IHRvIGJlIHN1cmUgb2YgaXMgdGhhdCBhbnkgY29t cGxpYW50IGltcGxlbWVudGF0aW9uLCBieSBkZWZhdWx0LCB3aWxsIG5vdCBwcm9wYWdhdGUgdGhl IGF0dHJpYnV0ZSBvdXRzaWRlIHRoZSBBUy4NCj4+PiANCj4+PiBVbmRlciB3aGljaCBjb25kaXRp b25zIHByb3BhZ2F0aW9uIGlzIGFsbG93ZWQgaXMgYSBsb2NhbCBtYXR0ZXIgb2YgdGhlIG9wZXJh dG9yIGFuZCBob3cgaXQgaXMgZWZmZWN0aXZlbHkgYWNoaWV2ZWQgaXMgYSBtYXR0ZXIgb2YgbG9j YWwgaW1wbGVtZW50YXRpb24uDQo+Pj4gDQo+Pj4gDQo+Pj4+IChiKSBUaGUgbGFzdCBwYXJhZ3Jh cGggb2YgU2VjdGlvbiA4IHNheXMgaXQgaXMgYXBwbGljYWJsZSB3aXRoaW4gYW4gU1IgRG9tYWlu DQo+Pj4+IChpLmUuLCBtb3JlIHRoYW4gYW4gQVMpLCBhbmQgU2VjdXJpdHkgQ29uc2lkZXJhdGlv bnMgc2F5cyBzb21ldGhpbmcgc2ltaWxhci4NCj4+Pj4gDQo+Pj4+IChjKSBTZWN1cml0eSBDb25z aWRlcmF0aW9ucyBzcGVha3Mgb2YgbGltaXRpbmcgQkdQIFByZWZpeC1TSUQgd2l0aGluIGENCj4+ Pj4g4oCcZG9tYWlu4oCdLiBJcyB0aGF0IGludGVuZGluZyB0byBzYXkgYW4g4oCcU1IgZG9tYWlu 4oCdPw0KPj4+IA0KPj4+IA0KPj4+IE1vcmUgZ2VuZXJhbGx5LCBieSBkb21haW4gd2UgaW50ZW5k IHRoZSBzZXQgb2YgQVMgdW5kZXIgY29udHJvbCBvZiB0aGUgc2FtZSBvcmdhbml6YXRpb24vb3Bl cmF0b3IuDQo+Pj4gDQo+Pj4+IEkgc3VzcGVjdCB3aGV0aGVyIGFuIFNJRCBzaG91bGQgYmUgYWR2 ZXJ0aXNlZCBvdXRzaWRlIG9mIHRoZSBBUyBkZXBlbmRzIG9uDQo+Pj4+IHdoZXRoZXIgYW4gQVMg aXMgcGFydCBvZiBhbiDigJxTUiBkb21haW7igJ0gb3Igbm90LCBhbmQgdGhhdCB0aGVyZSdzIGxp a2VseSBuZXZlciBhDQo+Pj4+IGdvb2QgY2FzZSB0byBhZHZlcnRpc2UgaXQgb3V0c2lkZSBvZiBh biBBUyB1bmxlc3MgaXQgaXMgcGFydCBvZiBhbiAiU1IgZG9tYWluIi4NCj4+Pj4gQnV0IGl0IHdv dWxkIGJlIGdvb2QgaWYgdGhlcmUgd2FzIHNvbWUgdGV4dCBjbGFyaWZ5aW5nICB0aGUgY29uZGl0 aW9ucyB3aGVuIGl0DQo+Pj4+IGlzIHJlYXNvbmFibGUgdG8gc2hhcmUgYW4gU0lEIGJldHdlZW4g QVNlcy4NCj4+PiANCj4+PiANCj4+PiBXZWxsLCBJ4oCZbSBub3Qgc3VyZSB0aGF0IHdvdWxkIGJl IGEgZ29vZCBpZGVhIGJlY2F1c2UgdGhlIGNvbmRpdGlvbnMgbWF5IHZhcnkgb3ZlciB0aW1lIGFu ZCB3ZSB3aWxsIG5ldmVyIGJlIGV4aGF1c3RpdmUgYW55d2F5Lg0KPj4+IFRoYW5rcy4NCj4+PiBz Lg0KPj4+IA0KPj4+IA0KPj4+PiANCj4+PiANCj4+IA0KPj4gLS0gDQo+PiBCcmlhbiBXZWlzDQo+ PiBTZWN1cml0eSwgQ1NHLCBDaXNjbyBTeXN0ZW1zDQo+PiBUZWxlcGhvbmU6ICsxIDQwOCA1MjYg NDc5Ng0KPj4gRW1haWw6IGJld0BjaXNjby5jb20NCj4+IA0KPg0K From nobody Thu Oct 12 15:51:47 2017 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 15F03132D96; Thu, 12 Oct 2017 15:51:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 2QQ-2qhIay_i; Thu, 12 Oct 2017 15:51:44 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 09CE3133071; Thu, 12 Oct 2017 15:51:41 -0700 (PDT) Received: from thinny.local (unknown [216.38.134.66]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by colo.trepanning.net (Postfix) with ESMTPSA id 81E7F10224052; Thu, 12 Oct 2017 15:51:40 -0700 (PDT) To: "iesg@ietf.org" , secdir@ietf.org, draft-ietf-dnssd-hybrid.all@ietf.org From: Dan Harkins Message-ID: <58f723a1-b6df-3f6d-8337-9fd7ebfdb7e7@lounge.org> Date: Thu, 12 Oct 2017 15:51:39 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------3CBA112BAE5E71A9E96CAC24" Content-Language: en-US Archived-At: Subject: [secdir] secdir reveiw of draft-ietf-dnssd-hybrid X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Oct 2017 22:51:46 -0000 This is a multi-part message in MIME format. --------------3CBA112BAE5E71A9E96CAC24 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit   Greetings, 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 draft describes a new type of proxy that uses multicast DNS to discover multicast DNS records on local links and then makes corresponding DNS records visible in the unicast DNS namespace. This is a very well written draft and is easy to read and understand. I believe it is "Ready with nit". My nit is this: I understand that there is a general problem with restricting certain DNS records but this draft seems to exacerbate that problem. The draft's privacy considerations do discuss the case where a "Multicast Service Discovery Proxy" makes records for transient devices from the local link available to, theoretically, the global public DNS database and thereby advertises the presence or absence of a laptop (and more importantly it's owner from a house). This is a serious issue and I think the draft should address it instead of punting the problem to "firewalls, split-view DNS, and Virtual Private Networks". Due to my general DNS ignorance I am unable to suggest a workable solution but there should be a way to instruct the proxy to suppress certain records (perhaps encode something in the QNAME, I don't know). I just think this draft creates a serious problem out of a protocol limitation and it should provide some way to address it. regards, Dan. --------------3CBA112BAE5E71A9E96CAC24 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit  
  Greetings,
  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 draft describes a new type of proxy that uses multicast DNS
to discover multicast DNS records on local links and then makes
corresponding DNS records visible in the unicast DNS namespace. 

  This is a very well written draft and is easy to read and understand.
I believe it is "Ready with nit". My nit is this:

  I understand that there is a general problem with restricting certain
DNS records but this draft seems to exacerbate that problem. The draft's
privacy considerations do discuss the case where a "Multicast Service
Discovery Proxy" makes records for transient devices from the local link
available to, theoretically, the global public DNS database and thereby
advertises the presence or absence of a laptop (and more importantly it's
owner from a house). This is a serious issue and I think the draft should
address it instead of punting the problem to "firewalls, split-view DNS,
and Virtual Private Networks". Due to my general DNS ignorance I am unable
to suggest a workable solution but there should be a way to instruct the
proxy to suppress certain records (perhaps encode something in the QNAME,
I don't know). I just think this draft creates a serious problem out of a
protocol limitation and it should provide some way to address it.

  regards,

  Dan.
--------------3CBA112BAE5E71A9E96CAC24-- From nobody Fri Oct 13 05:22:44 2017 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 620AA13213D; Fri, 13 Oct 2017 05:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 BPg4ksNQMhBK; Fri, 13 Oct 2017 05:22:41 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C53D213293A; Fri, 13 Oct 2017 05:22:39 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML712-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DQO70686; Fri, 13 Oct 2017 12:22:31 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 13 Oct 2017 13:22:29 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.199]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Fri, 13 Oct 2017 20:22:25 +0800 From: Qin Wu To: "secdir@ietf.org" , "ietf@ietf.org" CC: "draft-wu-l3sm-rfc8049bis.all@ietf.org" Thread-Topic: I-D Action: draft-wu-l3sm-rfc8049bis-06.txt Thread-Index: AQHTQ8FnA3FIx8D1Uk2vyQnk4lYpPKLg+6fQgAAxjwCAAIbk8A== Date: Fri, 13 Oct 2017 12:22:25 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.79.163] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA9ABAF6ADnkgeml513mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.59E0B00D.0142, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.199, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: ace4809511db11f901484884e5f9c8fd Archived-At: Subject: Re: [secdir] I-D Action: draft-wu-l3sm-rfc8049bis-06.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Oct 2017 12:22:43 -0000 --_000_B8F9A780D330094D99AF023C5877DABA9ABAF6ADnkgeml513mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmlmYWF0Og0KVGhhbmtzIGZvciB5b3VyIGNvbmZpcm1hdGlvbi4NCg0KLVFpbg0K5Y+R5Lu25Lq6 OiBSaWZhYXQgU2hla2gtWXVzZWYgW21haWx0bzpyaWZhYXQuaWV0ZkBnbWFpbC5jb21dDQrlj5Hp gIHml7bpl7Q6IDIwMTflubQxMOaciDEz5pelIDIwOjE5DQrmlLbku7bkuro6IFFpbiBXdQ0K5oqE 6YCBOiBkcmFmdC13dS1sM3NtLXJmYzgwNDliaXNAaWV0Zi5vcmc7IEJlbm9pdCBDbGFpc2U7IEFk cmlhbiBGYXJyZWwNCuS4u+mimDogUmU6IEktRCBBY3Rpb246IGRyYWZ0LXd1LWwzc20tcmZjODA0 OWJpcy0wNi50eHQNCg0KSGkgUWluLA0KDQpJIGFtIGZpbmUgd2l0aCB0aGlzLg0KDQpSZWdhcmRz LA0KIFJpZmFhdA0KDQoNCk9uIFRodSwgT2N0IDEyLCAyMDE3IGF0IDk6MjMgUE0sIFFpbiBXdSA8 YmlsbC53dUBodWF3ZWkuY29tPG1haWx0bzpiaWxsLnd1QGh1YXdlaS5jb20+PiB3cm90ZToNCkhp LCBSaWZmYXQ6DQpMZXQgdXMga25vdyBpZiB0aGlzIHZlcnNpb24gKC0wNikgYWRkcmVzcyB5b3Vy IGNvbW1lbnQuDQoNCi1RaW4NCi0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCuWPkeS7tuS6ujogSS1E LUFubm91bmNlIFttYWlsdG86aS1kLWFubm91bmNlLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmkt ZC1hbm5vdW5jZS1ib3VuY2VzQGlldGYub3JnPl0g5Luj6KGoIGludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZzxtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPg0K5Y+R6YCB5pe26Ze0OiAyMDE3 5bm0MTDmnIgxM+aXpSA5OjIwDQrmlLbku7bkuro6IGktZC1hbm5vdW5jZUBpZXRmLm9yZzxtYWls dG86aS1kLWFubm91bmNlQGlldGYub3JnPg0K5Li76aKYOiBJLUQgQWN0aW9uOiBkcmFmdC13dS1s M3NtLXJmYzgwNDliaXMtMDYudHh0DQoNCg0KQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxh YmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KDQoNCiAg ICAgICAgVGl0bGUgICAgICAgICAgIDogWUFORyBEYXRhIE1vZGVsIGZvciBMM1ZQTiBTZXJ2aWNl IERlbGl2ZXJ5DQogICAgICAgIEF1dGhvcnMgICAgICAgICA6IFFpbiBXdQ0KICAgICAgICAgICAg ICAgICAgICAgICAgICBTdGVwaGFuZSBMaXRrb3dza2kNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgTHVpcyBUb21vdGFraQ0KICAgICAgICAgICAgICAgICAgICAgICAgICBLZW5pY2hpIE9nYWtp DQogICAgICAgIEZpbGVuYW1lICAgICAgICA6IGRyYWZ0LXd1LWwzc20tcmZjODA0OWJpcy0wNi50 eHQNCiAgICAgICAgUGFnZXMgICAgICAgICAgIDogMTgzDQogICAgICAgIERhdGUgICAgICAgICAg ICA6IDIwMTctMTAtMTINCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IGRlZmluZXMgYSBZ QU5HIGRhdGEgbW9kZWwgdGhhdCBjYW4gYmUgdXNlZCBmb3INCiAgIGNvbW11bmljYXRpb24gYmV0 d2VlbiBjdXN0b21lcnMgYW5kIG5ldHdvcmsgb3BlcmF0b3JzIGFuZCB0byBkZWxpdmVyDQogICBh IExheWVyIDMgcHJvdmlkZXItcHJvdmlzaW9uZWQgVlBOIHNlcnZpY2UuICBUaGlzIGRvY3VtZW50 IGlzIGxpbWl0ZWQNCiAgIHRvIEJHUCBQRS1iYXNlZCBWUE5zIGFzIGRlc2NyaWJlZCBpbiBSRkNz IDQwMjYsIDQxMTAsIGFuZCA0MzY0LiAgVGhpcw0KICAgbW9kZWwgaXMgaW50ZW5kZWQgdG8gYmUg aW5zdGFudGlhdGVkIGF0IHRoZSBtYW5hZ2VtZW50IHN5c3RlbSB0bw0KICAgZGVsaXZlciB0aGUg b3ZlcmFsbCBzZXJ2aWNlLiAgSXQgaXMgbm90IGEgY29uZmlndXJhdGlvbiBtb2RlbCB0byBiZQ0K ICAgdXNlZCBkaXJlY3RseSBvbiBuZXR3b3JrIGVsZW1lbnRzLiAgVGhpcyBtb2RlbCBwcm92aWRl cyBhbiBhYnN0cmFjdGVkDQogICB2aWV3IG9mIHRoZSBMYXllciAzIElQIFZQTiBzZXJ2aWNlIGNv bmZpZ3VyYXRpb24gY29tcG9uZW50cy4gIEl0IHdpbGwNCiAgIGJlIHVwIHRvIHRoZSBtYW5hZ2Vt ZW50IHN5c3RlbSB0byB0YWtlIHRoaXMgbW9kZWwgYXMgaW5wdXQgYW5kIHVzZQ0KICAgc3BlY2lm aWMgY29uZmlndXJhdGlvbiBtb2RlbHMgdG8gY29uZmlndXJlIHRoZSBkaWZmZXJlbnQgbmV0d29y aw0KICAgZWxlbWVudHMgdG8gZGVsaXZlciB0aGUgc2VydmljZS4gIEhvdyB0aGUgY29uZmlndXJh dGlvbiBvZiBuZXR3b3JrDQogICBlbGVtZW50cyBpcyBkb25lIGlzIG91dCBvZiBzY29wZSBmb3Ig dGhpcyBkb2N1bWVudC4NCg0KICAgSWYgYXBwcm92ZWQsIHRoaXMgZG9jdW1lbnQgb2Jzb2xldGVz IFJGQyA4MDQ5LiAgVGhlIGNoYW5nZXMgYXJlIGENCiAgIHNlcmllcyBvZiBzbWFsbCBmaXhlcyB0 byB0aGUgWUFORyBtb2R1bGUsIGFuZCBzb21lIGNsYXJpZmljYXRpb25zIHRvDQogICB0aGUgdGV4 dC4NCg0KDQpUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBp czoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXd1LWwzc20tcmZjODA0 OWJpcy8NCg0KVGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Og0K aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXd1LWwzc20tcmZjODA0OWJpcy0wNg0K aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC13dS1sM3NtLXJmYzgw NDliaXMtMDYNCg0KQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxl IGF0Og0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXd1LWwzc20tcmZj ODA0OWJpcy0wNg0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2Yg bWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZl cnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZzxodHRwOi8vdG9v bHMuaWV0Zi5vcmc+Lg0KDQpJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFu b255bW91cyBGVFAgYXQ6DQpmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSS1ELUFubm91 bmNlIG1haWxpbmcgbGlzdA0KSS1ELUFubm91bmNlQGlldGYub3JnPG1haWx0bzpJLUQtQW5ub3Vu Y2VAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ktZC1h bm5vdW5jZQ0KSW50ZXJuZXQtRHJhZnQgZGlyZWN0b3JpZXM6IGh0dHA6Ly93d3cuaWV0Zi5vcmcv c2hhZG93Lmh0bWwgb3IgZnRwOi8vZnRwLmlldGYub3JnL2lldGYvMXNoYWRvdy1zaXRlcy50eHQN Cg0K --_000_B8F9A780D330094D99AF023C5877DABA9ABAF6ADnkgeml513mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0FjZXRh dGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazoi5om55rOo5qGG5paH5pysIENoYXIiOw0KCW1hcmdpbjowY207 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo5LjBwdDsNCglmb250LWZhbWls eTrlrovkvZM7fQ0Kc3Bhbi5DaGFyDQoJe21zby1zdHlsZS1uYW1lOiLmibnms6jmoYbmlofmnKwg Q2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOuaJueazqOah huaWh+acrDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzky LjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iWkgt Q04iIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UmlmYWF0OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtzIGZvciB5b3VyIGNvbmZpcm1hdGlvbi48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LVFpbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0Ij7lj5Hku7bkuro8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bh bj48L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+ IFJpZmFhdCBTaGVraC1ZdXNlZiBbbWFpbHRvOnJpZmFhdC5pZXRmQGdtYWlsLmNvbV0NCjxicj4N Cjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+5Y+R6YCB5pe26Ze0PHNw YW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiAyMDE3PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0Ij7lubQ8c3BhbiBsYW5nPSJFTi1VUyI+MTA8L3NwYW4+5pyIPHNwYW4gbGFuZz0iRU4t VVMiPjEzPC9zcGFuPuaXpTxzcGFuIGxhbmc9IkVOLVVTIj4gMjA6MTk8YnI+DQo8L3NwYW4+PGI+ 5pS25Lu25Lq6PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVT Ij4gUWluIFd1PGJyPg0KPC9zcGFuPjxiPuaKhOmAgTxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFu PjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IGRyYWZ0LXd1LWwzc20tcmZjODA0OWJpc0BpZXRmLm9y ZzsgQmVub2l0IENsYWlzZTsgQWRyaWFuIEZhcnJlbDxicj4NCjwvc3Bhbj48Yj7kuLvpopg8c3Bh biBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBSZTogSS1EIEFj dGlvbjogZHJhZnQtd3UtbDNzbS1yZmM4MDQ5YmlzLTA2LnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5IaSBRaW4sPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgYW0gZmluZSB3aXRoIHRoaXMuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ Jm5ic3A7UmlmYWF0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+T24gVGh1LCBPY3QgMTIsIDIwMTcgYXQg OToyMyBQTSwgUWluIFd1ICZsdDs8YSBocmVmPSJtYWlsdG86YmlsbC53dUBodWF3ZWkuY29tIiB0 YXJnZXQ9Il9ibGFuayI+YmlsbC53dUBodWF3ZWkuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkhp LCBSaWZmYXQ6PGJyPg0KTGV0IHVzIGtub3cgaWYgdGhpcyB2ZXJzaW9uICgtMDYpIGFkZHJlc3Mg eW91ciBjb21tZW50Ljxicj4NCjxicj4NCi1RaW48YnI+DQotLS0tLTwvc3Bhbj7pgq7ku7bljp/k u7Y8c3BhbiBsYW5nPSJFTi1VUyI+LS0tLS08YnI+DQo8L3NwYW4+5Y+R5Lu25Lq6PHNwYW4gbGFu Zz0iRU4tVVMiPjogSS1ELUFubm91bmNlIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmktZC1hbm5v dW5jZS1ib3VuY2VzQGlldGYub3JnIj5pLWQtYW5ub3VuY2UtYm91bmNlc0BpZXRmLm9yZzwvYT5d DQo8L3NwYW4+5Luj6KGoIDxzcGFuIGxhbmc9IkVOLVVTIj48YSBocmVmPSJtYWlsdG86aW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnIj5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+PGJyPg0KPC9z cGFuPuWPkemAgeaXtumXtDxzcGFuIGxhbmc9IkVOLVVTIj46IDIwMTc8L3NwYW4+5bm0PHNwYW4g bGFuZz0iRU4tVVMiPjEwPC9zcGFuPuaciDxzcGFuIGxhbmc9IkVOLVVTIj4xMzwvc3Bhbj7ml6U8 c3BhbiBsYW5nPSJFTi1VUyI+IDk6MjA8YnI+DQo8L3NwYW4+5pS25Lu25Lq6PHNwYW4gbGFuZz0i RU4tVVMiPjogPGEgaHJlZj0ibWFpbHRvOmktZC1hbm5vdW5jZUBpZXRmLm9yZyI+aS1kLWFubm91 bmNlQGlldGYub3JnPC9hPjxicj4NCjwvc3Bhbj7kuLvpopg8c3BhbiBsYW5nPSJFTi1VUyI+OiBJ LUQgQWN0aW9uOiBkcmFmdC13dS1sM3NtLXJmYzgwNDliaXMtMDYudHh0PGJyPg0KPGJyPg0KPGJy Pg0KQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50 ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLjxicj4NCjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyBUaXRsZSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7OiBZQU5HIERhdGEgTW9kZWwgZm9yIEwzVlBOIFNlcnZpY2UgRGVsaXZlcnk8YnI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgQXV0aG9ycyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDs6IFFpbiBXdTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBT dGVwaGFuZSBMaXRrb3dza2k8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg THVpcyBUb21vdGFraTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBLZW5p Y2hpIE9nYWtpPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEZpbGVuYW1lJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDogZHJhZnQtd3UtbDNzbS1yZmM4MDQ5YmlzLTA2LnR4dDxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBQYWdlcyZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7OiAxODM8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgRGF0ZSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDogMjAxNy0x MC0xMjxicj4NCjxicj4NCkFic3RyYWN0Ojxicj4NCiZuYnNwOyAmbmJzcDtUaGlzIGRvY3VtZW50 IGRlZmluZXMgYSBZQU5HIGRhdGEgbW9kZWwgdGhhdCBjYW4gYmUgdXNlZCBmb3I8YnI+DQombmJz cDsgJm5ic3A7Y29tbXVuaWNhdGlvbiBiZXR3ZWVuIGN1c3RvbWVycyBhbmQgbmV0d29yayBvcGVy YXRvcnMgYW5kIHRvIGRlbGl2ZXI8YnI+DQombmJzcDsgJm5ic3A7YSBMYXllciAzIHByb3ZpZGVy LXByb3Zpc2lvbmVkIFZQTiBzZXJ2aWNlLiZuYnNwOyBUaGlzIGRvY3VtZW50IGlzIGxpbWl0ZWQ8 YnI+DQombmJzcDsgJm5ic3A7dG8gQkdQIFBFLWJhc2VkIFZQTnMgYXMgZGVzY3JpYmVkIGluIFJG Q3MgNDAyNiwgNDExMCwgYW5kIDQzNjQuJm5ic3A7IFRoaXM8YnI+DQombmJzcDsgJm5ic3A7bW9k ZWwgaXMgaW50ZW5kZWQgdG8gYmUgaW5zdGFudGlhdGVkIGF0IHRoZSBtYW5hZ2VtZW50IHN5c3Rl bSB0bzxicj4NCiZuYnNwOyAmbmJzcDtkZWxpdmVyIHRoZSBvdmVyYWxsIHNlcnZpY2UuJm5ic3A7 IEl0IGlzIG5vdCBhIGNvbmZpZ3VyYXRpb24gbW9kZWwgdG8gYmU8YnI+DQombmJzcDsgJm5ic3A7 dXNlZCBkaXJlY3RseSBvbiBuZXR3b3JrIGVsZW1lbnRzLiZuYnNwOyBUaGlzIG1vZGVsIHByb3Zp ZGVzIGFuIGFic3RyYWN0ZWQ8YnI+DQombmJzcDsgJm5ic3A7dmlldyBvZiB0aGUgTGF5ZXIgMyBJ UCBWUE4gc2VydmljZSBjb25maWd1cmF0aW9uIGNvbXBvbmVudHMuJm5ic3A7IEl0IHdpbGw8YnI+ DQombmJzcDsgJm5ic3A7YmUgdXAgdG8gdGhlIG1hbmFnZW1lbnQgc3lzdGVtIHRvIHRha2UgdGhp cyBtb2RlbCBhcyBpbnB1dCBhbmQgdXNlPGJyPg0KJm5ic3A7ICZuYnNwO3NwZWNpZmljIGNvbmZp Z3VyYXRpb24gbW9kZWxzIHRvIGNvbmZpZ3VyZSB0aGUgZGlmZmVyZW50IG5ldHdvcms8YnI+DQom bmJzcDsgJm5ic3A7ZWxlbWVudHMgdG8gZGVsaXZlciB0aGUgc2VydmljZS4mbmJzcDsgSG93IHRo ZSBjb25maWd1cmF0aW9uIG9mIG5ldHdvcms8YnI+DQombmJzcDsgJm5ic3A7ZWxlbWVudHMgaXMg ZG9uZSBpcyBvdXQgb2Ygc2NvcGUgZm9yIHRoaXMgZG9jdW1lbnQuPGJyPg0KPGJyPg0KJm5ic3A7 ICZuYnNwO0lmIGFwcHJvdmVkLCB0aGlzIGRvY3VtZW50IG9ic29sZXRlcyBSRkMgODA0OS4mbmJz cDsgVGhlIGNoYW5nZXMgYXJlIGE8YnI+DQombmJzcDsgJm5ic3A7c2VyaWVzIG9mIHNtYWxsIGZp eGVzIHRvIHRoZSBZQU5HIG1vZHVsZSwgYW5kIHNvbWUgY2xhcmlmaWNhdGlvbnMgdG88YnI+DQom bmJzcDsgJm5ic3A7dGhlIHRleHQuPGJyPg0KPGJyPg0KPGJyPg0KVGhlIElFVEYgZGF0YXRyYWNr ZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtd3UtbDNzbS1yZmM4MDQ5YmlzLyIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXd1LWwzc20t cmZjODA0OWJpcy88L2E+PGJyPg0KPGJyPg0KVGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVyc2lv bnMgYXZhaWxhYmxlIGF0Ojxicj4NCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC13dS1sM3NtLXJmYzgwNDliaXMtMDYiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd3UtbDNzbS1yZmM4MDQ5YmlzLTA2PC9hPjxicj4NCjxh IGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtd3UtbDNz bS1yZmM4MDQ5YmlzLTA2IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvaHRtbC9kcmFmdC13dS1sM3NtLXJmYzgwNDliaXMtMDY8L2E+PGJyPg0KPGJyPg0K QSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Ojxicj4NCjxh IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC13dS1sM3NtLXJm YzgwNDliaXMtMDYiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZm P3VybDI9ZHJhZnQtd3UtbDNzbS1yZmM4MDQ5YmlzLTA2PC9hPjxicj4NCjxicj4NCjxicj4NClBs ZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0 aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJl IGF2YWlsYWJsZSBhdA0KPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+dG9vbHMuaWV0Zi5vcmc8L2E+Ljxicj4NCjxicj4NCkludGVybmV0LURyYWZ0cyBhcmUg YWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDo8YnI+DQo8YSBocmVmPSJmdHA6Ly9m dHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLyIgdGFyZ2V0PSJfYmxhbmsiPmZ0cDovL2Z0cC5p ZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvPC9hPjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KSS1ELUFubm91bmNlIG1haWxpbmcg bGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpJLUQtQW5ub3VuY2VAaWV0Zi5vcmciPkktRC1Bbm5v dW5jZUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2ktZC1hbm5vdW5jZUludGVybmV0LURyYWZ0IiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2U8YnI+DQpJ bnRlcm5ldC1EcmFmdDwvYT4gZGlyZWN0b3JpZXM6IDxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5v cmcvc2hhZG93Lmh0bWwiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hh ZG93Lmh0bWw8L2E+IG9yIDxhIGhyZWY9ImZ0cDovL2Z0cC5pZXRmLm9yZy9pZXRmLzFzaGFkb3ct c2l0ZXMudHh0IiB0YXJnZXQ9Il9ibGFuayI+DQpmdHA6Ly9mdHAuaWV0Zi5vcmcvaWV0Zi8xc2hh ZG93LXNpdGVzLnR4dDwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_B8F9A780D330094D99AF023C5877DABA9ABAF6ADnkgeml513mbxchi_-- From nobody Sat Oct 14 20:57:42 2017 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 89E701321AC; Sat, 14 Oct 2017 20:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.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 PPnq6rDfu60L; Sat, 14 Oct 2017 20:57:38 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-oln040092007102.outbound.protection.outlook.com [40.92.7.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97CB21241F3; Sat, 14 Oct 2017 20:57:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=kQcBMTD5sYKIneQKXgZwJxg86ryA75Sc6s4kFK8aucU=; b=jon7XcC6CfIkXXXRseiJQUZ+Lhsyh+57SSq5j9tCqTJWsLCi57zY8x5YY/QzIgCJzhAJNDUtMvrVy+762nLvTkN4bl+aQv9sed93fmbHqs/wY/7M/fpjYfgKwz2XjSARn70eiTo0ndhaa8VSnI70O8tRnnpQaAvGdhFnloenRz3iVyMpjxg7+BYX0C3VtCd6Tlo0dYftYl5R2u1wQEhyRaFYTp40odknMHTDWGpsu4CtOwNhC0PONhdWiTKU48mBp9cnB2VrOG1xMKYwWP9MzlafiasLVZrRTjXVl062G6ruhIU+9ce1RhaCg/0574kCIR58t1nag7XRSnt0aPNd/g== Received: from DM3NAM03FT010.eop-NAM03.prod.protection.outlook.com (10.152.82.54) by DM3NAM03HT089.eop-NAM03.prod.protection.outlook.com (10.152.83.195) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.77.10; Sun, 15 Oct 2017 03:57:34 +0000 Received: from CY4PR1701MB1926.namprd17.prod.outlook.com (10.152.82.58) by DM3NAM03FT010.mail.protection.outlook.com (10.152.82.65) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.77.10 via Frontend Transport; Sun, 15 Oct 2017 03:57:34 +0000 Received: from CY4PR1701MB1926.namprd17.prod.outlook.com ([10.171.212.143]) by CY4PR1701MB1926.namprd17.prod.outlook.com ([10.171.212.143]) with mapi id 15.20.0077.022; Sun, 15 Oct 2017 03:57:34 +0000 From: Charlie Kaufman To: "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-lime-yang-connectionless-oam.all@ietf.org" Thread-Topic: secdir review of draft-ietf-lime-yang-connectionless-oam-11 Thread-Index: AQHTRWlfh4+GQ0heREaViILKKGb1NQ== Date: Sun, 15 Oct 2017 03:57:34 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:AB8873852CB4FF7BAA4780100D6301AF852EC657B3A55BC6253C5DD0D14335C8; UpperCasedChecksum:D8639F325D3ADC83A5DC227982815625ED89261A0522BDC24E4C4ACC57B55B79; SizeAsReceived:7191; Count:44 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [wEGerpBpuVT9tliF1DjA6db1BjRRTmi0JShksF7WG5vKy2yETeW/auiHcCdhdUn0] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM3NAM03HT089; 6:SEHNKwro/Jt2idiLxfKHZKSfxaZn+4+zd6Pr15UQegcVaRzLVdq5FNZgRgZlHVKZsfPDAkVOd25BHVg8bG2aE1aU8J9iq7Hqj0PsEhf7h7lxbPhUWhMJyGQ96rnLAu8PE9j6yYuLlI9IlRmnou1ipd8AVq1vs+qYccyQc4vXikIsjx0BmSP0QCp+YUkBl4pXCBjdZRzmYIbB4k0c0mMZYAaMtEgAr/nDx8gr9oDx4FpGnVOOtsQ/Bb2mQbjTVHc7KmLWyc275WaIzErpbop3rTCSkKqjjsulSzkCoobDirm4L0IfPUvqkCFJT6eUZTYy/pGnThOFLCaAiG7FsEZeoA==; 5:pN7kMq/SC+r5eaX+JplTCZuR9/uhB47S/KsMY0HM39g/SWpP9T/Th4hI9tQR+QaQNk53sjlx04kvo3L3VwnBGRZV8XhzHydBCmS/NNe1gJHcM7MQJGrUXUQXfESOlqL0vEw3+G9IU4XNKOjSD0SzfQ==; 24:tbqZ5H/MjTRdAO5EB6NscuuaWyp4unnjlOTtMF0g0qvByK5EQOpKtp7i35GnE8yYukaGqSeHobvs69HbWVgUEAjVatNQ+zg8nJ5JGVydxi4=; 7:yHFNF0v9QHeUVVYPjayjzANBMqmH5qg+IikJLLyz/lZoYe14G+vLhJOrAPgB955AYy88NCF8b14cFanpk0zSZ+uHawoXOsmKSkGU1FAdlLzCIsEf2tA2i21xj2qiFl8PrM79QWVtKFbqlvHskuAh8XH8PtosAyhusme3KhUIbCLJYP86rwrhGpUkitGdADIMsL5ixwtkVtk4PrxHfEI/sguiEg/r7Fww3Ls4cmi2BFg= x-incomingheadercount: 44 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: 71bb2585-8fc7-4786-e84c-08d51380de05 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1601125374)(1603101448)(1701031045); SRVR:DM3NAM03HT089; x-ms-traffictypediagnostic: DM3NAM03HT089: authentication-results: outbound.protection.outlook.com; spf=skipped (originating message); dkim=none (message not signed) header.d=none; dmarc=none action=none header.from=outlook.com; x-exchange-antispam-report-test: UriScan:(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(444000031); SRVR:DM3NAM03HT089; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM3NAM03HT089; x-forefront-prvs: 046164D5C4 x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:DM3NAM03HT089; H:CY4PR1701MB1926.namprd17.prod.outlook.com; FPR:; SPF:None; LANG:; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR1701MB1926E502B5738D79557613EADF4E0CY4PR1701MB1926_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Oct 2017 03:57:34.3838 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM3NAM03HT089 Archived-At: Subject: [secdir] secdir review of draft-ietf-lime-yang-connectionless-oam-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Oct 2017 03:57:40 -0000 --_000_CY4PR1701MB1926E502B5738D79557613EADF4E0CY4PR1701MB1926_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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 co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments. This document defines a data structure and defines a data transfer syntax f= or retrieving and sometimes setting routing configuration information from = network intermediaries and possibly network endpoints. This document is pretty much unreadable unless one is immersed in the arcan= e world of OAM YANG models. I remember having the same reaction to MIB RFCs= . That's not a criticism... just acknowledging my lack of qualification to = do this review. That said, I have some observations/feedback. Documents not intended to be readable by outsiders should include in the in= troduction a reference to documents that the reader is expected to have rea= d before reading this one. I made it through most of the document before re= alizing I had (probably) misparsed the title (I'm still not sure). I assume= d this specified something related to "Connectionless Operations, Administr= ation, and Maintenance Protocols" since those are the last words of the tit= le. The fact that the Introduction used Ping and Traceroute as protocols th= at this protocol wanted to generalize reinforced that view. Such protocols = have severe security issues because there is effectively no way to add encr= yption, authentication, and authorization to them. But the Security Conside= rations section specifies that these protocols are intended to be layered o= ver NETCONF or RESTCONF (both connection-oriented protocols that can be run= over secure transports). So I now believe this document is about accessing= configuration information that concerns connectionless protocols, but that= it is not intended to run over connectionless protocols. But the data type= s defined appear to be of interest to both connectionless and connection or= iented data transfer. If I have this wrong, then there are serious problems= with security. If not, then it is probably fine. Formatting Glitches / Typos: Throughout the document, there seems to be a problem with spaces erroneous= ly inserted and removed near single quotes and the sequence: "e.g..". A par= ticularly dramatic example is at the top of page 5: 'grouping is chosen based on 'tp-location-type' leaf which when chosen, leads to a container that includes a list of 'test-point- locations' keyed by technology specific keys(e.g., 'ipv4-location'leaf). Each test point location under 'test-point- locations 'grouping includes a 'test-point-location-info' grouping. I believe Section 3.6 has a wording error exacerbated by the space problem.= In any case, I could not parse the following: Path discovery includes data to be retrieved on a 'per- hop' basis via a list of 'path-trace-info- list'list which includes information like 'timestamp'grouping, ' ingress-intf-name ', ' egress-intf-name ' and 'app-meta-data'. Starting on page 21, there appear to be many lines that exceed the maximum = length for an RFC. This causes the PDF rendering to switch to a smaller fon= t for the pages that contain the long lines. Awkward English in section 5.2.1.2: To support lsp-ping, the "ietf-connectionless-oam" model can be extended and add lsp-ping specific parameters can be defined and under "test-point-location" list. User can reuse the attributes or groupings which are defined in [I-D.zheng-mpls-lsp-ping-yang-cfg] as follows: The snippet below depicts an example of augmenting the "test-point- locations" list with lsp ping attributes: --_000_CY4PR1701MB1926E502B5738D79557613EADF4E0CY4PR1701MB1926_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I have reviewed this document as part of the security directorate's ongo= ing 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 defines a data structure and defines a data transfer synta= x for retrieving and sometimes setting routing configuration information fr= om network intermediaries and possibly network endpoints.


This document is pretty much unreadable unless one is immersed in the ar= cane world of OAM YANG models. I remember having the same reaction to MIB R= FCs. That's not a criticism... just acknowledging my lack of qualification = to do this review. That said, I have some observations/feedback.

Documents not intended to be readable by outsiders should include in the= introduction a reference to documents that the reader is expected to have = read before reading this one. I made it through most of the document before= realizing I had (probably) misparsed the title (I'm still not sure). I assumed this specified something related= to "Connectionless Operations, Administration, and Maintenance Protoc= ols" since those are the last words of the title. The fact that the In= troduction used Ping and Traceroute as protocols that this protocol wanted to generalize reinforced that view. Such protoco= ls have severe security issues because there is effectively no way to add e= ncryption, authentication, and authorization to them. But the Security Cons= iderations section specifies that these protocols are intended to be layered over NETCONF or RESTCONF (both = connection-oriented protocols that can be run over secure transports). So I= now believe this document is about accessing configuration information tha= t concerns connectionless protocols, but that it is not intended to run over connectionless protocols. But the = data types defined appear to be of interest to both connectionless and conn= ection oriented data transfer. If I have this wrong, then there are serious= problems with security. If not, then it is probably fine.


Formatting Glitches / Typos:


Throughout the document, there seems to be a problem with  spaces e= rroneously inserted and removed near single quotes and the sequence: "= e.g..". A particularly dramatic example is at the top of page 5:

   'grouping is chosen based on 'tp-location-type' leaf which = when
   chosen, leads to a container that includes a list of 'test-poi= nt-
   locations' keyed by technology specific keys(e.g.,
   'ipv4-location'leaf).  Each test point location under 'te= st-point-
   locations 'grouping includes a 'test-point-location-info' grou= ping.


I believe Section 3.6 has a wording error exacerbated by the space probl= em. In any case, I could not parse the following:

   Path discovery includes data to be
   retrieved on a 'per- hop' basis via a list of 'path-trace-info= -
   list'list which includes information like 'timestamp'grouping,= '
   ingress-intf-name ', ' egress-intf-name ' and 'app-meta-data'.=


Starting on page 21, there appear to be many lines that exceed the maxim= um length for an RFC. This causes the PDF rendering to switch to a smaller = font for the pages that contain the long lines.


Awkward English in section 5.2.1.2:

   To support lsp-ping, the "ietf-connectionless-oam"= ; model can be
   extended and add lsp-ping specific parameters can be defined a= nd
   under "test-point-location" list.

   User can reuse the attributes or groupings which are define= d in
   [I-D.zheng-mpls-lsp-ping-yang-cfg] as follows:

   The snippet below depicts an example of augmenting the &quo= t;test-point-
   locations" list with lsp ping attributes:



--_000_CY4PR1701MB1926E502B5738D79557613EADF4E0CY4PR1701MB1926_-- From nobody Sun Oct 15 09:38:18 2017 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 30A4E1331D2; Sun, 15 Oct 2017 09:38:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Christian Huitema To: Cc: lwip@ietf.org, ietf@ietf.org, draft-ietf-lwig-crypto-sensors.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150808549717.12118.1993584722866227993@ietfa.amsl.com> Date: Sun, 15 Oct 2017 09:38:17 -0700 Archived-At: Subject: [secdir] Secdir early review of draft-ietf-lwig-crypto-sensors-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Oct 2017 16:38:17 -0000 Reviewer: Christian Huitema Review result: Has Nits This is an early review of draft-ietf-lwig-crypto-sensors-04 on behalf of the Security Directorate. The document is almost ready, but would benefit from a bit more further work. This draft examines a series of risks and challenges posed by securing small devices, proposes solutions for provisioning, and an architecture for securing the devices. The implementation experience section (section 8) provides measurements for the memory and CPU costs of various cryptographic operations using the Arduino platform. It will be good to see these results published and become a useful reference in further debates. In fact, I like this document a lot. My only concern is that it misses an opportunity to discuss identifiers and privacy. I like the discussion of platform constraints in section 3, and the statement that "at the end of the day, if strong cryptographic security is needed, the implementations have to support that." I think it is an important message, and it it might be good to reinfore it with examples. For example, we do ship medecine in child-proof containers. It would be cheaper to use ordinary containers, but we pay the cost because as a society we want to mitigate the risk of children mistaking pills for candy. Similarly, it is cheaper to build devices with no security, but we may want society to mandate that risks should be mitigated. The challenge section, and the document in general, would be even better if it included a discussion of identifiers and privacy. The general concern is that because small devices have limited resource, they end up using just one identity, maybe just one public key. This makes them easy to track when they move, and by extension track the movements of their owners for wearable devices, or associated objects such as cars for general devices. There are certainly mitigations, such as provisioning new identities at appropriate times, or using temporary identities in communication protocols, but these mitigations certainly require the kind of trade-offs discussed in the draft. It would thus be very nice to introduce the privacy challenges in the "challenge" section, and to discuss the privacy mitigations in the other sections, e.g., architecture and provisioning. From nobody Mon Oct 16 03:40:23 2017 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 64393132F69; Mon, 16 Oct 2017 03:40:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yN_WFnPldZAV; Mon, 16 Oct 2017 03:40:14 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 536A31270AB; Mon, 16 Oct 2017 03:40:13 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DQS66491; Mon, 16 Oct 2017 10:40:11 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.361.1; Mon, 16 Oct 2017 11:40:09 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.105]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Mon, 16 Oct 2017 18:40:05 +0800 From: Qin Wu To: Charlie Kaufman , "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-lime-yang-connectionless-oam.all@ietf.org" Thread-Topic: secdir review of draft-ietf-lime-yang-connectionless-oam-11 Thread-Index: AQHTRWlfh4+GQ0heREaViILKKGb1NaLmQMcQ Date: Mon, 16 Oct 2017 10:40:04 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.79.163] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA9ABE5A76nkgeml513mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090206.59E48C8B.0080, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.105, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: e137d978251286e2d4c07c6966d1c4d4 Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-lime-yang-connectionless-oam-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 10:40:17 -0000 --_000_B8F9A780D330094D99AF023C5877DABA9ABE5A76nkgeml513mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 Q2hhcmxpZToNClRoYW5rIGZvciB2YWx1YWJsZSByZXZpZXcgdG8gdGhpcyBkb2N1bWVudCwgcGxl YXNlIHNlZSBteSByZXBseSBpbmxpbmUgYmVsb3cgbWFya2VkIHdpdGggW1Fpbl0NCreivP7Iyzog Q2hhcmxpZSBLYXVmbWFuIFttYWlsdG86Y2hhcmxpZWthdWZtYW5Ab3V0bG9vay5jb21dDQq3osvN yrG85DogMjAxN8TqMTDUwjE1yNUgMTE6NTgNCsrVvP7Iyzogc2VjZGlyQGlldGYub3JnOyBpZXNn QGlldGYub3JnOyBkcmFmdC1pZXRmLWxpbWUteWFuZy1jb25uZWN0aW9ubGVzcy1vYW0uYWxsQGll dGYub3JnDQrW98ziOiBzZWNkaXIgcmV2aWV3IG9mIGRyYWZ0LWlldGYtbGltZS15YW5nLWNvbm5l Y3Rpb25sZXNzLW9hbS0xMQ0KDQoNCkkgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBh cnQgb2YgdGhlIHNlY3VyaXR5IGRpcmVjdG9yYXRlJ3Mgb25nb2luZyBlZmZvcnQgdG8gcmV2aWV3 IGFsbCBJRVRGIGRvY3VtZW50cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhlIElFU0cuICBUaGVzZSBj b21tZW50cyB3ZXJlIHdyaXR0ZW4gcHJpbWFyaWx5IGZvciB0aGUgYmVuZWZpdCBvZiB0aGUgc2Vj dXJpdHkgYXJlYSBkaXJlY3RvcnMuICBEb2N1bWVudCBlZGl0b3JzIGFuZCBXRyBjaGFpcnMgc2hv dWxkIHRyZWF0IHRoZXNlIGNvbW1lbnRzIGp1c3QgbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNv bW1lbnRzLg0KDQoNCg0KVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgZGF0YSBzdHJ1Y3R1cmUgYW5k IGRlZmluZXMgYSBkYXRhIHRyYW5zZmVyIHN5bnRheCBmb3IgcmV0cmlldmluZyBhbmQgc29tZXRp bWVzIHNldHRpbmcgcm91dGluZyBjb25maWd1cmF0aW9uIGluZm9ybWF0aW9uIGZyb20gbmV0d29y ayBpbnRlcm1lZGlhcmllcyBhbmQgcG9zc2libHkgbmV0d29yayBlbmRwb2ludHMuDQoNCg0KDQpU aGlzIGRvY3VtZW50IGlzIHByZXR0eSBtdWNoIHVucmVhZGFibGUgdW5sZXNzIG9uZSBpcyBpbW1l cnNlZCBpbiB0aGUgYXJjYW5lIHdvcmxkIG9mIE9BTSBZQU5HIG1vZGVscy4gSSByZW1lbWJlciBo YXZpbmcgdGhlIHNhbWUgcmVhY3Rpb24gdG8gTUlCIFJGQ3MuIFRoYXQncyBub3QgYSBjcml0aWNp c20uLi4ganVzdCBhY2tub3dsZWRnaW5nIG15IGxhY2sgb2YgcXVhbGlmaWNhdGlvbiB0byBkbyB0 aGlzIHJldmlldy4gVGhhdCBzYWlkLCBJIGhhdmUgc29tZSBvYnNlcnZhdGlvbnMvZmVlZGJhY2su DQoNCkRvY3VtZW50cyBub3QgaW50ZW5kZWQgdG8gYmUgcmVhZGFibGUgYnkgb3V0c2lkZXJzIHNo b3VsZCBpbmNsdWRlIGluIHRoZSBpbnRyb2R1Y3Rpb24gYSByZWZlcmVuY2UgdG8gZG9jdW1lbnRz IHRoYXQgdGhlIHJlYWRlciBpcyBleHBlY3RlZCB0byBoYXZlIHJlYWQgYmVmb3JlIHJlYWRpbmcg dGhpcyBvbmUuDQoNCg0KDQpbUWluXTogUGxlYXNlIHJlYWQgUkZDNjA4NyB3aGljaCBwcm92aWRl IEd1aWRlbGluZXMgZm9yIEF1dGhvcnMgYW5kIFJldmlld2VycyBvZiBZQU5HIERhdGEgTW9kZWwg RG9jdW1lbnRzIGFuZCBSRkM3OTUwIGFuZCBSRkM2MDIyIHdoaWNoIGRlZmluZXMgdGhlIFlBTkcg ZGF0YSBtb2RlbGluZyBsYW5ndWFnZSBiZWZvcmUgcmVhZGluZyB0aGlzIG9uZS4NCg0KV2UgY2Fu IGFkZCBhIHN0YXRlbWVudCB0byBzYXkNCg0KobBUaGUgcmVhZGVyIGlzIGV4cGVjdGVkIHRvIGtu b3cgdGhlIFlBTkcgZGF0YSBtb2RlbGluZyBsYW5ndWFnZSBbUkZDNzk1MF0gYW5kIEd1aWRlbGlu ZXMgZm9yIEF1dGhvcnMgYW5kIFJldmlld2VycyBvZiBZQU5HIERhdGEgTW9kZWwgRG9jdW1lbnRz IFtSRkM2MDg3XWJlZm9yZSB1c2luZyB0aGlzIGRvY3VtZW50LqGxDQoNCklmIHlvdSB0aGluayBu ZWNlc3NhcnkuIEJ1dCBub3RlIHRoYXQgdGhpcyBpcyBub3QgdHJhZGl0aW9uIG9yIGNvbnZlbnRp b24gdG8gYWRkIHRoaXMgc3RhdGVtZW50IGZvciBZQU5HIGRhdGEgbW9kZWxpbmcgc3RhbmRhcmRz Lg0KDQoNCg0KSSBtYWRlIGl0IHRocm91Z2ggbW9zdCBvZiB0aGUgZG9jdW1lbnQgYmVmb3JlIHJl YWxpemluZyBJIGhhZCAocHJvYmFibHkpIG1pc3BhcnNlZCB0aGUgdGl0bGUgKEknbSBzdGlsbCBu b3Qgc3VyZSkuIEkgYXNzdW1lZCB0aGlzIHNwZWNpZmllZCBzb21ldGhpbmcgcmVsYXRlZCB0byAi Q29ubmVjdGlvbmxlc3MgT3BlcmF0aW9ucywgQWRtaW5pc3RyYXRpb24sIGFuZCBNYWludGVuYW5j ZSBQcm90b2NvbHMiIHNpbmNlIHRob3NlIGFyZSB0aGUgbGFzdCB3b3JkcyBvZiB0aGUgdGl0bGUu IFRoZSBmYWN0IHRoYXQgdGhlIEludHJvZHVjdGlvbiB1c2VkIFBpbmcgYW5kIFRyYWNlcm91dGUg YXMgcHJvdG9jb2xzIHRoYXQgdGhpcyBwcm90b2NvbCB3YW50ZWQgdG8gZ2VuZXJhbGl6ZSByZWlu Zm9yY2VkIHRoYXQgdmlldy4gU3VjaCBwcm90b2NvbHMgaGF2ZSBzZXZlcmUgc2VjdXJpdHkgaXNz dWVzIGJlY2F1c2UgdGhlcmUgaXMgZWZmZWN0aXZlbHkgbm8gd2F5IHRvIGFkZCBlbmNyeXB0aW9u LCBhdXRoZW50aWNhdGlvbiwgYW5kIGF1dGhvcml6YXRpb24gdG8gdGhlbS4gQnV0IHRoZSBTZWN1 cml0eSBDb25zaWRlcmF0aW9ucyBzZWN0aW9uIHNwZWNpZmllcyB0aGF0IHRoZXNlIHByb3RvY29s cyBhcmUgaW50ZW5kZWQgdG8gYmUgbGF5ZXJlZCBvdmVyIE5FVENPTkYgb3IgUkVTVENPTkYgKGJv dGggY29ubmVjdGlvbi1vcmllbnRlZCBwcm90b2NvbHMgdGhhdCBjYW4gYmUgcnVuIG92ZXIgc2Vj dXJlIHRyYW5zcG9ydHMpLg0KDQpbUWluXTogd2hhdCB3ZSBkZWZpbmUgaW4gdGhpcyBkcmFmdCBp cyBkYXRhIG1vZGVsIG5vdCBuZXcgcHJvdG9jb2wsIHRoZSBwcm90b2NvbCB3ZSBhcmUgdXNpbmcg dG8gY2FycnkgbW9kZWxlZCBkYXRhIGlzIG5ldGNvbmYgb3IgcmVzdGNvbmYsIG5ldGNvbmYgb3Ig cmVzdGNvbmYgcnVucyBvbiB0b3Agb2Ygc2VjdXJlIHRyYW5zcG9ydCBzdWNoIGFzIFNTSC4NCg0K U28gSSBub3cgYmVsaWV2ZSB0aGlzIGRvY3VtZW50IGlzIGFib3V0IGFjY2Vzc2luZyBjb25maWd1 cmF0aW9uIGluZm9ybWF0aW9uIHRoYXQgY29uY2VybnMgY29ubmVjdGlvbmxlc3MgcHJvdG9jb2xz LCBidXQgdGhhdCBpdCBpcyBub3QgaW50ZW5kZWQgdG8gcnVuIG92ZXIgY29ubmVjdGlvbmxlc3Mg cHJvdG9jb2xzLg0KDQpbUWluXTogQ29ycmVjdCwgY29ubmVjdGlvbmxlc3MgcHJvdG9jb2xzIGlz IGVhc3Qgd2VzdCBwcm90b2NvbCB1c2VkIHRvIGdlbmVyYXRlIGRhdGEgb3IgdHJvdWJsZXNob290 aW5nIHJlc3VsdHMsICBhbmQgTkVUQ09ORisgdGhlIG1vZGVsIGRlZmluZWQgaW4gdGhpcyBkcmFm dCBjYW4gYmUgdXNlZCB0byBjb25maWd1cmUgdGhlIHBhcmFtZXRlcnMgdGhhdCBhcmUgbmVlZGVk IGZvciBjb25uZWN0aW9ubGVzcyBwcm90b2NvbHMgYW5kIGFsc28gZXhwb3J0IGRhdGEgb3IgdHJv dWJsZXNob290aW5nIHJlc3VsdHMgYmFjayBmcm9tIHRlc3QgZGV2aWNlIHRvIHRoZSBtYW5hZ2Vt ZW50IHN5c3RlbS4NCg0KQnV0IHRoZSBkYXRhIHR5cGVzIGRlZmluZWQgYXBwZWFyIHRvIGJlIG9m IGludGVyZXN0IHRvIGJvdGggY29ubmVjdGlvbmxlc3MgYW5kIGNvbm5lY3Rpb24gb3JpZW50ZWQg ZGF0YSB0cmFuc2Zlci4gSWYgSSBoYXZlIHRoaXMgd3JvbmcsIHRoZW4gdGhlcmUgYXJlIHNlcmlv dXMgcHJvYmxlbXMgd2l0aCBzZWN1cml0eS4gSWYgbm90LCB0aGVuIGl0IGlzIHByb2JhYmx5IGZp bmUuDQoNCltRaW5dOiBDb3JyZWN0LCBwbGVhc2Ugc2VlDQoNCmh0dHBzOi8vdHJhYy5pZXRmLm9y Zy90cmFjL29wcy93aWtpL3lhbmctc2VjdXJpdHktZ3VpZGVsaW5lcw0KDQp3ZSBmb2xsb3dzIHRo aXMgWUFORyBzZWN1cml0eSBndWlkZWxpbmVzIHRvIHdyaXRlIHRoaXMgc2VjdXJpdHkgY29uc2lk ZXJhdGlvbiBzZWN0aW9uLg0KDQoNCg0KRm9ybWF0dGluZyBHbGl0Y2hlcyAvIFR5cG9zOg0KDQoN Cg0KVGhyb3VnaG91dCB0aGUgZG9jdW1lbnQsIHRoZXJlIHNlZW1zIHRvIGJlIGEgcHJvYmxlbSB3 aXRoICBzcGFjZXMgZXJyb25lb3VzbHkgaW5zZXJ0ZWQgYW5kIHJlbW92ZWQgbmVhciBzaW5nbGUg cXVvdGVzIGFuZCB0aGUgc2VxdWVuY2U6ICJlLmcuLiIuIEEgcGFydGljdWxhcmx5IGRyYW1hdGlj IGV4YW1wbGUgaXMgYXQgdGhlIHRvcCBvZiBwYWdlIDU6DQoNCiAgICdncm91cGluZyBpcyBjaG9z ZW4gYmFzZWQgb24gJ3RwLWxvY2F0aW9uLXR5cGUnIGxlYWYgd2hpY2ggd2hlbg0KICAgY2hvc2Vu LCBsZWFkcyB0byBhIGNvbnRhaW5lciB0aGF0IGluY2x1ZGVzIGEgbGlzdCBvZiAndGVzdC1wb2lu dC0NCiAgIGxvY2F0aW9ucycga2V5ZWQgYnkgdGVjaG5vbG9neSBzcGVjaWZpYyBrZXlzKGUuZy4s DQogICAnaXB2NC1sb2NhdGlvbidsZWFmKS4gIEVhY2ggdGVzdCBwb2ludCBsb2NhdGlvbiB1bmRl ciAndGVzdC1wb2ludC0NCiAgIGxvY2F0aW9ucyAnZ3JvdXBpbmcgaW5jbHVkZXMgYSAndGVzdC1w b2ludC1sb2NhdGlvbi1pbmZvJyBncm91cGluZy4NCg0KDQoNCltRaW5dOkdvb2QgY2F0Y2hpbmcg YW5kIGhhdmUgZ290IHRoaXMgZml4ZWQuDQoNCg0KDQpJIGJlbGlldmUgU2VjdGlvbiAzLjYgaGFz IGEgd29yZGluZyBlcnJvciBleGFjZXJiYXRlZCBieSB0aGUgc3BhY2UgcHJvYmxlbS4gSW4gYW55 IGNhc2UsIEkgY291bGQgbm90IHBhcnNlIHRoZSBmb2xsb3dpbmc6DQoNCiAgIFBhdGggZGlzY292 ZXJ5IGluY2x1ZGVzIGRhdGEgdG8gYmUNCiAgIHJldHJpZXZlZCBvbiBhICdwZXItIGhvcCcgYmFz aXMgdmlhIGEgbGlzdCBvZiAncGF0aC10cmFjZS1pbmZvLQ0KICAgbGlzdCdsaXN0IHdoaWNoIGlu Y2x1ZGVzIGluZm9ybWF0aW9uIGxpa2UgJ3RpbWVzdGFtcCdncm91cGluZywgJw0KICAgaW5ncmVz cy1pbnRmLW5hbWUgJywgJyBlZ3Jlc3MtaW50Zi1uYW1lICcgYW5kICdhcHAtbWV0YS1kYXRhJy4N Cg0KDQoNCltRaW5dOiBJbiBhbGwgaW5mb3JtYXRpb24gaW5jbHVkZWQgaW4goa5wYXRoLXRyYWNl LWluZm8tbGlzdKGvICwgb25seSChrnRpbWVzdGFtcKGvIGlzIGRlZmluZWQgYXMgZ3JvdXBpbmcs IKGuaW5ncmVzcy1pbnRmLW5hbWWhryyhr2VncmVzcy1pbnRmLW5hbWWhryyhr2FwcC1tZXRhLWRh dGGhryBhcmUgZGVmaW5lZCBhcyBsZWFmLg0KDQp5ZXMsIHNwYWNlIHdpbGwgYmVlbiByZW1vdmVk DQoNClRoZSBwcm9wb3NlZCBjaGFuZ2UgaXMgYXMgZm9sbG93czoNCg0KobANCg0KICAgUGF0aCBk aXNjb3ZlcnkgaW5jbHVkZXMgZGF0YSB0byBiZQ0KICAgcmV0cmlldmVkIG9uIGEgJ3Blci0gaG9w JyBiYXNpcyB2aWEgYSBsaXN0IG9mICdwYXRoLXRyYWNlLWluZm8tDQogICBsaXN0JyBsaXN0IHdo aWNoIGluY2x1ZGVzIGluZm9ybWF0aW9uIGxpa2UgJ3RpbWVzdGFtcCcsICcNCiAgIGluZ3Jlc3Mt aW50Zi1uYW1lJywgJ2VncmVzcy1pbnRmLW5hbWUnIGFuZCAnYXBwLW1ldGEtZGF0YScuDQoNCqGx DQoNCg0KDQpTdGFydGluZyBvbiBwYWdlIDIxLCB0aGVyZSBhcHBlYXIgdG8gYmUgbWFueSBsaW5l cyB0aGF0IGV4Y2VlZCB0aGUgbWF4aW11bSBsZW5ndGggZm9yIGFuIFJGQy4gVGhpcyBjYXVzZXMg dGhlIFBERiByZW5kZXJpbmcgdG8gc3dpdGNoIHRvIGEgc21hbGxlciBmb250IGZvciB0aGUgcGFn ZXMgdGhhdCBjb250YWluIHRoZSBsb25nIGxpbmVzLg0KDQoNCg0KQXdrd2FyZCBFbmdsaXNoIGlu IHNlY3Rpb24gNS4yLjEuMjoNCg0KICAgVG8gc3VwcG9ydCBsc3AtcGluZywgdGhlICJpZXRmLWNv bm5lY3Rpb25sZXNzLW9hbSIgbW9kZWwgY2FuIGJlDQogICBleHRlbmRlZCBhbmQgYWRkIGxzcC1w aW5nIHNwZWNpZmljIHBhcmFtZXRlcnMgY2FuIGJlIGRlZmluZWQgYW5kDQogICB1bmRlciAidGVz dC1wb2ludC1sb2NhdGlvbiIgbGlzdC4NCg0KICAgVXNlciBjYW4gcmV1c2UgdGhlIGF0dHJpYnV0 ZXMgb3IgZ3JvdXBpbmdzIHdoaWNoIGFyZSBkZWZpbmVkIGluDQogICBbSS1ELnpoZW5nLW1wbHMt bHNwLXBpbmcteWFuZy1jZmddIGFzIGZvbGxvd3M6DQoNCiAgIFRoZSBzbmlwcGV0IGJlbG93IGRl cGljdHMgYW4gZXhhbXBsZSBvZiBhdWdtZW50aW5nIHRoZSAidGVzdC1wb2ludC0NCiAgIGxvY2F0 aW9ucyIgbGlzdCB3aXRoIGxzcCBwaW5nIGF0dHJpYnV0ZXM6DQoNCltRaW5dOiBDb3B5IGFuZCBw YXN0IGVycm9yLiBUaGUgcHJvcG9zZWQgY2hhbmdlIGlzIHRvIGZpeGUgdGhlIGZpcnN0IHNlbnRl bmNlIGFuZCByZW1vdmUgdGhlIHNlY29uZCBzZW50ZW5jZSBhcyBmb2xsb3dzOg0KDQqhsA0KDQog ICBUbyBzdXBwb3J0IGxzcC1waW5nLCB0aGUgImlldGYtY29ubmVjdGlvbmxlc3Mtb2FtIiBtb2Rl bCBjYW4gYmUNCiAgIGV4dGVuZGVkIGFuZCBhZGQgbHNwLXBpbmcgc3BlY2lmaWMgcGFyYW1ldGVy cyB1bmRlciAidGVzdC1wb2ludC1sb2NhdGlvbiIgbGlzdC4NCg0KICAgVGhlIHNuaXBwZXQgYmVs b3cgZGVwaWN0cyBhbiBleGFtcGxlIG9mIGF1Z21lbnRpbmcgdGhlICJ0ZXN0LXBvaW50LQ0KICAg bG9jYXRpb25zIiBsaXN0IHdpdGggbHNwIHBpbmcgYXR0cmlidXRlczoNCg0KobENCg0KVGhhbmtz IQ0KDQoNCg== --_000_B8F9A780D330094D99AF023C5877DABA9ABE5A76nkgeml513mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Charlie:

Thank for = valuable review to this document, please see my reply inline below marked w= ith [Qin]

=B7=A2=BC=FE=C8=CB: Charlie= Kaufman [mailto:charliekaufman@outlook.com]
=B7=A2= =CB=CD=CA=B1=BC=E4: 2017=C4=EA10=D4=C215=C8=D5 11:58
=CA=D5=BC=FE=C8=CB: secdir@ietf.org; iesg@ietf.org; draft-ietf-lime-yang-connectionless= -oam.all@ietf.org
=D6=F7=CC=E2: secdir review of draft-ietf-lime-yang-connectionless-oam-11

 

I have reviewed this document as part of the secu= rity directorate's ongoing effort to review all IETF documents being proces= sed 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 commen= ts.

 

This document defines a data structure and define= s a data transfer syntax for retrieving and sometimes setting routing confi= guration information from network intermediaries and possibly network endpoints.

 

This document is pretty much unreadable unless on= e is immersed in the arcane world of OAM YANG models. I remember having the= same reaction to MIB RFCs. That's not a criticism... just acknowledging my lack of qualification to do this review. That said, I hav= e some observations/feedback.

Documents not intended to be readable by outsider= s should include in the introduction a reference to documents that the read= er is expected to have read before reading this one.

 

[Qin]: Please read RFC6087 whi= ch provide Guidelines for Authors and Reviewers of YANG Data Model Document= s and RFC7950 and RFC6022 which defines the YANG data modeling language before reading this one.

We can add a statement to say

=A1=B0The reader is expected t= o know the YANG data modeling language [RFC7950] and Guidelines for Authors= and Reviewers of YANG Data Model Documents [RFC6087]before using this document.=A1=B1

If you think necessary. But no= te that this is not tradition or convention to add this statement for YANG = data modeling standards.

 

I made it through most of the document before rea= lizing I had (probably) misparsed the title (I'm still not sure). I assumed= this specified something related to "Connectionless Operations, Administration, and Maintenance Protocols" since those are the last w= ords of the title. The fact that the Introduction used Ping and Traceroute = as protocols that this protocol wanted to generalize reinforced that view. = Such protocols have severe security issues because there is effectively no way to add encryption, authentication, and= authorization to them. But the Security Considerations section specifies t= hat these protocols are intended to be layered over NETCONF or RESTCONF (bo= th connection-oriented protocols that can be run over secure transports).<= o:p>

[Qin]: what we define in this = draft is data model not new protocol, the protocol we are using to carry mo= deled data is netconf or restconf, netconf or restconf runs on top of secure transport such as SSH.

So I now believe this document is about accessing= configuration information that concerns connectionless protocols, but that= it is not intended to run over connectionless protocols.

[Qin]: Correct, connectionless= protocols is east west protocol used to generate data or troubleshooting r= esults,  and NETCONF+ the model defined in this draft can be used to configure the parameters that are needed for connectionless pro= tocols and also export data or troubleshooting results back from test devic= e to the management system.

But the data types defined appear to be of intere= st to both connectionless and connection oriented data transfer. If I have = this wrong, then there are serious problems with security. If not, then it is probably fine.

[Qin]: Correct, please see

https://trac.ietf.org/trac/ops/wiki/yang-security-guidel= ines

we follows this YANG security = guidelines to write this security consideration section.<= /p>

 

Formatting Glitches / Typos:

 

Throughout the document, there seems to be a prob= lem with  spaces erroneously inserted and removed near single quotes a= nd the sequence: "e.g..". A particularly dramatic example is at the top of page 5:

   'grouping is chosen based on 'tp-loc= ation-type' leaf which when
   chosen, leads to a container that includes a list of 'test-poi= nt-
   locations' keyed by technology specific keys(e.g.,
   'ipv4-location'leaf).  Each test point location under 'te= st-point-
   locations 'grouping includes a 'test-point-location-info' grou= ping.

 

[Qin]:Good catching and have g= ot this fixed.

 

I believe Section 3.6 has a wording error exacerb= ated by the space problem. In any case, I could not parse the following:

   Path discovery includes data to be    retrieved on a 'per- hop' basis via a list of 'path-trace-info= -
   list'list which includes information like 'timestamp'grouping,= '
   ingress-intf-name ', ' egress-intf-name ' and 'app-meta-data'.=

 

[Qin]: In all information incl= uded in =A1=AEpath-trace-info-list=A1=AF , only =A1=AEtimestamp=A1=AF is de= fined as grouping, =A1=AEingress-intf-name=A1=AF,=A1=AFegress-intf-name=A1= =AF,=A1=AFapp-meta-data=A1=AF are defined as leaf.

yes, space will been removed

The proposed change is as foll= ows:

=A1=B0

   Path discovery includes data to be    retrieved on a 'per- hop' basis via a list of 'path-trace-info= -
   list' list which includes information like 'timestamp', '
   ingress-intf-name', 'egress-intf-name' and 'app-meta-data'.

=A1=B1

 

Starting on page 21, there appear to be many line= s that exceed the maximum length for an RFC. This causes the PDF rendering = to switch to a smaller font for the pages that contain the long lines.

 

Awkward English in section 5.2.1.2:

   To support lsp-ping, the "ietf-= connectionless-oam" model can be
   extended and add lsp-ping specific parameters can be defined a= nd
   under "test-point-location" list.<= /p>

   User can reuse the attributes or gro= upings which are defined in
   [I-D.zheng-mpls-lsp-ping-yang-cfg] as follows:

   The snippet below depicts an example= of augmenting the "test-point-
   locations" list with lsp ping attributes:

[Qin]: Copy and past error. The proposed change= is to fixe the first sentence and remove the second sentence as follows:

=A1=B0

   To support lsp-ping, the "iet= f-connectionless-oam" model can be
   extended and add lsp-ping specific parameters under "test= -point-location" list.

   The snippet below depicts an examp= le of augmenting the "test-point-
   locations" list with lsp ping attributes:

=A1=B1

Thanks!

 

--_000_B8F9A780D330094D99AF023C5877DABA9ABE5A76nkgeml513mbxchi_-- From nobody Mon Oct 16 08:02:24 2017 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 3F2F0132811; Mon, 16 Oct 2017 08:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ihtfp.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 AE62QLAV1f2O; Mon, 16 Oct 2017 08:02:11 -0700 (PDT) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:470:e448:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 874B0133020; Mon, 16 Oct 2017 08:02:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id CBFE2E2063; Mon, 16 Oct 2017 11:01:46 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 14561-01; Mon, 16 Oct 2017 11:01:42 -0400 (EDT) Received: from securerf.ihtfp.org (unknown [IPv6:2601:c6:ca00:1173:228:f8ff:fe73:20ee]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 87595E2054; Mon, 16 Oct 2017 11:01:38 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1508166102; bh=A9S56toJS9/g0rTaRHzQlEk67G8gxq0NLtbpk6bXT7I=; h=From:To:Cc:Subject:Date; b=e9OrqLz5V9amxkXCs2PiWoiS+nXQlJDcgQhD37lUQKtrp56KxyXXnPdIf2nVjT3ZL vh719YySSInvhGUl3ufBfYZklUwKbw0l+6L5YpUpUdZbLMCI8OurGQqwbevaZHxqEJ Vl8nPeWhpSa4BxEtAG0CthgSVDAEHumNx2vQ+FJs= Received: (from warlord@localhost) by securerf.ihtfp.org (8.15.2/8.15.2/Submit) id v9GF1RIM026769; Mon, 16 Oct 2017 11:01:27 -0400 From: Derek Atkins To: iesg@ietf.org, secdir@ietf.org Cc: bier-chairs@ietf.org, israel@broadcom.com, aldrin.ietf@gmail.com, jefftant.ietf@gmail.com, andrew.dolganow@nokia.com, erosen@juniper.net, ice@cisco.com Date: Mon, 16 Oct 2017 11:01:23 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Subject: [secdir] sec-dir review of draft-ietf-bier-mpls-encapsulation-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 15:02:18 -0000 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: Obviously the security of this solution is based on the full trust of the complete end-to-end BIER network. There is no cryptography to ensure that a packet is not manipulated enroute which would change the bit-fields. The good news is that it's probably hard to inject a BIER-headed packet into the network from the outside (once it hits an external router it would be re-encapsulated). On the other hand there is nothing to stop a bad-actor internal router from creating a bogus BIER header or modifying an existing BIER header. I suspect this is already handled in the MPLS and IGP Security Considerations, but I wanted to ensure that the IESG was aware of this restriction (which is not explicitly stated here). -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Mon Oct 16 15:03:24 2017 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 A2D341331F2; Mon, 16 Oct 2017 15:03:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 Ql52TWx2L4yk; Mon, 16 Oct 2017 15:03:20 -0700 (PDT) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4710C13247A; Mon, 16 Oct 2017 15:03:17 -0700 (PDT) Received: by mail-ua0-x22e.google.com with SMTP id f46so10752022uae.1; Mon, 16 Oct 2017 15:03:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=vy55VDwNytCFrOsTyDPP1t2N9forBe1okCL0JClh6z0=; b=d5ycnnOusxCYA6Z8On8lv++cQpkcK3ho+kKc8LECLW8frQr6VTlFKpmCJ88NpYb9Ad 3qy9WDaLrkqrAV2l6hqUKaG0BDYmkoDT+tHM7U0+7L/f3o238SUs1/K8lzCQ/KUpJdCt fegZxO8EfKMw+xMzW+J8NpPlynGhK+ZYCclu4L56FEVeTuWa8F1LMwgL+G3Nk4LZ/O3j Johgz/rX8MViqxn399cAKLQtQWLSSAffIj08hr5+RnOj7Z1/8jbKUjmmeyclOKx3U7Oq 0c9wCpE9cQA1zkpQ1DJLDNT2APYQOLe0NaAc4AxDO5UVxFgSQNHhWOzP46g+sc2mLbkd V9bQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=vy55VDwNytCFrOsTyDPP1t2N9forBe1okCL0JClh6z0=; b=HFGK5EniQYGIjifU4UAEkkbcxywu6dehnznebCBXRPcB5WfweCYCKP+BuBRylr9eNf lqPq2i22pVt1pI7A2kRH+uCOo2W6g1HlS/1dBuqQE/H/g7iaAnOJT7HYl8j9kZ/Q8lfa Qy0+/9gQ9cvNDXvqsyfOK29rYSmtxM0w0wvpUNtPkkTB6dcstTKv/kxNt8gUmwfILM4X w+ZmLh34fQ0Leulu9i+sUBtgBTHulcHkxEHSpV+KHOzEeGhKPqjXajPiOpnda8G48e/o bfjoo+bN9q24KIJUkE2OFVW08fHN+zYctMUL6n7LsvZ2g7Orr4wTavivevgcL125rNrS Uq+Q== X-Gm-Message-State: AMCzsaXXKuzgCvDKYZDYV1hFD8wJMYgehpoPHzl91U9FjwTX1IFARLDq xVFIwHgUD2uhn1EEYCRIQvVRb4FikTgKnN04NkaslL4s X-Google-Smtp-Source: ABhQp+QSCKLFCJm6c2qs7XPLMlE27/IkGmUr+5kn+xRu+pxDHkTfq13QK1enGamJyhr+R8KdF/ygiaoaiEnt0aNsYjQ= X-Received: by 10.176.82.110 with SMTP id j43mr5609590uaa.9.1508191396082; Mon, 16 Oct 2017 15:03:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.48.129 with HTTP; Mon, 16 Oct 2017 15:03:15 -0700 (PDT) From: Watson Ladd Date: Mon, 16 Oct 2017 15:03:15 -0700 Message-ID: To: secdir@ietf.org, draft-ietf-tcpinc-tcpeno.all@ietf.org, iseg@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [secdir] Review of draft-ietf-tcpinc-tcpeno-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 22:03:22 -0000 Dear all, 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 that the writing and most of the structure is fine, but I am a bit confused by some of the security properties and how they are stated. It is not clear to me why the unpredictability of generated session IDs is required. It is also not clear to me that the requirement that a TEP produce different keys for different transcripts is strong enough: we need to ensure that every TEP produces different keys (with high probability) (and session identifiers) for different transcripts to prevent cross-protocol attacks. Sincerely, Watson Ladd From nobody Tue Oct 17 05:52:48 2017 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 256B4134184; Tue, 17 Oct 2017 05:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.778 X-Spam-Level: X-Spam-Status: No, score=0.778 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_NEUTRAL=0.779] 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 bP2OPP5D_7E9; Tue, 17 Oct 2017 05:52:46 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [212.16.101.130]) (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 3C881132FB1; Tue, 17 Oct 2017 05:52:46 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v9HCqfND022444 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 17 Oct 2017 15:52:41 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v9HCqeRo015726; Tue, 17 Oct 2017 15:52:40 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23013.64792.817951.742437@fireball.acr.fi> Date: Tue, 17 Oct 2017 15:52:40 +0300 From: Tero Kivinen To: iesg@ietf.org, secdir@ietf.org, draft-schaad-curdle-oid-registry.all@tools.ietf.org X-Edit-Time: 8 min X-Total-Time: 8 min Archived-At: Subject: [secdir] Secdir review of draft-schaad-curdle-oid-registry-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 12:52:48 -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 is Ready with Nits. This document creates and IANA registry and fills it with initial values. The numbers are inside the donated set of OIDs (donated from Symantec Website Security) that was donated to the curdle WG earlier. The security considerations section that as this just creates an IANA registry it does not raise any new security considerations (altoigh somepeople claim anything related to ASN.1 is security issue, I do agree with the statement in the draft). The only nit I have is that the document creates a called "SMI Security for Cryptographic Algorithms", and I have no idea what SMI means. I.e., it would be better if the name of the registry actually told people what is expected to be inside this registry... Perhaps "Short OIDs for Cryptographic Algorithms for different IETF protocol" or similar. -- kivinen@iki.fi From nobody Tue Oct 17 12:15:22 2017 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 E877F132D4E for ; Tue, 17 Oct 2017 12:15:21 -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] 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 CR8xeZ-fl_fI for ; Tue, 17 Oct 2017 12:15:20 -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 31192126B6E for ; Tue, 17 Oct 2017 12:15:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 97550300572 for ; Tue, 17 Oct 2017 15:15:19 -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 wcDWKRdcPeoM for ; Tue, 17 Oct 2017 15:15:18 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id D53F9300265; Tue, 17 Oct 2017 15:15:17 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: <23013.64792.817951.742437@fireball.acr.fi> Date: Tue, 17 Oct 2017 15:15:17 -0400 Cc: IESG , IETF SecDir , draft-schaad-curdle-oid-registry.all@tools.ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <1E64673D-5612-442C-A543-045059C40811@vigilsec.com> References: <23013.64792.817951.742437@fireball.acr.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [secdir] Secdir review of draft-schaad-curdle-oid-registry-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 19:15:22 -0000 SMI =3D Structure of Management Information That was assigned way back when someone thought that only MIB modules = would need OIDs. Russ > On Oct 17, 2017, at 8:52 AM, Tero Kivinen wrote: >=20 >=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 Ready with Nits. >=20 > This document creates and IANA registry and fills it with initial > values. The numbers are inside the donated set of OIDs (donated from > Symantec Website Security) that was donated to the curdle WG earlier. >=20 > The security considerations section that as this just creates an IANA > registry it does not raise any new security considerations (altoigh > somepeople claim anything related to ASN.1 is security issue, I do > agree with the statement in the draft). >=20 > The only nit I have is that the document creates a called "SMI > Security for Cryptographic Algorithms", and I have no idea what SMI > means. I.e., it would be better if the name of the registry actually > told people what is expected to be inside this registry... >=20 > Perhaps "Short OIDs for Cryptographic Algorithms for different IETF > protocol" or similar. > --=20 > kivinen@iki.fi >=20 > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From nobody Tue Oct 17 17:03:01 2017 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 884FA1331C2; Tue, 17 Oct 2017 17:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8S5pR9Yz4qgz; Tue, 17 Oct 2017 17:02:57 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E47F132351; Tue, 17 Oct 2017 17:02:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7494; q=dns/txt; s=iport; t=1508284977; x=1509494577; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Ym+AKBd+fcyjGBpWzGCphLcOvZNJXghwibPaYavXkxQ=; b=mPr/+bcvAsTL48fZOZ6hgrxf6jQCxFRtjFd/17YiyyUNCMneiuE9sCLi JH7CObqdwAyH4yHUJcGggn9r1TWPby2cjSA/bOebE+S4WzRKtHM2g8f36 oyW3sMnRr3h0Xy72dAhMHGxZcgKmu1ejTyb3D2CWE4/cI1iWmEogggid2 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CsAACwmeZZ/5FdJa1UBgMZAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGDX4FSJweDc4ofjziBeJYzEIIECoU7AhqEUj8YAQIBAQEBAQE?= =?us-ascii?q?BayiFHgEFIxEzEhACAQgYAgImAgICMBUQAgQBDQWKHapEgieLOQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAR2BD4IfggeBUYFqK4MAhFIBCAMHAR8XCiaCTC+CMgWhSwK?= =?us-ascii?q?UaZMYlUMCERkBgTgBHziBA1Z6FXYBgjaCXAEbgWd2iCgPGIEMgREBAQE?= X-IronPort-AV: E=Sophos;i="5.43,393,1503360000"; d="scan'208";a="302911043" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Oct 2017 00:02:27 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v9I02R17029596 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 18 Oct 2017 00:02:27 GMT Received: from xch-rcd-019.cisco.com (173.37.102.29) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 17 Oct 2017 19:02:26 -0500 Received: from xch-rcd-019.cisco.com ([173.37.102.29]) by XCH-RCD-019.cisco.com ([173.37.102.29]) with mapi id 15.00.1320.000; Tue, 17 Oct 2017 19:02:26 -0500 From: "Arjun Sreekantiah (asreekan)" To: "John G. Scudder" , "Brian Weis (bew)" CC: stefano previdi , "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-idr-bgp-prefix-sid.all@ietf.org" , "Gaurav Dawra (gdawra)" Thread-Topic: Secdir early review of draft-ietf-idr-bgp-prefix-sid-06 Thread-Index: AQHTAtRSCuBzILjiK0OIovgMdDR4U6JmcY0AgA7UdgCAYmpQgIARcWKA Date: Wed, 18 Oct 2017 00:02:26 +0000 Message-ID: <885B62AD-CC5B-40A9-947F-A9D0A187997F@cisco.com> References: <150071889993.20425.5273428383173596948@ietfa.amsl.com> <6A05B578-F8DE-4197-97B8-82886089782B@previdi.net> <13FD5BC6-69AD-46F1-8767-DE11740A49A0@juniper.net> In-Reply-To: <13FD5BC6-69AD-46F1-8767-DE11740A49A0@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.15.1.160411 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.83.178] Content-Type: text/plain; charset="utf-8" Content-ID: <4AF26D7A2B4AE64F9772C10BAAC93271@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] Secdir early review of draft-ietf-idr-bgp-prefix-sid-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Oct 2017 00:02:59 -0000 SGkgSm9obiwgQWxsDQpUaGUgc3VnZ2VzdGVkIGNoYW5nZSBiZWxvdyBoYXMgYmVlbiBtYWRlIGFu ZCBhIG5ldyByZXZpc2lvbiBvZiB0aGUgZHJhZnQgaGFzIGJlZW4gcG9zdGVkLg0KDQpUaGFua3MN CkFyanVuDQoNCg0KDQpPbiAxMC82LzE3LCA3OjQwIEFNLCAiSm9obiBHLiBTY3VkZGVyIiA8amdz QGp1bmlwZXIubmV0PiB3cm90ZToNCg0KPkhpIEJyaWFuIGFuZCBTdGVmYW5vLA0KPg0KPkknbSBn bGFkIFN0ZWZhbm8ncyBjb21tZW50cyBzYXRpc2Z5IEJyaWFuLiBJdCBzZWVtcyB0byBtZSB0aGF0 IHRoaXMgY2xhcmlmaWNhdGlvbiB3b3VsZCBiZSB3b3J0aCBhZGRpbmcgdG8gYSBuZXcgcmV2aXNp b24gb2YgdGhlIGRyYWZ0Og0KPg0KPj4+IChjKSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBzcGVh a3Mgb2YgbGltaXRpbmcgQkdQIFByZWZpeC1TSUQgd2l0aGluIGENCj4+PiDigJxkb21haW7igJ0u IElzIHRoYXQgaW50ZW5kaW5nIHRvIHNheSBhbiDigJxTUiBkb21haW7igJ0/DQo+PiANCj4+IE1v cmUgZ2VuZXJhbGx5LCBieSBkb21haW4gd2UgaW50ZW5kIHRoZSBzZXQgb2YgQVMgdW5kZXIgY29u dHJvbCBvZiB0aGUgc2FtZSBvcmdhbml6YXRpb24vb3BlcmF0b3IuDQo+DQo+U2VlbXMgYXMgdGhv dWdoIHRoZSBvdGhlciBuaXRzIHdlcmUgYWRkcmVzc2VkIHdpdGggbm8gY2hhbmdlIG5lZWRlZCwg b3IgdGhhdCdzIG15IHVuZGVyc3RhbmRpbmcgb2YgdGhlIGNvbnNlbnN1cyBiZXR3ZWVuIEJyaWFu IGFuZCBTdGVmYW5vLg0KPg0KPlN0ZWZhbm8gb3Igb3RoZXIgYXV0aG9ycywgY2FuIHlvdSBlaXRo ZXIgbWFrZSB0aGUgbWlub3IgcmV2aXNpb24gaW5kaWNhdGVkLCBvciByZXBseSB0aGF0IHlvdSBk b24ndCBwbGFuIHRvPw0KPg0KPlRoYW5rcywNCj4NCj4tLUpvaG4NCj4NCj4+IE9uIEF1ZyA0LCAy MDE3LCBhdCA3OjQ2IFBNLCBCcmlhbiBXZWlzIChiZXcpIDxiZXdAY2lzY28uY29tPiB3cm90ZToN Cj4+IA0KPj4gSGkgU3RlZmFubywNCj4+IA0KPj4gVGhhbmtzIGZvciB5b3VyIG5vdGVzIGJlbG93 LCB3aGljaCBtYWtlIHNlbnNlIHRvIG1lLiBJIGRvbuKAmXQgaGF2ZSBhbnkgbW9yZSBjb21tZW50 cy4gDQo+PiANCj4+IEJyaWFuDQo+PiANCj4+PiBPbiBKdWwgMjYsIDIwMTcsIGF0IDY6MTggQU0s IHN0ZWZhbm8gcHJldmlkaSA8c3RlZmFub0BwcmV2aWRpLm5ldD4gd3JvdGU6DQo+Pj4gDQo+Pj4g SGkgQnJpYW4sDQo+Pj4gDQo+Pj4gdGhhbmtzIGZvciB0aGUgcmV2aWV3LiBTb21lIGNvbW1lbnRz IGhlcmUgYmVsb3cuDQo+Pj4gDQo+Pj4gDQo+Pj4+IE9uIEp1bCAyMiwgMjAxNywgYXQgMTI6MjEg UE0sIEJyaWFuIFdlaXMgPGJld0BjaXNjby5jb20+IHdyb3RlOg0KPj4+PiANCj4+Pj4gUmV2aWV3 ZXI6IEJyaWFuIFdlaXMNCj4+Pj4gUmV2aWV3IHJlc3VsdDogSGFzIE5pdHMNCj4+Pj4gDQo+Pj4+ IEkgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlIHNlY3VyaXR5IGRp cmVjdG9yYXRlJ3Mgb25nb2luZw0KPj4+PiBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRGIGRvY3Vt ZW50cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhlIElFU0cuIFRoZXNlIGNvbW1lbnRzDQo+Pj4+IHdl cmUgd3JpdHRlbiBwcmltYXJpbHkgZm9yIHRoZSBiZW5lZml0IG9mIHRoZSBzZWN1cml0eSBhcmVh IGRpcmVjdG9ycy4gRG9jdW1lbnQNCj4+Pj4gZWRpdG9ycyBhbmQgV0cgY2hhaXJzIHNob3VsZCB0 cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0IGxpa2UgYW55IG90aGVyIGxhc3QgY2FsbA0KPj4+PiBj b21tZW50cy4NCj4+Pj4gDQo+Pj4+IFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgQkdQIGV4dGVu c2lvbiB0byBzaWduYWwgdGhlIEJHUCBQcmVmaXgtU0lEIHVzZSB3aXRoDQo+Pj4+IFNlZ21lbnQg Um91dGluZy4gIGFzIHdlbGwgYXMgdGhlIHJ1bGVzIHRvIG9yaWdpbmF0ZSwgcmVjZWl2ZSBhbmQg aGFuZGxlIGVycm9yDQo+Pj4+IGNvbmRpdGlvbnMuIFRoZSBCR1AgZXh0ZW5zaW9uIGRlZmluZXMg YSBuZXcgdHlwZSBvZiBCR1AgcGF0aCBhdHRyaWJ1dGUgcGFzc2VkDQo+Pj4+IHdpdGhpbiBCR1As IGFuZCBkb2VzIG5vdCBjaGFuZ2UgdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIG9mIHRoZSBC R1AgcHJvdG9jb2wNCj4+Pj4gaXRzZWxmLg0KPj4+PiANCj4+Pj4gSSBjb25zaWRlciB0aGlzIGRv Y3VtZW50IOKAnHJlYWR5IHdpdGggbml0c+KAnS4NCj4+Pj4gDQo+Pj4+IFRoZSBTZWN1cml0eSBD b25zaWRlcmF0aW9ucyBzZWN0aW9uIHJlYXNvbmFibHkgc3RhdGVzIHRoYXQgdGhlIHVzZSBvZiB0 aGlzIEJHUA0KPj4+PiBhdHRyaWJ1dGUg4oCcaW5oZXJpdHMgdGhlIHNlY3VyaXR5IGNvbnNpZGVy YXRpb25z4oCdIG9mIHRoZSBCR1AtNCBSRkMgYXMgd2VsbCBhcw0KPj4+PiB0aGUgUkZDIGRlZmlu aW5nIGhvdyBsYWJlbHMgYXJlIGNhcnJpZWQgaW4gQkdQLTQuIEFzIGFuIGFzaWRlLCB0aG9zZSBk b2N1bWVudHMNCj4+Pj4gYXJlIHF1aXRlIG9sZC4gRm9yIGV4YW1wbGUsIFJGQyA0MjcxIHNheXMg dGhhdCB0aGUgVENQLU1ENSBvcHRpb24gaXMgcmVxdWlyZWQNCj4+Pj4gdG8gaW1wbGVtZW50IGZv ciBhdXRoZW50aWNhdGlvbiwgYnV0IHRoaXMgaGFzIGJlZW4gcmVwbGFjZWQgYnkgYSBtdWNoIHN0 cm9uZ2VyDQo+Pj4+IGF1dGhlbnRpY2F0aW9uIG1ldGhvZCAoVENQLUFPKS4gSXQgd291bGQgYmUg bmljZSBpZiB3ZSBoYWQgbmV3ZXIgc2VjdXJpdHkNCj4+Pj4gY29uc2lkZXJhdGlvbnMgZm9yIEJH UC00IGJ1dCB0aGF0IGFkdmljZSBkb2VzbuKAmXQgYmVsb25nIGluIHRoaXMgZG9jdW1lbnQuDQo+ Pj4+IA0KPj4+PiBUaGUgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgbWlnaHQgaGF2ZSBzYWlkIHNv bWV0aGluZyBhYm91dCB0aGUgaG93IGFuIEFTIHdvdWxkDQo+Pj4+IHByb3RlY3QgaXRzZWxmIGFn YWluc3QgYSBwZWVyIHNlbmRpbmcgdGhlIFByZWZpeC1TSUQgYXR0cmlidXRlIGFjcm9zcyBBUw0K Pj4+PiBib3VuZGFyaWVzLCBidXQgdGhhdCB0ZXh0IGlzIGNvbnRhaW5lZCBpbiB1c2VmdWwgcGxh Y2VzIGVsc2V3aGVyZSBpbiB0aGUNCj4+Pj4gZG9jdW1lbnQgYW5kIHNlZW1zIHN1ZmZpY2llbnQu DQo+Pj4+IA0KPj4+PiBJIGhhdmUgb25seSBvbmUgbml0LCB3aGljaCBpcyBzb21lIGNvbmZ1c2lv biByZWdhcmRpbmcgc2NvcGluZyBvZiB0aGUgU0lELiBUaGUNCj4+Pj4gZG9jdW1lbnQgY2xlYXJs eSBzdGF0ZXMgdGhhdCBhIFNJRCBoYXMgYSBsaW1pdGVkIHNjb3BlIHdpdGhpbiB0aGUgbmV0d29y aywgDQo+Pj4+IHdoaWNoIGlzIGltcG9ydGFudCBiZWNhdXNlIG91dHNpZGUgb2YgdGhhdCBzY29w ZSBhbiBTSUQgdmFsdWUgd291bGQgaGF2ZSBhDQo+Pj4+IGRpZmZlcmVudCBtZWFuaW5nLiBUaGlz IGlzIGEgc2VjdXJpdHkgIGNvbnNpZGVyYXRpb24sIGJlY2F1c2UgYWNjZXB0aW5nIGEgU0lEDQo+ Pj4+IGluIHRoZSB3cm9uZyBzY29wZSBjb3VsZCBwb3NzaWJseSBjYXVzZSBhIHNlY3VyaXR5IGlz c3VlIGlmIHBhY2tldHMgYXJlDQo+Pj4+IGZvcndhcmRlZCB0byB0aGUgd3JvbmcgaWRlbnRpdHkg KGUuZywgdGhlIHBhY2tldHMgd2VyZSBpbnRlbmRlZCBmb3IgYSBmaXJld2FsbA0KPj4+PiB3aXRo aW4gdGhlIEFTLCBub3QgYSBzZXJ2aWNlIG91dHNpZGUgb2YgdGhlIEFTKS4NCj4+Pj4gDQo+Pj4+ IChhKSBTZWN0aW9uIDUuMSBzYXlzIGl0IHNob3VsZCBub3QgYmUgYWR2ZXJ0aXNlZCBvdXRzaWRl IG9mIGFuIEFTIHVubGVzcw0KPj4+PiDigJxleHBsaWNpdGx5IGNvbmZpZ3VyZWQgdG8gZG8gc2/i gJ0uIEl0IHdvdWxkIGJlIG5pY2UgaWYgdGhlIGNvbmRpdGlvbnMgZm9yDQo+Pj4+IGV4cGxpY2l0 bHkgY29uZmlndXJpbmcgdGhlIFNJRCB0byBiZSBhZHZlcnRpc2VkIG91dHNpZGUgb2YgdGhlIEFT IHdlcmUNCj4+Pj4gbWVudGlvbmVkIGhlcmUuDQo+Pj4gDQo+Pj4gDQo+Pj4gdXN1YWxseSB3ZSBk b27igJl0IGRlZmluZSB0aGVzZSBjb25kaXRpb24gYmVjYXVzZSB0aGV5IGFyZSByZWxhdGVkIHRv IGVhY2ggaW5kaXZpZHVhbCBvcGVyYXRvciBwb2xpY3kuIFdoYXQgd2Ugd2FudCB0byBiZSBzdXJl IG9mIGlzIHRoYXQgYW55IGNvbXBsaWFudCBpbXBsZW1lbnRhdGlvbiwgYnkgZGVmYXVsdCwgd2ls bCBub3QgcHJvcGFnYXRlIHRoZSBhdHRyaWJ1dGUgb3V0c2lkZSB0aGUgQVMuDQo+Pj4gDQo+Pj4g VW5kZXIgd2hpY2ggY29uZGl0aW9ucyBwcm9wYWdhdGlvbiBpcyBhbGxvd2VkIGlzIGEgbG9jYWwg bWF0dGVyIG9mIHRoZSBvcGVyYXRvciBhbmQgaG93IGl0IGlzIGVmZmVjdGl2ZWx5IGFjaGlldmVk IGlzIGEgbWF0dGVyIG9mIGxvY2FsIGltcGxlbWVudGF0aW9uLg0KPj4+IA0KPj4+IA0KPj4+PiAo YikgVGhlIGxhc3QgcGFyYWdyYXBoIG9mIFNlY3Rpb24gOCBzYXlzIGl0IGlzIGFwcGxpY2FibGUg d2l0aGluIGFuIFNSIERvbWFpbg0KPj4+PiAoaS5lLiwgbW9yZSB0aGFuIGFuIEFTKSwgYW5kIFNl Y3VyaXR5IENvbnNpZGVyYXRpb25zIHNheXMgc29tZXRoaW5nIHNpbWlsYXIuDQo+Pj4+IA0KPj4+ PiAoYykgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgc3BlYWtzIG9mIGxpbWl0aW5nIEJHUCBQcmVm aXgtU0lEIHdpdGhpbiBhDQo+Pj4+IOKAnGRvbWFpbuKAnS4gSXMgdGhhdCBpbnRlbmRpbmcgdG8g c2F5IGFuIOKAnFNSIGRvbWFpbuKAnT8NCj4+PiANCj4+PiANCj4+PiBNb3JlIGdlbmVyYWxseSwg YnkgZG9tYWluIHdlIGludGVuZCB0aGUgc2V0IG9mIEFTIHVuZGVyIGNvbnRyb2wgb2YgdGhlIHNh bWUgb3JnYW5pemF0aW9uL29wZXJhdG9yLg0KPj4+IA0KPj4+PiBJIHN1c3BlY3Qgd2hldGhlciBh biBTSUQgc2hvdWxkIGJlIGFkdmVydGlzZWQgb3V0c2lkZSBvZiB0aGUgQVMgZGVwZW5kcyBvbg0K Pj4+PiB3aGV0aGVyIGFuIEFTIGlzIHBhcnQgb2YgYW4g4oCcU1IgZG9tYWlu4oCdIG9yIG5vdCwg YW5kIHRoYXQgdGhlcmUncyBsaWtlbHkgbmV2ZXIgYQ0KPj4+PiBnb29kIGNhc2UgdG8gYWR2ZXJ0 aXNlIGl0IG91dHNpZGUgb2YgYW4gQVMgdW5sZXNzIGl0IGlzIHBhcnQgb2YgYW4gIlNSIGRvbWFp biIuDQo+Pj4+IEJ1dCBpdCB3b3VsZCBiZSBnb29kIGlmIHRoZXJlIHdhcyBzb21lIHRleHQgY2xh cmlmeWluZyAgdGhlIGNvbmRpdGlvbnMgd2hlbiBpdA0KPj4+PiBpcyByZWFzb25hYmxlIHRvIHNo YXJlIGFuIFNJRCBiZXR3ZWVuIEFTZXMuDQo+Pj4gDQo+Pj4gDQo+Pj4gV2VsbCwgSeKAmW0gbm90 IHN1cmUgdGhhdCB3b3VsZCBiZSBhIGdvb2QgaWRlYSBiZWNhdXNlIHRoZSBjb25kaXRpb25zIG1h eSB2YXJ5IG92ZXIgdGltZSBhbmQgd2Ugd2lsbCBuZXZlciBiZSBleGhhdXN0aXZlIGFueXdheS4N Cj4+PiBUaGFua3MuDQo+Pj4gcy4NCj4+PiANCj4+PiANCj4+Pj4gDQo+Pj4gDQo+PiANCj4+IC0t IA0KPj4gQnJpYW4gV2Vpcw0KPj4gU2VjdXJpdHksIENTRywgQ2lzY28gU3lzdGVtcw0KPj4gVGVs ZXBob25lOiArMSA0MDggNTI2IDQ3OTYNCj4+IEVtYWlsOiBiZXdAY2lzY28uY29tDQo+PiANCj4N Cg== From nobody Tue Oct 17 23:30:24 2017 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 20B21133039 for ; Tue, 17 Oct 2017 23:30:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJObbiKdU01S for ; Tue, 17 Oct 2017 23:30:20 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80A06132D17 for ; Tue, 17 Oct 2017 23:30:20 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id h70so4826133ioi.4 for ; Tue, 17 Oct 2017 23:30:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=b1I3W7hD3xGNy8JJuTTPULhk/7welDMQoM536eiXfSE=; b=njoGo3PYxBSFjfbjrOhpomOwNQmLsE87CFmjHLV3cibP9TH+jydn8hsq0/aRFZ2ndV 15c51cLMzNTtGZH8gwbFMvQyt6Y/0eimrg7wzxdiQAdStflNakb4HR3/uVdkbyYKk3rX EvChTE1ufhY7xnqI0TuGQKgy8r18hdLP7MNW0atCyo/yCj+ABm8bXzjpTKv5Ebvv36LS +OCggsmPV2uTU7PNrshd/J/MlT30BOerD2NmeF3lqpHDnvElVhz/meuvNL89BO18rUcX ZVYKMtOunC90AEAYRxAgrjmZuGKhPTfFHrtxMHr9UVdGYlpq2hKK9wea8O/kAtUDhjAo gcdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=b1I3W7hD3xGNy8JJuTTPULhk/7welDMQoM536eiXfSE=; b=THs4VNlpc6R3ZsWrnC7eswFN8nU3W1dozXuRQRl0gmS6GfL+CciYOkJY//hn4Py+8O PWpaSjU692TOuGFH0TwGuGbqVbbI/WfkE0em1C5v/FgWKWeQz7XXmjEQXNPSuJwqOBWo BACCb/VlSqjaeQH88XXgtupCjkRddRCcvrbBp9lShur7StffoEURxR1lzAXi0u64MGof 5dex3KHP4OdswOm4bEKR8WYkUKi5JRLLjmzDKIScW5nMW28TC/MQjxClatqW3xr0+L/A dzC0O6CFvkOzuON9VRYlity2VxhON5i7qb6vFVPMOi82t7ZL+mpvmiwYMrOPxSQv5JL9 VmbQ== X-Gm-Message-State: AMCzsaX4BjwUzw3F19SAtKNc7vSTWKiqfnCsdIciOfVZWo7rL+BqoIzZ sI1N+CI6iP1yITKlCLYVMgAiCXd5+XCdx68eZC7Sc/+g X-Google-Smtp-Source: AOwi7QC5fsRUiRON41U6MVYLf6WrmDRDUkr1Bx5FuMJ98sJ1sYbWI8Mab+rc/Ua8mupWWAcybJQ3THo8wBrX4EwR5Zw= X-Received: by 10.107.47.159 with SMTP id v31mr20052884iov.102.1508308219492; Tue, 17 Oct 2017 23:30:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.2.180.18 with HTTP; Tue, 17 Oct 2017 23:30:19 -0700 (PDT) From: Shawn Emery Date: Wed, 18 Oct 2017 00:30:19 -0600 Message-ID: To: secdir@ietf.org, draft-ietf-curdle-pkix.all@tools.ietf.org Content-Type: multipart/alternative; boundary="001a11c158b8a2806a055bcc5f73" Archived-At: Subject: [secdir] Review of draft-ietf-curdle-pkix-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Oct 2017 06:30:22 -0000 --001a11c158b8a2806a055bcc5f73 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 draft specifies ASN.1 structures, consisting of algorithm identifiers, parameters, public, private keys, and signatures, for Curve25519 and Curve448 curves. The security considerations section does exist and refers to RFC 5280 , 7748 , and 8032 for relevancy. The section adds that the same public key can not be used for ECDH and EdDSA. I don't see how this specifically relates to the ASN specification for Curve25519 and Curve448, but since these are two procedures related to this draft, I can see why this paragraph may exist. General comments: None. Editorial comments: For the public key field the document specifies: subjectPublicKey BIT STRING Shouldn't this be OCTET STRING? The same for signatureValue. s/algorithms need have/algorithms need to have/ s/cross-implementation naming this/cross-implementation naming, this/ OLD Asymmetric Key Packages [RFC5958 ] describes how encode a private key in a structure that both identifies what algorithm the private key is for, but allows for the public key and additional attributes about the key to be included as well. NEW Asymmetric Key Packages [RFC5958 ] describes how to encode a private key in a structure that both identifies what algorithm the private key is for, but allows for the public key and additional attributes of the key to be included as well. Shawn. -- --001a11c158b8a2806a055bcc5f73 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have reviewed this= document as part of the security directorate's
ongoing effort to review all= =C2=A0IETF=C2=A0documents being processed by the IESG.
These comments were= written primarily for the benefit of the security
area directors. Document edit= ors and WG chairs should treat these
<= span style=3D"font-size:12.8px">comments just like any other last call comm= ents.

This draft specifies ASN.1 structures= , consisting of algorithm identifiers, parameters, public, private keys, an= d signatures, for Curve25519 and Curve448 curves.=C2=A0

The security considerations section does exist and refers to RFC=C2= =A05280, 7748, and 8032=C2=A0for relevancy.=C2=A0 The section add= s that the same public key can not be used for=C2=A0ECDH and EdDSA.=C2=A0 I don't see how thi= s=C2=A0specific= ally relates to the ASN specification for=C2=A0Curve25519 and Curve4= 48, but since these are two procedures related to this draft, I can see why= this paragraph may exist.

General comments:
=

None.

Editorial comments:

For the public k= ey field the document specifies:

subjectPublicKey BIT STRING
<= span style=3D"color:rgb(0,0,0);font-family:monospace;font-size:medium">
=
Shouldn't this be=C2=A0OCTET STRING?=C2=A0 The same = for=C2=A0signat= ureValue.

s/algorithms need have/algorithms need to have/
s/cross-implementation naming this/cross-implementati= on naming, this/

OLD
   Asymme=
tric Key Packages [RFC5958] describes how encode a p=
rivate key
   in a structure that both identifies what algorithm the private key is
   for, but allows for the public key and additional attributes about=C2=A0=
=C2=A0 =C2= =A0 =C2=A0 =C2=A0the key to be included as well.

NEW
   Asymmetric Key Packages [RFC5=
958] describes how to encode a private key
   in a structure that both identifies what algorithm the private key is
   for, but allows for the public key and additional attributes of=C2=A0
=C2=A0 =C2=A0 =
=C2=A0 =C2=A0the key to be included as well.

Shawn.
<= div>--
--001a11c158b8a2806a055bcc5f73-- From nobody Wed Oct 18 11:52:42 2017 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 1D94113306B for ; Wed, 18 Oct 2017 11:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=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 3lvBzY7noZzQ for ; Wed, 18 Oct 2017 11:52:39 -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 CB398133059 for ; Wed, 18 Oct 2017 11:52:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 2FF76300577 for ; Wed, 18 Oct 2017 14:52:39 -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 SCe676sINv08 for ; Wed, 18 Oct 2017 14:52:38 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 1E3C430022B; Wed, 18 Oct 2017 14:52:38 -0400 (EDT) From: Russ Housley Message-Id: <9A19C4A9-93AD-4D1D-B3F2-B7112029B9DC@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_5A472C1D-16C5-4FA4-8586-048F37681923" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 18 Oct 2017 14:52:37 -0400 In-Reply-To: Cc: IETF SecDir , draft-ietf-curdle-pkix.all@tools.ietf.org To: Shawn Emery References: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [secdir] Review of draft-ietf-curdle-pkix-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Oct 2017 18:52:41 -0000 --Apple-Mail=_5A472C1D-16C5-4FA4-8586-048F37681923 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii > For the public key field the document specifies: > > subjectPublicKey BIT STRING > > Shouldn't this be OCTET STRING? The same for signatureValue. It is a BIT STRING; see RFC 5280. Russ --Apple-Mail=_5A472C1D-16C5-4FA4-8586-048F37681923 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
For the public key field the document = specifies:

subjectPublicKey BIT = STRING

Shouldn't this = be OCTET STRING?  The same for signatureValue.

It is a BIT STRING; see RFC 5280.

Russ

= --Apple-Mail=_5A472C1D-16C5-4FA4-8586-048F37681923-- From nobody Thu Oct 19 02:21:28 2017 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 0FFB8134870 for ; Thu, 19 Oct 2017 02:21:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Tero Kivinen To: X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Reply-to: secdir-secretary@mit.edu Message-ID: <150840488705.18719.895991961596739620.idtracker@ietfa.amsl.com> Date: Thu, 19 Oct 2017 02:21:27 -0700 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2017 09:21:27 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2017-10-26 Reviewer LC end Draft Daniel Franke 2017-10-25 draft-ietf-i2nsf-framework-08 Ólafur Guðmundsson 2017-10-13 draft-ietf-uta-email-deep-09 Leif Johansson 2017-10-25 draft-ietf-netconf-rfc6536bis-06 Benjamin Kaduk 2017-10-25 draft-ietf-lime-yang-connectionless-oam-methods-09 Ben Laurie 2017-10-23 draft-ietf-rmcat-scream-cc-11 Tom Yu 2017-09-28 draft-ietf-ippm-alt-mark-12 Dacheng Zhang 2017-10-13 draft-ietf-mile-rolie-10 For telechat 2017-11-30 Reviewer LC end Draft John Bradley None draft-ietf-acme-acme-07 Alan DeKok 2017-10-09 draft-ietf-tsvwg-ieee-802-11-09 Scott Kelly 2017-10-24 draft-ietf-dhc-relay-port-06 Tina Tsou R2017-06-29 draft-ietf-trill-arp-optimization-09 For telechat 2017-12-14 Reviewer LC end Draft Shaun Cooley 2017-10-11 draft-ietf-grow-bgp-gshut-12 Last calls: Reviewer LC end Draft Donald Eastlake 2017-10-09 draft-ietf-oauth-discovery-07 Daniel Gillmor 2017-10-17 draft-ietf-sidrops-bgpsec-rollover-02 Phillip Hallam-Baker 2017-10-13 draft-ietf-ospf-segment-routing-extensions-19 Russ Mundy 2017-09-14 draft-spinosa-urn-lex-11 Tim Polk 2017-09-11 draft-ietf-kitten-rfc5653bis-05 Tom Yu 2017-02-20 draft-ietf-slim-negotiating-human-language-17 Next in the reviewer rotation: Barry Leiba Chris Lonvick David Mandelberg Catherine Meadows Alexey Melnikov Daniel Migault Matthew Miller Adam Montville Russ Mundy Sandra Murphy From nobody Thu Oct 19 02:34:47 2017 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 CDA73134842; Thu, 19 Oct 2017 02:34:45 -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, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, SPF_PASS=-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 CPau11Z-WSfg; Thu, 19 Oct 2017 02:34:44 -0700 (PDT) Received: from market.scs.stanford.edu (www.scs.stanford.edu [IPv6:2001:470:806d:1::9]) (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 D1ADE1347C5; Thu, 19 Oct 2017 02:34:44 -0700 (PDT) Received: from market.scs.stanford.edu (localhost [127.0.0.1]) by market.scs.stanford.edu (8.15.2/8.15.2) with ESMTP id v9J9Yh3x092434; Thu, 19 Oct 2017 02:34:43 -0700 (PDT) Received: (from dm@localhost) by market.scs.stanford.edu (8.15.2/8.15.2/Submit) id v9J9YhbZ002854; Thu, 19 Oct 2017 02:34:43 -0700 (PDT) From: David Mazieres To: Watson Ladd , secdir@ietf.org, draft-ietf-tcpinc-tcpeno.all@ietf.org, iseg@ietf.org, "tcpinc" In-Reply-To: References: Reply-To: David Mazieres expires 2018-01-17 PST Date: Thu, 19 Oct 2017 02:34:43 -0700 Message-ID: <87o9p3wkek.fsf@ta.scs.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [secdir] Review of draft-ietf-tcpinc-tcpeno-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2017 09:34:46 -0000 Watson Ladd writes: > Dear all, > > 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 that the writing and most of the > structure is fine, but I am a bit confused by some of the security > properties and how they are stated. It is not clear to me why the > unpredictability of generated session IDs is required. Thanks for your review. Unpredictability of session IDs is required because doing so is not particularly burdensome and because it's a very strong property that subsumes the security requirements of a broad range of cases where things might otherwise go wrong. For example, the TEP has to be 33 bytes, and we don't want the last 16 of them being zeros. Moreover, if people sign session IDs for authentication, we want to be absolutely sure they don't mess up the domain separation. As another example, someone might use a session ID on one connection to try to authenticate a session ID on another. Do you buy this rationale? And is it important enough that you think we need to add a subsection to the rationale section discussing it? > It is also not clear to me that the requirement that a TEP produce > different keys for different transcripts is strong enough: we need to > ensure that every TEP produces different keys (with high probability) > (and session identifiers) for different transcripts to prevent > cross-protocol attacks. Do you mind clarifying this comment? I assume it's in relation the following two paragraphs from sections 4.8 and 10 respectively? To defend against attacks on encryption negotiation itself, a TEP MUST with high probability fail to establish a working connection between two ENO-compliant hosts when SYN-form ENO options have been altered in transit. (Of course, in the absence of endpoint authentication, two compliant hosts can each still be connected to a man-in-the-middle attacker.) To detect SYN-form ENO option tampering, TEPs must reference a transcript of TCP-ENO's negotiation. ... Because TCP-ENO enables multiple different TEPs to coexist, security could potentially be only as strong as the weakest available TEP. In particular, if session IDs do not depend on the TCP-ENO transcript in a strong way, an attacker can undetectably tamper with ENO options to force negotiation of a deprecated and vulnerable TEP. To avoid such problems, TEPs MUST compute session IDs using only well-studied and conservative hash functions. That way, even if other parts of a TEP are vulnerable, it is still intractable for an attacker to induce identical session IDs at both ends after tampering with ENO contents in SYN segments. The goal here is indeed to thwart both cross-TEP attacks and TEP downgrade attacks, but to do so without mandating a particular hash function for all TEPS, because that would severely hamper crypto agility. The extra byte in session IDs should save us from cases where somehow both SHA-512 and Keccac are secure, but someone found two inputs x and y such that SHA-512(x)==SHA-3(y) causing reuse of Session IDs across TEPs. So I can't figure out the attack you are worried about... Thanks, David From nobody Thu Oct 19 07:49:35 2017 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 6F4BD12421A; Thu, 19 Oct 2017 07:49:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 vLvo7_tabPh4; Thu, 19 Oct 2017 07:49:32 -0700 (PDT) Received: from mail-ua0-x243.google.com (mail-ua0-x243.google.com [IPv6:2607:f8b0:400c:c08::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54AEC124B17; Thu, 19 Oct 2017 07:49:32 -0700 (PDT) Received: by mail-ua0-x243.google.com with SMTP id s41so6158720uab.10; Thu, 19 Oct 2017 07:49:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=C/5sUN0ipDDLBsia1UaE6AqQo/f1hxK6gFrUF63VlrY=; b=IZjsgVQ9vtQYy44rvKSOblaJ3FKCejVoNg1hF3FxV84c/46LeSmDIRfq3XWlYv18ac aiddFnhyEY3cjYn9mGQb0g2J/ZGh/LgJ2MaGDEWU08q9ckQFfv1A5GsSUlDFg+F0/QWf wTPpD2E9eIOziZFXnuXbq82bVTQwy297sp7yAecEkO0/DI+SoOgAtUg46qJ2wMGFa13O JEG/e4LP8DHAHw8pGUUMxRHezR7+V4SOF7nXu5uqMMm/U+aFLppfhQyzjOjupkcoxx5z J6rviEo5wNjaKqgF6GizdXMw2p56Q/A6dESgt+JmCjpBVYPRcwE6o+XYmtHn4bi8rrmr lhig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=C/5sUN0ipDDLBsia1UaE6AqQo/f1hxK6gFrUF63VlrY=; b=qjNqUI6Mi/RDMJUaIRumOqVCUpLwqvRuAbrK+jMS9GD+nr8C0erlnIGMkr4YA7SX/4 GaSWNAwKbrPsCdy8hUQw0raNe5JObo1lrkcvcDdBBVpl11pBJMrW/HjzwexDtbFiSEZK rwaNWdiq8SDH2QG0hJy53xBZOrcknwRND56sFOPwa0Soe6w62XLi8TxkVQJ+WlBtz8jq qlI9EaA/h994Tm8oLQOUZHQsQoZl42RUoz1tslqP0+m2+1ISM5hNvGP/3UlEwo2VPil3 T6k8fzfeRtcmgkeCyGZOYHO7OYNCznYwwqGuNcTeQV2Qgilr54gIjjrpRstIVQpakDxX /Sjg== X-Gm-Message-State: AMCzsaX0KWi53VZU92+Vv2WEM1M1g/2aZmfKGVVVRDKkpaMjjy8khl+C rntNhdM08qVlc//GFIDi3tIIfG3NGt+JisytWH6QzA== X-Google-Smtp-Source: ABhQp+SWtnUlgNyeqIn/o3PRgxUAvzIjYj/vp1xpEFaaEoN4VB6L4xli/5T58Chu+robHqt2tgvELsw8h7h7gt534EM= X-Received: by 10.159.49.179 with SMTP id v48mr1561889uad.101.1508424571285; Thu, 19 Oct 2017 07:49:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.48.129 with HTTP; Thu, 19 Oct 2017 07:49:30 -0700 (PDT) In-Reply-To: <87o9p3wkek.fsf@ta.scs.stanford.edu> References: <87o9p3wkek.fsf@ta.scs.stanford.edu> From: Watson Ladd Date: Thu, 19 Oct 2017 07:49:30 -0700 Message-ID: To: David Mazieres expires 2018-01-17 PST Cc: secdir@ietf.org, draft-ietf-tcpinc-tcpeno.all@ietf.org, iseg@ietf.org, tcpinc Content-Type: multipart/alternative; boundary="001a11415848bdf5e3055be776f9" Archived-At: Subject: Re: [secdir] Review of draft-ietf-tcpinc-tcpeno-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2017 14:49:34 -0000 --001a11415848bdf5e3055be776f9 Content-Type: text/plain; charset="UTF-8" On Thu, Oct 19, 2017 at 2:34 AM, David Mazieres < dm-list-tcpcrypt@scs.stanford.edu> wrote: > Watson Ladd writes: > > > Dear all, > > > > 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 that the writing and most of the > > structure is fine, but I am a bit confused by some of the security > > properties and how they are stated. It is not clear to me why the > > unpredictability of generated session IDs is required. > > Thanks for your review. > > Unpredictability of session IDs is required because doing so is not > particularly burdensome and because it's a very strong property that > subsumes the security requirements of a broad range of cases where > things might otherwise go wrong. For example, the TEP has to be 33 > bytes, and we don't want the last 16 of them being zeros. Moreover, if > people sign session IDs for authentication, we want to be absolutely > sure they don't mess up the domain separation. As another example, > someone might use a session ID on one connection to try to authenticate > a session ID on another. Do you buy this rationale? And is it > important enough that you think we need to add a subsection to the > rationale section discussing it? > More rational for the requirement would I think help. > It is also not clear to me that the requirement that a TEP produce > > different keys for different transcripts is strong enough: we need to > > ensure that every TEP produces different keys (with high probability) > > (and session identifiers) for different transcripts to prevent > > cross-protocol attacks. > > Do you mind clarifying this comment? I assume it's in relation the > following two paragraphs from sections 4.8 and 10 respectively? > > To defend against attacks on encryption negotiation itself, a TEP > MUST with high probability fail to establish a working connection > between two ENO-compliant hosts when SYN-form ENO options have been > altered in transit. (Of course, in the absence of endpoint > authentication, two compliant hosts can each still be connected to a > man-in-the-middle attacker.) To detect SYN-form ENO option > tampering, TEPs must reference a transcript of TCP-ENO's negotiation. > > ... > > Because TCP-ENO enables multiple different TEPs to coexist, security > could potentially be only as strong as the weakest available TEP. In > particular, if session IDs do not depend on the TCP-ENO transcript in > a strong way, an attacker can undetectably tamper with ENO options to > force negotiation of a deprecated and vulnerable TEP. To avoid such > problems, TEPs MUST compute session IDs using only well-studied and > conservative hash functions. That way, even if other parts of a TEP > are vulnerable, it is still intractable for an attacker to induce > identical session IDs at both ends after tampering with ENO contents > in SYN segments. > > The goal here is indeed to thwart both cross-TEP attacks and TEP > downgrade attacks, but to do so without mandating a particular hash > function for all TEPS, because that would severely hamper crypto > agility. The extra byte in session IDs should save us from cases where > somehow both SHA-512 and Keccac are secure, but someone found two inputs > x and y such that SHA-512(x)==SHA-3(y) causing reuse of Session IDs > across TEPs. So I can't figure out the attack you are worried about... > Ah, that does work. Thanks for responding to my review. > > Thanks, > David > -- "Man is born free, but everywhere he is in chains". --Rousseau. --001a11415848bdf5e3055be776f9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Oct 19, 2017 at 2:34 AM, David Mazieres <<= a href=3D"mailto:dm-list-tcpcrypt@scs.stanford.edu" target=3D"_blank">dm-li= st-tcpcrypt@scs.stanford.edu> wrote:
Watson Ladd <watsonbladd@gmail.com> writes:

> Dear all,
>
> I have reviewed this document as part of the security directorate'= s
> ongoing effort to review all IETF documents being processed by the
> IESG.=C2=A0 These comments were written primarily for the benefit of t= he
> security area directors.=C2=A0 Document editors and WG chairs should t= reat
> these comments just like any other last call comments.
>
> The summary of the review is that the writing and most of the
> structure is fine, but I am a bit confused by some of the security
> properties and how they are stated. It is not clear to me why the
> unpredictability of generated session IDs is required.

Thanks for your review.

Unpredictability of session IDs is required because doing so is not
particularly burdensome and because it's a very strong property that subsumes the security requirements of a broad range of cases where
things might otherwise go wrong.=C2=A0 For example, the TEP has to be 33 bytes, and we don't want the last 16 of them being zeros.=C2=A0 Moreove= r, if
people sign session IDs for authentication, we want to be absolutely
sure they don't mess up the domain separation.=C2=A0 As another example= ,
someone might use a session ID on one connection to try to authenticate
a session ID on another.=C2=A0 Do you buy this rationale?=C2=A0 And is it important enough that you think we need to add a subsection to the
rationale section discussing it?

More r= ational for the requirement would I think help.

> It is also not clear to me that the requirement that a TEP produce
> different keys for different transcripts is strong enough: we need to<= br> > ensure that every TEP produces different keys (with high probability)<= br> > (and session identifiers) for different transcripts to prevent
> cross-protocol attacks.

Do you mind clarifying this comment?=C2=A0 I assume it's in rela= tion the
following two paragraphs from sections 4.8 and 10 respectively?

=C2=A0 =C2=A0To defend against attacks on encryption negotiation itself, a = TEP
=C2=A0 =C2=A0MUST with high probability fail to establish a working connect= ion
=C2=A0 =C2=A0between two ENO-compliant hosts when SYN-form ENO options have= been
=C2=A0 =C2=A0altered in transit.=C2=A0 (Of course, in the absence of endpoi= nt
=C2=A0 =C2=A0authentication, two compliant hosts can each still be connecte= d to a
=C2=A0 =C2=A0man-in-the-middle attacker.)=C2=A0 To detect SYN-form ENO opti= on
=C2=A0 =C2=A0tampering, TEPs must reference a transcript of TCP-ENO's n= egotiation.

=C2=A0 =C2=A0...

=C2=A0 =C2=A0Because TCP-ENO enables multiple different TEPs to coexist, se= curity
=C2=A0 =C2=A0could potentially be only as strong as the weakest available T= EP.=C2=A0 In
=C2=A0 =C2=A0particular, if session IDs do not depend on the TCP-ENO transc= ript in
=C2=A0 =C2=A0a strong way, an attacker can undetectably tamper with ENO opt= ions to
=C2=A0 =C2=A0force negotiation of a deprecated and vulnerable TEP.=C2=A0 To= avoid such
=C2=A0 =C2=A0problems, TEPs MUST compute session IDs using only well-studie= d and
=C2=A0 =C2=A0conservative hash functions.=C2=A0 That way, even if other par= ts of a TEP
=C2=A0 =C2=A0are vulnerable, it is still intractable for an attacker to ind= uce
=C2=A0 =C2=A0identical session IDs at both ends after tampering with ENO co= ntents
=C2=A0 =C2=A0in SYN segments.

The goal here is indeed to thwart both cross-TEP attacks and TEP
downgrade attacks, but to do so without mandating a particular hash
function for all TEPS, because that would severely hamper crypto
agility.=C2=A0 The extra byte in session IDs should save us from cases wher= e
somehow both SHA-512 and Keccac are secure, but someone found two inputs x and y such that SHA-512(x)=3D=3DSHA-3(y) causing reuse of Session IDs
across TEPs.=C2=A0 So I can't figure out the attack you are worried abo= ut...

Ah, that does work. Thanks for re= sponding to my review.
=C2=A0

Thanks,
David



--
"Man is born f= ree, but everywhere he is in chains".
--Rousseau.
--001a11415848bdf5e3055be776f9-- From nobody Fri Oct 20 02:24:40 2017 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 94CEA132697; Fri, 20 Oct 2017 02:24:34 -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, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, SPF_PASS=-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 SfTMXudkym97; Fri, 20 Oct 2017 02:24:33 -0700 (PDT) Received: from market.scs.stanford.edu (www.scs.stanford.edu [IPv6:2001:470:806d:1::9]) (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 C43481320D8; Fri, 20 Oct 2017 02:24:33 -0700 (PDT) Received: from market.scs.stanford.edu (localhost [127.0.0.1]) by market.scs.stanford.edu (8.15.2/8.15.2) with ESMTP id v9K9OWFM076452; Fri, 20 Oct 2017 02:24:32 -0700 (PDT) Received: (from dm@localhost) by market.scs.stanford.edu (8.15.2/8.15.2/Submit) id v9K9OWkf022309; Fri, 20 Oct 2017 02:24:32 -0700 (PDT) From: David Mazieres To: tcpinc , secdir@ietf.org, Watson Ladd In-Reply-To: References: <87o9p3wkek.fsf@ta.scs.stanford.edu> Reply-To: David Mazieres expires 2018-01-18 PST Date: Fri, 20 Oct 2017 02:24:32 -0700 Message-ID: <87a80mxjcf.fsf@ta.scs.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: [secdir] New TCP-ENO draft X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 09:24:34 -0000 There's a new TCP-ENO draft in the usual place: https://datatracker.ietf.org/doc/draft-ietf-tcpinc-tcpeno/ This draft addresses last call comments we received. Other than some typos, the main changes are to update the requirements language (section 1) to use RFC8174 and to add a new section 8.5. Since 8.5 contains new language, we'd appreciate other eyes on this paragraph (even just comments saying "looks fine" would be helpful): 8.5. Unpredictability of session IDs Section 5.1 specifies that all but the first (TEP identifier) byte of a session ID MUST be computationally indistinguishable from random bytes to a network eavesdropper. This property is easy to ensure under standard assumptions about cryptographic hash functions. Such unpredictability helps security in a broad range of cases. For example, it makes it possible for applications to use a session ID from one connection to authenticate a session ID from another, thereby tying the two connections together. If furthermore helps ensure that TEPs do not trivially subvert the 33-byte minimum length requirement for session IDs by padding shorter session IDs with zeros. Thanks, David From nobody Fri Oct 20 15:04:45 2017 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 2BFBD1342E6 for ; Fri, 20 Oct 2017 15:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 UCnpM3LJdJn1 for ; Fri, 20 Oct 2017 15:04:27 -0700 (PDT) Received: from mail-in6.apple.com (mail-out6.apple.com [17.151.62.28]) (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 81AC5134451 for ; Fri, 20 Oct 2017 15:04:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1508537063; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ct7EQtLelpiIkfite9iMEYLWo7+VC7nwdk2p8cqYQrs=; b=N9RFvV89awKGMB/rODQIPu7rg43YwqvmAc5mEEveCCo/blUgfmC0n4IIxFqJqGx4 N3mbCUfMAREqdcv2PBKFGhr+/nhqb1nAAbny38lMcxO7xPVNnmWg+sAV0wQl0lv7 B39wpAX1gnB9a/w6pRxsNS9uclWK0m1ZRaf44dy5AQeldGgdUR7Wu8BB/21j2MZb dZS9QSyPS8FmoNnMty7Y3oag7D6fZEalNrQv6iJ1OSrFcl5vC9/I+ZbqFfwQeewG QacV3NRxgeGbms2UXTvPT6GHoB2wtK+Z8ZtTeDZWLjl0npys6l9gXom9lnhMFhJA uYgBmj4QHQoKmodI6Ti5gQ==; Received: from relay4.apple.com (relay4.apple.com [17.128.113.87]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in6.apple.com (Apple Secure Mail Relay) with SMTP id B4.A3.23776.7E27AE95; Fri, 20 Oct 2017 15:04:23 -0700 (PDT) X-AuditID: 11973e15-3421e9c000005ce0-36-59ea72e77cef Received: from nwk-mmpp-sz09.apple.com (nwk-mmpp-sz09.apple.com [17.128.115.80]) by relay4.apple.com (Apple SCV relay) with SMTP id 43.F8.31187.7E27AE95; Fri, 20 Oct 2017 15:04:23 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_HrV5ZiY671tfC16Z/oJ3uw)" Received: from [17.234.83.63] by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.1.3.20170825 64bit (built Aug 25 2017)) with ESMTPSA id <0OY5006PM6NAR080@nwk-mmpp-sz09.apple.com>; Fri, 20 Oct 2017 15:04:23 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly Message-id: <3A0867BC-D16E-4350-843B-832DFBF2C9E8@apple.com> Date: Fri, 20 Oct 2017 15:04:21 -0700 In-reply-to: <150661534403.27693.10060826661300587258@ietfa.amsl.com> Cc: secdir@ietf.org, v6ops@ietf.org, ietf@ietf.org, draft-ietf-v6ops-rfc6555bis.all@ietf.org To: Brian Weis References: <150661534403.27693.10060826661300587258@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.5.5) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrLLMWRmVeSWpSXmKPExsUi2FAYrvu86FWkwZILvBZ9bxtZLXYsuMts 8WzjfBaLDwsfslicPraX2YHVY8rvjaweS5b8ZApgiuKySUnNySxLLdK3S+DKuHXwE2PBUduK HZfbGRsYt5h0MXJySAiYSOw4+ZgRxBYSWM0kcfWYURcjB1h8YmcIRPggo0TLej0Qm1dAUOLH 5HssIDazQJjE2ZeL2CBqvjBK3P9aDNIqLCAhsXlPIkiYTUBF4vi3DcwQrTYSv3dOAWsVFvCT 6O1tBNvKIqAqsf/VERaQVk4BV4mpl6ohpsdJPPjUBdYqIiAnMe/3BVaITS4SLz88ZIQ4XlHi 4aYuoDgXkL2CTWLq+c2MExiFZiG5dBaSS2cBrWAWUJeYMiUXIqwt8eTdBVYIW01i4e9FTMji CxjZVjEK5SZm5uhm5pnpJRYU5KTqJefnbmIExcd0O9EdjGdWWR1iFOBgVOLhrRB7FSnEmlhW XJl7iFGag0VJnLc3BygkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBcdaUmZczeHYsi+1nLw1I Wvd/sWT5gvv+YZvnP//+ZIv91oL0aDVd+eS3N/t5xc5zJ89NiguzF7XZdH8r/3KO3MLfC2OW zOKwtuaauOuFcJvlir5nSg2P+s74rL/GGlPNUfzguWOd7f13/41uVHyS3FBYPvfBNoVVL+Km VHXoLYu4Hjvz1pxL3kosxRmJhlrMRcWJAIGsCDZwAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrILMWRmVeSWpSXmKPExsUi2FAcoPu86FWkweY/nBZ9bxtZLXYsuMts 8WzjfBaLDwsfslicPraX2YHVY8rvjaweS5b8ZApgiuKySUnNySxLLdK3S+DKuHXwE2PBUduK HZfbGRsYt5h0MXJwSAiYSEzsDOli5OQQEjjIKNGyXg/E5hUQlPgx+R4LiM0sECZx9uUiNoia L4wS978Wg7QKC0hIbN6TCBJmE1CROP5tAzNEq43E751TwFqFBfwkensbGUFsFgFVif2vjrCA tHIKuEpMvVQNMT1O4sGnLrBWEQE5iXm/L7BCbHKRePnhIVirhICixMNNXawTGPlnITluFpLj ZgFNZRZQl5gyJRcirC3x5N0FVghbTWLh70VMyOILGNlWMQoUpeYkVproJRYU5KTqJefnbmIE B3Rh+A7Gf8usDjEKcDAq8fBekHgVKcSaWFZcmXuIUYKDWUmE92EhUIg3JbGyKrUoP76oNCe1 +BCjNAeLkjjvjjtPIoUE0hNLUrNTUwtSi2CyTBycUg2M7gc+KL5tsT4rKMgtxyItq9UqpXxa cPPzvS+lZ61S+Lf7fWzeFT8715OvLNz+GLTtuPE++2xAxMVdugVc73P3z7275//F7R/XiejN K+mbIOt6P8RRatmU2bxnNzG8qXPZlecSf89nXoVej1ObGePFwM64s0e7bYr7p8u+Nn/zJdTp Qd63lLY0JZbijERDLeai4kQAeHZdcmQCAAA= Archived-At: Subject: Re: [secdir] [v6ops] Secdir last call review of draft-ietf-v6ops-rfc6555bis-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 22:04:29 -0000 --Boundary_(ID_HrV5ZiY671tfC16Z/oJ3uw) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Hello Brian, Thanks for your review! We've just posted a new version of the draft = that includes an extra section in the security considerations. https://tools.ietf.org/html/draft-ietf-v6ops-rfc6555bis-06 = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-rfc6555bis-06 = The references in RFC 6555 to Same-Origin Policy point to RFC 6454. That = document actually only references that the policy gates schemes, hosts, = and ports=E2=80=94not IP addresses directly. Relying on consistent IP = address results from hostname resolution as a security property would be = a problem that arises any time a new DNS query is made, so we believe = that Happy Eyeballs does not actually expose any new concern here. Using = TLS to validate the identity of a server, along with validation of the = same host, port, and scheme, should avoid any concern with using = different DNS results. The comment I've added to the security considerations indicates that = implementations should not assume that addresses will be consistent for = a hostname as a security property, and that Happy Eyeballs may make it = more likely in some scenarios that an address will change between = connection attempts. Thanks, Tommy > On Sep 28, 2017, at 9:15 AM, Brian Weis wrote: >=20 > Reviewer: Brian Weis > 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 >> =46rom the Introduction, "This document expands on "Happy Eyeballs" = [RFC6555], a > technique of reducing user-visible delays on dual-stack hosts." It = lists a set > of steps by which a client can asynchronously perform IPv6 and IPv4 = DNS > queries, and also semantics on how to handle the replies such that the = user > delay is minimized. >=20 > The Security Considerations section simply states "This memo has no = direct > security considerations.", and I believe this is true. However, I = wonder about > "indirect" security considerations. RFC 6555 warns several times = against > breaking a browser's same-origin policy, which seems to me to be an = "indirect" > security consideration. I realize that browser policies have changed > considerably since RFC 6555 was published, and I personally do not = know if > same-origin is still in general use or whether there are other newer = but > similar issues of which an implementor should be aware. But if there = are, then > this section should note them. Otherwise, I consider the document = ready to be > published. >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Boundary_(ID_HrV5ZiY671tfC16Z/oJ3uw) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable Hello= Brian,

Thanks for = your review! We've just posted a new version of the draft that includes = an extra section in the security considerations.

https://tools.ietf.org/html/draft-ietf-v6ops-rfc6555bis-06<= br class=3D"">https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-rfc6555bis= -06

The = references in RFC 6555 to Same-Origin Policy point to RFC 6454. That = document actually only references that the policy gates schemes, hosts, = and ports=E2=80=94not IP addresses directly. Relying on consistent IP = address results from hostname resolution as a security property would be = a problem that arises any time a new DNS query is made, so we believe = that Happy Eyeballs does not actually expose any new concern here. Using = TLS to validate the identity of a server, along with validation of the = same host, port, and scheme, should avoid any concern with using = different DNS results.

The comment I've added to the security considerations = indicates that implementations should not assume that addresses will be = consistent for a hostname as a security property, and that Happy = Eyeballs may make it more likely in some scenarios that an address will = change between connection attempts.

Thanks,
Tommy

On Sep 28, 2017, at 9:15 AM, = Brian Weis <bew@cisco.com> wrote:

Reviewer: Brian Weis
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.

=46rom the Introduction, = "This document expands on "Happy Eyeballs" [RFC6555], a
technique of reducing user-visible delays on = dual-stack hosts." It lists a set
of steps by which a = client can asynchronously perform IPv6 and IPv4 DNS
queries,= and also semantics on how to handle the replies such that the user
delay is minimized.

The Security = Considerations section simply states "This memo has no direct
security considerations.", and I believe this is true. = However, I wonder about
"indirect" security = considerations. RFC 6555 warns several times against
breaking a browser's same-origin policy, which seems to me to = be an "indirect"
security consideration. I realize that = browser policies have changed
considerably since RFC 6555 = was published, and I personally do not know if
same-origin = is still in general use or whether there are other newer but
similar issues of which an implementor should be aware. But = if there are, then
this section should note them. = Otherwise, I consider the document ready to be
published.
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops

= --Boundary_(ID_HrV5ZiY671tfC16Z/oJ3uw)-- From nobody Fri Oct 20 17:23:48 2017 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 C82D9134326; Fri, 20 Oct 2017 17:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KzozuOJ6XRhV; Fri, 20 Oct 2017 17:23:38 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 660E812ECEC; Fri, 20 Oct 2017 17:23:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12158; q=dns/txt; s=iport; t=1508545418; x=1509755018; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=knGA335VQSnYQqwE2N2WAV9QXGFzI6vxrxwjEPQNLmU=; b=JuaHUDdlZQWLbcZ+kY9dm4PbjGJAn44keQkzfBPgq2JtL9Pn+3a0oq+O um16fZksuoDOxBQSuTW5SIeTlJUubvTS0B9DvKqhvAYYOwHvinFb0yhZ+ R06BL3tAerFRg4r5XKOKxkKyq2oB6/wUiuP5cg8fW4AfLXtfVkP2QNS1I Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DNAAAHk+pZ/4wNJK1TBgMZAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGDX2RuJweDc4ofj0CScIVBEIIBChgBCoUYAhqEIT8YAQIBAQE?= =?us-ascii?q?BAQEBayiFHgIBAwEBIUsLEAIBCA4CLwMCAgIlCxQRAgQOBYk8ZBCqf4IniyQBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEYBYMuggeDOSmDAYMygSABCAoBCS0KJoJNL4I?= =?us-ascii?q?yBaFfAodhjQ6CFZEKkmUsgjwCERkBgTgBHziBA1h6FUktAYI2hF92iBwNGAeBB?= =?us-ascii?q?YERAQEB?= X-IronPort-AV: E=Sophos;i="5.43,408,1503360000"; d="scan'208,217";a="313425614" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Oct 2017 00:23:36 +0000 Received: from XCH-RTP-005.cisco.com (xch-rtp-005.cisco.com [64.101.220.145]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v9L0Nacw001795 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 21 Oct 2017 00:23:36 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-005.cisco.com (64.101.220.145) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 20 Oct 2017 20:23:35 -0400 Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1320.000; Fri, 20 Oct 2017 20:23:35 -0400 From: "Brian Weis (bew)" To: Tommy Pauly CC: "secdir@ietf.org" , "v6ops@ietf.org" , "ietf@ietf.org" , "draft-ietf-v6ops-rfc6555bis.all@ietf.org" Thread-Topic: [v6ops] Secdir last call review of draft-ietf-v6ops-rfc6555bis-05 Thread-Index: AQHTSe9lZB3LABs0BESiUtIkFPc68aLttO0A Date: Sat, 21 Oct 2017 00:23:35 +0000 Message-ID: <642F6417-5C01-4F95-A0B0-BEBA7A475D58@cisco.com> References: <150661534403.27693.10060826661300587258@ietfa.amsl.com> <3A0867BC-D16E-4350-843B-832DFBF2C9E8@apple.com> In-Reply-To: <3A0867BC-D16E-4350-843B-832DFBF2C9E8@apple.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.41.32.182] Content-Type: multipart/alternative; boundary="_000_642F64175C014F95A0B0BEBA7A475D58ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] [v6ops] Secdir last call review of draft-ietf-v6ops-rfc6555bis-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Oct 2017 00:23:41 -0000 --_000_642F64175C014F95A0B0BEBA7A475D58ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgVG9tbXksDQoNClRoYW5rcyBmb3IgdGhlIGJhY2tncm91bmQgaW5mby4gWW91ciBuZXcgdGV4 dCBpbiB0aGUgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgbG9va3MgZ3JlYXQgdG8gbWUsIGFuZCBJ IGNvbnNpZGVyIHRoaXMgZG9jdW1lbnQgUmVhZHkgdG8gcHVibGlzaC4NCg0KVGhhbmtzLA0KQnJp YW4NCg0KT24gT2N0IDIwLCAyMDE3LCBhdCAzOjA0IFBNLCBUb21teSBQYXVseSA8dHBhdWx5QGFw cGxlLmNvbTxtYWlsdG86dHBhdWx5QGFwcGxlLmNvbT4+IHdyb3RlOg0KDQpIZWxsbyBCcmlhbiwN Cg0KVGhhbmtzIGZvciB5b3VyIHJldmlldyEgV2UndmUganVzdCBwb3N0ZWQgYSBuZXcgdmVyc2lv biBvZiB0aGUgZHJhZnQgdGhhdCBpbmNsdWRlcyBhbiBleHRyYSBzZWN0aW9uIGluIHRoZSBzZWN1 cml0eSBjb25zaWRlcmF0aW9ucy4NCg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtdjZvcHMtcmZjNjU1NWJpcy0wNg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91 cmwyPWRyYWZ0LWlldGYtdjZvcHMtcmZjNjU1NWJpcy0wNg0KDQpUaGUgcmVmZXJlbmNlcyBpbiBS RkMgNjU1NSB0byBTYW1lLU9yaWdpbiBQb2xpY3kgcG9pbnQgdG8gUkZDIDY0NTQuIFRoYXQgZG9j dW1lbnQgYWN0dWFsbHkgb25seSByZWZlcmVuY2VzIHRoYXQgdGhlIHBvbGljeSBnYXRlcyBzY2hl bWVzLCBob3N0cywgYW5kIHBvcnRz4oCUbm90IElQIGFkZHJlc3NlcyBkaXJlY3RseS4gUmVseWlu ZyBvbiBjb25zaXN0ZW50IElQIGFkZHJlc3MgcmVzdWx0cyBmcm9tIGhvc3RuYW1lIHJlc29sdXRp b24gYXMgYSBzZWN1cml0eSBwcm9wZXJ0eSB3b3VsZCBiZSBhIHByb2JsZW0gdGhhdCBhcmlzZXMg YW55IHRpbWUgYSBuZXcgRE5TIHF1ZXJ5IGlzIG1hZGUsIHNvIHdlIGJlbGlldmUgdGhhdCBIYXBw eSBFeWViYWxscyBkb2VzIG5vdCBhY3R1YWxseSBleHBvc2UgYW55IG5ldyBjb25jZXJuIGhlcmUu IFVzaW5nIFRMUyB0byB2YWxpZGF0ZSB0aGUgaWRlbnRpdHkgb2YgYSBzZXJ2ZXIsIGFsb25nIHdp dGggdmFsaWRhdGlvbiBvZiB0aGUgc2FtZSBob3N0LCBwb3J0LCBhbmQgc2NoZW1lLCBzaG91bGQg YXZvaWQgYW55IGNvbmNlcm4gd2l0aCB1c2luZyBkaWZmZXJlbnQgRE5TIHJlc3VsdHMuDQoNClRo ZSBjb21tZW50IEkndmUgYWRkZWQgdG8gdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGluZGlj YXRlcyB0aGF0IGltcGxlbWVudGF0aW9ucyBzaG91bGQgbm90IGFzc3VtZSB0aGF0IGFkZHJlc3Nl cyB3aWxsIGJlIGNvbnNpc3RlbnQgZm9yIGEgaG9zdG5hbWUgYXMgYSBzZWN1cml0eSBwcm9wZXJ0 eSwgYW5kIHRoYXQgSGFwcHkgRXllYmFsbHMgbWF5IG1ha2UgaXQgbW9yZSBsaWtlbHkgaW4gc29t ZSBzY2VuYXJpb3MgdGhhdCBhbiBhZGRyZXNzIHdpbGwgY2hhbmdlIGJldHdlZW4gY29ubmVjdGlv biBhdHRlbXB0cy4NCg0KVGhhbmtzLA0KVG9tbXkNCg0KT24gU2VwIDI4LCAyMDE3LCBhdCA5OjE1 IEFNLCBCcmlhbiBXZWlzIDxiZXdAY2lzY28uY29tPG1haWx0bzpiZXdAY2lzY28uY29tPj4gd3Jv dGU6DQoNClJldmlld2VyOiBCcmlhbiBXZWlzDQpSZXZpZXcgcmVzdWx0OiBIYXMgTml0cw0KDQpJ IGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhcyBwYXJ0IG9mIHRoZSBzZWN1cml0eSBkaXJl Y3RvcmF0ZSdzIG9uZ29pbmcNCmVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJl aW5nIHByb2Nlc3NlZCBieSB0aGUgSUVTRy4gVGhlc2UgY29tbWVudHMNCndlcmUgd3JpdHRlbiBw cmltYXJpbHkgZm9yIHRoZSBiZW5lZml0IG9mIHRoZSBzZWN1cml0eSBhcmVhIGRpcmVjdG9ycy4g RG9jdW1lbnQNCmVkaXRvcnMgYW5kIFdHIGNoYWlycyBzaG91bGQgdHJlYXQgdGhlc2UgY29tbWVu dHMganVzdCBsaWtlIGFueSBvdGhlciBsYXN0IGNhbGwNCmNvbW1lbnRzLg0KDQpGcm9tIHRoZSBJ bnRyb2R1Y3Rpb24sICJUaGlzIGRvY3VtZW50IGV4cGFuZHMgb24gIkhhcHB5IEV5ZWJhbGxzIiBb UkZDNjU1NV0sIGENCnRlY2huaXF1ZSBvZiByZWR1Y2luZyB1c2VyLXZpc2libGUgZGVsYXlzIG9u IGR1YWwtc3RhY2sgaG9zdHMuIiBJdCBsaXN0cyBhIHNldA0Kb2Ygc3RlcHMgYnkgd2hpY2ggYSBj bGllbnQgY2FuIGFzeW5jaHJvbm91c2x5IHBlcmZvcm0gSVB2NiBhbmQgSVB2NCBETlMNCnF1ZXJp ZXMsIGFuZCBhbHNvIHNlbWFudGljcyBvbiBob3cgdG8gaGFuZGxlIHRoZSByZXBsaWVzIHN1Y2gg dGhhdCB0aGUgdXNlcg0KZGVsYXkgaXMgbWluaW1pemVkLg0KDQpUaGUgU2VjdXJpdHkgQ29uc2lk ZXJhdGlvbnMgc2VjdGlvbiBzaW1wbHkgc3RhdGVzICJUaGlzIG1lbW8gaGFzIG5vIGRpcmVjdA0K c2VjdXJpdHkgY29uc2lkZXJhdGlvbnMuIiwgYW5kIEkgYmVsaWV2ZSB0aGlzIGlzIHRydWUuIEhv d2V2ZXIsIEkgd29uZGVyIGFib3V0DQoiaW5kaXJlY3QiIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25z LiBSRkMgNjU1NSB3YXJucyBzZXZlcmFsIHRpbWVzIGFnYWluc3QNCmJyZWFraW5nIGEgYnJvd3Nl cidzIHNhbWUtb3JpZ2luIHBvbGljeSwgd2hpY2ggc2VlbXMgdG8gbWUgdG8gYmUgYW4gImluZGly ZWN0Ig0Kc2VjdXJpdHkgY29uc2lkZXJhdGlvbi4gSSByZWFsaXplIHRoYXQgYnJvd3NlciBwb2xp Y2llcyBoYXZlIGNoYW5nZWQNCmNvbnNpZGVyYWJseSBzaW5jZSBSRkMgNjU1NSB3YXMgcHVibGlz aGVkLCBhbmQgSSBwZXJzb25hbGx5IGRvIG5vdCBrbm93IGlmDQpzYW1lLW9yaWdpbiBpcyBzdGls bCBpbiBnZW5lcmFsIHVzZSBvciB3aGV0aGVyIHRoZXJlIGFyZSBvdGhlciBuZXdlciBidXQNCnNp bWlsYXIgaXNzdWVzIG9mIHdoaWNoIGFuIGltcGxlbWVudG9yIHNob3VsZCBiZSBhd2FyZS4gQnV0 IGlmIHRoZXJlIGFyZSwgdGhlbg0KdGhpcyBzZWN0aW9uIHNob3VsZCBub3RlIHRoZW0uIE90aGVy d2lzZSwgSSBjb25zaWRlciB0aGUgZG9jdW1lbnQgcmVhZHkgdG8gYmUNCnB1Ymxpc2hlZC4NCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnY2b3BzIG1h aWxpbmcgbGlzdA0KdjZvcHNAaWV0Zi5vcmc8bWFpbHRvOnY2b3BzQGlldGYub3JnPg0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KDQoNCi0tDQpCcmlhbiBXZWlz DQpTZWN1cml0eSwgQ1NHLCBDaXNjbyBTeXN0ZW1zDQpUZWxlcGhvbmU6ICsxIDQwOCA1MjYgNDc5 Ng0KRW1haWw6IGJld0BjaXNjby5jb208bWFpbHRvOmJld0BjaXNjby5jb20+DQoNCg== --_000_642F64175C014F95A0B0BEBA7A475D58ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <73C4CBAC3A3FC444B302D834E5DCB8B4@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGkgVG9tbXksDQo8ZGl2IGNsYXNz PSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGFua3MgZm9yIHRoZSBi YWNrZ3JvdW5kIGluZm8uIFlvdXIgbmV3IHRleHQgaW4gdGhlIFNlY3VyaXR5IENvbnNpZGVyYXRp b25zIGxvb2tzIGdyZWF0IHRvIG1lLCBhbmQgSSBjb25zaWRlciB0aGlzIGRvY3VtZW50IFJlYWR5 IHRvIHB1Ymxpc2guPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj5UaGFua3MsPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkJyaWFuPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxkaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRl IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gT2N0IDIwLCAyMDE3LCBhdCAzOjA0IFBNLCBU b21teSBQYXVseSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRwYXVseUBhcHBsZS5jb20iIGNsYXNzPSIi PnRwYXVseUBhcHBsZS5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUt aW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0id29yZC13 cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IGxpbmUtYnJlYWs6IGFm dGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQpIZWxsbyBCcmlhbiwNCjxkaXYgY2xhc3M9IiI+ PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRoYW5rcyBmb3IgeW91ciByZXZp ZXchIFdlJ3ZlIGp1c3QgcG9zdGVkIGEgbmV3IHZlcnNpb24gb2YgdGhlIGRyYWZ0IHRoYXQgaW5j bHVkZXMgYW4gZXh0cmEgc2VjdGlvbiBpbiB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMuPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48 YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi12Nm9wcy1yZmM2 NTU1YmlzLTA2IiBjbGFzcz0iIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi12Nm9wcy1yZmM2NTU1YmlzLTA2PC9hPjxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXY2b3BzLXJmYzY1NTViaXMtMDYi IGNsYXNzPSIiPmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXY2 b3BzLXJmYzY1NTViaXMtMDY8L2E+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGUgcmVmZXJlbmNlcyBpbiBSRkMgNjU1NSB0byBTYW1l LU9yaWdpbiBQb2xpY3kgcG9pbnQgdG8gUkZDIDY0NTQuIFRoYXQgZG9jdW1lbnQgYWN0dWFsbHkg b25seSByZWZlcmVuY2VzIHRoYXQgdGhlIHBvbGljeSBnYXRlcyBzY2hlbWVzLCBob3N0cywgYW5k IHBvcnRz4oCUbm90IElQIGFkZHJlc3NlcyBkaXJlY3RseS4gUmVseWluZyBvbiBjb25zaXN0ZW50 IElQIGFkZHJlc3MgcmVzdWx0cyBmcm9tIGhvc3RuYW1lIHJlc29sdXRpb24NCiBhcyBhIHNlY3Vy aXR5IHByb3BlcnR5IHdvdWxkIGJlIGEgcHJvYmxlbSB0aGF0IGFyaXNlcyBhbnkgdGltZSBhIG5l dyBETlMgcXVlcnkgaXMgbWFkZSwgc28gd2UgYmVsaWV2ZSB0aGF0IEhhcHB5IEV5ZWJhbGxzIGRv ZXMgbm90IGFjdHVhbGx5IGV4cG9zZSBhbnkgbmV3IGNvbmNlcm4gaGVyZS4gVXNpbmcgVExTIHRv IHZhbGlkYXRlIHRoZSBpZGVudGl0eSBvZiBhIHNlcnZlciwgYWxvbmcgd2l0aCB2YWxpZGF0aW9u IG9mIHRoZSBzYW1lIGhvc3QsDQogcG9ydCwgYW5kIHNjaGVtZSwgc2hvdWxkIGF2b2lkIGFueSBj b25jZXJuIHdpdGggdXNpbmcgZGlmZmVyZW50IEROUyByZXN1bHRzLjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhlIGNvbW1lbnQgSSd2 ZSBhZGRlZCB0byB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgaW5kaWNhdGVzIHRoYXQgaW1w bGVtZW50YXRpb25zIHNob3VsZCBub3QgYXNzdW1lIHRoYXQgYWRkcmVzc2VzIHdpbGwgYmUgY29u c2lzdGVudCBmb3IgYSBob3N0bmFtZSBhcyBhIHNlY3VyaXR5IHByb3BlcnR5LCBhbmQgdGhhdCBI YXBweSBFeWViYWxscyBtYXkgbWFrZSBpdCBtb3JlIGxpa2VseSBpbiBzb21lIHNjZW5hcmlvcyB0 aGF0DQogYW4gYWRkcmVzcyB3aWxsIGNoYW5nZSBiZXR3ZWVuIGNvbm5lY3Rpb24gYXR0ZW1wdHMu PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij5UaGFua3MsPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRvbW15PC9kaXY+DQo8ZGl2IGNsYXNzPSIi Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBj bGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gU2VwIDI4LCAyMDE3LCBhdCA5OjE1IEFNLCBCcmlh biBXZWlzICZsdDs8YSBocmVmPSJtYWlsdG86YmV3QGNpc2NvLmNvbSIgY2xhc3M9IiI+YmV3QGNp c2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5n ZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPlJldmlld2VyOiBCcmlh biBXZWlzPGJyIGNsYXNzPSIiPg0KUmV2aWV3IHJlc3VsdDogSGFzIE5pdHM8YnIgY2xhc3M9IiI+ DQo8YnIgY2xhc3M9IiI+DQpJIGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhcyBwYXJ0IG9m IHRoZSBzZWN1cml0eSBkaXJlY3RvcmF0ZSdzIG9uZ29pbmc8YnIgY2xhc3M9IiI+DQplZmZvcnQg dG8gcmV2aWV3IGFsbCBJRVRGIGRvY3VtZW50cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhlIElFU0cu IFRoZXNlIGNvbW1lbnRzPGJyIGNsYXNzPSIiPg0Kd2VyZSB3cml0dGVuIHByaW1hcmlseSBmb3Ig dGhlIGJlbmVmaXQgb2YgdGhlIHNlY3VyaXR5IGFyZWEgZGlyZWN0b3JzLiBEb2N1bWVudDxiciBj bGFzcz0iIj4NCmVkaXRvcnMgYW5kIFdHIGNoYWlycyBzaG91bGQgdHJlYXQgdGhlc2UgY29tbWVu dHMganVzdCBsaWtlIGFueSBvdGhlciBsYXN0IGNhbGw8YnIgY2xhc3M9IiI+DQpjb21tZW50cy48 YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFz cz0iIj5Gcm9tIHRoZSBJbnRyb2R1Y3Rpb24sICZxdW90O1RoaXMgZG9jdW1lbnQgZXhwYW5kcyBv biAmcXVvdDtIYXBweSBFeWViYWxscyZxdW90OyBbUkZDNjU1NV0sIGE8YnIgY2xhc3M9IiI+DQo8 L2Jsb2NrcXVvdGU+DQp0ZWNobmlxdWUgb2YgcmVkdWNpbmcgdXNlci12aXNpYmxlIGRlbGF5cyBv biBkdWFsLXN0YWNrIGhvc3RzLiZxdW90OyBJdCBsaXN0cyBhIHNldDxiciBjbGFzcz0iIj4NCm9m IHN0ZXBzIGJ5IHdoaWNoIGEgY2xpZW50IGNhbiBhc3luY2hyb25vdXNseSBwZXJmb3JtIElQdjYg YW5kIElQdjQgRE5TPGJyIGNsYXNzPSIiPg0KcXVlcmllcywgYW5kIGFsc28gc2VtYW50aWNzIG9u IGhvdyB0byBoYW5kbGUgdGhlIHJlcGxpZXMgc3VjaCB0aGF0IHRoZSB1c2VyPGJyIGNsYXNzPSIi Pg0KZGVsYXkgaXMgbWluaW1pemVkLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClRoZSBT ZWN1cml0eSBDb25zaWRlcmF0aW9ucyBzZWN0aW9uIHNpbXBseSBzdGF0ZXMgJnF1b3Q7VGhpcyBt ZW1vIGhhcyBubyBkaXJlY3Q8YnIgY2xhc3M9IiI+DQpzZWN1cml0eSBjb25zaWRlcmF0aW9ucy4m cXVvdDssIGFuZCBJIGJlbGlldmUgdGhpcyBpcyB0cnVlLiBIb3dldmVyLCBJIHdvbmRlciBhYm91 dDxiciBjbGFzcz0iIj4NCiZxdW90O2luZGlyZWN0JnF1b3Q7IHNlY3VyaXR5IGNvbnNpZGVyYXRp b25zLiBSRkMgNjU1NSB3YXJucyBzZXZlcmFsIHRpbWVzIGFnYWluc3Q8YnIgY2xhc3M9IiI+DQpi cmVha2luZyBhIGJyb3dzZXIncyBzYW1lLW9yaWdpbiBwb2xpY3ksIHdoaWNoIHNlZW1zIHRvIG1l IHRvIGJlIGFuICZxdW90O2luZGlyZWN0JnF1b3Q7PGJyIGNsYXNzPSIiPg0Kc2VjdXJpdHkgY29u c2lkZXJhdGlvbi4gSSByZWFsaXplIHRoYXQgYnJvd3NlciBwb2xpY2llcyBoYXZlIGNoYW5nZWQ8 YnIgY2xhc3M9IiI+DQpjb25zaWRlcmFibHkgc2luY2UgUkZDIDY1NTUgd2FzIHB1Ymxpc2hlZCwg YW5kIEkgcGVyc29uYWxseSBkbyBub3Qga25vdyBpZjxiciBjbGFzcz0iIj4NCnNhbWUtb3JpZ2lu IGlzIHN0aWxsIGluIGdlbmVyYWwgdXNlIG9yIHdoZXRoZXIgdGhlcmUgYXJlIG90aGVyIG5ld2Vy IGJ1dDxiciBjbGFzcz0iIj4NCnNpbWlsYXIgaXNzdWVzIG9mIHdoaWNoIGFuIGltcGxlbWVudG9y IHNob3VsZCBiZSBhd2FyZS4gQnV0IGlmIHRoZXJlIGFyZSwgdGhlbjxiciBjbGFzcz0iIj4NCnRo aXMgc2VjdGlvbiBzaG91bGQgbm90ZSB0aGVtLiBPdGhlcndpc2UsIEkgY29uc2lkZXIgdGhlIGRv Y3VtZW50IHJlYWR5IHRvIGJlPGJyIGNsYXNzPSIiPg0KcHVibGlzaGVkLjxiciBjbGFzcz0iIj4N CjxiciBjbGFzcz0iIj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyIGNsYXNzPSIiPg0KdjZvcHMgbWFpbGluZyBsaXN0PGJyIGNsYXNzPSIiPg0KPGEg aHJlZj0ibWFpbHRvOnY2b3BzQGlldGYub3JnIiBjbGFzcz0iIj52Nm9wc0BpZXRmLm9yZzwvYT48 YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3Y2b3BzIiBjbGFzcz0iIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3Y2b3BzPC9hPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4tLSZuYnNwOzxiciBjbGFz cz0iIj4NCkJyaWFuIFdlaXM8YnIgY2xhc3M9IiI+DQpTZWN1cml0eSwgQ1NHLCBDaXNjbyBTeXN0 ZW1zPGJyIGNsYXNzPSIiPg0KVGVsZXBob25lOiAmIzQzOzEgNDA4IDUyNiA0Nzk2PGJyIGNsYXNz PSIiPg0KRW1haWw6IDxhIGhyZWY9Im1haWx0bzpiZXdAY2lzY28uY29tIiBjbGFzcz0iIj5iZXdA Y2lzY28uY29tPC9hPiA8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_642F64175C014F95A0B0BEBA7A475D58ciscocom_-- From nobody Fri Oct 20 18:37:13 2017 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 C64D1134184 for ; Fri, 20 Oct 2017 18:37:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 gZyk-R3bFAv2 for ; Fri, 20 Oct 2017 18:37:08 -0700 (PDT) Received: from market.scs.stanford.edu (www.scs.stanford.edu [IPv6:2001:470:806d:1::9]) (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 56D631320DC for ; Fri, 20 Oct 2017 18:37:08 -0700 (PDT) Received: from market.scs.stanford.edu (localhost [127.0.0.1]) by market.scs.stanford.edu (8.15.2/8.15.2) with ESMTP id v9L1b3ne062721; Fri, 20 Oct 2017 18:37:03 -0700 (PDT) Received: (from dbg@localhost) by market.scs.stanford.edu (8.15.2/8.15.2/Submit) id v9L1b2to095617; Fri, 20 Oct 2017 18:37:02 -0700 (PDT) Date: Fri, 20 Oct 2017 18:37:02 -0700 From: Daniel B Giffin To: Stephen Kent Cc: secdir@ietf.org, david.black@dell.com, krose@krose.org, ietf@kuehlewind.net, M.Handley@cs.ucl.ac.uk, dm@uun.org, eric.smith@kestrel.edu, sqs@sourcegraph.com Message-ID: <20171021013702.GB85636@scs.stanford.edu> References: 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 of draft-ietf-t cpinc-tcpcrypt-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Oct 2017 01:37:11 -0000 Hi Stephen, Thanks very much for your detailed review! So that others can see how your notes will be incorporated into the next draft, I'll respond to them below. (Where I take an interactive tone below, I don't mean that you need to respond. Although more discussion is welcome, I will go ahead with the changes I propose.) > 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. > > This document is the specification for tcpcrypt, which is targeted to be an > Experimental RFC. It is generally very well written, but it could benefit > from a few edits, as noted below. > > The introduction (section 2) is brief and well written, stating the goals > for the design. > > Section 3 is much longer, providing a detailed description of the protocol. > (Although the description is characterized as “abstract” it is very > detailed, with only format details deferred to Section 4.) This section also > is generally well-written. > > In 3.2 I suggest including a forward pointer to the IANA Considerations > section, since that section describes how future TEPs may be added to the > list in Table 2. Well, although this document provides (in the IANA Considerations section) a policy for assignment of identifiers to the "tcpcrypt AEAD Algorithm" registry", the policy for assignment of TEP identifiers lives in TCP-ENO. How about changing the last sentence of the first paragraph of 3.2 from: Future standards may associate additional identifiers with tcpcrypt. to instead: Future standards may associate additional TEP identifiers with tcpcrypt, following the assignment policy specified by TCP-ENO. > > In 3.5 the text says: > > When two hosts have previously negotiated a tcpcrypt session, > > either host may initiate session resumption regardless of which > > host was the active opener or played the "A" role in the > > previous session. > > It’s not clear to me in what time frame this comment is meant to apply, > e.g., if two hosts established a tcpcrypt session a week ago, is this > comment still supposed to be applicable? Some clarification here would be > useful. The end of this section establishes a requirement for an interface > to enable an application to control session caching. Are interfaces of this > sort commonly provided to applications by an OS? If so, an example would be > useful; if not, the authors should acknowledge that this requirement may be > problematic, i.e., applications may require modification to make use of the > mandated interface. Regarding the timeframe for resumption: I see how our language is confusing. I'll replace the first sentence of the first paragraph of this section with: If two hosts have previously negotiated a tcpcrypt session secret "ss[i-1]", and have cached the derived session secret "ss[i]", they may later establish a new connection without public-key operations using "ss[i]". ... and then also replace the paragraph you mention with: If two hosts have previously negotiated a tcpcrypt session, either host may later initiate session resumption regardless of which host was the active opener or played the "A" role in the previous session. These changes are subtle, but I hope they better convey (together with the rest of the section) that resumption with a particular session secret may be performed once, at any time later, provided that both hosts have cached the secret. Regarding interfaces: Although applications can benefit from tcpcrypt without knowledge of it (and thus without having to configure it), this document nevertheless requires implementations of tcpcrypt to provide an interface for configuring some aspects of its operation; this permits tcpcrypt-aware applications the control they need to build even-more-secure arrangements. The working group has an Informational draft suggesting how best to extend OS interfaces to include the configuration of TCP-ENO and tcpcrypt, using mechanisms (socket options and sysctls) present in most popular operating systems: https://datatracker.ietf.org/doc/draft-ietf-tcpinc-api/ I can see that reading the tcpcrypt document alone leaves questions about how to meet the API requirements; but of course we aren't in a position to cite the not-yet-published API draft. I don't know enough about how related RFCs could be brought to the attention of readers, so suggestions to address this are welcome. > > In 3.6 the mention Table 3 also should refer to IANA Considerations, since > that section describes how additions algorithms may be added. Thanks, I'm changing the relevant paragraph to read: This protection is provided via algorithms for Authenticated Encryption with Associated Data (AEAD). The particular algorithms that may be used are listed in Table 3, and additional algorithms may be specified according to the policy in Section 7. One algorithm is selected during the negotiation described in Section 3.3. > > The last sentence of 3.7 should be broken into several sentences; it is > currently 7 lines long! Ha, indeed ... done! > > Section 3.8 describes a fairly complicated set of constraintsassociated with > rekeying, some of which are inter-related. It might help to have a table > here to describe how these constraints interact, e.g., when TCP-mandated > retransmission takes place in the context of a rekey. Certainly that is a delicate section. Although I can't quite picture the table you're suggesting, I have reworked the paragraph mentioning TCP retransmission as follows: Note that when parts of the datastream are retransmitted, TCP requires that implementations always send the same data bytes for the same TCP sequence numbers. Thus, frame data in retransmitted segments must be encrypted with the same key as when it was first transmitted, regardless of the current local generation number. I'm hoping that makes it more clear that retransmission and rekeying shouldn't really interact at all: this paragraph doesn't impose any new constraints, and I've changed to a lower-case "must" to avoid the appearance of one. It is merely a note to help implementations avoid offending TCP. > > I suggest the following editorial changes in section 3: > > … assigns different roles to -> … assigns the roles to the two hosts > > … ephemeral public keys for hosts A and B -> … ephemeral public key > agreement keys for hosts A and B > > … whose length depends -> … the length of which depends > > … whose integer value -> … the integer value of which > > … security of the AEAD algorithm -> … security of every AEAD algorithm Great, I've mostly incorporated these suggestions. Although I understand it might not sound quite right to every ear, I couldn't bring myself to abandon those applications of "whose" to inanimate objects. I mean hey, two less words than "the _ of which"! And although I don't want to argue by authority or precedent, these literary examples sound elegant and clear to me: https://english.stackexchange.com/questions/23541/can-whose-refer-to-an-inanimate-object And as for nonce-reuse in AEAD algorithms, I guess we shouldn't say it is strictly verboten for *every* algorithm, as there are new "nonce-misuse resistant" algs coming down the pipe. So I've gone with: "Because it is strictly necessary for the security of the AEAD algorithms specified in this document, ..." > > Section 4 describes the byte-level encoding for the data structures > described in Section 3, as part of the tcpcrypt specification. In 4.1 found > the description of the “ignored” data the INIT1_ and INIT2_ messages to be a > bit confusing. I had to reread the descriptions to figure out that this was > the authors’ way of saying that data beyond the end of the message (as > indicated by the message_len field) is to be ignored upon reception. I don’t > think the graphics used here are a great way to explain this. Yes ... I'll try to find a better way. > > Section 6 defines the initial set of AEAD algorithms supported by tcpcrypt, > in Table 2. Each algorithm is assigned a value in the 1-255 range, a much > smaller range of values that used in protocols like TLS. The text in Section > 7 might need to remind readers that this will argue against the registration > of “vanity” AEAD algorithms for tcpcrypt. Hm yes, I see that TLS 1.3 uses a two-byte identifier for a similar purpose, although it looks like this specifies both an AEAD algorithm and an HKDF. Well, although the code-space used by tcpcrypt is small, TCP-ENO is a big escape-hatch in terms of extensibility. For example, tcpcrypt could be extended with additional TEPs whose only difference is to map the symmetric-cipher identifier-bytes to different meanings. Not the prettiest solution, but perhaps acceptable if one is optimistic that exhaustion is unlikely anyway? > > Security Considerations are described in Section 8. I found the phrase “Most > implementations will rely on system-wide pseudo-random generators…” to be a > bit confusing, because the ambiguity of the word “system” here. I presume > this really refers to a single device in mots cases, e.g., a laptop, > desktop, smartphone, right? I suggest a reference to RFC 4086 might be a > good substitute for much of the text at the beginning of this section. Right. I'll clarify that, and also consider invoking RFC 4086 to replace the details of the first three paragraphs. > > I’d like the authors to provide a rationale for the advice: “…limit the > lifetime of the private parameters, ideally to no more than two minutes.” > This seems a bit arbitrary to me. Indeed. I've reworked that paragraph as follows: Tcpcrypt uses short-lived public keys to provide forward secrecy. That is, once an implementation removes these keys from memory, a compromise of the system will not provide any means to derive the session keys for past connections. All currently specified key agreement schemes involve ECDHE-based key agreement, meaning a new keypair can be efficiently computed for each connection. If implementations reuse these parameters, they SHOULD limit the lifetime of the private parameters as far as practical in order to minimize the number of past connections that are vulnerable. > > Suggested editorial changes to Section 8: > > … is one on which -> is one for which > > … without guessing the content of the resumption identifier, -> without > successfully guessing the value of the resumption identifier, > > Thus, tcpcrypt specifies a way … -> To counter this threat, tcpcrypt > specifies a way … > Great, I've adopted the first and third suggestions. Thanks again for your very thoughtful review! I think this has significantly improved the draft in quite a few ways. daniel From nobody Sat Oct 21 10:18:18 2017 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 D0F4A126E64 for ; Sat, 21 Oct 2017 10:18:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.821 X-Spam-Level: X-Spam-Status: No, score=-0.821 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com header.b=kksDjdSQ; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=t0h7Kq4/ 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 luf76y-tnfAR for ; Sat, 21 Oct 2017 10:18:13 -0700 (PDT) Received: from esa4.dell-outbound.iphmx.com (esa4.dell-outbound.iphmx.com [68.232.149.214]) (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 372111241F3 for ; Sat, 21 Oct 2017 10:18:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1508606293; x=1540142293; h=from:cc:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=Uur7eHBo4sRqKuCTexbhJozIrTxM6l1wLwjtPFrDcUA=; b=kksDjdSQogEzZh/mWl4pbR2mi1bspjOQvuZKFhxPAfL/5F3KtwOtPxHy NYbMmlyywN1T38oZW8NzYOZSZYUZh5ndJ/T6AixzE6L82VijNoreY6Unb LBn/3VdfFmSKUkEjgFynfYFRDRPJ1ChCQYPpAF5zYibIOPiuDCjw9ep3D o=; Received: from esa4.dell-outbound2.iphmx.com ([68.232.154.98]) by esa4.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Oct 2017 12:18:11 -0500 From: "Black, David" Cc: "secdir@ietf.org" , "krose@krose.org" , "ietf@kuehlewind.net" , "M.Handley@cs.ucl.ac.uk" , "dm@uun.org" , "eric.smith@kestrel.edu" , "sqs@sourcegraph.com" , "Black, David" Received: from mailuogwdur.emc.com ([128.221.224.79]) by esa4.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Oct 2017 23:18:10 +0600 Received: from maildlpprd53.lss.emc.com (maildlpprd53.lss.emc.com [10.106.48.157]) by mailuogwprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v9LHI7hg023033 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 21 Oct 2017 13:18:08 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com v9LHI7hg023033 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1508606290; bh=1+OS/f5pChASKihGJOWTjkejcTM=; h=From:To:CC:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=t0h7Kq4/XNqbfzs0+hj7NrnibOreNfRTJpRu0REAh3F/0ABGMZplAjxbQ6Adm87Ve yF2c+ROtoNdIQumPj+mQSvwVHlZp/SvSOgE36MDBvBCHMnFPeu1VdBQNc5jEFICOgb iKioHXq4ESgpwCNEZfTlC1J/Yf2VZHIw6yXS1ewA= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com v9LHI7hg023033 Received: from mailusrhubprd02.lss.emc.com (mailusrhubprd02.lss.emc.com [10.253.24.20]) by maildlpprd53.lss.emc.com (RSA Interceptor); Sat, 21 Oct 2017 13:17:46 -0400 Received: from MXHUB306.corp.emc.com (MXHUB306.corp.emc.com [10.146.3.32]) by mailusrhubprd02.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v9LHHtOR017069 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Sat, 21 Oct 2017 13:17:55 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB306.corp.emc.com ([10.146.3.32]) with mapi id 14.03.0352.000; Sat, 21 Oct 2017 13:17:54 -0400 To: Daniel B Giffin , Stephen Kent Thread-Topic: SECDIR review of draft-ietf-tcpinc-tcpcrypt-07 Thread-Index: AdNKkIZnLjxOcXUhQbGBU5YCP/B/qw== Date: Sat, 21 Oct 2017 17:17:54 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.97.27.122] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd02.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: Re: [secdir] SECDIR review of draft-ietf-tcpinc-tcpcrypt-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Oct 2017 17:18:16 -0000 UXVpY2sgZm9sbG93LXVwIG9uIHRoaXMgaXRlbToNCg0KPiBSZWdhcmRpbmcgaW50ZXJmYWNlczog QWx0aG91Z2ggYXBwbGljYXRpb25zIGNhbiBiZW5lZml0IGZyb20NCj4gdGNwY3J5cHQgd2l0aG91 dCBrbm93bGVkZ2Ugb2YgaXQgKGFuZCB0aHVzIHdpdGhvdXQgaGF2aW5nIHRvDQo+IGNvbmZpZ3Vy ZSBpdCksIHRoaXMgZG9jdW1lbnQgbmV2ZXJ0aGVsZXNzIHJlcXVpcmVzDQo+IGltcGxlbWVudGF0 aW9ucyBvZiB0Y3BjcnlwdCB0byBwcm92aWRlIGFuIGludGVyZmFjZSBmb3INCj4gY29uZmlndXJp bmcgc29tZSBhc3BlY3RzIG9mIGl0cyBvcGVyYXRpb247IHRoaXMgcGVybWl0cw0KPiB0Y3Bjcnlw dC1hd2FyZSBhcHBsaWNhdGlvbnMgdGhlIGNvbnRyb2wgdGhleSBuZWVkIHRvIGJ1aWxkDQo+IGV2 ZW4tbW9yZS1zZWN1cmUgYXJyYW5nZW1lbnRzLg0KPiANCj4gVGhlIHdvcmtpbmcgZ3JvdXAgaGFz IGFuIEluZm9ybWF0aW9uYWwgZHJhZnQgc3VnZ2VzdGluZyBob3cNCj4gYmVzdCB0byBleHRlbmQg T1MgaW50ZXJmYWNlcyB0byBpbmNsdWRlIHRoZSBjb25maWd1cmF0aW9uIG9mDQo+IFRDUC1FTk8g YW5kIHRjcGNyeXB0LCB1c2luZyBtZWNoYW5pc21zIChzb2NrZXQgb3B0aW9ucyBhbmQNCj4gc3lz Y3RscykgcHJlc2VudCBpbiBtb3N0IHBvcHVsYXIgb3BlcmF0aW5nIHN5c3RlbXM6DQo+IA0KPiAg IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdGNwaW5jLWFwaS8N Cj4gDQo+IEkgY2FuIHNlZSB0aGF0IHJlYWRpbmcgdGhlIHRjcGNyeXB0IGRvY3VtZW50IGFsb25l IGxlYXZlcw0KPiBxdWVzdGlvbnMgYWJvdXQgaG93IHRvIG1lZXQgdGhlIEFQSSByZXF1aXJlbWVu dHM7IGJ1dCBvZg0KPiBjb3Vyc2Ugd2UgYXJlbid0IGluIGEgcG9zaXRpb24gdG8gY2l0ZSB0aGUg bm90LXlldC1wdWJsaXNoZWQNCj4gQVBJIGRyYWZ0LiAgSSBkb24ndCBrbm93IGVub3VnaCBhYm91 dCBob3cgcmVsYXRlZCBSRkNzIGNvdWxkDQo+IGJlIGJyb3VnaHQgdG8gdGhlIGF0dGVudGlvbiBv ZiByZWFkZXJzLCBzbyBzdWdnZXN0aW9ucyB0bw0KPiBhZGRyZXNzIHRoaXMgYXJlIHdlbGNvbWUu DQoNCkl0J3MgZmluZSB0byBjaXRlIHRoYXQgZHJhZnQgYXMgYW4gaW5mb3JtYXRpdmUgcmVmZXJl bmNlIC0gdGhlIHJlc3VsdGluZyByZWZlcmVuY2UgaW4gdGhlIHRjcGNyeXB0IFJGQyB3aWxsIChj b3JyZWN0bHkpIGluZGljYXRlIHRoYXQgdGhlIEFQSSBpcyB3b3JrIGluIHByb2dyZXNzLiAgIEFk ZGluZyB0aGF0IHJlZmVyZW5jZSB3b3VsZCBiZSBhIGdvb2QgdGhpbmcgdG8gZG8uDQoNCk9UT0gs IHRoYXQgZHJhZnQgc2hvdWxkIG5vdCBiZSBjaXRlZCBhcyBhIG5vcm1hdGl2ZSByZWZlcmVuY2Us IGZvciByZWFzb25zIHRoYXQgaW5jbHVkZSB0aGUgaW5hcHByb3ByaWF0ZW5lc3Mgb2YgbWFuZGF0 aW5nIHRoYXQgQVBJIGZvciBhbGwgaW1wbGVtZW50YXRpb25zLg0KDQpUaGFua3MsIC0tRGF2aWQN Cg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBEYW5pZWwgQiBHaWZmaW4g W21haWx0bzpkYmdAc2NzLnN0YW5mb3JkLmVkdV0NCj4gU2VudDogRnJpZGF5LCBPY3RvYmVyIDIw LCAyMDE3IDk6MzcgUE0NCj4gVG86IFN0ZXBoZW4gS2VudCA8c3RrZW50QHZlcml6b24ubmV0Pg0K PiBDYzogc2VjZGlyQGlldGYub3JnOyBCbGFjaywgRGF2aWQgPGRhdmlkLmJsYWNrQGVtYy5jb20+ OyBrcm9zZUBrcm9zZS5vcmc7DQo+IGlldGZAa3VlaGxld2luZC5uZXQ7IE0uSGFuZGxleUBjcy51 Y2wuYWMudWs7IGRtQHV1bi5vcmc7DQo+IGVyaWMuc21pdGhAa2VzdHJlbC5lZHU7IHNxc0Bzb3Vy Y2VncmFwaC5jb20NCj4gU3ViamVjdDogUmU6IFNFQ0RJUiByZXZpZXcgb2YgZHJhZnQtaWV0Zi10 IGNwaW5jLXRjcGNyeXB0LTA3DQo+IA0KPiBIaSBTdGVwaGVuLA0KPiANCj4gVGhhbmtzIHZlcnkg bXVjaCBmb3IgeW91ciBkZXRhaWxlZCByZXZpZXchDQo+IA0KPiBTbyB0aGF0IG90aGVycyBjYW4g c2VlIGhvdyB5b3VyIG5vdGVzIHdpbGwgYmUgaW5jb3Jwb3JhdGVkDQo+IGludG8gdGhlIG5leHQg ZHJhZnQsIEknbGwgcmVzcG9uZCB0byB0aGVtIGJlbG93Lg0KPiANCj4gKFdoZXJlIEkgdGFrZSBh biBpbnRlcmFjdGl2ZSB0b25lIGJlbG93LCBJIGRvbid0IG1lYW4gdGhhdA0KPiB5b3UgbmVlZCB0 byByZXNwb25kLiAgQWx0aG91Z2ggbW9yZSBkaXNjdXNzaW9uIGlzIHdlbGNvbWUsIEkNCj4gd2ls bCBnbyBhaGVhZCB3aXRoIHRoZSBjaGFuZ2VzIEkgcHJvcG9zZS4pDQo+IA0KPiA+IEkgaGF2ZSBy ZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlIHNlY3VyaXR5IGRpcmVjdG9yYXRl J3Mgb25nb2luZw0KPiA+IGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5n IHByb2Nlc3NlZCBieSB0aGUgSUVTRy5UaGVzZQ0KPiA+IGNvbW1lbnRzIHdlcmUgd3JpdHRlbiB3 aXRoIHRoZSBpbnRlbnQgb2YgaW1wcm92aW5nIHNlY3VyaXR5DQo+IHJlcXVpcmVtZW50cyBhbmQN Cj4gPiBjb25zaWRlcmF0aW9ucyBpbiBJRVRGIGRyYWZ0cy5Db21tZW50cyBub3QgYWRkcmVzc2Vk IGluIGxhc3QgY2FsbCBtYXkgYmUNCj4gPiBpbmNsdWRlZCBpbiBBRCByZXZpZXdzIGR1cmluZyB0 aGUgSUVTRyByZXZpZXcuRG9jdW1lbnQgZWRpdG9ycyBhbmQgV0cNCj4gY2hhaXJzDQo+ID4gc2hv dWxkIHRyZWF0IHRoZXNlIGNvbW1lbnRzIGp1c3QgbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNv bW1lbnRzLg0KPiA+DQo+ID4gVGhpcyBkb2N1bWVudCBpcyB0aGUgc3BlY2lmaWNhdGlvbiBmb3Ig dGNwY3J5cHQsIHdoaWNoIGlzIHRhcmdldGVkIHRvIGJlIGFuDQo+ID4gRXhwZXJpbWVudGFsIFJG Qy4gSXQgaXMgZ2VuZXJhbGx5IHZlcnkgd2VsbCB3cml0dGVuLCBidXQgaXQgY291bGQgYmVuZWZp dA0KPiA+IGZyb20gYSBmZXcgZWRpdHMsIGFzIG5vdGVkIGJlbG93Lg0KPiA+DQo+ID4gVGhlIGlu dHJvZHVjdGlvbiAoc2VjdGlvbiAyKSBpcyBicmllZiBhbmQgd2VsbCB3cml0dGVuLCBzdGF0aW5n IHRoZSBnb2Fscw0KPiA+IGZvciB0aGUgZGVzaWduLg0KPiA+DQo+ID4gU2VjdGlvbiAzIGlzIG11 Y2ggbG9uZ2VyLCBwcm92aWRpbmcgYSBkZXRhaWxlZCBkZXNjcmlwdGlvbiBvZiB0aGUgcHJvdG9j b2wuDQo+ID4gKEFsdGhvdWdoIHRoZSBkZXNjcmlwdGlvbiBpcyBjaGFyYWN0ZXJpemVkIGFzIOKA nGFic3RyYWN04oCdIGl0IGlzIHZlcnkNCj4gPiBkZXRhaWxlZCwgd2l0aCBvbmx5IGZvcm1hdCBk ZXRhaWxzIGRlZmVycmVkIHRvIFNlY3Rpb24gNC4pIFRoaXMgc2VjdGlvbiBhbHNvDQo+ID4gaXMg Z2VuZXJhbGx5IHdlbGwtd3JpdHRlbi4NCj4gPg0KPiA+IEluIDMuMiBJIHN1Z2dlc3QgaW5jbHVk aW5nIGEgZm9yd2FyZCBwb2ludGVyIHRvIHRoZSBJQU5BIENvbnNpZGVyYXRpb25zDQo+ID4gc2Vj dGlvbiwgc2luY2UgdGhhdCBzZWN0aW9uIGRlc2NyaWJlcyBob3cgZnV0dXJlIFRFUHMgbWF5IGJl IGFkZGVkIHRvIHRoZQ0KPiA+IGxpc3QgaW4gVGFibGUgMi4NCj4gDQo+IFdlbGwsIGFsdGhvdWdo IHRoaXMgZG9jdW1lbnQgcHJvdmlkZXMgKGluIHRoZSBJQU5BDQo+IENvbnNpZGVyYXRpb25zIHNl Y3Rpb24pIGEgcG9saWN5IGZvciBhc3NpZ25tZW50IG9mDQo+IGlkZW50aWZpZXJzIHRvIHRoZSAi dGNwY3J5cHQgQUVBRCBBbGdvcml0aG0iIHJlZ2lzdHJ5IiwgdGhlDQo+IHBvbGljeSBmb3IgYXNz aWdubWVudCBvZiBURVAgaWRlbnRpZmllcnMgbGl2ZXMgaW4gVENQLUVOTy4NCj4gDQo+IEhvdyBh Ym91dCBjaGFuZ2luZyB0aGUgbGFzdCBzZW50ZW5jZSBvZiB0aGUgZmlyc3QgcGFyYWdyYXBoDQo+ IG9mIDMuMiBmcm9tOg0KPiANCj4gICBGdXR1cmUgc3RhbmRhcmRzIG1heSBhc3NvY2lhdGUgYWRk aXRpb25hbCBpZGVudGlmaWVycyB3aXRoDQo+ICAgdGNwY3J5cHQuDQo+IA0KPiB0byBpbnN0ZWFk Og0KPiANCj4gICBGdXR1cmUgc3RhbmRhcmRzIG1heSBhc3NvY2lhdGUgYWRkaXRpb25hbCBURVAg aWRlbnRpZmllcnMNCj4gICB3aXRoIHRjcGNyeXB0LCBmb2xsb3dpbmcgdGhlIGFzc2lnbm1lbnQg cG9saWN5IHNwZWNpZmllZA0KPiAgIGJ5IFRDUC1FTk8uDQo+IA0KPiA+DQo+ID4gSW4gMy41IHRo ZSB0ZXh0IHNheXM6DQo+ID4NCj4gPiBXaGVuIHR3byBob3N0cyBoYXZlIHByZXZpb3VzbHkgbmVn b3RpYXRlZCBhIHRjcGNyeXB0IHNlc3Npb24sDQo+ID4NCj4gPiBlaXRoZXIgaG9zdCBtYXkgaW5p dGlhdGUgc2Vzc2lvbiByZXN1bXB0aW9uIHJlZ2FyZGxlc3Mgb2Ygd2hpY2gNCj4gPg0KPiA+IGhv c3Qgd2FzIHRoZSBhY3RpdmUgb3BlbmVyIG9yIHBsYXllZCB0aGUgIkEiIHJvbGUgaW4gdGhlDQo+ ID4NCj4gPiBwcmV2aW91cyBzZXNzaW9uLg0KPiA+DQo+ID4gSXTigJlzIG5vdCBjbGVhciB0byBt ZSBpbiB3aGF0IHRpbWUgZnJhbWUgdGhpcyBjb21tZW50IGlzIG1lYW50IHRvIGFwcGx5LA0KPiA+ IGUuZy4sIGlmIHR3byBob3N0cyBlc3RhYmxpc2hlZCBhIHRjcGNyeXB0IHNlc3Npb24gYSB3ZWVr IGFnbywgaXMgdGhpcw0KPiA+IGNvbW1lbnQgc3RpbGwgc3VwcG9zZWQgdG8gYmUgYXBwbGljYWJs ZT8gU29tZSBjbGFyaWZpY2F0aW9uIGhlcmUgd291bGQgYmUNCj4gPiB1c2VmdWwuIFRoZSBlbmQg b2YgdGhpcyBzZWN0aW9uIGVzdGFibGlzaGVzIGEgcmVxdWlyZW1lbnQgZm9yIGFuIGludGVyZmFj ZQ0KPiA+IHRvIGVuYWJsZSBhbiBhcHBsaWNhdGlvbiB0byBjb250cm9sIHNlc3Npb24gY2FjaGlu Zy4gQXJlIGludGVyZmFjZXMgb2YgdGhpcw0KPiA+IHNvcnQgY29tbW9ubHkgcHJvdmlkZWQgdG8g YXBwbGljYXRpb25zIGJ5IGFuIE9TPyBJZiBzbywgYW4gZXhhbXBsZSB3b3VsZA0KPiBiZQ0KPiA+ IHVzZWZ1bDsgaWYgbm90LCB0aGUgYXV0aG9ycyBzaG91bGQgYWNrbm93bGVkZ2UgdGhhdCB0aGlz IHJlcXVpcmVtZW50IG1heQ0KPiBiZQ0KPiA+IHByb2JsZW1hdGljLCBpLmUuLCBhcHBsaWNhdGlv bnMgbWF5IHJlcXVpcmUgbW9kaWZpY2F0aW9uIHRvIG1ha2UgdXNlIG9mIHRoZQ0KPiA+IG1hbmRh dGVkIGludGVyZmFjZS4NCj4gDQo+IFJlZ2FyZGluZyB0aGUgdGltZWZyYW1lIGZvciByZXN1bXB0 aW9uOiBJIHNlZSBob3cgb3VyDQo+IGxhbmd1YWdlIGlzIGNvbmZ1c2luZy4gIEknbGwgcmVwbGFj ZSB0aGUgZmlyc3Qgc2VudGVuY2Ugb2YNCj4gdGhlIGZpcnN0IHBhcmFncmFwaCBvZiB0aGlzIHNl Y3Rpb24gd2l0aDoNCj4gDQo+ICAgIElmIHR3byBob3N0cyBoYXZlIHByZXZpb3VzbHkgbmVnb3Rp YXRlZCBhIHRjcGNyeXB0IHNlc3Npb24gc2VjcmV0DQo+ICAgICJzc1tpLTFdIiwgYW5kIGhhdmUg Y2FjaGVkIHRoZSBkZXJpdmVkIHNlc3Npb24gc2VjcmV0ICJzc1tpXSIsIHRoZXkNCj4gICAgbWF5 IGxhdGVyIGVzdGFibGlzaCBhIG5ldyBjb25uZWN0aW9uIHdpdGhvdXQgcHVibGljLWtleSBvcGVy YXRpb25zDQo+ICAgIHVzaW5nICJzc1tpXSIuDQo+IA0KPiAuLi4gYW5kIHRoZW4gYWxzbyByZXBs YWNlIHRoZSBwYXJhZ3JhcGggeW91IG1lbnRpb24gd2l0aDoNCj4gDQo+ICAgIElmIHR3byBob3N0 cyBoYXZlIHByZXZpb3VzbHkgbmVnb3RpYXRlZCBhIHRjcGNyeXB0IHNlc3Npb24sIGVpdGhlcg0K PiAgICBob3N0IG1heSBsYXRlciBpbml0aWF0ZSBzZXNzaW9uIHJlc3VtcHRpb24gcmVnYXJkbGVz cyBvZiB3aGljaCBob3N0DQo+ICAgIHdhcyB0aGUgYWN0aXZlIG9wZW5lciBvciBwbGF5ZWQgdGhl ICJBIiByb2xlIGluIHRoZSBwcmV2aW91cyBzZXNzaW9uLg0KPiANCj4gVGhlc2UgY2hhbmdlcyBh cmUgc3VidGxlLCBidXQgSSBob3BlIHRoZXkgYmV0dGVyIGNvbnZleQ0KPiAodG9nZXRoZXIgd2l0 aCB0aGUgcmVzdCBvZiB0aGUgc2VjdGlvbikgdGhhdCByZXN1bXB0aW9uIHdpdGgNCj4gYSBwYXJ0 aWN1bGFyIHNlc3Npb24gc2VjcmV0IG1heSBiZSBwZXJmb3JtZWQgb25jZSwgYXQgYW55DQo+IHRp bWUgbGF0ZXIsIHByb3ZpZGVkIHRoYXQgYm90aCBob3N0cyBoYXZlIGNhY2hlZCB0aGUgc2VjcmV0 Lg0KPiANCj4gUmVnYXJkaW5nIGludGVyZmFjZXM6IEFsdGhvdWdoIGFwcGxpY2F0aW9ucyBjYW4g YmVuZWZpdCBmcm9tDQo+IHRjcGNyeXB0IHdpdGhvdXQga25vd2xlZGdlIG9mIGl0IChhbmQgdGh1 cyB3aXRob3V0IGhhdmluZyB0bw0KPiBjb25maWd1cmUgaXQpLCB0aGlzIGRvY3VtZW50IG5ldmVy dGhlbGVzcyByZXF1aXJlcw0KPiBpbXBsZW1lbnRhdGlvbnMgb2YgdGNwY3J5cHQgdG8gcHJvdmlk ZSBhbiBpbnRlcmZhY2UgZm9yDQo+IGNvbmZpZ3VyaW5nIHNvbWUgYXNwZWN0cyBvZiBpdHMgb3Bl cmF0aW9uOyB0aGlzIHBlcm1pdHMNCj4gdGNwY3J5cHQtYXdhcmUgYXBwbGljYXRpb25zIHRoZSBj b250cm9sIHRoZXkgbmVlZCB0byBidWlsZA0KPiBldmVuLW1vcmUtc2VjdXJlIGFycmFuZ2VtZW50 cy4NCj4gDQo+IFRoZSB3b3JraW5nIGdyb3VwIGhhcyBhbiBJbmZvcm1hdGlvbmFsIGRyYWZ0IHN1 Z2dlc3RpbmcgaG93DQo+IGJlc3QgdG8gZXh0ZW5kIE9TIGludGVyZmFjZXMgdG8gaW5jbHVkZSB0 aGUgY29uZmlndXJhdGlvbiBvZg0KPiBUQ1AtRU5PIGFuZCB0Y3BjcnlwdCwgdXNpbmcgbWVjaGFu aXNtcyAoc29ja2V0IG9wdGlvbnMgYW5kDQo+IHN5c2N0bHMpIHByZXNlbnQgaW4gbW9zdCBwb3B1 bGFyIG9wZXJhdGluZyBzeXN0ZW1zOg0KPiANCj4gICBodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1pZXRmLXRjcGluYy1hcGkvDQo+IA0KPiBJIGNhbiBzZWUgdGhhdCByZWFk aW5nIHRoZSB0Y3BjcnlwdCBkb2N1bWVudCBhbG9uZSBsZWF2ZXMNCj4gcXVlc3Rpb25zIGFib3V0 IGhvdyB0byBtZWV0IHRoZSBBUEkgcmVxdWlyZW1lbnRzOyBidXQgb2YNCj4gY291cnNlIHdlIGFy ZW4ndCBpbiBhIHBvc2l0aW9uIHRvIGNpdGUgdGhlIG5vdC15ZXQtcHVibGlzaGVkDQo+IEFQSSBk cmFmdC4gIEkgZG9uJ3Qga25vdyBlbm91Z2ggYWJvdXQgaG93IHJlbGF0ZWQgUkZDcyBjb3VsZA0K PiBiZSBicm91Z2h0IHRvIHRoZSBhdHRlbnRpb24gb2YgcmVhZGVycywgc28gc3VnZ2VzdGlvbnMg dG8NCj4gYWRkcmVzcyB0aGlzIGFyZSB3ZWxjb21lLg0KPiANCj4gPg0KPiA+IEluIDMuNiB0aGUg bWVudGlvbiBUYWJsZSAzIGFsc28gc2hvdWxkIHJlZmVyIHRvIElBTkEgQ29uc2lkZXJhdGlvbnMs IHNpbmNlDQo+ID4gdGhhdCBzZWN0aW9uIGRlc2NyaWJlcyBob3cgYWRkaXRpb25zIGFsZ29yaXRo bXMgbWF5IGJlIGFkZGVkLg0KPiANCj4gVGhhbmtzLCBJJ20gY2hhbmdpbmcgdGhlIHJlbGV2YW50 IHBhcmFncmFwaCB0byByZWFkOg0KPiANCj4gICAgVGhpcyBwcm90ZWN0aW9uIGlzIHByb3ZpZGVk IHZpYSBhbGdvcml0aG1zIGZvciBBdXRoZW50aWNhdGVkDQo+ICAgIEVuY3J5cHRpb24gd2l0aCBB c3NvY2lhdGVkIERhdGEgKEFFQUQpLiAgVGhlIHBhcnRpY3VsYXIgYWxnb3JpdGhtcw0KPiAgICB0 aGF0IG1heSBiZSB1c2VkIGFyZSBsaXN0ZWQgaW4gVGFibGUgMywgYW5kIGFkZGl0aW9uYWwgYWxn b3JpdGhtcyBtYXkNCj4gICAgYmUgc3BlY2lmaWVkIGFjY29yZGluZyB0byB0aGUgcG9saWN5IGlu IFNlY3Rpb24gNy4gIE9uZSBhbGdvcml0aG0gaXMNCj4gICAgc2VsZWN0ZWQgZHVyaW5nIHRoZSBu ZWdvdGlhdGlvbiBkZXNjcmliZWQgaW4gU2VjdGlvbiAzLjMuDQo+IA0KPiA+DQo+ID4gVGhlIGxh c3Qgc2VudGVuY2Ugb2YgMy43IHNob3VsZCBiZSBicm9rZW4gaW50byBzZXZlcmFsIHNlbnRlbmNl czsgaXQgaXMNCj4gPiBjdXJyZW50bHkgNyBsaW5lcyBsb25nIQ0KPiANCj4gSGEsIGluZGVlZCAu Li4gZG9uZSENCj4gDQo+ID4NCj4gPiBTZWN0aW9uIDMuOCBkZXNjcmliZXMgYSBmYWlybHkgY29t cGxpY2F0ZWQgc2V0IG9mIGNvbnN0cmFpbnRzYXNzb2NpYXRlZCB3aXRoDQo+ID4gcmVrZXlpbmcs IHNvbWUgb2Ygd2hpY2ggYXJlIGludGVyLXJlbGF0ZWQuIEl0IG1pZ2h0IGhlbHAgdG8gaGF2ZSBh IHRhYmxlDQo+ID4gaGVyZSB0byBkZXNjcmliZSBob3cgdGhlc2UgY29uc3RyYWludHMgaW50ZXJh Y3QsIGUuZy4sIHdoZW4gVENQLW1hbmRhdGVkDQo+ID4gcmV0cmFuc21pc3Npb24gdGFrZXMgcGxh Y2UgaW4gdGhlIGNvbnRleHQgb2YgYSByZWtleS4NCj4gDQo+IENlcnRhaW5seSB0aGF0IGlzIGEg ZGVsaWNhdGUgc2VjdGlvbi4gIEFsdGhvdWdoIEkgY2FuJ3QNCj4gcXVpdGUgcGljdHVyZSB0aGUg dGFibGUgeW91J3JlIHN1Z2dlc3RpbmcsIEkgaGF2ZSByZXdvcmtlZA0KPiB0aGUgcGFyYWdyYXBo IG1lbnRpb25pbmcgVENQIHJldHJhbnNtaXNzaW9uIGFzIGZvbGxvd3M6DQo+IA0KPiAgICBOb3Rl IHRoYXQgd2hlbiBwYXJ0cyBvZiB0aGUgZGF0YXN0cmVhbSBhcmUgcmV0cmFuc21pdHRlZCwgVENQ DQo+ICAgIHJlcXVpcmVzIHRoYXQgaW1wbGVtZW50YXRpb25zIGFsd2F5cyBzZW5kIHRoZSBzYW1l IGRhdGEgYnl0ZXMgZm9yIHRoZQ0KPiAgICBzYW1lIFRDUCBzZXF1ZW5jZSBudW1iZXJzLiAgVGh1 cywgZnJhbWUgZGF0YSBpbiByZXRyYW5zbWl0dGVkDQo+ICAgIHNlZ21lbnRzIG11c3QgYmUgZW5j cnlwdGVkIHdpdGggdGhlIHNhbWUga2V5IGFzIHdoZW4gaXQgd2FzIGZpcnN0DQo+ICAgIHRyYW5z bWl0dGVkLCByZWdhcmRsZXNzIG9mIHRoZSBjdXJyZW50IGxvY2FsIGdlbmVyYXRpb24gbnVtYmVy Lg0KPiANCj4gSSdtIGhvcGluZyB0aGF0IG1ha2VzIGl0IG1vcmUgY2xlYXIgdGhhdCByZXRyYW5z bWlzc2lvbiBhbmQNCj4gcmVrZXlpbmcgc2hvdWxkbid0IHJlYWxseSBpbnRlcmFjdCBhdCBhbGw6 IHRoaXMgcGFyYWdyYXBoDQo+IGRvZXNuJ3QgaW1wb3NlIGFueSBuZXcgY29uc3RyYWludHMsIGFu ZCBJJ3ZlIGNoYW5nZWQgdG8gYQ0KPiBsb3dlci1jYXNlICJtdXN0IiB0byBhdm9pZCB0aGUgYXBw ZWFyYW5jZSBvZiBvbmUuICBJdCBpcw0KPiBtZXJlbHkgYSBub3RlIHRvIGhlbHAgaW1wbGVtZW50 YXRpb25zIGF2b2lkIG9mZmVuZGluZyBUQ1AuDQo+IA0KPiA+DQo+ID4gSSBzdWdnZXN0IHRoZSBm b2xsb3dpbmcgZWRpdG9yaWFsIGNoYW5nZXMgaW4gc2VjdGlvbiAzOg0KPiA+DQo+ID4g4oCmIGFz c2lnbnMgZGlmZmVyZW50IHJvbGVzIHRvIC0+IOKApiBhc3NpZ25zIHRoZSByb2xlcyB0byB0aGUg dHdvIGhvc3RzDQo+ID4NCj4gPiDigKYgZXBoZW1lcmFsIHB1YmxpYyBrZXlzIGZvciBob3N0cyBB IGFuZCBCIC0+IOKApiBlcGhlbWVyYWwgcHVibGljIGtleQ0KPiA+IGFncmVlbWVudCBrZXlzIGZv ciBob3N0cyBBIGFuZCBCDQo+ID4NCj4gPiDigKYgd2hvc2UgbGVuZ3RoIGRlcGVuZHMgLT4g4oCm IHRoZSBsZW5ndGggb2Ygd2hpY2ggZGVwZW5kcw0KPiA+DQo+ID4g4oCmIHdob3NlIGludGVnZXIg dmFsdWUgLT4g4oCmIHRoZSBpbnRlZ2VyIHZhbHVlIG9mIHdoaWNoDQo+ID4NCj4gPiDigKYgc2Vj dXJpdHkgb2YgdGhlIEFFQUQgYWxnb3JpdGhtIC0+IOKApiBzZWN1cml0eSBvZiBldmVyeSBBRUFE IGFsZ29yaXRobQ0KPiANCj4gR3JlYXQsIEkndmUgbW9zdGx5IGluY29ycG9yYXRlZCB0aGVzZSBz dWdnZXN0aW9ucy4NCj4gDQo+IEFsdGhvdWdoIEkgdW5kZXJzdGFuZCBpdCBtaWdodCBub3Qgc291 bmQgcXVpdGUgcmlnaHQgdG8NCj4gZXZlcnkgZWFyLCBJIGNvdWxkbid0IGJyaW5nIG15c2VsZiB0 byBhYmFuZG9uIHRob3NlDQo+IGFwcGxpY2F0aW9ucyBvZiAid2hvc2UiIHRvIGluYW5pbWF0ZSBv YmplY3RzLiAgSSBtZWFuIGhleSwNCj4gdHdvIGxlc3Mgd29yZHMgdGhhbiAidGhlIF8gb2Ygd2hp Y2giISAgQW5kIGFsdGhvdWdoIEkgZG9uJ3QNCj4gd2FudCB0byBhcmd1ZSBieSBhdXRob3JpdHkg b3IgcHJlY2VkZW50LCB0aGVzZSBsaXRlcmFyeQ0KPiBleGFtcGxlcyBzb3VuZCBlbGVnYW50IGFu ZCBjbGVhciB0byBtZToNCj4gDQo+ICAgaHR0cHM6Ly9lbmdsaXNoLnN0YWNrZXhjaGFuZ2UuY29t L3F1ZXN0aW9ucy8yMzU0MS9jYW4td2hvc2UtcmVmZXItdG8tDQo+IGFuLWluYW5pbWF0ZS1vYmpl Y3QNCj4gDQo+IEFuZCBhcyBmb3Igbm9uY2UtcmV1c2UgaW4gQUVBRCBhbGdvcml0aG1zLCBJIGd1 ZXNzIHdlDQo+IHNob3VsZG4ndCBzYXkgaXQgaXMgc3RyaWN0bHkgdmVyYm90ZW4gZm9yICpldmVy eSogYWxnb3JpdGhtLA0KPiBhcyB0aGVyZSBhcmUgbmV3ICJub25jZS1taXN1c2UgcmVzaXN0YW50 IiBhbGdzIGNvbWluZyBkb3duDQo+IHRoZSBwaXBlLiAgU28gSSd2ZSBnb25lIHdpdGg6ICJCZWNh dXNlIGl0IGlzIHN0cmljdGx5DQo+IG5lY2Vzc2FyeSBmb3IgdGhlIHNlY3VyaXR5IG9mIHRoZSBB RUFEIGFsZ29yaXRobXMgc3BlY2lmaWVkDQo+IGluIHRoaXMgZG9jdW1lbnQsIC4uLiINCj4gDQo+ ID4NCj4gPiBTZWN0aW9uIDQgZGVzY3JpYmVzIHRoZSBieXRlLWxldmVsIGVuY29kaW5nIGZvciB0 aGUgZGF0YSBzdHJ1Y3R1cmVzDQo+ID4gZGVzY3JpYmVkIGluIFNlY3Rpb24gMywgYXMgcGFydCBv ZiB0aGUgdGNwY3J5cHQgc3BlY2lmaWNhdGlvbi4gSW4gNC4xIGZvdW5kDQo+ID4gdGhlIGRlc2Ny aXB0aW9uIG9mIHRoZSDigJxpZ25vcmVk4oCdIGRhdGEgdGhlIElOSVQxXyBhbmQgSU5JVDJfIG1l c3NhZ2VzIHRvIGJlDQo+IGENCj4gPiBiaXQgY29uZnVzaW5nLiBJIGhhZCB0byByZXJlYWQgdGhl IGRlc2NyaXB0aW9ucyB0byBmaWd1cmUgb3V0IHRoYXQgdGhpcyB3YXMNCj4gPiB0aGUgYXV0aG9y c+KAmSB3YXkgb2Ygc2F5aW5nIHRoYXQgZGF0YSBiZXlvbmQgdGhlIGVuZCBvZiB0aGUgbWVzc2Fn ZSAoYXMNCj4gPiBpbmRpY2F0ZWQgYnkgdGhlIG1lc3NhZ2VfbGVuIGZpZWxkKSBpcyB0byBiZSBp Z25vcmVkIHVwb24gcmVjZXB0aW9uLiBJIGRvbuKAmXQNCj4gPiB0aGluayB0aGUgZ3JhcGhpY3Mg dXNlZCBoZXJlIGFyZSBhIGdyZWF0IHdheSB0byBleHBsYWluIHRoaXMuDQo+IA0KPiBZZXMgLi4u IEknbGwgdHJ5IHRvIGZpbmQgYSBiZXR0ZXIgd2F5Lg0KPiANCj4gPg0KPiA+IFNlY3Rpb24gNiBk ZWZpbmVzIHRoZSBpbml0aWFsIHNldCBvZiBBRUFEIGFsZ29yaXRobXMgc3VwcG9ydGVkIGJ5IHRj cGNyeXB0LA0KPiA+IGluIFRhYmxlIDIuIEVhY2ggYWxnb3JpdGhtIGlzIGFzc2lnbmVkIGEgdmFs dWUgaW4gdGhlIDEtMjU1IHJhbmdlLCBhIG11Y2gNCj4gPiBzbWFsbGVyIHJhbmdlIG9mIHZhbHVl cyB0aGF0IHVzZWQgaW4gcHJvdG9jb2xzIGxpa2UgVExTLiBUaGUgdGV4dCBpbiBTZWN0aW9uDQo+ ID4gNyBtaWdodCBuZWVkIHRvIHJlbWluZCByZWFkZXJzIHRoYXQgdGhpcyB3aWxsIGFyZ3VlIGFn YWluc3QgdGhlIHJlZ2lzdHJhdGlvbg0KPiA+IG9mIOKAnHZhbml0eeKAnSBBRUFEIGFsZ29yaXRo bXMgZm9yIHRjcGNyeXB0Lg0KPiANCj4gSG0geWVzLCBJIHNlZSB0aGF0IFRMUyAxLjMgdXNlcyBh IHR3by1ieXRlIGlkZW50aWZpZXIgZm9yIGENCj4gc2ltaWxhciBwdXJwb3NlLCBhbHRob3VnaCBp dCBsb29rcyBsaWtlIHRoaXMgc3BlY2lmaWVzIGJvdGgNCj4gYW4gQUVBRCBhbGdvcml0aG0gYW5k IGFuIEhLREYuDQo+IA0KPiBXZWxsLCBhbHRob3VnaCB0aGUgY29kZS1zcGFjZSB1c2VkIGJ5IHRj cGNyeXB0IGlzIHNtYWxsLA0KPiBUQ1AtRU5PIGlzIGEgYmlnIGVzY2FwZS1oYXRjaCBpbiB0ZXJt cyBvZiBleHRlbnNpYmlsaXR5Lg0KPiBGb3IgZXhhbXBsZSwgdGNwY3J5cHQgY291bGQgYmUgZXh0 ZW5kZWQgd2l0aCBhZGRpdGlvbmFsIFRFUHMNCj4gd2hvc2Ugb25seSBkaWZmZXJlbmNlIGlzIHRv IG1hcCB0aGUgc3ltbWV0cmljLWNpcGhlcg0KPiBpZGVudGlmaWVyLWJ5dGVzIHRvIGRpZmZlcmVu dCBtZWFuaW5ncy4gIE5vdCB0aGUgcHJldHRpZXN0DQo+IHNvbHV0aW9uLCBidXQgcGVyaGFwcyBh Y2NlcHRhYmxlIGlmIG9uZSBpcyBvcHRpbWlzdGljIHRoYXQNCj4gZXhoYXVzdGlvbiBpcyB1bmxp a2VseSBhbnl3YXk/DQo+IA0KPiA+DQo+ID4gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgYXJlIGRl c2NyaWJlZCBpbiBTZWN0aW9uIDguIEkgZm91bmQgdGhlIHBocmFzZQ0KPiDigJxNb3N0DQo+ID4g aW1wbGVtZW50YXRpb25zIHdpbGwgcmVseSBvbiBzeXN0ZW0td2lkZSBwc2V1ZG8tcmFuZG9tIGdl bmVyYXRvcnPigKbigJ0gdG8NCj4gYmUgYQ0KPiA+IGJpdCBjb25mdXNpbmcsIGJlY2F1c2UgdGhl IGFtYmlndWl0eSBvZiB0aGUgd29yZCDigJxzeXN0ZW3igJ0gaGVyZS4gSSBwcmVzdW1lDQo+ID4g dGhpcyByZWFsbHkgcmVmZXJzIHRvIGEgc2luZ2xlIGRldmljZSBpbiBtb3RzIGNhc2VzLCBlLmcu LCBhIGxhcHRvcCwNCj4gPiBkZXNrdG9wLCBzbWFydHBob25lLCByaWdodD8gSSBzdWdnZXN0IGEg cmVmZXJlbmNlIHRvIFJGQyA0MDg2IG1pZ2h0IGJlIGENCj4gPiBnb29kIHN1YnN0aXR1dGUgZm9y IG11Y2ggb2YgdGhlIHRleHQgYXQgdGhlIGJlZ2lubmluZyBvZiB0aGlzIHNlY3Rpb24uDQo+IA0K PiBSaWdodC4gIEknbGwgY2xhcmlmeSB0aGF0LCBhbmQgYWxzbyBjb25zaWRlciBpbnZva2luZw0K PiBSRkMgNDA4NiB0byByZXBsYWNlIHRoZSBkZXRhaWxzIG9mIHRoZSBmaXJzdCB0aHJlZQ0KPiBw YXJhZ3JhcGhzLg0KPiANCj4gPg0KPiA+IEnigJlkIGxpa2UgdGhlIGF1dGhvcnMgdG8gcHJvdmlk ZSBhIHJhdGlvbmFsZSBmb3IgdGhlIGFkdmljZTog4oCc4oCmbGltaXQgdGhlDQo+ID4gbGlmZXRp bWUgb2YgdGhlIHByaXZhdGUgcGFyYW1ldGVycywgaWRlYWxseSB0byBubyBtb3JlIHRoYW4gdHdv IG1pbnV0ZXMu4oCdDQo+ID4gVGhpcyBzZWVtcyBhIGJpdCBhcmJpdHJhcnkgdG8gbWUuDQo+IA0K PiBJbmRlZWQuICBJJ3ZlIHJld29ya2VkIHRoYXQgcGFyYWdyYXBoIGFzIGZvbGxvd3M6DQo+IA0K PiAgICBUY3BjcnlwdCB1c2VzIHNob3J0LWxpdmVkIHB1YmxpYyBrZXlzIHRvIHByb3ZpZGUgZm9y d2FyZCBzZWNyZWN5Lg0KPiAgICBUaGF0IGlzLCBvbmNlIGFuIGltcGxlbWVudGF0aW9uIHJlbW92 ZXMgdGhlc2Uga2V5cyBmcm9tIG1lbW9yeSwgYQ0KPiAgICBjb21wcm9taXNlIG9mIHRoZSBzeXN0 ZW0gd2lsbCBub3QgcHJvdmlkZSBhbnkgbWVhbnMgdG8gZGVyaXZlIHRoZQ0KPiAgICBzZXNzaW9u IGtleXMgZm9yIHBhc3QgY29ubmVjdGlvbnMuICBBbGwgY3VycmVudGx5IHNwZWNpZmllZCBrZXkN Cj4gICAgYWdyZWVtZW50IHNjaGVtZXMgaW52b2x2ZSBFQ0RIRS1iYXNlZCBrZXkgYWdyZWVtZW50 LCBtZWFuaW5nIGEgbmV3DQo+ICAgIGtleXBhaXIgY2FuIGJlIGVmZmljaWVudGx5IGNvbXB1dGVk IGZvciBlYWNoIGNvbm5lY3Rpb24uICBJZg0KPiAgICBpbXBsZW1lbnRhdGlvbnMgcmV1c2UgdGhl c2UgcGFyYW1ldGVycywgdGhleSBTSE9VTEQgbGltaXQgdGhlDQo+ICAgIGxpZmV0aW1lIG9mIHRo ZSBwcml2YXRlIHBhcmFtZXRlcnMgYXMgZmFyIGFzIHByYWN0aWNhbCBpbiBvcmRlciB0bw0KPiAg ICBtaW5pbWl6ZSB0aGUgbnVtYmVyIG9mIHBhc3QgY29ubmVjdGlvbnMgdGhhdCBhcmUgdnVsbmVy YWJsZS4NCj4gDQo+ID4NCj4gPiBTdWdnZXN0ZWQgZWRpdG9yaWFsIGNoYW5nZXMgdG8gU2VjdGlv biA4Og0KPiA+DQo+ID4g4oCmIGlzIG9uZSBvbiB3aGljaCAtPiBpcyBvbmUgZm9yIHdoaWNoDQo+ ID4NCj4gPiDigKYgd2l0aG91dCBndWVzc2luZyB0aGUgY29udGVudCBvZiB0aGUgcmVzdW1wdGlv biBpZGVudGlmaWVyLCAtPiB3aXRob3V0DQo+ID4gc3VjY2Vzc2Z1bGx5IGd1ZXNzaW5nIHRoZSB2 YWx1ZSBvZiB0aGUgcmVzdW1wdGlvbiBpZGVudGlmaWVyLA0KPiA+DQo+ID4gVGh1cywgdGNwY3J5 cHQgc3BlY2lmaWVzIGEgd2F5IOKApiAtPiBUbyBjb3VudGVyIHRoaXMgdGhyZWF0LCB0Y3Bjcnlw dA0KPiA+IHNwZWNpZmllcyBhIHdheSDigKYNCj4gPg0KPiANCj4gR3JlYXQsIEkndmUgYWRvcHRl ZCB0aGUgZmlyc3QgYW5kIHRoaXJkIHN1Z2dlc3Rpb25zLg0KPiANCj4gVGhhbmtzIGFnYWluIGZv ciB5b3VyIHZlcnkgdGhvdWdodGZ1bCByZXZpZXchICBJIHRoaW5rIHRoaXMNCj4gaGFzIHNpZ25p ZmljYW50bHkgaW1wcm92ZWQgdGhlIGRyYWZ0IGluIHF1aXRlIGEgZmV3IHdheXMuDQo+IA0KPiBk YW5pZWwNCg0K From nobody Mon Oct 23 08:30:45 2017 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 79FD3139478 for ; Mon, 23 Oct 2017 08:30:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.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 qsOnK1qEC9jN for ; Mon, 23 Oct 2017 08:30:41 -0700 (PDT) Received: from omr-a011e.mx.aol.com (omr-a011e.mx.aol.com [204.29.186.59]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C260D139428 for ; Mon, 23 Oct 2017 08:30:40 -0700 (PDT) Received: from mtaout-aaa01.mx.aol.com (mtaout-aaa01.mx.aol.com [172.27.1.225]) by omr-a011e.mx.aol.com (Outbound Mail Relay) with ESMTP id C4068380008D; Mon, 23 Oct 2017 11:30:39 -0400 (EDT) Received: from iMac.fios-router.home (pool-173-48-69-73.bstnma.fios.verizon.net [173.48.69.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mtaout-aaa01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 74F9B38000089; Mon, 23 Oct 2017 11:30:38 -0400 (EDT) To: Daniel B Giffin Cc: secdir@ietf.org, david.black@dell.com, krose@krose.org, ietf@kuehlewind.net, M.Handley@cs.ucl.ac.uk, dm@uun.org, eric.smith@kestrel.edu, sqs@sourcegraph.com References: <20171021013702.GB85636@scs.stanford.edu> From: Stephen Kent Message-ID: <88e80c7a-0534-5ff0-deeb-c0bc5f3c9a09@verizon.net> Date: Mon, 23 Oct 2017 11:30:38 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20171021013702.GB85636@scs.stanford.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US x-aol-global-disposition: G x-aol-sid: 3039ac1b01e159ee0b1e7a55 X-AOL-IP: 173.48.69.73 Archived-At: Subject: Re: [secdir] SECDIR review of draft-ietf-t cpinc-tcpcrypt-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2017 15:30:43 -0000 Daniel, Thanks for the response. > Hi Stephen, > > Thanks very much for your detailed review! > > So that others can see how your notes will be incorporated > into the next draft, I'll respond to them below. > > (Where I take an interactive tone below, I don't mean that > you need to respond. Although more discussion is welcome, I > will go ahead with the changes I propose.) > >> 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. >> >> This document is the specification for tcpcrypt, which is targeted to be an >> Experimental RFC. It is generally very well written, but it could benefit >> from a few edits, as noted below. >> >> The introduction (section 2) is brief and well written, stating the goals >> for the design. >> >> Section 3 is much longer, providing a detailed description of the protocol. >> (Although the description is characterized as “abstract” it is very >> detailed, with only format details deferred to Section 4.) This section also >> is generally well-written. >> >> In 3.2 I suggest including a forward pointer to the IANA Considerations >> section, since that section describes how future TEPs may be added to the >> list in Table 2. > Well, although this document provides (in the IANA > Considerations section) a policy for assignment of > identifiers to the "tcpcrypt AEAD Algorithm" registry", the > policy for assignment of TEP identifiers lives in TCP-ENO. OK. > How about changing the last sentence of the first paragraph > of 3.2 from: > > Future standards may associate additional identifiers with > tcpcrypt. > > to instead: > > Future standards may associate additional TEP identifiers > with tcpcrypt, following the assignment policy specified > by TCP-ENO. Great. > >> In 3.5 the text says: >> >> When two hosts have previously negotiated a tcpcrypt session, >> >> either host may initiate session resumption regardless of which >> >> host was the active opener or played the "A" role in the >> >> previous session. >> >> It’s not clear to me in what time frame this comment is meant to apply, >> e.g., if two hosts established a tcpcrypt session a week ago, is this >> comment still supposed to be applicable? Some clarification here would be >> useful. The end of this section establishes a requirement for an interface >> to enable an application to control session caching. Are interfaces of this >> sort commonly provided to applications by an OS? If so, an example would be >> useful; if not, the authors should acknowledge that this requirement may be >> problematic, i.e., applications may require modification to make use of the >> mandated interface. > Regarding the timeframe for resumption: I see how our > language is confusing. I'll replace the first sentence of > the first paragraph of this section with: > > If two hosts have previously negotiated a tcpcrypt session secret > "ss[i-1]", and have cached the derived session secret "ss[i]", they > may later establish a new connection without public-key operations > using "ss[i]". Good. > > ... and then also replace the paragraph you mention with: > > If two hosts have previously negotiated a tcpcrypt session, either > host may later initiate session resumption regardless of which host > was the active opener or played the "A" role in the previous session. Great. > > These changes are subtle, but I hope they better convey > (together with the rest of the section) that resumption with > a particular session secret may be performed once, at any > time later, provided that both hosts have cached the secret. > > Regarding interfaces: Although applications can benefit from > tcpcrypt without knowledge of it (and thus without having to > configure it), this document nevertheless requires > implementations of tcpcrypt to provide an interface for > configuring some aspects of its operation; this permits > tcpcrypt-aware applications the control they need to build > even-more-secure arrangements. > > The working group has an Informational draft suggesting how > best to extend OS interfaces to include the configuration of > TCP-ENO and tcpcrypt, using mechanisms (socket options and > sysctls) present in most popular operating systems: > > https://datatracker.ietf.org/doc/draft-ietf-tcpinc-api/ > > I can see that reading the tcpcrypt document alone leaves > questions about how to meet the API requirements; but of > course we aren't in a position to cite the not-yet-published > API draft. I don't know enough about how related RFCs could > be brought to the attention of readers, so suggestions to > address this are welcome. David's message explained how to refer to that I-D w/o making it a gating factor for this one. > >> In 3.6 the mention Table 3 also should refer to IANA Considerations, since >> that section describes how additions algorithms may be added. > Thanks, I'm changing the relevant paragraph to read: > > This protection is provided via algorithms for Authenticated > Encryption with Associated Data (AEAD). The particular algorithms > that may be used are listed in Table 3, and additional algorithms may > be specified according to the policy in Section 7. One algorithm is > selected during the negotiation described in Section 3.3. Good. > >> The last sentence of 3.7 should be broken into several sentences; it is >> currently 7 lines long! > Ha, indeed ... done! thanks. > >> Section 3.8 describes a fairly complicated set of constraintsassociated with >> rekeying, some of which are inter-related. It might help to have a table >> here to describe how these constraints interact, e.g., when TCP-mandated >> retransmission takes place in the context of a rekey. > Certainly that is a delicate section. Although I can't > quite picture the table you're suggesting, I have reworked > the paragraph mentioning TCP retransmission as follows: > > Note that when parts of the datastream are retransmitted, TCP > requires that implementations always send the same data bytes for the > same TCP sequence numbers. Thus, frame data in retransmitted > segments must be encrypted with the same key as when it was first > transmitted, regardless of the current local generation number. that's better. > > I'm hoping that makes it more clear that retransmission and > rekeying shouldn't really interact at all: this paragraph > doesn't impose any new constraints, and I've changed to a > lower-case "must" to avoid the appearance of one. It is > merely a note to help implementations avoid offending TCP. good. > >> I suggest the following editorial changes in section 3: >> >> … assigns different roles to -> … assigns the roles to the two hosts >> >> … ephemeral public keys for hosts A and B -> … ephemeral public key >> agreement keys for hosts A and B >> >> … whose length depends -> … the length of which depends >> >> … whose integer value -> … the integer value of which >> >> … security of the AEAD algorithm -> … security of every AEAD algorithm > Great, I've mostly incorporated these suggestions. > > Although I understand it might not sound quite right to > every ear, I couldn't bring myself to abandon those > applications of "whose" to inanimate objects. I mean hey, > two less words than "the _ of which"! And although I don't > want to argue by authority or precedent, these literary > examples sound elegant and clear to me: > > https://english.stackexchange.com/questions/23541/can-whose-refer-to-an-inanimate-object I believe Strunk & White is more restrictive, but then I'm a guy who's picky about using which vs. that, fewer vs. less,  ... :-) > > And as for nonce-reuse in AEAD algorithms, I guess we > shouldn't say it is strictly verboten for *every* algorithm, > as there are new "nonce-misuse resistant" algs coming down > the pipe. So I've gone with: "Because it is strictly > necessary for the security of the AEAD algorithms specified > in this document, ..." yes, that's a good clarification. > >> Section 4 describes the byte-level encoding for the data structures >> described in Section 3, as part of the tcpcrypt specification. In 4.1 found >> the description of the “ignored” data the INIT1_ and INIT2_ messages to be a >> bit confusing. I had to reread the descriptions to figure out that this was >> the authors’ way of saying that data beyond the end of the message (as >> indicated by the message_len field) is to be ignored upon reception. I don’t >> think the graphics used here are a great way to explain this. > Yes ... I'll try to find a better way. > >> Section 6 defines the initial set of AEAD algorithms supported by tcpcrypt, >> in Table 2. Each algorithm is assigned a value in the 1-255 range, a much >> smaller range of values that used in protocols like TLS. The text in Section >> 7 might need to remind readers that this will argue against the registration >> of “vanity” AEAD algorithms for tcpcrypt. > Hm yes, I see that TLS 1.3 uses a two-byte identifier for a > similar purpose, although it looks like this specifies both > an AEAD algorithm and an HKDF. > > Well, although the code-space used by tcpcrypt is small, > TCP-ENO is a big escape-hatch in terms of extensibility. > For example, tcpcrypt could be extended with additional TEPs > whose only difference is to map the symmetric-cipher > identifier-bytes to different meanings. Not the prettiest > solution, but perhaps acceptable if one is optimistic that > exhaustion is unlikely anyway? We've seen nation-specific algorithms proposed as optional for use with a number of security protocols, which is why I mention this issue. An allusion to the potential to expand this space, if needed, would be useful here. > >> Security Considerations are described in Section 8. I found the phrase “Most >> implementations will rely on system-wide pseudo-random generators…” to be a >> bit confusing, because the ambiguity of the word “system” here. I presume >> this really refers to a single device in mots cases, e.g., a laptop, >> desktop, smartphone, right? I suggest a reference to RFC 4086 might be a >> good substitute for much of the text at the beginning of this section. > Right. I'll clarify that, and also consider invoking > RFC 4086 to replace the details of the first three > paragraphs. OK. > >> I’d like the authors to provide a rationale for the advice: “…limit the >> lifetime of the private parameters, ideally to no more than two minutes.” >> This seems a bit arbitrary to me. > Indeed. I've reworked that paragraph as follows: > > Tcpcrypt uses short-lived public keys to provide forward secrecy. > That is, once an implementation removes these keys from memory, a > compromise of the system will not provide any means to derive the > session keys for past connections. All currently specified key > agreement schemes involve ECDHE-based key agreement, meaning a new > keypair can be efficiently computed for each connection. If > implementations reuse these parameters, they SHOULD limit the > lifetime of the private parameters as far as practical in order to > minimize the number of past connections that are vulnerable. Much better! Steve From nobody Tue Oct 24 00:08:08 2017 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 183C113C96F for ; Tue, 24 Oct 2017 00:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 p7VSr_x81_UC for ; Tue, 24 Oct 2017 00:08:05 -0700 (PDT) Received: from market.scs.stanford.edu (www.scs.stanford.edu [IPv6:2001:470:806d:1::9]) (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 C047E13C907 for ; Tue, 24 Oct 2017 00:08:05 -0700 (PDT) Received: from market.scs.stanford.edu (localhost [127.0.0.1]) by market.scs.stanford.edu (8.15.2/8.15.2) with ESMTP id v9O7827J035890; Tue, 24 Oct 2017 00:08:02 -0700 (PDT) Received: (from dbg@localhost) by market.scs.stanford.edu (8.15.2/8.15.2/Submit) id v9O77xJS063368; Tue, 24 Oct 2017 00:07:59 -0700 (PDT) Date: Tue, 24 Oct 2017 00:07:59 -0700 From: Daniel B Giffin To: Stephen Kent Cc: secdir@ietf.org, david.black@dell.com, krose@krose.org, ietf@kuehlewind.net, M.Handley@cs.ucl.ac.uk, dm@uun.org, eric.smith@kestrel.edu, sqs@sourcegraph.com Message-ID: <20171024070759.GA61933@scs.stanford.edu> References: <20171021013702.GB85636@scs.stanford.edu> <88e80c7a-0534-5ff0-deeb-c0bc5f3c9a09@verizon.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <88e80c7a-0534-5ff0-deeb-c0bc5f3c9a09@verizon.net> Archived-At: Subject: Re: [secdir] SECDIR review of draft-ietf-t cpinc-tcpcrypt-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 07:08:07 -0000 Hi Stephen et al., Below is some discussion about the number of bits devoted to negotiating the symmetric cipher (currently eight for tcpcrypt) ... Stephen Kent wrote: > > > Section 6 defines the initial set of AEAD algorithms supported by tcpcrypt, > > > in Table 2. Each algorithm is assigned a value in the 1-255 range, a much > > > smaller range of values that used in protocols like TLS. The text in Section > > > 7 might need to remind readers that this will argue against the registration > > > of “vanity” AEAD algorithms for tcpcrypt. > > Hm yes, I see that TLS 1.3 uses a two-byte identifier for a > > similar purpose, although it looks like this specifies both > > an AEAD algorithm and an HKDF. > > > > Well, although the code-space used by tcpcrypt is small, > > TCP-ENO is a big escape-hatch in terms of extensibility. > > For example, tcpcrypt could be extended with additional TEPs > > whose only difference is to map the symmetric-cipher > > identifier-bytes to different meanings. Not the prettiest > > solution, but perhaps acceptable if one is optimistic that > > exhaustion is unlikely anyway? > We've seen nation-specific algorithms proposed as optional for use with a > number of > security protocols, which is why I mention this issue. An allusion to the > potential > to expand this space, if needed, would be useful here. If you could let us know what protocols you mean, that would be a helpful point of comparison. It looks like the main TLS 1.3 document specifies only five symmetric algorithms, but of course other documents could supplement this arbitrarily; I guess I should look at OpenSSL or something to see how many are actually supported. Concerning "nation-specific algorithms", do you mean that the number of needed symmetric-encryption algorithms could be on the same order as the number of countries in the world? If there's a need to mention how the code-space for symmetric ciphers could be expanded, maybe we should seriously consider allocating 16 bits to this; I just don't have a good handle on the order of magnitude that is plausibly needed. daniel From nobody Tue Oct 24 06:45:06 2017 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 6BE4F13F49A for ; Tue, 24 Oct 2017 06:45:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=dell.com header.b=H69Jn88V; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=rsa.com header.b=BwbESJbJ 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 QOTHznND845f for ; Tue, 24 Oct 2017 06:45:02 -0700 (PDT) Received: from esa5.dell-outbound.iphmx.com (esa5.dell-outbound.iphmx.com [68.232.153.95]) (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 3ACC2138BD6 for ; Tue, 24 Oct 2017 06:45:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1508852536; x=1540388536; h=from:cc:to:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=MD/obAKJTw+5gHQyLST9FIe/aUvVqP3avDfmY2StJpY=; b=H69Jn88VKnVjTktVpesqEpjgFZW9GEnvf6Ix1+ujcfIQtldzxnlXsM23 OU+3oSrbzvY49wCFPzmAEzGR0H8lYM/IcQlz7eC4qjCL15KOZ9yTogI7n 7+48EGSsDRuMrAnVO4KxC1J/vWxej6hMfBZlnjB0xKCabcj2uczuoCbFp g=; Received: from esa1.dell-outbound2.iphmx.com ([68.232.153.201]) by esa5.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Oct 2017 08:42:16 -0500 From: "Black, David" Cc: "secdir@ietf.org" , "krose@krose.org" , "ietf@kuehlewind.net" , "M.Handley@cs.ucl.ac.uk" , "dm@uun.org" , "eric.smith@kestrel.edu" , "sqs@sourcegraph.com" , "Black, David" Received: from mailuogwhop.emc.com ([168.159.213.141]) by esa1.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Oct 2017 19:38:06 +0600 Received: from maildlpprd03.lss.emc.com (maildlpprd03.lss.emc.com [10.253.24.35]) by mailuogwprd05.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v9ODiqIx003336 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 24 Oct 2017 09:44:59 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd05.lss.emc.com v9ODiqIx003336 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=rsa.com; s=jan2013; t=1508852699; bh=f77qufK6H42uARZP4Cy/eqp2INs=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=BwbESJbJVTmoNH7paKsMP1OpoUTt78EXx8OKT49Bdr5UizvgP4wCFVLe2GWn7CaSn p/9kiLw69qW1PU94kzEo2q9fq9WlJ19XOvjGvs3LZJqPEOJPjbzp6i0GT5IRHuKN8d 6I/+9UqFagMHVnu8d2E7QohpFZBP4IJxhov2l7wg= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd05.lss.emc.com v9ODiqIx003336 Received: from mailusrhubprd03.lss.emc.com (mailusrhubprd03.lss.emc.com [10.253.24.21]) by maildlpprd03.lss.emc.com (RSA Interceptor); Tue, 24 Oct 2017 09:42:53 -0400 Received: from MXHUB313.corp.emc.com (MXHUB313.corp.emc.com [10.146.3.91]) by mailusrhubprd03.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v9ODiTFs013742 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Tue, 24 Oct 2017 09:44:31 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB313.corp.emc.com ([10.146.3.91]) with mapi id 14.03.0352.000; Tue, 24 Oct 2017 09:44:29 -0400 To: Daniel B Giffin , Stephen Kent Thread-Topic: SECDIR review of draft-ietf-t cpinc-tcpcrypt-07 Thread-Index: AQHTQ3r+s8CqFyKgTEyy6VMimgVfjaLt1kcAgAQNkgCAAQXkgIAAJVwA Date: Tue, 24 Oct 2017 13:44:28 +0000 Message-ID: References: <20171021013702.GB85636@scs.stanford.edu> <88e80c7a-0534-5ff0-deeb-c0bc5f3c9a09@verizon.net> <20171024070759.GA61933@scs.stanford.edu> In-Reply-To: <20171024070759.GA61933@scs.stanford.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.138] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd03.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: Re: [secdir] SECDIR review of draft-ietf-t cpinc-tcpcrypt-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 13:45:04 -0000 U3RlcGhlbiwNCg0KPiA+ID4gPiBTZWN0aW9uIDYgZGVmaW5lcyB0aGUgaW5pdGlhbCBzZXQgb2Yg QUVBRCBhbGdvcml0aG1zIHN1cHBvcnRlZCBieSB0Y3BjcnlwdCwNCj4gPiA+ID4gaW4gVGFibGUg Mi4gRWFjaCBhbGdvcml0aG0gaXMgYXNzaWduZWQgYSB2YWx1ZSBpbiB0aGUgMS0yNTUgcmFuZ2Us IGEgbXVjaA0KPiA+ID4gPiBzbWFsbGVyIHJhbmdlIG9mIHZhbHVlcyB0aGF0IHVzZWQgaW4gcHJv dG9jb2xzIGxpa2UgVExTLiBUaGUNCg0KVGhpcyBkb2VzIG5vdCBhcHBlYXIgdG8gYmUgYSBzaWdu aWZpY2FudCBwcm9ibGVtIGluIHByYWN0aWNlIC0gYSBxdWljayBzY2FuIG9mIHRoZSBUTFMgY2lw aGVyc3VpdGUgcmVnaXN0cnkgKGh0dHBzOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL3Rscy1w YXJhbWV0ZXJzL3Rscy1wYXJhbWV0ZXJzLnhodG1sI3Rscy1wYXJhbWV0ZXJzLTQpIHR1cm5zIHVw IGxlc3MgdGhhbiBoYWxmLWEtZG96ZW4gZW5jcnlwdGlvbiBhbGdvcml0aG1zIHRoYXQgYXBwZWFy IHRvIGJlIG5hdGlvbi1zcGVjaWZpYy4NCg0KVGhlIHR3byBwcmltYXJ5IHJlYXNvbnMgZm9yIHRo ZSBtYXNzaXZlIHNpemUgb2YgdGhhdCBUTFMgcmVnaXN0cnkgYXJlOg0KCWEpIGEgYnVuY2ggb2Yg b2Jzb2xldGUgY3IqcCB0aGF0IFNIT1VMRCBOT1QgYmUgdXNlZCAoZS5nLiwgUkM0LCBERVMgYW5k ICBFWFBPUlQgY2lwaGVyc3VpdGVzKTsgYW5kDQoJYikgdGhlIGNvbWJpbmF0b3JpY3Mgb2YgcmVn aXN0ZXJpbmcgYWxsIHRoZSBwb3NzaWJsZSBUTFMgY2lwaGVyc3VpdGVzLCBjb3VydGVzeSBvZiB0 aGUgbnVtYmVyIG9mIGNvbXBvbmVudHMgaW4gYSBUTFMgY2lwaGVyc3VpdGUuDQpOZWl0aGVyIG9m IHRob3NlIGFwcGx5IHRvIHRjcGNyeXB0Lg0KDQpUaGUgSUtFdjIgVHJhbnNmb3JtIFR5cGUgMSAt IEVuY3J5cHRpb24gQWxnb3JpdGhtIFRyYW5zZm9ybSBJRHMgcmVnaXN0cnkgKGh0dHBzOi8vd3d3 LmlhbmEub3JnL2Fzc2lnbm1lbnRzL2lrZXYyLXBhcmFtZXRlcnMvaWtldjItcGFyYW1ldGVycy54 aHRtbCNpa2V2Mi1wYXJhbWV0ZXJzLTMpIGFwcGVhcnMgdG8gYmUgYSBiZXR0ZXIgZXhhbXBsZSBm b3IgdGhpcyBhbmFsb2d5IC0gaXQgaGFzIGxlc3MgdGhhbiAzMCB2YWx1ZXMgYXNzaWduZWQuICBJ J2Qgc3VnZ2VzdCBhZGRpbmcgb25lIHNlbnRlbmNlIHRvIHBvaW50IG91dCB0aGUgZm9sbG93aW5n Og0KDQo+ID4gPiBXZWxsLCBhbHRob3VnaCB0aGUgY29kZS1zcGFjZSB1c2VkIGJ5IHRjcGNyeXB0 IGlzIHNtYWxsLA0KPiA+ID4gVENQLUVOTyBpcyBhIGJpZyBlc2NhcGUtaGF0Y2ggaW4gdGVybXMg b2YgZXh0ZW5zaWJpbGl0eS4NCg0KVGhhbmtzLCAtLURhdmlkDQoNCj4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4gRnJvbTogRGFuaWVsIEIgR2lmZmluIFttYWlsdG86ZGJnQHNjcy5zdGFu Zm9yZC5lZHVdDQo+IFNlbnQ6IFR1ZXNkYXksIE9jdG9iZXIgMjQsIDIwMTcgMzowOCBBTQ0KPiBU bzogU3RlcGhlbiBLZW50IDxzdGtlbnRAdmVyaXpvbi5uZXQ+DQo+IENjOiBzZWNkaXJAaWV0Zi5v cmc7IEJsYWNrLCBEYXZpZCA8ZGF2aWQuYmxhY2tAZW1jLmNvbT47IGtyb3NlQGtyb3NlLm9yZzsN Cj4gaWV0ZkBrdWVobGV3aW5kLm5ldDsgTS5IYW5kbGV5QGNzLnVjbC5hYy51azsgZG1AdXVuLm9y ZzsNCj4gZXJpYy5zbWl0aEBrZXN0cmVsLmVkdTsgc3FzQHNvdXJjZWdyYXBoLmNvbQ0KPiBTdWJq ZWN0OiBSZTogU0VDRElSIHJldmlldyBvZiBkcmFmdC1pZXRmLXQgY3BpbmMtdGNwY3J5cHQtMDcN Cj4gDQo+IEhpIFN0ZXBoZW4gZXQgYWwuLA0KPiANCj4gQmVsb3cgaXMgc29tZSBkaXNjdXNzaW9u IGFib3V0IHRoZSBudW1iZXIgb2YgYml0cyBkZXZvdGVkIHRvDQo+IG5lZ290aWF0aW5nIHRoZSBz eW1tZXRyaWMgY2lwaGVyIChjdXJyZW50bHkgZWlnaHQgZm9yDQo+IHRjcGNyeXB0KSAuLi4NCj4g DQo+IFN0ZXBoZW4gS2VudCB3cm90ZToNCj4gPiA+ID4gU2VjdGlvbiA2IGRlZmluZXMgdGhlIGlu aXRpYWwgc2V0IG9mIEFFQUQgYWxnb3JpdGhtcyBzdXBwb3J0ZWQgYnkNCj4gdGNwY3J5cHQsDQo+ ID4gPiA+IGluIFRhYmxlIDIuIEVhY2ggYWxnb3JpdGhtIGlzIGFzc2lnbmVkIGEgdmFsdWUgaW4g dGhlIDEtMjU1IHJhbmdlLCBhIG11Y2gNCj4gPiA+ID4gc21hbGxlciByYW5nZSBvZiB2YWx1ZXMg dGhhdCB1c2VkIGluIHByb3RvY29scyBsaWtlIFRMUy4gVGhlIHRleHQgaW4NCj4gU2VjdGlvbg0K PiA+ID4gPiA3IG1pZ2h0IG5lZWQgdG8gcmVtaW5kIHJlYWRlcnMgdGhhdCB0aGlzIHdpbGwgYXJn dWUgYWdhaW5zdCB0aGUNCj4gcmVnaXN0cmF0aW9uDQo+ID4gPiA+IG9mIOKAnHZhbml0eeKAnSBB RUFEIGFsZ29yaXRobXMgZm9yIHRjcGNyeXB0Lg0KPiA+ID4gSG0geWVzLCBJIHNlZSB0aGF0IFRM UyAxLjMgdXNlcyBhIHR3by1ieXRlIGlkZW50aWZpZXIgZm9yIGENCj4gPiA+IHNpbWlsYXIgcHVy cG9zZSwgYWx0aG91Z2ggaXQgbG9va3MgbGlrZSB0aGlzIHNwZWNpZmllcyBib3RoDQo+ID4gPiBh biBBRUFEIGFsZ29yaXRobSBhbmQgYW4gSEtERi4NCj4gPiA+DQo+ID4gPiBXZWxsLCBhbHRob3Vn aCB0aGUgY29kZS1zcGFjZSB1c2VkIGJ5IHRjcGNyeXB0IGlzIHNtYWxsLA0KPiA+ID4gVENQLUVO TyBpcyBhIGJpZyBlc2NhcGUtaGF0Y2ggaW4gdGVybXMgb2YgZXh0ZW5zaWJpbGl0eS4NCj4gPiA+ IEZvciBleGFtcGxlLCB0Y3BjcnlwdCBjb3VsZCBiZSBleHRlbmRlZCB3aXRoIGFkZGl0aW9uYWwg VEVQcw0KPiA+ID4gd2hvc2Ugb25seSBkaWZmZXJlbmNlIGlzIHRvIG1hcCB0aGUgc3ltbWV0cmlj LWNpcGhlcg0KPiA+ID4gaWRlbnRpZmllci1ieXRlcyB0byBkaWZmZXJlbnQgbWVhbmluZ3MuICBO b3QgdGhlIHByZXR0aWVzdA0KPiA+ID4gc29sdXRpb24sIGJ1dCBwZXJoYXBzIGFjY2VwdGFibGUg aWYgb25lIGlzIG9wdGltaXN0aWMgdGhhdA0KPiA+ID4gZXhoYXVzdGlvbiBpcyB1bmxpa2VseSBh bnl3YXk/DQo+ID4gV2UndmUgc2VlbiBuYXRpb24tc3BlY2lmaWMgYWxnb3JpdGhtcyBwcm9wb3Nl ZCBhcyBvcHRpb25hbCBmb3IgdXNlIHdpdGggYQ0KPiA+IG51bWJlciBvZg0KPiA+IHNlY3VyaXR5 IHByb3RvY29scywgd2hpY2ggaXMgd2h5IEkgbWVudGlvbiB0aGlzIGlzc3VlLiBBbiBhbGx1c2lv biB0byB0aGUNCj4gPiBwb3RlbnRpYWwNCj4gPiB0byBleHBhbmQgdGhpcyBzcGFjZSwgaWYgbmVl ZGVkLCB3b3VsZCBiZSB1c2VmdWwgaGVyZS4NCj4gDQo+IElmIHlvdSBjb3VsZCBsZXQgdXMga25v dyB3aGF0IHByb3RvY29scyB5b3UgbWVhbiwgdGhhdCB3b3VsZA0KPiBiZSBhIGhlbHBmdWwgcG9p bnQgb2YgY29tcGFyaXNvbi4gIEl0IGxvb2tzIGxpa2UgdGhlIG1haW4NCj4gVExTIDEuMyBkb2N1 bWVudCBzcGVjaWZpZXMgb25seSBmaXZlIHN5bW1ldHJpYyBhbGdvcml0aG1zLA0KPiBidXQgb2Yg Y291cnNlIG90aGVyIGRvY3VtZW50cyBjb3VsZCBzdXBwbGVtZW50IHRoaXMNCj4gYXJiaXRyYXJp bHk7IEkgZ3Vlc3MgSSBzaG91bGQgbG9vayBhdCBPcGVuU1NMIG9yIHNvbWV0aGluZw0KPiB0byBz ZWUgaG93IG1hbnkgYXJlIGFjdHVhbGx5IHN1cHBvcnRlZC4NCj4gDQo+IENvbmNlcm5pbmcgIm5h dGlvbi1zcGVjaWZpYyBhbGdvcml0aG1zIiwgZG8geW91IG1lYW4gdGhhdA0KPiB0aGUgbnVtYmVy IG9mIG5lZWRlZCBzeW1tZXRyaWMtZW5jcnlwdGlvbiBhbGdvcml0aG1zIGNvdWxkDQo+IGJlIG9u IHRoZSBzYW1lIG9yZGVyIGFzIHRoZSBudW1iZXIgb2YgY291bnRyaWVzIGluIHRoZQ0KPiB3b3Js ZD8NCj4gDQo+IElmIHRoZXJlJ3MgYSBuZWVkIHRvIG1lbnRpb24gaG93IHRoZSBjb2RlLXNwYWNl IGZvcg0KPiBzeW1tZXRyaWMgY2lwaGVycyBjb3VsZCBiZSBleHBhbmRlZCwgbWF5YmUgd2Ugc2hv dWxkDQo+IHNlcmlvdXNseSBjb25zaWRlciBhbGxvY2F0aW5nIDE2IGJpdHMgdG8gdGhpczsgSSBq dXN0IGRvbid0DQo+IGhhdmUgYSBnb29kIGhhbmRsZSBvbiB0aGUgb3JkZXIgb2YgbWFnbml0dWRl IHRoYXQgaXMNCj4gcGxhdXNpYmx5IG5lZWRlZC4NCj4gDQo+IGRhbmllbA0KDQo= From nobody Tue Oct 24 09:18:33 2017 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 61A4013943F for ; Tue, 24 Oct 2017 09:18:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.801 X-Spam-Level: X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8] 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 O-cCecD5JpZJ for ; Tue, 24 Oct 2017 09:18:25 -0700 (PDT) Received: from smtp90.iad3a.emailsrvr.com (smtp90.iad3a.emailsrvr.com [173.203.187.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 0CC4C13946F for ; Tue, 24 Oct 2017 09:18:25 -0700 (PDT) Received: from smtp4.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp4.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id EFF6B5AA5; Tue, 24 Oct 2017 12:18:21 -0400 (EDT) Received: from app11.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp4.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id DD4E05A98; Tue, 24 Oct 2017 12:18:21 -0400 (EDT) X-Sender-Id: scott@hyperthought.com Received: from app11.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.7.12); Tue, 24 Oct 2017 12:18:21 -0400 Received: from hyperthought.com (localhost.localdomain [127.0.0.1]) by app11.wa-webapps.iad3a (Postfix) with ESMTP id C9F99C0045; Tue, 24 Oct 2017 12:18:21 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: scott@hyperthought.com, from: scott@hyperthought.com) with HTTP; Tue, 24 Oct 2017 09:18:21 -0700 (PDT) X-Auth-ID: scott@hyperthought.com Date: Tue, 24 Oct 2017 09:18:21 -0700 (PDT) From: "Scott G. Kelly" To: "secdir@ietf.org" , "iesg@ietf.org" , draft-ietf-dhc-relay-port.all@tools.ietf.org MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-Type: plain Message-ID: <1508861901.825516724@apps.rackspace.com> X-Mailer: webmail/12.9.6-RC Archived-At: Subject: [secdir] secdir review of draft-ietf-dhc-relay-port-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 16:18:26 -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 com= ments 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.=0A=0AThe summary of the review is "ready" with mi= nor editorial nits.=0A=0AFrom the abstract, this document proposes an exten= sion to the DHCP protocols that allows a (DHCP) relay agent to receive pack= ets from a server or an upstream relay agent on any UDP port, not just the = default port 67 for IPv4 or default port 547 for IPv6.=0A=0AParaphrasing, i= t allows a relay agent to use any available source port for upstream commun= ications, and to include a DHCP option that can be used to statelessly rout= e responses back to the appropriate source port on downstream communication= s.=0A=0AThe security considerations section references [RFC3118] and [RFC33= 15], and adds that any firewalls in the path may need reconfiguration to al= low DHCP flows from non-fixed addresses. I don't have anything to add, thou= gh I think that section could benefit from a little word-smithing. I'll def= er to the RFC editor on that. =0A=0AThe draft is clear, though a simple asc= ii diagram illustrating a client, relay, and server (including src/dst port= s) might help readers to more immediately understand what this looks like t= opologically. I read it through, and then went back and drew myself a pictu= re as I read, and that helped. Just a thought.=0A=0AOne minor (non-security= ) question I had: section 6 illustrates a cascaded IPv6 example wherein Rel= ay1 is using a non-standard port, but Relay2 is not. What happens if both R= elay1 and Relay2 are using non-standard source ports? Is this allowed? If n= ot, you might want to call this out. If so, it might be good to describe a = general case of n relays with m non-standard source ports.=0A=0A--Scott=0A = =0A From nobody Tue Oct 24 10:16:54 2017 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 562BA13955E; Tue, 24 Oct 2017 10:16:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A1ieShkQjZBY; Tue, 24 Oct 2017 10:16:42 -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 01FC913954E; Tue, 24 Oct 2017 10:16:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2692; q=dns/txt; s=iport; t=1508865402; x=1510075002; h=from:subject:to:cc:references:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=+LV4/1v9fQxWHVlEe9RoD0erksF+JaruzAUoDXFJ56E=; b=Qg+7bKAhKChZ9zAfve/cVUZ/DvO2qoc2hwrMvtuEg3Y0dFp5Xt9FC+in PjrivPySWWb25U70Am0iIxoUb2uaQ4iJImkMSWLuM0yqM6gXeFnfC3Qhw 7bLYBeOnFqcuTiy2/Y8B/gHE/jblDbmS05T3mHdmpBEtfNREw49zDDF/I o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CiAAAEde9Z/4ENJK1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1+BUoQhih+PSYFUJnuVP4IRCoU7AoRhPxgBAgEBAQEBAQFrKIU?= =?us-ascii?q?dAQEBAQIBIw8BBUEFCwsYAgImAgJXBgEMCAEBihQIqB6CJ4shAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBIIEPgh+BKl2BUIFpKQuCQTWIGYJhBZJjjwqUdYIVhXqDXSSHFZV?= =?us-ascii?q?/gTkfOIFbNCEIHRWDLoJbHIIHIIwnAQEB?= X-IronPort-AV: E=Sophos;i="5.43,428,1503360000"; d="scan'208";a="21555998" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 Oct 2017 17:16:41 +0000 Received: from [10.155.69.231] (dhcp-10-155-69-231.cisco.com [10.155.69.231]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v9OHGb1k006413; Tue, 24 Oct 2017 17:16:40 GMT From: Fabio Maino To: Takeshi Takahashi , secdir@ietf.org Cc: draft-ietf-lisp-sec.all@ietf.org, ietf@ietf.org, lisp@ietf.org References: <150764751351.13466.15119625109787574982@ietfa.amsl.com> Message-ID: <77a18485-6759-5d24-de52-27f76a7d3837@cisco.com> Date: Tue, 24 Oct 2017 10:16:38 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <150764751351.13466.15119625109787574982@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-lisp-sec-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 17:16:43 -0000 Hi Takeshi, thanks for taking the time to review the document. Please see below for comments. Unless you have objections we plan to publish an updated rev by monday. On 10/10/17 7:58 AM, Takeshi Takahashi wrote: > Reviewer: Takeshi Takahashi > 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. > > I would say this document is ready with nits, but the nits are very minor. > > [comments that require chages to the current draft] > 1. I guess the authors mix up "reply" and "replay" in Section 6.6. "Reply > attacks" could be "Replay attacks". fixed, thanks! > [comments that does not necessarily require changes to the current draft] > 2. The security aspect of LISP is addressed not only in this draft but also in > RFC6830 and in RFC7835. If I understood correctly, LISP-SEC addressed a part of > the threats mentioned in RFC7835. Then, it would be nice if the authors could > clarify what types of further threats that are not mentioned in LISP-SEC still > exist by referring to RFC6830 and RFC7835. Section 3 of LISP-SEC provides the cross references with the threat model of RFC 7835. LISP-SEC focuses particularly on the threads described in section  3.7 and 3.8 of RFC 7835 that describes attacks that "target EID-to-RLOC mappings, including manipulations of Map-Request and Map-Reply messages, and malicious ETR EID prefix overclaiming." We should change the first sentence of section 3 to read: "LISP-SEC addresses the control plane threats, described in *Section 3.7 and 3.8 of* [RFC7835], that target EID-to-RLOC mappings, including manipulations of Map-Request and Map-Reply messages, and malicious ETR EID prefix overclaiming." > 3. DOS/DDoS was mentioned in the introduction section, but it was not discussed > in the later sections. It would be nice if the authors could address DoS/DDoS > issues as well. > > Good point. We should add a Section 6.7 that reads: "6.7 Denial of Service and Distributed Denial of Service Attacks LISP-SEC mitigates the risks of  Denial of Service and Distributed Denial of Service attacks by protecting the integrity and authenticating the origin of the Map-Request/Map-Reply messages, and by preventing malicious ETRs from overclaiming EID prefixes that could re-direct traffic directed to a potentially large number of hosts." Thanks, Fabio From nobody Tue Oct 24 14:02:41 2017 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 CC45A13F841 for ; Tue, 24 Oct 2017 14:02:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.901 X-Spam-Level: X-Spam-Status: No, score=-4.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.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 AL4KIfrAB56r for ; Tue, 24 Oct 2017 14:02:32 -0700 (PDT) Received: from omr-a017e.mx.aol.com (omr-a017e.mx.aol.com [204.29.186.68]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEB8513F846 for ; Tue, 24 Oct 2017 14:02:31 -0700 (PDT) Received: from mtaout-mae02.mx.aol.com (mtaout-mae02.mx.aol.com [172.26.254.142]) by omr-a017e.mx.aol.com (Outbound Mail Relay) with ESMTP id B311B3800091; Tue, 24 Oct 2017 17:02:30 -0400 (EDT) Received: from iMac.local (pool-173-48-69-73.bstnma.fios.verizon.net [173.48.69.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mtaout-mae02.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 285913800008F; Tue, 24 Oct 2017 17:02:29 -0400 (EDT) To: Daniel B Giffin Cc: secdir@ietf.org, david.black@dell.com, krose@krose.org, ietf@kuehlewind.net, M.Handley@cs.ucl.ac.uk, dm@uun.org, eric.smith@kestrel.edu, sqs@sourcegraph.com References: <20171021013702.GB85636@scs.stanford.edu> <88e80c7a-0534-5ff0-deeb-c0bc5f3c9a09@verizon.net> <20171024070759.GA61933@scs.stanford.edu> From: Stephen Kent Message-ID: <78cf97c4-daca-0ade-bf38-613622390c6c@verizon.net> Date: Tue, 24 Oct 2017 17:02:36 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20171024070759.GA61933@scs.stanford.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US x-aol-global-disposition: G x-aol-sid: 3039ac1afe8e59efaa656e45 X-AOL-IP: 173.48.69.73 Archived-At: Subject: Re: [secdir] SECDIR review of draft-ietf-t cpinc-tcpcrypt-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 21:02:39 -0000 Daniel, > If you could let us know what protocols you mean, that would > be a helpful point of comparison. It looks like the main > TLS 1.3 document specifies only five symmetric algorithms, > but of course other documents could supplement this > arbitrarily; I guess I should look at OpenSSL or something > to see how many are actually supported. My comments are based on my experiences with IPsec (ESP and AH). If you look at RFCs 4305, 4835,  and 7321, you see a set of algs that have been recommended, and ones that have been deprecated over many years. There are a fair number of them when one looks at the need to specify both an encryption alg and an integrity alg. We started with DEC-CBC and MD5, moved on to triple DES-CBC and several SHA-based MACs, then AES-CBC (in 3 key lengths) with SHA MACs, plus AES-GMAC (3 key lenghts) and AES-GCM (3 key lengths).  Don't forget outliers like SKIPKACK, RC4, RC5, Blowfiosh, Twofish, Threefish, CAST, and IDEA. One might add Salsa20, ChaCha, Poly1305-AES to the list of more recent options, if anyone wanted to register them. Note that even when we deprecate an alg it may live on for a long time in implementations. > Concerning "nation-specific algorithms", do you mean that > the number of needed symmetric-encryption algorithms could > be on the same order as the number of countries in the > world? not likely, but potentially, and I would not like to have IANA rejecting a national alg because of limited ID space. In the IPsec arena, we had SEED (South Korea), GOST symmetric crypto and MAC algs (Russia), and Camilla (Japan) all defined for use ion the IPsec environment. Nothing makes for a good international incident like having the IETF reject some country's request for an alg ID. > If there's a need to mention how the code-space for > symmetric ciphers could be expanded, maybe we should > seriously consider allocating 16 bits to this; I just don't > have a good handle on the order of magnitude that is > plausibly needed. I'd prefer 16 bits, just to be safe, based on the IPsec experiences and a strong desire to NEVER reuse IDs. Steve From nobody Tue Oct 24 15:48:56 2017 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 4184813A658; Tue, 24 Oct 2017 15:48:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Daniel Franke To: Cc: i2nsf@ietf.org, draft-ietf-i2nsf-framework.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150888532124.4802.13758793569414682089@ietfa.amsl.com> Date: Tue, 24 Oct 2017 15:48:41 -0700 Archived-At: Subject: [secdir] Secdir telechat review of draft-ietf-i2nsf-framework-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2017 22:48:41 -0000 Reviewer: Daniel Franke Review result: Not 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. This document is too broad and too vague for any reasonable security review to be possible. It expresses a desire to define a framework which satisfies certain requirements and use cases, but does not actually define anything concrete. At its most specific, the document gives parametricity constraints that future definitions must satisfy, such as being agnostic to network topology. This doesn't give me much to go on. The security considerations section is brief, calling out the need for access control and for protecting the confidentiality and integrity of data. Again, with so few specifics, there's not much more to be said. I do not think it is useful to anyone to publish this document as an RFC, not even an informational one. It is perfectly fine, when specifying an intricate suite of protocols, to have a separate document that gives a broad architectural overview of them all without delving into the specifics necessary for implementation. RFC 4251, which outlines the SSH protocol, is a good example of this. But, crucially, RFC 4251 was published simultaneously with 4252-4256, which provided all those specifics. This document has nothing similar as a companion; everything it describes is simply aspirational. I do not see any value in publishing an RFC full of unfulfilled aspirations. From nobody Tue Oct 24 19:32:12 2017 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 9917C13ACA2; Tue, 24 Oct 2017 19:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ElvLKRIwZ-L5; Tue, 24 Oct 2017 19:32:09 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 297CD13AC0E; Tue, 24 Oct 2017 19:32:06 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id a132so40672141oih.11; Tue, 24 Oct 2017 19:32:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=2sKqPxv28dUyygoLV9++iBytE9PM+yBhahD293JpqJI=; b=dJBQJUSzrsOiqSk9ni9us0HE0FR/lwu/FSE/ohjLRb5Z00/RUpIlaSFA0F3L1tVuEQ qlNt5A8ILM5azVfJBpQYI3dIg4J110RrDwvUG/X86f95Nlzmf/SsO9Op5T0gN5aB/h4K Bmpnl+3WWF+64J2pMsW8NnUnr4AaEbUI0iyPWFsY7MN5nI1wwXblFWFLx1G9gTKc1+Iz ++40CiU7edPhybdrc3uwnc73oakGAuwWCYXoysap5137kBiZidOXRTRkDKYum0mXO1kE GS1qmQlqwrNrOCstvjJwiIGjSfDhQMYfnybMvEOK8x47uORXt9EF5jKSN6aoY1vO0Ojq CULg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=2sKqPxv28dUyygoLV9++iBytE9PM+yBhahD293JpqJI=; b=j5IZOAUNvFbVGZSNx7Y4eB2OqemRWasG6huXUvMYsgkoeAyZ06KsAO+1eYBx6hiUGW aequm8kfhfx1mZqW8ut7JtS/3ZP3875SWiexJOyiCWHLestOXIIuOLzACttfXFLcJoTW D0mE7RKpVIugJmUpF2YDCtSs60sajFm0eV0clP4kiWT3USYTGeCcwyw5qq/iIuW67i0W N7XG+GTfiNXO3Jouz0APKE6qxCjw/mFwyI2moUuU0g9SPZsXd7V0mgK9oIg7Vg51sPF2 R63VFBYO5LChLs3L0EvKPAoqkZc+msRPwxf5cXQDr7iRGANCkXZSpEwrDlD5RsUrapm1 xuiQ== X-Gm-Message-State: AMCzsaUQwpFVlVJtk65EFXYGWYwf6HsivtyZErmHwesNTMNUV9bGg49U 0jpfiJ0AMUfBlNpkHzdjrA6xlt6oyyHr5yeBNR6FsatX X-Google-Smtp-Source: ABhQp+TLeo5gSn7F23wUvhjb12TnMEuwMnTYuMrbOBix8sVk9Qoln3ersBcdTfs46YTP15H9yQQFfCMzJZv3MqIdUNk= X-Received: by 10.202.72.75 with SMTP id v72mr359640oia.46.1508898725134; Tue, 24 Oct 2017 19:32:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.168.73.194 with HTTP; Tue, 24 Oct 2017 19:31:49 -0700 (PDT) From: Donald Eastlake Date: Tue, 24 Oct 2017 22:31:49 -0400 Message-ID: To: "iesg@ietf.org" , draft-ietf-oauth-discovery@ietf.org Cc: "secdir@ietf.org" Content-Type: multipart/alternative; boundary="001a113dc6a88385c9055c55dc7f" Archived-At: Subject: [secdir] SECDIR review of draft-ietf-oauth-discovery-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Oct 2017 02:32:10 -0000 --001a113dc6a88385c9055c55dc7f 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. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is draft is ready with one nit. This draft defines a metadata format that an OAuth 2.0 client can use to obtain the information needed to interact with an OAuth 2.0 authorization server, including its endpoint locations and authorization server capabilities. While I am not deeply familiar with this area of security technology, the extensive Security Considerations section seems thorough and correct as far as I can see. Nit: The reference to RFC 5226 should probably be updated to RFC 8126 Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 <(508)%20333-2270> (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com --001a113dc6a88385c9055c55dc7f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have reviewed this document as part of the security= directorate's ongoing effort to review all IETF documents being proces= sed by the IESG.=C2=A0 Document editors and WG chairs should treat these co= mments just like any other last call comments.=C2=A0

The summary of the review is draft is ready with one nit.

=
This draft defines a metadata format that an OAuth 2.0 client ca= n use to obtain the information needed to interact with an OAuth 2.0 author= ization server, including its endpoint locations and authorization server c= apabilities.

While I am not deeply familiar with t= his area of security technology, the extensive Security Considerations sect= ion seems thorough and correct as far as I can see.

Nit: The reference to RFC 5226 should probably be updated to RFC 8126

Thanks,
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
=C2=A0Donald E. Eastl= ake 3rd =C2=A0 +1-508-333-2270 (cell)
=C2=A0155 Beaver Street, Milfor= d, MA 01757 USA
=C2=A0d3e3e3@gmail.com
--001a113dc6a88385c9055c55dc7f-- From nobody Wed Oct 25 08:47:12 2017 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 5039813F406; Wed, 25 Oct 2017 08:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GvwBPiKq8dH6; Wed, 25 Oct 2017 08:47:08 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2759F13F3EE; Wed, 25 Oct 2017 08:47:07 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DYK95145; Wed, 25 Oct 2017 15:46:59 +0000 (GMT) Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 25 Oct 2017 16:46:58 +0100 Received: from SJCEML521-MBS.china.huawei.com ([169.254.2.92]) by SJCEML701-CHM.china.huawei.com ([169.254.3.104]) with mapi id 14.03.0361.001; Wed, 25 Oct 2017 08:46:53 -0700 From: Linda Dunbar To: Daniel Franke , "secdir@ietf.org" CC: "i2nsf@ietf.org" , "draft-ietf-i2nsf-framework.all@ietf.org" , "ietf@ietf.org" Thread-Topic: Secdir telechat review of draft-ietf-i2nsf-framework-08 Thread-Index: AQHTTRpBCbU9DO58mU+SEAnkR5GapKL0s9MQ Date: Wed, 25 Oct 2017 15:46:52 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F66AFC51C1@sjceml521-mbs.china.huawei.com> References: <150888532124.4802.13758793569414682089@ietfa.amsl.com> In-Reply-To: <150888532124.4802.13758793569414682089@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.78] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.59F0B1F8.0036, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.92, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: c4b6b41609fe2910d8d2a82d98c850a6 Archived-At: Subject: Re: [secdir] Secdir telechat review of draft-ietf-i2nsf-framework-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Oct 2017 15:47:10 -0000 RGFuaWVsLCANCg0KVGhhbmsgeW91IGZvciB5b3VyIHRpbWUgcmV2aWV3aW5nIHRoaXMgZG9jdW1l bnQuIE9idmlvdXNseSBvdXIgb3BpbmlvbnMgb24gdGhlIHZhbHVlIG9mIHB1YmxpY2F0aW9uIGFy ZSBkaWZmZXJlbnQgZnJvbSB0aGUgV0cgY29uc2Vuc3VzLiANClRoZSBkcmFmdC1pZXRmLWkybnNm LWZyYW1ld29yayBkZXNjcmliZXMgdGhlIGZyYW1ld29yayB0aGF0IGdsdWVzIHRvZ2V0aGVyIG11 bHRpcGxlIGRldGFpbGVkIGRyYWZ0cyBkZXNjcmliaW5nIGRpZmZlcmVudCBhc3BlY3RzIG9mIElu dGVyZmFjZSB0byBOZXR3b3JrIFNlY3VyaXR5IGZ1bmN0aW9ucywgc3VjaCBhcyAgIGRyYWZ0LWll dGYtaTJuc2YtY2FwYWJpbGl0eS0wMCwgCQ0KZHJhZnQtYWJhZC1pMm5zZi1zZG4taXBzZWMtZmxv dy1wcm90ZWN0aW9uLTAzLCBkcmFmdC1oYXJlcy1pMm5zZi1jYXBhYmlsaXR5LWRhdGEtbW9kZWwt MDQsIGRyYWZ0LWtpbS1pMm5zZi1uc2YtZmFjaW5nLWludGVyZmFjZS1kYXRhLW1vZGVsLTAzLCBl dGMuIA0KDQpJbiBhZGRpdGlvbiwgc2V2ZXJhbCByZWNlbnQgaW5kdXN0cnkgaW5pdGlhdGl2ZXMg YXJlIHJlZmVyZW5jaW5nIEkyTlNGIHRvIGd1aWRlIHRoZWlyIG5leHQgc3RlcCB3b3JrLiBTdWNo IGFzIE9OVUcgKE9wZW4gTmV0d29yayBVc2VyIEdyb3VwKSBTb2Z0d2FyZSBEZWZpbmVkIFNlY3Vy aXR5IFNlcnZpY2VzIGFuZCBMaW51eCBGb3VuZGF0aW9u4oCZcyBPU0MgKE9wZW4gU2VjdXJpdHkg Q29udHJvbGxlcikuICBUaGlzIGlzIG9uZSBleGFtcGxlIHRoYXQgSUVURiBpcyBsZWFkaW5nIHRo ZSBpbmR1c3RyeS4NCldpdGhvdXQgcHVibGlzaGluZyBkcmFmdC1pZXRmLWkybnNmLWZyYW1ld29y aywgaXQgaXMgbm90IGVhc3kgZm9yIHRoZSBpbmR1c3RyeSBvdGhlciBpbml0aWF0aXZlcyB0byB1 dGlsaXplIHRoZSBzcGVjaWZpY2F0aW9ucyAoaW4gbWFueSBwaWVjZXMpIHB1Ymxpc2hlZCBieSBJ RVRGLiANCg0KTGluZGEgRHVuYmFyDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy b206IERhbmllbCBGcmFua2UgW21haWx0bzpkYWZyYW5rZUBha2FtYWkuY29tXSANClNlbnQ6IFR1 ZXNkYXksIE9jdG9iZXIgMjQsIDIwMTcgNTo0OSBQTQ0KVG86IHNlY2RpckBpZXRmLm9yZw0KQ2M6 IGkybnNmQGlldGYub3JnOyBkcmFmdC1pZXRmLWkybnNmLWZyYW1ld29yay5hbGxAaWV0Zi5vcmc7 IGlldGZAaWV0Zi5vcmcNClN1YmplY3Q6IFNlY2RpciB0ZWxlY2hhdCByZXZpZXcgb2YgZHJhZnQt aWV0Zi1pMm5zZi1mcmFtZXdvcmstMDgNCg0KUmV2aWV3ZXI6IERhbmllbCBGcmFua2UNClJldmll dyByZXN1bHQ6IE5vdCBSZWFkeQ0KDQpJIGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhcyBw YXJ0IG9mIHRoZSBzZWN1cml0eSBkaXJlY3RvcmF0ZSdzIG9uZ29pbmcgZWZmb3J0IHRvIHJldmll dyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkIGJ5IHRoZSBJRVNHLiBUaGVzZSBj b21tZW50cyB3ZXJlIHdyaXR0ZW4gcHJpbWFyaWx5IGZvciB0aGUgYmVuZWZpdCBvZiB0aGUgc2Vj dXJpdHkgYXJlYSBkaXJlY3RvcnMuIERvY3VtZW50IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBzaG91 bGQgdHJlYXQgdGhlc2UgY29tbWVudHMganVzdCBsaWtlIGFueSBvdGhlciBsYXN0IGNhbGwgY29t bWVudHMuDQoNClRoaXMgZG9jdW1lbnQgaXMgdG9vIGJyb2FkIGFuZCB0b28gdmFndWUgZm9yIGFu eSByZWFzb25hYmxlIHNlY3VyaXR5IHJldmlldyB0byBiZSBwb3NzaWJsZS4gSXQgZXhwcmVzc2Vz IGEgZGVzaXJlIHRvIGRlZmluZSBhIGZyYW1ld29yayB3aGljaCBzYXRpc2ZpZXMgY2VydGFpbiBy ZXF1aXJlbWVudHMgYW5kIHVzZSBjYXNlcywgYnV0IGRvZXMgbm90IGFjdHVhbGx5IGRlZmluZSBh bnl0aGluZyBjb25jcmV0ZS4gQXQgaXRzIG1vc3Qgc3BlY2lmaWMsIHRoZSBkb2N1bWVudCBnaXZl cyBwYXJhbWV0cmljaXR5IGNvbnN0cmFpbnRzIHRoYXQgZnV0dXJlIGRlZmluaXRpb25zIG11c3Qg c2F0aXNmeSwgc3VjaCBhcyBiZWluZyBhZ25vc3RpYyB0byBuZXR3b3JrIHRvcG9sb2d5LiBUaGlz IGRvZXNuJ3QgZ2l2ZSBtZSBtdWNoIHRvIGdvIG9uLg0KDQpUaGUgc2VjdXJpdHkgY29uc2lkZXJh dGlvbnMgc2VjdGlvbiBpcyBicmllZiwgY2FsbGluZyBvdXQgdGhlIG5lZWQgZm9yIGFjY2VzcyBj b250cm9sIGFuZCBmb3IgcHJvdGVjdGluZyB0aGUgY29uZmlkZW50aWFsaXR5IGFuZCBpbnRlZ3Jp dHkgb2YgZGF0YS4gQWdhaW4sIHdpdGggc28gZmV3IHNwZWNpZmljcywgdGhlcmUncyBub3QgbXVj aCBtb3JlIHRvIGJlIHNhaWQuDQoNCkkgZG8gbm90IHRoaW5rIGl0IGlzIHVzZWZ1bCB0byBhbnlv bmUgdG8gcHVibGlzaCB0aGlzIGRvY3VtZW50IGFzIGFuIFJGQywgbm90IGV2ZW4gYW4gaW5mb3Jt YXRpb25hbCBvbmUuIEl0IGlzIHBlcmZlY3RseSBmaW5lLCB3aGVuIHNwZWNpZnlpbmcgYW4gaW50 cmljYXRlIHN1aXRlIG9mIHByb3RvY29scywgdG8gaGF2ZSBhIHNlcGFyYXRlIGRvY3VtZW50IHRo YXQgZ2l2ZXMgYSBicm9hZCBhcmNoaXRlY3R1cmFsIG92ZXJ2aWV3IG9mIHRoZW0gYWxsIHdpdGhv dXQgZGVsdmluZyBpbnRvIHRoZSBzcGVjaWZpY3MgbmVjZXNzYXJ5IGZvciBpbXBsZW1lbnRhdGlv bi4gUkZDIDQyNTEsIHdoaWNoIG91dGxpbmVzIHRoZSBTU0ggcHJvdG9jb2wsIGlzIGEgZ29vZCBl eGFtcGxlIG9mIHRoaXMuIEJ1dCwgY3J1Y2lhbGx5LCBSRkMgNDI1MSB3YXMgcHVibGlzaGVkIHNp bXVsdGFuZW91c2x5IHdpdGggNDI1Mi00MjU2LCB3aGljaCBwcm92aWRlZCBhbGwgdGhvc2Ugc3Bl Y2lmaWNzLiBUaGlzIGRvY3VtZW50IGhhcyBub3RoaW5nIHNpbWlsYXIgYXMgYSBjb21wYW5pb247 IGV2ZXJ5dGhpbmcgaXQgZGVzY3JpYmVzIGlzIHNpbXBseSBhc3BpcmF0aW9uYWwuIEkgZG8gbm90 IHNlZSBhbnkgdmFsdWUgaW4gcHVibGlzaGluZyBhbiBSRkMgZnVsbCBvZiB1bmZ1bGZpbGxlZCBh c3BpcmF0aW9ucy4NCg0K From nobody Wed Oct 25 08:48:10 2017 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 46F1913F406; Wed, 25 Oct 2017 08:48:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xD02dxeD4f8n; Wed, 25 Oct 2017 08:48:02 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6847C13F408; Wed, 25 Oct 2017 08:48:00 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DRI00155; Wed, 25 Oct 2017 15:47:57 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 25 Oct 2017 16:47:56 +0100 Received: from SJCEML521-MBS.china.huawei.com ([169.254.2.92]) by SJCEML703-CHM.china.huawei.com ([169.254.5.27]) with mapi id 14.03.0361.001; Wed, 25 Oct 2017 08:47:49 -0700 From: Linda Dunbar To: Daniel Franke , "secdir@ietf.org" CC: "i2nsf@ietf.org" , "draft-ietf-i2nsf-framework.all@ietf.org" , "ietf@ietf.org" Thread-Topic: Secdir telechat review of draft-ietf-i2nsf-framework-08 Thread-Index: AdNNqJuoCbU9DO58mU+SEAnkR5GapA== X-CallingTelephoneNumber: IPM.Note X-VoiceMessageDuration: 1 X-FaxNumberOfPages: 0 Date: Wed, 25 Oct 2017 15:47:48 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F66AFC51D4@sjceml521-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.78] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.59F0B22E.01DF, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.92, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 1aa0de1d3dbc57b59f3e7e0ea0b11447 Archived-At: Subject: [secdir] Recall: Secdir telechat review of draft-ietf-i2nsf-framework-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Oct 2017 15:48:03 -0000 Linda Dunbar would like to recall the message, "Secdir telechat review of d= raft-ietf-i2nsf-framework-08".= From nobody Wed Oct 25 08:49:12 2017 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 076C513DC3B; Wed, 25 Oct 2017 08:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NHUm1Y8WMTdN; Wed, 25 Oct 2017 08:49:08 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C1DE13DA67; Wed, 25 Oct 2017 08:49:06 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DRI00165; Wed, 25 Oct 2017 15:48:02 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 25 Oct 2017 16:48:01 +0100 Received: from SJCEML521-MBS.china.huawei.com ([169.254.2.92]) by SJCEML702-CHM.china.huawei.com ([169.254.4.145]) with mapi id 14.03.0361.001; Wed, 25 Oct 2017 08:47:57 -0700 From: Linda Dunbar To: Daniel Franke , "secdir@ietf.org" CC: "i2nsf@ietf.org" , "draft-ietf-i2nsf-framework.all@ietf.org" , "ietf@ietf.org" Thread-Topic: Secdir telechat review of draft-ietf-i2nsf-framework-08 Thread-Index: AQHTTRpBCbU9DO58mU+SEAnkR5GapKL0s9MQ Date: Wed, 25 Oct 2017 15:47:56 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F66AFC51D9@sjceml521-mbs.china.huawei.com> References: <150888532124.4802.13758793569414682089@ietfa.amsl.com> In-Reply-To: <150888532124.4802.13758793569414682089@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.78] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.59F0B234.0152, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.92, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 4bc3ac0ae64270b098b25bb9fa3e2935 Archived-At: Subject: Re: [secdir] Secdir telechat review of draft-ietf-i2nsf-framework-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Oct 2017 15:49:10 -0000 RGFuaWVsLCANCg0KVGhhbmsgeW91IGZvciB5b3VyIHRpbWUgcmV2aWV3aW5nIHRoaXMgZG9jdW1l bnQuIE9idmlvdXNseSB5b3Ugb3BpbmlvbnMgb24gdGhlIHZhbHVlIG9mIHB1YmxpY2F0aW9uIGFy ZSBkaWZmZXJlbnQgZnJvbSB0aGUgV0cgY29uc2Vuc3VzLiANClRoZSBkcmFmdC1pZXRmLWkybnNm LWZyYW1ld29yayBkZXNjcmliZXMgdGhlIGZyYW1ld29yayB0aGF0IGdsdWVzIHRvZ2V0aGVyIG11 bHRpcGxlIGRldGFpbGVkIGRyYWZ0cyBkZXNjcmliaW5nIGRpZmZlcmVudCBhc3BlY3RzIG9mIElu dGVyZmFjZSB0byBOZXR3b3JrIFNlY3VyaXR5IGZ1bmN0aW9ucywgc3VjaCBhcyAgIGRyYWZ0LWll dGYtaTJuc2YtY2FwYWJpbGl0eS0wMCwgCQ0KZHJhZnQtYWJhZC1pMm5zZi1zZG4taXBzZWMtZmxv dy1wcm90ZWN0aW9uLTAzLCBkcmFmdC1oYXJlcy1pMm5zZi1jYXBhYmlsaXR5LWRhdGEtbW9kZWwt MDQsIGRyYWZ0LWtpbS1pMm5zZi1uc2YtZmFjaW5nLWludGVyZmFjZS1kYXRhLW1vZGVsLTAzLCBl dGMuIA0KDQpJbiBhZGRpdGlvbiwgc2V2ZXJhbCByZWNlbnQgaW5kdXN0cnkgaW5pdGlhdGl2ZXMg YXJlIHJlZmVyZW5jaW5nIEkyTlNGIHRvIGd1aWRlIHRoZWlyIG5leHQgc3RlcCB3b3JrLiBTdWNo IGFzIE9OVUcgKE9wZW4gTmV0d29yayBVc2VyIEdyb3VwKSBTb2Z0d2FyZSBEZWZpbmVkIFNlY3Vy aXR5IFNlcnZpY2VzIGFuZCBMaW51eCBGb3VuZGF0aW9u4oCZcyBPU0MgKE9wZW4gU2VjdXJpdHkg Q29udHJvbGxlcikuICBUaGlzIGlzIG9uZSBleGFtcGxlIHRoYXQgSUVURiBpcyBsZWFkaW5nIHRo ZSBpbmR1c3RyeS4NCldpdGhvdXQgcHVibGlzaGluZyBkcmFmdC1pZXRmLWkybnNmLWZyYW1ld29y aywgaXQgaXMgbm90IGVhc3kgZm9yIHRoZSBpbmR1c3RyeSBvdGhlciBpbml0aWF0aXZlcyB0byB1 dGlsaXplIHRoZSBzcGVjaWZpY2F0aW9ucyAoaW4gbWFueSBwaWVjZXMpIHB1Ymxpc2hlZCBieSBJ RVRGLiANCg0KTGluZGEgRHVuYmFyDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy b206IERhbmllbCBGcmFua2UgW21haWx0bzpkYWZyYW5rZUBha2FtYWkuY29tXSANClNlbnQ6IFR1 ZXNkYXksIE9jdG9iZXIgMjQsIDIwMTcgNTo0OSBQTQ0KVG86IHNlY2RpckBpZXRmLm9yZw0KQ2M6 IGkybnNmQGlldGYub3JnOyBkcmFmdC1pZXRmLWkybnNmLWZyYW1ld29yay5hbGxAaWV0Zi5vcmc7 IGlldGZAaWV0Zi5vcmcNClN1YmplY3Q6IFNlY2RpciB0ZWxlY2hhdCByZXZpZXcgb2YgZHJhZnQt aWV0Zi1pMm5zZi1mcmFtZXdvcmstMDgNCg0KUmV2aWV3ZXI6IERhbmllbCBGcmFua2UNClJldmll dyByZXN1bHQ6IE5vdCBSZWFkeQ0KDQpJIGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhcyBw YXJ0IG9mIHRoZSBzZWN1cml0eSBkaXJlY3RvcmF0ZSdzIG9uZ29pbmcgZWZmb3J0IHRvIHJldmll dyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkIGJ5IHRoZSBJRVNHLiBUaGVzZSBj b21tZW50cyB3ZXJlIHdyaXR0ZW4gcHJpbWFyaWx5IGZvciB0aGUgYmVuZWZpdCBvZiB0aGUgc2Vj dXJpdHkgYXJlYSBkaXJlY3RvcnMuIERvY3VtZW50IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBzaG91 bGQgdHJlYXQgdGhlc2UgY29tbWVudHMganVzdCBsaWtlIGFueSBvdGhlciBsYXN0IGNhbGwgY29t bWVudHMuDQoNClRoaXMgZG9jdW1lbnQgaXMgdG9vIGJyb2FkIGFuZCB0b28gdmFndWUgZm9yIGFu eSByZWFzb25hYmxlIHNlY3VyaXR5IHJldmlldyB0byBiZSBwb3NzaWJsZS4gSXQgZXhwcmVzc2Vz IGEgZGVzaXJlIHRvIGRlZmluZSBhIGZyYW1ld29yayB3aGljaCBzYXRpc2ZpZXMgY2VydGFpbiBy ZXF1aXJlbWVudHMgYW5kIHVzZSBjYXNlcywgYnV0IGRvZXMgbm90IGFjdHVhbGx5IGRlZmluZSBh bnl0aGluZyBjb25jcmV0ZS4gQXQgaXRzIG1vc3Qgc3BlY2lmaWMsIHRoZSBkb2N1bWVudCBnaXZl cyBwYXJhbWV0cmljaXR5IGNvbnN0cmFpbnRzIHRoYXQgZnV0dXJlIGRlZmluaXRpb25zIG11c3Qg c2F0aXNmeSwgc3VjaCBhcyBiZWluZyBhZ25vc3RpYyB0byBuZXR3b3JrIHRvcG9sb2d5LiBUaGlz IGRvZXNuJ3QgZ2l2ZSBtZSBtdWNoIHRvIGdvIG9uLg0KDQpUaGUgc2VjdXJpdHkgY29uc2lkZXJh dGlvbnMgc2VjdGlvbiBpcyBicmllZiwgY2FsbGluZyBvdXQgdGhlIG5lZWQgZm9yIGFjY2VzcyBj b250cm9sIGFuZCBmb3IgcHJvdGVjdGluZyB0aGUgY29uZmlkZW50aWFsaXR5IGFuZCBpbnRlZ3Jp dHkgb2YgZGF0YS4gQWdhaW4sIHdpdGggc28gZmV3IHNwZWNpZmljcywgdGhlcmUncyBub3QgbXVj aCBtb3JlIHRvIGJlIHNhaWQuDQoNCkkgZG8gbm90IHRoaW5rIGl0IGlzIHVzZWZ1bCB0byBhbnlv bmUgdG8gcHVibGlzaCB0aGlzIGRvY3VtZW50IGFzIGFuIFJGQywgbm90IGV2ZW4gYW4gaW5mb3Jt YXRpb25hbCBvbmUuIEl0IGlzIHBlcmZlY3RseSBmaW5lLCB3aGVuIHNwZWNpZnlpbmcgYW4gaW50 cmljYXRlIHN1aXRlIG9mIHByb3RvY29scywgdG8gaGF2ZSBhIHNlcGFyYXRlIGRvY3VtZW50IHRo YXQgZ2l2ZXMgYSBicm9hZCBhcmNoaXRlY3R1cmFsIG92ZXJ2aWV3IG9mIHRoZW0gYWxsIHdpdGhv dXQgZGVsdmluZyBpbnRvIHRoZSBzcGVjaWZpY3MgbmVjZXNzYXJ5IGZvciBpbXBsZW1lbnRhdGlv bi4gUkZDIDQyNTEsIHdoaWNoIG91dGxpbmVzIHRoZSBTU0ggcHJvdG9jb2wsIGlzIGEgZ29vZCBl eGFtcGxlIG9mIHRoaXMuIEJ1dCwgY3J1Y2lhbGx5LCBSRkMgNDI1MSB3YXMgcHVibGlzaGVkIHNp bXVsdGFuZW91c2x5IHdpdGggNDI1Mi00MjU2LCB3aGljaCBwcm92aWRlZCBhbGwgdGhvc2Ugc3Bl Y2lmaWNzLiBUaGlzIGRvY3VtZW50IGhhcyBub3RoaW5nIHNpbWlsYXIgYXMgYSBjb21wYW5pb247 IGV2ZXJ5dGhpbmcgaXQgZGVzY3JpYmVzIGlzIHNpbXBseSBhc3BpcmF0aW9uYWwuIEkgZG8gbm90 IHNlZSBhbnkgdmFsdWUgaW4gcHVibGlzaGluZyBhbiBSRkMgZnVsbCBvZiB1bmZ1bGZpbGxlZCBh c3BpcmF0aW9ucy4NCg0K From nobody Wed Oct 25 09:33:11 2017 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 D1C4213F419; Wed, 25 Oct 2017 09:32:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk To: Cc: draft-ietf-lime-yang-connectionless-oam-methods.all@ietf.org, lime@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150894917478.4886.16418816851585609070@ietfa.amsl.com> Date: Wed, 25 Oct 2017 09:32:54 -0700 Archived-At: Subject: [secdir] Secdir telechat review of draft-ietf-lime-yang-connectionless-oam-methods-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Oct 2017 16:32:55 -0000 Reviewer: Benjamin Kaduk Review result: Ready This draft is basically providing a YANG model as an abstraction over existing (connectionless OAM) functionality, perhaps with some intention of facilitating similar functionality in new spaces. (E.g., ICMP ping/traceroute exist, but entries are also given for SFC, MPLS, MPLS-TP, TWAMP, BIER, and I do not expect that all of those currently have such functionality.). The modeled functionality is intended to be run over management protocols such as NETCONF or RESTCONF (i.e., ssh or HTTPS), which are at least nominally secure transports. Though it is possible to configure either of them in an insecure fashion, I don't feel a particular need to beat the reader over the head with notes about actually verifying TLS certificates, etc.. The security considerations duly mention that access control is appropriate and that some operations may be considered sensitive or vulnerable in some environments, which is true, and probably the most that can reasonably be said at this level of abstraction. I do see several appearances of an abstract "location-type" field and other system identifiers ("identityref", "system-id", MAC/IPv4/IPv6 addresses), which are sometimes considered sensitive, especially when they can be associated back to individual users, which leads to privacy considerations about user tracking and similar. Since this is OAM work, I don't actually know that there are real users in scope as opposed to fixed infrastructure, but perhaps a statement in the security considerations about privacy and this sort of identifiers would still be useful. The document could benefit from some general copy editing for language/grammar/etc., but unfortunately given the short turnaround between last call end and the telechat, I cannot provide a more detailed patch or comments at the present time. From nobody Wed Oct 25 18:50:17 2017 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 4E5DD139D0B; Wed, 25 Oct 2017 18:50:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.322 X-Spam-Level: X-Spam-Status: No, score=-2.322 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NGvrN3uBvHYq; Wed, 25 Oct 2017 18:50:09 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (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 E6B0A139689; Wed, 25 Oct 2017 18:50:08 -0700 (PDT) X-AuditID: 1209190e-5e7ff70000006402-b4-59f13f4f1260 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 02.E8.25602.F4F31F95; Wed, 25 Oct 2017 21:50:07 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id v9Q1o6nm001702; Wed, 25 Oct 2017 21:50:06 -0400 Received: from localhost (nyc-02.triskelion.com [162.243.175.178]) (authenticated bits=0) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v9Q1o40o002237; Wed, 25 Oct 2017 21:50:05 -0400 From: Taylor Yu To: iesg@ietf.org, secdir@ietf.org, draft-ietf-ippm-alt-mark.all@ietf.org Date: Thu, 26 Oct 2017 01:50:04 +0000 Message-ID: Lines: 31 MIME-Version: 1.0 Content-Type: text/plain X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrKIsWRmVeSWpSXmKPExsUixCmqrOtv/zHS4NNFVYtZtxvZLWb8mchs 8WHhQxYHZo8lS34yBTBGcdmkpOZklqUW6dslcGWcPHyYreAUV8XVn0dZGxiPcnQxcnJICJhI zH65lA3EFhJYzCQxe4ZeFyMXkL2RUeLbhBXMEIlvjBLPtxR2MXJwsAnISVy+FQwSFhHwlHix /DUrSFhYwFTi9IQUkDCLgKrE9v0LGEFsXgEbibaZ31lAbB4BTolDPSuh4oISJ2c+AYszC0hI HHzxgnkCI88sJKlZSFILGJlWMcqm5Fbp5iZm5hSnJusWJyfm5aUW6Rrr5WaW6KWmlG5iBIeK JN8OxkkN3ocYBTgYlXh4P3z8ECnEmlhWXJl7iFGSg0lJlJdhD1CILyk/pTIjsTgjvqg0J7X4 EKMEB7OSCO9snY+RQrwpiZVVqUX5MClpDhYlcd5tQbsihQTSE0tSs1NTC1KLYLIyHBxKErxv bIEaBYtS01Mr0jJzShDSTBycIMN5gIbz2YEMLy5IzC3OTIfIn2K05Nh08+4fJo4N3x8AyWcz XzcwC7Hk5eelSonz7gcZKgDSkFGaBzcTFPuLPq/f9IpRHOhFYV5ekLE8wLQBN/UV0EImoIVN qh9AFpYkIqSkGhgnbLXmKPWfFSn2S07eI7L8/Xf+UxPTz+X2hWnnvr37ccHqfVt2zbdnTXz9 3NVi1uSIrul1DhcvXjlw6HrpySuL18ZMmaC/bxEvg0l66/1VbCe/72Arfd9uIeKQ8nDL2ncy zdW5/Pf3vnh/5N3/juDS19M3bNQ/blO6QYp55o9lhnscne6zJ6jOUmIpzkg01GIuKk4EAC2p DAvYAgAA Archived-At: Subject: [secdir] secdir review of draft-ietf-ippm-alt-mark-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 01:50:10 -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. The summary of the review is Ready. The Security Considerations section seems reasonable. I mostly agree that "The privacy concerns of network measurement are limited because the method only relies on information contained in the IP header without any release of user data." I would add that although information in the IP header is metadata that can be used to compromise the privacy of users, the limited marking technique in this document seems unlikely to substantially increase the existing privacy risks from IP header metadata. I also think it's reasonable to consider this detail to be already addressed by the wording "privacy concerns... are limited". It might be theoretically possible to modulate the marking to serve as a covert channel, but I think it would have a very low data rate if it is to avoid adversely affecting the measurement systems that monitor the marking. It's probably not worth mentioning this possibility in the document. Best regards, -Taylor From nobody Wed Oct 25 20:56:46 2017 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 89B47138BE2; Wed, 25 Oct 2017 20:56:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5qjKJOl6B4Bo; Wed, 25 Oct 2017 20:56:42 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88C8F137C4A; Wed, 25 Oct 2017 20:56:41 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DYL41846; Thu, 26 Oct 2017 03:56:39 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 26 Oct 2017 04:56:39 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.105]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Thu, 26 Oct 2017 11:56:31 +0800 From: Qin Wu To: Benjamin Kaduk , "secdir@ietf.org" CC: "draft-ietf-lime-yang-connectionless-oam-methods.all@ietf.org" , "lime@ietf.org" , "ietf@ietf.org" Thread-Topic: Secdir telechat review of draft-ietf-lime-yang-connectionless-oam-methods-11 Thread-Index: AQHTTa7ue9H/pHu33EWTnbCYvsyLpKL1f3iQ Date: Thu, 26 Oct 2017 03:56:31 +0000 Message-ID: References: <150894917478.4886.16418816851585609070@ietfa.amsl.com> In-Reply-To: <150894917478.4886.16418816851585609070@ietfa.amsl.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.79.163] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A010204.59F15CF8.0009, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.105, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 07da40cb0dfac61a35c5822d87060466 Archived-At: Subject: Re: [secdir] Secdir telechat review of draft-ietf-lime-yang-connectionless-oam-methods-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 03:56:44 -0000 VGhhbmtzIEJlbmphbWluIGZvciB2YWx1YWJsZSByZXZpZXcuDQpUaGlzIGRyYWZ0IGlzIHVwZGF0 ZWQgYmFzZWQgb24gWUFORyBzZWN1cml0eSBndWlkZWxpbmU6DQpodHRwczovL3RyYWMuaWV0Zi5v cmcvdHJhYy9vcHMvd2lraS95YW5nLXNlY3VyaXR5LWd1aWRlbGluZXMNClByaXZhY3kgaXNzdWUg aGFzIGJlZW4gY29uc2lkZXJlZCBpbiBzZWN1cml0eSBzZWN0aW9uIHNpbmNlICJsb2NhdGlvbi10 eXBlIiBhbmQgb3RoZXIgc3lzdGVtIGlkZW50aWZpZXJzIGFyZSBkZWZpbmVkIHdpdGhpbiB0d28g UlBDIG9wZXJhdGlvbnMuDQpSZWdhcmRpbmcgY29weSBlZGl0aW5nIGZvciBsYW5ndWFnZS9ncmFt bWFyIGlzc3VlLCB5ZXMsIG1hbnkgb3RoZXIgcmFpc2VkIHNpbWlsYXIgaXNzdWUgYXMgeW91IHNh aWQsIHdlIHdpbGwgZml4IHRob3NlIHR5cG8gYW5kIGZvcm1hdCBpc3N1ZSBpbiB0aGUgdXBkYXRl LiANClRoYW5rcyBhIGxvdC4NCg0KLVFpbg0KLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K5Y+R5Lu2 5Lq6OiBCZW5qYW1pbiBLYWR1ayBbbWFpbHRvOmthZHVrQG1pdC5lZHVdIA0K5Y+R6YCB5pe26Ze0 OiAyMDE35bm0MTDmnIgyNuaXpSAwOjMzDQrmlLbku7bkuro6IHNlY2RpckBpZXRmLm9yZw0K5oqE 6YCBOiBkcmFmdC1pZXRmLWxpbWUteWFuZy1jb25uZWN0aW9ubGVzcy1vYW0tbWV0aG9kcy5hbGxA aWV0Zi5vcmc7IGxpbWVAaWV0Zi5vcmc7IGlldGZAaWV0Zi5vcmcNCuS4u+mimDogU2VjZGlyIHRl bGVjaGF0IHJldmlldyBvZiBkcmFmdC1pZXRmLWxpbWUteWFuZy1jb25uZWN0aW9ubGVzcy1vYW0t bWV0aG9kcy0xMQ0KDQpSZXZpZXdlcjogQmVuamFtaW4gS2FkdWsNClJldmlldyByZXN1bHQ6IFJl YWR5DQoNClRoaXMgZHJhZnQgaXMgYmFzaWNhbGx5IHByb3ZpZGluZyBhIFlBTkcgbW9kZWwgYXMg YW4gYWJzdHJhY3Rpb24gb3ZlciBleGlzdGluZyAoY29ubmVjdGlvbmxlc3MgT0FNKSBmdW5jdGlv bmFsaXR5LCBwZXJoYXBzIHdpdGggc29tZSBpbnRlbnRpb24gb2YgZmFjaWxpdGF0aW5nIHNpbWls YXIgZnVuY3Rpb25hbGl0eSBpbiBuZXcgc3BhY2VzLiAgKEUuZy4sIElDTVAgcGluZy90cmFjZXJv dXRlIGV4aXN0LCBidXQgZW50cmllcyBhcmUgYWxzbyBnaXZlbiBmb3IgU0ZDLCBNUExTLCBNUExT LVRQLCBUV0FNUCwgQklFUiwgYW5kIEkgZG8gbm90IGV4cGVjdCB0aGF0IGFsbCBvZiB0aG9zZSBj dXJyZW50bHkgaGF2ZSBzdWNoIGZ1bmN0aW9uYWxpdHkuKS4NCg0KVGhlIG1vZGVsZWQgZnVuY3Rp b25hbGl0eSBpcyBpbnRlbmRlZCB0byBiZSBydW4gb3ZlciBtYW5hZ2VtZW50IHByb3RvY29scyBz dWNoIGFzIE5FVENPTkYgb3IgUkVTVENPTkYgKGkuZS4sIHNzaCBvciBIVFRQUyksIHdoaWNoIGFy ZSBhdCBsZWFzdCBub21pbmFsbHkgc2VjdXJlIHRyYW5zcG9ydHMuICBUaG91Z2ggaXQgaXMgcG9z c2libGUgdG8gY29uZmlndXJlIGVpdGhlciBvZiB0aGVtIGluIGFuIGluc2VjdXJlIGZhc2hpb24s IEkgZG9uJ3QgZmVlbCBhIHBhcnRpY3VsYXIgbmVlZCB0byBiZWF0IHRoZSByZWFkZXIgb3ZlciB0 aGUgaGVhZCB3aXRoIG5vdGVzIGFib3V0IGFjdHVhbGx5IHZlcmlmeWluZyBUTFMgY2VydGlmaWNh dGVzLCBldGMuLiAgVGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGR1bHkgbWVudGlvbiB0aGF0 IGFjY2VzcyBjb250cm9sIGlzIGFwcHJvcHJpYXRlIGFuZCB0aGF0IHNvbWUgb3BlcmF0aW9ucyBt YXkgYmUgY29uc2lkZXJlZCBzZW5zaXRpdmUgb3IgdnVsbmVyYWJsZSBpbiBzb21lIGVudmlyb25t ZW50cywgd2hpY2ggaXMgdHJ1ZSwgYW5kIHByb2JhYmx5IHRoZSBtb3N0IHRoYXQgY2FuIHJlYXNv bmFibHkgYmUgc2FpZCBhdCB0aGlzIGxldmVsIG9mIGFic3RyYWN0aW9uLg0KDQpJIGRvIHNlZSBz ZXZlcmFsIGFwcGVhcmFuY2VzIG9mIGFuIGFic3RyYWN0ICJsb2NhdGlvbi10eXBlIiBmaWVsZCBh bmQgb3RoZXIgc3lzdGVtIGlkZW50aWZpZXJzICgiaWRlbnRpdHlyZWYiLCAic3lzdGVtLWlkIiwg TUFDL0lQdjQvSVB2NiBhZGRyZXNzZXMpLCB3aGljaCAgYXJlIHNvbWV0aW1lcyBjb25zaWRlcmVk IHNlbnNpdGl2ZSwgZXNwZWNpYWxseSB3aGVuIHRoZXkgY2FuIGJlIGFzc29jaWF0ZWQgYmFjayB0 byBpbmRpdmlkdWFsIHVzZXJzLCB3aGljaCBsZWFkcyB0byBwcml2YWN5IGNvbnNpZGVyYXRpb25z IGFib3V0IHVzZXIgdHJhY2tpbmcgYW5kIHNpbWlsYXIuICBTaW5jZSB0aGlzIGlzIE9BTSB3b3Jr LCBJIGRvbid0IGFjdHVhbGx5IGtub3cgdGhhdCB0aGVyZSBhcmUgcmVhbCB1c2VycyBpbiBzY29w ZSBhcyBvcHBvc2VkIHRvIGZpeGVkIGluZnJhc3RydWN0dXJlLCBidXQgcGVyaGFwcyBhIHN0YXRl bWVudCBpbiB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgYWJvdXQgcHJpdmFjeSBhbmQgdGhp cyBzb3J0IG9mIGlkZW50aWZpZXJzIHdvdWxkIHN0aWxsIGJlIHVzZWZ1bC4NCg0KVGhlIGRvY3Vt ZW50IGNvdWxkIGJlbmVmaXQgZnJvbSBzb21lIGdlbmVyYWwgY29weSBlZGl0aW5nIGZvciBsYW5n dWFnZS9ncmFtbWFyL2V0Yy4sIGJ1dCB1bmZvcnR1bmF0ZWx5IGdpdmVuIHRoZSBzaG9ydCB0dXJu YXJvdW5kIGJldHdlZW4gbGFzdCBjYWxsIGVuZCBhbmQgdGhlIHRlbGVjaGF0LCBJIGNhbm5vdCBw cm92aWRlIGEgbW9yZSBkZXRhaWxlZCBwYXRjaCBvciBjb21tZW50cyBhdCB0aGUgcHJlc2VudCB0 aW1lLg0KDQo= From nobody Thu Oct 26 02:14:25 2017 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 CB82E13F4F4; Thu, 26 Oct 2017 02:14:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0nrP2_9o8zdn; Thu, 26 Oct 2017 02:14:17 -0700 (PDT) Received: from mx02.telecomitalia.it (mx02.telecomitalia.it [217.169.121.22]) (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 81E9613AB12; Thu, 26 Oct 2017 02:14:16 -0700 (PDT) X-AuditID: d9a97916-059ff7000000b3a3-ec-59f1a766d46a Received: from TELMBXB02RM001.telecomitalia.local ( [10.14.252.27]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by mx02.telecomitalia.it () with SMTP id B9.BD.45987.667A1F95; Thu, 26 Oct 2017 11:14:14 +0200 (CEST) From: Fioccola Giuseppe To: Taylor Yu , "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-ippm-alt-mark.all@ietf.org" Thread-Topic: secdir review of draft-ietf-ippm-alt-mark-13 Thread-Index: AQHTTfzDqwPRXUR6aE6ZHyCQVGUiw6L11+CA Date: Thu, 26 Oct 2017 09:14:13 +0000 Message-ID: <391beb71155048f3b8168c2c1fb5c8bd@TELMBXB02RM001.telecomitalia.local> References: In-Reply-To: Accept-Language: it-IT, en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.14.252.234] x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrPKsWRmVeSWpSXmKPExsXCxfdHWjdt+cdIg76FwhazbjeyW8z4M5HZ 4sPChywW3c0b2RxYPJYs+cnk0XTmKHMAU1QDo01iXl5+SWJJqkJKanGyrZJLZnFyTmJmbmqR QkhqTmpyfq6SQmaKrZKxkkJBTmJyam5qXomtUmJBQWpeipIdlwIGsAEqy8xTSM1Lzk/JzEu3 VfIM9te1sDC11DVUsgssTS0uyVfITS0uTkxPz8xXSE1YL5ixaPN6xoJjvBVbvx5hbGD8z9XF yMkhIWAicXNiD1MXIxeHkMBUJomt84+ygiTYBGwkDr46wQZiiwhsZ5SY0G8KYgsLWEh8+vCU ESJuJbF2705mCNtIouXTJrA4i4CqxLTt38Hm8AoESrx/0Q82Rwho5vRju9hBbE4BW4nVXxaD xRkFZCUm7F4E1sssIC7xYvoJdojjBCSW7DnPDGGLSrx8/I8VwjaQ2Lp0HwuErSgx5fdORghb RmLhkcmsEHP0JG5MncIGYWtLLFv4mhniHkGJkzOfsExgFJ2FZN0sJC2zkLTMQtKygJFlFaNo boWBkV4JJM4ySxJzMhP1Mks2MQJTxc2VlWI7GFvXOh9iFOBgVOLhvdb+MVKINbGsuDL3EKME B7OSCO+dGUAh3pTEyqrUovz4otKc1OJDjD7AEJvILCWanA9MY3kl8YYmFpaGxhYWRoYWZqY4 hJXEeeMdPkQKCaQDE1V2ampBahHMOCYOTqkGRsYS897oc2eEFzsV7P++KfUkc0ZGzuvr7r4v Yn/UtRy/YvS+9/+puTGNqanGfIYsO5tc87k+K+jO4FbbMHND4J7rO6a0hOsaz2AwkPmiUO/c nHXifepq/v9HHrkL/zDf9rb9ypK+a6eDT78WmGRXnMp0mf/G6023Hp9szpNsPh/20jaC73yk ohJLcUaioRZzUXEiAD6BO1pCAwAA Archived-At: Subject: [secdir] R: secdir review of draft-ietf-ippm-alt-mark-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 09:14:19 -0000 Hi Taylor, I appreciate your good opinion of the document and I agree with your notes. Thanks, Giuseppe -----Messaggio originale----- Da: Taylor Yu [mailto:tlyu@mit.edu] Inviato: gioved=EC 26 ottobre 2017 03:50 A: iesg@ietf.org; secdir@ietf.org; draft-ietf-ippm-alt-mark.all@ietf.org Oggetto: secdir review of draft-ietf-ippm-alt-mark-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 com= ments were written primarily for the benefit of the security area directors.= Document editors and WG chairs should treat these comments just like any o= ther last call comments. The summary of the review is Ready. The Security Considerations section seems reasonable. I mostly agree that "The privacy concerns of network measurement are limited because the method only relies on information contained in the IP header without any release of user data." I would add that although information in the IP header is metadata that can= be used to compromise the privacy of users, the limited marking technique i= n this document seems unlikely to substantially increase the existing privac= y risks from IP header metadata. I also think it's reasonable to consider t= his detail to be already addressed by the wording "privacy concerns... are l= imited". It might be theoretically possible to modulate the marking to serve as a cov= ert channel, but I think it would have a very low data rate if it is to avoi= d adversely affecting the measurement systems that monitor the marking. It'= s probably not worth mentioning this possibility in the document. Best regards, -Taylor Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle pers= one indicate. La diffusione, copia o qualsiasi altra azione derivante dalla= conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbia= te ricevuto questo documento per errore siete cortesemente pregati di darne= immediata comunicazione al mittente e di provvedere alla sua distruzione, G= razie. This e-mail and any attachments is confidential and may contain privileged i= nformation intended for the addressee(s) only. Dissemination, copying, print= ing or use by anybody else is unauthorised. If you are not the intended reci= pient, please delete this message and any attachments and advise the sender= by return e-mail, Thanks. Rispetta l'ambiente. Non stampare questa mail se non =E8 necessario. From nobody Thu Oct 26 07:01:42 2017 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 7E473137832 for ; Thu, 26 Oct 2017 07:01:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Tero Kivinen To: X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Reply-to: secdir-secretary@mit.edu Message-ID: <150902650151.24056.15116926500305607161.idtracker@ietfa.amsl.com> Date: Thu, 26 Oct 2017 07:01:41 -0700 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 14:01:41 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2017-10-26 Reviewer LC end Draft Ólafur Guðmundsson 2017-10-13 draft-ietf-uta-email-deep-09 Leif Johansson 2017-10-25 draft-ietf-netconf-rfc6536bis-07 Ben Laurie 2017-10-23 draft-ietf-rmcat-scream-cc-12 Dacheng Zhang 2017-10-13 draft-ietf-mile-rolie-12 For telechat 2017-11-30 Reviewer LC end Draft John Bradley None draft-ietf-acme-acme-07 Alan DeKok 2017-10-09 draft-ietf-tsvwg-ieee-802-11-09 Daniel Gillmor 2017-10-17 draft-ietf-sidrops-bgpsec-rollover-02 Watson Ladd R2017-10-19 draft-ietf-tcpinc-tcpeno-12 Barry Leiba 2017-10-19 draft-ietf-tcpinc-tcpcrypt-08 Chris Lonvick 2017-11-03 draft-ietf-regext-launchphase-06 Tina Tsou R2017-06-29 draft-ietf-trill-arp-optimization-09 For telechat 2017-12-14 Reviewer LC end Draft Shaun Cooley 2017-10-11 draft-ietf-grow-bgp-gshut-12 Last calls: Reviewer LC end Draft Phillip Hallam-Baker 2017-10-13 draft-ietf-ospf-segment-routing-extensions-21 Adam Montville R2017-11-07 draft-ietf-opsawg-mud-13 Russ Mundy 2017-09-14 draft-spinosa-urn-lex-11 Tim Polk 2017-09-11 draft-ietf-kitten-rfc5653bis-05 Tom Yu 2017-02-20 draft-ietf-slim-negotiating-human-language-17 Next in the reviewer rotation: David Mandelberg Catherine Meadows Alexey Melnikov Daniel Migault Matthew Miller Adam Montville Russ Mundy Sandra Murphy Yoav Nir Magnus Nystrom From nobody Fri Oct 27 11:53:42 2017 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 A3D0513F3E6; Fri, 27 Oct 2017 11:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PWOmsEQ3KI1V; Fri, 27 Oct 2017 11:53:38 -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 914C913D179; Fri, 27 Oct 2017 11:53:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6722; q=dns/txt; s=iport; t=1509130418; x=1510340018; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=lIBVT9UOP/kYyxSwLstqGiM87BTW6SWgo+KC5oSluok=; b=C6KFTPhFdteJEOkLVXCXPTrojwFSG7lrprX9or6I2nF2T6gpa3fMj+Gy J/EqAnxCFbfpcitWZ66wDhFByAF56wLFM12ym4IDRJdqnS2/lIG1IWflS 25IMrsDsEmIWNBV1a38QCpsu8YLz/WGhB0xdQaXoFWCr90kTkkIsU0bNR M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C8AAACgPNZ/5ldJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg19kbicHjhKPFJJ3hUWCEQojhRgChEs/GAECAQEBAQEBAWsohR4?= =?us-ascii?q?GeRACAQg/BzIUEQIEDgWJP2QQqziKagEBAQEBAQEBAQEBAQEBAQEBAQEBARgFg?= =?us-ascii?q?y6CB4M5KYMBhG+DWoIyBZkCiQEClHqCFYoDhxWVYwIRGQGBOAEfOIFoehV2AYI?= =?us-ascii?q?2hF93AYpTgREBAQE?= X-IronPort-AV: E=Sophos;i="5.44,305,1505779200"; d="scan'208,217";a="313220176" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Oct 2017 18:50:58 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v9RIow3m017075 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 27 Oct 2017 18:50:58 GMT Received: from xch-rcd-004.cisco.com (173.37.102.14) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 27 Oct 2017 13:50:58 -0500 Received: from xch-rcd-004.cisco.com ([173.37.102.14]) by XCH-RCD-004.cisco.com ([173.37.102.14]) with mapi id 15.00.1320.000; Fri, 27 Oct 2017 13:50:58 -0500 From: "Naiming Shen (naiming)" To: "Scott G. Kelly" CC: "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-dhc-relay-port.all@tools.ietf.org" Thread-Topic: secdir review of draft-ietf-dhc-relay-port-06 Thread-Index: AQHTTOkcXv7OQr8l1Eym+7B0D2tfN6L4YwoA Date: Fri, 27 Oct 2017 18:50:57 +0000 Message-ID: <52A67135-4F66-47B7-B9C2-85477B6E7077@cisco.com> References: <1508861901.825516724@apps.rackspace.com> In-Reply-To: <1508861901.825516724@apps.rackspace.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.92.136] Content-Type: multipart/alternative; boundary="_000_52A671354F6647B7B9C285477B6E7077ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-dhc-relay-port-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 18:53:41 -0000 --_000_52A671354F6647B7B9C285477B6E7077ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Scott, Thanks for the review of this draft. To answer the question in your last pa= ragraph, Yes, the scheme does not that, or any combination of that. I have included = two more paragraph in the new version trying to demonstrate that along with the existing example. The new version just posted: https://www.ietf.org/id/draft-ietf-dhc-relay-port-07.txt Best Regards, - Naiming On Oct 24, 2017, at 9:18 AM, 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 com= ments 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 "ready" with minor editorial nits. >From the abstract, this document proposes an extension to the DHCP protocol= s that allows a (DHCP) relay agent to receive packets from a server or an u= pstream relay agent on any UDP port, not just the default port 67 for IPv4 = or default port 547 for IPv6. Paraphrasing, it allows a relay agent to use any available source port for = upstream communications, and to include a DHCP option that can be used to s= tatelessly route responses back to the appropriate source port on downstrea= m communications. The security considerations section references [RFC3118] and [RFC3315], and= adds that any firewalls in the path may need reconfiguration to allow DHCP= flows from non-fixed addresses. I don't have anything to add, though I thi= nk that section could benefit from a little word-smithing. I'll defer to th= e RFC editor on that. The draft is clear, though a simple ascii diagram illustrating a client, re= lay, and server (including src/dst ports) might help readers to more immedi= ately understand what this looks like topologically. I read it through, and= then went back and drew myself a picture as I read, and that helped. Just = a thought. One minor (non-security) question I had: section 6 illustrates a cascaded I= Pv6 example wherein Relay1 is using a non-standard port, but Relay2 is not.= What happens if both Relay1 and Relay2 are using non-standard source ports= ? Is this allowed? If not, you might want to call this out. If so, it might= be good to describe a general case of n relays with m non-standard source = ports. --Scott --_000_52A671354F6647B7B9C285477B6E7077ciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable

Hi Scott,

Thanks for the review of this draft. To answer the question= in your last paragraph,
Yes, the scheme does not that, or any combination of that. = I have included two
more paragraph in the new version trying to demonstrate tha= t along with the
existing example.

The new version just posted:

https://www.ietf.org/id/draft-ietf-dhc-relay-port-07.t= xt

Best Regards,
- Naiming

On Oct 24, 2017, at 9:18 AM, Scott G. Kelly <scott@hyperthought.com> wr= ote:

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

The summary of the review is "ready" with minor editorial nits.
>From the abstract, this document proposes an extension to the DHCP protocol= s that allows a (DHCP) relay agent to receive packets from a server or an u= pstream relay agent on any UDP port, not just the default port 67 for IPv4 = or default port 547 for IPv6.

Paraphrasing, it allows a relay agent to use any available source port for = upstream communications, and to include a DHCP option that can be used to s= tatelessly route responses back to the appropriate source port on downstrea= m communications.

The security considerations section references [RFC3118] and [RFC3315], and= adds that any firewalls in the path may need reconfiguration to allow DHCP= flows from non-fixed addresses. I don't have anything to add, though I thi= nk that section could benefit from a little word-smithing. I'll defer to the RFC editor on that.

The draft is clear, though a simple ascii diagram illustrating a client, re= lay, and server (including src/dst ports) might help readers to more immedi= ately understand what this looks like topologically. I read it through, and= then went back and drew myself a picture as I read, and that helped. Just a thought.

One minor (non-security) question I had: section 6 illustrates a cascaded I= Pv6 example wherein Relay1 is using a non-standard port, but Relay2 is not.= What happens if both Relay1 and Relay2 are using non-standard source ports= ? Is this allowed? If not, you might want to call this out. If so, it might be good to describe a general case = of n relays with m non-standard source ports.

--Scott




--_000_52A671354F6647B7B9C285477B6E7077ciscocom_-- From nobody Fri Oct 27 13:33:52 2017 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 EA38813F3F5; Fri, 27 Oct 2017 13:33:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 SZZhZt3qI9_H; Fri, 27 Oct 2017 13:33:48 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0129.outbound.protection.outlook.com [104.47.41.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C5CD13955E; Fri, 27 Oct 2017 13:33:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=dzr8e8AiZO1j7x4oBHzVrk9i5JbwYGEybPvLLIh8jkM=; b=oumO5MTcyapRGxY4FhTh0hizpgSUs1oW6CtPI9JUL03O7JaAS34WhsAcPCr6QF86Rixi3eMxIWxMAKoAs0cufLgUr872TXFKV2uflgbMm4sfoYpnYSJfv9tLGrnBBC4uVwMQ52KXZr6aOAKVGiqNwIdmS15vlSqksSGoG6gOXpw= Received: from CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) by CY4PR21MB0135.namprd21.prod.outlook.com (10.173.189.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.197.0; Fri, 27 Oct 2017 20:33:46 +0000 Received: from CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) by CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) with mapi id 15.20.0197.006; Fri, 27 Oct 2017 20:33:46 +0000 From: Mike Jones To: Donald Eastlake , "iesg@ietf.org" , "draft-ietf-oauth-discovery@ietf.org" CC: "secdir@ietf.org" Thread-Topic: SECDIR review of draft-ietf-oauth-discovery-07 Thread-Index: AQHTTTl4CbwmVHpMG0aiqTfcAGLFYqL4KzHg Date: Fri, 27 Oct 2017 20:33:46 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Ref=https://api.informationprotection.azure.com/api/72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=mbj@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2017-10-27T13:33:44.9766311-07:00; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General x-originating-ip: [2001:4898:80e8:8::36] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0135; 6:rkSYGCAb8nrj20t1dJPIluwIfDF1gvc1KG6D5jCItu+V1IvDhCKLRQYJoLPwgPnplGvEgqrtcH71+IlhWsT4bPRxsqsOCLwde9tmb0+At0BhQEb9V3Fx1z7Q6tptRP6mYmBLWA5GaMZ5lfvS4FIbsGS0HuCfqGhooulgwwJrOXd13E06CwO1TzXGyBsTSNY9mzH6fIXhWEBhHOeS1NUo6+Ekyp0YoGtav8FRqQhdsklza6xqI0MRmPasU7DvFJdfDha/UGRb8EtBHcCBE6x5qPQLP9GoA6h4P3jmBZDP5zvCzpquy5m432VaPnJDT23eqZlGwFaxdXzao02b12fj48GA08aDZRd2D1MUodKhO48=; 5:sHFFccTeq0pSl67KX3JqpZVVXXPiOEev7RFSZSjve1inUGhdTvAQnPJcoik8VK4SCsdWvXSQgaBkTGxfSSZYJqAwkoZZ1z2+apkT79BFouxQNiUTAZ2yniYpVAFA1xPA9qLe/fAOUvzlMCyEGbbbYPAXcR9sVWptQOV7ZYKnK7g=; 24:2X+4qlLf+ArNfgf93NeOny7M0enA+swC/XWeQEuYDfPDKGmgwdBpY80XrGfPTqnsaYuzKxPXgMqPtTtg+Z/5RbJIWcLrmBuSOcZ6/HtbX7Q=; 7:ixKLLKNJtPjjjzmgw5NTv2Dj11t+kgf1jiP1r5TqDHLjwbGbtTrB9UETxShE48z6peutosdAP8XgbL/hX+e6nNVmn55SmwuNnqk2P5khxUa1uGqdLjKbZ4r5dqosbXgcD7kyfq4ETB5fBLH5krxnjgrby+13uEAfA/mgDPZ4WozlpLC/4u5LUfUvQ+X6zHV8Pwx0ezWGwHU0ziVPbpaJur/JgDNvqGgzo8iJHGus19+YUxQpBF3pT9EhaQgGdgVf x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 1345ac3e-924d-4e84-df39-08d51d7a05db x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(4534020)(4602075)(2017052603238); SRVR:CY4PR21MB0135; x-ms-traffictypediagnostic: CY4PR21MB0135: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705)(35073007944872)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(3231020)(100000703101)(100105400095)(6055026)(61426038)(61427038)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(20161123560025)(20161123558100)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR21MB0135; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR21MB0135; x-forefront-prvs: 0473A03F3F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(376002)(346002)(47760400005)(199003)(30594003)(189002)(86612001)(86362001)(5660300001)(68736007)(2501003)(53546010)(8676002)(189998001)(3280700002)(2900100001)(6436002)(4326008)(3660700001)(2906002)(7736002)(72206003)(81156014)(6506006)(77096006)(81166006)(316002)(10290500003)(106356001)(74316002)(478600001)(14454004)(54896002)(6306002)(6246003)(25786009)(102836003)(19609705001)(229853002)(2950100002)(76176999)(50986999)(54356999)(39060400002)(6116002)(7696004)(790700001)(110136005)(8990500004)(33656002)(105586002)(22452003)(97736004)(53936002)(8936002)(55016002)(10090500001)(2201001)(236005)(230783001)(9686003)(101416001)(99286003); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0135; H:CY4PR21MB0504.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0504DC13A5BDDD0C86E5B300F55A0CY4PR21MB0504namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1345ac3e-924d-4e84-df39-08d51d7a05db X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Oct 2017 20:33:46.3223 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0135 Archived-At: Subject: Re: [secdir] SECDIR review of draft-ietf-oauth-discovery-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 20:33:51 -0000 --_000_CY4PR21MB0504DC13A5BDDD0C86E5B300F55A0CY4PR21MB0504namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzLCBEb25hbGQuICBJ4oCZbGwgZG8gdGhlIHVwZGF0ZSB0byA4MTI2IGluIHRoZSBuZXh0 IGRyYWZ0Lg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBEb25hbGQgRWFzdGxha2UgW21haWx0 bzpkM2UzZTNAZ21haWwuY29tXQ0KU2VudDogVHVlc2RheSwgT2N0b2JlciAyNCwgMjAxNyA3OjMy IFBNDQpUbzogaWVzZ0BpZXRmLm9yZzsgZHJhZnQtaWV0Zi1vYXV0aC1kaXNjb3ZlcnlAaWV0Zi5v cmcNCkNjOiBzZWNkaXJAaWV0Zi5vcmcNClN1YmplY3Q6IFNFQ0RJUiByZXZpZXcgb2YgZHJhZnQt aWV0Zi1vYXV0aC1kaXNjb3ZlcnktMDcNCg0KSSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQg YXMgcGFydCBvZiB0aGUgc2VjdXJpdHkgZGlyZWN0b3JhdGUncyBvbmdvaW5nIGVmZm9ydCB0byBy ZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUgSUVTRy4gIERv Y3VtZW50IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBzaG91bGQgdHJlYXQgdGhlc2UgY29tbWVudHMg anVzdCBsaWtlIGFueSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMuDQoNClRoZSBzdW1tYXJ5IG9m IHRoZSByZXZpZXcgaXMgZHJhZnQgaXMgcmVhZHkgd2l0aCBvbmUgbml0Lg0KDQpUaGlzIGRyYWZ0 IGRlZmluZXMgYSBtZXRhZGF0YSBmb3JtYXQgdGhhdCBhbiBPQXV0aCAyLjAgY2xpZW50IGNhbiB1 c2UgdG8gb2J0YWluIHRoZSBpbmZvcm1hdGlvbiBuZWVkZWQgdG8gaW50ZXJhY3Qgd2l0aCBhbiBP QXV0aCAyLjAgYXV0aG9yaXphdGlvbiBzZXJ2ZXIsIGluY2x1ZGluZyBpdHMgZW5kcG9pbnQgbG9j YXRpb25zIGFuZCBhdXRob3JpemF0aW9uIHNlcnZlciBjYXBhYmlsaXRpZXMuDQoNCldoaWxlIEkg YW0gbm90IGRlZXBseSBmYW1pbGlhciB3aXRoIHRoaXMgYXJlYSBvZiBzZWN1cml0eSB0ZWNobm9s b2d5LCB0aGUgZXh0ZW5zaXZlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIHNlY3Rpb24gc2VlbXMg dGhvcm91Z2ggYW5kIGNvcnJlY3QgYXMgZmFyIGFzIEkgY2FuIHNlZS4NCg0KTml0OiBUaGUgcmVm ZXJlbmNlIHRvIFJGQyA1MjI2IHNob3VsZCBwcm9iYWJseSBiZSB1cGRhdGVkIHRvIFJGQyA4MTI2 DQoNClRoYW5rcywNCkRvbmFsZA0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KIERv bmFsZCBFLiBFYXN0bGFrZSAzcmQgICArMS01MDgtMzMzLTIyNzA8dGVsOig1MDgpJTIwMzMzLTIy NzA+IChjZWxsKQ0KIDE1NSBCZWF2ZXIgU3RyZWV0LCBNaWxmb3JkLCBNQSAwMTc1NyBVU0ENCiBk M2UzZTNAZ21haWwuY29tPG1haWx0bzpkM2UzZTNAZ21haWwuY29tPg0K --_000_CY4PR21MB0504DC13A5BDDD0C86E5B300F55A0CY4PR21MB0504namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOiMwMDIwNjA7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBp biAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6 ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IzAwMjA2MCI+VGhhbmtzLCBEb25hbGQuJm5ic3A7IEnigJlsbCBkbyB0 aGUgdXBkYXRlIHRvIDgxMjYgaW4gdGhlIG5leHQgZHJhZnQuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0g TWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gRG9uYWxkIEVhc3RsYWtlIFttYWlsdG86ZDNlM2Uz QGdtYWlsLmNvbV0gPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIE9jdG9iZXIgMjQsIDIwMTcg NzozMiBQTTxicj4NCjxiPlRvOjwvYj4gaWVzZ0BpZXRmLm9yZzsgZHJhZnQtaWV0Zi1vYXV0aC1k aXNjb3ZlcnlAaWV0Zi5vcmc8YnI+DQo8Yj5DYzo8L2I+IHNlY2RpckBpZXRmLm9yZzxicj4NCjxi PlN1YmplY3Q6PC9iPiBTRUNESVIgcmV2aWV3IG9mIGRyYWZ0LWlldGYtb2F1dGgtZGlzY292ZXJ5 LTA3PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBoYXZlIHJldmlld2Vk IHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgc2VjdXJpdHkgZGlyZWN0b3JhdGUncyBvbmdv aW5nIGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBi eSB0aGUgSUVTRy4mbmJzcDsgRG9jdW1lbnQgZWRpdG9ycyBhbmQgV0cgY2hhaXJzIHNob3VsZCB0 cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0IGxpa2UgYW55IG90aGVyIGxhc3QgY2FsbCBjb21tZW50 cy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+VGhlIHN1bW1hcnkgb2YgdGhlIHJldmlldyBpcyBkcmFmdCBpcyByZWFkeSB3aXRoIG9u ZSBuaXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlRoaXMgZHJhZnQgZGVmaW5lcyBhIG1ldGFkYXRhIGZvcm1hdCB0aGF0IGFuIE9BdXRoIDIu MCBjbGllbnQgY2FuIHVzZSB0byBvYnRhaW4gdGhlIGluZm9ybWF0aW9uIG5lZWRlZCB0byBpbnRl cmFjdCB3aXRoIGFuIE9BdXRoIDIuMCBhdXRob3JpemF0aW9uIHNlcnZlciwgaW5jbHVkaW5nIGl0 cyBlbmRwb2ludCBsb2NhdGlvbnMgYW5kIGF1dGhvcml6YXRpb24gc2VydmVyIGNhcGFiaWxpdGll cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ V2hpbGUgSSBhbSBub3QgZGVlcGx5IGZhbWlsaWFyIHdpdGggdGhpcyBhcmVhIG9mIHNlY3VyaXR5 IHRlY2hub2xvZ3ksIHRoZSBleHRlbnNpdmUgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgc2VjdGlv biBzZWVtcyB0aG9yb3VnaCBhbmQgY29ycmVjdCBhcyBmYXIgYXMgSSBjYW4gc2VlLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5OaXQ6IFRoZSBy ZWZlcmVuY2UgdG8gUkZDIDUyMjYgc2hvdWxkIHByb2JhYmx5IGJlIHVwZGF0ZWQgdG8gUkZDIDgx MjY8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlRoYW5rcyw8YnI+DQpEb25hbGQ8YnI+DQo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PGJyPg0KJm5ic3A7RG9uYWxkIEUuIEVhc3RsYWtlIDNyZCAmbmJzcDsgPGEgaHJlZj0i dGVsOig1MDgpJTIwMzMzLTIyNzAiIHRhcmdldD0iX2JsYW5rIj4mIzQzOzEtNTA4LTMzMy0yMjcw PC9hPiAoY2VsbCk8YnI+DQombmJzcDsxNTUgQmVhdmVyIFN0cmVldCwgTWlsZm9yZCwgTUEgMDE3 NTcgVVNBPGJyPg0KJm5ic3A7PGEgaHJlZj0ibWFpbHRvOmQzZTNlM0BnbWFpbC5jb20iIHRhcmdl dD0iX2JsYW5rIj5kM2UzZTNAZ21haWwuY29tPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CY4PR21MB0504DC13A5BDDD0C86E5B300F55A0CY4PR21MB0504namp_-- From nobody Sat Oct 28 07:05:41 2017 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 9533913F550; Sat, 28 Oct 2017 07:05:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adam Montville To: Cc: draft-ietf-opsawg-mud.all@ietf.org, opsawg@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150919953057.2627.7990473745194211968@ietfa.amsl.com> Date: Sat, 28 Oct 2017 07:05:30 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-opsawg-mud-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Oct 2017 14:05:31 -0000 Reviewer: Adam Montville 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 draft is ready. All previously identified potential issues (see [1]) seem to have been addressed. For the security ADs, please review the summary I wrote at [1], which is still applicable. For the opsawg folks, if (when?) you get around to describing how software packages might be able to convey their intended use and/or preferred configuration, let me know - I'd like to help. [1] https://www.ietf.org/mail-archive/web/secdir/current/msg07563.html