From nobody Fri Jun 1 02:23:32 2018 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 225E51275AB; Fri, 1 Jun 2018 02:23:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Liang Xia To: Cc: draft-ietf-cellar-ffv1.all@ietf.org, cellar@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152784500007.15152.9045057653501275171@ietfa.amsl.com> Date: Fri, 01 Jun 2018 02:23:20 -0700 Archived-At: Subject: [secdir] Secdir early review of draft-ietf-cellar-ffv1-02 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, 01 Jun 2018 09:23:21 -0000 Reviewer: Liang Xia Review result: Ready The whole draft is in good shape and well written. Some nits: 1. every word should start with capital letter for the section title; 2. section 2.2.4: / ceil(a) the largest integer less than or equal to a / ceil(a) the smallest integer larger than or equal to a / 3. section 3.7.2: [ISO.15444-1.2016]? 4. section 12.1: [I-D.ietf-cellar-ffv1]? 5. section 12.2: should all the RFC move to the Normative References (section 12.1)? Issues for clarification: In Security Considerations, besides the DoS attacks brought by the malicious payloads, is there any other kinds of attack possibly? For example, virus or worm are hidden in the malicious payloads to attack the system for more damages? Does it make sense and what's the consideration? From nobody Fri Jun 1 07:38:12 2018 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 1B82B12D883; Fri, 1 Jun 2018 07:38:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 y81H5uBOlKEp; Fri, 1 Jun 2018 07:37:57 -0700 (PDT) Received: from server172-3.web-hosting.com (server172-3.web-hosting.com [68.65.122.111]) (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 E665912D885; Fri, 1 Jun 2018 07:37:53 -0700 (PDT) Received: from [146.96.19.240] (port=20616 helo=[10.10.201.39]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1fOlBe-000MvB-HD; Fri, 01 Jun 2018 10:37:52 -0400 From: Dave Rice Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_71F82103-5CE2-45B9-B7B5-22D0629ED470" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 1 Jun 2018 10:37:49 -0400 In-Reply-To: <152784500007.15152.9045057653501275171@ietfa.amsl.com> Cc: secdir@ietf.org, draft-ietf-cellar-ffv1.all@ietf.org, Codec Encoding for LossLess Archiving and Realtime transmission , ietf@ietf.org To: Liang Xia References: <152784500007.15152.9045057653501275171@ietfa.amsl.com> X-Mailer: Apple Mail (2.3273) X-OutGoing-Spam-Status: No, score=-2.4 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [secdir] Secdir early review of draft-ietf-cellar-ffv1-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: Fri, 01 Jun 2018 14:38:03 -0000 --Apple-Mail=_71F82103-5CE2-45B9-B7B5-22D0629ED470 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Thanks for this review. > On Jun 1, 2018, at 5:23 AM, Liang Xia = wrote: >=20 > Reviewer: Liang Xia > Review result: Ready >=20 > The whole draft is in good shape and well written. > Some nits: > 1. every word should start with capital letter for the section title; > 2. section 2.2.4: / ceil(a) the largest integer less than or equal to = a / > ceil(a) the smallest integer larger than or equal to a / 3. section = 3.7.2: > [ISO.15444-1.2016]? 4. section 12.1: [I-D.ietf-cellar-ffv1]? 5. = section 12.2: > should all the RFC move to the Normative References (section 12.1)? I added a pull request at https://github.com/FFmpeg/FFV1/pull/116 = that addresses many of these = issues. Regarding=20 > section 12.1: [I-D.ietf-cellar-ffv1]? I found that Media Type Definitions within RFC=E2=80=99s tend to be = self-referencing. Since there is no RFC number here on this draft, = I=E2=80=99ve used [I-D.ietf-cellar-ffv1] as a temporary self reference. > Issues for clarification: > In Security Considerations, besides the DoS attacks brought by the = malicious > payloads, is there any other kinds of attack possibly? For example, = virus or > worm are hidden in the malicious payloads to attack the system for = more > damages? Does it make sense and what's the consideration? I haven=E2=80=99t done any update for this. Nudge to Michael Niedermayer = and J=C3=A9r=C3=B4me Martinez. Best Regards, Dave Rice --Apple-Mail=_71F82103-5CE2-45B9-B7B5-22D0629ED470 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi,
Thanks for this = review.

On Jun 1, 2018, at 5:23 AM, Liang Xia <frank.xialiang@huawei.com> wrote:

Reviewer: Liang Xia
Review result: Ready

The whole draft is in good shape and well = written.
Some nits:
1. every word should = start with capital letter for the section title;
2. = section 2.2.4: / ceil(a) the largest integer less than or equal to a = /
ceil(a) the smallest integer larger than or equal to a / = 3. section 3.7.2:
[ISO.15444-1.2016]? 4. section 12.1: = [I-D.ietf-cellar-ffv1]? 5. section 12.2:
should all the = RFC move to the Normative References (section 12.1)?

I = added a pull request at https://github.com/FFmpeg/FFV1/pull/116 that = addresses many of these issues.

Regarding 
section 12.1: [I-D.ietf-cellar-ffv1]?
I found = that Media Type Definitions within RFC=E2=80=99s tend to be = self-referencing. Since there is no RFC number here on this draft, = I=E2=80=99ve used [I-D.ietf-cellar-ffv1] as a temporary self = reference.

Issues for clarification:
In = Security Considerations, besides the DoS attacks brought by the = malicious
payloads, is there any other kinds of attack = possibly? For example, virus or
worm are hidden in the = malicious payloads to attack the system for more
damages? = Does it make sense and what's the consideration?

I = haven=E2=80=99t done any update for this. Nudge to Michael Niedermayer = and J=C3=A9r=C3=B4me Martinez.
Best = Regards,
Dave Rice

= --Apple-Mail=_71F82103-5CE2-45B9-B7B5-22D0629ED470-- From nobody Fri Jun 1 08:13:11 2018 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 4438E12D941 for ; Fri, 1 Jun 2018 08:13:04 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VXlGC3jM1g-g for ; Fri, 1 Jun 2018 08:13:01 -0700 (PDT) Received: from 10.mo68.mail-out.ovh.net (10.mo68.mail-out.ovh.net [46.105.79.203]) (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 D805B12D940 for ; Fri, 1 Jun 2018 08:13:00 -0700 (PDT) Received: from player761.ha.ovh.net (unknown [10.109.122.1]) by mo68.mail-out.ovh.net (Postfix) with ESMTP id 173C7E2A68 for ; Fri, 1 Jun 2018 17:12:58 +0200 (CEST) Received: from [192.168.2.120] (p5DDB54A6.dip0.t-ipconnect.de [93.219.84.166]) (Authenticated sender: jerome@mediaarea.net) by player761.ha.ovh.net (Postfix) with ESMTPSA id 2B22E480091; Fri, 1 Jun 2018 17:12:53 +0200 (CEST) To: Liang Xia Cc: secdir@ietf.org, draft-ietf-cellar-ffv1.all@ietf.org, cellar@ietf.org, ietf@ietf.org References: <152784500007.15152.9045057653501275171@ietfa.amsl.com> From: Jerome Martinez Message-ID: <29965bd1-ce37-d8a8-25c4-81f6d2ddff4b@mediaarea.net> Date: Fri, 1 Jun 2018 17:12:54 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <152784500007.15152.9045057653501275171@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-Ovh-Tracer-Id: 7095984163828273286 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedthedrieeggdekvdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemuceftddtnecu Archived-At: Subject: Re: [secdir] [Cellar] Secdir early review of draft-ietf-cellar-ffv1-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: Fri, 01 Jun 2018 15:13:04 -0000 On 01/06/2018 11:23, Liang Xia wrote: > Issues for clarification: > In Security Considerations, besides the DoS attacks brought by the malicious > payloads, is there any other kinds of attack possibly? For example, virus or > worm are hidden in the malicious payloads to attack the system for more > damages? Does it make sense and what's the consideration? IMO transport of virus or worm is doable in the bitstream and could attack the system if there are buffer overflows in the decoding software, but not more dangerous than any other protocol or format (it depends on bugs in the decoding software). Checking e.g. Opus spec (I tried AV1 draft, but no security chapter right now if I well searched), I see generic sentences like: "It is extremely    important for the decoder to be robust against malicious payloads.    Malicious payloads must not cause the decoder to overrun its    allocated memory or to take an excessive amount of resources to    decode." "The reference implementation contains no known buffer overflow or    cases where a specially crafted packet or audio segment could cause a    significant increase in CPU load. " "The reference implementation was validated in the following    conditions: (...)" (note: we ran same tests on our side) We could add such sentences in FFV1 security section. About the reference decoder, there are some hard coded limitations (e.g. maximum 1024 slices per frame, arbitrary choice which is sometimes increased in the code) for dropping frames which could use too much memory, and the decoder tries to allocate memory for big frames (e.g. if you try to decode de 1,000,000x1,000,000 pixel frames, FFmpeg will try to allocate corresponding memory as for any other format, and rejects the frame because memory can not be allocated. I don't think it is worth it to put details about that in spec, as FFmpeg code may change, maybe the generic sentences are enough? Thank you for your review. Jérôme From nobody Tue Jun 5 07:02:29 2018 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 C6E7213107B for ; Tue, 5 Jun 2018 07:02:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.695 X-Spam-Level: X-Spam-Status: No, score=-2.695 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.795, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.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 ndoN3AcAgrFK for ; Tue, 5 Jun 2018 07:02:20 -0700 (PDT) Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) (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 771BD13107D for ; Tue, 5 Jun 2018 07:02:20 -0700 (PDT) Received: from cmgw14.unifiedlayer.com (unknown [10.9.0.14]) by gproxy2.mail.unifiedlayer.com (Postfix) with ESMTP id 648291E0F40 for ; Tue, 5 Jun 2018 08:01:16 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id QCUzf0hrVYnqBQCUzfcEyx; Tue, 05 Jun 2018 07:59:45 -0600 X-Authority-Reason: nr=8 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=zZccASSnNOzmhEAXe6z4PoC+3ldhj1Seu3qCwp7zx0E=; b=WhyJGRgtElbDKAWhnOe3Ca8ySj poDNxh0ZC+ezDN9VUbxOiPGLh/1ZieFZAdemIVdfVzh1jqPkuDgSKvMlYBej1H4LBy9b9KF7QKEl/ T0of+JksBd1HH6X16/j+x2u53; Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:48452 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_1) (envelope-from ) id 1fQCWS-003llN-0h; Tue, 05 Jun 2018 08:01:16 -0600 To: Melinda Shore , secdir@ietf.org, IESG , draft-ietf-teas-yang-te-topo.all@ietf.org References: <1b9239b4-ff6a-4f85-4c6e-8b714cf6b6a3@gmail.com> From: Lou Berger Message-ID: Date: Tue, 5 Jun 2018 10:01:13 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <1b9239b4-ff6a-4f85-4c6e-8b714cf6b6a3@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.86.101 X-Source-L: No X-Exim-ID: 1fQCWS-003llN-0h X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-86-101.washdc.fios.verizon.net ([IPv6:::1]) [100.15.86.101]:48452 X-Source-Auth: lberger@labn.net X-Email-Count: 2 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [secdir] Secdir review of draft-ietf-teas-yang-te-topo-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 14:02:28 -0000 Melinda,     The authors have published an update with a revised security considerations section, please take a look at your convenience and let the authors know if you see that more is needed. https://tools.ietf.org/html/draft-ietf-teas-yang-te-topo-16#section-8 Lou (Doc Shepherd) On 5/31/2018 11:19 PM, Melinda Shore wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > The summary of the review is Ready with issues > > This document defines a technology-agnostic YANG data model for > representation of traffic engineering topologies, and is intended to > serve as a base model for other technology-specific traffic engineering > topology models. > > The document is clearly written and appears comprehensive with respect > to its subject matter. I suspect that sections 1-4 would be a useful > reference for people wanting to learn about TE topologies in general, > and I enjoyed reading it. > > The security considerations section is scanty and, unfortunately, > insufficient. The statement "The data-model by itself does not create > any security implications" seems questionable at best, since it contains > information about network topology and the treatment of traffic, > which may be of value to an attacker. The lack of discussion of > the threat environment is particularly problematic given that the > model is intended to be used for manipulating TE topologies. The > authors may want to look to draft-ietf-i2rs-yang-network-topo as > a model (no pun intended) of a good security considerations > section for a topology model. I don't see how this document can > be published with the security considerations section in its current > condition. > > This is really a trivial nit, but a nit nevertheless - the second > paragraph of the terminology section probably belongs in the > introduction instead, as it lays out expectations for the reader > and contains a pointer to introductory material for readers > unfamiliar with the IETF's traffic engineering work. > > Melinda > From nobody Wed Jun 6 04:13:18 2018 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 2B795130E06; Wed, 6 Jun 2018 04:13:08 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 P7_o-04ZrZpV; Wed, 6 Jun 2018 04:13:04 -0700 (PDT) Received: from mail-ot0-x236.google.com (mail-ot0-x236.google.com [IPv6:2607:f8b0:4003:c0f::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5188F1277BB; Wed, 6 Jun 2018 04:13:04 -0700 (PDT) Received: by mail-ot0-x236.google.com with SMTP id w13-v6so6651028ote.11; Wed, 06 Jun 2018 04:13:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=71hqAvJ784HhDaulk3DhRyE3awcJf59FEq+wmrZnOU8=; b=NJg008N7Szx3bQ/V7DrKnpMZJafyHILqL5Z3NzfF265OI5ki4ec+BjIhA1HQt8t2EP rzbZhVs+TCKSO/mHF8TvUoUfHjbqcyQKv+VUtPn+0hAUHDs9KHZboCFSmR+ecl4CptY3 r0c2tXhUKRmhuhxtsqQ2qiwSz1shsw2tr2TwlS8ECwt6ZIAksIMs0CoW5zs0pn3PwgJW CpL6lTZ3Ypzz1RKX+3ixeBI0g87hRMkE2pQcNOnG4qT05uwhNhrbeBuLtlwelG7ZZGWa 5COqZ0CmmyH6Kn91sV1uWa2SsfInHa2SnlXKDQFVG4XiyLKbMcywuPhJMNCS/yjaF+7p g6tQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=71hqAvJ784HhDaulk3DhRyE3awcJf59FEq+wmrZnOU8=; b=QFGPYcuRZPHA3BJfEGcI9p8+PuDATBDVJ4KFm9nGN12AM92zDPk8wk8tUC1bxQRFg4 6ZoZ/D6BzUhi7KCQt0xbaTEiA2GCmjGFUJBabCcbfjIyc7HNQfYCk6yoQ/3cL/c4yyAM pv5nJQZT6e+KhoPvs81g0975xqQ4SYGMW3TZq5v2vvYqeegqk1duepV7HmFndqfhdUSG udsMwW8ELVpCQn86DEpwuUbzmsK/Txhkwj7Z/dJKZh5J0iY7N5OJqXyoxFG3zxbURyn3 1PiK3MDzus9I6H3pXT4a0gsdc5NmaeHdzJJXjqH80WYJRmY0alovuSWn2pGaRzI3ywGU JnbQ== X-Gm-Message-State: APt69E2BhQXvtglD7UbWJo0nBgCPU10umpKBfb6Kwh65Dw8i+Aws6k9M +ZIfLXq06OBeTbENmNY4J4mxNNavovSZutoFLdI= X-Google-Smtp-Source: ADUXVKKMkT+VBQ85adhkyi9qqbFmwmhJdQvDBp/cLTstKsfPVP6g8Ahs6KIV8Am7o4602HxP7ESE1gYfc7rqNqptomA= X-Received: by 2002:aca:f141:: with SMTP id p62-v6mr1484296oih.80.1528283583703; Wed, 06 Jun 2018 04:13:03 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 6 Jun 2018 07:13:02 -0400 From: Alvaro Retana In-Reply-To: References: <1b9239b4-ff6a-4f85-4c6e-8b714cf6b6a3@gmail.com> X-Mailer: Airmail (467) MIME-Version: 1.0 Date: Wed, 6 Jun 2018 07:13:02 -0400 Message-ID: To: Lou Berger , draft-ietf-teas-yang-te-topo.all@ietf.org Cc: secdir@ietf.org, Melinda Shore , IESG Content-Type: multipart/alternative; boundary="0000000000001f6f8f056df7408f" Archived-At: Subject: Re: [secdir] Secdir review of draft-ietf-teas-yang-te-topo-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 11:13:09 -0000 --0000000000001f6f8f056df7408f Content-Type: text/plain; charset="UTF-8" Hi! The updated section looks a lot better to me. However, I think it is important to call out the fact that the sensitive information in the readable data nodes includes geolocation. Alvaro. On June 5, 2018 at 10:23:18 AM, Lou Berger (lberger@labn.net) wrote: Melinda, The authors have published an update with a revised security considerations section, please take a look at your convenience and let the authors know if you see that more is needed. https://tools.ietf.org/html/draft-ietf-teas-yang-te-topo-16#section-8 Lou (Doc Shepherd) On 5/31/2018 11:19 PM, Melinda Shore wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > The summary of the review is Ready with issues > > This document defines a technology-agnostic YANG data model for > representation of traffic engineering topologies, and is intended to > serve as a base model for other technology-specific traffic engineering > topology models. > > The document is clearly written and appears comprehensive with respect > to its subject matter. I suspect that sections 1-4 would be a useful > reference for people wanting to learn about TE topologies in general, > and I enjoyed reading it. > > The security considerations section is scanty and, unfortunately, > insufficient. The statement "The data-model by itself does not create > any security implications" seems questionable at best, since it contains > information about network topology and the treatment of traffic, > which may be of value to an attacker. The lack of discussion of > the threat environment is particularly problematic given that the > model is intended to be used for manipulating TE topologies. The > authors may want to look to draft-ietf-i2rs-yang-network-topo as > a model (no pun intended) of a good security considerations > section for a topology model. I don't see how this document can > be published with the security considerations section in its current > condition. > > This is really a trivial nit, but a nit nevertheless - the second > paragraph of the terminology section probably belongs in the > introduction instead, as it lays out expectations for the reader > and contains a pointer to introductory material for readers > unfamiliar with the IETF's traffic engineering work. > > Melinda > --0000000000001f6f8f056df7408f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Hi!

The updated section looks a lot better to me.=C2=A0 However, I thi= nk it is important to call out the fact that the sensitive information in t= he readable data nodes includes geolocation.

Alvaro.

On June 5= , 2018 at 10:23:18 AM, Lou Berger (lber= ger@labn.net) wrote:

<= span>
Melinda,

=C2=A0=C2=A0=C2=A0 The authors have published an update with a revised= security =20
considerations section, please take a look at your convenience and let = =20
the authors know if you see that more is needed.

https://tools.ietf.org/html/draft-ietf-teas-yang-te-topo-16#sect= ion-8

Lou
(Doc Shepherd)
On 5/31/2018 11:19 PM, Melinda Shore wrote:
> I have reviewed this document as part of the security directorate&= #39;s
> ongoing effort to review all IETF documents being processed by the
> IESG. These comments were written primarily for the benefit of th= e
> security area directors. Document editors and WG chairs should tr= eat
> these comments just like any other last call comments.
>
> The summary of the review is Ready with issues
>
> This document defines a technology-agnostic YANG data model for
> representation of traffic engineering topologies, and is intended = to
> serve as a base model for other technology-specific traffic engine= ering
> topology models.
>
> The document is clearly written and appears comprehensive with res= pect
> to its subject matter. I suspect that sections 1-4 would be a use= ful
> reference for people wanting to learn about TE topologies in gener= al,
> and I enjoyed reading it.
>
> The security considerations section is scanty and, unfortunately,
> insufficient. The statement "The data-model by itself does n= ot create
> any security implications" seems questionable at best, since = it contains
> information about network topology and the treatment of traffic,
> which may be of value to an attacker. The lack of discussion of
> the threat environment is particularly problematic given that the
> model is intended to be used for manipulating TE topologies. The
> authors may want to look to draft-ietf-i2rs-yang-network-topo as
> a model (no pun intended) of a good security considerations
> section for a topology model. I don't see how this document c= an
> be published with the security considerations section in its curre= nt
> condition.
>
> This is really a trivial nit, but a nit nevertheless - the second
> paragraph of the terminology section probably belongs in the
> introduction instead, as it lays out expectations for the reader
> and contains a pointer to introductory material for readers
> unfamiliar with the IETF's traffic engineering work.
>
> Melinda
>

--0000000000001f6f8f056df7408f-- From nobody Thu Jun 7 06:30:23 2018 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 4B81213114B for ; Thu, 7 Jun 2018 06:30:11 -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.81.1 Auto-Submitted: auto-generated Precedence: bulk Reply-to: secdir-secretary@mit.edu Message-ID: <152837821130.30652.14707708847264145694.idtracker@ietfa.amsl.com> Date: Thu, 07 Jun 2018 06:30:11 -0700 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.26 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 13:30:19 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2018-06-21 Reviewer LC end Draft Sandra Murphy 2018-04-24 draft-ietf-mmusic-sdp-simulcast-12 Paul Wouters 2018-06-12 draft-ietf-dcrup-dkim-crypto-12 Last calls: Reviewer LC end Draft John Bradley 2018-06-18 draft-ietf-bfd-multipoint-active-tail-08 John Bradley 2018-04-18 draft-ietf-acme-acme-12 Roman Danyliw 2018-06-15 draft-ietf-teas-actn-info-model-08 Alan DeKok 2018-06-15 draft-ietf-pals-ethernet-cw-06 Daniel Gillmor 2018-03-19 draft-gutmann-scep-10 Christian Huitema R2018-06-08 draft-ietf-bfd-yang-14 Russ Mundy 2017-09-14 draft-spinosa-urn-lex-13 Tina Tsou 2018-05-21 draft-ietf-v6ops-conditional-ras-04 Samuel Weiler 2018-05-21 draft-ietf-bfd-multipoint-17 Brian Weis 2018-06-04 draft-ietf-tsvwg-rfc4960-errata-06 Klaas Wierenga 2018-06-26 draft-richer-vectors-of-trust-11 Christopher Wood 2018-06-12 draft-ietf-oauth-device-flow-10 Taylor Yu 2018-06-19 draft-ietf-regext-rdap-object-tag-03 Dacheng Zhang 2018-06-19 draft-ietf-mpls-spring-entropy-label-11 Early review requests: Reviewer Due Draft Donald Eastlake 2018-06-30 draft-ietf-mptcp-rfc6824bis-11 Daniel Franke 2018-01-31 draft-ietf-intarea-provisioning-domains-00 Ólafur Guðmundsson 2018-01-09 draft-ietf-opsawg-nat-yang-09 Next in the reviewer rotation: Shawn Emery Stephen Farrell Daniel Franke Daniel Gillmor Tobias Gondrom Ólafur Guðmundsson Phillip Hallam-Baker Steve Hanna Dan Harkins Russ Housley From nobody Thu Jun 7 12:58:55 2018 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 5FB23131164; Thu, 7 Jun 2018 12:58:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Brian Weis To: Cc: draft-ietf-tsvwg-rfc4960-errata.all@ietf.org, iesg@ietf.org, tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152840153235.30652.4913197199283925939@ietfa.amsl.com> Date: Thu, 07 Jun 2018 12:58:52 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-tsvwg-rfc4960-errata-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.26 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 19:58:53 -0000 Reviewer: Brian Weis 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 purpose of this document is to provide a history of changes that will be made to the next version of SCTP. The changes are comprised of resolutions to errata and referencing published extensions to SCTP that should be included in the next version of SCTP. There do no appear to be any security considerations to the errata or other text included in this Internet-Draft. I consider it Ready for publication. From nobody Sat Jun 9 17:21:22 2018 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 65EAC130DD1; Sat, 9 Jun 2018 17:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[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 chUN7J76KGE7; Sat, 9 Jun 2018 17:21:16 -0700 (PDT) Received: from mail-pg0-x243.google.com (mail-pg0-x243.google.com [IPv6:2607:f8b0:400e:c05::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 9A15E130DD2; Sat, 9 Jun 2018 17:21:16 -0700 (PDT) Received: by mail-pg0-x243.google.com with SMTP id d2-v6so8040726pga.13; Sat, 09 Jun 2018 17:21:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=Rsnn65rGjqWrA9RNuavcMDJOZ/AMu8KmX2alTJv5Y5I=; b=N3IRBGyLfqwPx99/QBbFE99NY3D3CbqAJx4yLLwKnUtAylp3QigvWwRYIoyAJkKRRL A4NC/BK4U0bgPlk05Yoh2W5eiLBhl5j5Kl/vxnLrqL3PXNN87H1GT2vMZX3CF/pv/WKI 3BaipTcW6u2G+hne/ywA0FPIDo0J9uwTuK2eFBgTKgwfLC4W4caMRe3zH2tUcy9rhOkZ NLvfPTQBe3W39KhaJmPwpfV2Oijy7zG8DO86ea4CoY2LuLuqctD4e85KnNxRW2VIVG4/ 5h9Zlj77cEigUCA2IMqJk0eQiBk1o6vb5vOZRE1wpbtpvPe857WmBUfYEmxKdswAyIK9 G/og== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Rsnn65rGjqWrA9RNuavcMDJOZ/AMu8KmX2alTJv5Y5I=; b=JbDpC4/YMWKS+uTeI1U168GYa/8nXEU8Sw8G52yoJ7n0zcAs4oaGuCeSFJryzrUFFj l3FlVmOynhj2kBb5SDmj2rvYg4zCGpmjl6r4noPeMgp/X7M0wzx+JMkXsuvcj60J1kMa PkkFkO1QXRkwcm90Zc2CJ1AWggNWmxRvgGuzOldtwjesS/rOiXRR4oPq/LO4kKYjofJO 7CqNknCgyKRQRXJ3WtCMkOTfE3q2S8ZY9exH6pmI1Td2rwy5/fFvEISi9hcu4Tj+E/YG sJSRszkxcp7ngphBQQkrVB4QQugmeJvqOd1KQZ6AWtmhVlWvEvLsCtAU7PKLg8I3mSJu eS6A== X-Gm-Message-State: APt69E38dFaLpb9RExoghy2z1hae7dG00orWVCxzoInPQ0wXGTbe8jYx iDvcG8QXgbaq1cE+6qUITshIMF8k X-Google-Smtp-Source: ADUXVKL7oFvHXT5fe7RNZTHs5IXbVECJSEH8tv+vfcBto1d2RKEFnYj0xucTdm2fa+8KB+XIFXoNTQ== X-Received: by 2002:a63:770b:: with SMTP id s11-v6mr10179529pgc.339.1528590075873; Sat, 09 Jun 2018 17:21:15 -0700 (PDT) Received: from aspen.local (63-140-99-174-radius.dynamic.acsalaska.net. [63.140.99.174]) by smtp.gmail.com with ESMTPSA id q68-v6sm106316366pfb.182.2018.06.09.17.21.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 09 Jun 2018 17:21:14 -0700 (PDT) To: Lou Berger , secdir@ietf.org, IESG , draft-ietf-teas-yang-te-topo.all@ietf.org References: <1b9239b4-ff6a-4f85-4c6e-8b714cf6b6a3@gmail.com> From: Melinda Shore Message-ID: <7938d449-d25e-5414-fae4-e5c999bf6751@gmail.com> Date: Sat, 9 Jun 2018 16:21:12 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [secdir] Secdir review of draft-ietf-teas-yang-te-topo-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2018 00:21:21 -0000 On 6/5/18 6:01 AM, Lou Berger wrote: >     The authors have published an update with a revised security > considerations section, please take a look at your convenience and let > the authors know if you see that more is needed. > > https://tools.ietf.org/html/draft-ietf-teas-yang-te-topo-16#section-8 This addresses my concerns - many thanks. I like the structure, btw. Melinda From nobody Sun Jun 10 08:04:56 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A51FF130E48; Sun, 10 Jun 2018 04:56:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1528631784; bh=QM/i7W13y1vVcxl2U8l88ZP6ZkktSsmrv38mgIDU78Q=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Cc; b=XoAOdSZOxv+WD/k9L7hsvqm5daS/iLSQZX08SPM4BU1qHN5hgtUpKQPXRAtpbch8O m+imOIAWRfu1qEGUdPx9AUGFvZdF1S02piXx8NABmNB54tqRwWPjFC6QYhXZQsjje4 uH16ecMPy1v9b1h6IapxeAufBWfefqjbrqYd5K/g= X-Mailbox-Line: From new-work-bounces@ietf.org Sun Jun 10 04:56:24 2018 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C385B130E3C; Sun, 10 Jun 2018 04:56:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1528631783; bh=/3ps2uEBcGo+gcWkQZaipV0atHC2VRbKpMsuOlzi55s=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Cc; b=EbXnF22z+3JH4I96jOxlcvBRmzELdjG1UvoqCY5x9FUYFdmM6TkLOvEkApuCswa7S Q3JvJJLH3/eKid8MV9JSSWZyC7ED99wtlIdjblmbs2++KypL8BQzmpSilxSwHA8cT4 VZ7rlpAnep4ORsiFaWH6iEj/ZPApVHdRkQUvpoOg= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 686A6130E3C for ; Sun, 10 Jun 2018 04:56:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 2IPIYIAk0CKL for ; Sun, 10 Jun 2018 04:56:19 -0700 (PDT) Received: from mail-pl0-x22f.google.com (mail-pl0-x22f.google.com [IPv6:2607:f8b0:400e:c01::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 38AD2130E35 for ; Sun, 10 Jun 2018 04:56:19 -0700 (PDT) Received: by mail-pl0-x22f.google.com with SMTP id g20-v6so10752115plq.1 for ; Sun, 10 Jun 2018 04:56:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:mime-version:thread-index :content-language; bh=DnVLIyxhcL3hBuWMwPA1zsgo+kQNJWBqEKlRHTxyq60=; b=gvpNJpg0SURJ01J9xnEEBWz7t+xoQHgwVxQuht73+d7orKXawy2SdwQ6bdYoxINM6I 1IWb3OCo7ot1L9FFjvnGnTuDaVuUOVCR2f2pvxmJIeLNvrai6LCumKDHzpGA22uYM6uP cP1JTKM3NJ9kKaZGqZ4gZcX9Rfq+QrRjawmwY5gTkboZtG31Sg2SAVr6q7cjLGQHD0KC 0Z0/Kg4QZAthJZpu7MH2k3gQFk4R3LjDe99Sv8PY4dfPMOzTssMVTYJypCXTUFSEmEEh w4jNwjYtVOPUpXUU5fE1Fj+0ipD3GLkb6qQDLRgHn8yBM1hG++QBRwaU69i2d2W7Ib2r oOUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :thread-index:content-language; bh=DnVLIyxhcL3hBuWMwPA1zsgo+kQNJWBqEKlRHTxyq60=; b=LqkQStKaG3t4DIzR7NtWCQAgAiuLyYI8ByzuWmRqkDkh6f0WyLqTwurMNHxc9Rokuw 6Bi00lnRkmAH9FkeB8M7Q2rfqcb1FS2609/1R0uV4NMC8spQlODO61eEZgWo9Rk/U73l L/lJk+rx55Wuce9ZbHWDo4tndsdEffE1mxhplJ2utwUEh+eXetWAXQxUs8gZqDWNNEoO BWqQcInMAK3DzF/MnND7I2Uv/OvceykmbimiAJ/3MLV85oT1K7o6+NlE81OgGu3ItnLo ZeZq4NV53gczfDnKQ6fLgXZtBC7gLPcWvC5VMpi0UTby1JiqCf7q/sG+zzlVRyJABzoy jaCA== X-Gm-Message-State: APt69E1QQ/KWuce7LXYuxDzV6KE5aBe4fOa5Eln0Mc2hvYD4tVEPbVqo MHKVDJM0qQevHKSn+FCdOrA= X-Google-Smtp-Source: ADUXVKJGiGrm/Ow0G4N2t+cDMKRgZHX9MRmN542o/Cb58V4r20pKJHUdYTtC1cjeBBskvnFvBk9IOw== X-Received: by 2002:a17:902:9004:: with SMTP id a4-v6mr14188270plp.143.1528631778826; Sun, 10 Jun 2018 04:56:18 -0700 (PDT) Received: from DESKTOPGUNUVB7 ([101.102.139.190]) by smtp.gmail.com with ESMTPSA id x8-v6sm36237749pfa.87.2018.06.10.04.56.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 10 Jun 2018 04:56:18 -0700 (PDT) From: "John DAmbrosia" To: Date: Sun, 10 Jun 2018 07:56:19 -0400 Message-ID: <0d3301d400b2$0daf06a0$290d13e0$@gmail.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdQAsZUzPsodmkZMRLCt8ztafLfpBQ== Content-Language: en-us Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.26 Precedence: list Cc: "'Stanley, Dorothy'" , 'Paul Nikolich' Content-Type: multipart/mixed; boundary="===============8982819601394008839==" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Sun, 10 Jun 2018 08:04:55 -0700 Subject: [secdir] [new-work] IEEE 802 Jul 2018 PARs Under Consideration X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2018 11:56:27 -0000 This is a multipart message in MIME format. --===============8982819601394008839== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0D34_01D40090.869E7810" Content-Language: en-us This is a multipart message in MIME format. ------=_NextPart_000_0D34_01D40090.869E7810 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit All, The following Project Authorization Requests (PARs) will be considered at the IEEE 802 July 2018 Plenary: The PARs can be found at http://www.ieee802.org/PARs.shtml along with the supporting IEEE 802 Criteria for Standards Development, or CSD, (which includes the 5 criteria, i.e. the explanations of how they fit the IEEE 802 criteria for initiating new work). 802.1Qcr - Amendment: Asynchronous Traffic Shaping, PAR Modification and CSD * 802.1Qcz - Amendment: Congestion Isolation, PAR and CSD * 802.1Qdd - Amendment: Resource Allocation Protocol, PAR and CSD * 802.3cn - Amendment: 50 Gb/s, 100 Gb/s, 200 Gb/s, and 400 Gb/s Operation over Single-Mode Fiber and DWDM (dense wavelength division multiplexing) systems, PAR and CSD * 802.11ax - Amendment: High Efficiency WLAN, PAR Extension and CSD Modification Any comments on a proposed PAR should be sent to the Working Group chair identified on the PAR to be received by 6:30 PM (San Diego, CA, USA, PST ), Tuesday, July10 (1:30am UTC, July 11, 2018) Regards, John D'Ambrosia Recording Secretary, IEEE 802 LMSC ------=_NextPart_000_0D34_01D40090.869E7810 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable IEEE 802 Jul 2018 PARs Under Consideration

All,

The following Project Authorization Requests (PARs) will = be considered at the IEEE 802 July = 2018 Plenary:

The PARs can be found at http://www.ieee802.org/PARs.shtml along with the supporting IEEE 802 Criteria for = Standards Development, or CSD, (which includes the 5 criteria, i.e. the = explanations of how they fit the IEEE 802 criteria for initiating new = work). 802.1Qcr - Amendment: Asynchronous Traffic = Shaping, PAR Modification and = CSD

·       = 802.1Qcz - Amendment: = Congestion Isolation, PAR = and CSD =

·       802.1Qdd – Amendment: = Resource Allocation Protocol, = PAR = and CSD

·       802.3cn - Amendment: 50 Gb/s, = 100 Gb/s, 200 Gb/s, and 400 Gb/s Operation over Single-Mode Fiber and = DWDM (dense wavelength division multiplexing) = systems, PAR = and CSD

·       802.11ax - Amendment: High = Efficiency WLAN, PAR Extension and = CSD Modification

Any comments on a proposed PAR should be sent to the = Working Group chair identified on the PAR to be received by 6:30 PM = (San Diego, CA, USA, PST ), = Tuesday, = July10 (1:30am = UTC, July 11, 2018)

Regards,

John D’Ambrosia

Recording Secretary, IEEE 802 LMSC

------=_NextPart_000_0D34_01D40090.869E7810-- --===============8982819601394008839== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work --===============8982819601394008839==-- From nobody Mon Jun 11 09:58:43 2018 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 51CFC130E76; Mon, 11 Jun 2018 09:58:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Paul Wouters To: Cc: dcrup@ietf.org, ietf@ietf.org, draft-ietf-dcrup-dkim-crypto.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152873631529.2793.6649645368844625316@ietfa.amsl.com> Date: Mon, 11 Jun 2018 09:58:35 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-dcrup-dkim-crypto-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.26 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2018 16:58:36 -0000 Reviewer: Paul Wouters Review result: Has Nits NITS: I believe the [FIPS-180-4-2015] reference should be replaced with a reference to RFC-6376 Remove or indicate the RFC Editor should remove the following text: Discussion Venue: Discussion about this draft is directed to the dcrup@ietf.org [1] mailing list. This sentence doesn't parse easily: This is an additional DKIM signature algorithm added to Section 3.3 of [RFC6376] as envisioned in Section 3.3.4 of [RFC6376]. It should simply say something like "This document adds an additional key algorithm type to the DKIM Key Type Registry and a new signature type to the DKIM Hash Algorithms Registry" This text reads a little odd: Ed25519 is a widely used cryptographic technique, so the security of DKIM signatures using new signing algorithms should be at least as good as those using old algorithms. It seems to suggest that being "widely used" is a guarantee for being "at least as good as older stuff". Better would be to just point to the Security Considerations of RFC 8032 Section 4 and 8 have an introductory lines that says "update as follows" followed by a dot instead of a colon. That is a little confusing to the reader, as if some text is missing before the dot. From nobody Tue Jun 12 17:55:41 2018 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 2A255130DC5; Tue, 12 Jun 2018 17:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9z9XhhQYqn0O; Tue, 12 Jun 2018 17:55:36 -0700 (PDT) Received: from mail-pl0-x242.google.com (mail-pl0-x242.google.com [IPv6:2607:f8b0:400e:c01::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AC7A12F1AB; Tue, 12 Jun 2018 17:55:33 -0700 (PDT) Received: by mail-pl0-x242.google.com with SMTP id b14-v6so474655pls.5; Tue, 12 Jun 2018 17:55:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=Z1cnwK4VlGFflP8D+7Y6CyCFpZrskj0p4WkQSzjQ7/o=; b=FxrQx6DrikWx8eCzoZJqhDFtM3slIdWqlsgFq5//byvvru37VXA9LeQpEUosxMEZuD hSL2mf3jbqHtF9nLFMXrfgSCBr2a7FuGgJ7nhPbKOlJMit27aJVbLG8FoqvsQBQWeTXz ppo39FlaX/DcbHiL8QVigAFiPGih7q2NYVlZN922sJhEcSMcePsrLqeQPSGFQUeqERpl BoMlRDHHxzu0dDl7eSwK2zD/R5JRNEi7t65fz7HKiSZdkXFMzjaVilWAdpvzC9aYqTPZ rPfV8ks+8uqwJgxtBkdSqKBhbIL+0l29KKyyGV4LGKl6PAaxiYaQvN4ESI0KgFjdRzRb Xj4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=Z1cnwK4VlGFflP8D+7Y6CyCFpZrskj0p4WkQSzjQ7/o=; b=H5THf5NVwjEDBOY9shefYeE2wAIdukg/WXRYKTk0YpweiesHqdmyvktjfIH5NgOBxN Qw4jFHtX9S4hx361zzc/mRpC3BTNkjUzN86oNgre0kc5TfA+ghOA4/O+MkpsXL9kUZE/ 2Hynjy1fNruGtBMe7hGfLJUypuZpX1pDIijNKJUQwW7bjQmaB7G0aWC7fp41TVXWHPgC d3dxQRgaijzFOJi5/MgBiHMHJ/S/K24GcANCU9NTi7/IX1nCeyFvqoAWuWdlF8SZJYkm W7ymCNffCDgQb61uBpn1Mx6/Ij2aeHTg+R3m20sqpoTt54fuvsnEVLEcv0VK2TKpVD3C SUxA== X-Gm-Message-State: APt69E1c1KH7VEjryQBvEjfDaZLWXBgVL6dlEGsFLANillNQ2dckmzKk dCCAmAxqzztHrdtB+heqwB7Zsidm X-Google-Smtp-Source: ADUXVKL9o/CnjI1V3Hjlxc7btC1ue3D6HTQIb1sV1Vk68gSNS2AedFLhhYMvIwdMpf6XhIjQm5xnGw== X-Received: by 2002:a17:902:145:: with SMTP id 63-v6mr2783807plb.332.1528851332355; Tue, 12 Jun 2018 17:55:32 -0700 (PDT) Received: from [10.132.58.100] ([66.155.106.22]) by smtp.gmail.com with ESMTPSA id l8-v6sm1931544pfb.102.2018.06.12.17.55.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Jun 2018 17:55:31 -0700 (PDT) From: "Christopher Wood" To: iesg@ietf.org, secdir@ietf.org, draft-ietf-oauth-device-flow.all@ietf.org Date: Tue, 12 Jun 2018 17:55:22 -0700 X-Mailer: MailMate (1.11.2r5479) Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [secdir] secdir review of draft-ietf-oauth-device-flow X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 00:55:38 -0000 Hello, 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 my review is: Ready with nits. Overall, the document is in fine shape. I have a few general comments (not quite nits, though not quite issues either), listed below: - Section 3.5, fifth paragraph: Requiring clients to poll at a “reasonable” polling interval without a suggestion of what is reasonable seems strange. Could you suggest a value that’s within reason, e.g., every second? - Section 5.1, first paragraph: It might be useful to point to Section 6.1 wherein User Code generation is discussed. Right now minimum entropy “requirements” are listed without further details regarding viable mechanisms. - Section 5.2, second paragraph: The text claims that an end user would end up “on the authorization page of the wrong service.” Can you provide more details here? What stops the malicious MITM from serving an authorization page that’s indistinguishable from the legitimate service page? - Section 5.3, first paragraph: How specifically does the authorization service prevent devices from lying when providing “information about the device”? Or, alternatively, how does the authorization service learn this information? - Section 5.4: Would it be useful to suggest that clients SHOULD use a secure (encrypted and authenticated) channel when communicating to the user device? The remainder of my comments, listed below, are editorial in nature, aimed towards improving readability of the document. - Section 1, step (E): This is the first time client polling is mentioned without discussion of timeouts or server-generated errors. The draft provides such details later on, so it would be helpful to allude or point to them here. - Section 3.3, second paragraph: Please cite TLS upon use (“… in a secure TLS-protected session.”). - Section 3.3, second paragraph: The text suggests that the server informs the user to “return to their device.” Perhaps this should be prefaced with a MAY, as the client will eventually learn that authorization is complete upon polling. - Section 3.3.1, first paragraph: Should it be required that “verification_uri_complete” is constructed in part from the “verification_uri” and “user_code”? I’m not sure this is necessary, though the example given is constructed this way. If not required, this might be worth noting. - Section 3.5, first paragraph: s/token endpoint/authentication server? - Section 5.1, third paragraph: This text is mostly redundant with the preceding paragraphs. I would remove or merge it with the paragraphs above. Please let me know if you’ve further questions, comments, or concerns. I hope this helps. Best, Chris From nobody Wed Jun 13 02:20:22 2018 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 6CB97130E0A; Wed, 13 Jun 2018 02:20:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 8E1bXcuMq-Ap; Wed, 13 Jun 2018 02:20:14 -0700 (PDT) Received: from orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A33EC130EB2; Wed, 13 Jun 2018 02:20:14 -0700 (PDT) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 2D3EEC078D; Wed, 13 Jun 2018 11:20:13 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.58]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 01E08120083; Wed, 13 Jun 2018 11:20:13 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM33.corporate.adroot.infra.ftgroup ([fe80::3881:fc15:b4b2:9017%19]) with mapi id 14.03.0389.001; Wed, 13 Jun 2018 11:20:12 +0200 From: To: Sean Turner , "secdir@ietf.org" CC: "draft-ietf-sfc-hierarchical.all@ietf.org" , "ietf@ietf.org" , "sfc@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-sfc-hierarchical-08 Thread-Index: AQHT91gIey1rcuKs3U+uFAmpphPKT6Rd/37g Date: Wed, 13 Jun 2018 09:20:12 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DF357C6@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <152760355124.12572.4328281075629737814@ietfa.amsl.com> In-Reply-To: <152760355124.12572.4328281075629737814@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.2] 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-sfc-hierarchical-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 09:20:20 -0000 SGkgU2VhbiwgDQoNClRoYW5rIHlvdS4NCg0KRmlndXJlIDQgaXMgcHJvdmlkZWQgYXMgKiogYW4g ZXhhbXBsZSAqKiB0byBpbGx1c3RyYXRlIGhvdyB0aGUgZmxvdyBJRCBjYW4gYmUgcGxhY2VkIG9u IHRoZSBOU0guIFRoaXMgaXMgbm90IG5vcm1hdGl2ZS4gICANCg0KQ2hlZXJzLA0KTWVkDQoNCj4g LS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IFNlYW4gVHVybmVyIFttYWlsdG86 c2VhbkBzbjNyZC5jb21dDQo+IEVudm95w6nCoDogbWFyZGkgMjkgbWFpIDIwMTggMTY6MTkNCj4g w4DCoDogc2VjZGlyQGlldGYub3JnDQo+IENjwqA6IGRyYWZ0LWlldGYtc2ZjLWhpZXJhcmNoaWNh bC5hbGxAaWV0Zi5vcmc7IGlldGZAaWV0Zi5vcmc7IHNmY0BpZXRmLm9yZw0KPiBPYmpldMKgOiBT ZWNkaXIgbGFzdCBjYWxsIHJldmlldyBvZiBkcmFmdC1pZXRmLXNmYy1oaWVyYXJjaGljYWwtMDgN Cj4gDQo+IFJldmlld2VyOiBTZWFuIFR1cm5lcg0KPiBSZXZpZXcgcmVzdWx0OiBSZWFkeQ0KPiAN Cj4gSGkhIEnigJltIG5vIGV4cGVydCBvbiBTRkMgc28gSSBzcGVudCBzb21lIHRpbWUgcmV2aWV3 aW5nIFJGQzc2NjUgYW5kIFNpbW9uDQo+IEpvc2Vmc3NvbuKAmXMgc2VjZGlyIHJldmlldyBbMF0g YXMgd2VsbCBhcyBSRkMgODMwMCBhbmQgODM5My4gIEl0IGxvb2tzIGxpa2UNCj4gYWxsDQo+IHRo ZSB0aGluZ3MgSSB3YXMgZ29pbmcgdG8gcGljayBvbiBhcmUgYWRkcmVzc2VkIGJ5IHRoZSByZWZl cmVuY2VzLg0KPiANCj4gSeKAmWxsIGxldCBzb21lYm9keSBlbHNlIG9uIHRoZSBJRVNHIGRlYmF0 ZSB3aGV0aGVyIEZpZ3VyZSA0IGlzIHRyeWluZyB0byBiZSBhDQo+IGxpdHRsZSBkaWZmZXJlbnQg dGhhbiB0aGUgcmVzdCBvZiB0aGlzIGFyY2hpdGVjdHVyYWwgZG9jdW1lbnQgYnkgc3BlY2lmeSBz b21lDQo+IHByb3RvY29scyBiaXRzOyBpbmZvcm1hdGlvbmFsIHN0aWxsPw0KPiANCj4gWzBdDQo+ IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL3Jldmlldy1pZXRmLXNmYy1hcmNoaXRl Y3R1cmUtMDgtc2VjZGlyLWxjLQ0KPiBqb3NlZnNzb24tMjAxNS0wNS0yOC8NCg0K From nobody Wed Jun 13 12:26:15 2018 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 788C012426A; Wed, 13 Jun 2018 12:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oaj9l5V0qxo8; Wed, 13 Jun 2018 12:26:12 -0700 (PDT) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (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 E6E1F130E87; Wed, 13 Jun 2018 12:26:11 -0700 (PDT) Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id w5DJQAg8043882; Wed, 13 Jun 2018 15:26:10 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu w5DJQAg8043882 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1528917970; bh=nX/nmiqXsDnszYneujh4erHhVwFGezsm7fzaWb85FpE=; h=From:To:Subject:Date:From; b=rVsHaaYOd07u77+IzbQJydf2AQ4DkRLXkvylrh0IaOuxB3T75U4tKa9igV3XEnVn8 gioLBVg/RYwy/ozHuY50QkI0jFSpaIw4yIF2gd4LpIIOWaPrFzT742lyLHH1IFADgx 0d7u00U+ZqOG2tzMQmMxN/3k1y/zHjwCobJogGJE= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id w5DJQ7JT008782; Wed, 13 Jun 2018 15:26:07 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0399.000; Wed, 13 Jun 2018 15:26:07 -0400 From: Roman Danyliw To: "draft-ietf-teas-actn-info-model@ietf.org" , "secdir@ietf.org" Thread-Topic: Secdir review of draft-ietf-teas-actn-info-model-08 Thread-Index: AdQDOhTrKf9Z1zyVTi6xa900/JYx/g== Date: Wed, 13 Jun 2018 19:26:06 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC014C3E8109@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [secdir] Secdir review of draft-ietf-teas-actn-info-model-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 19:26:15 -0000 Reviewer: Roman Danyliw Review result: Ready with 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 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. The summary of the review is Ready with nits. My feedback is as follows: (1) Section 9, Security Considerations, Page 21, Paragraph 1 [original text] The ACTN information model described in this document defines key interfaces for managed traffic engineered networks. Securing the request and control of resources, confidentiality of the information, and availability of function, should all be critical security considerations when deploying and operating ACTN platforms. [feedback] This section (Section 9) reads to me as if it is describing more than just = the information model. The text appears to be identical to the security co= nsiderations in draft-ietf-teas-actn-framework-15. IMO, the text here woul= d benefit from tighter scoping. Perhaps something like: "The ACTN information model does not directly introduce security issues. R= ather, it defines a set of interfaces for traffic engineered networks. The= underlying protocols, procedures, and implementations used to exchange the= information model described in this draft will need to secure the request = and control of resources ...: Furthermore, I assumed that "securing the request and control of resources"= was implying the need for authentication and authorization of requests. H= owever, there is no discussion of that in the subsequent text. There is al= so no subsequent discussion of the significance of availability despite it = being referenced in this paragraph. (2) Section 9, Security Considerations, Page 21, Paragraph 2 [original text] Several distributed ACTN functional components are required, and implementations should consider encrypting data that flows between components, especially when they are implemented at remote nodes, regardless of these data flows are on external or internal network interfaces. [feedback] Editorial -- This paragraph was a dense read for me. Perhaps something lik= e the following would be more approachable: "Implementations of the ACTN framework will have distributed functional com= ponents that will exchange this information model. Implementations SHOULD = encrypt data that flows between them, especially when they are implemented = at remote nodes and irrespective of whether these data flows are on externa= l or internal network interfaces." (3) Section 9, Security Considerations, Page 21, Paragraph 3 [original text] The ACTN security discussion is further split into two specific categories described in the following sub-sections: - Interface between the Customer Network Controller and Multi Domain Service Coordinator (MDSC), CNC-MDSC Interface (CMI) - Interface between the Multi Domain Service Coordinator and Provisioning Network Controller (PNC), MDSC-PNC Interface (MPI) [feedback] This sentence references additional sub-sections that don't appear to exist= -- Section 9 has no sub-sections. draft-ietf-teas-actn-framework-15 which= has identical text does have these sub-sections (Sections 9.1 and 9.2). W= ithout additional text, this paragraph doesn't add anything. If the text i= n draft-ietf-teas-actn-framework-15 is relevant, I would recommend simply r= eferencing it. (4) Section 9, Security Considerations, Page 21, Paragraph 4 [original text] From a security and reliability perspective, ACTN may encounter many risks such as malicious attack and rogue elements attempting to connect to various ACTN components. Furthermore, some ACTN components represent a single point of failure and threat vector, and must also manage policy conflicts, and eavesdropping of communication between different ACTN components. [feedback] This text identifies some of the potential threats. What mitigations shoul= d be applied? Furthermore, these threats aren't scoped within the bounds o= f the information model. I recommend revising this threat discussion to be= around the information being exchange or dropping the paragraph. (5) Section 9, Security Considerations, Page 22, Paragraph 5 [original text] The conclusion is that all data models and protocols used to realize the ACTN info model should have rich security features, and customer, application and network data should be stored in encrypted data stores. Additional security risks may still exist. Therefore, discussion and applicability of specific security functions and protocols will be better described in documents that are use case and environment specific. [feedback] Per "The conclusion is that ... should have rich security features". What = does "rich security" mean? Per "... and customer, application and network data should be stored ...", = this is a good point about encryption at rest. Is the "customer, applicati= on and network data" a more descriptive version of "data in the information= model"? If no, then it's out of scope. If yes, then I would recommend ex= plicitly stating that "The information model may contain customer, applicat= ion and network data that for business or privacy reasons may be considered= sensitive. It SHOULD be stored only in an encrypted data store". As data= in motion is discussed in paragraph 2, it might make sense to move this te= xt there. Regards, Roman From nobody Wed Jun 13 14:05:35 2018 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 99D44131021; Wed, 13 Jun 2018 14:05:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=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 1zqEmQTTg_mh; Wed, 13 Jun 2018 14:05:27 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 457EE131036; Wed, 13 Jun 2018 14:05:27 -0700 (PDT) Received: from LHREML710-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 659FE9CD36748; Wed, 13 Jun 2018 22:05:23 +0100 (IST) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.382.0; Wed, 13 Jun 2018 22:05:24 +0100 Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.141]) by SJCEML703-CHM.china.huawei.com ([169.254.5.6]) with mapi id 14.03.0382.000; Wed, 13 Jun 2018 14:05:21 -0700 From: Leeyoung To: Roman Danyliw , "draft-ietf-teas-actn-info-model@ietf.org" , "secdir@ietf.org" CC: "BRUNGARD, DEBORAH A" Thread-Topic: Secdir review of draft-ietf-teas-actn-info-model-08 Thread-Index: AdQDOhTrKf9Z1zyVTi6xa900/JYx/gAFptWQ Date: Wed, 13 Jun 2018 21:05:20 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E173D014345@sjceml521-mbx.china.huawei.com> References: <359EC4B99E040048A7131E0F4E113AFC014C3E8109@marathon> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC014C3E8109@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.218.137.166] Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E173D014345sjceml521mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [secdir] Secdir review of draft-ietf-teas-actn-info-model-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 21:05:34 -0000 --_000_7AEB3D6833318045B4AE71C2C87E8E173D014345sjceml521mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Roman, Thanks for your review of the draft and providing good comments. Please see inline for our responses to your comments. Please let us know if= our responses are satisfactory to you; if not, please provide us your furt= her comments. Thanks & Best regards, Young -----Original Message----- From: Roman Danyliw [mailto:rdd@cert.org] Sent: Wednesday, June 13, 2018 2:26 PM To: draft-ietf-teas-actn-info-model@ietf.org; secdir@ietf.org Subject: Secdir review of draft-ietf-teas-actn-info-model-08 Reviewer: Roman Danyliw Review result: Ready with 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 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. The summary of the review is Ready with nits. My feedback is as follows: (1) Section 9, Security Considerations, Page 21, Paragraph 1 [original text] The ACTN information model described in this document defines key interfaces for managed traffic engineered networks. Securing the request and control of resources, confidentiality of the information, and availability of function, should all be critical security considerations when deploying and operating ACTN platforms. [feedback] This section (Section 9) reads to me as if it is describing more than just = the information model. The text appears to be identical to the security co= nsiderations in draft-ietf-teas-actn-framework-15. IMO, the text here woul= d benefit from tighter scoping. Perhaps something like: "The ACTN information model does not directly introduce security issues. R= ather, it defines a set of interfaces for traffic engineered networks. The= underlying protocols, procedures, and implementations used to exchange the= information model described in this draft will need to secure the request = and control of resources ...: Furthermore, I assumed that "securing the request and control of resources"= was implying the need for authentication and authorization of requests. H= owever, there is no discussion of that in the subsequent text. There is al= so no subsequent discussion of the significance of availability despite it = being referenced in this paragraph. YL>> Your suggested text is very good. How about the new paragraph as follo= ws: [new] The ACTN information model does not directly introduce security issues. Rather, it defines a set of interfaces for traffic engineered networks. The underlying protocols, procedures, and implementations used to exchang= e the information model described in this draft will need to secure the req= uest and control of resources with proper authentication and authorization mechani= sms. In addition, the data exchanged over the ACTN interfaces discussed in thi= s document requires verification of data integrity. Backup or redundancies = SHOULD also be available to restore the affected data to its correct state. (2) Section 9, Security Considerations, Page 21, Paragraph 2 [original text] Several distributed ACTN functional components are required, and implementations should consider encrypting data that flows between components, especially when they are implemented at remote nodes, regardless of these data flows are on external or internal network interfaces. [feedback] Editorial -- This paragraph was a dense read for me. Perhaps something lik= e the following would be more approachable: "Implementations of the ACTN framework will have distributed functional com= ponents that will exchange this information model. Implementations SHOULD = encrypt data that flows between them, especially when they are implemented = at remote nodes and irrespective of whether these data flows are on externa= l or internal network interfaces." YL>> Thanks. I agree with your suggested text that will replace the origina= l text. (3) Section 9, Security Considerations, Page 21, Paragraph 3 [original text] The ACTN security discussion is further split into two specific categories described in the following sub-sections: - Interface between the Customer Network Controller and Multi Domain Service Coordinator (MDSC), CNC-MDSC Interface (CMI) - Interface between the Multi Domain Service Coordinator and Provisioning Network Controller (PNC), MDSC-PNC Interface (MPI) [feedback] This sentence references additional sub-sections that don't appear to exist= -- Section 9 has no sub-sections. draft-ietf-teas-actn-framework-15 which= has identical text does have these sub-sections (Sections 9.1 and 9.2). W= ithout additional text, this paragraph doesn't add anything. If the text i= n draft-ietf-teas-actn-framework-15 is relevant, I would recommend simply r= eferencing it. YL>> Correct. I think the text in draft-ietf-teas-actn-framework-15 is rele= vant. So I will reference it. So the new text will look like: [new text] The ACTN security discussion is further split into two specific interfaces: - Interface between the Customer Network Controller and Multi Domain Service Coordinator (MDSC), CNC-MDSC Interface (CMI) - Interface between the Multi Domain Service Coordinator and Provisioning Network Controller (PNC), MDSC-PNC Interface (MPI) See the detailed discussion of the CMI and MPI in Sections 9.1 and 9.2, res= pectively in [ACTN-Frame]. (4) Section 9, Security Considerations, Page 21, Paragraph 4 [original text] From a security and reliability perspective, ACTN may encounter many risks such as malicious attack and rogue elements attempting to connect to various ACTN components. Furthermore, some ACTN components represent a single point of failure and threat vector, and must also manage policy conflicts, and eavesdropping of communication between different ACTN components. [feedback] This text identifies some of the potential threats. What mitigations shoul= d be applied? Furthermore, these threats aren't scoped within the bounds o= f the information model. I recommend revising this threat discussion to be= around the information being exchange or dropping the paragraph. YL>> Thanks. I would drop the paragraph. (5) Section 9, Security Considerations, Page 22, Paragraph 5 [original text] The conclusion is that all data models and protocols used to realize the ACTN info model should have rich security features, and customer, application and network data should be stored in encrypted data stores. Additional security risks may still exist. Therefore, discussion and applicability of specific security functions and protocols will be better described in documents that are use case and environment specific. [feedback] Per "The conclusion is that ... should have rich security features". What = does "rich security" mean? YL>> for instance, encryption. Per "... and customer, application and network data should be stored ...", = this is a good point about encryption at rest. Is the "customer, applicati= on and network data" a more descriptive version of "data in the information= model"? If no, then it's out of scope. If yes, then I would recommend ex= plicitly stating that "The information model may contain customer, applicat= ion and network data that for business or privacy reasons may be considered= sensitive. It SHOULD be stored only in an encrypted data store". As data= in motion is discussed in paragraph 2, it might make sense to move this te= xt there. YL>> Yes, actually "customer, application and network data" is a more descr= iptive version of "data in the information model". As such, I would take yo= ur text to replace the first sentence of Paragraph 5 (and move it to Paragr= aph 2). So Paragraph 2 will look like: [new - Paragraph 2] Implementations of the ACTN framework will have distributed functional components that will exchange this information model. Implementations SHOULD encrypt data that flows between them, especially when they are implemented at remote nodes and irrespective of whether these data flows are on external or internal network interfac= es. The information model may contain customer, application and network data that for business or privacy reasons may be considered sensitive. It SHOULD be stored only in an encrypted data store. [new - Paragraph 5] The conclusion is that all data models and protocols used to realize the ACTN info model should have rich security features as discussed in this section. Additional security risks may still exist. Therefore, discussion and applicability of specific security functions and protocols will be better described in documents that are use case and environment specific. Regards, Roman --_000_7AEB3D6833318045B4AE71C2C87E8E173D014345sjceml521mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Roman,

 

Thanks for your review of the draft and providing= good comments.

 

Please see inline for our responses to your comme= nts. Please let us know if our responses are satisfactory to you; if not, p= lease provide us your further comments.

 

Thanks & Best regards,

Young

 

-----Original Message-----
From: Roman Danyliw [mailto:rdd@cert.org]
Sent: Wednesday, June 13, 2018 2:26 PM
To: draft-ietf-teas-actn-info-model@ietf.org; secdir@ietf.org
Subject: Secdir review of draft-ietf-teas-actn-info-model-08

 

Reviewer: Roman Danyliw

Review result: Ready with nits

 

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 benefi= t 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.

 

My feedback is as follows:

 

(1) Section 9, Security Considerations, Page 21, = Paragraph 1

 

[original text]

   The ACTN information model described= in this document defines key

   interfaces for managed traffic engin= eered networks.  Securing the

   request and control of resources, co= nfidentiality of the

   information, and availability of fun= ction, should all be critical

   security considerations when deployi= ng and operating ACTN platforms.

 

[feedback]

 

This section (Section 9) reads to me as if it is = describing more than just the information model.  The text appears to = be identical to the security considerations in draft-ietf-teas-actn-framewo= rk-15.  IMO, the text here would benefit from tighter scoping.  Perhaps something like:

 

"The ACTN information model does not directl= y introduce security issues.  Rather, it defines a set of interfaces f= or traffic engineered networks.  The underlying protocols, procedures,= and implementations used to exchange the information model described in this draft will need to secure the request and control = of resources ...:

 

Furthermore, I assumed that "securing the re= quest and control of resources" was implying the need for authenticati= on and authorization of requests.  However, there is no discussion of = that in the subsequent text.  There is also no subsequent discussion of the significance of availability despite it being referenced= in this paragraph.

 

YL>> Your = suggested text is very good. How about the new paragraph as follows:

 

[new]=

   The= ACTN information model does not directly introduce security issues. 

  &nbs= p;Rather, it defines a set of interfaces for traffic engineered networks.&n= bsp;

  The = underlying protocols, procedures, and implementations used to exchange

  the = information model described in this draft will need to secure the request a= nd

  cont= rol of resources with proper authentication and authorization mechanisms.

  In a= ddition, the data exchanged over the ACTN interfaces discussed in this

  docu= ment requires verification of data integrity. Backup or redundancies SHOULD

  also= be available to restore the affected data to its correct state.  

 

(2) Section 9, Security Considerations, Page 21, = Paragraph 2

 

[original text]

   Several distributed ACTN functional = components are required, and

   implementations should consider encr= ypting data that flows between

   components, especially when they are= implemented at remote nodes,

   regardless of these data flows are o= n external or internal network

   interfaces.

 

[feedback]

 

Editorial -- This paragraph was a dense read for = me.  Perhaps something like the following would be more approachable:<= o:p>

 

"Implementations of the ACTN framework will = have distributed functional components that will exchange this information = model.  Implementations SHOULD encrypt data that flows between them, e= specially when they are implemented at remote nodes and irrespective of whether these data flows are on external or inte= rnal network interfaces."

 

YL>> Thank= s. I agree with your suggested text that will replace the original text.

 

(3) Section 9, Security Considerations, Page 21, = Paragraph 3

 

[original text]

   The ACTN security discussion is furt= her split into two specific

   categories described in the followin= g sub-sections:

 

   - Interface between the Customer Net= work Controller and Multi Domain

     Service Coordinator (MDS= C), CNC-MDSC Interface (CMI)

 

   - Interface between the Multi Domain= Service Coordinator and

     Provisioning Network Con= troller (PNC), MDSC-PNC Interface (MPI)

 

[feedback]

 

This sentence references additional sub-sections = that don't appear to exist -- Section 9 has no sub-sections.  draft-ie= tf-teas-actn-framework-15 which has identical text does have these sub-sect= ions (Sections 9.1 and 9.2).  Without additional text, this paragraph doesn't add anything.  If the text in draft-ietf= -teas-actn-framework-15 is relevant, I would recommend simply referencing i= t.

 

YL>> Corre= ct. I think the text in draft-ietf-teas-actn-framework-15 is relevant. So I= will reference it. So the new text will look like:

 

[new text]<= /o:p>

   The= ACTN security discussion is further split into two specific

   int= erfaces:

 

   - I= nterface between the Customer Network Controller and Multi Domain

  &nbs= p;  Service Coordinator (MDSC), CNC-MDSC Interface (CMI)

 

   - I= nterface between the Multi Domain Service Coordinator and=

  &nbs= p;  Provisioning Network Controller (PNC), MDSC-PNC Interface (MPI)

 

See the detailed= discussion of the CMI and MPI in Sections 9.1 and 9.2, respectively in [AC= TN-Frame].

 

 

(4) Section 9, Security Considerations, Page 21, = Paragraph 4

 

[original text]

   From a security and reliability pers= pective, ACTN may encounter many

   risks such as malicious attack and r= ogue elements attempting to

   connect to various ACTN components.&= nbsp; Furthermore, some ACTN

   components represent a single point = of failure and threat vector,

   and must also manage policy conflict= s, and eavesdropping of

   communication between different ACTN= components.

 

[feedback]

 

This text identifies some of the potential threat= s.  What mitigations should be applied?  Furthermore, these threa= ts aren't scoped within the bounds of the information model.  I recomm= end revising this threat discussion to be around the information being exchange or dropping the paragraph.

 

YL>> Thank= s. I would drop the paragraph.

 

(5) Section 9, Security Considerations, Page 22, = Paragraph 5

 

[original text]

   The conclusion is that all data mode= ls and protocols used to realize

   the ACTN info model should have rich= security features, and

   customer, application and network da= ta should be stored in encrypted

   data stores.  Additional securi= ty risks may still exist.  Therefore,

   discussion and applicability of spec= ific security functions and

   protocols will be better described i= n documents that are use case

   and environment specific.=

 

[feedback]

 

Per "The conclusion is that ... should have = rich security features".  What does "rich security" mea= n?

 

YL>> for i= nstance, encryption.

 

Per "... and customer, application and netwo= rk data should be stored ...", this is a good point about encryption a= t rest.  Is the "customer, application and network data" a m= ore descriptive version of "data in the information model"?  If no, then it's out of scope.  If yes, then I would recommend explic= itly stating that "The information model may contain customer, applica= tion and network data that for business or privacy reasons may be considere= d sensitive.  It SHOULD be stored only in an encrypted data store".  As data in motion is discussed in par= agraph 2, it might make sense to move this text there.

 

YL>> Yes, = actually "customer, application and network data" is a more descr= iptive version of "data in the information model". As such, I wou= ld take your text to replace the first sentence of Paragraph 5 (and move it to Paragraph 2). So Paragraph 2 will look like:

 

[new – Par= agraph 2]

   Imp= lementations of the ACTN framework will have distributed

  &nbs= p;functional components that will exchange this information model. 

  &nbs= p;Implementations SHOULD encrypt data that flows between them,

  &nbs= p;especially when they are implemented at remote nodes and irrespective

  &nbs= p;of whether these data flows are on external or internal network interface= s.

  &nbs= p;The information model may contain customer, application and network

  &nbs= p;data that for business or privacy reasons may be considered sensitive.&nb= sp;

  &nbs= p;It SHOULD be stored only in an encrypted data store.

 

[new – Par= agraph 5]

   The= conclusion is that all data models and protocols used to realize

   the= ACTN info model should have rich security features as discussed=

   in = this section. Additional security risks may still exist.  Therefore,

   dis= cussion and applicability of specific security functions and

   pro= tocols will be better described in documents that are use case

   and= environment specific.

 

Regards,

Roman

--_000_7AEB3D6833318045B4AE71C2C87E8E173D014345sjceml521mbxchi_-- From nobody Thu Jun 14 22:28:03 2018 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 6E138130DC7; Thu, 14 Jun 2018 22:27:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Christian Huitema To: Cc: rtg-bfd@ietf.org, draft-ietf-bfd-yang.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152904046940.26576.5655178143666756803@ietfa.amsl.com> Date: Thu, 14 Jun 2018 22:27:49 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-bfd-yang-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.26 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2018 05:27:50 -0000 Reviewer: Christian Huitema Review result: Ready I already reviewed version 9 of this draft. The changes since then include more precise syntax definitions, a list of examples, and an extended security section. The security extensions outline the issues with even read-only disclosure of sensitive information, which is a welcome addition to the draft. >From a security point of view, this draft seems ready. From nobody Fri Jun 15 05:44:24 2018 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 51737130E5C; Fri, 15 Jun 2018 05:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C5ntPRwSoxhM; Fri, 15 Jun 2018 05:44:18 -0700 (PDT) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (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 E3990130E0F; Fri, 15 Jun 2018 05:44:17 -0700 (PDT) Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id w5FCi8r4027957; Fri, 15 Jun 2018 08:44:08 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu w5FCi8r4027957 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1529066648; bh=Rcf1v84EkDf9AevWDyMN0x/2pkE0B1sbRrAvKyY0NeY=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=ak1GEX3uYxgUp4iVd+bYK0LGH/7Xxt99Ci3XD9Av2YiyhDt6UQAtoOPoBmzkPfOHg tpi5k/T7ZLOO85+ZXQnb5aJgj+hrQYvLADM7XK7fDSYpY2ZdgwmoP1vPDBgtjnfrVm OIMHusg6eVQDo04AMS9T1WMOZ8W3Ib9d4Vw09VJ4= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id w5FCi72Z026222; Fri, 15 Jun 2018 08:44:08 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0399.000; Fri, 15 Jun 2018 08:44:07 -0400 From: Roman Danyliw To: Leeyoung , "draft-ietf-teas-actn-info-model@ietf.org" , "secdir@ietf.org" CC: "BRUNGARD, DEBORAH A" Thread-Topic: Secdir review of draft-ietf-teas-actn-info-model-08 Thread-Index: AdQDOhTrKf9Z1zyVTi6xa900/JYx/gAFptWQAFUtTCA= Date: Fri, 15 Jun 2018 12:44:06 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC014C3E9923@marathon> References: <359EC4B99E040048A7131E0F4E113AFC014C3E8109@marathon> <7AEB3D6833318045B4AE71C2C87E8E173D014345@sjceml521-mbx.china.huawei.com> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E173D014345@sjceml521-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: multipart/alternative; boundary="_000_359EC4B99E040048A7131E0F4E113AFC014C3E9923marathon_" MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] Secdir review of draft-ietf-teas-actn-info-model-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2018 12:44:22 -0000 --_000_359EC4B99E040048A7131E0F4E113AFC014C3E9923marathon_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Young! All of your proposed changes below address my concerns. Thanks for the qui= ck turn-around. Cheers, Roman From: Leeyoung [mailto:leeyoung@huawei.com] Sent: Wednesday, June 13, 2018 5:05 PM To: Roman Danyliw ; draft-ietf-teas-actn-info-model@ietf.org;= secdir@ietf.org Cc: BRUNGARD, DEBORAH A Subject: RE: Secdir review of draft-ietf-teas-actn-info-model-08 Hi Roman, Thanks for your review of the draft and providing good comments. Please see inline for our responses to your comments. Please let us know if= our responses are satisfactory to you; if not, please provide us your furt= her comments. Thanks & Best regards, Young -----Original Message----- From: Roman Danyliw [mailto:rdd@cert.org] Sent: Wednesday, June 13, 2018 2:26 PM To: draft-ietf-teas-actn-info-model@ietf.org; secdir@ietf.org Subject: Secdir review of draft-ietf-teas-actn-info-model-08 Reviewer: Roman Danyliw Review result: Ready with 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 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. The summary of the review is Ready with nits. My feedback is as follows: (1) Section 9, Security Considerations, Page 21, Paragraph 1 [original text] The ACTN information model described in this document defines key interfaces for managed traffic engineered networks. Securing the request and control of resources, confidentiality of the information, and availability of function, should all be critical security considerations when deploying and operating ACTN platforms. [feedback] This section (Section 9) reads to me as if it is describing more than just = the information model. The text appears to be identical to the security co= nsiderations in draft-ietf-teas-actn-framework-15. IMO, the text here woul= d benefit from tighter scoping. Perhaps something like: "The ACTN information model does not directly introduce security issues. R= ather, it defines a set of interfaces for traffic engineered networks. The= underlying protocols, procedures, and implementations used to exchange the= information model described in this draft will need to secure the request = and control of resources ...: Furthermore, I assumed that "securing the request and control of resources"= was implying the need for authentication and authorization of requests. H= owever, there is no discussion of that in the subsequent text. There is al= so no subsequent discussion of the significance of availability despite it = being referenced in this paragraph. YL>> Your suggested text is very good. How about the new paragraph as follo= ws: [new] The ACTN information model does not directly introduce security issues. Rather, it defines a set of interfaces for traffic engineered networks. The underlying protocols, procedures, and implementations used to exchang= e the information model described in this draft will need to secure the req= uest and control of resources with proper authentication and authorization mechani= sms. In addition, the data exchanged over the ACTN interfaces discussed in thi= s document requires verification of data integrity. Backup or redundancies = SHOULD also be available to restore the affected data to its correct state. (2) Section 9, Security Considerations, Page 21, Paragraph 2 [original text] Several distributed ACTN functional components are required, and implementations should consider encrypting data that flows between components, especially when they are implemented at remote nodes, regardless of these data flows are on external or internal network interfaces. [feedback] Editorial -- This paragraph was a dense read for me. Perhaps something lik= e the following would be more approachable: "Implementations of the ACTN framework will have distributed functional com= ponents that will exchange this information model. Implementations SHOULD = encrypt data that flows between them, especially when they are implemented = at remote nodes and irrespective of whether these data flows are on externa= l or internal network interfaces." YL>> Thanks. I agree with your suggested text that will replace the origina= l text. (3) Section 9, Security Considerations, Page 21, Paragraph 3 [original text] The ACTN security discussion is further split into two specific categories described in the following sub-sections: - Interface between the Customer Network Controller and Multi Domain Service Coordinator (MDSC), CNC-MDSC Interface (CMI) - Interface between the Multi Domain Service Coordinator and Provisioning Network Controller (PNC), MDSC-PNC Interface (MPI) [feedback] This sentence references additional sub-sections that don't appear to exist= -- Section 9 has no sub-sections. draft-ietf-teas-actn-framework-15 which= has identical text does have these sub-sections (Sections 9.1 and 9.2). W= ithout additional text, this paragraph doesn't add anything. If the text i= n draft-ietf-teas-actn-framework-15 is relevant, I would recommend simply r= eferencing it. YL>> Correct. I think the text in draft-ietf-teas-actn-framework-15 is rele= vant. So I will reference it. So the new text will look like: [new text] The ACTN security discussion is further split into two specific interfaces: - Interface between the Customer Network Controller and Multi Domain Service Coordinator (MDSC), CNC-MDSC Interface (CMI) - Interface between the Multi Domain Service Coordinator and Provisioning Network Controller (PNC), MDSC-PNC Interface (MPI) See the detailed discussion of the CMI and MPI in Sections 9.1 and 9.2, res= pectively in [ACTN-Frame]. (4) Section 9, Security Considerations, Page 21, Paragraph 4 [original text] From a security and reliability perspective, ACTN may encounter many risks such as malicious attack and rogue elements attempting to connect to various ACTN components. Furthermore, some ACTN components represent a single point of failure and threat vector, and must also manage policy conflicts, and eavesdropping of communication between different ACTN components. [feedback] This text identifies some of the potential threats. What mitigations shoul= d be applied? Furthermore, these threats aren't scoped within the bounds o= f the information model. I recommend revising this threat discussion to be= around the information being exchange or dropping the paragraph. YL>> Thanks. I would drop the paragraph. (5) Section 9, Security Considerations, Page 22, Paragraph 5 [original text] The conclusion is that all data models and protocols used to realize the ACTN info model should have rich security features, and customer, application and network data should be stored in encrypted data stores. Additional security risks may still exist. Therefore, discussion and applicability of specific security functions and protocols will be better described in documents that are use case and environment specific. [feedback] Per "The conclusion is that ... should have rich security features". What = does "rich security" mean? YL>> for instance, encryption. Per "... and customer, application and network data should be stored ...", = this is a good point about encryption at rest. Is the "customer, applicati= on and network data" a more descriptive version of "data in the information= model"? If no, then it's out of scope. If yes, then I would recommend ex= plicitly stating that "The information model may contain customer, applicat= ion and network data that for business or privacy reasons may be considered= sensitive. It SHOULD be stored only in an encrypted data store". As data= in motion is discussed in paragraph 2, it might make sense to move this te= xt there. YL>> Yes, actually "customer, application and network data" is a more descr= iptive version of "data in the information model". As such, I would take yo= ur text to replace the first sentence of Paragraph 5 (and move it to Paragr= aph 2). So Paragraph 2 will look like: [new - Paragraph 2] Implementations of the ACTN framework will have distributed functional components that will exchange this information model. Implementations SHOULD encrypt data that flows between them, especially when they are implemented at remote nodes and irrespective of whether these data flows are on external or internal network interfac= es. The information model may contain customer, application and network data that for business or privacy reasons may be considered sensitive. It SHOULD be stored only in an encrypted data store. [new - Paragraph 5] The conclusion is that all data models and protocols used to realize the ACTN info model should have rich security features as discussed in this section. Additional security risks may still exist. Therefore, discussion and applicability of specific security functions and protocols will be better described in documents that are use case and environment specific. Regards, Roman --_000_359EC4B99E040048A7131E0F4E113AFC014C3E9923marathon_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Young!

 

All of your proposed c= hanges below address my concerns.  Thanks for the quick turn-around.

 

Cheers,

Roman

 

From: Leeyoung [mailto:leeyoung@huawei.com] <= br> Sent: Wednesday, June 13, 2018 5:05 PM
To: Roman Danyliw <rdd@cert.org>; draft-ietf-teas-actn-info-mo= del@ietf.org; secdir@ietf.org
Cc: BRUNGARD, DEBORAH A <db3546@att.com>
Subject: RE: Secdir review of draft-ietf-teas-actn-info-model-08

 

Hi Roman,

 

Thanks for your review of the draft and providing= good comments.

 

Please see inline for our responses to your comme= nts. Please let us know if our responses are satisfactory to you; if not, p= lease provide us your further comments.

 

Thanks & Best regards,

Young

 

-----Original Message-----
From: Roman Danyliw [mailto:rdd@cert.org]
Sent: Wednesday, June 13, 2018 2:26 PM
To: draft-ietf-= teas-actn-info-model@ietf.org; secdir@ietf.org
Subject: Secdir review of draft-ietf-teas-actn-info-model-08

 

Reviewer: Roman Danyliw

Review result: Ready with nits

 

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 benefi= t 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.

 

My feedback is as follows:

 

(1) Section 9, Security Considerations, Page 21, = Paragraph 1

 

[original text]

   The ACTN information model described= in this document defines key

   interfaces for managed traffic engin= eered networks.  Securing the

   request and control of resources, co= nfidentiality of the

   information, and availability of fun= ction, should all be critical

   security considerations when deployi= ng and operating ACTN platforms.

 

[feedback]

 

This section (Section 9) reads to me as if it is = describing more than just the information model.  The text appears to = be identical to the security considerations in draft-ietf-teas-actn-framewo= rk-15.  IMO, the text here would benefit from tighter scoping.  Perhaps something like:

 

"The ACTN information model does not directl= y introduce security issues.  Rather, it defines a set of interfaces f= or traffic engineered networks.  The underlying protocols, procedures,= and implementations used to exchange the information model described in this draft will need to secure the request and control = of resources ...:

 

Furthermore, I assumed that "securing the re= quest and control of resources" was implying the need for authenticati= on and authorization of requests.  However, there is no discussion of = that in the subsequent text.  There is also no subsequent discussion of the significance of availability despite it being referenced= in this paragraph.

 

YL>> Your = suggested text is very good. How about the new paragraph as follows:

 

[new]=

   The= ACTN information model does not directly introduce security issues. 

  &nbs= p;Rather, it defines a set of interfaces for traffic engineered networks.&n= bsp;

  The = underlying protocols, procedures, and implementations used to exchange

  the = information model described in this draft will need to secure the request a= nd

  cont= rol of resources with proper authentication and authorization mechanisms.

  In a= ddition, the data exchanged over the ACTN interfaces discussed in this

  docu= ment requires verification of data integrity. Backup or redundancies SHOULD

  also= be available to restore the affected data to its correct state.  

 

(2) Section 9, Security Considerations, Page 21, = Paragraph 2

 

[original text]

   Several distributed ACTN functional = components are required, and

   implementations should consider encr= ypting data that flows between

   components, especially when they are= implemented at remote nodes,

   regardless of these data flows are o= n external or internal network

   interfaces.

 

[feedback]

 

Editorial -- This paragraph was a dense read for = me.  Perhaps something like the following would be more approachable:<= o:p>

 

"Implementations of the ACTN framework will = have distributed functional components that will exchange this information = model.  Implementations SHOULD encrypt data that flows between them, e= specially when they are implemented at remote nodes and irrespective of whether these data flows are on external or inte= rnal network interfaces."

 

YL>> Thank= s. I agree with your suggested text that will replace the original text.

 

(3) Section 9, Security Considerations, Page 21, = Paragraph 3

 

[original text]

   The ACTN security discussion is furt= her split into two specific

   categories described in the followin= g sub-sections:

 

   - Interface between the Customer Net= work Controller and Multi Domain

     Service Coordinator (MDS= C), CNC-MDSC Interface (CMI)

 

   - Interface between the Multi Domain= Service Coordinator and

     Provisioning Network Con= troller (PNC), MDSC-PNC Interface (MPI)

 

[feedback]

 

This sentence references additional sub-sections = that don't appear to exist -- Section 9 has no sub-sections.  draft-ie= tf-teas-actn-framework-15 which has identical text does have these sub-sect= ions (Sections 9.1 and 9.2).  Without additional text, this paragraph doesn't add anything.  If the text in draft-ietf= -teas-actn-framework-15 is relevant, I would recommend simply referencing i= t.

 

YL>> Corre= ct. I think the text in draft-ietf-teas-actn-framework-15 is relevant. So I= will reference it. So the new text will look like:

 

[new text]<= /o:p>

   The= ACTN security discussion is further split into two specific

   int= erfaces:

 

   - I= nterface between the Customer Network Controller and Multi Domain

  &nbs= p;  Service Coordinator (MDSC), CNC-MDSC Interface (CMI)

 

   - I= nterface between the Multi Domain Service Coordinator and=

  &nbs= p;  Provisioning Network Controller (PNC), MDSC-PNC Interface (MPI)

 

See the detailed= discussion of the CMI and MPI in Sections 9.1 and 9.2, respectively in [AC= TN-Frame].

 

 

(4) Section 9, Security Considerations, Page 21, = Paragraph 4

 

[original text]

   From a security and reliability pers= pective, ACTN may encounter many

   risks such as malicious attack and r= ogue elements attempting to

   connect to various ACTN components.&= nbsp; Furthermore, some ACTN

   components represent a single point = of failure and threat vector,

   and must also manage policy conflict= s, and eavesdropping of

   communication between different ACTN= components.

 

[feedback]

 

This text identifies some of the potential threat= s.  What mitigations should be applied?  Furthermore, these threa= ts aren't scoped within the bounds of the information model.  I recomm= end revising this threat discussion to be around the information being exchange or dropping the paragraph.

 

YL>> Thank= s. I would drop the paragraph.

 

(5) Section 9, Security Considerations, Page 22, = Paragraph 5

 

[original text]

   The conclusion is that all data mode= ls and protocols used to realize

   the ACTN info model should have rich= security features, and

   customer, application and network da= ta should be stored in encrypted

   data stores.  Additional securi= ty risks may still exist.  Therefore,

   discussion and applicability of spec= ific security functions and

   protocols will be better described i= n documents that are use case

   and environment specific.=

 

[feedback]

 

Per "The conclusion is that ... should have = rich security features".  What does "rich security" mea= n?

 

YL>> for i= nstance, encryption.

 

Per "... and customer, application and netwo= rk data should be stored ...", this is a good point about encryption a= t rest.  Is the "customer, application and network data" a m= ore descriptive version of "data in the information model"?  If no, then it's out of scope.  If yes, then I would recommend explic= itly stating that "The information model may contain customer, applica= tion and network data that for business or privacy reasons may be considere= d sensitive.  It SHOULD be stored only in an encrypted data store".  As data in motion is discussed in par= agraph 2, it might make sense to move this text there.

 

YL>> Yes, = actually "customer, application and network data" is a more descr= iptive version of "data in the information model". As such, I wou= ld take your text to replace the first sentence of Paragraph 5 (and move it to Paragraph 2). So Paragraph 2 will look like:

 

[new – Par= agraph 2]

   Imp= lementations of the ACTN framework will have distributed

  &nbs= p;functional components that will exchange this information model. 

  &nbs= p;Implementations SHOULD encrypt data that flows between them,

  &nbs= p;especially when they are implemented at remote nodes and irrespective

  &nbs= p;of whether these data flows are on external or internal network interface= s.

  &nbs= p;The information model may contain customer, application and network

  &nbs= p;data that for business or privacy reasons may be considered sensitive.&nb= sp;

  &nbs= p;It SHOULD be stored only in an encrypted data store.

 

[new – Par= agraph 5]

   The= conclusion is that all data models and protocols used to realize

   the= ACTN info model should have rich security features as discussed=

   in = this section. Additional security risks may still exist.  Therefore,

   dis= cussion and applicability of specific security functions and

   pro= tocols will be better described in documents that are use case

   and= environment specific.

 

Regards,

Roman

--_000_359EC4B99E040048A7131E0F4E113AFC014C3E9923marathon_-- From nobody Fri Jun 15 09:42:51 2018 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 00C5D130DFB; Fri, 15 Jun 2018 09:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=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 ajT49HGhb2vq; Fri, 15 Jun 2018 09:42:46 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 BB8C212F18C; Fri, 15 Jun 2018 09:42:45 -0700 (PDT) Received: from lhreml702-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 98B7391DA5F1; Fri, 15 Jun 2018 17:42:40 +0100 (IST) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.382.0; Fri, 15 Jun 2018 17:42:42 +0100 Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.141]) by SJCEML703-CHM.china.huawei.com ([169.254.5.167]) with mapi id 14.03.0382.000; Fri, 15 Jun 2018 09:42:35 -0700 From: Leeyoung To: Roman Danyliw , "draft-ietf-teas-actn-info-model@ietf.org" , "secdir@ietf.org" CC: "BRUNGARD, DEBORAH A" Thread-Topic: Secdir review of draft-ietf-teas-actn-info-model-08 Thread-Index: AdQDOhTrKf9Z1zyVTi6xa900/JYx/gAFptWQAFUtTCAACJcF0A== Date: Fri, 15 Jun 2018 16:42:35 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E173D016E5D@sjceml521-mbx.china.huawei.com> References: <359EC4B99E040048A7131E0F4E113AFC014C3E8109@marathon> <7AEB3D6833318045B4AE71C2C87E8E173D014345@sjceml521-mbx.china.huawei.com> <359EC4B99E040048A7131E0F4E113AFC014C3E9923@marathon> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC014C3E9923@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.139.76] Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E173D016E5Dsjceml521mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [secdir] Secdir review of draft-ietf-teas-actn-info-model-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2018 16:42:49 -0000 --_000_7AEB3D6833318045B4AE71C2C87E8E173D016E5Dsjceml521mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Roman, Thanks again for your quick acknowledgement on the changes. Best regards, Young From: Roman Danyliw [mailto:rdd@cert.org] Sent: Friday, June 15, 2018 7:44 AM To: Leeyoung ; draft-ietf-teas-actn-info-model@ietf.or= g; secdir@ietf.org Cc: BRUNGARD, DEBORAH A Subject: RE: Secdir review of draft-ietf-teas-actn-info-model-08 Hi Young! All of your proposed changes below address my concerns. Thanks for the qui= ck turn-around. Cheers, Roman From: Leeyoung [mailto:leeyoung@huawei.com] Sent: Wednesday, June 13, 2018 5:05 PM To: Roman Danyliw >; draft-ietf-teas-actn= -info-model@ietf.org; secd= ir@ietf.org Cc: BRUNGARD, DEBORAH A > Subject: RE: Secdir review of draft-ietf-teas-actn-info-model-08 Hi Roman, Thanks for your review of the draft and providing good comments. Please see inline for our responses to your comments. Please let us know if= our responses are satisfactory to you; if not, please provide us your furt= her comments. Thanks & Best regards, Young -----Original Message----- From: Roman Danyliw [mailto:rdd@cert.org] Sent: Wednesday, June 13, 2018 2:26 PM To: draft-ietf-teas-actn-info-model@ietf.org; secdir@ietf.org Subject: Secdir review of draft-ietf-teas-actn-info-model-08 Reviewer: Roman Danyliw Review result: Ready with 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 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. The summary of the review is Ready with nits. My feedback is as follows: (1) Section 9, Security Considerations, Page 21, Paragraph 1 [original text] The ACTN information model described in this document defines key interfaces for managed traffic engineered networks. Securing the request and control of resources, confidentiality of the information, and availability of function, should all be critical security considerations when deploying and operating ACTN platforms. [feedback] This section (Section 9) reads to me as if it is describing more than just = the information model. The text appears to be identical to the security co= nsiderations in draft-ietf-teas-actn-framework-15. IMO, the text here woul= d benefit from tighter scoping. Perhaps something like: "The ACTN information model does not directly introduce security issues. R= ather, it defines a set of interfaces for traffic engineered networks. The= underlying protocols, procedures, and implementations used to exchange the= information model described in this draft will need to secure the request = and control of resources ...: Furthermore, I assumed that "securing the request and control of resources"= was implying the need for authentication and authorization of requests. H= owever, there is no discussion of that in the subsequent text. There is al= so no subsequent discussion of the significance of availability despite it = being referenced in this paragraph. YL>> Your suggested text is very good. How about the new paragraph as follo= ws: [new] The ACTN information model does not directly introduce security issues. Rather, it defines a set of interfaces for traffic engineered networks. The underlying protocols, procedures, and implementations used to exchang= e the information model described in this draft will need to secure the req= uest and control of resources with proper authentication and authorization mechani= sms. In addition, the data exchanged over the ACTN interfaces discussed in thi= s document requires verification of data integrity. Backup or redundancies = SHOULD also be available to restore the affected data to its correct state. (2) Section 9, Security Considerations, Page 21, Paragraph 2 [original text] Several distributed ACTN functional components are required, and implementations should consider encrypting data that flows between components, especially when they are implemented at remote nodes, regardless of these data flows are on external or internal network interfaces. [feedback] Editorial -- This paragraph was a dense read for me. Perhaps something lik= e the following would be more approachable: "Implementations of the ACTN framework will have distributed functional com= ponents that will exchange this information model. Implementations SHOULD = encrypt data that flows between them, especially when they are implemented = at remote nodes and irrespective of whether these data flows are on externa= l or internal network interfaces." YL>> Thanks. I agree with your suggested text that will replace the origina= l text. (3) Section 9, Security Considerations, Page 21, Paragraph 3 [original text] The ACTN security discussion is further split into two specific categories described in the following sub-sections: - Interface between the Customer Network Controller and Multi Domain Service Coordinator (MDSC), CNC-MDSC Interface (CMI) - Interface between the Multi Domain Service Coordinator and Provisioning Network Controller (PNC), MDSC-PNC Interface (MPI) [feedback] This sentence references additional sub-sections that don't appear to exist= -- Section 9 has no sub-sections. draft-ietf-teas-actn-framework-15 which= has identical text does have these sub-sections (Sections 9.1 and 9.2). W= ithout additional text, this paragraph doesn't add anything. If the text i= n draft-ietf-teas-actn-framework-15 is relevant, I would recommend simply r= eferencing it. YL>> Correct. I think the text in draft-ietf-teas-actn-framework-15 is rele= vant. So I will reference it. So the new text will look like: [new text] The ACTN security discussion is further split into two specific interfaces: - Interface between the Customer Network Controller and Multi Domain Service Coordinator (MDSC), CNC-MDSC Interface (CMI) - Interface between the Multi Domain Service Coordinator and Provisioning Network Controller (PNC), MDSC-PNC Interface (MPI) See the detailed discussion of the CMI and MPI in Sections 9.1 and 9.2, res= pectively in [ACTN-Frame]. (4) Section 9, Security Considerations, Page 21, Paragraph 4 [original text] From a security and reliability perspective, ACTN may encounter many risks such as malicious attack and rogue elements attempting to connect to various ACTN components. Furthermore, some ACTN components represent a single point of failure and threat vector, and must also manage policy conflicts, and eavesdropping of communication between different ACTN components. [feedback] This text identifies some of the potential threats. What mitigations shoul= d be applied? Furthermore, these threats aren't scoped within the bounds o= f the information model. I recommend revising this threat discussion to be= around the information being exchange or dropping the paragraph. YL>> Thanks. I would drop the paragraph. (5) Section 9, Security Considerations, Page 22, Paragraph 5 [original text] The conclusion is that all data models and protocols used to realize the ACTN info model should have rich security features, and customer, application and network data should be stored in encrypted data stores. Additional security risks may still exist. Therefore, discussion and applicability of specific security functions and protocols will be better described in documents that are use case and environment specific. [feedback] Per "The conclusion is that ... should have rich security features". What = does "rich security" mean? YL>> for instance, encryption. Per "... and customer, application and network data should be stored ...", = this is a good point about encryption at rest. Is the "customer, applicati= on and network data" a more descriptive version of "data in the information= model"? If no, then it's out of scope. If yes, then I would recommend ex= plicitly stating that "The information model may contain customer, applicat= ion and network data that for business or privacy reasons may be considered= sensitive. It SHOULD be stored only in an encrypted data store". As data= in motion is discussed in paragraph 2, it might make sense to move this te= xt there. YL>> Yes, actually "customer, application and network data" is a more descr= iptive version of "data in the information model". As such, I would take yo= ur text to replace the first sentence of Paragraph 5 (and move it to Paragr= aph 2). So Paragraph 2 will look like: [new - Paragraph 2] Implementations of the ACTN framework will have distributed functional components that will exchange this information model. Implementations SHOULD encrypt data that flows between them, especially when they are implemented at remote nodes and irrespective of whether these data flows are on external or internal network interfac= es. The information model may contain customer, application and network data that for business or privacy reasons may be considered sensitive. It SHOULD be stored only in an encrypted data store. [new - Paragraph 5] The conclusion is that all data models and protocols used to realize the ACTN info model should have rich security features as discussed in this section. Additional security risks may still exist. Therefore, discussion and applicability of specific security functions and protocols will be better described in documents that are use case and environment specific. Regards, Roman --_000_7AEB3D6833318045B4AE71C2C87E8E173D016E5Dsjceml521mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Roman,

 

Thanks again for your = quick acknowledgement on the changes.

 

Best regards,

Young

 

From: Roman Danyliw [mailto:rdd@cert.org] Sent: Friday, June 15, 2018 7:44 AM
To: Leeyoung <leeyoung@huawei.com>; draft-ietf-teas-actn-info-= model@ietf.org; secdir@ietf.org
Cc: BRUNGARD, DEBORAH A <db3546@att.com>
Subject: RE: Secdir review of draft-ietf-teas-actn-info-model-08

 

Hi Young!

 

All of your proposed c= hanges below address my concerns.  Thanks for the quick turn-around.

 

Cheers,

Roman

 

From: Leeyoung [mailto:leeyoung@huawei.com]
Sent: Wednesday, June 13, 2018 5:05 PM
To: Roman Danyliw <rdd@cert.org>; draft-ietf-teas-actn-info-model@ietf.org; secdir@ietf.org
Cc: BRUNGARD, DEBORAH A <db3546= @att.com>
Subject: RE: Secdir review of draft-ietf-teas-actn-info-model-08

 

Hi Roman,

 

Thanks for your review of the draft and providing= good comments.

 

Please see inline for our responses to your comme= nts. Please let us know if our responses are satisfactory to you; if not, p= lease provide us your further comments.

 

Thanks & Best regards,

Young

 

-----Original Message-----
From: Roman Danyliw [mailto:rdd@cert.org]
Sent: Wednesday, June 13, 2018 2:26 PM
To: draft-ietf-= teas-actn-info-model@ietf.org; secdir@ietf.org
Subject: Secdir review of draft-ietf-teas-actn-info-model-08

 

Reviewer: Roman Danyliw

Review result: Ready with nits

 

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 benefi= t 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.

 

My feedback is as follows:

 

(1) Section 9, Security Considerations, Page 21, = Paragraph 1

 

[original text]

   The ACTN information model described= in this document defines key

   interfaces for managed traffic engin= eered networks.  Securing the

   request and control of resources, co= nfidentiality of the

   information, and availability of fun= ction, should all be critical

   security considerations when deployi= ng and operating ACTN platforms.

 

[feedback]

 

This section (Section 9) reads to me as if it is = describing more than just the information model.  The text appears to = be identical to the security considerations in draft-ietf-teas-actn-framewo= rk-15.  IMO, the text here would benefit from tighter scoping.  Perhaps something like:

 

"The ACTN information model does not directl= y introduce security issues.  Rather, it defines a set of interfaces f= or traffic engineered networks.  The underlying protocols, procedures,= and implementations used to exchange the information model described in this draft will need to secure the request and control = of resources ...:

 

Furthermore, I assumed that "securing the re= quest and control of resources" was implying the need for authenticati= on and authorization of requests.  However, there is no discussion of = that in the subsequent text.  There is also no subsequent discussion of the significance of availability despite it being referenced= in this paragraph.

 

YL>> Your = suggested text is very good. How about the new paragraph as follows:

 

[new]=

   The= ACTN information model does not directly introduce security issues. 

  &nbs= p;Rather, it defines a set of interfaces for traffic engineered networks.&n= bsp;

  The = underlying protocols, procedures, and implementations used to exchange

  the = information model described in this draft will need to secure the request a= nd

  cont= rol of resources with proper authentication and authorization mechanisms.

  In a= ddition, the data exchanged over the ACTN interfaces discussed in this

  docu= ment requires verification of data integrity. Backup or redundancies SHOULD

  also= be available to restore the affected data to its correct state.  

 

(2) Section 9, Security Considerations, Page 21, = Paragraph 2

 

[original text]

   Several distributed ACTN functional = components are required, and

   implementations should consider encr= ypting data that flows between

   components, especially when they are= implemented at remote nodes,

   regardless of these data flows are o= n external or internal network

   interfaces.

 

[feedback]

 

Editorial -- This paragraph was a dense read for = me.  Perhaps something like the following would be more approachable:<= o:p>

 

"Implementations of the ACTN framework will = have distributed functional components that will exchange this information = model.  Implementations SHOULD encrypt data that flows between them, e= specially when they are implemented at remote nodes and irrespective of whether these data flows are on external or inte= rnal network interfaces."

 

YL>> Thank= s. I agree with your suggested text that will replace the original text.

 

(3) Section 9, Security Considerations, Page 21, = Paragraph 3

 

[original text]

   The ACTN security discussion is furt= her split into two specific

   categories described in the followin= g sub-sections:

 

   - Interface between the Customer Net= work Controller and Multi Domain

     Service Coordinator (MDS= C), CNC-MDSC Interface (CMI)

 

   - Interface between the Multi Domain= Service Coordinator and

     Provisioning Network Con= troller (PNC), MDSC-PNC Interface (MPI)

 

[feedback]

 

This sentence references additional sub-sections = that don't appear to exist -- Section 9 has no sub-sections.  draft-ie= tf-teas-actn-framework-15 which has identical text does have these sub-sect= ions (Sections 9.1 and 9.2).  Without additional text, this paragraph doesn't add anything.  If the text in draft-ietf= -teas-actn-framework-15 is relevant, I would recommend simply referencing i= t.

 

YL>> Corre= ct. I think the text in draft-ietf-teas-actn-framework-15 is relevant. So I= will reference it. So the new text will look like:

 

[new text]<= /o:p>

   The= ACTN security discussion is further split into two specific

   int= erfaces:

 

   - I= nterface between the Customer Network Controller and Multi Domain

  &nbs= p;  Service Coordinator (MDSC), CNC-MDSC Interface (CMI)

 

   - I= nterface between the Multi Domain Service Coordinator and=

  &nbs= p;  Provisioning Network Controller (PNC), MDSC-PNC Interface (MPI)

 

See the detailed= discussion of the CMI and MPI in Sections 9.1 and 9.2, respectively in [AC= TN-Frame].

 

 

(4) Section 9, Security Considerations, Page 21, = Paragraph 4

 

[original text]

   From a security and reliability pers= pective, ACTN may encounter many

   risks such as malicious attack and r= ogue elements attempting to

   connect to various ACTN components.&= nbsp; Furthermore, some ACTN

   components represent a single point = of failure and threat vector,

   and must also manage policy conflict= s, and eavesdropping of

   communication between different ACTN= components.

 

[feedback]

 

This text identifies some of the potential threat= s.  What mitigations should be applied?  Furthermore, these threa= ts aren't scoped within the bounds of the information model.  I recomm= end revising this threat discussion to be around the information being exchange or dropping the paragraph.

 

YL>> Thank= s. I would drop the paragraph.

 

(5) Section 9, Security Considerations, Page 22, = Paragraph 5

 

[original text]

   The conclusion is that all data mode= ls and protocols used to realize

   the ACTN info model should have rich= security features, and

   customer, application and network da= ta should be stored in encrypted

   data stores.  Additional securi= ty risks may still exist.  Therefore,

   discussion and applicability of spec= ific security functions and

   protocols will be better described i= n documents that are use case

   and environment specific.=

 

[feedback]

 

Per "The conclusion is that ... should have = rich security features".  What does "rich security" mea= n?

 

YL>> for i= nstance, encryption.

 

Per "... and customer, application and netwo= rk data should be stored ...", this is a good point about encryption a= t rest.  Is the "customer, application and network data" a m= ore descriptive version of "data in the information model"?  If no, then it's out of scope.  If yes, then I would recommend explic= itly stating that "The information model may contain customer, applica= tion and network data that for business or privacy reasons may be considere= d sensitive.  It SHOULD be stored only in an encrypted data store".  As data in motion is discussed in par= agraph 2, it might make sense to move this text there.

 

YL>> Yes, = actually "customer, application and network data" is a more descr= iptive version of "data in the information model". As such, I wou= ld take your text to replace the first sentence of Paragraph 5 (and move it to Paragraph 2). So Paragraph 2 will look like:

 

[new – Par= agraph 2]

   Imp= lementations of the ACTN framework will have distributed

  &nbs= p;functional components that will exchange this information model. 

  &nbs= p;Implementations SHOULD encrypt data that flows between them,

  &nbs= p;especially when they are implemented at remote nodes and irrespective

  &nbs= p;of whether these data flows are on external or internal network interface= s.

  &nbs= p;The information model may contain customer, application and network

  &nbs= p;data that for business or privacy reasons may be considered sensitive.&nb= sp;

  &nbs= p;It SHOULD be stored only in an encrypted data store.

 

[new – Par= agraph 5]

   The= conclusion is that all data models and protocols used to realize

   the= ACTN info model should have rich security features as discussed=

   in = this section. Additional security risks may still exist.  Therefore,

   dis= cussion and applicability of specific security functions and

   pro= tocols will be better described in documents that are use case

   and= environment specific.

 

Regards,

Roman

--_000_7AEB3D6833318045B4AE71C2C87E8E173D016E5Dsjceml521mbxchi_-- From nobody Fri Jun 15 11:52:47 2018 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 34AFC12F18C; Fri, 15 Jun 2018 11:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.798 X-Spam-Level: X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HTML_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_HTML_ATTACH=0.01] 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 A-BVE0er13nS; Fri, 15 Jun 2018 11:52:32 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 A148912785F; Fri, 15 Jun 2018 11:52:31 -0700 (PDT) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id B9FA616534448; Fri, 15 Jun 2018 19:52:26 +0100 (IST) Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.382.0; Fri, 15 Jun 2018 19:52:28 +0100 Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.141]) by SJCEML701-CHM.china.huawei.com ([169.254.3.168]) with mapi id 14.03.0382.000; Fri, 15 Jun 2018 11:52:22 -0700 From: Leeyoung To: "teas@ietf.org" , "ops-dir@ietf.org" , "secdir@ietf.org" , "rtg-dir@ietf.org" CC: "BRUNGARD, DEBORAH A" Thread-Topic: [Teas] I-D Action: draft-ietf-teas-actn-info-model-09.txt Thread-Index: AQHUBNjIUh3SSYBa90aKN4ANHAynYKRhqQ2Q Date: Fri, 15 Jun 2018 18:52:21 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E173D0170E0@sjceml521-mbx.china.huawei.com> References: <152908814467.27325.16052851210659458300@ietfa.amsl.com> In-Reply-To: <152908814467.27325.16052851210659458300@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.47.139.76] Content-Type: multipart/mixed; boundary="_002_7AEB3D6833318045B4AE71C2C87E8E173D0170E0sjceml521mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [secdir] [Teas] I-D Action: draft-ietf-teas-actn-info-model-09.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2018 18:52:38 -0000 --_002_7AEB3D6833318045B4AE71C2C87E8E173D0170E0sjceml521mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, This revision incorporated all comments received from ops-dir, secdir and r= tg-dir. Let us know if we by any chance missed your comments.=20 Thanks & best regards, Young (on behalf of other co-authors) -----Original Message----- From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of internet-drafts@ietf= .org Sent: Friday, June 15, 2018 1:42 PM To: i-d-announce@ietf.org Cc: teas@ietf.org Subject: [Teas] I-D Action: draft-ietf-teas-actn-info-model-09.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Traffic Engineering Architecture and Signa= ling WG of the IETF. Title : Information Model for Abstraction and Control of = TE Networks (ACTN) Authors : Young Lee Sergio Belotti Dhruv Dhody Daniele Ceccarelli Bin Yeong Yoon Filename : draft-ietf-teas-actn-info-model-09.txt Pages : 24 Date : 2018-06-15 Abstract: This draft provides an information model for Abstraction and Control of Traffic Engineered Networks (ACTN). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-actn-info-model/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-teas-actn-info-model-09 https://datatracker.ietf.org/doc/html/draft-ietf-teas-actn-info-model-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-teas-actn-info-model-09 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas --_002_7AEB3D6833318045B4AE71C2C87E8E173D0170E0sjceml521mbxchi_ Content-Type: text/html; name="Diff_ draft-ietf-teas-actn-info-model-08.txt - draft-ietf-teas-actn-info-model-09.txt.html" Content-Description: Diff_ draft-ietf-teas-actn-info-model-08.txt - draft-ietf-teas-actn-info-model-09.txt.html Content-Disposition: attachment; filename="Diff_ draft-ietf-teas-actn-info-model-08.txt - draft-ietf-teas-actn-info-model-09.txt.html"; size=29650; creation-date="Fri, 15 Jun 2018 18:35:08 GMT"; modification-date="Fri, 15 Jun 2018 18:35:08 GMT" Content-Transfer-Encoding: base64 PCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBYSFRNTCAxLjAgVHJhbnNpdGlvbmFs Ly9FTiIgImh0dHA6Ly93d3cudzMub3JnL1RSL3hodG1sMS9EVEQveGh0bWwxLXRyYW5zaXRpb25h bC5kdGQiPgo8IS0tIHNhdmVkIGZyb20gdXJsPSgwMDMwKWh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv cmZjZGlmZiAtLT4KPGh0bWwgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkveGh0bWwiPjxo ZWFkPjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1sOyBj aGFyc2V0PVVURi04Ij4gCiAgIAogIDxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtU3R5bGUtVHlw ZSIgY29udGVudD0idGV4dC9jc3MiPiAKICA8dGl0bGU+RGlmZjogZHJhZnQtaWV0Zi10ZWFzLWFj dG4taW5mby1tb2RlbC0wOC50eHQgLSBkcmFmdC1pZXRmLXRlYXMtYWN0bi1pbmZvLW1vZGVsLTA5 LnR4dDwvdGl0bGU+IAogIDxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyI+IAogICAgYm9keSAgICB7IG1h cmdpbjogMC40ZXg7IG1hcmdpbi1yaWdodDogYXV0bzsgfSAKICAgIHRyICAgICAgeyB9IAogICAg dGQgICAgICB7IHdoaXRlLXNwYWNlOiBwcmU7IGZvbnQtZmFtaWx5OiBtb25vc3BhY2U7IHZlcnRp Y2FsLWFsaWduOiB0b3A7IGZvbnQtc2l6ZTogMC44NmVtO30gCiAgICB0aCAgICAgIHsgZm9udC1z aXplOiAwLjg2ZW07IH0gCiAgICAuc21hbGwgIHsgZm9udC1zaXplOiAwLjZlbTsgZm9udC1zdHls ZTogaXRhbGljOyBmb250LWZhbWlseTogVmVyZGFuYSwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyB9 IAogICAgLmxlZnQgICB7IGJhY2tncm91bmQtY29sb3I6ICNFRUU7IH0gCiAgICAucmlnaHQgIHsg YmFja2dyb3VuZC1jb2xvcjogI0ZGRjsgfSAKICAgIC5kaWZmICAgeyBiYWNrZ3JvdW5kLWNvbG9y OiAjQ0NGOyB9IAogICAgLmxibG9jayB7IGJhY2tncm91bmQtY29sb3I6ICNCRkI7IH0gCiAgICAu cmJsb2NrIHsgYmFja2dyb3VuZC1jb2xvcjogI0ZGODsgfSAKICAgIC5pbnNlcnQgeyBiYWNrZ3Jv dW5kLWNvbG9yOiAjOEZGOyB9IAogICAgLmRlbGV0ZSB7IGJhY2tncm91bmQtY29sb3I6ICNBQ0Y7 IH0gCiAgICAudm9pZCAgIHsgYmFja2dyb3VuZC1jb2xvcjogI0ZGQjsgfSAKICAgIC5jb250ICAg eyBiYWNrZ3JvdW5kLWNvbG9yOiAjRUVFOyB9IAogICAgLmxpbmViciB7IGJhY2tncm91bmQtY29s b3I6ICNBQUE7IH0gCiAgICAubGluZW5vIHsgY29sb3I6IHJlZDsgYmFja2dyb3VuZC1jb2xvcjog I0ZGRjsgZm9udC1zaXplOiAwLjdlbTsgdGV4dC1hbGlnbjogcmlnaHQ7IHBhZGRpbmc6IDAgMnB4 OyB9IAogICAgLmVsaXBzaXN7IGJhY2tncm91bmQtY29sb3I6ICNBQUE7IH0gCiAgICAubGVmdCAu Y29udCB7IGJhY2tncm91bmQtY29sb3I6ICNEREQ7IH0gCiAgICAucmlnaHQgLmNvbnQgeyBiYWNr Z3JvdW5kLWNvbG9yOiAjRUVFOyB9IAogICAgLmxibG9jayAuY29udCB7IGJhY2tncm91bmQtY29s b3I6ICM5RDk7IH0gCiAgICAucmJsb2NrIC5jb250IHsgYmFja2dyb3VuZC1jb2xvcjogI0RENjsg fSAKICAgIC5pbnNlcnQgLmNvbnQgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjMEREOyB9IAogICAgLmRl bGV0ZSAuY29udCB7IGJhY2tncm91bmQtY29sb3I6ICM4QUQ7IH0gCiAgICAuc3RhdHMsIC5zdGF0 cyB0ZCwgLnN0YXRzIHRoIHsgYmFja2dyb3VuZC1jb2xvcjogI0VFRTsgcGFkZGluZzogMnB4IDA7 IH0gCiAgICBzcGFuLmhpZGUgeyBkaXNwbGF5OiBub25lOyBjb2xvcjogI2FhYTt9ICAgIGE6aG92 ZXIgc3BhbiB7IGRpc3BsYXk6IGlubGluZTsgfSAgICB0ci5jaGFuZ2UgeyBiYWNrZ3JvdW5kLWNv bG9yOiBncmF5OyB9IAogICAgdHIuY2hhbmdlIGEgeyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IGNv bG9yOiBibGFjayB9IAogIDwvc3R5bGU+IAogICAgIDxzY3JpcHQ+CnZhciBjaHVua19pbmRleCA9 IDA7CnZhciBvbGRfY2h1bmsgPSBudWxsOwoKZnVuY3Rpb24gZm9ybWF0X2NodW5rKGluZGV4KSB7 CiAgICB2YXIgcHJlZml4ID0gImRpZmYiOwogICAgdmFyIHN0ciA9IGluZGV4LnRvU3RyaW5nKCk7 CiAgICBmb3IgKHg9MDsgeDwoNC1zdHIubGVuZ3RoKTsgKyt4KSB7CiAgICAgICAgcHJlZml4Kz0n MCc7CiAgICB9CiAgICByZXR1cm4gcHJlZml4ICsgc3RyOwp9CgpmdW5jdGlvbiBmaW5kX2NodW5r KG4pewogICAgcmV0dXJuIGRvY3VtZW50LnF1ZXJ5U2VsZWN0b3IoJ3RyW2lkJD0iJyArIG4gKyAn Il0nKTsKfQoKZnVuY3Rpb24gY2hhbmdlX2NodW5rKG9mZnNldCkgewogICAgdmFyIGluZGV4ID0g Y2h1bmtfaW5kZXggKyBvZmZzZXQ7CiAgICB2YXIgbmV3X3N0cjsKICAgIHZhciBuZXdfY2h1bms7 CgogICAgbmV3X3N0ciA9IGZvcm1hdF9jaHVuayhpbmRleCk7CiAgICBuZXdfY2h1bmsgPSBmaW5k X2NodW5rKG5ld19zdHIpOwogICAgaWYgKCFuZXdfY2h1bmspIHsKICAgICAgICByZXR1cm47CiAg ICB9CiAgICBpZiAob2xkX2NodW5rKSB7CiAgICAgICAgb2xkX2NodW5rLnN0eWxlLm91dGxpbmUg PSAiIjsKICAgIH0KICAgIG9sZF9jaHVuayA9IG5ld19jaHVuazsKICAgIG9sZF9jaHVuay5zdHls ZS5vdXRsaW5lID0gIjFweCBzb2xpZCByZWQiOwogICAgd2luZG93LmxvY2F0aW9uLnJlcGxhY2Uo IiMiICsgbmV3X3N0cikKICAgIHdpbmRvdy5zY3JvbGxCeSgwLC0xMDApOwogICAgY2h1bmtfaW5k ZXggPSBpbmRleDsKfQoKZG9jdW1lbnQub25rZXlkb3duID0gZnVuY3Rpb24oZSkgewogICAgc3dp dGNoIChlLmtleUNvZGUpIHsKICAgIGNhc2UgNzg6CiAgICAgICAgY2hhbmdlX2NodW5rKDEpOwog ICAgICAgIGJyZWFrOwogICAgY2FzZSA4MDoKICAgICAgICBjaGFuZ2VfY2h1bmsoLTEpOwogICAg ICAgIGJyZWFrOwogICAgfQp9OwogICA8L3NjcmlwdD4gCjwvaGVhZD4gCjxib2R5PiAKICA8dGFi bGUgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjAiPiAKICA8dGJvZHk+ PHRyIGlkPSJwYXJ0LTEiIGJnY29sb3I9Im9yYW5nZSI+PHRoPjwvdGg+PHRoPjxhIGhyZWY9Imh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtdGVhcy1hY3RuLWlu Zm8tbW9kZWwtMDgudHh0IiBzdHlsZT0iY29sb3I6IzAwODsgdGV4dC1kZWNvcmF0aW9uOm5vbmU7 Ij4mbHQ7PC9hPiZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLXRlYXMtYWN0bi1pbmZvLW1vZGVsLTA4LnR4dCIgc3R5bGU9ImNvbG9yOiMwMDgiPmRy YWZ0LWlldGYtdGVhcy1hY3RuLWluZm8tbW9kZWwtMDgudHh0PC9hPiZuYnNwOzwvdGg+PHRoPiA8 L3RoPjx0aD4mbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi10ZWFzLWFjdG4taW5mby1tb2RlbC0wOS50eHQiIHN0eWxlPSJjb2xvcjojMDA4Ij5kcmFm dC1pZXRmLXRlYXMtYWN0bi1pbmZvLW1vZGVsLTA5LnR4dDwvYT4mbmJzcDs8YSBocmVmPSJodHRw czovL3Rvb2xzLmlldGYub3JnL3JmY2RpZmY/dXJsMT1kcmFmdC1pZXRmLXRlYXMtYWN0bi1pbmZv LW1vZGVsLTA5LnR4dCIgc3R5bGU9ImNvbG9yOiMwMDg7IHRleHQtZGVjb3JhdGlvbjpub25lOyI+ Jmd0OzwvYT48L3RoPjx0aD48L3RoPjwvdHI+IAogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPlRlYXMgV29ya2luZyBHcm91cCAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgWW91bmcgTGVlPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+VGVhcyBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBZb3VuZyBMZWU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPkludGVybmV0IERyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgSHVhd2VpPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+SW50ZXJu ZXQgRHJhZnQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBIdWF3ZWk8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+SW50ZW5kZWQgc3RhdHVz OiBJbmZvcm1hdGlvbmFsICAgICAgICAgICAgICAgICAgICAgICAgICAgU2VyZ2lvIEJlbG90dGk8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij5JbnRlbmRlZCBzdGF0dXM6IEluZm9ybWF0 aW9uYWwgICAgICAgICAgICAgICAgICAgICAgICAgICBTZXJnaW8gQmVsb3R0aTwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgTm9raWE8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBOb2tpYTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyIGlkPSJkaWZmMDAwMSI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj5FeHBpcmVzOiA8c3BhbiBjbGFzcz0i ZGVsZXRlIj5Ob3ZlbWJlciAzPC9zcGFuPiwgMjAxODwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmJsb2NrIj5FeHBpcmVzOiA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5EZWNlbWJlciAxNTwvc3Bhbj4s IDIwMTg8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIERocnV2IERob2R5PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgRGhydXYgRGhvZHk8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgSHVhd2VpPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBIdWF3ZWk8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBEYW5pZWxlIENlY2Nh cmVsbGk8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIERhbmllbGUgQ2VjY2FyZWxsaTwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRXJpY3Nzb248L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBFcmljc3NvbjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBCaW4gWWVvbmcgWW9vbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEJpbiBZ ZW9uZyBZb29uPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRVRSSTwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBFVFJJPC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMDIiPjx0ZD48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9j ayI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIDxzcGFuIGNsYXNzPSJkZWxldGUiPiAgTWF5IDM8L3NwYW4+LCAyMDE4PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5KdW5lIDE1PC9zcGFu PiwgMjAxODwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gIEluZm9ybWF0aW9uIE1v ZGVsIGZvciBBYnN0cmFjdGlvbiBhbmQgQ29udHJvbCBvZiBURSBOZXR3b3JrcyAoQUNUTik8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gIEluZm9ybWF0aW9uIE1vZGVsIGZvciBBYnN0 cmFjdGlvbiBhbmQgQ29udHJvbCBvZiBURSBOZXR3b3JrcyAoQUNUTik8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICAgICAgZHJhZnQtaWV0Zi10ZWFzLWFjdG4t aW5mby1tb2RlbC0wOC50eHQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAg ICAgICAgICAgICBkcmFmdC1pZXRmLXRlYXMtYWN0bi1pbmZvLW1vZGVsLTA4LnR4dDwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij5BYnN0cmFjdDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPkFic3RyYWN0PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRo aXMgZHJhZnQgcHJvdmlkZXMgYW4gaW5mb3JtYXRpb24gbW9kZWwgZm9yIEFic3RyYWN0aW9uIGFu ZCBDb250cm9sPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhpcyBkcmFmdCBw cm92aWRlcyBhbiBpbmZvcm1hdGlvbiBtb2RlbCBmb3IgQWJzdHJhY3Rpb24gYW5kIENvbnRyb2w8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG9mIFRyYWZmaWMgRW5naW5lZXJlZCBOZXR3 b3JrcyAoQUNUTikuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgb2YgVHJhZmZp YyBFbmdpbmVlcmVkIE5ldHdvcmtzIChBQ1ROKS48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9InBhcnQtMiIgY2xhc3M9ImNoYW5nZSI+PHRk PjwvdGQ+PHRoPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxhIGhyZWY9Imh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvcmZjZGlmZiNwYXJ0LTIiPjxlbT4gcGFnZSAyLCBsaW5lIDc8 c3BhbiBjbGFzcz0iaGlkZSI+IMK2PC9zcGFuPjwvZW0+PC9hPjwvdGg+PHRoPiA8L3RoPjx0aD48 c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48YSBocmVmPSJodHRwczovL3Rvb2xz LmlldGYub3JnL3JmY2RpZmYjcGFydC0yIj48ZW0+IHBhZ2UgMiwgbGluZSA3PHNwYW4gY2xhc3M9 ImhpZGUiPiDCtjwvc3Bhbj48L2VtPjwvYT48L3RoPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEludGVybmV0LURyYWZ0 cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1 bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXg8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPiAgIG1vbnRocyBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQg Ynkgb3RoZXIgZG9jdW1lbnRzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgbW9u dGhzIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBk b2N1bWVudHM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGF0IGFueSB0aW1lLiAgSXQg aXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgYXQgYW55IHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRv IHVzZSBJbnRlcm5ldC1EcmFmdHMgYXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHJl ZmVyZW5jZSBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBw cm9ncmVzcy4iPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgcmVmZXJlbmNlIG1h dGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiI8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhlIGxpc3Qgb2YgY3VycmVudCBJ bnRlcm5ldC1EcmFmdHMgY2FuIGJlIGFjY2Vzc2VkIGF0PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC1EcmFmdHMgY2FuIGJlIGFj Y2Vzc2VkIGF0PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBodHRwOi8vd3d3LmlldGYu b3JnL2lldGYvMWlkLWFic3RyYWN0cy50eHQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICBodHRwOi8vd3d3LmlldGYub3JnL2lldGYvMWlkLWFic3RyYWN0cy50eHQ8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRoZSBsaXN0IG9mIEludGVybmV0LURyYWZ0IFNoYWRvdyBE aXJlY3RvcmllcyBjYW4gYmUgYWNjZXNzZWQgYXQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICBUaGUgbGlzdCBvZiBJbnRlcm5ldC1EcmFmdCBTaGFkb3cgRGlyZWN0b3JpZXMgY2Fu IGJlIGFjY2Vzc2VkIGF0PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBodHRwOi8vd3d3 LmlldGYub3JnL3NoYWRvdy5odG1sLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMDMiPjx0ZD48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgVGhp cyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiA8c3BhbiBjbGFzcz0iZGVsZXRlIj5Ob3Zl bWJlciAzPC9zcGFuPiwgMjAxOC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAg VGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5E ZWNlbWJlciAxNTwvc3Bhbj4sIDIwMTguPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PkNvcHlyaWdodCBOb3RpY2U8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij5Db3B5cmln aHQgTm90aWNlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIENvcHlyaWdodCAo YykgMjAxOCBJRVRGIFRydXN0IGFuZCB0aGUgcGVyc29ucyBpZGVudGlmaWVkIGFzIHRoZTwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIENvcHlyaWdodCAoYykgMjAxOCBJRVRGIFRy dXN0IGFuZCB0aGUgcGVyc29ucyBpZGVudGlmaWVkIGFzIHRoZTwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgZG9jdW1lbnQgYXV0aG9ycy4gQWxsIHJpZ2h0cyByZXNlcnZlZC48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBkb2N1bWVudCBhdXRob3JzLiBBbGwgcmlnaHRz IHJlc2VydmVkLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUaGlzIGRvY3Vt ZW50IGlzIHN1YmplY3QgdG8gQkNQIDc4IGFuZCB0aGUgSUVURiBUcnVzdCdzIExlZ2FsPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhpcyBkb2N1bWVudCBpcyBzdWJqZWN0IHRv IEJDUCA3OCBhbmQgdGhlIElFVEYgVHJ1c3QncyBMZWdhbDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgUHJvdmlzaW9ucyBSZWxhdGluZyB0byBJRVRGIERvY3VtZW50czwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFByb3Zpc2lvbnMgUmVsYXRpbmcgdG8gSUVURiBEb2N1 bWVudHM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIChodHRwOi8vdHJ1c3RlZS5pZXRm Lm9yZy9saWNlbnNlLWluZm8pIGluIGVmZmVjdCBvbiB0aGUgZGF0ZSBvZjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIChodHRwOi8vdHJ1c3RlZS5pZXRmLm9yZy9saWNlbnNlLWlu Zm8pIGluIGVmZmVjdCBvbiB0aGUgZGF0ZSBvZjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgcHVibGljYXRpb24gb2YgdGhpcyBkb2N1bWVudC4gIFBsZWFzZSByZXZpZXcgdGhlc2UgZG9j dW1lbnRzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgcHVibGljYXRpb24gb2Yg dGhpcyBkb2N1bWVudC4gIFBsZWFzZSByZXZpZXcgdGhlc2UgZG9jdW1lbnRzPC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0icGFydC0zIiBjbGFzcz0i Y2hhbmdlIj48dGQ+PC90ZD48dGg+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+ PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9yZmNkaWZmI3BhcnQtMyI+PGVtPiBwYWdl IDIxLCBsaW5lIDE0PHNwYW4gY2xhc3M9ImhpZGUiPiDCtjwvc3Bhbj48L2VtPjwvYT48L3RoPjx0 aD4gPC90aD48dGg+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGEgaHJlZj0i aHR0cHM6Ly90b29scy5pZXRmLm9yZy9yZmNkaWZmI3BhcnQtMyI+PGVtPiBwYWdlIDIxLCBsaW5l IDE0PHNwYW4gY2xhc3M9ImhpZGUiPiDCtjwvc3Bhbj48L2VtPjwvYT48L3RoPjx0ZD48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg ICZsdDtURSBUb3BvbG9neSBVcGRhdGUmZ3Q7IDo6PSAmbHQ7VEUtdG9wb2xvZ3ktbGlzdCZndDs8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAmbHQ7VEUgVG9wb2xvZ3kgVXBkYXRl Jmd0OyA6Oj0gJmx0O1RFLXRvcG9sb2d5LWxpc3QmZ3Q7PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgICZsdDtQYXRoIENvbXB1dGUgUmVxdWVzdCZndDsgOjo9ICZsdDtURSBUdW5u ZWwgQ2hhcmFjdGVyaXN0aWNzJmd0OzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg ICZsdDtQYXRoIENvbXB1dGUgUmVxdWVzdCZndDsgOjo9ICZsdDtURSBUdW5uZWwgQ2hhcmFjdGVy aXN0aWNzJmd0OzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAmbHQ7UGF0aCBD b21wdXRlIFJlcGx5Jmd0OyA6Oj0gJmx0O1RFIENvbXB1dGVkIFBhdGgmZ3Q7PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgJmx0O1BhdGggQ29tcHV0ZSBSZXBseSZndDsgOjo9ICZs dDtURSBDb21wdXRlZCBQYXRoJmd0OzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICAgICAgICAgICAgICAgICAgICAgICAgICAgJmx0O1RFIFR1bm5lbCBDaGFyYWN0ZXJpc3RpY3Mm Z3Q7PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICZsdDtURSBUdW5uZWwgQ2hhcmFjdGVyaXN0aWNzJmd0OzwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij45LiBTZWN1cml0eSBDb25zaWRlcmF0aW9uczwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPjkuIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zPC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMDQiPjx0ZD48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxi bG9jayI+ICAgVGhlIEFDVE4gaW5mb3JtYXRpb24gbW9kZWwgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+ ZGVzY3JpYmVkIGluIHRoaXMgZG9jdW1lbnQ8L3NwYW4+IGRlZmluZXMgPHNwYW4gY2xhc3M9ImRl bGV0ZSI+a2V5PC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBUaGUg QUNUTiBpbmZvcm1hdGlvbiBtb2RlbCA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5kb2VzIG5vdCBkaXJl Y3RseSBpbnRyb2R1Y2Ugc2VjdXJpdHk8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPiAgIGludGVyZmFjZXMgZm9yIDxzcGFuIGNsYXNzPSJkZWxldGUiPm1hbmFnZWQ8L3NwYW4+ IHRyYWZmaWMgZW5naW5lZXJlZCBuZXR3b3Jrcy4gIDxzcGFuIGNsYXNzPSJkZWxldGUiPlNlY3Vy aW5nPC9zcGFuPiB0aGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xh c3M9Imluc2VydCI+ICAgaXNzdWVzLiBSYXRoZXIsIGl0PC9zcGFuPiBkZWZpbmVzIDxzcGFuIGNs YXNzPSJpbnNlcnQiPmEgc2V0IG9mPC9zcGFuPiBpbnRlcmZhY2VzIGZvciB0cmFmZmljPC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIHJlcXVlc3QgYW5kIGNvbnRyb2wgb2YgPHNwYW4g Y2xhc3M9ImRlbGV0ZSI+cmVzb3VyY2VzLCBjb25maWRlbnRpYWxpdHkgb2YgdGhlPC9zcGFuPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBlbmdpbmVlcmVkIG5ldHdvcmtzLiA8 c3BhbiBjbGFzcz0iaW5zZXJ0Ij5UaGUgdW5kZXJseWluZyBwcm90b2NvbHMsIHByb2NlZHVyZXMs IGFuZDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRl bGV0ZSI+ICAgaW5mb3JtYXRpb24sPC9zcGFuPiBhbmQgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+YXZh aWxhYmlsaXR5PC9zcGFuPiBvZiA8c3BhbiBjbGFzcz0iZGVsZXRlIj5mdW5jdGlvbiwgc2hvdWxk IGFsbDwvc3Bhbj4gYmUgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+Y3JpdGljYWw8L3NwYW4+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIGltcGxl bWVudGF0aW9ucyB1c2VkIHRvIGV4Y2hhbmdlIHRoZSBpbmZvcm1hdGlvbiBtb2RlbCBkZXNjcmli ZWQ8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxl dGUiPiAgIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHdoZW4gZGVwbG95aW5nIGFuZCBvcGVyYXRp bmcgQUNUTiBwbGF0Zm9ybXMuPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2Nr Ij48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBpbiB0aGlzIGRyYWZ0IHdpbGwgbmVlZCB0byBzZWN1 cmU8L3NwYW4+IHRoZSByZXF1ZXN0IGFuZCBjb250cm9sIG9mPC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICA8c3BhbiBjbGFz cz0iaW5zZXJ0Ij5yZXNvdXJjZXMgd2l0aCBwcm9wZXIgYXV0aGVudGljYXRpb248L3NwYW4+IGFu ZCA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5hdXRob3JpemF0aW9uIG1lY2hhbmlzbXMuPC9zcGFuPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJi bG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgSW4gYWRkaXRpb24sIHRoZSBkYXRhIGV4Y2hh bmdlZCBvdmVyIHRoZSBBQ1ROIGludGVyZmFjZXMgZGlzY3Vzc2VkPC9zcGFuPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNw YW4gY2xhc3M9Imluc2VydCI+ICAgaW4gdGhpcyBkb2N1bWVudCByZXF1aXJlcyB2ZXJpZmljYXRp b248L3NwYW4+IG9mIDxzcGFuIGNsYXNzPSJpbnNlcnQiPmRhdGEgaW50ZWdyaXR5LiBCYWNrdXAg b3I8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICByZWR1bmRhbmNpZXMgU0hP VUxEIGFsc288L3NwYW4+IGJlIDxzcGFuIGNsYXNzPSJpbnNlcnQiPmF2YWlsYWJsZSB0byByZXN0 b3JlIHRoZSBhZmZlY3RlZCBkYXRhPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2Nr Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ ICAgdG8gaXRzIGNvcnJlY3Qgc3RhdGUuPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDA1Ij48dGQ+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIDxzcGFu IGNsYXNzPSJkZWxldGUiPlNldmVyYWwgZGlzdHJpYnV0ZWQ8L3NwYW4+IEFDVE4gZnVuY3Rpb25h bCBjb21wb25lbnRzIDxzcGFuIGNsYXNzPSJkZWxldGUiPmFyZSByZXF1aXJlZCwgYW5kPC9zcGFu PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICA8c3BhbiBjbGFzcz0iaW5zZXJ0 Ij5JbXBsZW1lbnRhdGlvbnMgb2YgdGhlPC9zcGFuPiBBQ1ROIDxzcGFuIGNsYXNzPSJpbnNlcnQi PmZyYW1ld29yayB3aWxsIGhhdmUgZGlzdHJpYnV0ZWQ8L3NwYW4+PC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgIGltcGxlbWVudGF0aW9ucyBzaG91 bGQgY29uc2lkZXIgZW5jcnlwdGluZzwvc3Bhbj4gZGF0YSB0aGF0IGZsb3dzIGJldHdlZW48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgZnVuY3Rpb25hbCBjb21wb25lbnRzIDxz cGFuIGNsYXNzPSJpbnNlcnQiPnRoYXQgd2lsbCBleGNoYW5nZSB0aGlzIGluZm9ybWF0aW9uIG1v ZGVsLjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgPHNwYW4gY2xhc3M9 ImRlbGV0ZSI+Y29tcG9uZW50cyw8L3NwYW4+IGVzcGVjaWFsbHkgd2hlbiB0aGV5IGFyZSBpbXBs ZW1lbnRlZCBhdCByZW1vdGUgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+bm9kZXMsPC9zcGFuPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBJbXBs ZW1lbnRhdGlvbnMgU0hPVUxEIGVuY3J5cHQ8L3NwYW4+IGRhdGEgdGhhdCBmbG93cyBiZXR3ZWVu IDxzcGFuIGNsYXNzPSJpbnNlcnQiPnRoZW0sPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4gICByZWdhcmRsZXNzPC9zcGFuPiBvZiB0aGVz ZSBkYXRhIGZsb3dzIGFyZSBvbiBleHRlcm5hbCBvciBpbnRlcm5hbCBuZXR3b3JrPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIGVzcGVjaWFsbHkgd2hlbiB0aGV5IGFyZSBpbXBs ZW1lbnRlZCBhdCByZW1vdGUgPHNwYW4gY2xhc3M9Imluc2VydCI+bm9kZXMgYW5kPC9zcGFuPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBpbnRlcmZhY2VzLjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBpcnJlc3BlY3RpdmU8 L3NwYW4+IG9mIDxzcGFuIGNsYXNzPSJpbnNlcnQiPndoZXRoZXI8L3NwYW4+IHRoZXNlIGRhdGEg Zmxvd3MgYXJlIG9uIGV4dGVybmFsIG9yIGludGVybmFsPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs YmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBuZXR3b3JrIGludGVy ZmFjZXMuIDxzcGFuIGNsYXNzPSJpbnNlcnQiPlRoZSBpbmZvcm1hdGlvbiBtb2RlbCBtYXkgY29u dGFpbiBjdXN0b21lciw8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBhcHBs aWNhdGlvbiBhbmQgbmV0d29yayBkYXRhIHRoYXQgZm9yIGJ1c2luZXNzIG9yIHByaXZhY3kgcmVh c29uczwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIG1heSBiZSBjb25zaWRl cmVkIHNlbnNpdGl2ZS4gSXQgU0hPVUxEIGJlIHN0b3JlZCBvbmx5IGluIGFuPC9zcGFuPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9j ayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgZW5jcnlwdGVkIGRhdGEgc3RvcmUuPC9zcGFuPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUaGUgQUNUTiBzZWN1cml0eSBkaXNj dXNzaW9uIGlzIGZ1cnRoZXIgc3BsaXQgaW50byB0d28gc3BlY2lmaWM8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGUgQUNUTiBzZWN1cml0eSBkaXNjdXNzaW9uIGlzIGZ1cnRo ZXIgc3BsaXQgaW50byB0d28gc3BlY2lmaWM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMDYiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgPHNwYW4gY2xhc3M9ImRl bGV0ZSI+Y2F0ZWdvcmllcyBkZXNjcmliZWQgaW4gdGhlIGZvbGxvd2luZyBzdWItc2VjdGlvbjwv c3Bhbj5zOjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICA8c3BhbiBjbGFzcz0i aW5zZXJ0Ij5pbnRlcmZhY2U8L3NwYW4+czo8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAwNyI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAtIEludGVyZmFj ZSBiZXR3ZWVuIHRoZSBDdXN0b21lciBOZXR3b3JrIENvbnRyb2xsZXIgYW5kIE11bHRpIERvbWFp bjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgIC0JSW50ZXJmYWNlIGJldHdl ZW4gdGhlIEN1c3RvbWVyIE5ldHdvcmsgQ29udHJvbGxlciBhbmQgTXVsdGk8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxibG9jayI+ICAgICBTZXJ2aWNlIENvb3JkaW5hdG9yIChNRFNDKSwgQ05DLU1E U0MgSW50ZXJmYWNlIChDTUkpPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAg ICAgRG9tYWluIFNlcnZpY2UgQ29vcmRpbmF0b3IgKE1EU0MpLCBDTkMtTURTQyBJbnRlcmZhY2Ug KENNSSk8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlk PSJkaWZmMDAwOCI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAtIEludGVyZmFjZSBiZXR3ZWVuIHRoZSBNdWx0aSBE b21haW4gU2VydmljZSBDb29yZGluYXRvciBhbmQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJi bG9jayI+ICAgICAtCUludGVyZmFjZSBiZXR3ZWVuIHRoZSBNdWx0aSBEb21haW4gU2VydmljZSBD b29yZGluYXRvciBhbmQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICBQcm92aXNp b25pbmcgTmV0d29yayBDb250cm9sbGVyIChQTkMpLCBNRFNDLVBOQyBJbnRlcmZhY2UgKE1QSSk8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAgICBQcm92aXNpb25pbmcgTmV0 d29yayBDb250cm9sbGVyIChQTkMpLCBNRFNDLVBOQyBJbnRlcmZhY2UgKE1QSSk8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAwOSI+PHRk PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGJsb2NrIj4gICA8c3BhbiBjbGFzcz0iZGVsZXRlIj5Gcm9tIGEgc2VjdXJpdHkgYW5kIHJlbGlh YmlsaXR5IHBlcnNwZWN0aXZlLCBBQ1ROIG1heSBlbmNvdW50ZXIgbWFueTwvc3Bhbj48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgPHNwYW4gY2xhc3M9Imluc2VydCI+U2VlIHRo ZSBkZXRhaWxlZCBkaXNjdXNzaW9uPC9zcGFuPiBvZiA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij50aGUg Q01JPC9zcGFuPiBhbmQgPHNwYW4gY2xhc3M9Imluc2VydCI+TVBJIGluIFNlY3Rpb25zIDkuMTwv c3Bhbj4gYW5kPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxl dGUiPiAgIHJpc2tzIHN1Y2ggYXMgbWFsaWNpb3VzIGF0dGFjayBhbmQgcm9ndWUgZWxlbWVudHMg YXR0ZW1wdGluZyB0bzwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAg PHNwYW4gY2xhc3M9Imluc2VydCI+OS4yLCByZXNwZWN0aXZlbHkgaW4gW0FDVE4tRnJhbWVdLjwv c3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ ICAgY29ubmVjdCB0byB2YXJpb3VzIEFDVE4gY29tcG9uZW50cy4gIEZ1cnRoZXJtb3JlLCBzb21l IEFDVE48L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4gICBjb21wb25lbnRzIHJl cHJlc2VudCBhIHNpbmdsZSBwb2ludDwvc3Bhbj4gb2YgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+ZmFp bHVyZTwvc3Bhbj4gYW5kIDxzcGFuIGNsYXNzPSJkZWxldGUiPnRocmVhdCB2ZWN0b3IsPC9zcGFu PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxibG9jayI+ICAgYW5kIDxzcGFuIGNsYXNzPSJkZWxldGUiPm11c3QgYWxzbyBtYW5hZ2UgcG9s aWN5IGNvbmZsaWN0cywgYW5kIGVhdmVzZHJvcHBpbmcgb2Y8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBj bGFzcz0iZGVsZXRlIj4gICBjb21tdW5pY2F0aW9uIGJldHdlZW4gZGlmZmVyZW50IEFDVE4gY29t cG9uZW50cy48L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDEwIj48 dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsYmxvY2siPiAgIFRoZSBjb25jbHVzaW9uIGlzIHRoYXQgYWxsIGRhdGEgbW9kZWxzIGFuZCBw cm90b2NvbHMgdXNlZCB0byByZWFsaXplPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2si PiAgIFRoZSBjb25jbHVzaW9uIGlzIHRoYXQgYWxsIGRhdGEgbW9kZWxzIGFuZCBwcm90b2NvbHMg dXNlZCB0bzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICB0aGUgQUNUTiBpbmZvIG1v ZGVsIHNob3VsZCBoYXZlIHJpY2ggc2VjdXJpdHkgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+ZmVhdHVy ZXMsIGFuZDwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgcmVhbGl6 ZSB0aGUgQUNUTiBpbmZvIG1vZGVsIHNob3VsZCBoYXZlIHJpY2ggc2VjdXJpdHkgPHNwYW4gY2xh c3M9Imluc2VydCI+ZmVhdHVyZXMgYXM8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgIGN1c3RvbWVyLCBhcHBsaWNhdGlvbiBhbmQgbmV0 d29yayBkYXRhIHNob3VsZCBiZSBzdG9yZWQ8L3NwYW4+IGluIDxzcGFuIGNsYXNzPSJkZWxldGUi PmVuY3J5cHRlZDwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4g Y2xhc3M9Imluc2VydCI+ICAgZGlzY3Vzc2VkPC9zcGFuPiBpbiA8c3BhbiBjbGFzcz0iaW5zZXJ0 Ij50aGlzIHNlY3Rpb24uPC9zcGFuPiBBZGRpdGlvbmFsIHNlY3VyaXR5IHJpc2tzIG1heSBzdGls bDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4gICBk YXRhIHN0b3Jlcy48L3NwYW4+ICBBZGRpdGlvbmFsIHNlY3VyaXR5IHJpc2tzIG1heSBzdGlsbCBl eGlzdC4gIFRoZXJlZm9yZSw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgZXhp c3QuIFRoZXJlZm9yZSwgZGlzY3Vzc2lvbiBhbmQgYXBwbGljYWJpbGl0eSBvZiBzcGVjaWZpYyBz ZWN1cml0eTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBkaXNjdXNzaW9uIGFuZCBh cHBsaWNhYmlsaXR5IG9mIHNwZWNpZmljIHNlY3VyaXR5IGZ1bmN0aW9ucyBhbmQ8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgZnVuY3Rpb25zIGFuZCBwcm90b2NvbHMgd2lsbCBi ZSBiZXR0ZXIgZGVzY3JpYmVkIGluIGRvY3VtZW50cyB0aGF0PC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsYmxvY2siPiAgIHByb3RvY29scyB3aWxsIGJlIGJldHRlciBkZXNjcmliZWQgaW4gZG9jdW1l bnRzIHRoYXQgYXJlIHVzZSBjYXNlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAg IGFyZSB1c2UgY2FzZSBhbmQgZW52aXJvbm1lbnQgPHNwYW4gY2xhc3M9Imluc2VydCI+c3BlY2lm aWM8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIGFuZCBlbnZpcm9ubWVu dCA8c3BhbiBjbGFzcz0iZGVsZXRlIj5zcGVjaWZpYy48L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4xMC4gSUFO QSBDb25zaWRlcmF0aW9uczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjEwLiBJQU5B IENvbnNpZGVyYXRpb25zPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRoaXMg ZG9jdW1lbnQgaGFzIG5vIGFjdGlvbnMgZm9yIElBTkEuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgVGhpcyBkb2N1bWVudCBoYXMgbm8gYWN0aW9ucyBmb3IgSUFOQS48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+MTEuIFJlZmVyZW5jZXM8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4xMS4gUmVmZXJlbmNlczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4xMS4xLiBOb3JtYXRpdmUgUmVmZXJlbmNlczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPjExLjEuIE5vcm1hdGl2ZSBSZWZlcmVuY2VzPC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIFtBQ1ROLVJFUV0gWS4gTGVlLCBldCBhbC4sICJSZXF1aXJlbWVudHMg Zm9yIEFic3RyYWN0aW9uIGFuZCBDb250cm9sPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgW0FDVE4tUkVRXSBZLiBMZWUsIGV0IGFsLiwgIlJlcXVpcmVtZW50cyBmb3IgQWJzdHJh Y3Rpb24gYW5kIENvbnRyb2w8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CgogICAg IDx0cj48dGQ+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPjwvdGQ+PHRkPjwvdGQ+PC90cj4KICAgICA8dHIgaWQ9ImVuZCIgYmdjb2xvcj0iZ3Jh eSI+PHRoIGNvbHNwYW49IjUiIGFsaWduPSJjZW50ZXIiPiZuYnNwO0VuZCBvZiBjaGFuZ2VzLiAx MCBjaGFuZ2UgYmxvY2tzLiZuYnNwOzwvdGg+PC90cj4KICAgICA8dHIgY2xhc3M9InN0YXRzIj48 dGQ+PC90ZD48dGg+PGk+MzEgbGluZXMgY2hhbmdlZCBvciBkZWxldGVkPC9pPjwvdGg+PHRoPjxp PiA8L2k+PC90aD48dGg+PGk+MzUgbGluZXMgY2hhbmdlZCBvciBhZGRlZDwvaT48L3RoPjx0ZD48 L3RkPjwvdHI+CiAgICAgPHRyPjx0ZCBjb2xzcGFuPSI1IiBhbGlnbj0iY2VudGVyIiBjbGFzcz0i c21hbGwiPjxicj5UaGlzIGh0bWwgZGlmZiB3YXMgcHJvZHVjZWQgYnkgcmZjZGlmZiAxLjQ2LiBU aGUgbGF0ZXN0IHZlcnNpb24gaXMgYXZhaWxhYmxlIGZyb20gPGEgaHJlZj0iaHR0cDovL3d3dy50 b29scy5pZXRmLm9yZy90b29scy9yZmNkaWZmLyI+aHR0cDovL3Rvb2xzLmlldGYub3JnL3Rvb2xz L3JmY2RpZmYvPC9hPiA8L3RkPjwvdHI+CiAgIDwvdGJvZHk+PC90YWJsZT4KICAgCiAgIAo8L2Jv ZHk+PC9odG1sPg== --_002_7AEB3D6833318045B4AE71C2C87E8E173D0170E0sjceml521mbxchi_-- From nobody Fri Jun 15 15:08:00 2018 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 5E049130E27 for ; Fri, 15 Jun 2018 15:07:57 -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.81.2 Auto-Submitted: auto-generated Precedence: bulk Reply-to: secdir-secretary@mit.edu Message-ID: <152910047732.27370.16708365563441619656.idtracker@ietfa.amsl.com> Date: Fri, 15 Jun 2018 15:07:57 -0700 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.26 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2018 22:07:58 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2018-06-21 Reviewer LC end Draft Alan DeKok 2018-06-15 draft-ietf-pals-ethernet-cw-06 Sandra Murphy 2018-04-24 draft-ietf-mmusic-sdp-simulcast-12 Last calls: Reviewer LC end Draft John Bradley 2018-06-18 draft-ietf-bfd-multipoint-active-tail-08 John Bradley 2018-04-18 draft-ietf-acme-acme-12 Shawn Emery 2018-06-29 draft-ietf-netmod-schema-mount-10 Stephen Farrell 2018-06-28 draft-ietf-opsawg-nat-yang-14 Daniel Franke 2018-06-28 draft-ietf-netconf-rfc7895bis-06 Daniel Gillmor 2018-06-25 draft-ietf-dnsop-session-signal-10 Daniel Gillmor 2018-03-19 draft-gutmann-scep-10 Tobias Gondrom 2018-06-25 draft-ietf-6man-rfc6434-bis-08 Russ Mundy 2017-09-14 draft-spinosa-urn-lex-13 Tina Tsou 2018-05-21 draft-ietf-v6ops-conditional-ras-04 Samuel Weiler 2018-05-21 draft-ietf-bfd-multipoint-17 Klaas Wierenga 2018-06-26 draft-richer-vectors-of-trust-11 Taylor Yu 2018-06-19 draft-ietf-regext-rdap-object-tag-03 Dacheng Zhang 2018-06-19 draft-ietf-mpls-spring-entropy-label-11 Early review requests: Reviewer Due Draft Donald Eastlake 2018-06-30 draft-ietf-mptcp-rfc6824bis-11 Daniel Franke 2018-01-31 draft-ietf-intarea-provisioning-domains-00 Ólafur Guðmundsson 2018-01-09 draft-ietf-opsawg-nat-yang-09 Next in the reviewer rotation: Ólafur Guðmundsson Phillip Hallam-Baker Steve Hanna Dan Harkins Russ Housley Christian Huitema Leif Johansson Benjamin Kaduk Charlie Kaufman Scott Kelly From nobody Sun Jun 17 13:06:34 2018 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 976D6130E51; Sun, 17 Jun 2018 13:06:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Stephen Farrell To: Cc: draft-ietf-opsawg-nat-yang.all@ietf.org, ietf@ietf.org, opsawg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152926599250.2311.15532810595098738604@ietfa.amsl.com> Date: Sun, 17 Jun 2018 13:06:32 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-opsawg-nat-yang-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.26 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jun 2018 20:06:33 -0000 Reviewer: Stephen Farrell Review result: Has Issues I see one major issue: 2.1: Logging in NATs and esp. CGNs is clearly sensitive in various ways. I think it'd be ok if logging was really out of scope, however, there is a logging-enable feature, I think under-specified, (on page 63) so the statement in 2.1 seems contradictory to me - if logging is out of scope why is logging-enable a flag?. Presumably if logging-enable transitions from F->T then you turn on (some undefined kind of) logging. If this transitions from T->F then what is the implementer supposed to do? I think that illustrates the under-specification here. The simplest thing might be to really make logging out of scope here by deleting the logging-enable thing entirely. (I can imagine that reaching consensus on a logging control interface would be non-trivial, hence the suggestion to really put it out of scope rather than try specify it fully.) Just one nit: The abstract could do with a bit of re-wording as it reads awkwardly. I'd say maybe just delete the 1st sentence. From nobody Mon Jun 18 00:10:26 2018 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 6E945127598; Mon, 18 Jun 2018 00:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.395 X-Spam-Level: X-Spam-Status: No, score=-3.395 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.795, 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 Lm8z6HDo7LiV; Mon, 18 Jun 2018 00:10:21 -0700 (PDT) Received: from orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AE63130DEB; Mon, 18 Jun 2018 00:10:21 -0700 (PDT) Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id C690DC07D9; Mon, 18 Jun 2018 09:10:19 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.32]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id 98C971A0065; Mon, 18 Jun 2018 09:10:19 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM32.corporate.adroot.infra.ftgroup ([fe80::8924:188:2124:a046%19]) with mapi id 14.03.0399.000; Mon, 18 Jun 2018 09:10:19 +0200 From: To: Stephen Farrell , "secdir@ietf.org" CC: "draft-ietf-opsawg-nat-yang.all@ietf.org" , "ietf@ietf.org" , "opsawg@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-opsawg-nat-yang-14 Thread-Index: AQHUBnaxNi2Gt51rukm5BMZI7aoJ46RllBdw Date: Mon, 18 Jun 2018 07:10:18 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DF4678E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <152926599250.2311.15532810595098738604@ietfa.amsl.com> In-Reply-To: <152926599250.2311.15532810595098738604@ietfa.amsl.com> 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: 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-opsawg-nat-yang-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2018 07:10:24 -0000 SGkgU3RlcGhlbiwgDQoNClRoYW5rIHlvdSBmb3IgdGhlIHJldmlldy4gDQoNClBsZWFzZSBzZWUg aW5saW5lLiANCg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0t DQo+IERlwqA6IFN0ZXBoZW4gRmFycmVsbCBbbWFpbHRvOnN0ZXBoZW4uZmFycmVsbEBjcy50Y2Qu aWVdDQo+IEVudm95w6nCoDogZGltYW5jaGUgMTcganVpbiAyMDE4IDIyOjA3DQo+IMOAwqA6IHNl Y2RpckBpZXRmLm9yZw0KPiBDY8KgOiBkcmFmdC1pZXRmLW9wc2F3Zy1uYXQteWFuZy5hbGxAaWV0 Zi5vcmc7IGlldGZAaWV0Zi5vcmc7IG9wc2F3Z0BpZXRmLm9yZw0KPiBPYmpldMKgOiBTZWNkaXIg bGFzdCBjYWxsIHJldmlldyBvZiBkcmFmdC1pZXRmLW9wc2F3Zy1uYXQteWFuZy0xNA0KPiANCj4g UmV2aWV3ZXI6IFN0ZXBoZW4gRmFycmVsbA0KPiBSZXZpZXcgcmVzdWx0OiBIYXMgSXNzdWVzDQo+ IA0KPiBJIHNlZSBvbmUgbWFqb3IgaXNzdWU6DQo+IA0KPiAyLjE6IExvZ2dpbmcgaW4gTkFUcyBh bmQgZXNwLiBDR05zIGlzIGNsZWFybHkgc2Vuc2l0aXZlIGluIHZhcmlvdXMgd2F5cy4gSQ0KPiB0 aGluayBpdCdkIGJlIG9rIGlmIGxvZ2dpbmcgd2FzIHJlYWxseSBvdXQgb2Ygc2NvcGUsIGhvd2V2 ZXIsIHRoZXJlIGlzIGENCj4gbG9nZ2luZy1lbmFibGUgZmVhdHVyZSwgSSB0aGluayB1bmRlci1z cGVjaWZpZWQsICAob24gcGFnZSA2Mykgc28gdGhlDQo+IHN0YXRlbWVudA0KPiBpbiAyLjEgc2Vl bXMgY29udHJhZGljdG9yeSB0byBtZSAtIGlmIGxvZ2dpbmcgaXMgb3V0IG9mIHNjb3BlIHdoeSBp cw0KPiBsb2dnaW5nLWVuYWJsZSBhIGZsYWc/LiAgUHJlc3VtYWJseSBpZiBsb2dnaW5nLWVuYWJs ZSB0cmFuc2l0aW9ucyBmcm9tIEYtPlQNCj4gdGhlbiB5b3UgdHVybiBvbiAoc29tZSB1bmRlZmlu ZWQga2luZCBvZikgbG9nZ2luZy4gDQoNCltNZWRdIFRoZSBpbnRlbnQgaXMgbm90IHRvIGRlZmlu ZSB0aGUgZXhhY3Qgc2V0IG9mIGxvZ2dpbmcgaW5mb3JtYXRpb24gKGUuZy4sIFNlY3Rpb24gNCBv ZiBSRkM2ODg4KSwgdGhlIHByb3RvY29sIHRvIHVzZSAoZS5nLiwgUkZDODE1OCBvciBkcmFmdC1p ZXRmLWJlaGF2ZS1zeXNsb2ctbmF0LWxvZ2dpbmcpLCBldGMuLi4gYnV0IHRvIGFsbG93IGZvciBk aXNhYmxpbmcvZW5hYmxpbmcgc3VjaCBmZWF0dXJlICh3aGVuIHN1cHBvcnRlZCBieSBhbiBpbXBs ZW1lbnRhdGlvbikuIA0KDQpJZiB0aGlzIHRyYW5zaXRpb25zIGZyb20NCj4gVC0+RiB0aGVuIHdo YXQgaXMgdGhlIGltcGxlbWVudGVyIHN1cHBvc2VkIHRvIGRvPw0KDQpbTWVkXSBUaGlzIHRyYW5z aXRpb24gd2lsbCBoYXZlIGFuIGVmZmVjdCB0byBkaXNhYmxlIEFOWSBsb2dnaW5nIGZlYXR1cmUg c3VwcG9ydGVkIGJ5IGFuIGltcGxlbWVudGF0aW9uLiBUaGUgdHJhbnNpdGlvbiBmb3IgRiB0byBU IGlzIG1vcmUgcHJvYmxlbWF0aWMgYXMgaXQgcmVxdWlyZXMgYWRkaXRpb25hbCBpbmZvcm1hdGlv biB0byBiZSBhdmFpbGFibGUgKGUuZy4sIGxvZ2dpbmcgc2VydmVyIElQIGFkZHJlc3MgYW5kIHBv cnQsIGNyZWRlbnRpYWxzLCAuLi4pLiBUaGUgZG9jdW1lbnQgYXNzdW1lcyB0aGF0IGRhdGEgaXMg cHJvdmlzaW9uZWQgdXNpbmcgb3RoZXIgc3BlY2lmaWMgbW9kdWxlcyAoc3lzbG9nLCBpcGZpeCwg ZXRjLikuDQoNCiBJIHRoaW5rIHRoYXQgaWxsdXN0cmF0ZXMNCj4gdGhlDQo+IHVuZGVyLXNwZWNp ZmljYXRpb24gaGVyZS4gVGhlIHNpbXBsZXN0IHRoaW5nIG1pZ2h0IGJlIHRvIHJlYWxseSBtYWtl IGxvZ2dpbmcNCj4gb3V0IG9mIHNjb3BlIGhlcmUgYnkgZGVsZXRpbmcgdGhlIGxvZ2dpbmctZW5h YmxlIHRoaW5nIGVudGlyZWx5LiAoSSBjYW4NCj4gaW1hZ2luZQ0KPiB0aGF0IHJlYWNoaW5nIGNv bnNlbnN1cyBvbiBhIGxvZ2dpbmcgY29udHJvbCBpbnRlcmZhY2Ugd291bGQgYmUgbm9uLXRyaXZp YWwsDQoNCltNZWRdIFRoZXJlIGlzIGFscmVhZHkgUkZDIDgxNTguDQoNCj4gaGVuY2UgdGhlIHN1 Z2dlc3Rpb24gdG8gcmVhbGx5IHB1dCBpdCBvdXQgb2Ygc2NvcGUgcmF0aGVyIHRoYW4gdHJ5IHNw ZWNpZnkgaXQNCj4gZnVsbHkuKQ0KPiANCg0KW01lZF0gSWYsIHdpdGggdGhlIGFib3ZlIGNsYXJp ZmljYXRpb24sIHlvdSBtYWludGFpbiB5b3VyIGNvbW1lbnQsIHRoZW4gSSBkb24ndCBoYXZlIGFu eSBvYmplY3Rpb24gdG8gcmVtb3ZlIHRoYXQgb3B0aW9uYWwgZmVhdHVyZSBmcm9tIHRoZSBtb2R1 bGUuIFBsZWFzZSBhZHZpc2UuIA0KDQo+IEp1c3Qgb25lIG5pdDoNCj4gDQo+IFRoZSBhYnN0cmFj dCBjb3VsZCBkbyB3aXRoIGEgYml0IG9mIHJlLXdvcmRpbmcgYXMgaXQgcmVhZHMgYXdrd2FyZGx5 LiAgSSdkDQo+IHNheQ0KPiBtYXliZSBqdXN0IGRlbGV0ZSB0aGUgMXN0IHNlbnRlbmNlLg0KPiAN Cg0KW01lZF0gT0suDQoNCg== From nobody Mon Jun 18 02:49:05 2018 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 71206130DCC; Mon, 18 Jun 2018 02:48:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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_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=cs.tcd.ie 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 5jBV8rZa94Ib; Mon, 18 Jun 2018 02:48:47 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7F1E1277C8; Mon, 18 Jun 2018 02:48:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 28D5DBE2E; Mon, 18 Jun 2018 10:48:45 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sbVbrxe_nzm2; Mon, 18 Jun 2018 10:48:45 +0100 (IST) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id DF127BE24; Mon, 18 Jun 2018 10:48:44 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1529315324; bh=2IqN8oJBHeSZP1zO8yk8BmWvDpBClQig4RyfA+Z4Sko=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=Z8cCckdjiI9vdHUgwFv9O3tbKKlHtWEfmvo88BJw7E1r/W+zGKEDsiDyWU72njT2S xw/4EbCXgHIDfSxjUOy00KzYSbMWx9ET21Pc8sNoOVaFizJ5dmboCJqO+5kNx7cNL0 oqozcxJ5U2RFy96JTXtSXoK57uoMNixpX1MLYNpc= To: mohamed.boucadair@orange.com, "secdir@ietf.org" Cc: "draft-ietf-opsawg-nat-yang.all@ietf.org" , "ietf@ietf.org" , "opsawg@ietf.org" References: <152926599250.2311.15532810595098738604@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302DF4678E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABzTJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPsLBgAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxM7BTQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAcLBZQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <1c4bf138-afb1-4aef-ddb5-b15262b05af2@cs.tcd.ie> Date: Mon, 18 Jun 2018 10:48:43 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B93302DF4678E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="dMyLed2VmvreUswV1UzhTlEZptsFSuARy" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-opsawg-nat-yang-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2018 09:48:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --dMyLed2VmvreUswV1UzhTlEZptsFSuARy Content-Type: multipart/mixed; boundary="qEzOqJkie2A8ch9pz1ePvlpfHMN72ZYWB"; protected-headers="v1" From: Stephen Farrell To: mohamed.boucadair@orange.com, "secdir@ietf.org" Cc: "draft-ietf-opsawg-nat-yang.all@ietf.org" , "ietf@ietf.org" , "opsawg@ietf.org" Message-ID: <1c4bf138-afb1-4aef-ddb5-b15262b05af2@cs.tcd.ie> Subject: Re: Secdir last call review of draft-ietf-opsawg-nat-yang-14 References: <152926599250.2311.15532810595098738604@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302DF4678E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302DF4678E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> --qEzOqJkie2A8ch9pz1ePvlpfHMN72ZYWB Content-Type: multipart/mixed; boundary="------------D644238EA9BC3548F949AFD9" Content-Language: en-GB This is a multi-part message in MIME format. --------------D644238EA9BC3548F949AFD9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Med, On 18/06/18 08:10, mohamed.boucadair@orange.com wrote: > Hi Stephen, >=20 > Thank you for the review. >=20 > Please see inline. >=20 > Cheers, Med >=20 >> -----Message d'origine----- De : Stephen Farrell >> [mailto:stephen.farrell@cs.tcd.ie] Envoy=C3=A9 : dimanche 17 juin 2018= >> 22:07 =C3=80 : secdir@ietf.org Cc : >> draft-ietf-opsawg-nat-yang.all@ietf.org; ietf@ietf.org; >> opsawg@ietf.org Objet : Secdir last call review of >> draft-ietf-opsawg-nat-yang-14 >>=20 >> Reviewer: Stephen Farrell Review result: Has Issues >>=20 >> I see one major issue: >>=20 >> 2.1: Logging in NATs and esp. CGNs is clearly sensitive in various >> ways. I think it'd be ok if logging was really out of scope, >> however, there is a logging-enable feature, I think >> under-specified, (on page 63) so the statement in 2.1 seems >> contradictory to me - if logging is out of scope why is=20 >> logging-enable a flag?. Presumably if logging-enable transitions >> from F->T then you turn on (some undefined kind of) logging. >=20 > [Med] The intent is not to define the exact set of logging > information (e.g., Section 4 of RFC6888), the protocol to use (e.g., > RFC8158 or draft-ietf-behave-syslog-nat-logging), etc... but to allow > for disabling/enabling such feature (when supported by an > implementation). Sure, I get the idea. I guess I'm not sure it's a good idea though, if not more fully specified. >=20 > If this transitions from >> T->F then what is the implementer supposed to do? >=20 > [Med] This transition will have an effect to disable ANY logging > feature supported by an implementation.=20 Really? I'd have thought there was going to be some logging that was always on, e.g. to detect attacks. Or maybe you're not calling that logging? (I think that maybe also illustrates that as-is, this is currently not very well defined.) > The transition for F to T is > more problematic as it requires additional information to be > available (e.g., logging server IP address and port, credentials, > ...). The document assumes that data is provisioned using other > specific modules (syslog, ipfix, etc.). I suspect that there'd also be a need for information about data retention duration and scope, for logging that is local to the NAT box. >=20 >> I think that illustrates >> the under-specification here. The simplest thing might be to really >> make logging out of scope here by deleting the logging-enable thing >> entirely. (I can imagine that reaching consensus on a logging >> control interface would be non-trivial, >=20 > [Med] There is already RFC 8158. >=20 >> hence the suggestion to really put it out of scope rather than try >> specify it fully.) >>=20 >=20 > [Med] If, with the above clarification, you maintain your comment, > then I don't have any objection to remove that optional feature from > the module. Please advise. Well, mine is just a secdir review - you're not forced to do anything at all about it (unless some AD decides that you need to). But FWIW, yes, I do think it'd be better to drop that from this draft, and maybe consider working on some other interface to handle it better. Cheers, S. >=20 >> Just one nit: >>=20 >> The abstract could do with a bit of re-wording as it reads >> awkwardly. I'd say maybe just delete the 1st sentence. >>=20 >=20 > [Med] OK. >=20 --------------D644238EA9BC3548F949AFD9 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1bQyU3RlcGhlbiBGYXJy ZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT6JAkAEEwEIACoC GwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o3cCGQEACgkQWrL6 8XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKow5o DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp 0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCr uFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+t AIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k4S+sN2CnYk4tTW7jHjsWarV3FLIS COObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4EIkCXAJUtzJhoFUuGaF /PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZDIJpdzh LiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelce ZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizM XnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+X QeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd8MxYNAbNYgSPtkbhZ8SJARwEEAEI AAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGtw/r1miKNGcopzvzILQ9oB8r KI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZJaf3bJXinDZ 5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u 14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpC XRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB 5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlve2Q6UTrmHxP5U22DlokCPQQTAQgA JwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx excr6tJpD/4rrILH+meP07vrx8wW5eYuqCiPGYnh/CXxIF8eLrfbe5d4QRgtq+w6 UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dTMrEGn8QWKx2iNuz9rZMXyOSWFetu O01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9gQ7edR9mfLTdvBf2FR522hg8BRBM 1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZXripS0uFA07dM46Oi/E8osjx6fQt/ lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGFL64/VCQb1YGjf0Z5MBPnWm9jgUoO Y5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2DFeo9+S9f2V53Llz1WIspXJg6f+n9 lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCbhrC3+yobyy/AUOs5Z3E+njjX1FF/ VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10MSU8GEZu9ayU4M3o3N9yxOjaoP0Nu Q4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXtGKvJtFAEppGEYezB+bLKIm6XlpPk hnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA5rEP4lL16BmijmF+CHoPE/zwgKZb KpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ksZgUUnNyvfQr2p7jrQuU3RlcGhl biBGYXJyZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgA JwUCWj1RWgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx excr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvn crAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtg rlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIg pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5c F8R4OvB1n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaP y1/fEgIqhCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5 b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7 b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkpo rMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXR dS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGl Ru78ba0HArxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgA BgUCWj1SoAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89Sq Bd++uG06TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VO dL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD 4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lz nNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8I WOMqN2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBuQINBFo9UDIB EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4H Jee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOU NuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8 tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE4bGjXdJW5pKphFB2lX3d G4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbTuW/eITbMbI1eV3+fyym 9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yDaWT3NAp vi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDP ck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpny qMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayX XJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtv T51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1gwARAQABiQIlBBgBCAAP BQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6MasqXyrBjwc LmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOx iRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwm h+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNcz mq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqo p+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGsokRina9947fRWxXHh3O6 6ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN2OE0C1chqgDZQxk r+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHTzcS oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n /9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfj mLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZi nUk+H3pkqOKoHAy/8fST =3DTOQn -----END PGP PUBLIC KEY BLOCK----- --------------D644238EA9BC3548F949AFD9-- --qEzOqJkie2A8ch9pz1ePvlpfHMN72ZYWB-- --dMyLed2VmvreUswV1UzhTlEZptsFSuARy Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlsnf/sACgkQWrL68XsX K+rojg//a2+vxRrUmdFpFJKA7V/sNzcTREVd/IyC59xSjRd3sW9InXvRqk4rPhq+ H0zpcSxFYpP2SR1oJCHGaPphyXx2nvyzT3asOW0x4NyMqWjzvQC/vb97iwTWfG3S vPkbER79U60kdOC6n7MlRnuhAZGSHaBKeBWcBPo6cALnIUdi8xzjyqRuk7vSV2eM Qn8CnAJcSnO745u2b8XYDBScGK50VkhtTDEuVEawsR6icb97netF/6kPTMrc7F4p yKjpJXorZIKzDB6CSGl9rHE5NovSPnXSTJrSmebd9sewWGcovhSYYCg9LGf+Po5w nXizqIW86gSktrsSYOBhoumnVbOodVVwjc9LiPIZfIEfXh3EC+Xlt2yIvPa84jFG 2ihEN7Ns8lMCpQu6/HXAgn7x7ZzvA7CTEaymD1qpQ6q6Q860Qx0vmeE9R3z3oLn4 1gsxqR/nZB4igkfHN4ZZLNm5Bt+ws/3CDUledtkVwSORQfqd3JnM9lygQHhEXtuh JVB/OjA2gsHySB4guRLk0B2vSDRD/G3r2HmYr4A4LnKSlSiQ8WHhfYUS1KMhdXAX NZCEiE7+fAzfj3EyUcMvu4ednfyH5T4C98/9oP1X2ncuNU3OkYmIiMiJqTTt6TQ3 VEaZHTm+lYtuBOUyDMok9QIxmy1nEzvI1a0zit2gUIzN21kvxTA= =gNj/ -----END PGP SIGNATURE----- --dMyLed2VmvreUswV1UzhTlEZptsFSuARy-- From nobody Mon Jun 18 04:14:12 2018 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 DFD24130E96; Mon, 18 Jun 2018 04:13:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 gsjao4f2dUoO; Mon, 18 Jun 2018 04:13:53 -0700 (PDT) Received: from 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 F2A8F130DDF; Mon, 18 Jun 2018 04:13:52 -0700 (PDT) Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) by opfedar27.francetelecom.fr (ESMTP service) with ESMTP id 418T4H4dtrz2yl5; Mon, 18 Jun 2018 13:13:51 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.43]) by opfedar01.francetelecom.fr (ESMTP service) with ESMTP id E2E38160098; Mon, 18 Jun 2018 13:13:38 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM5F.corporate.adroot.infra.ftgroup ([fe80::e172:f13e:8be6:71cc%18]) with mapi id 14.03.0399.000; Mon, 18 Jun 2018 13:13:38 +0200 From: To: Stephen Farrell , "secdir@ietf.org" CC: "draft-ietf-opsawg-nat-yang.all@ietf.org" , "ietf@ietf.org" , "opsawg@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-opsawg-nat-yang-14 Thread-Index: AQHUBumN98KCqFI0Y0G23qLjJqwx/6Rl2k7Q Date: Mon, 18 Jun 2018 11:13:38 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DF469A7@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <152926599250.2311.15532810595098738604@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302DF4678E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <1c4bf138-afb1-4aef-ddb5-b15262b05af2@cs.tcd.ie> In-Reply-To: <1c4bf138-afb1-4aef-ddb5-b15262b05af2@cs.tcd.ie> 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: 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-opsawg-nat-yang-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2018 11:13:56 -0000 UmUtLA0KDQpQbGVhc2Ugc2VlIGlubGluZS4gDQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0tTWVz c2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKgOiBTdGVwaGVuIEZhcnJlbGwgW21haWx0bzpzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllXQ0KPiBFbnZvecOpwqA6IGx1bmRpIDE4IGp1aW4gMjAxOCAx MTo0OQ0KPiDDgMKgOiBCT1VDQURBSVIgTW9oYW1lZCBJTVQvT0xOOyBzZWNkaXJAaWV0Zi5vcmcN Cj4gQ2PCoDogZHJhZnQtaWV0Zi1vcHNhd2ctbmF0LXlhbmcuYWxsQGlldGYub3JnOyBpZXRmQGll dGYub3JnOyBvcHNhd2dAaWV0Zi5vcmcNCj4gT2JqZXTCoDogUmU6IFNlY2RpciBsYXN0IGNhbGwg cmV2aWV3IG9mIGRyYWZ0LWlldGYtb3BzYXdnLW5hdC15YW5nLTE0DQo+IA0KPiANCj4gSGkgTWVk LA0KPiANCj4gT24gMTgvMDYvMTggMDg6MTAsIG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20g d3JvdGU6DQo+ID4gSGkgU3RlcGhlbiwNCj4gPg0KPiA+IFRoYW5rIHlvdSBmb3IgdGhlIHJldmll dy4NCj4gPg0KPiA+IFBsZWFzZSBzZWUgaW5saW5lLg0KPiA+DQo+ID4gQ2hlZXJzLCBNZWQNCj4g Pg0KPiA+PiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0gRGUgOiBTdGVwaGVuIEZhcnJlbGwN Cj4gPj4gW21haWx0bzpzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllXSBFbnZvecOpIDogZGltYW5j aGUgMTcganVpbiAyMDE4DQo+ID4+IDIyOjA3IMOAIDogc2VjZGlyQGlldGYub3JnIENjIDoNCj4g Pj4gZHJhZnQtaWV0Zi1vcHNhd2ctbmF0LXlhbmcuYWxsQGlldGYub3JnOyBpZXRmQGlldGYub3Jn Ow0KPiA+PiBvcHNhd2dAaWV0Zi5vcmcgT2JqZXQgOiBTZWNkaXIgbGFzdCBjYWxsIHJldmlldyBv Zg0KPiA+PiBkcmFmdC1pZXRmLW9wc2F3Zy1uYXQteWFuZy0xNA0KPiA+Pg0KPiA+PiBSZXZpZXdl cjogU3RlcGhlbiBGYXJyZWxsIFJldmlldyByZXN1bHQ6IEhhcyBJc3N1ZXMNCj4gPj4NCj4gPj4g SSBzZWUgb25lIG1ham9yIGlzc3VlOg0KPiA+Pg0KPiA+PiAyLjE6IExvZ2dpbmcgaW4gTkFUcyBh bmQgZXNwLiBDR05zIGlzIGNsZWFybHkgc2Vuc2l0aXZlIGluIHZhcmlvdXMNCj4gPj4gd2F5cy4g SSB0aGluayBpdCdkIGJlIG9rIGlmIGxvZ2dpbmcgd2FzIHJlYWxseSBvdXQgb2Ygc2NvcGUsDQo+ ID4+IGhvd2V2ZXIsIHRoZXJlIGlzIGEgbG9nZ2luZy1lbmFibGUgZmVhdHVyZSwgSSB0aGluaw0K PiA+PiB1bmRlci1zcGVjaWZpZWQsICAob24gcGFnZSA2Mykgc28gdGhlIHN0YXRlbWVudCBpbiAy LjEgc2VlbXMNCj4gPj4gY29udHJhZGljdG9yeSB0byBtZSAtIGlmIGxvZ2dpbmcgaXMgb3V0IG9m IHNjb3BlIHdoeSBpcw0KPiA+PiBsb2dnaW5nLWVuYWJsZSBhIGZsYWc/LiAgUHJlc3VtYWJseSBp ZiBsb2dnaW5nLWVuYWJsZSB0cmFuc2l0aW9ucw0KPiA+PiBmcm9tIEYtPlQgdGhlbiB5b3UgdHVy biBvbiAoc29tZSB1bmRlZmluZWQga2luZCBvZikgbG9nZ2luZy4NCj4gPg0KPiA+IFtNZWRdIFRo ZSBpbnRlbnQgaXMgbm90IHRvIGRlZmluZSB0aGUgZXhhY3Qgc2V0IG9mIGxvZ2dpbmcNCj4gPiBp bmZvcm1hdGlvbiAoZS5nLiwgU2VjdGlvbiA0IG9mIFJGQzY4ODgpLCB0aGUgcHJvdG9jb2wgdG8g dXNlIChlLmcuLA0KPiA+IFJGQzgxNTggb3IgZHJhZnQtaWV0Zi1iZWhhdmUtc3lzbG9nLW5hdC1s b2dnaW5nKSwgZXRjLi4uIGJ1dCB0byBhbGxvdw0KPiA+IGZvciBkaXNhYmxpbmcvZW5hYmxpbmcg c3VjaCBmZWF0dXJlICh3aGVuIHN1cHBvcnRlZCBieSBhbg0KPiA+IGltcGxlbWVudGF0aW9uKS4N Cj4gDQo+IFN1cmUsIEkgZ2V0IHRoZSBpZGVhLiBJIGd1ZXNzIEknbSBub3Qgc3VyZSBpdCdzIGEg Z29vZCBpZGVhDQo+IHRob3VnaCwgaWYgbm90IG1vcmUgZnVsbHkgc3BlY2lmaWVkLg0KPiANCj4g Pg0KPiA+IElmIHRoaXMgdHJhbnNpdGlvbnMgZnJvbQ0KPiA+PiBULT5GIHRoZW4gd2hhdCBpcyB0 aGUgaW1wbGVtZW50ZXIgc3VwcG9zZWQgdG8gZG8/DQo+ID4NCj4gPiBbTWVkXSBUaGlzIHRyYW5z aXRpb24gd2lsbCBoYXZlIGFuIGVmZmVjdCB0byBkaXNhYmxlIEFOWSBsb2dnaW5nDQo+ID4gZmVh dHVyZSBzdXBwb3J0ZWQgYnkgYW4gaW1wbGVtZW50YXRpb24uDQo+IA0KPiBSZWFsbHk/IEknZCBo YXZlIHRob3VnaHQgdGhlcmUgd2FzIGdvaW5nIHRvIGJlIHNvbWUgbG9nZ2luZw0KPiB0aGF0IHdh cyBhbHdheXMgb24sIGUuZy4gdG8gZGV0ZWN0IGF0dGFja3MuDQoNCltNZWRdIFRoaXMgaXMgZGVw bG95bWVudC1zcGVjaWZpYy4gRm9yIGV4YW1wbGUsIGEgQ0dOIHdoaWNoIGlzIGNvbmZpZ3VyZWQg dG8gYmVoYXZlIGluIHBvcnQgZGV0ZXJtaW5pc3RpYyBiZWhhdmlvciAoUkZDNzQyMikgaW5zdGVh ZCBvZiBhbm90aGVyIHBvcnQgYXNzaWdubWVudCBzY2hlbWUgZG9lcyBub3QgbmVlZCB0byBlbmFi bGUgbG9nZ2luZyBzaW5jZSB0aGUgaW50ZXJuYWwgSVAgYWRkcmVzcy9wb3J0KC1yYW5nZSkgaXMg YSBmdW5jdGlvbiBvZiB0aGUgZXh0ZXJuYWwgSVAgYWRkcmVzcy9wb3J0KC1yYW5nZSkuDQoNCiBP ciBtYXliZSB5b3UncmUNCj4gbm90IGNhbGxpbmcgdGhhdCBsb2dnaW5nPyAoSSB0aGluayB0aGF0 IG1heWJlIGFsc28gaWxsdXN0cmF0ZXMNCj4gdGhhdCBhcy1pcywgdGhpcyBpcyBjdXJyZW50bHkg bm90IHZlcnkgd2VsbCBkZWZpbmVkLikNCj4gDQo+ID4gVGhlIHRyYW5zaXRpb24gZm9yIEYgdG8g VCBpcw0KPiA+IG1vcmUgcHJvYmxlbWF0aWMgYXMgaXQgcmVxdWlyZXMgYWRkaXRpb25hbCBpbmZv cm1hdGlvbiB0byBiZQ0KPiA+IGF2YWlsYWJsZSAoZS5nLiwgbG9nZ2luZyBzZXJ2ZXIgSVAgYWRk cmVzcyBhbmQgcG9ydCwgY3JlZGVudGlhbHMsDQo+ID4gLi4uKS4gVGhlIGRvY3VtZW50IGFzc3Vt ZXMgdGhhdCBkYXRhIGlzIHByb3Zpc2lvbmVkIHVzaW5nIG90aGVyDQo+ID4gc3BlY2lmaWMgbW9k dWxlcyAoc3lzbG9nLCBpcGZpeCwgZXRjLikuDQo+IA0KPiBJIHN1c3BlY3QgdGhhdCB0aGVyZSdk IGFsc28gYmUgYSBuZWVkIGZvciBpbmZvcm1hdGlvbiBhYm91dA0KPiBkYXRhIHJldGVudGlvbiBk dXJhdGlvbiBhbmQgc2NvcGUsIGZvciBsb2dnaW5nIHRoYXQgaXMgbG9jYWwNCj4gdG8gdGhlIE5B VCBib3guDQoNCltNZWRdIFR5cGljYWxseSwgZGF0YSByZXRlbnRpb24gZHVyYXRpb24gaXMgbm90 IGhhbmRsZWQgYXQgdGhlIE5BVCBpdHNlbGYgYnV0IGFzIHBhcnQgb2YgYSAiZGVkaWNhdGVkIiBw bGF0Zm9ybSB0aGF0IGlzIHVzZWQgdG8gZ2F0aGVyIGxvZ2dpbmcgaW5mb3JtYXRpb24gZnJvbSB2 YXJpb3VzIHNvdXJjZXMgaW4gYSBuZXR3b3JrLiAgDQoNCj4gDQo+ID4NCj4gPj4gSSB0aGluayB0 aGF0IGlsbHVzdHJhdGVzDQo+ID4+IHRoZSB1bmRlci1zcGVjaWZpY2F0aW9uIGhlcmUuIFRoZSBz aW1wbGVzdCB0aGluZyBtaWdodCBiZSB0byByZWFsbHkNCj4gPj4gbWFrZSBsb2dnaW5nIG91dCBv ZiBzY29wZSBoZXJlIGJ5IGRlbGV0aW5nIHRoZSBsb2dnaW5nLWVuYWJsZSB0aGluZw0KPiA+PiBl bnRpcmVseS4gKEkgY2FuIGltYWdpbmUgdGhhdCByZWFjaGluZyBjb25zZW5zdXMgb24gYSBsb2dn aW5nDQo+ID4+IGNvbnRyb2wgaW50ZXJmYWNlIHdvdWxkIGJlIG5vbi10cml2aWFsLA0KPiA+DQo+ ID4gW01lZF0gVGhlcmUgaXMgYWxyZWFkeSBSRkMgODE1OC4NCj4gPg0KPiA+PiBoZW5jZSB0aGUg c3VnZ2VzdGlvbiB0byByZWFsbHkgcHV0IGl0IG91dCBvZiBzY29wZSByYXRoZXIgdGhhbiB0cnkN Cj4gPj4gc3BlY2lmeSBpdCBmdWxseS4pDQo+ID4+DQo+ID4NCj4gPiBbTWVkXSBJZiwgd2l0aCB0 aGUgYWJvdmUgY2xhcmlmaWNhdGlvbiwgeW91IG1haW50YWluIHlvdXIgY29tbWVudCwNCj4gPiB0 aGVuIEkgZG9uJ3QgaGF2ZSBhbnkgb2JqZWN0aW9uIHRvIHJlbW92ZSB0aGF0IG9wdGlvbmFsIGZl YXR1cmUgZnJvbQ0KPiA+IHRoZSBtb2R1bGUuIFBsZWFzZSBhZHZpc2UuDQo+IA0KPiBXZWxsLCBt aW5lIGlzIGp1c3QgYSBzZWNkaXIgcmV2aWV3IC0geW91J3JlIG5vdCBmb3JjZWQgdG8gZG8NCj4g YW55dGhpbmcgYXQgYWxsIGFib3V0IGl0ICh1bmxlc3Mgc29tZSBBRCBkZWNpZGVzIHRoYXQgeW91 IG5lZWQNCj4gdG8pLiBCdXQgRldJVywgeWVzLCBJIGRvIHRoaW5rIGl0J2QgYmUgYmV0dGVyIHRv IGRyb3AgdGhhdCBmcm9tDQo+IHRoaXMgZHJhZnQsIGFuZCBtYXliZSBjb25zaWRlciB3b3JraW5n IG9uIHNvbWUgb3RoZXIgaW50ZXJmYWNlDQo+IHRvIGhhbmRsZSBpdCBiZXR0ZXIuDQo+IA0KDQpb TWVkXSBBQ0suICANCg0KPiBDaGVlcnMsDQo+IFMuDQo+IA0KPiANCj4gDQo+ID4NCj4gPj4gSnVz dCBvbmUgbml0Og0KPiA+Pg0KPiA+PiBUaGUgYWJzdHJhY3QgY291bGQgZG8gd2l0aCBhIGJpdCBv ZiByZS13b3JkaW5nIGFzIGl0IHJlYWRzDQo+ID4+IGF3a3dhcmRseS4gIEknZCBzYXkgbWF5YmUg anVzdCBkZWxldGUgdGhlIDFzdCBzZW50ZW5jZS4NCj4gPj4NCj4gPg0KPiA+IFtNZWRdIE9LLg0K PiA+DQo= From nobody Tue Jun 19 06:43:53 2018 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 5824A130F59; Tue, 19 Jun 2018 06:43:44 -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 mTQU4bFBAKZf; Tue, 19 Jun 2018 06:43:39 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id CC1331310F7; Tue, 19 Jun 2018 06:43:19 -0700 (PDT) Received: from [192.168.20.16] (CPEf4cc55220745-CM64777ddff610.cpe.net.cable.rogers.com [173.32.191.82]) by mail.networkradius.com (Postfix) with ESMTPSA id 0C9B010E; Tue, 19 Jun 2018 13:43:17 +0000 (UTC) From: Alan DeKok Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 19 Jun 2018 09:43:17 -0400 Message-Id: Cc: draft-ietf-pals-ethernet-cw@ietf.org To: secdir@ietf.org, IESG Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [secdir] Secdir review of draft-ietf-pals-ethernet-cw X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 13:43:45 -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= From nobody Tue Jun 19 07:46:31 2018 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 D254F130DCB; Tue, 19 Jun 2018 07:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 LgPtoC2L4xi8; Tue, 19 Jun 2018 07:46:19 -0700 (PDT) Received: from out27-ams.mf.surf.net (out27-ams.mf.surf.net [145.0.1.27]) (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 B7285130F23; Tue, 19 Jun 2018 07:46:18 -0700 (PDT) Received: from mail.het.net.je (mail.het.net.je [192.87.110.20]) by outgoing1-ams.mf.surf.net (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id w5JEkFYK009472 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 19 Jun 2018 16:46:16 +0200 Received: from [2001:610:9d8:4:d106:bda2:89f0:a6cf] (helo=GEANT-AMS-036-Wierenga-2.local) by mail.het.net.je with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1fVHtf-0006EG-Oa; Tue, 19 Jun 2018 16:46:15 +0200 From: Klaas Wierenga To: iesg@ietf.org, secdir@ietf.org, draft-richer-vectors-of-trust.all@ietf.org Message-ID: <792fcf56-d568-7da7-3dbe-b858bb8c99d3@wierenga.net> Date: Tue, 19 Jun 2018 16:46:15 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-Antivirus: no malware found X-Bayes-Prob: 0.0001 (Score 0, tokens from: p-out:default, p:default, base:default, @@RPTN) X-CanIt-Geo: ip=192.87.110.20; country=NL; latitude=52.3824; longitude=4.8995; http://maps.google.com/maps?q=52.3824,4.8995&z=6 X-CanItPRO-Stream: p-out:default (inherits from p:default,base:default) X-Canit-Stats-ID: 0uW0CKfaU - 5ae5dc831f97 - 20180619 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: Subject: [secdir] review of draft-richer-vectors-of-trust-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 14:46:23 -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 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" The document defines a method of signaling multiple relevant aspects of a digital identity transaction instead of a single "level of assurance" that is supposed to capture all of those aspects into one single value. The document is well written and provides clear guidance as to how the various aspects of an identity transaction can be expressed, without exploding the solution space. The majority of the comments I have are to do with assuming too much prior knowledge from the reader and two more subtsntial comments: chapter 1, page 3: the second paragraph describes the vectors rather abstract which may prove difficult to the reader, I would recommend to add here something like "for example identity proofing, credential strength etc.) instead of in the 4th paragraph chapter 1.1: I thought some of that terminology had been defined in another RFC, but unfortunately I couldn't find it chapter 1.2: The main thing I am missing here is a reference to Attribute Authorities (AAs). I do realise that introducing AAs complicates the trust model big time, and am totally ok with declaring that out of scope, but I don't think you can just pretend they don;t exist, especially since we are seeing a movement towards it. chapter 2.2: I am not crazy about the word "Usage", I think you are looking for a word that expresses something akin to "strength" (without wanting to imply ordering) chapter 2.2, paragraph 2: You write that no ordering should be implied, and I presume that is why you distinguish between vectors that use numbers and those that use letters. I find that not very convincing, letters equally imply order, so i see no compelling reason to not use either numbers or letters in all cases instead of mixing up chapter 3.2: have you considered adding also a SAML example, since that is widely used as well? chapter 8.1: it is unclear to me what meeting the criteria means (and what is good, what is bad, and what the treshold should be) chapter 9: isn't it true that the "strength" of the assertion of a vector can only be as good as the cryptographical protection in transit? Cheers, Klaas From nobody Tue Jun 19 18:18:04 2018 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 C2DF9130E09; Tue, 19 Jun 2018 18:17:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 ov_q6e9fccb5; Tue, 19 Jun 2018 18:17:53 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (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 5DB69130E54; Tue, 19 Jun 2018 18:17:53 -0700 (PDT) X-AuditID: 12074424-f45ff7000000610d-ea-5b29ab4041db 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-7.mit.edu (Symantec Messaging Gateway) with SMTP id DB.24.24845.04BA92B5; Tue, 19 Jun 2018 21:17:52 -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 w5K1HoRu008124; Tue, 19 Jun 2018 21:17:51 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w5K1HjY7019370 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 19 Jun 2018 21:17:48 -0400 Date: Tue, 19 Jun 2018 20:17:44 -0500 From: Benjamin Kaduk To: Klaas Wierenga Cc: iesg@ietf.org, secdir@ietf.org, draft-richer-vectors-of-trust.all@ietf.org Message-ID: <20180620011744.GI4946@kduck.kaduk.org> References: <792fcf56-d568-7da7-3dbe-b858bb8c99d3@wierenga.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <792fcf56-d568-7da7-3dbe-b858bb8c99d3@wierenga.net> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPIsWRmVeSWpSXmKPExsUixCmqreuwWjPaYP1uYYvtH1awWcz4M5HZ YubFS8wWHxY+ZHFg8Viy5CeTx+R33xkDmKK4bFJSczLLUov07RK4MhY2TGcs2CJesa3zKXMD 4zOhLkZODgkBE4mJH7YxdjFycQgJLGaSeDZzKwuEs5FR4srjzVDOVSaJBf+nsYK0sAioSkxa 1A1mswmoSDR0X2YGsUUE1CW+7zzMDmIzC/hJbO39yQZiCwuYSxxr3AW0goODV8BYYurSeJCw kIC9xKyvLYwgNq+AoMTJmU9YIFq1JG78e8kEUs4sIC2x/B8HiMkp4CDxqNsbpEJUQFlib98h 9gmMArOQNM9C0jwLoXkBI/MqRtmU3Crd3MTMnOLUZN3i5MS8vNQiXXO93MwSvdSU0k2MoLBl d1HZwdjd432IUYCDUYmHl4FZM1qINbGsuDL3EKMkB5OSKC/XCqAQX1J+SmVGYnFGfFFpTmrx IUYJDmYlEV6GUxrRQrwpiZVVqUX5MClpDhYlcd7cRYzRQgLpiSWp2ampBalFMFkZDg4lCd51 q4CGChalpqdWpGXmlCCkmTg4QYbzAA03BlnMW1yQmFucmQ6RP8Woy3Hs8rQeZiGWvPy8VClx 3sMggwRAijJK8+DmgNKNRPb+mleM4kBvCfO+XQlUxQNMVXCTXgEtYQJasqVKHWRJSSJCSqqB MYJrTfgafvsd7JXCT7oE73Qf2RhsHsjhuE/8zTRFj6T7sTKHWv2vdR5S3nt6s5m1rk7btS2s 50zSjV88bnGb4e3w7MCNh68z0y1qEgT4rt88Vv1qmd+Wxb90areIhF1ZafqtftGco9yXMhf0 uwuIMBvNfH7vx/nshxuSRf237DXe4bZr5c0PH5RYijMSDbWYi4oTAax0NGcSAwAA Archived-At: Subject: Re: [secdir] review of draft-richer-vectors-of-trust-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 01:17:57 -0000 Hi Klaas, Thanks for the review! I am sure the authors will respond, so I will just touch on one note... On Tue, Jun 19, 2018 at 04:46:15PM +0200, Klaas Wierenga wrote: > 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 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" > > The document defines a method of signaling multiple relevant aspects of a digital identity transaction instead of a single "level of assurance" that is supposed to capture all of those aspects into one single value. > The document is well written and provides clear guidance as to how the various aspects of an identity transaction can be expressed, without exploding the solution space. The majority of the comments I have are to do with assuming too much prior knowledge from the reader and two more subtsntial comments: > > > chapter 1, page 3: the second paragraph describes the vectors rather abstract which may prove difficult to the reader, I would recommend to add here something like "for example identity proofing, credential strength etc.) instead of in the 4th paragraph > > chapter 1.1: I thought some of that terminology had been defined in another RFC, but unfortunately I couldn't find it > > chapter 1.2: The main thing I am missing here is a reference to Attribute Authorities (AAs). I do realise that introducing AAs complicates the trust model big time, and am totally ok with declaring that out of scope, but I don't think you can just pretend they don;t exist, especially since we are seeing a movement towards it. > > chapter 2.2: I am not crazy about the word "Usage", I think you are looking for a word that expresses something akin to "strength" (without wanting to imply ordering) > > chapter 2.2, paragraph 2: You write that no ordering should be implied, and I presume that is why you distinguish between vectors that use numbers and those that use letters. I find that not very convincing, letters equally imply order, so i see no compelling reason to not use either numbers or letters in all cases instead of mixing up > > chapter 3.2: have you considered adding also a SAML example, since that is widely used as well? There was a SAML example in a previous version of the draft, but none of us could convince ourselves that we could validate its correctness properly, so we removed it out of expediency. -Benjamin (as responsible AD) > chapter 8.1: it is unclear to me what meeting the criteria means (and what is good, what is bad, and what the treshold should be) > > chapter 9: isn't it true that the "strength" of the assertion of a vector can only be as good as the cryptographical protection in transit? > > Cheers, > > Klaas > From nobody Wed Jun 20 22:28:52 2018 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 C3F821311E4; Wed, 20 Jun 2018 22:28:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 I4t48Qtyz1R5; Wed, 20 Jun 2018 22:28:48 -0700 (PDT) Received: from out65-ams.mf.surf.net (out65-ams.mf.surf.net [145.0.1.65]) (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 950A213103D; Wed, 20 Jun 2018 22:28:48 -0700 (PDT) Received: from mail.het.net.je (mail.het.net.je [192.87.110.20]) by outgoing3-ams.mf.surf.net (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id w5L5SgmM031470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 21 Jun 2018 07:28:43 +0200 Received: from [62.140.137.116] (helo=[100.116.155.232]) by mail.het.net.je with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1fVs9F-0007B4-Gy; Thu, 21 Jun 2018 07:28:45 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Klaas Wierenga X-Mailer: iPhone Mail (15F79) In-Reply-To: <20180620011744.GI4946@kduck.kaduk.org> Date: Thu, 21 Jun 2018 07:28:44 +0200 Cc: iesg@ietf.org, secdir@ietf.org, draft-richer-vectors-of-trust.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <88D1F2CB-0FC2-45A9-BDE7-A21F8D01FE0D@wierenga.net> References: <792fcf56-d568-7da7-3dbe-b858bb8c99d3@wierenga.net> <20180620011744.GI4946@kduck.kaduk.org> To: Benjamin Kaduk X-Antivirus: no malware found X-Bayes-Prob: 0.0001 (Score 0, tokens from: p-out:default, p:default, base:default, @@RPTN) X-CanIt-Geo: ip=192.87.110.20; country=NL; latitude=52.3824; longitude=4.8995; http://maps.google.com/maps?q=52.3824,4.8995&z=6 X-CanItPRO-Stream: p-out:default (inherits from p:default,base:default) X-Canit-Stats-ID: 0bW1hsHhO - 7490cfe3a6dc - 20180621 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: Subject: Re: [secdir] review of draft-richer-vectors-of-trust-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 05:28:51 -0000 Hi Benjamin, Thanks for the explanation. Klaas Sent from my iPhone > On 20 Jun 2018, at 03:17, Benjamin Kaduk wrote: >=20 > Hi Klaas, >=20 > Thanks for the review! I am sure the authors will respond, so I > will just touch on one note... >=20 >> On Tue, Jun 19, 2018 at 04:46:15PM +0200, Klaas Wierenga wrote: >> Hi, >>=20 >> I have reviewed this document as part of the security directorate's ongoi= ng effort to review all IETF documents being processed by the IESG. These c= omments were written primarily for the benefit of the=20 >> security area directors. Document editors and WG chairs should treat the= se comments just like any other last call comments. >>=20 >> The summary of the review is: "ready with nits" >>=20 >> The document defines a method of signaling multiple relevant aspects of a= digital identity transaction instead of a single "level of assurance" that i= s supposed to capture all of those aspects into one single value. >> The document is well written and provides clear guidance as to how the va= rious aspects of an identity transaction can be expressed, without exploding= the solution space. The majority of the comments I have are to do with assu= ming too much prior knowledge from the reader and two more subtsntial commen= ts: >>=20 >>=20 >> chapter 1, page 3: the second paragraph describes the vectors rather abst= ract which may prove difficult to the reader, I would recommend to add here s= omething like "for example identity proofing, credential strength etc.) inst= ead of in the 4th paragraph >>=20 >> chapter 1.1: I thought some of that terminology had been defined in anoth= er RFC, but unfortunately I couldn't find it >>=20 >> chapter 1.2: The main thing I am missing here is a reference to Attribute= Authorities (AAs). I do realise that introducing AAs complicates the trust m= odel big time, and am totally ok with declaring that out of scope, but I don= 't think you can just pretend they don;t exist, especially since we are seei= ng a movement towards it. >>=20 >> chapter 2.2: I am not crazy about the word "Usage", I think you are looki= ng for a word that expresses something akin to "strength" (without wanting t= o imply ordering) >>=20 >> chapter 2.2, paragraph 2: You write that no ordering should be implied, a= nd I presume that is why you distinguish between vectors that use numbers an= d those that use letters. I find that not very convincing, letters equally i= mply order, so i see no compelling reason to not use either numbers or lette= rs in all cases instead of mixing up >>=20 >> chapter 3.2: have you considered adding also a SAML example, since that i= s widely used as well? >=20 > There was a SAML example in a previous version of the draft, but > none of us could convince ourselves that we could validate its > correctness properly, so we removed it out of expediency. >=20 > -Benjamin (as responsible AD) >=20 >> chapter 8.1: it is unclear to me what meeting the criteria means (and wha= t is good, what is bad, and what the treshold should be) >>=20 >> chapter 9: isn't it true that the "strength" of the assertion of a vector= can only be as good as the cryptographical protection in transit? >>=20 >> Cheers, >>=20 >> Klaas >>=20 From nobody Thu Jun 21 01:59:28 2018 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 B53651274D0 for ; Thu, 21 Jun 2018 01:59:25 -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.81.2 Auto-Submitted: auto-generated Precedence: bulk Reply-to: secdir-secretary@mit.edu Message-ID: <152957156573.31582.13691083389924555296.idtracker@ietfa.amsl.com> Date: Thu, 21 Jun 2018 01:59:25 -0700 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.26 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 08:59:26 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2018-06-21 Reviewer LC end Draft Sandra Murphy 2018-04-24 draft-ietf-mmusic-sdp-simulcast-12 For telechat 2018-07-05 Reviewer LC end Draft John Bradley 2018-06-18 draft-ietf-bfd-multipoint-active-tail-09 Daniel Migault R2018-04-27 draft-ietf-lamps-rfc5751-bis-10 Samuel Weiler 2018-05-21 draft-ietf-bfd-multipoint-18 Last calls: Reviewer LC end Draft John Bradley 2018-04-18 draft-ietf-acme-acme-12 Shawn Emery 2018-06-29 draft-ietf-netmod-schema-mount-10 Daniel Franke 2018-06-28 draft-ietf-netconf-rfc7895bis-06 Daniel Gillmor 2018-06-25 draft-ietf-dnsop-session-signal-10 Daniel Gillmor 2018-03-19 draft-gutmann-scep-10 Tobias Gondrom 2018-06-25 draft-ietf-6man-rfc6434-bis-08 Russ Mundy 2017-09-14 draft-spinosa-urn-lex-13 Tina Tsou 2018-05-21 draft-ietf-v6ops-conditional-ras-05 Taylor Yu 2018-06-19 draft-ietf-regext-rdap-object-tag-03 Dacheng Zhang 2018-06-19 draft-ietf-mpls-spring-entropy-label-11 Early review requests: Reviewer Due Draft Donald Eastlake 2018-06-30 draft-ietf-mptcp-rfc6824bis-11 Daniel Franke 2018-01-31 draft-ietf-intarea-provisioning-domains-00 Ólafur Guðmundsson 2018-01-09 draft-ietf-opsawg-nat-yang-09 Next in the reviewer rotation: Ólafur Guðmundsson Phillip Hallam-Baker Steve Hanna Dan Harkins Russ Housley Christian Huitema Leif Johansson Benjamin Kaduk Charlie Kaufman Scott Kelly From nobody Fri Jun 22 11:11:59 2018 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 318A6130EBB; Fri, 22 Jun 2018 11:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 qbLsMt-utc6B; Fri, 22 Jun 2018 11:11:56 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (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 1E75E130E10; Fri, 22 Jun 2018 11:11:56 -0700 (PDT) X-AuditID: 1209190d-445ff7000000194d-4b-5b2d3bea693e 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-2.mit.edu (Symantec Messaging Gateway) with SMTP id 7B.6B.06477.AEB3D2B5; Fri, 22 Jun 2018 14:11:54 -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 w5MIBrcC028963; Fri, 22 Jun 2018 14:11:53 -0400 Received: from [192.168.1.4] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w5MIBoDQ027147 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 22 Jun 2018 14:11:51 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Justin Richer In-Reply-To: <792fcf56-d568-7da7-3dbe-b858bb8c99d3@wierenga.net> Date: Fri, 22 Jun 2018 14:11:49 -0400 Cc: iesg@ietf.org, secdir@ietf.org, draft-richer-vectors-of-trust.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <792fcf56-d568-7da7-3dbe-b858bb8c99d3@wierenga.net> To: Klaas Wierenga X-Mailer: Apple Mail (2.3445.8.2) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPIsWRmVeSWpSXmKPExsUixCmqrPvKWjfaoOWOlcX2DyvYLGb8mchs MfPiJWaLDwsfsjiweCxZ8pPJY/K774wBTFFcNimpOZllqUX6dglcGVembmMuOKRdse7HGtYG xh9KXYycHBICJhKNk1axdzFycQgJLGaS6H3yjRHC2cgoMfHuMWaQKiGBa0wSnzezgtjMApoS +7uXs3QxcnDwChhLrL9YDhIWFjCXONa4ixHEZhNQlZi+poUJpIRTwEHiUbc3SJgFKHz/w2U2 iCl+Elt7f0LZ2hLLFr4G28QrYCUxcWUXK8RWe4lZX1vARooIqEt833mYHeJmRYlFGxtYJzAK zEJy0CyEg2YhmbqAkXkVo2xKbpVubmJmTnFqsm5xcmJeXmqRrpFebmaJXmpK6SZGcNhK8u5g /HfX6xCjAAejEg+vxledaCHWxLLiytxDjJIcTEqivDcrgEJ8SfkplRmJxRnxRaU5qcWHGCU4 mJVEeN2eAuV4UxIrq1KL8mFS0hwsSuK82YsYo4UE0hNLUrNTUwtSi2CyMhwcShK8/610o4UE i1LTUyvSMnNKENJMHJwgw3mAht8GqeEtLkjMLc5Mh8ifYtTlOHZ5Wg+zEEtefl6qlDjvV5Ai AZCijNI8uDmgdOO+zs7iFaM40FvCvIzA5CPEA0xVcJNeAS1hAlpS3awFsqQkESEl1cDYFXFi VqO2QkrnNZ+VdxTCfn84pSQeEa3q9iDkubzOU8avYsZlN/vXL935oWSr19+IW9dlbuTlMsj9 ErIoLzA4yx+0KXFehem79A2+F3WlM5bW1+mpTtuqcMVWr31SfTfX1FmmgUv3VzSH6Saob1XZ kM9StprlwcVfU81vzdvxXP6AV+/jjIlKLMUZiYZazEXFiQDAHnn3EgMAAA== Archived-At: Subject: Re: [secdir] review of draft-richer-vectors-of-trust-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2018 18:11:58 -0000 Hi Klaas, thanks for the review. I=E2=80=99ve replied inline and have = addressed your comments in the working copy where applicable.=20 > On Jun 19, 2018, at 10:46 AM, Klaas Wierenga = wrote: >=20 > Hi, >=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=20 > 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 > The document defines a method of signaling multiple relevant aspects = of a digital identity transaction instead of a single "level of = assurance" that is supposed to capture all of those aspects into one = single value. > The document is well written and provides clear guidance as to how the = various aspects of an identity transaction can be expressed, without = exploding the solution space. The majority of the comments I have are to = do with assuming too much prior knowledge from the reader and two more = subtsntial comments: >=20 >=20 > chapter 1, page 3: the second paragraph describes the vectors rather = abstract which may prove difficult to the reader, I would recommend to = add here something like "for example identity proofing, credential = strength etc.) instead of in the 4th paragraph The paragraph prior to the one mentioned here has just such an aside, = and repeating it in the next paragraph would be redundant in my opinion.=20= >=20 > chapter 1.1: I thought some of that terminology had been defined in = another RFC, but unfortunately I couldn't find it Most of these are terms of industry but if there=E2=80=99s a specific = external reference that we can include informatively I=E2=80=99d be = happy to add it >=20 > chapter 1.2: The main thing I am missing here is a reference to = Attribute Authorities (AAs). I do realise that introducing AAs = complicates the trust model big time, and am totally ok with declaring = that out of scope, but I don't think you can just pretend they don;t = exist, especially since we are seeing a movement towards it. I really don=E2=80=99t want to go into that depth =E2=80=94 as stated in = the intro, we are trying to avoid the complexities of = all-attribute-all-the-time systems. We distinctly do not want to get = into attribute metadata here, which is where the attribute authority = model really starts to come into play.=20 >=20 > chapter 2.2: I am not crazy about the word "Usage", I think you are = looking for a word that expresses something akin to "strength" (without = wanting to imply ordering) We originally started with =E2=80=9Cstrength=E2=80=9D but that implies = more than we wanted it to in terms of one being =E2=80=9Cbetter=E2=80=9D = than the other. The real bit is =E2=80=9Cwhat does the person need to do = in order to make the credential do its thing with the server they=E2=80=99= re trying to authenticate to=E2=80=9D but that=E2=80=99s a bit long. :) = In the end, we felt this category captured =E2=80=9Chow do you use this = credential=E2=80=9D and went with =E2=80=9Cusage=E2=80=9D in order to = stay neutral. >=20 > chapter 2.2, paragraph 2: You write that no ordering should be = implied, and I presume that is why you distinguish between vectors that = use numbers and those that use letters. I find that not very convincing, = letters equally imply order, so i see no compelling reason to not use = either numbers or letters in all cases instead of mixing up This is a good point, and I=E2=80=99ll try to make the wording here = clearer. You can of course assign letters to things with natural = ordering, but it also often makes sense to not necessarily use the = letters as an ordered list. In the NIST implementation, for example, = =E2=80=9CPi=E2=80=9D means =E2=80=9Cin person=E2=80=9D, =E2=80=9CPr=E2=80=9D= means =E2=80=9Cremote=E2=80=9D, =E2=80=9CPt=E2=80=9D means =E2=80=9Ctrust= ed referee=E2=80=9D, etc.=20 >=20 > chapter 3.2: have you considered adding also a SAML example, since = that is widely used as well? As Ben mentioned, yes, and it=E2=80=99s gone now. I=E2=80=99d be happy = for someone to make a SAML binding to VoT but at this point I think it = would make more sense in another document.=20 >=20 > chapter 8.1: it is unclear to me what meeting the criteria means (and = what is good, what is bad, and what the treshold should be) The intent is in the guidance to the DEs in the second paragraph:=20 - It shouldn=E2=80=99t be a duplicate of something that=E2=80=99s = already out there - It should be clear whether it=E2=80=99s of general applicability or = something very case-specific (and if it can be the former, that=E2=80=99s = preferred) - The definition of the category should be clear enough for a trust = framework to define values for it and for people to use those values If you have suggested text for making that set clearer I=E2=80=99m happy = to incorporate it. >=20 > chapter 9: isn't it true that the "strength" of the assertion of a = vector can only be as good as the cryptographical protection in transit? That=E2=80=99s one limiting factor, but there are others including the = amount of trust that can be put in the IdP making the assertion in the = first place.=20 >=20 > Cheers, >=20 > Klaas >=20 Thank you, =E2=80=94 Justin From nobody Sun Jun 24 20:30:55 2018 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 DBAB1128BAC; Sun, 24 Jun 2018 20:30:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Daniel Migault To: Cc: spasm@ietf.org, ietf@ietf.org, draft-ietf-lamps-rfc5751-bis.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152989744784.21551.17394312874613473171@ietfa.amsl.com> Date: Sun, 24 Jun 2018 20:30:47 -0700 Archived-At: Subject: [secdir] Secdir telechat review of draft-ietf-lamps-rfc5751-bis-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.26 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2018 03:30:49 -0000 Reviewer: Daniel Migault Review result: Ready Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written 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 (tiny) nits Yours, Daniel --- 1.7. Changes for S/MIME v4.0 """ Update the content encryption algorithms (Section 2.7 and Section 2.7.1.2): Add AES-256 GCM, add ChaCha200-Poly1305, remove AES-192 CBC, mark tripleDES as historic. """ In section AES-CBC has its status set to MUST-. "removed" sounds to me as MUST NOT status. In that case, I believe sunsetting or something equivalent might be more appropriated than removed. TripleDES is mentioned in section 2.7.2 I believe it would be appropriated to also mention these algorithms in section 2.7 with a MUST NOT. It might be also appropriated to mention that these algorithm concerns the messages being sent and received while old emails may still be decrypted with there old algorithms. Note that the two latest comments are being discussed in the review thread of version 07. I understand that AES-CBC is being mentioned for compatibility reasons with older S/MIME versions, but that AES-CTR as well as enveloped-data type are expected to be rolled out in the next or next next next version. --- section 2.7.1 """ Before sending a message, the sending agent MUST decide whether it is willing to use weak encryption for the particular data in the message. If the sending agent decides that weak encryption is unacceptable for this data, then the sending agent MUST NOT use a weak algorithm. The decision to use or not use weak encryption overrides any other decision in this section about which encryption algorithm to use. """ I am a bit worried by the text that seems to provide an enable weak encryption check box. Maybe it should be stated that weak encryption SHOULD NOT be used. (same in section 2.7.2) --- 3.1.2 Transfer encoding I see the 7-bit transfer encoding as a legacy mechanisms. While this seems to me out of scope of S/MIME to roll it out and make binary encoding as the base, I am wondering if that is something to consider for next version of MIME for example ? --- 3.5.3.2 Creating a multipart/signed Message I believe that MD5 SHA1, SHA224 are not deprecated to verify the old messages, but should not be used for the new sent/received messages. --- 4 Certificate Processing I am wondering if some recommendations so the security associated to the certification is greater or equal to teh security associated to the message. At least when the comparison is possible. ---section 4.2 It is strange not to have MUST for 2048 <= key size <= 4096. I understand why, but it also means that we may not have interoperability between the Signature Generation and Signature Verification. idem for section 4.4 From nobody Sun Jun 24 22:27:47 2018 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 8F08212F1A5 for ; Sun, 24 Jun 2018 22:27:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 8aidWyKOcNbs for ; Sun, 24 Jun 2018 22:27:44 -0700 (PDT) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAA2F12F1A2 for ; Sun, 24 Jun 2018 22:27:43 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id q11-v6so13379000lfc.7 for ; Sun, 24 Jun 2018 22:27:43 -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=yI1AJBtgyDtzcGa5SVOkEBnx5aGIfL8h9XIKawrZ6UU=; b=GnKsrM2jz81yMnp8PB+uiX2irM2knrLhY17rvNt/UwhEdsvnlrUXaVDfbWiWK86l7Q uySGWJLzHjAoG0oryEB5QivcTN/NcATMcA87kSb68acqYD3128hITRW6UzJ2cri5SHby XBBTmyJO1BG7Jfni34xbRMCUxR6sMbQce5EpY38Big1lWaBi0/okRxNI5+BO/R0LLKeO Xkzavms87DX0ZhWHMrdkROMFzTAc3layNIi9xJE7UTUnaRPQEJGR6ZKcHXUTdej8ypQ8 5mFisNYnV0Q0tjnapOxRGAiekmzeQ6WveYAuXgV9HDWJGDCmWsqsEpCY09/RuGycsljQ 9DtQ== 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=yI1AJBtgyDtzcGa5SVOkEBnx5aGIfL8h9XIKawrZ6UU=; b=hvReTmAhjRROjJc06WQnRqQdnuqFe1G1Kyy7C6iPKrM061zcBxYtug4tX7etAVpCob L9pWeESMnqJ0ehWUCbLa0lrIBrot4e1YFpBOCqiry/TadXinPtfxW5Oj1/FOeWKiubPz nzBNKiwsvNWOKTJ+WpOXnDfWQS1Ip6Xt6aayhAHgUUGCD642bq6LgHGDk7M2cmqiPkcC 6odS3EV3oHck9WF3LRcxE5CeLR77Y/jdlAkVMUxpklKtB2FuBcUcL004TAt0knrZ32k5 e1Z0jzk7y6CKgek4UZ0hlYZYk+fnF3hpBWJyE1trxRI1bRXO/6bj48T4MU6z8nB/KaJW jLNQ== X-Gm-Message-State: APt69E3+V0PwlGczig3u+Z/hV10X55q0aNzggWgk4ui2hYDr711bdo/3 /bfyWmJAztF/V6o23G9ui4SPxpSKFa3uFwaKAgc9X7hI+YM= X-Google-Smtp-Source: ADUXVKIT4OtL2rOhDs60u3vFyqC/QEBK89pj/+M5dHSTWQAXahc1ERPdyimG8Xc2xqnXtCtUmkRGMV/XqSR6gaHCEIc= X-Received: by 2002:a19:1d8c:: with SMTP id d134-v6mr5140934lfd.56.1529904461615; Sun, 24 Jun 2018 22:27:41 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:8751:0:0:0:0:0 with HTTP; Sun, 24 Jun 2018 22:27:40 -0700 (PDT) From: Shawn Emery Date: Sun, 24 Jun 2018 23:27:40 -0600 Message-ID: To: secdir@ietf.org, draft-ietf-netmod-schema-mount.all@tools.ietf.org Content-Type: multipart/alternative; boundary="000000000000f99812056f70a32f" Archived-At: Subject: [secdir] Review of draft-ietf-netmod-schema-mount-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2018 05:27:46 -0000 --000000000000f99812056f70a32f Content-Type: text/plain; charset="UTF-8" Reviewer: Shawn M. Emery Review result: Ready with nits I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This draft specifies a schema for YANG module mount points for yet another specified schema location. The security considerations section does exist and refers to transport security through SSH and HTTPS for NETCONF and RESTCONF, respectively. For authorization, the spec refers to RFC 8341 for controlling NETCONF and RESTCONF user access. Data that would be considered sensitive or subject to attack is briefly described and prescribes read access controls for said data. I agree with the authors' assertions. General comments: None. Editorial comments: OLD: These are the subtrees and data nodes and their sensitivity/vulnerability: NEW: The following should be considered for subtrees/data nodes and their corresponding sensitivity/vulnerability: Shawn. -- --000000000000f99812056f70a32f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Reviewer: Sha= wn M. Emery
Review result: Ready with nits<= /span>

I have reviewed this document as part of= the security directorate's
ong= oing effort to review all=C2=A0IETF=C2=A0documents being processed by the IESG.These comments were written primarily for th= e benefit of the security
area dire= ctors. Document editors and WG chairs should treat these
comments just like any other last call comments.

This draft sp= ecifies a schema for YANG module mount points for yet another
specified=C2=A0schema location.

The security considerations section does exist and refers to tran= sport security
thr= ough SSH and HTTPS for NETCONF and RESTCONF, respectively.=C2=A0 For
<= div style=3D"font-size:12.8px;color:rgb(34,34,34)">authorization, the spec = refers to RFC 8341 for controlling NETCONF and
RESTCONF user access.=C2=A0 Data that would be considered sensitive or subject
to attack=C2=A0is brie= fly described and prescribes read access controls for said data.
I agree with=C2=A0the a= uthors' assertions.

= General comments:
=
None.

Editorial comments:

OLD:
These are the subtrees and data nodes and their sensitivity/vulnerability:=

NEW:
The following should be considered f=
or subtrees/data nodes and their corresponding 
sensitivity/vulnerability:
<=
pre style=3D"color:rgb(34,34,34);background-color:rgb(255,255,255);text-dec=
oration-style:initial;text-decoration-color:initial;margin-top:0px;margin-b=
ottom:0px">
Shawn.
=
--
--000000000000f99812056f70a32f-- From nobody Mon Jun 25 06:38:28 2018 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 874F2130E95 for ; Mon, 25 Jun 2018 06:38:25 -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 Bd49yQknfKHn for ; Mon, 25 Jun 2018 06:38:23 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 9928C130E93 for ; Mon, 25 Jun 2018 06:38:23 -0700 (PDT) Received: by trail.lhotka.name (Postfix, from userid 109) id 2644C1820075; Mon, 25 Jun 2018 15:44:57 +0200 (CEST) Received: from localhost (unknown [195.113.220.121]) by trail.lhotka.name (Postfix) with ESMTPSA id 4A1131820051; Mon, 25 Jun 2018 15:44:54 +0200 (CEST) From: Ladislav Lhotka To: Shawn Emery , secdir@ietf.org, draft-ietf-netmod-schema-mount.all@tools.ietf.org In-Reply-To: References: Date: Mon, 25 Jun 2018 15:38:56 +0200 Message-ID: <87po0fgf4f.fsf@nic.cz> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [secdir] Review of draft-ietf-netmod-schema-mount-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2018 13:38:26 -0000 Hi Shawn, thank you for the review, please see my comment below. Shawn Emery writes: > Reviewer: Shawn M. Emery > Review result: Ready with nits > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the IESG. > These comments were written primarily for the benefit of the security > area directors. Document editors and WG chairs should treat these > comments just like any other last call comments. > > This draft specifies a schema for YANG module mount points for yet another > specified schema location. > > The security considerations section does exist and refers to transport > security > through SSH and HTTPS for NETCONF and RESTCONF, respectively. For > authorization, the spec refers to RFC 8341 for controlling NETCONF and > RESTCONF user access. Data that would be considered sensitive or subject > to attack is briefly described and prescribes read access controls for said > data. > I agree with the authors' assertions. > > General comments: > > None. > > Editorial comments: > > OLD: > > These are the subtrees and data nodes and their sensitivity/vulnerability: > > NEW: > > The following should be considered for subtrees/data nodes and their > corresponding > > sensitivity/vulnerability: > The OLD formulation actually comes from RFC 6087, section 6.1 (Security Considerations Section Template). Your NEW formulation indeed looks better, so we will use it in the present draft, and I will also send it to the netmod mailing list in order to apply this change in draft-ietf-netmod-rfc6087bis. Thanks, Lada > > Shawn. > -- -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Mon Jun 25 07:41:37 2018 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 53AEE130E97 for ; Mon, 25 Jun 2018 07:41:34 -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 l2iYR41hTmcp for ; Mon, 25 Jun 2018 07:41:32 -0700 (PDT) Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69DC6130DEE for ; Mon, 25 Jun 2018 07:41:32 -0700 (PDT) Received: by mail-ua0-x232.google.com with SMTP id g6-v6so1304009uam.2 for ; Mon, 25 Jun 2018 07:41:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=+8bfhdLgCj5B/4GwwGomCD0tuhOcWWkn2ww1ZVwIPaI=; b=bogkC35IXnw/fSCcb1atHzhlP3uCQzly1vOy5rD/AzOxrf8x3yzAyV3qyjpC3U0aSv fqkeLM++pAaMk56uw+DJmif1kLfaqebvZj0GXx2YRiNVr18HGnFUi8nH9cVhDFQ7VylB MbE1AhxcH55dV+WQ9RsafuC54gduXvGmhtgTg3ayVMZhEgXnVbrzH+pqVgCIs3RqsfLP dQDTpOU3UA/wK/VrfUkermJjxa1njRnaga83eAikoNScfozkwT0+3DtcxJXO64nSkdoU EUOjZjMqUOULqpMKG4r8TiuAF21Lm9GIDx2Jqnr9C4dwIJOo4QnfkR7T/FbIt/51Ltzp YJ5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding:content-language; bh=+8bfhdLgCj5B/4GwwGomCD0tuhOcWWkn2ww1ZVwIPaI=; b=HoXImHtdBkPjoBFHSVE8rtp2yhUdAB5VMtp28Ve13LQkK2Okj8jBe25CaqADPmywD4 y8g+yfkdr4zYybWuR9+2h38/TOun4+muU9Um/Acuz8pQ2PSp+wjnS4UlR99Rp4ZV1VHW c8gIsLcYFx5kRpUDqR/0Q3T1DHNDo6/qV55IwgtKs+69rjazDQYj40wFgALqZZKyezmz kUGlrDMOG/+QxAkIGjE8tNIKskx+CyJoicD388btyX07GfNvxmpXFzlW7fVLo3IWuiYJ lZ1cN98f6wsAp1uYNuTXRwwwXUQZQLP9lTIYZ0tmQScm6+uJhwToBL/IPYV30lGoNfb8 3+6w== X-Gm-Message-State: APt69E2j9T1s8QAWs5iHm6eWBquw2AyqgpBkb9Q/FLW7SaWQBHrQtm4I ZcJCguJpvJRPPFuxGmIT0u0= X-Google-Smtp-Source: ADUXVKJg9XjeWk1psyiPoGiu3dh5Du1lhHY0TReL64nhX3IGBr6oJ3DINZG1FtMLskHSK/hazHCVIw== X-Received: by 2002:ab0:663:: with SMTP id f90-v6mr8101689uaf.167.1529937691033; Mon, 25 Jun 2018 07:41:31 -0700 (PDT) Received: from static-219-180.meetings.nanog.org ([2620:0:ce0:101:4567:a5c2:8d:ce5f]) by smtp.gmail.com with ESMTPSA id r128-v6sm1377369vkb.18.2018.06.25.07.41.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Jun 2018 07:41:29 -0700 (PDT) To: Ladislav Lhotka , Shawn Emery , secdir@ietf.org, draft-ietf-netmod-schema-mount.all@tools.ietf.org References: <87po0fgf4f.fsf@nic.cz> From: joel jaeggli Openpgp: preference=signencrypt Autocrypt: addr=joelja@gmail.com; prefer-encrypt=mutual; keydata= xsDiBD832SIRBADVEfzsfIX+fuN2XUPyyEXP4Mq8dqpjmcy+XTIHzZLVKzxmP+17zJYTj9MR dMA5vuZRsRpzFoeDMOJyHVVyaQeSwEApO3FJOej+CNAXpaTLYgobL1XcsQXMTbeNT5x9ZK+R ZQtoC8Vunv6UTygY+kHUHvNijhVtJtCcAW0NE2fiWwCgjKPAldaGNbPg6SKvSTFipsPPqoUE ALKjZApjCG/3Yi4kHgzCQw65mfE9u8O7bZcrvmzzRgmwShyQjrRNgxhwl2q9+e8Uo6kuk56q 0Q4On6y873W6EtBRYLTU5MiIK3mspi5YYpIi/F2XTkcW6Dx/C/ZQQ8WddAyX6QLAXHYMus86 x7tzjGM3HVlvJpWTb4CqcDOcvZakA/9aJhMEffleJx+6xrjZTUYvAQDYUSRWNmc+ehyAuh/B KH0DKqhkLlm0SBdsnKvQHXbdjhu9m9K4E6aR/s117QK60jZo1XNrVKJ1oM3X+2DNmDBl/K33 e/tPSC8byvD77doezHvWvE5n50KIEZezVgMkYWDSPWb0nefdXLY5+rgfms0fSm9lbCBKYWVn Z2xpIDxqb2VsamFAYm9ndXMuY29tPsJjBBMRAgAjAhsDBgsJCAcDAgQVAggDBBYCAwECHgEC F4AFAk3mKPcCGQEACgkQ8AA1q7Z/VrJ6vgCfYITQSd0+WXcYjEoj8+tNys5egPcAn3OUUHVt JElVkSSARJ4XWjRYqKiazsNNBD8320MQEACTNxol/GIZW4CGUnyIlr+13Dqx8aHZfbd96UQE Ys9mZkBxwP2V7D00tOETcY5apr9tr9oHf5p4xA2l2oE8KR4xbF6+0XIpeYzRcl5d0iUaSMwm HcX3J/+XyZegJqTG7zMEK72c1tPVrra9DRNZP+rhKFLJJornDiQJFQVhtQE37WA1kmC6rlyR KHA2RMYS3IugAgJfuy5pZn/5jKCv+ZxIv7tnk7GUQWwfPdr4PokPCBxSXUYch98Rcq3dbCio 8FPmrfI6K2Z9NMa/gXGpF3ynmxDJLY31aPgbUiv9VllZoeMkotbXHW1zrsXte/1MEgFrlkiQ WDJ/dHjlCdlFASfaPvVXxdiUgH7LV3cW+BOY2z4VVwhYM6/kTDoLKWZ3opBeN9KcAHPRFCkA fxwAu8PNgi74lMjcFzu66U8vVM37YqSYpXsi+mlwZDhzCJ8qm9FDwaH2bB1LJ7m41F098B29 SRG3s/XXgTCSt0js/yUp9EXRPQpME99GvwiBNFN9p9e45ZqS85Wll6GqHh+Jyvq0ODWH6XOz uop3UUqw6I2Q8rG7e/uxKWcFnt1q48uhdTHA0TfnYC5HpHf/tAuR+ui6s16xrENgFgeeu4b/ q/jA4N1ZuJU7IbnO5f28YTlJOef/HywY3OXBsrdhEXKLIc5xRj6NC4WphyQ9MQrx8cS1bwAD BQ//WNM1WUlr6tIn8/7SIqqHRg3UmzVNu4u+r9rK9LJkYRLA4xKb/TrqDhP9oyO7Oz2S5CsF wjiPc1vzGzfRgIOArPJrejM4BzHQ03tl1qb/5YNDaB1QzfPv6dT9OkhMMuth0tcmH5sjfbiF Nc41aKU5w4FFkTv3XmrXciz4+PWbAYGB7pYbhGmsx//9C2bS56Bu1QkFeSCzN5AvWAmJfyPU yMXFKDe21DlImMdkrn/K838Lm8o0CLOKbJBX8K0pE4rGEf20FLfmHx/bLZRcWhTm8cB/vHNd 8GhwFlvHylj6+5QtR0Tc0hBcOG8SZktjE/hEiYi+dAZCrwT9i8Hjulnx/vu+Knt40+5CB2hk L1VQwdGWLYO4FGqWwwv0Y8XhWOudLYCZQWrgOsIzYezahC5b9iobFx8dgAElXNPTxI/dymrI d/6foyBrGnzzOnV/gfWfQp7N1rbrh0mQXRhwwwQIjlmbUyz8fTlaTcAo8ocXTVUb6WY7U5nr ufzKsFceR/olFnvZKKhbGVG6VvqNLS1r5lcRR1J7GVZM+Sb2ZNKgnwiUf8yxKfWg84NUPt/b etviJ73LVPdjV1PNZgcxfPRO3XL6Y9FaBP9oB4f58ujuhzOLUt+6I0KuzY8H5RBBaIrJJptl DEOnxFn1J7Q0uxQ2BzqfZdKTwJS4OCjm+OsLd8HCRgQYEQIABgUCPzfbQwAKCRDwADWrtn9W soUzAJ4zatxnKYcGdyoFojBc1Y2jqaHZsQCbB25DmeFRx14xxuxdAXb0wsKf35w= Message-ID: <7755e577-7327-3b2f-0406-7b0c392701a9@gmail.com> Date: Mon, 25 Jun 2018 08:41:01 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <87po0fgf4f.fsf@nic.cz> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [secdir] Review of draft-ietf-netmod-schema-mount-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2018 14:41:35 -0000 On 6/25/18 7:38 AM, Ladislav Lhotka wrote: > >> Editorial comments: >> >> OLD: >> >> These are the subtrees and data nodes and their sensitivity/vulnerability: >> >> NEW: >> >> The following should be considered for subtrees/data nodes and their >> corresponding >> >> sensitivity/vulnerability: >> > The OLD formulation actually comes from RFC 6087, section 6.1 (Security > Considerations Section Template). Your NEW formulation indeed looks > better, so we will use it in the present draft, and I will also send it > to the netmod mailing list in order to apply this change in > draft-ietf-netmod-rfc6087bis. > > Thanks, Lada thank you > >> Shawn. >> -- From nobody Wed Jun 27 07:44:43 2018 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B222130DE1; Wed, 27 Jun 2018 07:26:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1530109575; bh=jhH1gQuBUMlQ/9KPJmQiaCbB3uIbwfVidIR6RFduoJ4=; h=From:Date:To:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=Mo02WXsr7vzj36BnNtHqTqxf4mdhlP8tftsPEvAmTZgzRKTHkY8vkkAVonQEY3rq2 m/3HdDdT/96sCDNKhg2EoyryD2MGrmduH1qNVPSLiUBsD1by3kZ/B/MocY7ilHayIe BPi2Nw7mGTiYm2VAMfSQYODScOZyWq0SBypSrVHs= X-Mailbox-Line: From new-work-bounces@ietf.org Wed Jun 27 07:26:14 2018 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7014B130DD5; Wed, 27 Jun 2018 07:26:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1530109574; bh=jhH1gQuBUMlQ/9KPJmQiaCbB3uIbwfVidIR6RFduoJ4=; h=From:Date:To:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=JuRVidK/i5hvHAXDlz0omnrGqSlaB7l/MZ2zdFa+O1igt+FtJAN+2ms800QfFs7s9 FnaSEbUTj5Btm2ev8qnp4im+yDiT1W1YbSpC5kid0OYTlmmiKU7LpH0RZhYquesPog PRQtwv+OdCsoXyIo3pPHXl8ILPf3m3JVgWRTvClI= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA9E0130DD5 for ; Wed, 27 Jun 2018 07:26:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 0OnPcyA2aS7J for ; Wed, 27 Jun 2018 07:26:10 -0700 (PDT) Received: from raoul.w3.org (raoul.w3.org [128.30.52.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA27A1294D7 for ; Wed, 27 Jun 2018 07:26:09 -0700 (PDT) Received: from boc06-4-78-216-15-101.fbx.proxad.net ([78.216.15.101] helo=[192.168.0.12]) by raoul.w3.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1fYBOZ-0002QJ-ML; Wed, 27 Jun 2018 14:26:07 +0000 From: Coralie Mercier Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Wed, 27 Jun 2018 16:25:55 +0200 Message-Id: To: new-work@ietf.org X-Mailer: Apple Mail (2.3445.8.2) Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.26 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Wed, 27 Jun 2018 07:44:41 -0700 Subject: [secdir] [new-work] Proposed W3C Charters: Accessible Platform Architectures (APA) Working Group; Accessible Rich Internet Applications (ARIA) Working Group (until 2018-07-27) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 14:26:21 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to review draft charters for the following groups: * Accessible Platform Architectures Working Group (APA WG): https://www.w3.org/2018/03/draft-apa-charter * Accessible Rich Internet Working Group (ARIA WG): https://www.w3.org/2018/03/draft-aria-charter As part of ensuring that the community is aware of proposed work at W3C, these draft charters are public during the Advisory Committee review period. W3C invites public comments through 2018-07-27 on the proposed charter. Please send comments to public-new-work@w3.org, which has a public archive: http://lists.w3.org/Archives/Public/public-new-work/ Other than comments sent in formal responses by W3C Advisory Committee Representatives, W3C cannot guarantee a response to comments. If you work for a W3C Member [1], please coordinate your comments with your Advisory Committee Representative. For example, you may wish to make public comments via this list and have your Advisory Committee Representative refer to it from his or her formal review comments. If you should have any questions or need further information, please contact Michael Cooper , Staff Contact. Thank you, Coralie Mercier, Head of W3C Marketing & Communications [1] http://www.w3.org/Consortium/Member/List -- Coralie Mercier - W3C Marketing & Communications - https://www.w3.org mailto:coralie@w3.org +337 810 795 22 https://www.w3.org/People/CMercier/ _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Wed Jun 27 15:55:34 2018 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 022DD130DF1 for ; Wed, 27 Jun 2018 15:55:32 -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.81.3 Auto-Submitted: auto-generated Precedence: bulk Reply-to: secdir-secretary@mit.edu Message-ID: <153014013200.15346.4961009417431069503.idtracker@ietfa.amsl.com> Date: Wed, 27 Jun 2018 15:55:32 -0700 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.26 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 22:55:32 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2018-07-05 Reviewer LC end Draft John Bradley 2018-06-18 draft-ietf-bfd-multipoint-active-tail-09 Tobias Gondrom 2018-06-25 draft-ietf-6man-rfc6434-bis-08 Samuel Weiler 2018-05-21 draft-ietf-bfd-multipoint-18 Dacheng Zhang 2018-06-19 draft-ietf-mpls-spring-entropy-label-11 Last calls: Reviewer LC end Draft John Bradley 2018-04-18 draft-ietf-acme-acme-12 Daniel Franke 2018-06-28 draft-ietf-netconf-rfc7895bis-06 Daniel Gillmor 2018-06-25 draft-ietf-dnsop-session-signal-10 Daniel Gillmor 2018-03-19 draft-gutmann-scep-10 Ólafur Guðmundsson 2018-07-10 draft-ietf-insipid-logme-marking-11 Phillip Hallam-Baker 2018-07-10 draft-ietf-codec-ambisonics-07 Steve Hanna 2018-07-09 draft-ietf-netmod-acl-model-19 Dan Harkins 2018-07-09 draft-ietf-netconf-nmda-restconf-04 Christian Huitema 2018-07-09 draft-ietf-netconf-nmda-netconf-06 Russ Mundy 2017-09-14 draft-spinosa-urn-lex-13 Sandra Murphy 2018-04-24 draft-ietf-mmusic-sdp-simulcast-13 Tina Tsou 2018-05-21 draft-ietf-v6ops-conditional-ras-05 Taylor Yu 2018-06-19 draft-ietf-regext-rdap-object-tag-03 Early review requests: Reviewer Due Draft Donald Eastlake 2018-06-30 draft-ietf-mptcp-rfc6824bis-11 Daniel Franke 2018-01-31 draft-ietf-intarea-provisioning-domains-00 Ólafur Guðmundsson 2018-01-09 draft-ietf-opsawg-nat-yang-09 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 Fri Jun 29 12:07:10 2018 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 06F0D130E26; Fri, 29 Jun 2018 12:06:54 -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, 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 pFN4nq50404k; Fri, 29 Jun 2018 12:06:52 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F32A2130E1C; Fri, 29 Jun 2018 12:06:48 -0700 (PDT) Received: from Jude (104.129.192.187) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 29 Jun 2018 12:03:38 -0700 From: Jim Schaad To: 'Daniel Migault' , CC: , , References: <152989744784.21551.17394312874613473171@ietfa.amsl.com> In-Reply-To: <152989744784.21551.17394312874613473171@ietfa.amsl.com> Date: Fri, 29 Jun 2018 12:06:38 -0700 Message-ID: <028301d40fdc$5091c820$f1b55860$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQEAqyn4NPNcgmg/BqQlPkidEifLJ6Yd+MlQ X-Originating-IP: [104.129.192.187] Archived-At: Subject: Re: [secdir] Secdir telechat review of draft-ietf-lamps-rfc5751-bis-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 19:06:54 -0000 > -----Original Message----- > From: Daniel Migault > Sent: Sunday, June 24, 2018 8:31 PM > To: secdir@ietf.org > Cc: spasm@ietf.org; ietf@ietf.org; = draft-ietf-lamps-rfc5751-bis.all@ietf.org > Subject: Secdir telechat review of draft-ietf-lamps-rfc5751-bis-10 >=20 > Reviewer: Daniel Migault > Review result: Ready >=20 > Hi, >=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 (tiny) nits >=20 > Yours, > Daniel >=20 > --- 1.7. Changes for S/MIME v4.0 >=20 > """ > Update the content encryption algorithms (Section 2.7 and Section = 2.7.1.2): > Add > AES-256 GCM, add ChaCha200-Poly1305, remove AES-192 CBC, mark > tripleDES as historic. """ >=20 > In section AES-CBC has its status set to MUST-. "removed" sounds to me = as > MUST NOT status. In that case, I believe sunsetting or something = equivalent > might be more appropriated than removed. This is not to be a MUST NOT, I have changed to the text to 'remove mention of AES-192 CBC' >=20 > TripleDES is mentioned in section 2.7.2 I believe it would be = appropriated to > also mention these algorithms in section 2.7 with a MUST NOT. There is not a MUST NOT on TripleDES at this time. There may still be = cases where TripleDES may need to be used to send messages to older = implementations of S/MIME. All we are doing is saying - make sure that = the user knows that this may not be a good idea. There are no known = attacks against TripleDES that I am aware of. >=20 > It might be also appropriated to mention that these algorithm concerns = the > messages being sent and received while old emails may still be = decrypted > with there old algorithms. This is the entire point of the appendix B. =20 >=20 > Note that the two latest comments are being discussed in the review = thread > of version 07. >=20 > I understand that AES-CBC is being mentioned for compatibility reasons = with > older S/MIME versions, but that AES-CTR as well as enveloped-data type = are > expected to be rolled out in the next or next next next version. There is zero chance that AES-CTR is going to be rolled out at any time = in the future. The trend is to go to AEAD algorithms only. >=20 > --- section 2.7.1 >=20 > """ > Before sending a message, the sending agent MUST decide whether it is > willing to use weak encryption for the particular data in the message. = If the > sending agent decides that weak encryption is unacceptable for this = data, > then the sending agent MUST NOT use a weak algorithm. The decision to = use > or not use weak encryption overrides any other decision in this = section about > which encryption algorithm to use. """ >=20 > I am a bit worried by the text that seems to provide an enable weak > encryption check box. Maybe it should be stated that weak encryption > SHOULD NOT be used. If you do not use a weak encryption algorithm you might not be able to = send the message at all. Bad encryption is considered to be better than = no encryption. >=20 > (same in section 2.7.2) >=20 > --- 3.1.2 Transfer encoding >=20 > I see the 7-bit transfer encoding as a legacy mechanisms. While this = seems to > me out of scope of S/MIME to roll it out and make binary encoding as = the > base, I am wondering if that is something to consider for next version = of > MIME for example ? It would be great if the world had all 8-bit clean for sending and = receiving messages. Even if MIME were updated to it is not clear that = S/MIME should ever change it's recommendation as hitting a single 7-bit = only gateway completely destroys the message. I don't see any changes in this document. >=20 > --- 3.5.3.2 Creating a multipart/signed Message >=20 > I believe that MD5 SHA1, SHA224 are not deprecated to verify the old > messages, but should not be used for the new sent/received messages. That is true, however this does not change the set of values that are = placed in the micalg parameter. =20 >=20 > --- 4 Certificate Processing >=20 > I am wondering if some recommendations so the security associated to = the > certification is greater or equal to teh security associated to the = message. At > least when the comparison is possible. This is an interesting idea, however I am unsure how to even go about = making this statement. Trying to set levels of security between = different algorithms is fraught with danger. Additionally, what would = you do with the message if there was a difference in the comparison = should it be marked as insecure? =20 >=20 > ---section 4.2 >=20 > It is strange not to have MUST for 2048 <=3D key size <=3D 4096. I = understand > why, but it also means that we may not have interoperability between = the > Signature Generation and Signature Verification. I understand what you are saying. However an implementation that only = does RSA keys of 2048 for signature generation would not be compliant = under a MUST and is for a SHOULD. Also an implementation that only = creates EdDSA signatures but cannot create an RSA signature is fine w/ = SHOULD but not w/ MUST. >=20 > idem for section 4.4 From nobody Fri Jun 29 15:12:38 2018 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 5B85A130F37; Fri, 29 Jun 2018 15:12:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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_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 pyHY5X9BhUwu; Fri, 29 Jun 2018 15:12:14 -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 F3D08130EA8; Fri, 29 Jun 2018 15:12:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=infineon.com; i=@infineon.com; q=dns/txt; s=IFXMAIL; t=1530310334; x=1561846334; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=1xKVbkauuCuQd42w7gDmv3hXN4e2sEOg5klNGDxeAfo=; b=kVn1j6HaRryggVXcNL9nVh/3p3Zy/UHo70aRdD8t3XapwXAkaZnpuXxJ 1ZyWsqYSlyfURUmSCmqIdiO6o8nPfLLH8n5pBTIVMDXOf1r7m24/wrMAc gHOmpD5FV7i8nELHSWsA9ZennTPR2q1oCm7o3wpj7FKsxdb3Nwea0/i8V s=; X-SBRS: None X-IronPort-AV: E=McAfee;i="5900,7806,8939"; a="83749320" X-IronPort-AV: E=Sophos;i="5.51,287,1526335200"; d="scan'208";a="83749320" Received: from unknown (HELO mucxv001.muc.infineon.com) ([172.23.11.16]) by smtp11.infineon.com with ESMTP/TLS/AES256-GCM-SHA384; 30 Jun 2018 00:12:09 +0200 Received: from MUCSE706.infineon.com (MUCSE706.infineon.com [172.23.7.80]) by mucxv001.muc.infineon.com (Postfix) with ESMTPS; Sat, 30 Jun 2018 00:12:09 +0200 (CEST) Received: from MUCSE707.infineon.com (172.23.7.81) 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.1466.3; Sat, 30 Jun 2018 00:12:08 +0200 Received: from MUCSE707.infineon.com ([172.23.106.27]) by MUCSE707.infineon.com ([172.23.106.27]) with mapi id 15.01.1466.008; Sat, 30 Jun 2018 00:12:08 +0200 From: To: , , Thread-Topic: Review of draft-ietf-netmod-acl-model-19.txt Thread-Index: AdQP9Y2jSrah9SdYSKyvzsnOr44HiQ== Date: Fri, 29 Jun 2018 22:12:08 +0000 Message-ID: <5f33d7efee044a08b51d206b605b945c@infineon.com> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [secdir] Review of draft-ietf-netmod-acl-model-19.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 22:12:30 -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 issues. This document defines a YANG data model for ACL. When the term "ACL" is used in this document it means the sort of ACL that you might see in firewall rules (e.g., "drop IPv4 traffic with destination port 21"). *Overall Clarity and Quality* The document is fairly clear and well written. However, there is a confusing typo that is listed in the Minor Errors section of this review. *Security Analysis* The Security Considerations section is brief but decent. However, the last two sentences are unclear and maybe wrong: Unauthorized write access to this list can allow intruders to access and control the system. Unauthorized read access to this list can allow intruders to spoof packets with authorized addresses thereby compromising the system. Which "system" is referred to here? Whatever the answer to that question, I believe that the main impact of unauthorized write access to the ACL is that the attacker can modify the ACL to permit traffic that should not be permitted or deny traffic that should be permitted. The former may result in denial of service or compromise of systems on the network. The latter may result in denial of service. The main impact of unauthorized read access to the ACL is that the attacker can determine what ACL rules are in effect and may be able to use this information to better craft an attack. *Minor Errors* Section 3 refers to "action criteria". Every other part of the specification refers only to "action" or "actions". My review of the specification indicates that this text in section 3 should say "actions" not "action criteria".