From nobody Thu Feb 2 03:34:43 2017 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BC332129624 for ; Thu, 2 Feb 2017 03:34:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Tero Kivinen" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148603528272.28243.14781838933633899201.idtracker@ietfa.amsl.com> Date: Thu, 02 Feb 2017 03:34:42 -0800 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 11:34:43 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2017-02-02 Reviewer LC end Draft Steve Hanna 2017-01-12 draft-ietf-softwire-dslite-multicast-17 Leif Johansson 2017-01-17 draft-ietf-teas-p2mp-loose-path-reopt-08 Sandra Murphy 2017-01-26 draft-ietf-mmusic-4572-update-12 Liang Xia 2017-01-17 draft-ietf-teas-gmpls-resource-sharing-proc-08 For telechat 2017-02-16 Reviewer LC end Draft Stephen Kent R2017-02-13 draft-ietf-oauth-jwsreq-11 Tero Kivinen R2016-12-20 draft-ietf-6tisch-minimal-19 Matthew Miller 2017-01-30 draft-ietf-sidr-rpki-rtr-rfc6810-bis-08 Sandra Murphy 2016-12-20 draft-ietf-6tisch-minimal-19 Hilarie Orman 2017-02-09 draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-05 Joseph Salowey 2017-02-07 draft-ietf-dmm-4283mnids-04 For telechat 2017-03-02 Reviewer LC end Draft Benjamin Kaduk R2017-01-17 draft-ietf-mpls-residence-time-13 Melinda Shore 2017-02-27 draft-sgtatham-secsh-iutf8-05 Klaas Wierenga 2017-02-10 draft-ietf-dmm-hnprenum-05 Last calls: Reviewer LC end Draft Alan DeKok 2017-02-15 draft-bradner-rfc3979bis-11 Lt. Mundy 2017-01-26 draft-ietf-mpls-tp-linear-protection-mib-11 Yoav Nir 2017-02-21 draft-hardie-privsec-metadata-insertion-05 Vincent Roca 2017-02-07 draft-ietf-nfsv4-rfc5666bis-09 Rich Salz 2017-03-01 draft-ietf-6man-rfc4291bis-07 Yaron Sheffer 2017-03-01 draft-ietf-6man-rfc2460bis-08 Rifaat Shekh-Yusef 2017-03-01 draft-ietf-6man-rfc1981bis-04 Robert Sparks 2017-02-15 draft-ietf-grow-mrt-add-paths-03 Sean Turner 2017-02-15 draft-ietf-bmwg-virtual-net-04 David Waltermire 2017-02-13 draft-ietf-pals-mpls-tp-dual-homing-protection-05 Brian Weis 2017-02-13 draft-ietf-pals-mpls-tp-dual-homing-coordination-05 Paul Wouters 2017-02-09 draft-ietf-mmusic-sctp-sdp-22 Early review requests: Reviewer Due Draft Daniel Gillmor 2016-02-01 draft-ietf-rtcweb-security-08 Brian Weis 2016-02-01 draft-ietf-cdni-uri-signing-10 Next in the reviewer rotation: Tom Yu Dacheng Zhang Derek Atkins John Bradley Shaun Cooley Alan DeKok Donald Eastlake Shawn Emery Daniel Franke Daniel Gillmor From nobody Thu Feb 2 09:41:56 2017 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C5DAC1298AC; Thu, 2 Feb 2017 09:41:55 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Sean Turner To: X-Test-IDTracker: no X-IETF-IDTracker: 6.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148605731580.13933.16924639077387696348.idtracker@ietfa.amsl.com> Date: Thu, 02 Feb 2017 09:41:55 -0800 Archived-At: Cc: draft-ietf-bmwg-virtual-net.all@ietf.org, ietf@ietf.org, bmwg@ietf.org Subject: [secdir] Review of draft-ietf-bmwg-virtual-net-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 17:41:55 -0000 Reviewer: Sean Turner Review result: Ready This draft investigates additional benchmarking considerations for Virtualized Network Functions (VNF). Comments: lgtm From nobody Fri Feb 3 06:29:21 2017 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E64AD129648; Fri, 3 Feb 2017 06:29:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 R02VDXaWeDOD; Fri, 3 Feb 2017 06:29:13 -0800 (PST) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B586B129417; Fri, 3 Feb 2017 06:29:13 -0800 (PST) Received: by mail-ua0-x235.google.com with SMTP id 35so14781015uak.1; Fri, 03 Feb 2017 06:29:13 -0800 (PST) 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=lHFc+fedJj2iZoyORcL6OQUnFj1K0ifYeVPOhDwgdE4=; b=W51bYnVbaLUUtzzkbAnNXLGKyvBw5Wn3aQyP89C8L7vipMnmFQYZo0vw35ECeFfaZn hXTRzoH6eKxrqdS+vhbKliUGU8ZCuDv4OpEpwwLL35GX4C6rFD/EUmR0kmX+w3Dsvusd W75ebRQTFnjz6GvO2d2wunZdSf25etv4o61h/g1LsTTFba50BwFMmi6lPaEYEVj7HfhD iUbMrvRFhLmqw/6ABj/r60sIbSrlLKi2CO4UOKdNX4Kf5XJ1OXzW287tGOI3RoQFesoO +jazr6f9l0ErcoYYVunadtRkWfJA2F7BkHuILKxTRrscnJNzHOwncV+uw8NUR7Er0/CT AAnw== 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=lHFc+fedJj2iZoyORcL6OQUnFj1K0ifYeVPOhDwgdE4=; b=IFX8JU/y/ir8rio9CqRtkw7T04PHTNzOirEmmCp8QUFBGXk2Jjen/GC/LY+uBB5aO+ Oif8HqVTkk+Uqfrhzo0csADwObu6D1TSbc3J2ZZp3fr6zq6Ts/2KDrw80HN57Fa549zc +4q7W/euk58YoT8vltJQPnE8aNSnfx23odrwcYYkETr1soiMyBKipZIH+O6V+VJF5ma8 5EPvKCIoy9VNCJ4S30eoXIe6x10GKqFhO5v62zPJd4hnjgZdCaMWgspPnOs7FErzg2yM tCDAOBHdLjJZ576hpqNmfRZkOov45pDugFPhp8If6QyakaCwtqZAFKVL6bHmU3xn1ky3 +g9w== X-Gm-Message-State: AIkVDXLIRi88gsERhCiNM9b4XvU0h08BeyWvIWTTGKeudVU4kj+wVthJmLfNGtzHd1BfwvR/lIsVprDTf6Sy8Q== X-Received: by 10.159.36.39 with SMTP id 36mr7009885uaq.146.1486132152631; Fri, 03 Feb 2017 06:29:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.52.146 with HTTP; Fri, 3 Feb 2017 06:29:12 -0800 (PST) From: Rifaat Shekh-Yusef Date: Fri, 3 Feb 2017 09:29:12 -0500 Message-ID: To: draft-ietf-6man-rfc1981bis@ietf.org, secdir@ietf.org, The IESG Content-Type: multipart/alternative; boundary=001a113527680c25380547a11b4e Archived-At: Subject: [secdir] SecDir review of draft-ietf-6man-rfc1981bis-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 14:29:15 -0000 --001a113527680c25380547a11b4e Content-Type: text/plain; charset=UTF-8 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: *Ready*. The Security Considerations section describes the possible attacks and their implications, and reasonable ways to mitigate their impact. Regards, Rifaat --001a113527680c25380547a11b4e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have reviewed this document as part of the security= directorate's=C2=A0
ongoing effort to review all IETF docume= nts being processed by the=C2=A0
IESG.=C2=A0 These comments were = written primarily for the benefit of the=C2=A0
security area dire= ctors.=C2=A0 Document editors and WG chairs should treat=C2=A0
th= ese comments just like any other last call comments.

Summary: Ready.

The Security Considerati= ons section describes the possible attacks and their implications, and reas= onable ways to mitigate their impact.

Regards,
=C2=A0Rifaat

--001a113527680c25380547a11b4e-- From nobody Sun Feb 5 04:44:34 2017 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBE3212956A; Sun, 5 Feb 2017 04:44:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kr8nRlNsO-FE; Sun, 5 Feb 2017 04:44:28 -0800 (PST) Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67684129563; Sun, 5 Feb 2017 04:44:28 -0800 (PST) Received: from titi.ripe.net ([193.0.23.11]) by mahimahi.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1caMB7-000AKz-EC; Sun, 05 Feb 2017 13:44:26 +0100 Received: from dog.ripe.net ([193.0.1.217] helo=[IPv6:::1]) by titi.ripe.net with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84_2) (envelope-from ) id 1caMB6-0004sj-3W; Sun, 05 Feb 2017 13:44:24 +0100 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_859A04C5-E554-4AB3-BDAE-FF178A6BBC7C"; protocol="application/pgp-signature"; micalg=pgp-sha256 From: Oleg Muravskiy In-Reply-To: <8bee5b64-8b54-99f4-3e86-f6450f664fd6@mandelberg.org> Date: Sun, 5 Feb 2017 13:44:22 +0100 Message-Id: References: <8bee5b64-8b54-99f4-3e86-f6450f664fd6@mandelberg.org> To: David Mandelberg X-Mailer: Apple Mail (2.3124) X-ACL-Warn: Delaying message X-RIPE-Spam-Level: ------ X-RIPE-Spam-Report: Spam Total Points: -6.7 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4923] X-RIPE-Signature: c408758d4ce2e8eb06762a65a3365b74c156e9b0dc169faf27788eb1e6a5aa80 Archived-At: Cc: draft-ietf-sidr-delta-protocol.all@ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-sidr-delta-protocol-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2017 12:44:29 -0000 --Apple-Mail=_859A04C5-E554-4AB3-BDAE-FF178A6BBC7C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi David, Thanks for your review and comments, I'll try to address them below in = the text: > On 28 Jan 2017, at 22:29, David Mandelberg = 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 > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. >=20 > This document provides a new way for RPKI Relying Parties to download > RPKI objects. As mentioned in the Security Considerations, those = objects > are already cryptographically signed. The RRDP protocol provides some > additional security to the download process, with no changes to the > security properties of the RPKI objects themselves. >=20 > I think this document is Ready with nits. >=20 >=20 > 3.3.2: It seems strange to me that you use MUST when talking about the > timing/performance of the repository server. Is this relevant to > security? Or is there another reason for a MUST? I do not think this time interval (less than 1 minute to publish updates = for any CA) has a direct impact on the security. However, it'a also not = about the performance of the publication server, but to guarantee the = expectations on the staleness of the data in the repository, both from = CA's and RP's point of view. So I'd like to keep it a "MUST". > 3.4.2: I think "update its last processed serial number to the serial > number of this snapshot file" should say "delta file" instead. Correct. Fixed in -06. > 3.4.5: I'd recommend changing "in case of network issues" to "in case = of > network issues, or temporary failures of the repository server(s) or > caching infrastructure". I agree that "network issues" is only one possible cause. I'm not sure = we could/should mention all of them in that paragraph, so I'll leave it = with "Relying Parties may wish to employ re-try strategies while = fetching RRDP files". > 3.5.1.2: I think the last paragraph might make it harder for the = server > to recover from a temporary overload, since it can't tell clients to > wait longer than 1 minute before re-fetching. It seems to me that > letting the clients get a few minutes out of date until the server > operator can provision more capacity is better than accidentally = DoSing > the server. I think what we want to say here is that [for security reasons] RPs = should not trust the HTTP caching headers for notification files, if = they specify caching for longer than 1 minute, because those headers = could be overwritten by the (CDN) distribution servers which might be = out of control of the publication server operator. One minute should be enough for a CDN to overcome DDoS anyway. = Additionally, the If-Modified-Since: request header is mandatory, which = also lowers the load on the server. And specifying 1 minute cache = expiration on notification file does not mean an RP *will* come back for = a new file after a minute. So do you want a longer text in that paragraph? > 3.5.4: Why is serial not an xsd:positiveInteger? Section 3.3.1 says = that > serials start at 1. Correct. Fixed in -06. Cheers, Oleg --Apple-Mail=_859A04C5-E554-4AB3-BDAE-FF178A6BBC7C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJYlx4nAAoJEKt45HsRg/7AMf4QAKdTJ4JVNUd6uqaepS2XIZUs O2fJc7eOKkWPxUp8hWoG/+2boWcCh3OkMwFa/FN6YapQsSDHOW5JIqoYUcbGZFtR s7DCb8Ot4yYPSuC2NnoiFgBYjcEzs9XUd3ohF/cVcbAQD0W9StQZN3cG87LTmcfT ev7eTs3X+TC5G5eZHIcbkSHOCfpAffphFQ5ZHrTy5WHxLvr61F+QOtkZry7oVVn+ Yy5Xle6e0UBSx2h/LXgXOD3KJf5UvZQU3YiUlSQ8UaHXjhIXif+0tZ01ejsZrF9b QbJMlkC2ZAd/5pwVr9CZnoqp8Tyito7cZlSEl1+dQURt2nzRYjCN2WAER6aavxZc VreMMs/uoL7fvrElfwJTP6tU22U5p0oNipEizx3PaOJt63IaKdwSq+gy7/yVbjsk rt50iX+JBmkvEyr28RWBa/kS7tD6MiKES3/a3BgFOnfB1osU7k5+/BsFpEbPUX6h fNsYnpP84MjzHFgzbDUhdhrBUkH3eTihujmsPiRVyfOmmtkLGkvC6kvQbG2stBXT cJQA4qtsnzj7BYxxtm6vTeUelmJdJoTDv4qWKr6jutEY4hDjZnJK3TP1WsC5BDgd bWBI1QLbFpaoRDClvFzR4Jd/M2AEsX5GyGDjUjMe2nuyjVHovbzNtu4UPDdpGYyh 0EgX1gLj14rlvY4IU9wE =0Wr9 -----END PGP SIGNATURE----- --Apple-Mail=_859A04C5-E554-4AB3-BDAE-FF178A6BBC7C-- From nobody Sun Feb 5 09:23:30 2017 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7324B129483 for ; Sun, 5 Feb 2017 09:23:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tMh-1tJZ0Xgv for ; Sun, 5 Feb 2017 09:23:27 -0800 (PST) Received: from nm12-vm7.access.bullet.mail.bf1.yahoo.com (nm12-vm7.access.bullet.mail.bf1.yahoo.com [216.109.114.246]) (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 57C7C129481 for ; Sun, 5 Feb 2017 09:23:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1486315405; bh=dxHp1FNNfpnq7dobaTQOtb6Uaxgc28VkTZsexTpKpew=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From:Subject; b=HOIk2QZFfCmMC9LGhvTa9z5hdojURsq4brT31Lsttkx7tvWf7eisSasWwBY1b1rJeY39eL1UqYiDzw5aKfbAJIUlLxVIXDBiTBQdaSybEAaajP+I8ArCMXr/zqoPPo5jUl/n99f5GgdN1d6PE9x0hk6V+GbfBi/g7e6sl2TY0JTLTLEWfsAD+5EKrTRm6OROq8qpt71Qm6PfRYqK26bWkIYDAfqbSvWHBOAP/WgLJNeWUWOFoxD2i5yLE1yYezR6b2lMyGcLiDMOpKmZhhg7lQOOh29+bz2eSOnv8dSzrmFGQI/SUqQlIbiaI0Qh2pE1q9iVHTRsrV6oRvOTm4Rvng== Received: from [66.196.81.161] by nm12.access.bullet.mail.bf1.yahoo.com with NNFMP; 05 Feb 2017 17:23:25 -0000 Received: from [98.138.226.243] by tm7.access.bullet.mail.bf1.yahoo.com with NNFMP; 05 Feb 2017 17:23:25 -0000 Received: from [127.0.0.1] by smtp114.sbc.mail.ne1.yahoo.com with NNFMP; 05 Feb 2017 17:23:25 -0000 X-Yahoo-Newman-Id: 787558.38807.bm@smtp114.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: K9Im_RgVM1lNqTIVxaiNNguDttJ8oHUxUWRVV1pwdWmQ1fq GS20ECZeN7pUXZp6K.MoIftQ4.KepTYPELpli5jDDX9fKCRSwFb_x.T4H4z8 v50hAPl8wzDjbIEvvtUyhoXVaTbzU1N20UcUbjkXyI0RQZ3GHpYP3Mb31rtR fBeL.Hlelii4AKJbTUBnLL1m_oOFo_.45LKU.YRvEyckZ8hGQuunhc9wVdhp T4a7klHyHAOJBeN_vG3i20azCor2YqxUsuVLGZJwNOYcxeXWH.2FSQam_LpW eNTifJnKNQQga11NNqVenY0oPXzykRTeIw7X_wuDTinTYU407UjQ.hT1Uyq6 AU6vSfnKaozRobtIalFva_47qeoFQL0S2IjsbzDK6VucDX7giYd2GM_Fd0mN zau.aMFdG3.0y_pi.vDP3pQcC6cufQkwOOb8WmMbzkVLvb6MMU8HKHPbe5XI zMCJEN4mJJlkJLiuMkWgzN.qc_A8fH2QnzPwj_5.wHHIKJU1PgLp9oazlUdY TGDPSbPwHyJsttGoebKGOov_jwZYMHgkNjg-- X-Yahoo-SMTP: 4kJJK.qswBDPuwyc5wW.BPAQqNXdy5j09UNyeAS0pyOQ708- Received: from [192.168.1.152] (DD-WRT [192.168.1.1]) by uriel.mandelberg.org (Postfix) with ESMTPSA id D57BB1C609A; Sun, 5 Feb 2017 12:23:24 -0500 (EST) To: Oleg Muravskiy References: <8bee5b64-8b54-99f4-3e86-f6450f664fd6@mandelberg.org> From: David Mandelberg Message-ID: <7f56ecd6-1753-ad26-0ff3-1cde6e3fe63d@mandelberg.org> Date: Sun, 5 Feb 2017 12:23:19 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9TX9JsBRC4XqONoWw7Ox6xDxTLJPCNbqD" Archived-At: Cc: draft-ietf-sidr-delta-protocol.all@ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-sidr-delta-protocol-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2017 17:23:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --9TX9JsBRC4XqONoWw7Ox6xDxTLJPCNbqD Content-Type: multipart/mixed; boundary="RocWvfNHCd3CGRNvxauSse1HxA28t0m0c" From: David Mandelberg To: Oleg Muravskiy Cc: iesg@ietf.org, secdir@ietf.org, draft-ietf-sidr-delta-protocol.all@ietf.org Message-ID: <7f56ecd6-1753-ad26-0ff3-1cde6e3fe63d@mandelberg.org> Subject: Re: secdir review of draft-ietf-sidr-delta-protocol-05 References: <8bee5b64-8b54-99f4-3e86-f6450f664fd6@mandelberg.org> In-Reply-To: --RocWvfNHCd3CGRNvxauSse1HxA28t0m0c Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 02/05/2017 07:44 AM, Oleg Muravskiy wrote: >> On 28 Jan 2017, at 22:29, David Mandelberg wrot= e: >> 3.5.1.2: I think the last paragraph might make it harder for the serve= r >> to recover from a temporary overload, since it can't tell clients to >> wait longer than 1 minute before re-fetching. It seems to me that >> letting the clients get a few minutes out of date until the server >> operator can provision more capacity is better than accidentally DoSin= g >> the server. >=20 > I think what we want to say here is that [for security reasons] RPs sho= uld not trust the HTTP caching headers for notification files, if they sp= ecify caching for longer than 1 minute, because those headers could be ov= erwritten by the (CDN) distribution servers which might be out of control= of the publication server operator. >=20 > One minute should be enough for a CDN to overcome DDoS anyway. Addition= ally, the If-Modified-Since: request header is mandatory, which also lowe= rs the load on the server. And specifying 1 minute cache expiration on no= tification file does not mean an RP *will* come back for a new file after= a minute. >=20 > So do you want a longer text in that paragraph? No, I think the existing text adequately explains what you're saying. I still think it's excessive to poll every 1 minute without honoring headers that say to wait longer*. But I don't think it's a security issue, and I don't think my opinion on this should delay publication. * I was aware of the issue you described where RPs should not trust unverified headers, so I'm not advocating for unconditional trust of the headers. I just think the RPs should trust the caching headers up to, maybe, 1 hour instead of 1 minute. But even 5 minutes would give CDN operators a lot more leeway to shed load. --=20 David Eric Mandelberg / dseomn http://david.mandelberg.org/ --RocWvfNHCd3CGRNvxauSse1HxA28t0m0c-- --9TX9JsBRC4XqONoWw7Ox6xDxTLJPCNbqD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAliXX4gACgkQRKlmUHCg4sB/TwCfVXWJG2IaQOEGmCYn/zh2DxdH ll8AoIUuZ4qb+pv7ZF9HC+4zbEu8FI7d =9pyY -----END PGP SIGNATURE----- --9TX9JsBRC4XqONoWw7Ox6xDxTLJPCNbqD-- From nobody Sun Feb 5 14:37:26 2017 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F15C3129A23 for ; Sun, 5 Feb 2017 14:37:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yA9hMB4BwwTr for ; Sun, 5 Feb 2017 14:37:19 -0800 (PST) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::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 CDFAC129A1E for ; Sun, 5 Feb 2017 14:37:16 -0800 (PST) Received: by mail-oi0-x236.google.com with SMTP id w204so38692890oiw.0 for ; Sun, 05 Feb 2017 14:37:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=m9Zw7GBbGbmGfZKAiue3DgWbHLJp/3P9bZD1zpOKDZk=; b=JwozVrfOhlergza5szLo3lcMnzWXmHHzFE0nBoKGNsNoCNzzAKGmadoeifwj6tnz8W vRodoqm3FW+TM4FMsbmzVcITAFZLE+Woz2SmrCc5GaEY10INsO7JoIYlnBZvlkAMIRTH j8l2gh6mAqGIjQL4aQWCns9onc/JnulYT40dfJ1zwgMWVuqEElTC6DjD9hbMm0sW/hH8 sGjk/PnMsNRqhLvCtRbsffxaa1nLNc0B2Bs0a6zyNMnYxmu3+CBGGwhVEQFTy5vLuXRc eOffk00gfv1v4MQ29JDGY6ROmhs57xl6+gJq4iWgDAW8wDmVzTyxYEKQoi7UHaGVTlDM onkQ== 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=m9Zw7GBbGbmGfZKAiue3DgWbHLJp/3P9bZD1zpOKDZk=; b=d4cRRFowNvoRjPfilXooxAMcU8rMzVimoUXDjWX+PhHlJyI9Yqfw2Oj/upXBSR+F/E /LH0sEo2cw/3tkjeK3c5z/kq2f3PmsF7Zck7uIFnIvlfOIMldHWKnu+epETeaVZHlFt9 wi7RZYCZvZ1AfymcIJPCk88Yzz23Ee3gLuoEvPC0vZDFdMJL3hX5rvQyngGDFoPoevFS rSD7vYD76hwdeYqcEZPLsv85AtWVBwTC1m7GqX3TbyNalvq+CvtBuWblZvsrWhN1X851 Zvh/J1Qhd/K96t03Mh0ASS49TQ+OkFfNytpD4Se5QXJCyTLxrs+5boxgPtilqDPZ7Frs v6Ow== X-Gm-Message-State: AMke39lBCtOsnVKHSEvUVvDmxw9hNlDZEMNepLa7sjVus8ay9NshC9FcNrTPb9oJFe6KaZkRulFJbMK1o3oIOQ== X-Received: by 10.202.178.11 with SMTP id b11mr3923877oif.101.1486334236046; Sun, 05 Feb 2017 14:37:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.74.51.201 with HTTP; Sun, 5 Feb 2017 14:36:55 -0800 (PST) From: Joseph Salowey Date: Sun, 5 Feb 2017 14:36:55 -0800 Message-ID: To: secdir , draft-ietf-dmm-4283mnids.all@ietf.org, The IESG Content-Type: multipart/alternative; boundary=001a113cd284284bbf0547d02863 Archived-At: Subject: [secdir] secdir review of draft-ietf-dmm-4283mnids-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2017 22:37:22 -0000 --001a113cd284284bbf0547d02863 Content-Type: text/plain; charset=UTF-8 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document is ready with nits. I was pleased that the security considerations does discuss some privacy issues. I think it would help to emphasize that identifiers can be trackable since many of the IDs in the draft are long lived. The section does mention it, this suggestion is just for emphasis. First sentence of second paragraph of security considerations. "Some identifiers (e.g., IMSI) are considered to be private information and some are long lived allowing for tracking of an individual or device." Cheers, Joe --001a113cd284284bbf0547d02863 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have reviewed this document as part of the security= directorate's ongoing effort to review all IETF documents being proces= sed by the IESG.=C2=A0 These comments were written primarily for the benefi= t of the security area directors.=C2=A0 Document editors and WG chairs shou= ld treat these comments just like any other last call comments.
<= br>
This document is ready with nits. =C2=A0

=
I was pleased that the security considerations does discuss some priva= cy issues.=C2=A0 I think it would help to emphasize that identifiers can be= trackable since many of the IDs in the draft are long lived.=C2=A0 The sec= tion does mention it, this suggestion is just for emphasis. =C2=A0

First sentence of second paragraph of security considerati= ons. =C2=A0

"Some identifiers (e.g., IMS= I) are considered to be private information and some are long lived allowin= g for tracking of an individual or device." =C2=A0
Cheers,

Joe
--001a113cd284284bbf0547d02863-- From nobody Sun Feb 5 18:41:25 2017 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 018E71294AD; Sun, 5 Feb 2017 18:41:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yhChqKqjPe7R; Sun, 5 Feb 2017 18:41:17 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E13FE129A8A; Sun, 5 Feb 2017 18:41:16 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DFV86559; Mon, 06 Feb 2017 02:41:15 +0000 (GMT) Received: from SZXEMA413-HUB.china.huawei.com (10.82.72.72) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 6 Feb 2017 02:41:14 +0000 Received: from SZXEMA502-MBS.china.huawei.com ([169.254.4.53]) by SZXEMA413-HUB.china.huawei.com ([10.82.72.72]) with mapi id 14.03.0235.001; Mon, 6 Feb 2017 10:41:10 +0800 From: "Xialiang (Frank)" To: secdir , The IESG , "draft-ietf-teas-gmpls-resource-sharing-proc.all@tools.ietf.org" Thread-Topic: [secdir] SecDir review of draft-ietf-teas-gmpls-resource-sharing-proc-08 Thread-Index: AdKAInfEqvyGbZ+IQNGuIrUZF9s6BA== Date: Mon, 6 Feb 2017 02:41:09 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.43.91] Content-Type: multipart/alternative; boundary="_000_C02846B1344F344EB4FAA6FA7AF481F12B0B1B24SZXEMA502MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.5897E24B.0125, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.53, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 5cdc91b6fe8cb36b252624efcb6d0029 Archived-At: Subject: [secdir] SecDir review of draft-ietf-teas-gmpls-resource-sharing-proc-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 02:41:19 -0000 --_000_C02846B1344F344EB4FAA6FA7AF481F12B0B1B24SZXEMA502MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments. This document reviews how the LSP association is to be provided using Resou= rce Reservation Protocol - Traffic Engineering (RSVP-TE) signaling in the c= ontext of GMPLS end-to-end recovery scheme when using restoration LSP where= failed LSP is not torn down. In addition, this document discusses resourc= e sharing-based setup and teardown of LSPs as well as LSP reversion procedu= res. Firstly, no new signaling extensions are defined by this document, and it i= s strictly informative in nature. So, no new security issues arise in this = document. Secondly, the security considerations in [RFC3209] [RFC4872] [RFC= 4873] and [RFC6689] are included in the security consideration section of t= his draft, nothing more is missed. In consequence, I have no more security = issues. Summary: this document appears in reasonably good shape, and no more securi= ty issues. I think it is ready. Thanks! B.R. Frank --_000_C02846B1344F344EB4FAA6FA7AF481F12B0B1B24SZXEMA502MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

I have reviewed this document as part of the security directorate's ongoin= g 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 chai= rs should treat these comments just like any other last call comments.=

 

This document reviews how the LSP association is to be provided using Reso= urce Reservation Protocol - Traffic Engineering (RSVP-TE) signaling in the context of GMPLS end-to-end recovery scheme whe= n using restoration LSP where failed LSP is not torn down.  In additio= n, this document discusses resource sharing-based setup and teardown of LSP= s as well as LSP reversion procedures.

 

Firstly, no new signaling extensions are defined by this document, and it = is strictly informative in nature. So, no new security issues arise in this document. Secondly, the security conside= rations in [RFC3209] [RFC4872] [RFC4873] and [RFC6689] are included in the = security consideration section of this draft, nothing more is missed. In co= nsequence, I have no more security issues.

 

Summary: this document appears in reasonably good shape, and no more secur= ity issues. I think it is ready.

 

Thanks!

 

B.R.

Frank

--_000_C02846B1344F344EB4FAA6FA7AF481F12B0B1B24SZXEMA502MBSchi_-- From nobody Mon Feb 6 02:50:43 2017 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AD31129545; Fri, 3 Feb 2017 16:26:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1486167968; bh=p9bAPRc7E+iqd8DKqPrRwWd7JOT0TzLwrXHhrn5XuGk=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=P4q1uWXF0m6vjxVew72rlF9XsGVdkiCWtRvJ8aVmW0axVYiSrYhBZ2UDpwME1O7HH Mcs/ckhEftA3iOp5xcU32GTKoADG7KiWwLnnbAM2dXxZEwy74NXtHsrIFOJKrXOwgI dAbCczrca2C9Trg4bf7SjwUm7bXx2RrsJ08asVJ8= X-Original-To: new-work@ietf.org Delivered-To: new-work@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E75C4126BF6 for ; Fri, 3 Feb 2017 16:26:02 -0800 (PST) MIME-Version: 1.0 From: The IESG To: X-Test-IDTracker: no X-IETF-IDTracker: 6.42.0 Auto-Submitted: auto-generated Precedence: bulk Reply_to: Message-ID: <148616796294.4079.12536501488662166371.idtracker@ietfa.amsl.com> Date: Fri, 03 Feb 2017 16:26:02 -0800 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 06 Feb 2017 02:50:43 -0800 Subject: [secdir] [new-work] WG Review: JSON Mail Access Protocol (jmap) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2017 00:26:08 -0000 A new IETF WG has been proposed in the Applications and Real-Time Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by 2017-02-13. JSON Mail Access Protocol (jmap) ----------------------------------------------------------------------- Current status: Proposed WG Chairs: TBD Assigned Area Director: Alexey Melnikov Applications and Real-Time Area Directors: Ben Campbell Alissa Cooper Alexey Melnikov Mailing list: Address: jmap@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/jmap Archive: https://mailarchive.ietf.org/arch/search/?email_list=jmap Group page: https://datatracker.ietf.org/group/jmap/ Charter: https://datatracker.ietf.org/doc/charter-ietf-jmap/ A number of JSON-based representations of email have been developed that are proprietary, non-standard, and incompatible with each other. These protocols are proliferating due to existing standards being insufficient or poorly suited to the environments they are operating in, particularly mobile and webmail. The use of multiple protocols to perform actions within a single application creates significant support challenges, as users may get a variety of partial failure modes (for example, can receive email, but can not send new messages). This is further exacerbated if the different protocols are authenticated separately. The JMAP working group will specify a mechanism to allow clients to both view and send email from a server over a single stateless HTTPS channel with minimal round trips. A single protocol for receipt and submission will resolve long-standing difficulties users face setting up clients to talk to servers. The protocol will support push notification of changes using the mechanism defined in RFC 8030. This will give mobile clients benefits in terms of battery life and network usage. It will also support push notifications via server-sent events (https://www.w3.org/TR/eventsource/) for direct connection to clients that can support persistent TCP connections. The work of this group is limited to developing a protocol for a client synchronising data with a server. Any server-to-server issues are out of scope for this working group. New end-to-end encryption mechanisms are out of scope, but the work should consider how to integrate with existing standards such as S/MIME and OpenPGP. The working group will coordinate with the Security Area on credential management and authentication. Input to working group discussions shall include: - CONDSTORE and QRESYNC [RFC 7162] - Collection Synchronisation for WebDav [RFC 6578] - LEMONADE and experiences from adoption of its output [https://datatracker.ietf.org/wg/lemonade/charter/] - SMTP SUBMISSION [RFC 6409] - SMTP BURL [RFC 4468] The working group will deliver the following: - A problem statement detailing the deployment environment and situations that motivate work on a new protocol for client to server email synchronisation. The working group may choose not to publish this as an RFC. - A document describing an extensible protocol and data structures, with support for flood control and batched operations, and operating over a stateless connection such as HTTPS. - A document describing how to use the extensible protocol over HTTPS with the data structures expressed as JSON. - A document describing a data model for email viewing, management, searching, and submission on top of the extensible protocol. - An executable test suite and documented test cases to assist developers of JMAP servers to ensure they conform to the specifications. Milestones: _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Mon Feb 6 08:08:42 2017 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7BBA129EDB for ; Mon, 6 Feb 2017 08:08:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.487 X-Spam-Level: X-Spam-Status: No, score=-4.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-1.887] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kYwTBwtqK3tu for ; Mon, 6 Feb 2017 08:08:34 -0800 (PST) Received: from nm20-vm4.bullet.mail.gq1.yahoo.com (nm20-vm4.bullet.mail.gq1.yahoo.com [98.136.217.35]) (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 8EF85129EDD for ; Mon, 6 Feb 2017 08:08:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1486397313; bh=aR2KcWDKibXClzz1ytdOZn3AC6lYC+4VWW7SgA70cAw=; h=Date:From:Reply-To:To:Cc:Subject:References:From:Subject; b=Zs2SkGnLFD3daIsaTJcu9wJ5G9Uj28za5Y9tY/BZmYtFHU5SB96g/3JQJ2LYY91u3Qf5fB9kmrw1XB6QfAAICmmnybo65663WNib57FuEUw2V0F1hWjJuzZBY64C3UB2O+w6a3g8UlZlrrccqphtgZhCMGjmseZcwoF7CYPTi8qSBbY+aJvYY8ujg6lovjKELxoNLSuyXCMYQiVPeRZ2EMR0f9LtNQebRsH6CP0MxwfKhVHVTpLKPdacnlrYSYSGa0396xXMN85ju11Hpf4z3HQCxCQadcIieYYzDZrEgHoFuyr2TZx+3V4vCxwdOcUOV1t0+NHeCqHbCRV4Hs4CIw== Received: from [216.39.60.183] by nm20.bullet.mail.gq1.yahoo.com with NNFMP; 06 Feb 2017 16:08:33 -0000 Received: from [98.137.12.237] by tm19.bullet.mail.gq1.yahoo.com with NNFMP; 06 Feb 2017 16:08:33 -0000 Received: from [127.0.0.1] by omp1045.mail.gq1.yahoo.com with NNFMP; 06 Feb 2017 16:08:33 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 932190.45649.bm@omp1045.mail.gq1.yahoo.com X-YMail-OSG: Yebr1kEVM1nRHRJz_HXaGhMXXkw8VXmz7vCyON7y.DH5qFQk1rdDBiYAQ9Ohjcc Tz7EqZz0ehiQHLDS_iOMLSwti8Jh08a_6suMX5b.QnQImb9mmc_KcUKMrto8g_ECPdhvCJF5JS93 _ezEi7tl5A1zHnlkMysQG52gModzeX1s08iPe5b6ABYSpy8iyl6No7Sd0OWnSxOFiEOmI6jt3CmX 3aBEVgEa4M30u7N.BZx1.l2dL9TTARnNdbDurA5mDYVjajMBlqv8.gVG.kcaSkM0m9eblmcKz_4u Cg0ZK8Rd3CXBnklKtiOCEcqolX9mpKhGSjNSFXUveuptLdQQdXH5EG8wLtORrolyqeXKEpCM9Isv c2N_AKJh_6.u.SpFCxxByp_3p.Qwgdc3L1vR_kqJmqG2lNqsgLIgYKBtD_Pht368FKXB_JD6hOr9 gZtyT2o7PXCLKYEvsDLzBzFP6sPkI90JscGptz3yvkp7Lr8Ram8g8B4QFLDgAZGv5dAZXU.W5gYW 1f5iaokYGGVs2z70X3HTedB3LtYLw5Yad Received: from jws300046.mail.gq1.yahoo.com by sendmailws147.mail.gq1.yahoo.com; Mon, 06 Feb 2017 16:08:33 +0000; 1486397313.538 Date: Mon, 6 Feb 2017 16:08:33 +0000 (UTC) From: To: , Tero Kivinen , Message-ID: <617949951.2705743.1486397313346@mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable References: <617949951.2705743.1486397313346.ref@mail.yahoo.com> Archived-At: Cc: draft-ietf-ippm-6man-pdm-option.all@tools.ietf.org Subject: [secdir] Fw: New Version Notification for draft-ietf-ippm-6man-pdm-option-07.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: nalini.elkins@insidethestack.com List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 16:08:39 -0000 Hello All, We have FINALLY revised the PDM draft to include all comments that we have = all agreed on. =20 There is: 1. A new layout for PDM since time base is now gone. 2. We have changed the description of timing calculations (some sections m= oved to an Appendix) 3. We have revised all examples, etc. to calculate in attoseconds & take o= ut timebase 4. Some minor wording changes. 5. The security section changes (non-minor!) 6. Changes for ESP (non-minor!) What is left to be done is to move the examples to an Appendix and to finis= h the Gen-Art reviewer comments. But, we wanted to get this in first as it= has taken very long already. Thanks, Nalini Elkins Inside Products, Inc. www.insidethestack.com (831) 659-8360 --- On Mon, 2/6/17, internet-drafts@ietf.org wro= te: > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-ietf-ippm-6man-pdm-option-07.= txt > To: ippm-chairs@ietf.org, "Robert M. Hamilton" , "Nali= ni Elkins" , "Rob Hamilton" , "mackermann@bcbsm.com" , "Michael S. Ackerman= n" > Date: Monday, February 6, 2017, 8:02 AM >=20 > A new version of I-D, > draft-ietf-ippm-6man-pdm-option-07.txt > has been successfully submitted by Nalini Elkins and posted > to the > IETF repository. >=20 > Name:=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 > draft-ietf-ippm-6man-pdm-option > Revision:=C2=A0=C2=A0=C2=A0 07 > Title:=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 IPv6 Performance > and Diagnostic Metrics (PDM) Destination Option > Document date:=C2=A0=C2=A0=C2=A0 2017-02-06 > Group:=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 ippm > Pages:=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 30 > URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/intern= et-drafts/draft-ietf-ippm-6man-pdm-option-07.txt > Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0https://datatracker.ietf.or= g/doc/draft-ietf-ippm-6man-pdm-option/ > Htmlized:=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0https://tools.ietf.org/html/draf= t-ietf-ippm-6man-pdm-option-07 > Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0https://www.ietf.org/r= fcdiff?url2=3Ddraft-ietf-ippm-6man-pdm-option-07 >=20 > Abstract: > =C2=A0=C2=A0=C2=A0To assess performance problems,=C2=A0 > measurements based on optional > =C2=A0=C2=A0=C2=A0sequence numbers and timing may be > embedded in each packet.=C2=A0 Such > =C2=A0=C2=A0=C2=A0measurements may be interpreted in > real-time or after the fact. An > =C2=A0=C2=A0=C2=A0implementation of the existing IPv6 > Destination Options extension > =C2=A0=C2=A0=C2=A0header, the Performance and Diagnostic > Metrics (PDM) Destination > =C2=A0=C2=A0=C2=A0Options extension header as well as the > field limits, calculations, > =C2=A0=C2=A0=C2=A0and usage of the PDM in measurement are > included in this document. >=20 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > =C2=A0=20 >=20 >=20 > Please note that it may take a couple of minutes from the > time of submission > until the htmlized version and diff are available at > tools.ietf.org. >=20 > The IETF Secretariat >=20 >=20 From nobody Tue Feb 7 12:27:06 2017 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F4B11294B3; Tue, 7 Feb 2017 12:27:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Yoav Nir To: X-Test-IDTracker: no X-IETF-IDTracker: 6.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148649922555.26656.10191520146576198408.idtracker@ietfa.amsl.com> Date: Tue, 07 Feb 2017 12:27:05 -0800 Archived-At: Cc: ietf@ietf.org, draft-hardie-privsec-metadata-insertion.all@ietf.org Subject: [secdir] Review of draft-hardie-privsec-metadata-insertion-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 20:27:05 -0000 Reviewer: Yoav Nir Review result: Has Nits Hi The document is well-written and understandable, but a few things about it seem wrong: Section 3 describes data minimization as "one of the core mitigations for the loss of confidentiality". However, the only example given where data minimization is used to mitigate confidentiality loss is when browsers suppress cookies in private mode. The rest of the examples given (HTTP proxies, recursive DNS, VPN) are such where the data minimization is incidental to some other function. Nobody deployed the HTTP proxy or the DNS server in order to enhance privacy. The HTTP proxy example in particular is not convincing. HTTP is designed to work without proxies. Any data minimization provided incidentally by a proxy is nothing that can be counted on, so a prohibition on restoring said data (especially in the case of a server-side load balancer) is just not convincing. OTOH in DNS recursive resolvers that hide the origin IP of the client are the norm - Authoritative servers hardly ever get to see real addresses of clients. In that case exposing the real IP address of the client shows data that was not there before. I believe the text should differentiate between cases where a network element is not part of the normal function of the protocol and works to undo the accidental data minimization that it causes, and cases where the network element is expected in the protocol and thus the minimization is expected as well. I think the prescription in the text applies to the latter. I am not convinced about the former The VPN example is a strange one. If the subject is a corporate VPN, then restoring the original IP addresses is the function of the VPN. If, OTOH, VPN is that service that allows people to watch Hulu outside of the US, then restoring the IP address would be counter-productive. It is also strange to see VPN used as an example of "systems whose primary function is not to provide confidentiality" From nobody Tue Feb 7 13:25:21 2017 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 445711295D5; Tue, 7 Feb 2017 13:25:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 Rp6QPhSJ9yWs; Tue, 7 Feb 2017 13:25:17 -0800 (PST) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44EF41294E4; Tue, 7 Feb 2017 13:25:17 -0800 (PST) Received: by mail-qt0-x22d.google.com with SMTP id w20so142603013qtb.1; Tue, 07 Feb 2017 13:25:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6tDw1+v982SFpHTSQV1kbUCiEVF9RiYVPSaGGV23X3k=; b=EaJqQVEHIg1q9pKPKypnAorJdhenBPgNjdhcPIy4L8Iied9N9EvCdQJ6Zfy0S1qkS8 M3mCGiFXzYfJ2nvlEpp7Wb9TjcZpHI6PXyPHexo2Gt0dfdT5BcL29FzbIXA1XyWfREGR tKJKxJk36rB5Wv3Bi6+WsHFlYrhgUQdg5N1q9WyCmN5vTR8Jk0Sk7x48xJ883PXOaWER C63jZtZwfvAH0UOXQqCl4E+/IeourhOE75Na18mZA10wcxecD81a8Nbpc3fHp45DYapm xdR80ozpUUCHq3Ji7MO4K6idkc2WJCCzVoliiHYVD1W3ppXLuzx9OlpbCuIk/DDHKN3K ifHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6tDw1+v982SFpHTSQV1kbUCiEVF9RiYVPSaGGV23X3k=; b=jPKBdvRysqU2Q3W/2Xq6f3A9rDx9mrLJsdlgynEJoN5FYLQzCvNM9wQzf4yuW/67Pl WteEpP78zO4AW+NQ32XJmq1HnUz5XzlCWc3CaZi0OluvqFUxmouXbLZYYktbXINZrA+d HKwPhnp0Q/DZhcwuRyylDhuYlPDEaYG5XreZ2K35PDVs2tpGqQ3UoMWupFYqEUh0ERg8 nE+qMUtPPC2n+eDGpCXrndhiN71q9qg2Ee/C04cs0ptu0Xf3fagKzIzSQgWtvmJqpxXJ 4wnG3HV3oM7kz4E0a8Xcimh2xOhVPrXV94SF82XBfWc+ul0D2ar2rZyePwLlHmJoPSei GbCg== X-Gm-Message-State: AMke39nPhBhlE3dO4X8vwkPL5M2Ey8WfHwZur43lXawB06vG78MW3kJ9q+QpZJiuUDM2OG/1XzgkrGQQ3G/oaw== X-Received: by 10.237.35.130 with SMTP id j2mr18360527qtc.45.1486502716388; Tue, 07 Feb 2017 13:25:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.174.226 with HTTP; Tue, 7 Feb 2017 13:24:46 -0800 (PST) In-Reply-To: <148649922555.26656.10191520146576198408.idtracker@ietfa.amsl.com> References: <148649922555.26656.10191520146576198408.idtracker@ietfa.amsl.com> From: Ted Hardie Date: Tue, 7 Feb 2017 13:24:46 -0800 Message-ID: To: Yoav Nir Content-Type: multipart/alternative; boundary=001a113914425e47750547f762e6 Archived-At: Cc: draft-hardie-privsec-metadata-insertion.all@ietf.org, IETF , "secdir@ietf.org" Subject: Re: [secdir] Review of draft-hardie-privsec-metadata-insertion-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 21:25:20 -0000 --001a113914425e47750547f762e6 Content-Type: text/plain; charset=UTF-8 On Tue, Feb 7, 2017 at 12:27 PM, Yoav Nir wrote: > Reviewer: Yoav Nir > Review result: Has Nits > > Hi > > The document is well-written and understandable, but a few things > about it seem wrong: > > Section 3 describes data minimization as "one of the core mitigations > for the loss of confidentiality". However, the only example given > where data minimization is used to mitigate confidentiality loss is > when browsers suppress cookies in private mode. The rest of the > examples given (HTTP proxies, recursive DNS, VPN) are such where the > data minimization is incidental to some other function. Nobody > deployed the HTTP proxy or the DNS server in order to enhance > privacy. > So, I would challenge "nobody" on the HTTP proxy front, but that's not the important piece here. The important piece is they generally do have a net privacy positive effect. That privacy positive effect is eliminated when metadata that would be concealed by normal operation is added back in. That's the converse of your statement: no one built an HTTP proxy or recursive DNS server in order to supply metadata. Is there a specific place in the doc where more text would make this point clearer? > > The HTTP proxy example in particular is not convincing. HTTP is > designed to work without proxies. Any data minimization provided > incidentally by a proxy is nothing that can be counted on, I'm not sure what you mean by "counted on" here. Do you mean that you can't know the pool of other users and thus the number of times you'll be served from cache rather than getting new data? > so a > prohibition on restoring said data (especially in the case of a > server-side load balancer) is just not convincing. OTOH in DNS > recursive resolvers that hide the origin IP of the client are the norm > - Authoritative servers hardly ever get to see real addresses of > clients. In that case exposing the real IP address of the client shows > data that was not there before. > > I believe the text should differentiate between cases where a network > element is not part of the normal function of the protocol and works > to undo the accidental data minimization that it causes, So, I think "accidental" is a tricky word here. The use of a proxy or recursive resolver is generally speaking not "accidental". Data minimization is a consequence of normal operation, and what we're talking about is changing operations in order to change that data minimization. The core of the advice is that instead of changing the operation of the middlebox, change the operation of the device about which you desire data. What would make that clearer? > and cases > where the network element is expected in the protocol and thus the > minimization is expected as well. I think the prescription in the text > applies to the latter. I am not convinced about the former > > The VPN example is a strange one. If the subject is a corporate VPN, > then restoring the original IP addresses is the function of the VPN. > If, OTOH, VPN is that service that allows people to watch Hulu outside > of the US, then restoring the IP address would be counter-productive. > It is also strange to see VPN used as an example of "systems whose > primary function is not to provide confidentiality" > > Well, it does two things: shifts the network locality of the endpoint using the VPN and masks who is shifting. I believe the first is the primary function and the second a common secondary property. If you would like different language on this, though, please let me know. thanks for the review, Ted --001a113914425e47750547f762e6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Feb 7, 2017 at 12:27 PM, Yoav Nir <ynir.ietf@gm= ail.com> wrote:
Reviewer: Yoav Nir
Review result: Has Nits

Hi

The document is well-written and understandable, but a few things
about it seem wrong:

Section 3 describes data minimization as "one of the core mitigations<= br> for the loss of confidentiality". However, the only example given
where data minimization is used to mitigate confidentiality loss is
when browsers suppress cookies in private mode. The rest of the
examples given (HTTP proxies, recursive DNS, VPN) are such where the
data minimization is incidental to some other function. Nobody
deployed the HTTP proxy or the DNS server in order to enhance
privacy.

So, I would challenge "no= body" on the HTTP proxy front, but that's not the important piece = here.=C2=A0 The important piece is they generally do have a net privacy pos= itive effect.=C2=A0 That privacy positive effect is eliminated when metadat= a that would be concealed by normal operation is added back in.=C2=A0 That&= #39;s the converse of your statement:=C2=A0 no one built an HTTP proxy or r= ecursive DNS server in order to supply metadata.=C2=A0

I= s there a specific place in the doc where more text would make this point c= learer?
=C2=A0

The HTTP proxy example in particular is not convincing. HTTP is
designed to work without proxies. Any data minimization provided
incidentally by a proxy is nothing that can be counted on,

I'm not sure what you mean by "counted on" h= ere.=C2=A0 Do you mean that you can't know the pool of other users and = thus the number of times you'll be served from cache rather than gettin= g new data?
=C2=A0
so a prohibition on restoring said data (especially in the case of a
server-side load balancer) is just not convincing. OTOH in DNS
recursive resolvers that hide the origin IP of the client are the norm
- Authoritative servers hardly ever get to see real addresses of
clients. In that case exposing the real IP address of the client shows
data that was not there before.

I believe the text should differentiate between cases where a network
element is not part of the normal function of the protocol and works
to undo the accidental data minimization that it causes,
<= br>
So, I think "accidental" is a tricky word here. The= use of a proxy or recursive resolver is generally speaking not "accid= ental".=C2=A0 Data minimization is a consequence of normal operation, = and what we're talking about is changing operations in order to change = that data minimization.=C2=A0 The core of the advice is that instead of cha= nging the operation of the middlebox, change the operation of the device ab= out which you desire data.

What would make that clearer?<= br>
=C2=A0
and cases
where the network element is expected in the protocol and thus the
minimization is expected as well. I think the prescription in the text
applies to the latter. I am not convinced about the former

The VPN example is a strange one. If the subject is a corporate VPN,
then restoring the original IP addresses is the function of the VPN.
If, OTOH, VPN is that service that allows people to watch Hulu outside
of the US, then restoring the IP address would be counter-productive.
It is also strange to see VPN used as an example of "systems whose
primary function is not to provide confidentiality"

Well, it does two things:=C2=A0 shifts the network lo= cality of the endpoint using the VPN and masks who is shifting.=C2=A0 I bel= ieve the first is the primary function and the second a common secondary pr= operty.=C2=A0 If you would like different language on this, though, please = let me know.

thanks for the review,

Ted=
=C2=A0

--001a113914425e47750547f762e6-- From nobody Wed Feb 8 03:05:00 2017 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6170B126CD8; Wed, 8 Feb 2017 03:04:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 Hxzof1fl-7Pb; Wed, 8 Feb 2017 03:04:54 -0800 (PST) Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61A57126579; Wed, 8 Feb 2017 03:04:54 -0800 (PST) Received: from titi.ripe.net ([193.0.23.11]) by mahimahi.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1cbQ3P-0009B2-My; Wed, 08 Feb 2017 12:04:53 +0100 Received: from dog.ripe.net ([193.0.1.217] helo=[IPv6:::1]) by titi.ripe.net with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84_2) (envelope-from ) id 1cbQ3O-0001Et-ET; Wed, 08 Feb 2017 12:04:50 +0100 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_F07CAB92-5F5C-4D4C-A861-A5AE561197F7"; protocol="application/pgp-signature"; micalg=pgp-sha256 From: Oleg Muravskiy In-Reply-To: <7f56ecd6-1753-ad26-0ff3-1cde6e3fe63d@mandelberg.org> Date: Wed, 8 Feb 2017 12:04:49 +0100 Message-Id: <8048CCD5-0D86-4C33-8F8A-C74728FE8B67@ripe.net> References: <8bee5b64-8b54-99f4-3e86-f6450f664fd6@mandelberg.org> <7f56ecd6-1753-ad26-0ff3-1cde6e3fe63d@mandelberg.org> To: David Mandelberg X-Mailer: Apple Mail (2.3124) X-ACL-Warn: Delaying message X-RIPE-Spam-Level: --------- X-RIPE-Spam-Report: Spam Total Points: -9.4 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: c408758d4ce2e8eb06762a65a3365b74b9f924d4ac838e63fb7605785a1ccb2c Archived-At: Cc: draft-ietf-sidr-delta-protocol.all@ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-sidr-delta-protocol-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 11:04:55 -0000 --Apple-Mail=_F07CAB92-5F5C-4D4C-A861-A5AE561197F7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi everybody, > On 05 Feb 2017, at 18:23, David Mandelberg = wrote: >=20 > On 02/05/2017 07:44 AM, Oleg Muravskiy wrote: >>> On 28 Jan 2017, at 22:29, David Mandelberg = wrote: >>> 3.5.1.2: I think the last paragraph might make it harder for the = server >>> to recover from a temporary overload, since it can't tell clients to >>> wait longer than 1 minute before re-fetching. It seems to me that >>> letting the clients get a few minutes out of date until the server >>> operator can provision more capacity is better than accidentally = DoSing >>> the server. >>=20 >> I think what we want to say here is that [for security reasons] RPs = should not trust the HTTP caching headers for notification files, if = they specify caching for longer than 1 minute, because those headers = could be overwritten by the (CDN) distribution servers which might be = out of control of the publication server operator. >>=20 >> One minute should be enough for a CDN to overcome DDoS anyway. = Additionally, the If-Modified-Since: request header is mandatory, which = also lowers the load on the server. And specifying 1 minute cache = expiration on notification file does not mean an RP *will* come back for = a new file after a minute. >>=20 >> So do you want a longer text in that paragraph? >=20 > No, I think the existing text adequately explains what you're saying. = I > still think it's excessive to poll every 1 minute without honoring > headers that say to wait longer*. But I don't think it's a security > issue, and I don't think my opinion on this should delay publication. >=20 > * I was aware of the issue you described where RPs should not trust > unverified headers, so I'm not advocating for unconditional trust of = the > headers. I just think the RPs should trust the caching headers up to, > maybe, 1 hour instead of 1 minute. But even 5 minutes would give CDN > operators a lot more leeway to shed load. Reading the paragraph in question again: Relying Parties SHOULD NOT cache the notification file for longer than 1 minute, regardless of the headers set by the repository server or CDN. I think it could be misinterpreted in a way that RP should re-fetch = notification file even if being in a middle of a validation run, which = is wrong. So I propose a new text: In case of a high load on a repository server or its distribution network, the Cache-Control HTTP header, or a similar mechanism, MAY be used to suggest an optimal (for the repository server) poll interval for Relying Parties. However, setting it to an interval longer than 1 hour is NOT RECOMMENDED. Relying parties SHOULD align the suggested interval with their operational practices and the expected update frequency of RPKI repository data, and MAY discard suggested value. What do you think? Oleg --Apple-Mail=_F07CAB92-5F5C-4D4C-A861-A5AE561197F7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJYmvtSAAoJEKt45HsRg/7A/nsP/0USlN6LamjkdaC1jGQzmCTz 5+VuPRpSk3OuLJNhSIoy+IDL3V/Y5WujKpQO0h+rRcjLAfEdtLVkKYErSwKXJGTx JQ9YK/hEhO63lsibvl9NSoMAbVAoGfoqkJfMLoeWr38V8laR+ODb8bEbTQjPDw1R RtTchE+ShUNYAVPYQWut0CBwJSiukjmTiV43769vyiT2q6aBoL6LYNVNLwlth09o +NOrwQKJzeKDRkh4im+sFpJC7zxmJwlhpch9EdEQIA20BLdPNBULUKK8voeJSsN1 cnrNaZt5uXFksO3FgZvar549qMrN5kca0ECNrTVqV4+KQdI62hCBm45NnFZ4p1h8 jp12++c1bQ/svLJoB7p2kSU2gXsdb5EUkBDmxwzFOBBv5W7O83bdNTaJS+arFfg3 tHBfJ9v0expXOSRXtHXiQPGer/9LI3QuHhCDuwkKcqSwc71ZlOZjY2MRB8NvYVv9 Lro1GOmZpee2gvufYJEVZJLPJSQlSYSlxCwGC9oIumuoZpAIsmUO3hMwKP1bpxPk QmX1B9PbvV8trHHuDz4agVZLgVhRNobtpUpGILQDT2Et0k773d4rFxKEGY/amsRD 8MwWU8YqNP/ZGzqFFaq3+n1VIEU5mAD2q5iMWFC96O4xyiNGFNRbHJXCpg2+RDmS G9eih3jqYDXnSg4T87Di =verJ -----END PGP SIGNATURE----- --Apple-Mail=_F07CAB92-5F5C-4D4C-A861-A5AE561197F7-- From nobody Wed Feb 8 10:45:31 2017 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC83129D5F; Wed, 8 Feb 2017 10:45:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 1IMlxQFGvj0c; Wed, 8 Feb 2017 10:45:22 -0800 (PST) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9AC6129D5A; Wed, 8 Feb 2017 10:45:16 -0800 (PST) Received: by mail-wm0-x231.google.com with SMTP id v186so58857156wmd.0; Wed, 08 Feb 2017 10:45:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=OrUedj1qObAJC3HT2CAUKHthOOrhyJlWXWL7EpTCFVc=; b=KJasgwqvdrTCUd/jyLNl02dmKkF2Rr7rqwdEaLkFbUEX9LtEJkqyKLuPFnVQRRzOpO fM2xfhh8FTeXXLODFI5glG2Xakx7A4MgSnCObmX0zFTUuBLzdmNH/vP837ftmah8RF2i jWeme0vsKkeh6Cg6Onxi7H+hRYBHpY6/H29iqZoRFI66/42B5cmM3ELhAItLe3Uu9jHT +N206eYYsx7leqs/4Gey9dSAuErae0M51DoAhrZ3DQ5pZyr1QNrSx46YRLFysdovypYk AfaF3RqnXRlgwkLSgzx7zpWylI2ZM/AyvboAdIFe5u0hm/xkC5kIluKOWaYyV1Z3eL9o /uLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=OrUedj1qObAJC3HT2CAUKHthOOrhyJlWXWL7EpTCFVc=; b=K17nB3iNJXv+Odf1lJ1Ryg0PYwV3qMaTk8cp3qiR9imHSVnQy0orWDs12nrM0HRS4o MoteVZDx2ptmzEjsSjExUuF0UAwSy2DCmCmiUGbrArpYfTBJplkiffSTGeoHDTPR7vOo w5u3xiFympoWMYUqokRQkAcsHpUNxJSkviScu1n/hvM9aos9sbJ/FdG3APqgytFSSNP2 W6AXNIRnVCDeY5/DWq6k6pkt6crMl+0Lf9GCnzzOb2nyFZvhoj9XJZu4iYU8oelspr8q LzHCGtexQouYbu/syksL8z61s91CClo9vCZMKD6hBWqb+m3WEI3nA6VLy/Uwa0oOAEF9 eV/A== X-Gm-Message-State: AMke39m+jLPsjkgxBeT0J/RHDOkmWxsCAmexqGRkzygWDu++TG97FF4MWr/23YB3/vBgNQ== X-Received: by 10.28.229.193 with SMTP id c184mr20865500wmh.83.1486579515165; Wed, 08 Feb 2017 10:45:15 -0800 (PST) Received: from [192.168.1.14] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id e6sm14416601wrc.30.2017.02.08.10.45.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Feb 2017 10:45:13 -0800 (PST) From: Yoav Nir Message-Id: <7375E069-469A-4799-821E-684EEF885217@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_2FA23AA9-C782-4202-9200-714F7259474A"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Wed, 8 Feb 2017 20:45:10 +0200 In-Reply-To: To: Ted Hardie References: <148649922555.26656.10191520146576198408.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: draft-hardie-privsec-metadata-insertion.all@ietf.org, IETF , "secdir@ietf.org" Subject: Re: [secdir] Review of draft-hardie-privsec-metadata-insertion-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 18:45:25 -0000 --Apple-Mail=_2FA23AA9-C782-4202-9200-714F7259474A Content-Type: multipart/alternative; boundary="Apple-Mail=_DE1FF170-8476-46FE-905C-2C6DA4653B69" --Apple-Mail=_DE1FF170-8476-46FE-905C-2C6DA4653B69 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 7 Feb 2017, at 23:24, Ted Hardie wrote: >=20 > On Tue, Feb 7, 2017 at 12:27 PM, Yoav Nir > wrote: > Reviewer: Yoav Nir > Review result: Has Nits >=20 > Hi >=20 > The document is well-written and understandable, but a few things > about it seem wrong: >=20 > Section 3 describes data minimization as "one of the core mitigations > for the loss of confidentiality". However, the only example given > where data minimization is used to mitigate confidentiality loss is > when browsers suppress cookies in private mode. The rest of the > examples given (HTTP proxies, recursive DNS, VPN) are such where the > data minimization is incidental to some other function. Nobody > deployed the HTTP proxy or the DNS server in order to enhance > privacy. >=20 > So, I would challenge "nobody" on the HTTP proxy front, but that's not = the important piece here. The important piece is they generally do have = a net privacy positive effect. That privacy positive effect is = eliminated when metadata that would be concealed by normal operation is = added back in. That's the converse of your statement: no one built an = HTTP proxy or recursive DNS server in order to supply metadata. >=20 > Is there a specific place in the doc where more text would make this = point clearer? Perhaps an explanation of the phrase =E2=80=9Cother actors within a = protocol=E2=80=9D in paragraph 2 of section 3. Is it just intermediaries = (which according to the definition in RFC 6973 are necessary for the = protocol) or are there any other entities? Is it existing middleboxes = that new protocols seed to modify or entirely new middleboxes? >=20 > The HTTP proxy example in particular is not convincing. HTTP is > designed to work without proxies. Any data minimization provided > incidentally by a proxy is nothing that can be counted on, >=20 > I'm not sure what you mean by "counted on" here. Do you mean that you = can't know the pool of other users and thus the number of times you'll = be served from cache rather than getting new data? Just that I would never write a privacy considerations section that says = =E2=80=9CThe source address of the client is obfuscated because NATs and = proxies are everywhere=E2=80=9D. I can=E2=80=99t count on a proxy (or = NAT) always being present, so I can=E2=80=99t count on them as the = solution to the data minimization need. I *can* generally assume that = clients will use a recursive DNS resolver. > so a > prohibition on restoring said data (especially in the case of a > server-side load balancer) is just not convincing. OTOH in DNS > recursive resolvers that hide the origin IP of the client are the norm > - Authoritative servers hardly ever get to see real addresses of > clients. In that case exposing the real IP address of the client shows > data that was not there before. >=20 > I believe the text should differentiate between cases where a network > element is not part of the normal function of the protocol and works > to undo the accidental data minimization that it causes, >=20 > So, I think "accidental" is a tricky word here. The use of a proxy or = recursive resolver is generally speaking not "accidental". Data = minimization is a consequence of normal operation, and what we're = talking about is changing operations in order to change that data = minimization. The core of the advice is that instead of changing the = operation of the middlebox, change the operation of the device about = which you desire data. >=20 > What would make that clearer? Yes. Talking about changing the operation of the middlebox assumes that = the middlebox already existed. So we already had a proxy, and now it=E2=80= =99s adding new fields. Is the advice just about extending the = functionality of existing intermediaries? > and cases > where the network element is expected in the protocol and thus the > minimization is expected as well. I think the prescription in the text > applies to the latter. I am not convinced about the former >=20 > The VPN example is a strange one. If the subject is a corporate VPN, > then restoring the original IP addresses is the function of the VPN. > If, OTOH, VPN is that service that allows people to watch Hulu outside > of the US, then restoring the IP address would be counter-productive. > It is also strange to see VPN used as an example of "systems whose > primary function is not to provide confidentiality" >=20 > Well, it does two things: shifts the network locality of the endpoint = using the VPN and masks who is shifting. I believe the first is the = primary function and the second a common secondary property. If you = would like different language on this, though, please let me know. To me VPN is mostly about providing confidentiality and data integrity = while traversing the Internet. How about OLD similarly a VPN system used to provide channel security may believe that origin IP should be restored. NEW similarly a VPN system restores all of the metadata associated with the IP packet at the tunnel egress. Yoav --Apple-Mail=_DE1FF170-8476-46FE-905C-2C6DA4653B69 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 7 Feb 2017, at 23:24, Ted Hardie <ted.ietf@gmail.com> = wrote:

On Tue, = Feb 7, 2017 at 12:27 PM, Yoav Nir <ynir.ietf@gmail.com> wrote:
Reviewer: Yoav Nir
Review result: Has Nits

Hi

The document is well-written and = understandable, but a few things
about it seem wrong:

Section 3 describes data minimization as "one = of the core mitigations
for the loss of confidentiality". = However, the only example given
where data minimization is = used to mitigate confidentiality loss is
when browsers = suppress cookies in private mode. The rest of the
examples = given (HTTP proxies, recursive DNS, VPN) are such where the
data minimization is incidental to some other function. = Nobody
deployed the HTTP proxy or the DNS server in order = to enhance
privacy.

So, I would challenge = "nobody" on the HTTP proxy front, but that's not the important piece = here.  The important piece is they generally do have a net privacy = positive effect.  That privacy positive effect is eliminated when = metadata that would be concealed by normal operation is added back = in.  That's the converse of your statement:  no one built an = HTTP proxy or recursive DNS server in order to supply = metadata.  

Is there a specific = place in the doc where more text would make this point clearer?

Perhaps an explanation of the phrase =E2=80=9Cother = actors within a protocol=E2=80=9D in paragraph 2 of section 3. Is it = just intermediaries (which according to the definition in RFC 6973 are = necessary for the protocol) or are there any other entities? Is it = existing middleboxes that new protocols seed to modify or entirely new = middleboxes?


The HTTP = proxy example in particular is not convincing. HTTP is
designed to work without proxies. Any data minimization = provided
incidentally by a proxy is nothing that can be = counted on, 

I'm not sure what you = mean by "counted on" here.  Do you mean that you can't know the = pool of other users and thus the number of times you'll be served from = cache rather than getting new = data?

Just that I would never write a privacy = considerations section that says =E2=80=9CThe source address of the = client is obfuscated because NATs and proxies are everywhere=E2=80=9D. I = can=E2=80=99t count on a proxy (or NAT) always being present, so I = can=E2=80=99t count on them as the solution to the data minimization = need. I *can* generally assume that clients will use a recursive DNS = resolver.

so a
prohibition on restoring said data (especially in the case of = a
server-side load balancer) is just not convincing. OTOH = in DNS
recursive resolvers that hide the origin IP of the = client are the norm
- Authoritative servers hardly ever = get to see real addresses of
clients. In that case = exposing the real IP address of the client shows
data that = was not there before.

I believe the text = should differentiate between cases where a network
element = is not part of the normal function of the protocol and works
to undo the accidental data minimization that it = causes,

So, I think "accidental" is a tricky word here. The use of a = proxy or recursive resolver is generally speaking not = "accidental".  Data minimization is a consequence of normal = operation, and what we're talking about is changing operations in order = to change that data minimization.  The core of the advice is that = instead of changing the operation of the middlebox, change the operation = of the device about which you desire data.

What would make that clearer?

Yes. Talking about changing the operation of the = middlebox assumes that the middlebox already existed. So we already had = a proxy, and now it=E2=80=99s adding new fields. Is the advice just = about extending the functionality of existing = intermediaries?

and cases
where the network element is expected in the protocol and = thus the
minimization is expected as well. I think the = prescription in the text
applies to the latter. I am not = convinced about the former

The VPN example = is a strange one. If the subject is a corporate VPN,
then = restoring the original IP addresses is the function of the VPN.
If, OTOH, VPN is that service that allows people to watch = Hulu outside
of the US, then restoring the IP address = would be counter-productive.
It is also strange to see VPN = used as an example of "systems whose
primary function is = not to provide confidentiality"

Well, it does two things:  = shifts the network locality of the endpoint using the VPN and masks who = is shifting.  I believe the first is the primary function and the = second a common secondary property.  If you would like different = language on this, though, please let me know.

To me VPN is mostly about providing confidentiality and = data integrity while traversing the Internet.  How = about

OLD
                    =
        similarly a VPN system used to provide
   channel security may believe that origin IP should be =
restored.

NEW
                         =
   similarly a VPN system restores all of
   the metadata associated with the IP packet at the tunnel =
egress.


Yoav
= --Apple-Mail=_DE1FF170-8476-46FE-905C-2C6DA4653B69-- --Apple-Mail=_2FA23AA9-C782-4202-9200-714F7259474A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJYm2c2AAoJELhJCxUKWMyZqxQH/RWrUrtijLQgfiCsModM9m5M LkWN3jiiQqzP3dX7GuqHDOxRGvN7u5o6h7KLEdvQRG20zVWdA+1XGWb09uV1MxEn gu+bK0vHxxbvwAiE1wWDtr5INhZxCPru0ZUrYAw0BeZfj6E4TyIb8pU5Nwtlbht6 HJSlVtIN0eaXWsm7BzYzYwfSIZUD/hWaQMCrMeuykRhK4SxofdW63FX5CDZv/z4o JCNmj3rVedohYif/GegTSlV1aAugqIMxuWJU4QQANHmYSukSksfXUd1N/WMysI7r 7RZfVd/36wgWhkpU7VmMn/Iy6QY2rCD8lJewDYp3mzQi01FipPAl8kW0vSUDLpE= =DOMo -----END PGP SIGNATURE----- --Apple-Mail=_2FA23AA9-C782-4202-9200-714F7259474A-- From nobody Thu Feb 9 04:10:18 2017 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D5F091299B2 for ; Thu, 9 Feb 2017 04:10:17 -0800 (PST) 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.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148664221786.20622.1653689321601839252.idtracker@ietfa.amsl.com> Date: Thu, 09 Feb 2017 04:10:17 -0800 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 12:10:18 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2017-02-16 Reviewer LC end Draft Tero Kivinen R2016-12-20 draft-ietf-6tisch-minimal-19 Matthew Miller 2017-01-30 draft-ietf-sidr-rpki-rtr-rfc6810-bis-08 Lt. Mundy 2017-01-26 draft-ietf-mpls-tp-linear-protection-mib-11 Sandra Murphy 2016-12-20 draft-ietf-6tisch-minimal-19 Hilarie Orman 2017-02-09 draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-05 For telechat 2017-03-02 Reviewer LC end Draft Benjamin Kaduk R2017-01-17 draft-ietf-mpls-residence-time-13 Melinda Shore 2017-02-27 draft-sgtatham-secsh-iutf8-05 David Waltermire 2017-02-13 draft-ietf-pals-mpls-tp-dual-homing-protection-05 Brian Weis 2017-02-13 draft-ietf-pals-mpls-tp-dual-homing-coordination-05 Klaas Wierenga 2017-02-10 draft-ietf-dmm-hnprenum-05 Dacheng Zhang 2017-02-20 draft-ietf-httpbis-rfc5987bis-04 Last calls: Reviewer LC end Draft Derek Atkins None draft-ietf-i2nsf-problem-and-use-cases-09 Alan DeKok 2017-02-15 draft-bradner-rfc3979bis-11 Vincent Roca 2017-02-07 draft-ietf-nfsv4-rfc5666bis-10 Rich Salz 2017-03-01 draft-ietf-6man-rfc4291bis-07 Yaron Sheffer 2017-03-01 draft-ietf-6man-rfc2460bis-08 Robert Sparks 2017-02-15 draft-ietf-grow-mrt-add-paths-03 Paul Wouters 2017-02-09 draft-ietf-mmusic-sctp-sdp-22 Tom Yu 2017-02-20 draft-ietf-slim-negotiating-human-language-06 Early review requests: Reviewer Due Draft Daniel Gillmor 2016-02-01 draft-ietf-rtcweb-security-08 Brian Weis 2016-02-01 draft-ietf-cdni-uri-signing-10 Next in the reviewer rotation: John Bradley Shaun Cooley Alan DeKok Donald Eastlake Shawn Emery Daniel Franke Daniel Gillmor Tobias Gondrom Ólafur Guðmundsson Phillip Hallam-Baker From nobody Thu Feb 9 12:51:11 2017 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB2F1295B7; Thu, 9 Feb 2017 12:51:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-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 09GlGRd1_zhk; Thu, 9 Feb 2017 12:51:08 -0800 (PST) Received: from out02.mta.xmission.com (out02.mta.xmission.com [166.70.13.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 7F661126D74; Thu, 9 Feb 2017 12:51:08 -0800 (PST) Received: from in02.mta.xmission.com ([166.70.13.52]) by out02.mta.xmission.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.87) (envelope-from ) id 1cbvgJ-0006jz-6F; Thu, 09 Feb 2017 13:51:07 -0700 Received: from [72.250.219.84] (helo=rumpleteazer.rhmr.com) by in02.mta.xmission.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.87) (envelope-from ) id 1cbvgI-0000Jw-FR; Thu, 09 Feb 2017 13:51:07 -0700 Received: from rumpleteazer.rhmr.com (localhost [127.0.0.1]) by rumpleteazer.rhmr.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id v19Ko9wb018644; Thu, 9 Feb 2017 13:50:09 -0700 Received: (from hilarie@localhost) by rumpleteazer.rhmr.com (8.14.4/8.14.4/Submit) id v19Ko9mi018578; Thu, 9 Feb 2017 13:50:09 -0700 Date: Thu, 9 Feb 2017 13:50:09 -0700 Message-Id: <201702092050.v19Ko9mi018578@rumpleteazer.rhmr.com> From: "Hilarie Orman" To: iesg@ietf.org, secdir@ietf.org X-XM-SPF: eid=1cbvgI-0000Jw-FR; ; ; mid=<201702092050.v19Ko9mi018578@rumpleteazer.rhmr.com>; ; ; hst=in02.mta.xmission.com; ; ; ip=72.250.219.84; ; ; frm=hilarie@purplestreak.com; ; ; spf=none X-XM-AID: U2FsdGVkX1+qDvTR5mTtxo663orfQZ0V X-SA-Exim-Connect-IP: 72.250.219.84 X-SA-Exim-Mail-From: hilarie@purplestreak.com X-Spam-DCC: XMission; sa05 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ****;iesg@ietf.org, secdir@ietf.org X-Spam-Relay-Country: X-Spam-Timing: total 376 ms - load_scoreonly_sql: 0.05 (0.0%), signal_user_changed: 4.3 (1.1%), b_tie_ro: 2.9 (0.8%), parse: 1.29 (0.3%), extract_message_metadata: 6 (1.5%), get_uri_detail_list: 1.90 (0.5%), tests_pri_-1000: 4.6 (1.2%), tests_pri_-950: 2.0 (0.5%), tests_pri_-900: 1.65 (0.4%), tests_pri_-400: 24 (6.4%), check_bayes: 23 (6.0%), b_tokenize: 8 (2.0%), b_tok_get_all: 7 (1.7%), b_comp_prob: 3.0 (0.8%), b_tok_touch_all: 2.9 (0.8%), b_finish: 0.71 (0.2%), tests_pri_0: 325 (86.6%), check_dkim_signature: 0.59 (0.2%), check_dkim_adsp: 3.6 (1.0%), tests_pri_500: 3.3 (0.9%), rewrite_mail: 0.00 (0.0%) X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Archived-At: Cc: draft-ietf-dhc-dhcpv6-prefix-length-hint-issue.all@tools.ietf.org Subject: [secdir] Security review of draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Hilarie Orman List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 20:51:09 -0000 Security review of DHCPv6 Prefix Length Hint Issues draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-05 Do not be alarmed. I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document gives advice on how servers and clients can handle DHCP cases in which the client requests a particular prefix length and the server cannot exactly match it. This statement is very difficult to interpret: "the server SHOULD provide the prefix with the shortest length possible which is closest to the prefix-length hint value." This alternative in section 3.6 makes more sense: "assign a prefix of at least the hint length (or shorter) if one is available." I do not see any obvious security flaws, but my opinion is tempered by the lack of prior discussion. The security considerations refer to RFC3633 "IPv6 Prefix Options for DHCPv6", and that refers to ongoing development of IPsec for DHCPv6. As nearly as I can tell, that work was never done. That makes it difficult to have confidence in the "no new security considerations" claim. Some nits: Remove the comma in the first sentence of the introduction. "prefix which length" should be "prefix with length" or possibly "prefix whose length". "The servers usually has a record" should be "The server usually has a record". No comma in "When the client wants the same prefix back from the server, and would prefer ...". Hilarie From nobody Thu Feb 9 19:27:41 2017 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D8BB7129568; Thu, 9 Feb 2017 19:27:32 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Paul Wouters To: X-Test-IDTracker: no X-IETF-IDTracker: 6.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148669725288.8138.2095744202497272272.idtracker@ietfa.amsl.com> Date: Thu, 09 Feb 2017 19:27:32 -0800 Archived-At: Cc: draft-ietf-mmusic-sctp-sdp.all@ietf.org, ietf@ietf.org, mmusic@ietf.org Subject: [secdir] Review of draft-ietf-mmusic-sctp-sdp-22 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 03:27:33 -0000 Reviewer: Paul Wouters Review result: Has Issues 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. [Note that I am not well versed in SCTP] This document defines SDP [RFC4566] protocol identifiers (proto values): 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP'. This specification also specifies how to use the new proto values with the SDP Offer/Answer mechanism [RFC3264] for negotiating SCTP-over-DTLS associations. As this document only defines a method of signaling to use UDP/DTLS/SCTP or UDP/DTLS/SCTP, there are not specific Security Considerations for this document, and the Security Considerations correctly points to the documents that actually implement the UDP/DTLS/SCTP and TCP/DTLS/SCTP protocols. So from a security point of view, this document is Ready. I do have some generic concerns and questions I would like to see addressed: One general issue I have is with the specification of IANA values and punting some of its meaning. Let me quote an example: NOTE: This specification only defines the usage of the SDP 'max- message-size' attribute when associated with an m- line containing one of the following proto values: 'UDP/DTLS/SCTP' or 'TCP/DTLS/ SCTP'. Usage of the attribute with other proto values needs to be defined in a separate specification. This type of constraint is not clear and easilly displayed in an IANA registry if other values are later added to the table. This text is also an example of how througout the document, items are explicitely "this use is unspecified for now but other documents may change that". It would have been better to just simply and clearly state the current specified use, and let future documents handle updating this document appropriately. This language use makes a lot of decisions for implementers unclear as these decisions are punted forward in time without a reference to follow. Section 4.4.1 states: This specification creates an IANA registry for 'association-usage' values. I think this should be specified a little more clearly, similar to the IANA section specification itself. Something like: This specification creates the IANA 'association-usage' registry for SDP Attributes. Section 4.4.2: The table contains an error on the entries (UDP instead of TCP). I would personally change the port parameter value to just "port number for " or "UDP or TCP port number" Section 4.5: I'm unsure if ordering matters, so I am confused by the table ordering in media, proto, port, and the m= line example ordering media, port proto. I'm further confused by the table listing colon's, eg ":" and the m= line not using colons but spaces. And the following a= lines using colons again. Is this an error, or this is my lack of familiarity with the used protocols? Section 5.1: Therefore, if the attribute is not present, the associated m- line MUST be considered invalid. Is it obvious what one must done when the m- line is considered invalid? Section 5.2: Leading zeroes MUST NOT be used. What is the problem with leading zeros? What can go wrong when these are used? Should an implementor be warned about something specific? Section 6.1: An SCTP endpoint MUST NOT send a SCTP user message with a message size that is larger than the maximum size indicated by the peer, as it cannot be assumed that the peer would accept such message. While this tells an implementer what not to do, it does not tell the implementer what to do when this happens on the receiving end. It would be good to specify that here as well so that implementors will be reminded to think of this error handling case. a maximum message size value of zero, it indicates the SCTP endpoint will handle messages of any size, subject to memory capacity etc. I'm personally not a big fan of 0 meaning infinite, but if this is how other related specs are handling these values in this way, I can understand doing it here as well. For instance, not specifying a max-message-size seems more indicative of not having a max message size. But here that has been defined as meaning 64k. If this usage would be a precedent, I would recommend to not do this. If this is how these things are done in this world, then I guess stick to what has already been done in this space. The table entry in 6.2 lists an email contact for an IANA entry. Why does an IANA entry need someone's email address as contact? IANA entries normally only refer to the RFC's that define them, and people are expected to contact the working group or maybe one of the RFC authors for questions. But putting a name and email address entry here seems to convey some kind of "ownership" of the IANA entry which I think is the wrong thing to do. Section 6.3 As the usage of multiple SCTP associations on top of a single DTLS association is outside the scope of this specification, no mux rules are specified for the 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP' proto values. Why is this out of scope? If there are good reasons not to do it, should it not be defined to MUST NOT? If it is out of scope only for now, then it seems that this document should in fact just specify it so people know how to do it. The way this is phrased seems to leave the thing hanging in midair, and implememters might end up doing different things. Section 7: NOTE: While [I-D.ietf-tsvwg-sctp-dtls-encaps] allows multiple SCTP associations on top of a single DTLS association, the procedures in this specification only support the negotiation of a single SCTP association on top of any given DTLS association. And similar here. Setion 8: Similar issues with "the procedures" and with "is out of scope for this" Section 9.2: This specification does not define semantics for the SDP direction attributes [RFC4566]. Unless semantics of these attributes for an SCTP association usage have been defined, SDP direction attributes MUST be ignored if present. Why are these attributes not defined in this specification? If there are good reasons for it not to have been specified, why not change the language to clearly state these attributes here are invalid and MUST be ignored? If it is possibly these will be defined in the future (which the current text suggest might happen) perhaps that specification really belongs in this document. Nits: Through the document, there are paragraphs that start with "NOTE:". I think those can all be safely removed to increase the readability. Section 1: [I-D.ietf-tsvwg-sctp-dtls-encaps] This looks but is not a proper reference. (eg there is no link) When the 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP' proto values, the m- line fmt value, identifying the application-layer protocol, MUST be registered by IANA. This sentence does not parse. Section 6.1 Line wrapping 'TCP/DTLS/ SCTP' is best avoided. Section 9 Each can be established and closed without impacting others. Should that not be "each other" or "the others" (as opposed to "others" being other things far far away) Section 10.3 [I-D.ietf-mmusic-dtls-sdp] is not a proper reference with link. Section 12 I would rephrase "The text in the paragraph above" as these indirect references make the text harder to read. From nobody Thu Feb 9 19:32:49 2017 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50296129656; Thu, 9 Feb 2017 19:32:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.991 X-Spam-Level: X-Spam-Status: No, score=-1.991 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 XpVunRpmG5i2; Thu, 9 Feb 2017 19:32:41 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 895E7129578; Thu, 9 Feb 2017 19:32:41 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3vKL9g3zFlz3Dh; Fri, 10 Feb 2017 04:32:39 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1486697559; bh=41ItAJCBPu8Y4GNdSkUe64AugKBIen1ZNJ36Nn8rYY0=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=slCOM8j0RCSCK0AZi/mUHPru6llcQWjcW7MumLmWS30EjA+6TzWxr8JKAXYT8owNm F06QC+162aALKyENVP3Tk99IaZUG1CHbAOd5fkw7sSTvFVKKR08WpvT95AqwVS3Q7/ 0Lazuo+v9qV+Pm5ymisq7Wx4PqdvzloHClqiwdwA= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id NlL_y-MJBiUh; Fri, 10 Feb 2017 04:32:37 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 10 Feb 2017 04:32:37 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 1C8292DEFE9; Thu, 9 Feb 2017 22:32:35 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 1C8292DEFE9 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 0473940267E6; Thu, 9 Feb 2017 22:32:34 -0500 (EST) Date: Thu, 9 Feb 2017 22:32:34 -0500 (EST) From: Paul Wouters To: Paul Wouters In-Reply-To: <148669725288.8138.2095744202497272272.idtracker@ietfa.amsl.com> Message-ID: References: <148669725288.8138.2095744202497272272.idtracker@ietfa.amsl.com> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: draft-ietf-mmusic-sctp-sdp.all@ietf.org, ietf@ietf.org, mmusic@ietf.org, secdir Subject: Re: [secdir] Review of draft-ietf-mmusic-sctp-sdp-22 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 03:32:44 -0000 On Thu, 9 Feb 2017, Paul Wouters wrote: > Subject: [secdir] Review of draft-ietf-mmusic-sctp-sdp-22 > > Reviewer: Paul Wouters > Review result: Has Issues ouch. The new secdir review submission using file upload really mangled the whitespace into something unreadable. I've included the original review txt file here inline to make the review readable. Perhaps Tero can investigate what's going on here? Paul 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. [Note that I am not well versed in SCTP] This document defines SDP [RFC4566] protocol identifiers (proto values): 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP'. This specification also specifies how to use the new proto values with the SDP Offer/Answer mechanism [RFC3264] for negotiating SCTP-over-DTLS associations. As this document only defines a method of signaling to use UDP/DTLS/SCTP or UDP/DTLS/SCTP, there are not specific Security Considerations for this document, and the Security Considerations correctly points to the documents that actually implement the UDP/DTLS/SCTP and TCP/DTLS/SCTP protocols. So from a security point of view, this document is Ready. I do have some generic concerns and questions I would like to see addressed: One general issue I have is with the specification of IANA values and punting some of its meaning. Let me quote an example: NOTE: This specification only defines the usage of the SDP 'max- message-size' attribute when associated with an m- line containing one of the following proto values: 'UDP/DTLS/SCTP' or 'TCP/DTLS/ SCTP'. Usage of the attribute with other proto values needs to be defined in a separate specification. This type of constraint is not clear and easilly displayed in an IANA registry if other values are later added to the table. This text is also an example of how througout the document, items are explicitely "this use is unspecified for now but other documents may change that". It would have been better to just simply and clearly state the current specified use, and let future documents handle updating this document appropriately. This language use makes a lot of decisions for implementers unclear as these decisions are punted forward in time without a reference to follow. Section 4.4.1 states: This specification creates an IANA registry for 'association-usage' values. I think this should be specified a little more clearly, similar to the IANA section specification itself. Something like: This specification creates the IANA 'association-usage' registry for SDP Attributes. Section 4.4.2: The table contains an error on the entries (UDP instead of TCP). I would personally change the port parameter value to just "port number for " or "UDP or TCP port number" Section 4.5: I'm unsure if ordering matters, so I am confused by the table ordering in media, proto, port, and the m= line example ordering media, port proto. I'm further confused by the table listing colon's, eg ":" and the m= line not using colons but spaces. And the following a= lines using colons again. Is this an error, or this is my lack of familiarity with the used protocols? Section 5.1: Therefore, if the attribute is not present, the associated m- line MUST be considered invalid. Is it obvious what one must done when the m- line is considered invalid? Section 5.2: Leading zeroes MUST NOT be used. What is the problem with leading zeros? What can go wrong when these are used? Should an implementor be warned about something specific? Section 6.1: An SCTP endpoint MUST NOT send a SCTP user message with a message size that is larger than the maximum size indicated by the peer, as it cannot be assumed that the peer would accept such message. While this tells an implementer what not to do, it does not tell the implementer what to do when this happens on the receiving end. It would be good to specify that here as well so that implementors will be reminded to think of this error handling case. a maximum message size value of zero, it indicates the SCTP endpoint will handle messages of any size, subject to memory capacity etc. I'm personally not a big fan of 0 meaning infinite, but if this is how other related specs are handling these values in this way, I can understand doing it here as well. For instance, not specifying a max-message-size seems more indicative of not having a max message size. But here that has been defined as meaning 64k. If this usage would be a precedent, I would recommend to not do this. If this is how these things are done in this world, then I guess stick to what has already been done in this space. The table entry in 6.2 lists an email contact for an IANA entry. Why does an IANA entry need someone's email address as contact? IANA entries normally only refer to the RFC's that define them, and people are expected to contact the working group or maybe one of the RFC authors for questions. But putting a name and email address entry here seems to convey some kind of "ownership" of the IANA entry which I think is the wrong thing to do. Section 6.3 As the usage of multiple SCTP associations on top of a single DTLS association is outside the scope of this specification, no mux rules are specified for the 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP' proto values. Why is this out of scope? If there are good reasons not to do it, should it not be defined to MUST NOT? If it is out of scope only for now, then it seems that this document should in fact just specify it so people know how to do it. The way this is phrased seems to leave the thing hanging in midair, and implememters might end up doing different things. Section 7: NOTE: While [I-D.ietf-tsvwg-sctp-dtls-encaps] allows multiple SCTP associations on top of a single DTLS association, the procedures in this specification only support the negotiation of a single SCTP association on top of any given DTLS association. And similar here. Setion 8: Similar issues with "the procedures" and with "is out of scope for this" Section 9.2: This specification does not define semantics for the SDP direction attributes [RFC4566]. Unless semantics of these attributes for an SCTP association usage have been defined, SDP direction attributes MUST be ignored if present. Why are these attributes not defined in this specification? If there are good reasons for it not to have been specified, why not change the language to clearly state these attributes here are invalid and MUST be ignored? If it is possibly these will be defined in the future (which the current text suggest might happen) perhaps that specification really belongs in this document. Nits: Through the document, there are paragraphs that start with "NOTE:". I think those can all be safely removed to increase the readability. Section 1: [I-D.ietf-tsvwg-sctp-dtls-encaps] This looks but is not a proper reference. (eg there is no link) When the 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP' proto values, the m- line fmt value, identifying the application-layer protocol, MUST be registered by IANA. This sentence does not parse. Section 6.1 Line wrapping 'TCP/DTLS/ SCTP' is best avoided. Section 9 Each can be established and closed without impacting others. Should that not be "each other" or "the others" (as opposed to "others" being other things far far away) Section 10.3 [I-D.ietf-mmusic-dtls-sdp] is not a proper reference with link. Section 12 I would rephrase "The text in the paragraph above" as these indirect references make the text harder to read. From nobody Thu Feb 9 23:30:15 2017 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A89CB1298A1 for ; Thu, 9 Feb 2017 23:30:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sunet-se.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iRfQmvUGqiki for ; Thu, 9 Feb 2017 23:30:10 -0800 (PST) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::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 A7D8312989F for ; Thu, 9 Feb 2017 23:30:09 -0800 (PST) Received: by mail-lf0-x22f.google.com with SMTP id z134so16289611lff.3 for ; Thu, 09 Feb 2017 23:30:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sunet-se.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=HsST1SPBP0dA13CwhPOTwLmdSt5ekhLArLa+ikab39U=; b=EWkt30lMblwMH5aeCtyU2q3zgrPad2bThF+gS/TTTr9V3aigiiLEKYvxNMe/JWoNOD A5oZ3KsuDj0STycwr6wruh5tjkMFMArYy/wBADnUPR4EwOMLWbZo7t9y00JMqOswV3bX KfqjxbqVtbebyKPWfdMHJSJ3SbnaPBSqPyieZXrQNaOxj++FQeZFQygHCxvb2PGokyYF UhXIurZmFuq+YgoWj+ytbVvSs8Ev1s2QDReaI388RlbeHxVDjlJ725ipy74HP+PSSc7T nAQWfUcF5pBFNTh86LV/CKcbZ1au/uZb+XoNvCbvuE39p9+4MLCS24BerqP+j4Y4uV7T gIDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=HsST1SPBP0dA13CwhPOTwLmdSt5ekhLArLa+ikab39U=; b=mNspvU203PTM8sgTgH1yBitZ04zY+ZDwuQW/6CFpyjz7t89yLcuKjpduqDoOofoF3v Q/4v80yBWkwinMkKZ1OIukKFdHHEbDdjjliHNy9SOktTXh2lLIFobD/jQUPevYIx0XsR IlSg1C+VPip6YIebsmAMOiiOSfx+mGhl5hAv+XtdrDtJ+cXwgdvxNzHFSWhNsFkOtOwl jx96u6sI5SRzEz0ogViFkEl2NbIbYcOn7h9NW9E/Ysj07xgZ5JercPDrND1rDKtZGy4R A6Umdzqf6XH5MDEEFG0xJKooTDWUU342d+wn1DbwvSwnxRE5UAVH/gni+fK7KQbaWJiC cnxQ== X-Gm-Message-State: AMke39lEQir326Ijay3fwjcOqnywyHvnij7piD7diIeA7xKG6+LJ9NgZPDVx40tDR/U4WQ== X-Received: by 10.46.81.18 with SMTP id f18mr2541057ljb.62.1486711807260; Thu, 09 Feb 2017 23:30:07 -0800 (PST) Received: from ?IPv6:2001:6b0:7:1:21ce:ce98:e81d:99fe? ([2001:6b0:7:1:21ce:ce98:e81d:99fe]) by smtp.gmail.com with ESMTPSA id h23sm254597lji.34.2017.02.09.23.30.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Feb 2017 23:30:06 -0800 (PST) To: secdir@ietf.org, draft-ietf-teas-p2mp-loose-path-reopt.all@ietf.org, iesg@ietf.org From: Leif Johansson Message-ID: <36116fa6-2670-c0b2-3a4f-b72107bfbc82@sunet.se> Date: Fri, 10 Feb 2017 08:30:04 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [secdir] secdir review draft-ietf-teas-p2mp-loose-path-reopt-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 07:30:12 -0000 Reviewer: Leif Johansson Review result: Minor issues I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The draft describes a way to handle groupings of large sets of sub- LSPs in a P2MP GMPLS setup for the purpose of traffic engineering (re-)optimization by introducing the concept of "fragment identifiers" Let me state up front that the topic is outside my normal area of expertise. My only question is this: could an attacker fake messages that would (to the receiver ingress node) appear to be part of a fragmented group of sub-LSPs so as to trigger a full re-computation of the tree? The text in the last but one paragraph of 4.2 would seem to suggest that this attack is a possibility. At "worst" this would be a denial-of-service attack but it should perhaps be addressed in the security considerations section anyway. Cheers Leif From nobody Fri Feb 10 04:54:35 2017 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D92B11295B2; Fri, 10 Feb 2017 04:54:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 6degDeecsNx0; Fri, 10 Feb 2017 04:54:28 -0800 (PST) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C94F128E19; Fri, 10 Feb 2017 04:54:28 -0800 (PST) Received: by mail-oi0-x229.google.com with SMTP id u143so20021014oif.3; Fri, 10 Feb 2017 04:54:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2aE0LWbmVSUdiF7Y19fFS3A1wXWf7VlNn0B/EGdOJ64=; b=FRWbZhUj/oWRZ+61BvY3dPjIsiy1owH7B8gb7WyfqlUWEGt8g2oL9L1g9A2nioG9MR dRHEhEOto3e2Rwcdb7C7NOwHiEWEribbK1bk9bwSnJbpXJXDsixGndYeG2jZqJP568Xp 3Nk+L7t+vDUXom6Hq7dqDN+rWmyPYXR3ALQTt2y+C5YiJM1RqvmJ4C55jb+UvCTm5zAJ ARnDW6icM6SBCf+tCriytbAzi/maxAQKcb8ZGL/uFTiwFLwGEW84o0aHfhU1grEqAldr I0uzqw5SFcXoVUYOhqrki6Jw1yTFtlDtPzMoHXx3KbtVYon0/1EOVY4MMlE6BqRLFpTt SgOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2aE0LWbmVSUdiF7Y19fFS3A1wXWf7VlNn0B/EGdOJ64=; b=JiYznS+i9kKdFS4K7t6yeht0F5ubPmhz2OfjsHtabvg+uOBFg8dbZ281u6jWh85c1h XNG4ZPHzi80XgmTo1+vD4otCVaCJbbUylJXHyCf15dHny2yD/TETBih61gMpYxbdcTYy CxYgmmw/+98U3GFEJM20DrsSbzN14oSuxf6ghfoOnRpo9Q7J+ag3gq0Uh1si0bjnBewL B15h3o7RAstihhVvnI3B0r3jT+Rd6GkTrc0xsnSn4oFpmZVMoDy6+HopDDKC2VvSzYtm neFWuNReoEJx3Zmc2eO5DuLMYGVelvPIml9ykIk7jZwJzBsnfD09WCxfmXMQkSpB+l72 2TYQ== X-Gm-Message-State: AMke39k90J9AzoIhFBqZrCaD3SSdwFdXDNoFC+japRtcsy3akufyXw/PAJ6wmucoR/bUYpRVZ4PKF45lBmPEkw== X-Received: by 10.202.219.9 with SMTP id s9mr4772561oig.88.1486731267824; Fri, 10 Feb 2017 04:54:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.1.202 with HTTP; Fri, 10 Feb 2017 04:53:47 -0800 (PST) In-Reply-To: <201702092050.v19Ko9mi018578@rumpleteazer.rhmr.com> References: <201702092050.v19Ko9mi018578@rumpleteazer.rhmr.com> From: tianxiang li Date: Fri, 10 Feb 2017 20:53:47 +0800 Message-ID: To: Hilarie Orman Content-Type: multipart/alternative; boundary=001a113d3d2e1861ae05482c9917 Archived-At: Cc: draft-ietf-dhc-dhcpv6-prefix-length-hint-issue.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Security review of draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 12:54:30 -0000 --001a113d3d2e1861ae05482c9917 Content-Type: text/plain; charset=UTF-8 Hi Hilarie, Thank you for the review, please see inline. Cheers, Tianxiang 2017-02-10 4:50 GMT+08:00 Hilarie Orman : > Security review of DHCPv6 Prefix Length Hint Issues > draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-05 > > Do not be alarmed. I have reviewed this document as part of the > security directorate's ongoing effort to review all IETF documents > being processed by the IESG. These comments were written primarily > for the benefit of the security area directors. Document editors and > WG chairs should treat these comments just like any other last call > comments. > > The document gives advice on how servers and clients can handle DHCP cases > in which the client requests a particular prefix length and the server > cannot exactly match it. > > This statement is very difficult to interpret: > "the server SHOULD provide the prefix with the shortest length > possible which is closest to the prefix-length hint value." > This alternative in section 3.6 makes more sense: > "assign a prefix of at least the hint length (or shorter) if one is > available." > > [Tianxiang]Thanks for pointing that out, the sentence in section 3.2 is a bit confusing, we could change it as follow: OLD: ... the server SHOULD try to provide a prefix matching the prefix-length value, or the prefix with the shortest length possible which is closest to the prefix-length hint value." NEW: ...the server SHOULD provide a prefix matching the prefix-length hint, or a prefix which is length is shorter and as close as possible to the prefix-length hint. > I do not see any obvious security flaws, but my opinion is tempered by > the lack of prior discussion. The security considerations refer to > RFC3633 "IPv6 Prefix Options for DHCPv6", and that refers to ongoing > development of IPsec for DHCPv6. As nearly as I can tell, that work > was never done. That makes it difficult to have confidence in the "no > new security considerations" claim. > > [Tianxiang] Do you have some suggestions as to how we should address this issue? I think one solution would be to change the Security Considerations section as follow: OLD: This document introduces no new security considerations over those already discussed in section 15 of RFC3633, as this document provides guidance on how the clients and servers interact with regard to the prefix-length hint mechanism introduced in RFC3633. NEW: This document provides guidance on how the clients and servers interact with regard to the prefix-length hint mechanism introduced in RFC3633, security considerations regarding DHCPv6 prefix delegation are described in section 15 of RFC 3633. > Some nits: > > Remove the comma in the first sentence of the introduction. > > "prefix which length" should be "prefix with length" or possibly > "prefix whose length". > > "The servers usually has a record" should be "The server usually has a > record". > > No comma in "When the client wants the same prefix back from the > server, and would prefer ...". > > [Tianxiang] Thank you, we will change this accordingly. > Hilarie > --001a113d3d2e1861ae05482c9917 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Hilarie,

Thank you for the review, p= lease see inline.

Cheers,
Tianxiang

2017-02-10 4:50 = GMT+08:00 Hilarie Orman <hilarie@purplestreak.com>:
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0Security review of DHCPv6 Prefix Length Hint Issues
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-ietf-dhc-dhcpv6-prefix-length= -hint-issue-05

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

The document gives advice on how servers and clients can handle DHCP cases<= br> in which the client requests a particular prefix length and the server
cannot exactly match it.

This statement is very difficult to interpret:
"the server SHOULD provide the prefix with the shortest length
=C2=A0 =C2=A0possible which is closest to the prefix-length hint value.&quo= t;
This alternative in section 3.6 makes more sense:
"assign a prefix of at least the hint length (or shorter) if one is =C2=A0 =C2=A0available."

[Tianxiang]Thanks for pointing that out, the sentence= in section 3.2 is a bit confusing, we could change it as follow:

OLD: ... the server SHOULD try to provide a prefix matching= the prefix-length value, or the prefix with the shortest length possible w= hich is closest to the prefix-length hint value."=C2=A0

=
NEW: ...the server SHOULD provide a prefix matching the prefix-l= ength hint, or a prefix which is length is shorter and as close as possible= to the prefix-length hint.=C2=A0
=C2=A0
I do not see any obvious security flaws, but my opinion is tempered by
the lack of prior discussion.=C2=A0 The security considerations refer to RFC3633 "IPv6 Prefix Options for DHCPv6", and that refers to ongo= ing
development of IPsec for DHCPv6.=C2=A0 As nearly as I can tell, that work was never done.=C2=A0 That makes it difficult to have confidence in the &qu= ot;no
new security considerations" claim.

[Tianxiang] Do you have some suggestions as to how we= should address this issue? I think one solution would be to change the Sec= urity Considerations section as follow:

OLD: = This document introduces no new security considerations over those already = discussed in section 15 of RFC3633, as this document provides guidance on h= ow the clients and servers interact with regard to the prefix-length hint m= echanism introduced in RFC3633.

NEW: This document= provides guidance on how the clients and servers interact with regard to t= he prefix-length hint mechanism introduced in RFC3633, security considerati= ons regarding DHCPv6 prefix delegation are described in section 15 of RFC 3= 633.
=C2=A0
Some nits:

Remove the comma in the first sentence of the introduction.

"prefix which length" should be "prefix with length" or= possibly
"prefix whose length".

"The servers usually has a record" should be "The server usu= ally has a record".

No comma in "When the client wants the same prefix back from the
server, and would prefer ...".
=
[Tianxiang] Thank you, we will change t= his accordingly.
=C2=A0
Hilarie

--001a113d3d2e1861ae05482c9917-- From nobody Fri Feb 10 05:28:21 2017 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3F4A1296F8; Fri, 10 Feb 2017 05:28:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0_92M2h_Rg-j; Fri, 10 Feb 2017 05:28:16 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C95A61298D9; Fri, 10 Feb 2017 05:28:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2218; q=dns/txt; s=iport; t=1486733295; x=1487942895; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=yZ1WUuHHUftnD9EWl/5O4QA1Q8BOW5DKR+aUeugDNCE=; b=YFxVzQyZIQmE1/Hd2Ay5RVlUJhMV548ZfDMBNsNYxXZqbPQElhQoR4Iv SGCrRs1AnLIaMXK0nhOzk38abBEe1MHX55rQUGhlWi0pl81tmE1HRp7lE EAHo9k+Pw/2+3YchZAoylDjvM/jzgqMewxLMFyV0P9UZXhBgl4W1I1g5z g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CFAQCJv51Y/5BdJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1KBageDUooIp0KCDYYiAhqCXD8YAQIBAQEBAQEBYiiEagYjETc?= =?us-ascii?q?eAgEGAhoCJgICAjAVEAIEARKJeJIPnU6CJYtUAQEBAQEBAQEBAQEBAQEBAQEBI?= =?us-ascii?q?IELhUGCBYJqhFQXgm8ugjEBBJtyAZITkQWTFAEfOH5PFU0BhDIdgWF1iRKBDAE?= =?us-ascii?q?BAQ?= X-IronPort-AV: E=Sophos;i="5.35,141,1484006400"; d="scan'208";a="179082421" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Feb 2017 13:28:00 +0000 Received: from XCH-ALN-018.cisco.com (xch-aln-018.cisco.com [173.36.7.28]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v1ADS0Cn032125 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 10 Feb 2017 13:28:00 GMT Received: from xch-aln-018.cisco.com (173.36.7.28) by XCH-ALN-018.cisco.com (173.36.7.28) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 10 Feb 2017 07:28:00 -0600 Received: from xch-aln-018.cisco.com ([173.36.7.28]) by XCH-ALN-018.cisco.com ([173.36.7.28]) with mapi id 15.00.1210.000; Fri, 10 Feb 2017 07:28:00 -0600 From: "Rakesh Gandhi (rgandhi)" To: Leif Johansson , "secdir@ietf.org" , "draft-ietf-teas-p2mp-loose-path-reopt.all@ietf.org" , "iesg@ietf.org" Thread-Topic: secdir review draft-ietf-teas-p2mp-loose-path-reopt-08 Thread-Index: AQHSg3BeCgs9ReovyU+ah1HabloPmqFiTOCA Date: Fri, 10 Feb 2017 13:28:00 +0000 Message-ID: <4CCAD7DC-173A-41E9-A22B-E87A05CFC07B@cisco.com> References: <36116fa6-2670-c0b2-3a4f-b72107bfbc82@sunet.se> In-Reply-To: <36116fa6-2670-c0b2-3a4f-b72107bfbc82@sunet.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1d.0.161209 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.246.247] Content-Type: text/plain; charset="utf-8" Content-ID: <5F5B462C160F1644BB61641AD77F82E5@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] secdir review draft-ietf-teas-p2mp-loose-path-reopt-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 13:28:17 -0000 SGkgTGVpZiwNCg0KVGhhbmsgeW91IGZvciB0aGUgcmV2aWV3IG9mIHRoZSBkb2N1bWVudC4gDQoN ClJGQyA0NzM2IChiYXNpcyBmb3IgdGhpcyBkb2N1bWVudCksIFNlY3VyaXR5IFNlY3Rpb24gOSwg aGFzIGNvdmVyYWdlIGZvciB0aGlzIGFzcGVjdCDigJMg4oCcRnVydGhlcm1vcmUsIGEgaGVhZC1l bmQgTFNSIG1heSBkZWNpZGUgdG8gaWdub3JlIGV4cGxpY2l0IG5vdGlmaWNhdGlvbiBjb21pbmcg ZnJvbSBhIG1pZC1wb2ludCByZXNpZGluZyBpbiBhbm90aGVyIGRvbWFpbi7igJ0NCg0KVGhhbmtz LA0KUmFrZXNoDQoNCg0KT24gMjAxNy0wMi0xMCwgMjozMCBBTSwgIkxlaWYgSm9oYW5zc29uIiA8 bGVpZmpAc3VuZXQuc2U+IHdyb3RlOg0KDQogICAgDQogICAgUmV2aWV3ZXI6IExlaWYgSm9oYW5z c29uDQogICAgUmV2aWV3IHJlc3VsdDogTWlub3IgaXNzdWVzDQogICAgDQogICAgSSBoYXZlIHJl dmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgc2VjdXJpdHkgZGlyZWN0b3JhdGUn cw0KICAgIG9uZ29pbmcgZWZmb3J0IHRvIHJldmlldyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcg cHJvY2Vzc2VkIGJ5IHRoZQ0KICAgIElFU0cuICBUaGVzZSBjb21tZW50cyB3ZXJlIHdyaXR0ZW4g cHJpbWFyaWx5IGZvciB0aGUgYmVuZWZpdCBvZiB0aGUNCiAgICBzZWN1cml0eSBhcmVhIGRpcmVj dG9ycy4gIERvY3VtZW50IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBzaG91bGQgdHJlYXQNCiAgICB0 aGVzZSBjb21tZW50cyBqdXN0IGxpa2UgYW55IG90aGVyIGxhc3QgY2FsbCBjb21tZW50cy4NCiAg ICANCiAgICBUaGUgZHJhZnQgZGVzY3JpYmVzIGEgd2F5IHRvIGhhbmRsZSBncm91cGluZ3Mgb2Yg bGFyZ2Ugc2V0cyBvZiBzdWItDQogICAgTFNQcyBpbiBhIFAyTVAgR01QTFMgc2V0dXAgZm9yIHRo ZSBwdXJwb3NlIG9mIHRyYWZmaWMgZW5naW5lZXJpbmcNCiAgICAocmUtKW9wdGltaXphdGlvbiBi eSBpbnRyb2R1Y2luZyB0aGUgY29uY2VwdCBvZiAiZnJhZ21lbnQgaWRlbnRpZmllcnMiDQogICAg DQogICAgTGV0IG1lIHN0YXRlIHVwIGZyb250IHRoYXQgdGhlIHRvcGljIGlzIG91dHNpZGUgbXkg bm9ybWFsIGFyZWEgb2YNCiAgICBleHBlcnRpc2UuIE15IG9ubHkgcXVlc3Rpb24gaXMgdGhpczog Y291bGQgYW4gYXR0YWNrZXIgZmFrZSBtZXNzYWdlcw0KICAgIHRoYXQgd291bGQgKHRvIHRoZSBy ZWNlaXZlciBpbmdyZXNzIG5vZGUpIGFwcGVhciB0byBiZSBwYXJ0IG9mIGENCiAgICBmcmFnbWVu dGVkIGdyb3VwIG9mIHN1Yi1MU1BzIHNvIGFzIHRvIHRyaWdnZXIgYSBmdWxsIHJlLWNvbXB1dGF0 aW9uDQogICAgb2YgdGhlIHRyZWU/IFRoZSB0ZXh0IGluIHRoZSBsYXN0IGJ1dCBvbmUgcGFyYWdy YXBoIG9mIDQuMiB3b3VsZA0KICAgIHNlZW0gdG8gc3VnZ2VzdCB0aGF0IHRoaXMgYXR0YWNrIGlz IGEgcG9zc2liaWxpdHkuIEF0ICJ3b3JzdCIgdGhpcw0KICAgIHdvdWxkIGJlIGEgZGVuaWFsLW9m LXNlcnZpY2UgYXR0YWNrIGJ1dCBpdCBzaG91bGQgcGVyaGFwcyBiZSBhZGRyZXNzZWQNCiAgICBp biB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2VjdGlvbiBhbnl3YXkuDQogICAgCQ0KICAg IAlDaGVlcnMgTGVpZg0KICAgIA0KDQo= From nobody Fri Feb 10 06:15:32 2017 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B22C0129965; Fri, 10 Feb 2017 06:15:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j6RUWTahSP87; Fri, 10 Feb 2017 06:15:29 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 1A3B812988A; Fri, 10 Feb 2017 06:15:28 -0800 (PST) X-AuditID: c1b4fb2d-2a63298000001743-e6-589dcaff6922 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by (Symantec Mail Security) with SMTP id E3.7D.05955.FFACD985; Fri, 10 Feb 2017 15:15:27 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0319.002; Fri, 10 Feb 2017 15:15:26 +0100 From: Christer Holmberg To: Paul Wouters , Paul Wouters Thread-Topic: [secdir] Review of draft-ietf-mmusic-sctp-sdp-22 Thread-Index: AQHSg02fz09JgsaxQEyJwWweq6l2mKFhhUMAgADVvIA= Date: Fri, 10 Feb 2017 14:15:25 +0000 Message-ID: References: <148669725288.8138.2095744202497272272.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="Windows-1252" Content-ID: <055BCFB29D6093489DCA3E1D4B0D75A4@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKIsWRmVeSWpSXmKPExsUyM2K7tO7/U3MjDF6+FbXY1L+JxeLZxvks FlOXP2axeH/rEpPFyX33mCw+LHzI4sDmsWTJTyaP7/OYPN7vu8oWwBzFZZOSmpNZllqkb5fA lXFqW1LBRf+KW/dOMzUwvrHrYuTkkBAwkdj47Dk7iC0ksI5R4uhili5GLiB7MaPEh/e3gRIc HGwCFhLd/7RBakQEXCX27r0BVsMssJtR4tmR/WA1wgK2Eqe/KUDU2Ek0z/7ABhIWEbCSaJtp DBJmEVCVaGnqZAGxeQWsJaadf8cMsaqZUWLyheNgYzgFHCW6tuSA1DAKiEl8P7WGCcRmFhCX uPVkPhPEyQISS/acZ4awRSVePv7HCmKLCuhJLH++BiquKPHx1T5GiF4Diffn5jND2NYSa3q3 QtnaEssWvmaGuEdQ4uTMJywTGMVnIVk3C0n7LCTts5C0z0LSvoCRdRWjaHFqcXFuupGxXmpR ZnJxcX6eXl5qySZGYGQe3PJbdwfj6teOhxgFOBiVeHg/NM+JEGJNLCuuzD3EKMHBrCTCO+HQ 3Agh3pTEyqrUovz4otKc1OJDjNIcLErivGYr74cLCaQnlqRmp6YWpBbBZJk4OKUaGJ0u14dN ND6qEuCYlvO5ailXp83By51hKZEtT5a0SHWt4Tx13/1z9c/frH4p387kJ67RX/M84m/Lk4lv mN5IxynNKkva6DbRchL7RomU7jT/6ZdYXnx83qn4pviTuW/Ox6OuytMy/r81fS3a/0uy8ftW ty+/oxsaWdcuS9JaU1z35MGnBRH8DUosxRmJhlrMRcWJAE9Mpl7IAgAA Archived-At: Cc: "draft-ietf-mmusic-sctp-sdp.all@ietf.org" , "ietf@ietf.org" , "mmusic@ietf.org" , secdir Subject: Re: [secdir] Review of draft-ietf-mmusic-sctp-sdp-22 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 14:15:32 -0000 Hi Paul, Thanks for your review! Please see inline. ... >This document defines SDP [RFC4566] protocol identifiers (proto values): >'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP'. This specification also specifies >how to use the new proto values with the SDP Offer/Answer mechanism >[RFC3264] for negotiating SCTP-over-DTLS associations. > >As this document only defines a method of signaling to use UDP/DTLS/SCTP >or UDP/DTLS/SCTP, there are not specific Security Considerations for this >document, and the Security Considerations correctly points to the >documents >that actually implement the UDP/DTLS/SCTP and TCP/DTLS/SCTP protocols. > >So from a security point of view, this document is Ready. Thanks! ---- >I do have some generic concerns and questions I would like to see >addressed: > >One general issue I have is with the specification of IANA values and >punting >some of its meaning. Let me quote an example: > > NOTE: This specification only defines the usage of the SDP 'max- > message-size' attribute when associated with an m- line containing > one of the following proto values: 'UDP/DTLS/SCTP' or 'TCP/DTLS/ > SCTP'. Usage of the attribute with other proto values needs to be > defined in a separate specification. > >This type of constraint is not clear and easilly displayed in an IANA >registry if >other values are later added to the table. This text is also an example >of how >througout the document, items are explicitely "this use is unspecified >for now >but other documents may change that". It would have been better to just >simply >and clearly state the current specified use, and let future documents >handle >updating this document appropriately. This language use makes a lot of >decisions >for implementers unclear as these decisions are punted forward in time >without >a reference to follow. I think the idea is that if someone wants to define the usage for other proto values he/she does not need to update THIS specification, as it already allows it. ---- >Section 4.4.1 states: > > This specification creates an IANA registry for 'association-usage' >values. > >I think this should be specified a little more clearly, similar to the >IANA section >specification itself. Something like: > > This specification creates the IANA 'association-usage' registry for >SDP Attributes. We are discussing this with IANA, so the text will be aligned. ---- >Section 4.4.2: > >The table contains an error on the entries (UDP instead of TCP). Correct. That was noted also by the AD. ---- > I would personally change the port parameter value to just "port number >for " or "UDP or TCP port number" People wanted to have the proto values explicitly stated, so I=B9d like to keep them. ---- >Section 4.5: > >I'm unsure if ordering matters, so I am confused by the table ordering in >media, proto, port, >and the m=3D line example ordering media, port proto. I obivously can=B9t change the order in the m=3D line, but I can change the order of and in the table, if you think that make things more clear. ---- >I'm further confused by the table listing colon's, eg ":" and the >m=3D line not >using colons but spaces. And the following a=3D lines using colons again. >Is this an error, >or this is my lack of familiarity with the used protocols? I honestly have no idea why the colones are there (probably a copy/paste error). I can remove them. ---- >Section 5.1: > > Therefore, if the attribute is not present, the associated m- line MUST >be considered invalid. > >Is it obvious what one must done when the m- line is considered invalid? I could add =B3, and MUST NOT be used to establish an SCTP-over-DTLS association." ---- >Section 5.2: > > Leading zeroes MUST NOT be used. > >What is the problem with leading zeros? What can go wrong when these are >used? Should >an implementor be warned about something specific? I don=B9t know. The same statement exists for a number of SDP attributes, but I didn=B9t find any justification. ---- >Section 6.1: > > An SCTP endpoint MUST NOT send a SCTP user message with a message > size that is larger than the maximum size indicated by the peer, as > it cannot be assumed that the peer would accept such message. > >While this tells an implementer what not to do, it does not tell the >implementer >what to do when this happens on the receiving end. It would be good to >specify >that here as well so that implementors will be reminded to think of this >error >handling case. I am not sure whether it=B9s within the scope of this document to say what SCTP endpoints do if they receive SCTP user messages that are too big for them to handle. > a maximum message size value of zero, it indicates the SCTP endpoint >will handle > messages of any size, subject to memory capacity etc. > >I'm personally not a big fan of 0 meaning infinite, but if this is how >other related >specs are handling these values in this way, I can understand doing it >here as well. >For instance, not specifying a max-message-size seems more indicative of >not having >a max message size. But here that has been defined as meaning 64k. If >this usage >would be a precedent, I would recommend to not do this. If this is how >these things >are done in this world, then I guess stick to what has already been done >in this space. I don=B9t know how things are normally done, because the only other SDP attribute I can think of providing similar information is =8Cmax-size=B9 (R= FC 4975), but it does not define a default value, nor a infinite value. >The table entry in 6.2 lists an email contact for an IANA entry. Why does >an IANA >entry need someone's email address as contact? IANA entries normally only >refer to >the RFC's that define them, and people are expected to contact the >working group >or maybe one of the RFC authors for questions. But putting a name and >email address >entry here seems to convey some kind of "ownership" of the IANA entry >which I think >is the wrong thing to do. You=B9ll have to ask IANA about that :) The e-mail address is within the template that has to be filled. Keep in mind, though, that IANA entries are not always defined in RFCs. For example, a number of registrations have been provided by 3GPP. ---- >Section 6.3 > > As the usage of multiple SCTP associations on top of a single DTLS > association is outside the scope of this specification, no mux rules > are specified for the 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP' proto > values. > >Why is this out of scope? If there are good reasons not to do it, should >it not >be defined to MUST NOT? If it is out of scope only for now, then it seems >that >this document should in fact just specify it so people know how to do it. >The >way this is phrased seems to leave the thing hanging in midair, and >implememters >might end up doing different things. In order to allow multiple SCTP associations, you would have to be able to provide multiple SCTP ports, and somehow associate those with each association. We decided not to do that. But, I don=B9t think we want to forbid people from establishing multiple SCTP associations - this spec just doesn=B9t support using SDP offer/answer for negotiating multiple associations. ---- >Section 7: > > NOTE: While [I-D.ietf-tsvwg-sctp-dtls-encaps] allows multiple SCTP > associations on top of a single DTLS association, the procedures in > this specification only support the negotiation of a single SCTP > association on top of any given DTLS association. > >And similar here. See above. ---- >Setion 8: > >Similar issues with "the procedures" and with "is out of scope for this" > >Section 9.2: > > This specification does not define semantics for the SDP direction > attributes [RFC4566]. Unless semantics of these attributes for an > SCTP association usage have been defined, SDP direction attributes > MUST be ignored if present. > >Why are these attributes not defined in this specification? If there are >good >reasons for it not to have been specified, why not change the language to >clearly state these attributes here are invalid and MUST be ignored? If it >is possibly these will be defined in the future (which the current text >suggest might happen) perhaps that specification really belongs in this >document. The direction attributes are not used for transports. They are used for =B3applications=B2, e.g, RTP. But, as nobody has indicated any interest of defining RTP-over-SCTP-over-DTLS, there is no idea to define how the direction attributes would be used. ---- Nits: >Through the document, there are paragraphs that start with "NOTE:". I >think >those can all be safely removed to increase the readability. Ok, I=B9ll look into that. ---- >Section 1: > > [I-D.ietf-tsvwg-sctp-dtls-encaps] > >This looks but is not a proper reference. (eg there is no link) > > When the 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP' proto values, the m- > line fmt value, identifying the application-layer protocol, MUST be > registered by IANA. > >This sentence does not parse. > > >Section 6.1 > >Line wrapping 'TCP/DTLS/ > SCTP' is best avoided. I=B9ll fix that. ---- >Section 9 > > Each can be established and closed without impacting others. > >Should that not be "each other" or "the others" (as opposed to "others" >being other things far far away) I=B9ll change to =B3the others=B2. ---- >Section 10.3 > >[I-D.ietf-mmusic-dtls-sdp] is not a proper reference with link. I=B9ll look into that. ---- >Section 12 > >I would rephrase "The text in the paragraph above" as these indirect >references make the text harder >to read. I could remove the first sentence, and keep the second: "If ICE is not used, the proto value MUST always reflect the transport protocol used at any given time." Regards, Christer From nobody Fri Feb 10 06:22:18 2017 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76A9E128B38 for ; Fri, 10 Feb 2017 06:22:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sunet-se.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ya6P0VVKrswg for ; Fri, 10 Feb 2017 06:22:16 -0800 (PST) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::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 C9059129965 for ; Fri, 10 Feb 2017 06:22:15 -0800 (PST) Received: by mail-lf0-x22f.google.com with SMTP id v186so22203351lfa.1 for ; Fri, 10 Feb 2017 06:22:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sunet-se.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=Zz4hxarfAOqbaDCRoetP3YUP9U00ZIor+Xd+tmCL/PM=; b=G3zh+DOTdvejknoZY8HEAKA02x8qRgrn2oLqG4mhCfbXJn7MeqK6AdWu1jOTk2ky92 BWFXlgtgmVX20pudZ96vRCkoeN9oquLF3oBngBhQ3XzX9s9UEJNojOf6/n0Pwf1ymXcO XDDZUD8/A766zuXyApafN878JXzo3VISHRFR1MqPlYy1BO9rxFz9xGRKCWlh2g5tEYPV rwEgXfnWu2Xh603Y2Kw4mYG2zLlQGfRRWMlD4d629OTsfSKtOLkB0wbXVdFKkLuu4TKW 1dO/hn2AgVs2xx8ndgX+OEV0YfbeY0WKIWKPYMv8qS2GMUdE7ukfnZWeuRitUQDvfejL 8udQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=Zz4hxarfAOqbaDCRoetP3YUP9U00ZIor+Xd+tmCL/PM=; b=A/f2MqKAYt1pi5nZYDVJRt7w/sMf3Bpv8jtUBqwxwK1xb4B7OF9gnZQyHGLooyVKgU OdlCDbQjNbJeWgls2VUfdBdTIVZeClLSiY9YS4CpRt2I+U4/yWHccBZHmnTl7M6s9tEk 5AyuyeNwFl2Bocm4z1dwsl+qih2y59oeHl/FAuOwDusp/WJLEO7auQZwm6AKWUVwZbui 9crCTsfVVBtcnWcqIOaA2G8Sq9DuB0y4Ch9MDYIdltZeEWB4uOANG5TLTihDpI6q7p8B i3dkfQEBxfSb0LBq976PQf9k/u+DY3cTKu4XEROYPAxoczu04pPlEJBlx2EM3ExjvRLF 43Mw== X-Gm-Message-State: AMke39kY7TlJodCIxcL0yvTVmF1i0iY66MdAMujSCwlgGzc3spzLbZUiVGxC/BuDkWBYow== X-Received: by 10.25.200.65 with SMTP id y62mr3229876lff.132.1486736533800; Fri, 10 Feb 2017 06:22:13 -0800 (PST) Received: from ?IPv6:2001:6b0:7:1:5d5e:1119:da9a:e72a? ([2001:6b0:7:1:5d5e:1119:da9a:e72a]) by smtp.gmail.com with ESMTPSA id 70sm592776lfq.14.2017.02.10.06.22.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Feb 2017 06:22:13 -0800 (PST) To: "Rakesh Gandhi (rgandhi)" , "secdir@ietf.org" , "draft-ietf-teas-p2mp-loose-path-reopt.all@ietf.org" , "iesg@ietf.org" References: <36116fa6-2670-c0b2-3a4f-b72107bfbc82@sunet.se> <4CCAD7DC-173A-41E9-A22B-E87A05CFC07B@cisco.com> From: Leif Johansson Message-ID: <4ba99af5-c23f-c521-9ec0-72aa642e47f7@sunet.se> Date: Fri, 10 Feb 2017 15:22:12 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <4CCAD7DC-173A-41E9-A22B-E87A05CFC07B@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [secdir] secdir review draft-ietf-teas-p2mp-loose-path-reopt-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 14:22:17 -0000 On 2017-02-10 14:28, Rakesh Gandhi (rgandhi) wrote: > Hi Leif, > > Thank you for the review of the document. > > RFC 4736 (basis for this document), Security Section 9, has coverage for this aspect – “Furthermore, a head-end LSR may decide to ignore explicit notification coming from a mid-point residing in another domain.” > Ah ok so trust is placed in the domain? I guess that property is something that could be made explicit in the security considerations (or maybe its obvious to people in the field) > Thanks, > Rakesh > > > On 2017-02-10, 2:30 AM, "Leif Johansson" wrote: > > > Reviewer: Leif Johansson > Review result: Minor issues > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > The draft describes a way to handle groupings of large sets of sub- > LSPs in a P2MP GMPLS setup for the purpose of traffic engineering > (re-)optimization by introducing the concept of "fragment identifiers" > > Let me state up front that the topic is outside my normal area of > expertise. My only question is this: could an attacker fake messages > that would (to the receiver ingress node) appear to be part of a > fragmented group of sub-LSPs so as to trigger a full re-computation > of the tree? The text in the last but one paragraph of 4.2 would > seem to suggest that this attack is a possibility. At "worst" this > would be a denial-of-service attack but it should perhaps be addressed > in the security considerations section anyway. > > Cheers Leif > > From nobody Fri Feb 10 06:43:34 2017 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE62B129995; Fri, 10 Feb 2017 06:43:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zjCM9qKzaq3K; Fri, 10 Feb 2017 06:43:30 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4325712998D; Fri, 10 Feb 2017 06:43:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3268; q=dns/txt; s=iport; t=1486737810; x=1487947410; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Hh26+b5hIDhuxcTH5LEZcltWCf1r3+zlP0HiYyySj3A=; b=REKXwUFDUk/lGE2IZg2/xP8J6aoheJhAvSmvNx0m2b/eGC2B7rDqiIpx HUgmUojnKyVPdJ8irFJPfK6S5cvqtU5Up4du5A6MaFHA8UYXFqvYXu6Na ALCejEbjmRiZ27UyDuw6o1FSGBMk+HXdhjzjny0GwDY6+h+g1EwX48myC 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BWAQAS0Z1Y/40NJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1KBageDUooIkgyVNoINhiICGoJdPxgBAgEBAQEBAQFiKIRpAQE?= =?us-ascii?q?BAwEjETceAgEGAhgCAiYCAgIwFRACBAESiXAIkhadToIli1EBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEdgQuFQYIFgmqEVBcjgkwugjEBBJtyAZITgXuFF4lzkxQBHzh?= =?us-ascii?q?+TxVNAYQyHYFhdYkSgQwBAQE?= X-IronPort-AV: E=Sophos;i="5.35,141,1484006400"; d="scan'208";a="179109116" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Feb 2017 14:43:29 +0000 Received: from XCH-ALN-018.cisco.com (xch-aln-018.cisco.com [173.36.7.28]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v1AEhTD4028951 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 10 Feb 2017 14:43:29 GMT Received: from xch-aln-018.cisco.com (173.36.7.28) by XCH-ALN-018.cisco.com (173.36.7.28) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 10 Feb 2017 08:43:28 -0600 Received: from xch-aln-018.cisco.com ([173.36.7.28]) by XCH-ALN-018.cisco.com ([173.36.7.28]) with mapi id 15.00.1210.000; Fri, 10 Feb 2017 08:43:28 -0600 From: "Rakesh Gandhi (rgandhi)" To: Leif Johansson , "secdir@ietf.org" , "draft-ietf-teas-p2mp-loose-path-reopt.all@ietf.org" , "iesg@ietf.org" Thread-Topic: secdir review draft-ietf-teas-p2mp-loose-path-reopt-08 Thread-Index: AQHSg3BeCgs9ReovyU+ah1HabloPmqFiTOCAgABi+AD//7IegA== Date: Fri, 10 Feb 2017 14:43:28 +0000 Message-ID: References: <36116fa6-2670-c0b2-3a4f-b72107bfbc82@sunet.se> <4CCAD7DC-173A-41E9-A22B-E87A05CFC07B@cisco.com> <4ba99af5-c23f-c521-9ec0-72aa642e47f7@sunet.se> In-Reply-To: <4ba99af5-c23f-c521-9ec0-72aa642e47f7@sunet.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1d.0.161209 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.246.247] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] secdir review draft-ietf-teas-p2mp-loose-path-reopt-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 14:43:32 -0000 SGkgTGVpZiwNCg0KVGhhbmtzIGZvciB5b3VyIHJlcGx5LiBQbGVhc2Ugc2VlIGlubGluZSA8Ukc+ IOKApg0KDQoNCk9uIDIwMTctMDItMTAsIDk6MjIgQU0sICJMZWlmIEpvaGFuc3NvbiIgPGxlaWZq QHN1bmV0LnNlPiB3cm90ZToNCg0KICAgIE9uIDIwMTctMDItMTAgMTQ6MjgsIFJha2VzaCBHYW5k aGkgKHJnYW5kaGkpIHdyb3RlOg0KICAgID4gSGkgTGVpZiwNCiAgICA+IA0KICAgID4gVGhhbmsg eW91IGZvciB0aGUgcmV2aWV3IG9mIHRoZSBkb2N1bWVudC4gDQogICAgPiANCiAgICA+IFJGQyA0 NzM2IChiYXNpcyBmb3IgdGhpcyBkb2N1bWVudCksIFNlY3VyaXR5IFNlY3Rpb24gOSwgaGFzIGNv dmVyYWdlIGZvciB0aGlzIGFzcGVjdCDigJMg4oCcRnVydGhlcm1vcmUsIGEgaGVhZC1lbmQgTFNS IG1heSBkZWNpZGUgdG8gaWdub3JlIGV4cGxpY2l0IG5vdGlmaWNhdGlvbiBjb21pbmcgZnJvbSBh IG1pZC1wb2ludCByZXNpZGluZyBpbiBhbm90aGVyIGRvbWFpbi7igJ0NCiAgICA+IA0KICAgIA0K ICAgIEFoIG9rIHNvIHRydXN0IGlzIHBsYWNlZCBpbiB0aGUgZG9tYWluPyBJIGd1ZXNzIHRoYXQg cHJvcGVydHkgaXMNCiAgICBzb21ldGhpbmcgdGhhdCBjb3VsZCBiZSBtYWRlIGV4cGxpY2l0IGlu IHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucw0KICAgIChvciBtYXliZSBpdHMgb2J2aW91cyB0 byBwZW9wbGUgaW4gdGhlIGZpZWxkKQ0KICAgIA0KDQo8Ukc+IFllcywgdGhpcyBhbmQgb3RoZXIg Y29uc2lkZXJhdGlvbnMgYXJlIGNvdmVyZWQgaW4gdGhlIHJlZmVyZW5jZWQgUkZDcyAoUkZDIDQ3 MzYgYW5kIFJGQyA1OTIwKS4NCg0KVGhhbmtzLA0KUmFrZXNoDQoNCg0KICAgID4gVGhhbmtzLA0K ICAgID4gUmFrZXNoDQogICAgPiANCiAgICA+IA0KICAgID4gT24gMjAxNy0wMi0xMCwgMjozMCBB TSwgIkxlaWYgSm9oYW5zc29uIiA8bGVpZmpAc3VuZXQuc2U+IHdyb3RlOg0KICAgID4gDQogICAg PiAgICAgDQogICAgPiAgICAgUmV2aWV3ZXI6IExlaWYgSm9oYW5zc29uDQogICAgPiAgICAgUmV2 aWV3IHJlc3VsdDogTWlub3IgaXNzdWVzDQogICAgPiAgICAgDQogICAgPiAgICAgSSBoYXZlIHJl dmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgc2VjdXJpdHkgZGlyZWN0b3JhdGUn cw0KICAgID4gICAgIG9uZ29pbmcgZWZmb3J0IHRvIHJldmlldyBhbGwgSUVURiBkb2N1bWVudHMg YmVpbmcgcHJvY2Vzc2VkIGJ5IHRoZQ0KICAgID4gICAgIElFU0cuICBUaGVzZSBjb21tZW50cyB3 ZXJlIHdyaXR0ZW4gcHJpbWFyaWx5IGZvciB0aGUgYmVuZWZpdCBvZiB0aGUNCiAgICA+ICAgICBz ZWN1cml0eSBhcmVhIGRpcmVjdG9ycy4gIERvY3VtZW50IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBz aG91bGQgdHJlYXQNCiAgICA+ICAgICB0aGVzZSBjb21tZW50cyBqdXN0IGxpa2UgYW55IG90aGVy IGxhc3QgY2FsbCBjb21tZW50cy4NCiAgICA+ICAgICANCiAgICA+ICAgICBUaGUgZHJhZnQgZGVz Y3JpYmVzIGEgd2F5IHRvIGhhbmRsZSBncm91cGluZ3Mgb2YgbGFyZ2Ugc2V0cyBvZiBzdWItDQog ICAgPiAgICAgTFNQcyBpbiBhIFAyTVAgR01QTFMgc2V0dXAgZm9yIHRoZSBwdXJwb3NlIG9mIHRy YWZmaWMgZW5naW5lZXJpbmcNCiAgICA+ICAgICAocmUtKW9wdGltaXphdGlvbiBieSBpbnRyb2R1 Y2luZyB0aGUgY29uY2VwdCBvZiAiZnJhZ21lbnQgaWRlbnRpZmllcnMiDQogICAgPiAgICAgDQog ICAgPiAgICAgTGV0IG1lIHN0YXRlIHVwIGZyb250IHRoYXQgdGhlIHRvcGljIGlzIG91dHNpZGUg bXkgbm9ybWFsIGFyZWEgb2YNCiAgICA+ICAgICBleHBlcnRpc2UuIE15IG9ubHkgcXVlc3Rpb24g aXMgdGhpczogY291bGQgYW4gYXR0YWNrZXIgZmFrZSBtZXNzYWdlcw0KICAgID4gICAgIHRoYXQg d291bGQgKHRvIHRoZSByZWNlaXZlciBpbmdyZXNzIG5vZGUpIGFwcGVhciB0byBiZSBwYXJ0IG9m IGENCiAgICA+ICAgICBmcmFnbWVudGVkIGdyb3VwIG9mIHN1Yi1MU1BzIHNvIGFzIHRvIHRyaWdn ZXIgYSBmdWxsIHJlLWNvbXB1dGF0aW9uDQogICAgPiAgICAgb2YgdGhlIHRyZWU/IFRoZSB0ZXh0 IGluIHRoZSBsYXN0IGJ1dCBvbmUgcGFyYWdyYXBoIG9mIDQuMiB3b3VsZA0KICAgID4gICAgIHNl ZW0gdG8gc3VnZ2VzdCB0aGF0IHRoaXMgYXR0YWNrIGlzIGEgcG9zc2liaWxpdHkuIEF0ICJ3b3Jz dCIgdGhpcw0KICAgID4gICAgIHdvdWxkIGJlIGEgZGVuaWFsLW9mLXNlcnZpY2UgYXR0YWNrIGJ1 dCBpdCBzaG91bGQgcGVyaGFwcyBiZSBhZGRyZXNzZWQNCiAgICA+ICAgICBpbiB0aGUgc2VjdXJp dHkgY29uc2lkZXJhdGlvbnMgc2VjdGlvbiBhbnl3YXkuDQogICAgPiAgICAgCQ0KICAgID4gICAg IAlDaGVlcnMgTGVpZg0KICAgID4gICAgIA0KICAgID4gDQogICAgDQogICAgDQoNCg== From nobody Fri Feb 10 08:15:47 2017 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6BF4129868; Fri, 10 Feb 2017 08:15:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ddT5awum_Vmw; Fri, 10 Feb 2017 08:15:43 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73699129426; Fri, 10 Feb 2017 08:15:42 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v1AGFdLh001431 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 10 Feb 2017 18:15:39 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v1AGFd3C019766; Fri, 10 Feb 2017 18:15:39 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <22685.59179.187157.685978@fireball.acr.fi> Date: Fri, 10 Feb 2017 18:15:39 +0200 From: Tero Kivinen To: iesg@ietf.org, secdir@ietf.org, draft-ietf-6tisch-minimal.all@ietf.org X-Edit-Time: 56 min X-Total-Time: 64 min Archived-At: Subject: [secdir] Secdir review of draft-ietf-6tisch-minimal-19 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 16:15:46 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This is my rereview of this draft. My original review found quite a lot of issues, and most of them have already been taken care of. There are still some remaining issues. Summary of the review: There are Issues. -- In section 4.6 the text Key K1 is used to authenticate EBs. As defined in Section 4.5.2,= EBs MUST be authenticated only (no encryption). is bit misleading, as while section 4.5.2 do define EBs it does not tell anything about the security of them. Perhaps rewrite that: Key K1 is used to authenticate EBs. EBs MUST be authenticated only (no encryption), and their contents is defined in the Section 4.5.2. -- In section 4.6 the text about secExempt is bit incorrect. If neither key K1 nor key K2 is pre-configured, the JN uses the secExempt mechanism (IEEE Std 802.15.4, Section 9.2.4) to process= EBs, and relies on the key distribution phase to learn K1 and K2.= Once K1 and K2 are learned, the secExempt mechanism MUST be disabled and EBs properly authenticated using K1. The secExempt is needed both in the the joining node and the node receiving the frames from the joining node. The joining node usually do not use secExempt method, as it does not have keys, so it will not turn security processing of the 802.15.4 on until it has keys. So while still in joining process, it has security turned off and it can receive frames without security. The joining assistant (or was it proxy in new terminology) will then receive frames without security and when it receives them it should then configure the security layer or the 802.15.4 so that from that specific joining node the frames are allowed to come in without security. After the joining process is finished, those secExempt rules installed are removed. So the text should be written as: If neither key K1 nor key K2 is pre-configured, the JN will will accept EBs as defined in the Section 6.3.1.2 of the 802.15.4, i.e., they are passed forward even "if the status of the unsecuring process indicated an error". The JN will then run key distribution phase to learn K1 and K2. During that process the node JN is talking to, uses the secExempt mechanism (IEEE Std 802.15.4, Section 9.2.4) to process frames from JN. Once the key distribution phase is done the node which has installed secExempts for the JN MUST clear the exception rules installed. -- In the section 8 there is text saying: If both K1 and K2 are pre-provisioned, a joining node can distinguish legitimate from fake EBs, and join the legitimate network. The fake EBs have no impact. This is incorrect, as just few paragraphs before it was noted, that "Fixed secrets will not remain secret.". Same applies also if only K1 is pre-provisioned. I.e., if K1 is pre-provisioned attacker can physically extract the key from one device, and then use that K1 to attack whole network by sending authenticated EBs. So in all cases attacker can most likely cause the joining node to initiate the joining process to the attacker. If joining process includes authentication and distributing K2 to joining node, then joining node will fail, and joining node will notice this. If both K1 and K2 are pre-provisioned and attacker extracted them from one of the nodes earlier, joining node will not notice the attack. -- The text If neither K1 nor K2 is pre-provisioned, a joining node uses the secExempt mechanism (IEEE Std 802.15.4, Section 9.2.4) to process= all correctly-formatted EBs. It therefore may mistake a fake EB for a legitimate one and initiate a joining process to the attacker. ... describes the secExempt system again, and does it again incorrectly, so it would be better to just remove secExempt parts from there, and leave them only in 4.6. I.e., change this to: If neither K1 nor K2 is pre-provisioned, a joining node may mistake a fake EB for a legitimate one and initiate a joining process to the attacker. ... -- Then we have text: Once the joining process is over, the node that has joined can authenticate EBs (it knows K1). This means it can process their contents and use EBs for synchronization. But if the K1 is pre-provisioned and we can then assume that attacker knows it, the attacker can then send authenticated fake EBs to the node even after that. So this section should analyze what those fake EBs can do. If we limit the minimal so that none of the parameters in the EBs can be changed during the lifetime of the network (i.e., the network timing, used channels, slotframe size will remain static etc), then the attacker cannot gain too much. It can still mess up the nodes trying to join the network as explained earlier. We do have the text in the section 1 saying: =09 When following this specification, the learned schedule is the same for all nodes and does not change over time. =20 which would indicate that all the parameters sent out in EB (except ASN and Join metrics), but do we have somewhere the text saying that nodes MUST ignore EBs which try to change the parameters=3F -- The security consideration section is missing the text about the fact that TSCH does NOT provide replay protection for retransmitted frames. I.e., if node A transmits frame X and attacker messes up the ACK from the node B acking that frame, then the node A will retransmit that frame X again using new ASN. The 802.15.4 layer would normally ignore the retransmission as it has seen the frame counter before, but as TSCH uses ASN instead of frame counter, this protection is not available when using TSCH. This means that all upper layer protocols MUST be resistant to this kind of attacks, and they MUST have mechanims to prevent this. For example if the 6top sends ADD message saying "Allocate 3 new cells", there must be sequence number (SeqNum) and the 6top protocol needs to notice that if it gets two ADD message with same SeqNum it must ignore the replayed one. This might not be obvious to the users of the 6tisch, as 802.15.4 for example do provide protection against retransmissions done by link layer. -- In section 8 (security consideration) there is text: The MAC layer SHOULD keep track of anomalous events and report them to a higher authority. For example, EBs reporting low Join Metrics for networks which can not be joined, as described above, may be a sign of attack. =20 I do not think we should put any requirements for the MAC layer in this document. Also in the 802.15.4 the Join Metrics etc processing is done by the higher layer, not by MAC. Perhaps change the "The MAC layer" to "The 6TiSCH layer". -- >From my previous review: > 6)EDITORIAL ISSUE 4 >=20 > Same for other names (slotOffset =3D=3D Timeslot, chOffset =3D=3D Cha= nnel Offset). > Also the IEEE Std 802.15.4-2015 moved away from using link > Options as hex number (0x0f), and instead lists the separate bit-fiel= ds in it > (tx, rx, shared, timekeeping), as does the Appendix A. >=20 > DISCUSSION > > Don=E2=80=99t see what change is requested here I was wondering why we are using two different terms for same things. I.e. figure 1 uses slotOffset and chOffset, but the appendix A uses the "Timeslot" and "Channel Offset" instead. Perhaps using "Channel Offset" for "chOffset" in whole document, and add "slotOffset" to the Append A.2 similarly than what was done for "(Cells)", i.e. change=20 Timeslot =3D 0x0000 (2B) to Timeslot (slotOffset) =3D 0x0000 (2B) The second item is that the saying "link Option 0x0f" in figure 1 is incorrect, as Link Options is not numeric field anymore, it is bitfield having bits "TX Link", "RX Link", "Shared Link", "Timekeeping" and "Priority" as is already explained in section 4.2. The figure 1 still insist using 0x0f. I think it is better to change that to list individual flags, i.e. change | | (link Option 0x0f) | = | in figure 1 to | | (Link Options: TX Link, | = | | | RX Link, Shared Link, | = | | | Timekeeping) | = | Also the figure 1 has line: | | (LinkType ADVERTISING) | = | as part of the Number of scheduled cells and it has EB marked as "X". The LinkType is not transmitted over the wire at all, it is parameter given to the MLME-SET-LINK.request primitive in the 802.15.4 MAC. So claiming it being part of EB is misleading. Perhaps removing that LinkType from the figure 1, but add footnote that applies to the Number of scheduled cells saying that "This cell is also set to have LinkType of ADVERTISING)". -- So this document is in much better shape now, but I still think there is issues that needs to be fixed before it can be approved. --=20 kivinen@iki.fi From nobody Fri Feb 10 08:34:04 2017 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43D14129A31 for ; Fri, 10 Feb 2017 08:34:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uoc.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Ap5b1yCXKh1 for ; Fri, 10 Feb 2017 08:33:59 -0800 (PST) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::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 81CC1129A27 for ; Fri, 10 Feb 2017 08:33:59 -0800 (PST) Received: by mail-it0-x232.google.com with SMTP id c7so36383478itd.1 for ; Fri, 10 Feb 2017 08:33:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoc.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=r6B7N+eERckHYUZCEsV9FJVgCCcN1/pD5QJUZdGxLIA=; b=dFF0LkTYSFT9535ubvD4AAyFk86sP8wlCTDWUim3QbkxLklv96FMm8nNrhDUa+UJVE TG7m7wYKqxg6eiGkRhTBkHutVxzPX0ghQHioaC0qzxmDKl468KbgfejdbpJztoCgXMGx VIswvVDDfYny5PRt/SBP83B8bd1y8Uqz291T0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=r6B7N+eERckHYUZCEsV9FJVgCCcN1/pD5QJUZdGxLIA=; b=uck7z4zNCO1owTaDR0e3R5E1+Qv2IKyJiwGwI8uKSflcX/8+7sZQLwIRpNBvwkyfqd 63xJryEfDJO/TaMEFkQGpP3y5DsRcPDw9yO/HYxkv0qMObaFNnfqJd7K6Wo8If5UV5Jv 1xoAKDnqX2z7AE+yyDBfP0NYDa8i0aoNXq0GXyDcE7unKXAYQqaEzR/yeYOeX5ijqZTi TWPPICcxj9ojp6tI+8afs1aNymiOiEElOkx6ib3VuwLJL9OD0W7JoSGiIoiSgnYebloW 2KFjGSNlr/eWPwLwH+bnrn6GJA/lhs++dl6fX+zr2B7/y1FNAOHdiHXGpmTJtcUGRd0Y hm5A== X-Gm-Message-State: AMke39mZI1nIaeOxkaEhPUOphkaQRcVU7dSMqToyqd3W4UTmiSgEM3/WMA++2feQbO+pcNN6GO0k+5lX3i72BJpY X-Received: by 10.36.6.199 with SMTP id 190mr9097849itv.79.1486744438648; Fri, 10 Feb 2017 08:33:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.46.13 with HTTP; Fri, 10 Feb 2017 08:33:58 -0800 (PST) In-Reply-To: <1316481833.2081691.1486743383878.JavaMail.root@vilafranca.uoc.es> References: <1316481833.2081691.1486743383878.JavaMail.root@vilafranca.uoc.es> From: Xavi Vilajosana Guillen Date: Fri, 10 Feb 2017 17:33:58 +0100 Message-ID: To: Tero Kivinen Content-Type: multipart/alternative; boundary=001a113f77e42352f505482faa4d Archived-At: Cc: iesg@ietf.org, draft-ietf-6tisch-minimal.all@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-6tisch-minimal-19 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 16:34:02 -0000 --001a113f77e42352f505482faa4d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Tero, thanks for your detailed review. I will proceed with the revision in the following days and provide a new version. have a nice weekend, Xavi 2017-02-10 17:15 GMT+01:00 Tero Kivinen : > 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 is my rereview of this draft. My original review found quite a > lot of issues, and most of them have already been taken care of. There > are still some remaining issues. > > Summary of the review: There are Issues. > > -- > > In section 4.6 the text > > Key K1 is used to authenticate EBs. As defined in Section 4.5.2, > EBs MUST be authenticated only (no encryption). > > is bit misleading, as while section 4.5.2 do define EBs it does not > tell anything about the security of them. > > Perhaps rewrite that: > > Key K1 is used to authenticate EBs. EBs MUST be authenticated > only (no encryption), and their contents is defined in the > Section 4.5.2. > > -- > > In section 4.6 the text about secExempt is bit incorrect. > > If neither key K1 nor key K2 is pre-configured, the JN uses the > secExempt mechanism (IEEE Std 802.15.4, Section 9.2.4) to process > EBs, and relies on the key distribution phase to learn K1 and K2. > Once K1 and K2 are learned, the secExempt mechanism MUST be > disabled and EBs properly authenticated using K1. > > The secExempt is needed both in the the joining node and the node > receiving the frames from the joining node. The joining node usually > do not use secExempt method, as it does not have keys, so it will not > turn security processing of the 802.15.4 on until it has keys. So > while still in joining process, it has security turned off and it can > receive frames without security. > > The joining assistant (or was it proxy in new terminology) will then > receive frames without security and when it receives them it should > then configure the security layer or the 802.15.4 so that from that > specific joining node the frames are allowed to come in without > security. After the joining process is finished, those secExempt rules > installed are removed. > > So the text should be written as: > > If neither key K1 nor key K2 is pre-configured, the JN will will > accept EBs as defined in the Section 6.3.1.2 of the 802.15.4, > i.e., they are passed forward even "if the status of the > unsecuring process indicated an error". The JN will then run key > distribution phase to learn K1 and K2. During that process the > node JN is talking to, uses the secExempt mechanism (IEEE Std > 802.15.4, Section 9.2.4) to process frames from JN. Once the key > distribution phase is done the node which has installed > secExempts for the JN MUST clear the exception rules installed. > > -- > > In the section 8 there is text saying: > > If both K1 and K2 are pre-provisioned, a joining node can > distinguish legitimate from fake EBs, and join the legitimate > network. The fake EBs have no impact. > > This is incorrect, as just few paragraphs before it was noted, that > "Fixed secrets will not remain secret.". > > Same applies also if only K1 is pre-provisioned. I.e., if K1 is > pre-provisioned attacker can physically extract the key from one > device, and then use that K1 to attack whole network by sending > authenticated EBs. So in all cases attacker can most likely cause the > joining node to initiate the joining process to the attacker. If > joining process includes authentication and distributing K2 to joining > node, then joining node will fail, and joining node will notice this. > > If both K1 and K2 are pre-provisioned and attacker extracted them from > one of the nodes earlier, joining node will not notice the attack. > > -- > > The text > > If neither K1 nor K2 is pre-provisioned, a joining node uses the > secExempt mechanism (IEEE Std 802.15.4, Section 9.2.4) to process > all correctly-formatted EBs. It therefore may mistake a fake EB > for a legitimate one and initiate a joining process to the > attacker. ... > > describes the secExempt system again, and does it again incorrectly, > so it would be better to just remove secExempt parts from there, and > leave them only in 4.6. I.e., change this to: > > If neither K1 nor K2 is pre-provisioned, a joining node may > mistake a fake EB for a legitimate one and initiate a joining > process to the attacker. ... > > -- > > Then we have text: > > Once the joining process is over, the node that has joined can > authenticate EBs (it knows K1). This means it can process their > contents and use EBs for synchronization. > > But if the K1 is pre-provisioned and we can then assume that attacker > knows it, the attacker can then send authenticated fake EBs to the > node even after that. So this section should analyze what those fake > EBs can do. If we limit the minimal so that none of the parameters in > the EBs can be changed during the lifetime of the network (i.e., the > network timing, used channels, slotframe size will remain static etc), > then the attacker cannot gain too much. It can still mess up the nodes > trying to join the network as explained earlier. > > We do have the text in the section 1 saying: > > When following this specification, the learned schedule is > the same for all nodes and does not change over time. > > which would indicate that all the parameters sent out in EB (except > ASN and Join metrics), but do we have somewhere the text saying that > nodes MUST ignore EBs which try to change the parameters? > > -- > > The security consideration section is missing the text about the fact > that TSCH does NOT provide replay protection for retransmitted frames. > I.e., if node A transmits frame X and attacker messes up the ACK from > the node B acking that frame, then the node A will retransmit that > frame X again using new ASN. The 802.15.4 layer would normally ignore > the retransmission as it has seen the frame counter before, but as > TSCH uses ASN instead of frame counter, this protection is not > available when using TSCH. > > This means that all upper layer protocols MUST be resistant to this > kind of attacks, and they MUST have mechanims to prevent this. > > For example if the 6top sends ADD message saying "Allocate 3 new > cells", there must be sequence number (SeqNum) and the 6top protocol > needs to notice that if it gets two ADD message with same SeqNum it > must ignore the replayed one. > > This might not be obvious to the users of the 6tisch, as 802.15.4 for > example do provide protection against retransmissions done by link > layer. > > -- > > In section 8 (security consideration) there is text: > > The MAC layer SHOULD keep track of anomalous events and report them > to a higher authority. For example, EBs reporting low Join Metrics > for networks which can not be joined, as described above, may be a > sign of attack. > > I do not think we should put any requirements for the MAC layer in > this document. Also in the 802.15.4 the Join Metrics etc processing is > done by the higher layer, not by MAC. Perhaps change the "The MAC > layer" to "The 6TiSCH layer". > > -- > > >From my previous review: > > > 6)EDITORIAL ISSUE 4 > > > > Same for other names (slotOffset =3D=3D Timeslot, chOffset =3D=3D Chann= el > Offset). > > Also the IEEE Std 802.15.4-2015 moved away from using link > > Options as hex number (0x0f), and instead lists the separate bit-fields > in it > > (tx, rx, shared, timekeeping), as does the Appendix A. > > > > DISCUSSION > > > > Don=E2=80=99t see what change is requested here > > I was wondering why we are using two different terms for same things. > I.e. figure 1 uses slotOffset and chOffset, but the appendix A uses > the "Timeslot" and "Channel Offset" instead. Perhaps using "Channel > Offset" for "chOffset" in whole document, and add "slotOffset" to the > Append A.2 similarly than what was done for "(Cells)", i.e. change > > Timeslot =3D 0x0000 (2B) > > to > > Timeslot (slotOffset) =3D 0x0000 (2B) > > The second item is that the saying "link Option 0x0f" in figure 1 is > incorrect, as Link Options is not numeric field anymore, it is > bitfield having bits "TX Link", "RX Link", "Shared Link", > "Timekeeping" and "Priority" as is already explained in section 4.2. > The figure 1 still insist using 0x0f. I think it is better to change > that to list individual flags, i.e. change > > | | (link Option 0x0f) | | > > in figure 1 to > > | | (Link Options: TX Link, | | > | | RX Link, Shared Link, | | > | | Timekeeping) | | > > Also the figure 1 has line: > > | | (LinkType ADVERTISING) | | > > as part of the Number of scheduled cells and it has EB marked as "X". > The LinkType is not transmitted over the wire at all, it is parameter > given to the MLME-SET-LINK.request primitive in the 802.15.4 MAC. So > claiming it being part of EB is misleading. > > Perhaps removing that LinkType from the figure 1, but add footnote > that applies to the Number of scheduled cells saying that "This cell > is also set to have LinkType of ADVERTISING)". > > -- > > So this document is in much better shape now, but I still think there > is issues that needs to be fixed before it can be approved. > -- > kivinen@iki.fi > --=20 Dr. Xavier Vilajosana Wireless Networks Lab *Internet Interdisciplinary Institute (IN3)Professor* (+34) 646 633 681 xvilajosana@uoc.edu http://xvilajosana.org http://wine.rdi.uoc.edu Parc Mediterrani de la Tecnologia Av Carl Friedrich Gauss 5, B3 Building 08860 Castelldefels (Barcelona). Catalonia. Spain [image: Universitat Oberta de Catalunya] =C2=AD --001a113f77e42352f505482faa4d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Tero,

thanks for your detailed rev= iew. I will proceed with the revision in the following days and provide a n= ew version.

have a nice weekend,
Xavi

2017-02-= 10 17:15 GMT+01:00 Tero Kivinen <kivinen@iki.fi>:
I have reviewed this document as part of the security = directorate's
ongoing effort to review all IETF documents being processed by the
IESG.=C2=A0 These comments were written primarily for the benefit of the security area directors.=C2=A0 Document editors and WG chairs should treat<= br> these comments just like any other last call comments.

This is my rereview of this draft. My original review found quite a
lot of issues, and most of them have already been taken care of. There
are still some remaining issues.

Summary of the review: There are Issues.

--

In section 4.6 the text

=C2=A0 =C2=A0 =C2=A0 Key K1 is used to authenticate EBs.=C2=A0 As defined i= n Section 4.5.2,
=C2=A0 =C2=A0 =C2=A0 EBs MUST be authenticated only (no encryption).

is bit misleading, as while section 4.5.2 do define EBs it does not
tell anything about the security of them.

Perhaps rewrite that:

=C2=A0 =C2=A0 =C2=A0 Key K1 is used to authenticate EBs. EBs MUST be authen= ticated
=C2=A0 =C2=A0 =C2=A0 only (no encryption), and their contents is defined in= the
=C2=A0 =C2=A0 =C2=A0 Section 4.5.2.

--

In section 4.6 the text about secExempt is bit incorrect.

=C2=A0 =C2=A0 =C2=A0 If neither key K1 nor key K2 is pre-configured, the JN= uses the
=C2=A0 =C2=A0 =C2=A0 secExempt mechanism (IEEE Std 802.15.4, Section 9.2.4)= to process
=C2=A0 =C2=A0 =C2=A0 EBs, and relies on the key distribution phase to learn= K1 and K2.
=C2=A0 =C2=A0 =C2=A0 Once K1 and K2 are learned, the secExempt mechanism MU= ST be
=C2=A0 =C2=A0 =C2=A0 disabled and EBs properly authenticated using K1.

The secExempt is needed both in the the joining node and the node
receiving the frames from the joining node. The joining node usually
do not use secExempt method, as it does not have keys, so it will not
turn security processing of the 802.15.4 on until it has keys. So
while still in joining process, it has security turned off and it can
receive frames without security.

The joining assistant (or was it proxy in new terminology) will then
receive frames without security and when it receives them it should
then configure the security layer or the 802.15.4 so that from that
specific joining node the frames are allowed to come in without
security. After the joining process is finished, those secExempt rules
installed are removed.

So the text should be written as:

=C2=A0 =C2=A0 =C2=A0 If neither key K1 nor key K2 is pre-configured, the JN= will will
=C2=A0 =C2=A0 =C2=A0 accept EBs as defined in the Section 6.3.1.2 of the 80= 2.15.4,
=C2=A0 =C2=A0 =C2=A0 i.e., they are passed forward even "if the status= of the
=C2=A0 =C2=A0 =C2=A0 unsecuring process indicated an error". The JN wi= ll then run key
=C2=A0 =C2=A0 =C2=A0 distribution phase to learn K1 and K2. During that pro= cess the
=C2=A0 =C2=A0 =C2=A0 node JN is talking to, uses the secExempt mechanism (I= EEE Std
=C2=A0 =C2=A0 =C2=A0 802.15.4, Section 9.2.4) to process frames from JN. On= ce the key
=C2=A0 =C2=A0 =C2=A0 distribution phase is done the node which has installe= d
=C2=A0 =C2=A0 =C2=A0 secExempts for the JN MUST clear the exception rules i= nstalled.

--

In the section 8 there is text saying:

=C2=A0 =C2=A0 =C2=A0 If both K1 and K2 are pre-provisioned, a joining node = can
=C2=A0 =C2=A0 =C2=A0 distinguish legitimate from fake EBs, and join the leg= itimate
=C2=A0 =C2=A0 =C2=A0 network.=C2=A0 The fake EBs have no impact.

This is incorrect, as just few paragraphs before it was noted, that
"Fixed secrets will not remain secret.".

Same applies also if only K1 is pre-provisioned. I.e., if K1 is
pre-provisioned attacker can physically extract the key from one
device, and then use that K1 to attack whole network by sending
authenticated EBs. So in all cases attacker can most likely cause the
joining node to initiate the joining process to the attacker. If
joining process includes authentication and distributing K2 to joining
node, then joining node will fail, and joining node will notice this.

If both K1 and K2 are pre-provisioned and attacker extracted them from
one of the nodes earlier, joining node will not notice the attack.

--

The text

=C2=A0 =C2=A0 =C2=A0 If neither K1 nor K2 is pre-provisioned, a joining nod= e uses the
=C2=A0 =C2=A0 =C2=A0 secExempt mechanism (IEEE Std 802.15.4, Section 9.2.4)= to process
=C2=A0 =C2=A0 =C2=A0 all correctly-formatted EBs.=C2=A0 It therefore may mi= stake a fake EB
=C2=A0 =C2=A0 =C2=A0 for a legitimate one and initiate a joining process to= the
=C2=A0 =C2=A0 =C2=A0 attacker. ...

describes the secExempt system again, and does it again incorrectly,
so it would be better to just remove secExempt parts from there, and
leave them only in 4.6. I.e., change this to:

=C2=A0 =C2=A0 =C2=A0 If neither K1 nor K2 is pre-provisioned, a joining nod= e may
=C2=A0 =C2=A0 =C2=A0 mistake a fake EB for a legitimate one and initiate a = joining
=C2=A0 =C2=A0 =C2=A0 process to the attacker. ...

--

Then we have text:

=C2=A0 =C2=A0Once the joining process is over, the node that has joined can=
=C2=A0 =C2=A0authenticate EBs (it knows K1).=C2=A0 This means it can proces= s their
=C2=A0 =C2=A0contents and use EBs for synchronization.

But if the K1 is pre-provisioned and we can then assume that attacker
knows it, the attacker can then send authenticated fake EBs to the
node even after that. So this section should analyze what those fake
EBs can do. If we limit the minimal so that none of the parameters in
the EBs can be changed during the lifetime of the network (i.e., the
network timing, used channels, slotframe size will remain static etc),
then the attacker cannot gain too much. It can still mess up the nodes
trying to join the network as explained earlier.

We do have the text in the section 1 saying:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0When following this specification,= the learned schedule is
=C2=A0 =C2=A0the same for all nodes and does not change over time.

which would indicate that all the parameters sent out in EB (except
ASN and Join metrics), but do we have somewhere the text saying that
nodes MUST ignore EBs which try to change the parameters?

--

The security consideration section is missing the text about the fact
that TSCH does NOT provide replay protection for retransmitted frames.
I.e., if node A transmits frame X and attacker messes up the ACK from
the node B acking that frame, then the node A will retransmit that
frame X again using new ASN. The 802.15.4 layer would normally ignore
the retransmission as it has seen the frame counter before, but as
TSCH uses ASN instead of frame counter, this protection is not
available when using TSCH.

This means that all upper layer protocols MUST be resistant to this
kind of attacks, and they MUST have mechanims to prevent this.

For example if the 6top sends ADD message saying "Allocate 3 new
cells", there must be sequence number (SeqNum) and the 6top protocol needs to notice that if it gets two ADD message with same SeqNum it
must ignore the replayed one.

This might not be obvious to the users of the 6tisch, as 802.15.4 for
example do provide protection against retransmissions done by link
layer.

--

In section 8 (security consideration) there is text:

=C2=A0 =C2=A0The MAC layer SHOULD keep track of anomalous events and report= them
=C2=A0 =C2=A0to a higher authority.=C2=A0 For example, EBs reporting low Jo= in Metrics
=C2=A0 =C2=A0for networks which can not be joined, as described above, may = be a
=C2=A0 =C2=A0sign of attack.

I do not think we should put any requirements for the MAC layer in
this document. Also in the 802.15.4 the Join Metrics etc processing is
done by the higher layer, not by MAC. Perhaps change the "The MAC
layer" to "The 6TiSCH layer".

--

>From my previous review:

> 6)EDITORIAL ISSUE 4
>
> Same for other names (slotOffset =3D=3D Timeslot, chOffset =3D=3D Chan= nel Offset).
> Also the IEEE Std 802.15.4-2015 moved away from using link
> Options as hex number (0x0f), and instead lists the separate bit-field= s in it
> (tx, rx, shared, timekeeping), as does the Appendix A.
>
> DISCUSSION
>
> Don=E2=80=99t see what change is requested here

I was wondering why we are using two different terms for same things.
I.e. figure 1 uses slotOffset and chOffset, but the appendix A uses
the "Timeslot" and "Channel Offset" instead. Perhaps us= ing "Channel
Offset" for "chOffset" in whole document, and add "slot= Offset" to the
Append A.2 similarly than what was done for "(Cells)", i.e. chang= e

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Timeslot =3D 0x0000 (2B)

to

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Timeslot (slotOffset) =3D 0x0000 (= 2B)

The second item is that the saying "link Option 0x0f" in figure 1= is
incorrect, as Link Options is not numeric field anymore, it is
bitfield having bits "TX Link", "RX Link", "Shared= Link",
"Timekeeping" and "Priority" as is already explained in= section 4.2.
The figure 1 still insist using 0x0f. I think it is better to change
that to list individual flags, i.e. change

=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0(link Op= tion 0x0f)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0|

in figure 1 to

=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0(Link Op= tions: TX Link,=C2=A0 =C2=A0 |=C2=A0 =C2=A0|
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 RX Link= , Shared Link,=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0|
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 Timekee= ping)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0|

Also the figure 1 has line:

=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0(LinkTyp= e=C2=A0 =C2=A0 ADVERTISING)=C2=A0 |=C2=A0 =C2=A0|

as part of the Number of scheduled cells and it has EB marked as "X&qu= ot;.
The LinkType is not transmitted over the wire at all, it is parameter
given to the MLME-SET-LINK.request primitive in the 802.15.4 MAC. So
claiming it being part of EB is misleading.

Perhaps removing that LinkType from the figure 1, but add footnote
that applies to the Number of scheduled cells saying that "This cell is also set to have LinkType of ADVERTISING)".

--

So this document is in much better shape now, but I still think there
is issues that needs to be fixed before it can be approved.
--
kivinen@iki.fi



--
=
Dr. Xavier Vilajosan= a
Wireless Networks Lab
Internet Interdisciplinary Institut= e (IN3)
Professor
(+34) 646 633 681
xvilajosana@uoc.edu<= /a>
http://xvilajos= ana.org
http:/= /wine.rdi.uoc.edu
Parc Mediterrani de la Tecnologia=C2=A0
Av Carl Friedrich Gauss 5,= B3 Building
08860 Castelldefels (Barcelona). Catalonia. Spain
3D"Universitat=C2=A0=C2=A0
=C2=AD
--001a113f77e42352f505482faa4d-- From nobody Sat Feb 11 10:42:53 2017 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9059E129526 for ; Sat, 11 Feb 2017 10:42:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ypYBlyNyP1L for ; Sat, 11 Feb 2017 10:42:47 -0800 (PST) Received: from nm13-vm4.access.bullet.mail.bf1.yahoo.com (nm13-vm4.access.bullet.mail.bf1.yahoo.com [216.109.115.4]) (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 B1782129A40 for ; Sat, 11 Feb 2017 10:42:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1486838565; bh=DudY4KEy7iMuRt/m8xXhHpzx4yVwz36asQww1kThfAo=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From:Subject; b=sJGIFPJGU0XgYSJZO9dEVGANBf5iGEKHhRYfvyhYhZPRn9q3k5jClkH49+dgLq6HsMJBgTwXP64wR9EbxXsBfRa7OA8oee3rpr898mdI91ampjeJU6Cm3i2fj1YmKu1yx/bruEHB29U5kskvjEzVTHW/qfn4123xrB4Mfr9DTF/MjARtUC+5Aj4rKBuWpzz1I/VxfamtUCgyoDl++a3dU1fLvYUrnPJSaQijkM/b7sy9RJcUwDnUzBq94aZohYE7i+es8Ijl1R0s16bmpJ7yvBXbtIwTXpLMwDiOCZHB9iXXN1dtLgPvq6LSK03dwI8syz91Mrd9/vv6StuE4CzfzQ== Received: from [66.196.81.158] by nm13.access.bullet.mail.bf1.yahoo.com with NNFMP; 11 Feb 2017 18:42:45 -0000 Received: from [98.138.104.100] by tm4.access.bullet.mail.bf1.yahoo.com with NNFMP; 11 Feb 2017 18:42:45 -0000 Received: from [127.0.0.1] by smtp120.sbc.mail.ne1.yahoo.com with NNFMP; 11 Feb 2017 18:42:45 -0000 X-Yahoo-Newman-Id: 109776.31329.bm@smtp120.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: euMjvCcVM1ndlXrD.ETwVP7YDEKvxqkLJW_AqtqzM0RnrDM kwNsSrT0ehOs_P4oRhfVbF2BIltf6qpr4tJjHVBfN42nWR5oYF4_gtSuZ4N4 Ipy2IjM1QRYPETDHIQenJelimBwK258b4eSq_UMnPE8mB5NqzfgXi1tukjbA gp3JtvWZyvAjP7V8dTVmNFKelCxnm1Hn5RKbMf6eNacX8PLTtx2kgab_YBMz Pll4dVIXjBw1Mn0ycaaqsTe_gbTXEsbFEiSlkp1GO60H1BLQOmY4XiZN2xQH buh_K0Ipvj61AahJ6.qePxS3nbxNaOS3wR.WuADVdDo77hV2vygN1aeAaCDY y417yCx0FUiQM3FGYZqacv9njR618HsOT6rlgTAZ13gUo2VXhfLAgcgiAEdm O4utmc4Nl2gpQ5m55rrus7O1tb28OjhGz0pzlM2.SlDBxjWzdbRJmuzO5ltR GY9JW1mc.aoYybHxIh78M9rs2dGt8PSkOpg5rzlY5Cjn9UWANvfmb_m6kLzn OoxCOoal3B4zMPxgOclB90ZJiS6N4DhpeVTB3bhEocw-- X-Yahoo-SMTP: 4kJJK.qswBDPuwyc5wW.BPAQqNXdy5j09UNyeAS0pyOQ708- Received: from [192.168.1.152] (DD-WRT [192.168.1.1]) by uriel.mandelberg.org (Postfix) with ESMTPSA id 1DE9F1C6034; Sat, 11 Feb 2017 13:42:44 -0500 (EST) To: Oleg Muravskiy References: <8bee5b64-8b54-99f4-3e86-f6450f664fd6@mandelberg.org> <7f56ecd6-1753-ad26-0ff3-1cde6e3fe63d@mandelberg.org> <8048CCD5-0D86-4C33-8F8A-C74728FE8B67@ripe.net> From: David Mandelberg Message-ID: <87e899b3-a922-bc0d-be2e-8150219774c1@mandelberg.org> Date: Sat, 11 Feb 2017 13:42:39 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <8048CCD5-0D86-4C33-8F8A-C74728FE8B67@ripe.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="il0WiHS3kq0XFsN8mWfSmXWFLLHw3C302" Archived-At: Cc: draft-ietf-sidr-delta-protocol.all@ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-sidr-delta-protocol-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Feb 2017 18:42:48 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --il0WiHS3kq0XFsN8mWfSmXWFLLHw3C302 Content-Type: multipart/mixed; boundary="W9Fi7Cn29LPkoF6TfagdjDBSOGEuBEM1B" From: David Mandelberg To: Oleg Muravskiy Cc: iesg@ietf.org, secdir@ietf.org, draft-ietf-sidr-delta-protocol.all@ietf.org Message-ID: <87e899b3-a922-bc0d-be2e-8150219774c1@mandelberg.org> Subject: Re: secdir review of draft-ietf-sidr-delta-protocol-05 References: <8bee5b64-8b54-99f4-3e86-f6450f664fd6@mandelberg.org> <7f56ecd6-1753-ad26-0ff3-1cde6e3fe63d@mandelberg.org> <8048CCD5-0D86-4C33-8F8A-C74728FE8B67@ripe.net> In-Reply-To: <8048CCD5-0D86-4C33-8F8A-C74728FE8B67@ripe.net> --W9Fi7Cn29LPkoF6TfagdjDBSOGEuBEM1B Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 02/08/2017 06:04 AM, Oleg Muravskiy wrote: > Reading the paragraph in question again: >=20 > Relying Parties SHOULD NOT cache the notification file for longer > than 1 minute, regardless of the headers set by the repository serve= r > or CDN. >=20 > I think it could be misinterpreted in a way that RP should re-fetch not= ification file even if being in a middle of a validation run, which is wr= ong. So I propose a new text: >=20 > In case of a high load on a repository server or its distribution > network, the Cache-Control HTTP header, or a similar mechanism, MAY > be used to suggest an optimal (for the repository server) poll > interval for Relying Parties. However, setting it to an interval > longer than 1 hour is NOT RECOMMENDED. Relying parties SHOULD align > the suggested interval with their operational practices and the > expected update frequency of RPKI repository data, and MAY discard > suggested value. >=20 > What do you think? I'm ok with the new text. --=20 David Eric Mandelberg / dseomn http://david.mandelberg.org/ --W9Fi7Cn29LPkoF6TfagdjDBSOGEuBEM1B-- --il0WiHS3kq0XFsN8mWfSmXWFLLHw3C302 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlifWx8ACgkQRKlmUHCg4sCPtQCeMAKMZpMVVJD1NtpYNbp9uwis aJ8AnirHJfpyaPpAKxFlbpExuT68MjBr =fJye -----END PGP SIGNATURE----- --il0WiHS3kq0XFsN8mWfSmXWFLLHw3C302-- From nobody Sun Feb 12 10:12:35 2017 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FEB31299A1; Sun, 12 Feb 2017 10:12:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=earthlink.net; domainkeys=pass (2048-bit key) header.from=charles.perkins@earthlink.net header.d=earthlink.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 G9QiELlRdp4P; Sun, 12 Feb 2017 10:12:27 -0800 (PST) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98251129993; Sun, 12 Feb 2017 10:12:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=earthlink.net; s=dk12062016; t=1486923147; bh=gd8XJFn/6UKxbqYTlgJ60SRFlS9NH06HsZCa E6RU0ig=; h=Received:Subject:To:References:From:Message-ID:Date: User-Agent:MIME-Version:In-Reply-To:Content-Type: Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; b=JvQyoVn RKV2T5U+FJ3yEVfTQ9OozhevaWzaigKxjIzEzYxFkAdcEga0P0Vev8i6j2JESyyn32n oj20AtuQXpqtbWJGQZA7UdItnbamxSf3tXqBLqaxDJiKIuPNa+04Fnb4tVI6RE3hDbo 2Dt6EDceHQoUTZSlHorH7un3Tr3b3QYCmHC7YrVjkvyqk/TtfvEAnSyT25/EXzITCH4 C/91aVjCIDykqx8ZEEufqiYUoBJXpZJcU+wGuLC/CqjIAhtmQcJtaR8hhDr95r79dVt bi/zvo5jMvWsnoxcK7jHHOBKynnb0ohCvoGds9WaF/qArMhtcqQP85Y8q02ZnjF+ohQ == DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=earthlink.net; b=UZ+AZHbrcUMbmJjxTsLIX0/Z3Hd1LJxk2KvIlpeNVsGSlOuui10D5vd8rPlYU+imm3ey63JpWAQGris67pfNIZtSWV4nqfBLnlEeL12rtBoheDPb7HGt16gNIZJZvD493J9q6QVau2zu/9SbLDDuwFmoo25biK3TiXsRHQuO+ZZqlf9X376wgyrlbmekQxgMFdUx0atW+1X2LoSg+DUEfnsmvA6vPx2l/HRnnf9FStZnF+3h38A0uW1FBXa3tQeV9pA6VAk9R9isswvf+od/s2h+rthmIdNcE8FieLGvDG1GwwNFZZi7aEtNvB4gH+IEu+7C2/JUteVphAsVfSEvIA==; h=Received:Subject:To:References:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.72.196] (helo=[192.168.1.82]) by elasmtp-galgo.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1ccyd4-0007Iy-K2; Sun, 12 Feb 2017 13:12:06 -0500 To: Joseph Salowey , secdir , draft-ietf-dmm-4283mnids.all@ietf.org, The IESG References: From: Charlie Perkins Message-ID: Date: Sun, 12 Feb 2017 10:12:01 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac7f1ef8e1983fa9f67d33b7d1b5ade781b350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-dmm-4283mnids-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2017 18:12:29 -0000 Hello Joseph, Thanks for the review. There will be new text added to the Security Considerations as suggested by other reviewers as well. It will indeed lend additional emphasis to the matter of trackable IDs. Regards, Charlie P. On 2/5/2017 2:36 PM, Joseph Salowey 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. > > This document is ready with nits. > > I was pleased that the security considerations does discuss some > privacy issues. I think it would help to emphasize that identifiers > can be trackable since many of the IDs in the draft are long lived. > The section does mention it, this suggestion is just for emphasis. > > First sentence of second paragraph of security considerations. > > "Some identifiers (e.g., IMSI) are considered to be private > information and some are long lived allowing for tracking of an > individual or device." > > Cheers, > > Joe From nobody Sun Feb 12 20:04:43 2017 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D684129549; Sun, 12 Feb 2017 20:04:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 79eyfDJd7F23; Sun, 12 Feb 2017 20:04:40 -0800 (PST) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0118.outbound.protection.outlook.com [23.103.200.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86292129AB3; Sun, 12 Feb 2017 20:04:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=rIAh9tbtjadVSISYw+GWExPcj4cUQgdx3rbkiL+hSqE=; b=TcL5joKn4EiHfSagXVFuL7lWtu3H7vrpLJ0NWkkk2fYtfxVjinL1hdQv71p4QN+YyFXV4Dy7vhqz0dpRcqCgMnDJstsWvD9dsz9QYT93X+IQrfocvFYrHtjeynMTGejPLXFPos3UCU36youLC01DyndXLgli0PLU/Fz5wEVC1R8= Received: from MWHPR09MB1440.namprd09.prod.outlook.com (10.173.50.14) by MWHPR09MB1438.namprd09.prod.outlook.com (10.173.50.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Mon, 13 Feb 2017 04:04:38 +0000 Received: from MWHPR09MB1440.namprd09.prod.outlook.com ([10.173.50.14]) by MWHPR09MB1440.namprd09.prod.outlook.com ([10.173.50.14]) with mapi id 15.01.0888.030; Mon, 13 Feb 2017 04:04:38 +0000 From: "Waltermire, David A. (Fed)" To: "'iesg@ietf.org'" , "secdir@ietf.org" , "draft-ietf-pals-mpls-tp-dual-homing-protection.all@ietf.org" Thread-Topic: Secdir review of draft-ietf-pals-mpls-tp-dual-homing-protection-05 Thread-Index: AdKFriNH20eBjgtHQLOntTZkRpbTkw== Date: Mon, 13 Feb 2017 04:04:38 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=david.waltermire@nist.gov; x-originating-ip: [129.6.220.71] x-ms-office365-filtering-correlation-id: e3ce518e-4362-409d-af6d-08d453c56e12 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:MWHPR09MB1438; x-microsoft-exchange-diagnostics: 1; MWHPR09MB1438; 7:VGeuJcY6ap+9jMI01H+sMAET6I7JUlwr7pC2kYV0wocdMB2uI8yTUxNn3gbbzNwiUdEiMeifyWnmFGCthPMvYe7BAmgYeILNS5+7xk4rOFWVxuxxkIElnqh3uwOatDyNPSAENGx5Ju5dmee1Iq97lWfCVlMcth6rOPPdWodqL9s3Zw0DcUKIwd+Mpv4artGeFsTe5RcqBhVdg9WdR9sz6JNQqE5iWeSBlEFc2w3kvnU0LGVg3mzN75maZNK7uLS5tOhvrAtYaOMuvBR9UFMXc6WtkaZ7+JDH38eLhtmlxAioXFg9Vfxi/UjkY27M0QcqaknhueY1V44KlLbX7uehpBud772xDc1lN97MUD1tMKmbfGpVBb3OV7gLe/DuaIiGVf2N4jHRSOw/EjV3lyuJfIO4yJ0ztUGJuGvNLOuwrN51xSxOzHNBu7IdXnowr+z9BR4DwrpgAcjordyhAkzXfysoXsMkosMRFwb/NT38rDqYHmspx2Qc/xsGatS+wM9Hy68c267dhlEyu5k/iYF8bg== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6041248)(20161123564025)(20161123555025)(20161123558025)(20161123560025)(20161123562025)(6072148); SRVR:MWHPR09MB1438; BCL:0; PCL:0; RULEID:; SRVR:MWHPR09MB1438; x-forefront-prvs: 02176E2458 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39840400002)(39850400002)(39410400002)(39450400003)(189002)(199003)(106356001)(105586002)(53936002)(9686003)(6116002)(102836003)(33656002)(450100001)(66066001)(55016002)(8676002)(122556002)(189998001)(2906002)(2501003)(99286003)(7696004)(25786008)(3660700001)(5890100001)(3280700002)(81156014)(86362001)(81166006)(3846002)(5660300001)(92566002)(6506006)(54356999)(77096006)(50986999)(305945005)(7736002)(2900100001)(38730400002)(2201001)(6436002)(8936002)(101416001)(97736004)(74316002)(68736007)(230783001)(491001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR09MB1438; H:MWHPR09MB1440.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Feb 2017 04:04:38.5542 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR09MB1438 Archived-At: Subject: [secdir] Secdir review of draft-ietf-pals-mpls-tp-dual-homing-protection-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 04:04:42 -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 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. Summary: Ready This informational draft identifies a mechanism for fault tolerance in pref= erred configurations for dual-homed Pseudowires that are used to carry traf= fic between the Provider Edge nodes when the Attachment Circuit, a Provider= Edge node, or the packet-switched network fails. The draft identifies a number of failure scenarios, and identifies how dual= homing can improve the reliability and integrity of a network implementing= this approach. This draft does not introduce any new security concerns ove= r the existing specifications it references. This draft appears to be ready= for publication. Regards, Dave Waltermire From nobody Mon Feb 13 05:17:25 2017 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73539129667; Mon, 13 Feb 2017 05:17:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1t0M00N8YflB; Mon, 13 Feb 2017 05:17:18 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 B7969129666; Mon, 13 Feb 2017 05:17:17 -0800 (PST) X-AuditID: c1b4fb3a-bb7cb98000005e23-4a-58a1b1db6ad5 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by (Symantec Mail Security) with SMTP id 08.20.24099.BD1B1A85; Mon, 13 Feb 2017 14:17:15 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0319.002; Mon, 13 Feb 2017 14:16:29 +0100 From: Christer Holmberg To: Christer Holmberg , Paul Wouters , Paul Wouters Thread-Topic: [secdir] Review of draft-ietf-mmusic-sctp-sdp-22 Thread-Index: AQHSg02fz09JgsaxQEyJwWweq6l2mKFhhUMAgADVvICABKaOgA== Date: Mon, 13 Feb 2017 13:16:28 +0000 Message-ID: References: <148669725288.8138.2095744202497272272.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="euc-kr" Content-ID: <7C93A738973FC344BE5F5B64AC34F280@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOIsWRmVeSWpSXmKPExsUyM2J7oO7tjQsjDDY1mFts6t/EYvFs43wW i6nLH7NYvL91icni5L57TBYfFj5kcWDzWLLkJ5PH93lMHu/3XWULYI7isklJzcksSy3St0vg ypi2+SxTwQ6mipmPNzA3MG5g6mLk5JAQMJHo/97C3MXIxSEksI5R4saxKSwgCSGBxYwSvxZY dTFycLAJWEh0/9MGCYsIVEu8bu1kAqlnFtjNKPHsyH52kBphAVuJ098UIGrsJJpnf2CDsJ0k Jn5dwQxiswioSnQ3bWEFsXkFrCW+dl+B2ruVUeL88p9gB3EK2EhcWX8E7AZGATGJ76fWgMWZ BcQlbj2ZD3W0gMSSPeeZIWxRiZeP/4ENFRXQk1j+fA0zyD0SAkoS07amQbRqSXz5sY8NwraW ePD4PTOErSgxpfshO8Q9ghInZz5hmcAoPgvJtllI2mchaZ+FpH0WkvYFjKyrGEWLU4uLc9ON jPRSizKTi4vz8/TyUks2MQKj8+CW31Y7GA8+dzzEKMDBqMTDu2HDgggh1sSy4srcQ4wSHMxK IrzlGxZGCPGmJFZWpRblxxeV5qQWH2KU5mBREuc1W3k/XEggPbEkNTs1tSC1CCbLxMEp1cBY +GgKB+/cdmf1Db9+ndjedO+k6ZWMN/dvZd+wCzz98NYklaONp76eu/ExT1Rc7zTD7rio+H2M p17VT65etuyu8UaBSjsbBm71+Lllk2bx6H5vauD73HVuZ+HJU2LaDQJGSrVX7rs5/us7w8z5 dq6pptrrbSpe689pFVla8vU+WNls1debP/GlEktxRqKhFnNRcSIAqy7p5MoCAAA= Archived-At: Cc: "draft-ietf-mmusic-sctp-sdp.all@ietf.org" , "ietf@ietf.org" , "mmusic@ietf.org" , secdir Subject: Re: [secdir] Review of draft-ietf-mmusic-sctp-sdp-22 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 13:17:19 -0000 SGkgUGF1bCwNCg0KLi4uDQoNCj4+U2VjdGlvbiAxMC4zDQo+Pg0KPj5bSS1ELmlldGYtbW11c2lj LWR0bHMtc2RwXSBpcyBub3QgYSBwcm9wZXIgcmVmZXJlbmNlIHdpdGggbGluay4NCj4NCj5JqfZs bCBsb29rIGludG8gdGhhdC4NCg0KSSBoYWQgYSBsb29rIGEgdGhpcywgYnV0IEkgYW0gbm90IHN1 cmUgSSB1bmRlcnN0YW5kIHlvdXIgaXNzdWUuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg== From nobody Mon Feb 13 07:41:42 2017 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 564931296CA; Mon, 13 Feb 2017 07:41:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 05R1TK_WSdyr; Mon, 13 Feb 2017 07:41:31 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 C6C38129406; Mon, 13 Feb 2017 07:41:30 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3vMVBb4lTmzd3; Mon, 13 Feb 2017 16:40:55 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1487000456; bh=nu5I0bqJq9L+xfMF+e5anV7CyisU334gGcoBDcUyBIU=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Hj4kT1oBeEzoONM2kDVZubv0bMeV+p6n1ywJgoQCSAsgxWHUgmhlpYOUnjvUBZH+O tVCVlAy6Uk+5Q7fU0Elcj3CJT3NuPTxtGtLQMqakvfTn8AEmLIkgbyUN3RE6b+eBG5 t6zEvC6IPn0gzpc2z3oyIH5qgcVBzQ2FrYEX6UDw= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id qzZk10l4PELa; Mon, 13 Feb 2017 16:40:53 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 13 Feb 2017 16:40:53 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id A42E02DEFF6; Mon, 13 Feb 2017 10:40:52 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca A42E02DEFF6 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 8D6AC41DA420; Mon, 13 Feb 2017 10:40:52 -0500 (EST) Date: Mon, 13 Feb 2017 10:40:52 -0500 (EST) From: Paul Wouters To: Christer Holmberg In-Reply-To: Message-ID: References: <148669725288.8138.2095744202497272272.idtracker@ietfa.amsl.com> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=euc-kr; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Cc: "draft-ietf-mmusic-sctp-sdp.all@ietf.org" , Paul Wouters , "ietf@ietf.org" , "mmusic@ietf.org" , secdir Subject: Re: [secdir] Review of draft-ietf-mmusic-sctp-sdp-22 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 15:41:32 -0000 On Mon, 13 Feb 2017, Christer Holmberg wrote: >>> Section 10.3 >>> >>> [I-D.ietf-mmusic-dtls-sdp] is not a proper reference with link. >> >> Ill look into that. > > I had a look a this, but I am not sure I understand your issue. It has the ascii test "[I-D.ietf-mmusic-dtls-sdp]" instead of the markup text: Paul From nobody Mon Feb 13 13:29:14 2017 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A9384129959; Mon, 13 Feb 2017 13:29:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Sparks To: X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148702134865.24993.7015216971422780095.idtracker@ietfa.amsl.com> Date: Mon, 13 Feb 2017 13:29:08 -0800 Archived-At: Cc: draft-ietf-grow-mrt-add-paths.all@ietf.org, grow@ietf.org, ietf@ietf.org Subject: [secdir] Review of draft-ietf-grow-mrt-add-paths-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 21:29:09 -0000 Reviewer: Robert Sparks 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. Document : draft-ietf-grow-mrt-add-paths-03 Summary: Ready for publication as Proposed Standard This document simply carries an extension to BGP forward into this routing information export format. It notes in its security consideration section that including the information the BGP extension allows to be conveyed increases the detail of the network path information exposed to any recipient (intended or otherwise). I agree that it adds no further new security considerations. From nobody Tue Feb 14 08:56:42 2017 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABCB61293F8 for ; Tue, 14 Feb 2017 08:56:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uoc.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6L7U9G_X7qW8 for ; Tue, 14 Feb 2017 08:56:37 -0800 (PST) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C3C8129641 for ; Tue, 14 Feb 2017 08:56:37 -0800 (PST) Received: by mail-it0-x235.google.com with SMTP id x75so39958927itb.0 for ; Tue, 14 Feb 2017 08:56:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoc.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=leErxoKtcInKZ8YVv5HzFDIvheM1DYGoqa36gb8WMHs=; b=WrpMsz95U3G/MlmnlWh80vvYymF5OMIa1hKd6Ka/rIXA0b/9sDSBOorbt0Vno2E7wh pKGEZuolfDBSnyqe/8OKisHOFso+yuwD31eBuqTvJ/p9RaTSRM0PUaMcZ/iOuKTCUIP4 KmqAsBUIUls944NrBb4q2KxSHCr9uuk9VpIqk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=leErxoKtcInKZ8YVv5HzFDIvheM1DYGoqa36gb8WMHs=; b=OivuQnSmZFt9h4+gtUEmUO+eCXZDhj93IFB9CZZgA222zidMl79uhYb9ud/I8x1E9h wDh0+bU8SVrVg0lM/ke2XM9f/FsN1wnrEkC9fUoD6je51XUOyG/kA/vlZy3wPlimEHds tpDMl8+K5+uo6en40r4ykT/FEhMP6CtcfuWv4uttkK2iCzUDFGHaoGTkr7oZ7tVyYyoW qTf6o8gArq9nPUFG2jgURuS11rcuzK9lrEmzjUjqtnvUR+Jst3D1O/RBMg4j3iywwqEK r3RHxRnBg0/lhM00FPGvoUf0YcueilPqNTZF3iB7k5DaLq4vCJDdZNCvpWWbHP0OzZB6 mdjw== X-Gm-Message-State: AMke39mhVKomY2TPgqCtBRsqrM+7YYH0nJyDRNAQpz4ie2hpeVPL1k/ybby5UuWqRts4gY6m6tip8taVWnPOJLOo X-Received: by 10.36.225.195 with SMTP id n186mr4328310ith.35.1487091396005; Tue, 14 Feb 2017 08:56:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.30.200 with HTTP; Tue, 14 Feb 2017 08:56:34 -0800 (PST) In-Reply-To: <1316481833.2081691.1486743383878.JavaMail.root@vilafranca.uoc.es> References: <1316481833.2081691.1486743383878.JavaMail.root@vilafranca.uoc.es> From: Xavi Vilajosana Guillen Date: Tue, 14 Feb 2017 17:56:34 +0100 Message-ID: To: Tero Kivinen Content-Type: multipart/alternative; boundary=94eb2c19d676686b5a054880723f Archived-At: Cc: The IESG , draft-ietf-6tisch-minimal.all@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-6tisch-minimal-19 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 16:56:40 -0000 --94eb2c19d676686b5a054880723f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Tero, thanks so much for your reviews. Find inline our responses. We proceed to publish another version of the draft including the resolutions proposed in this email. regards, =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D 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 is my rereview of this draft. My original review found quite a lot of issues, and most of them have already been taken care of. There are still some remaining issues. Summary of the review: There are Issues. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D ----------------------------- REMARK 1 ----------------------------- In section 4.6 the text Key K1 is used to authenticate EBs. As defined in Section 4.5.2, EBs MUST be authenticated only (no encryption). is bit misleading, as while section 4.5.2 do define EBs it does not tell anything about the security of them. Perhaps rewrite that: Key K1 is used to authenticate EBs. EBs MUST be authenticated only (no encryption), and their contents is defined in the Section 4.5.2. ----------------------------- ANSWER 1 ----------------------------- We have adopted the proposed text. Thanks. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D ----------------------------- REMARK 2 ----------------------------- In section 4.6 the text about secExempt is bit incorrect. If neither key K1 nor key K2 is pre-configured, the JN uses the secExempt mechanism (IEEE Std 802.15.4, Section 9.2.4) to process EBs, and relies on the key distribution phase to learn K1 and K2. Once K1 and K2 are learned, the secExempt mechanism MUST be disabled and EBs properly authenticated using K1. The secExempt is needed both in the the joining node and the node receiving the frames from the joining node. The joining node usually do not use secExempt method, as it does not have keys, so it will not turn security processing of the 802.15.4 on until it has keys. So while still in joining process, it has security turned off and it can receive frames without security. The joining assistant (or was it proxy in new terminology) will then receive frames without security and when it receives them it should then configure the security layer or the 802.15.4 so that from that specific joining node the frames are allowed to come in without security. After the joining process is finished, those secExempt rules installed are removed. So the text should be written as: If neither key K1 nor key K2 is pre-configured, the JN will will accept EBs as defined in the Section 6.3.1.2 of the 802.15.4, i.e., they are passed forward even "if the status of the unsecuring process indicated an error". The JN will then run key distribution phase to learn K1 and K2. During that process the node JN is talking to, uses the secExempt mechanism (IEEE Std 802.15.4, Section 9.2.4) to process frames from JN. Once the key distribution phase is done the node which has installed secExempts for the JN MUST clear the exception rules installed. ----------------------------- ANSWER 2 ----------------------------- We have adopted the proposed text. Thanks. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D ----------------------------- REMARK 3 ----------------------------- In the section 8 there is text saying: If both K1 and K2 are pre-provisioned, a joining node can distinguish legitimate from fake EBs, and join the legitimate network. The fake EBs have no impact. This is incorrect, as just few paragraphs before it was noted, that "Fixed secrets will not remain secret.". Same applies also if only K1 is pre-provisioned. I.e., if K1 is pre-provisioned attacker can physically extract the key from one device, and then use that K1 to attack whole network by sending authenticated EBs. So in all cases attacker can most likely cause the joining node to initiate the joining process to the attacker. If joining process includes authentication and distributing K2 to joining node, then joining node will fail, and joining node will notice this. If both K1 and K2 are pre-provisioned and attacker extracted them from one of the nodes earlier, joining node will not notice the attack. ----------------------------- ANSWER 3 ----------------------------- We have changed the organization of Section 8 by commenting two possible situations: 1) when the attacker knows the keys (K1, K2) 2) when the attacker does not know the keys. The discussed text refers when the attacker do not know the keys. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D ----------------------------- REMARK 4 ----------------------------- The text If neither K1 nor K2 is pre-provisioned, a joining node uses the secExempt mechanism (IEEE Std 802.15.4, Section 9.2.4) to process all correctly-formatted EBs. It therefore may mistake a fake EB for a legitimate one and initiate a joining process to the attacker. ... describes the secExempt system again, and does it again incorrectly, so it would be better to just remove secExempt parts from there, and leave them only in 4.6. I.e., change this to: If neither K1 nor K2 is pre-provisioned, a joining node may mistake a fake EB for a legitimate one and initiate a joining process to the attacker. ... ----------------------------- ANSWER 4 ----------------------------- secExempt parts have been removed. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D ----------------------------- REMARK 5 ----------------------------- Then we have text: Once the joining process is over, the node that has joined can authenticate EBs (it knows K1). This means it can process their contents and use EBs for synchronization. But if the K1 is pre-provisioned and we can then assume that attacker knows it, the attacker can then send authenticated fake EBs to the node even after that. So this section should analyze what those fake EBs can do. If we limit the minimal so that none of the parameters in the EBs can be changed during the lifetime of the network (i.e., the network timing, used channels, slotframe size will remain static etc), then the attacker cannot gain too much. It can still mess up the nodes trying to join the network as explained earlier. We do have the text in the section 1 saying: When following this specification, the learned schedule is the same for all nodes and does not change over time. which would indicate that all the parameters sent out in EB (except ASN and Join metrics), but do we have somewhere the text saying that nodes MUST ignore EBs which try to change the parameters? ----------------------------- ANSWER 5 ----------------------------- A sentence is added to indicate that in Section 4.5.2. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D ----------------------------- REMARK 6 ----------------------------- The security consideration section is missing the text about the fact that TSCH does NOT provide replay protection for retransmitted frames. I.e., if node A transmits frame X and attacker messes up the ACK from the node B acking that frame, then the node A will retransmit that frame X again using new ASN. The 802.15.4 layer would normally ignore the retransmission as it has seen the frame counter before, but as TSCH uses ASN instead of frame counter, this protection is not available when using TSCH. This means that all upper layer protocols MUST be resistant to this kind of attacks, and they MUST have mechanims to prevent this. For example if the 6top sends ADD message saying "Allocate 3 new cells", there must be sequence number (SeqNum) and the 6top protocol needs to notice that if it gets two ADD message with same SeqNum it must ignore the replayed one. This might not be obvious to the users of the 6tisch, as 802.15.4 for example do provide protection against retransmissions done by link layer. ----------------------------- ANSWER 6 ----------------------------- A paragraph have been added, thanks for the suggestion. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D ----------------------------- REMARK 7 ----------------------------- In section 8 (security consideration) there is text: The MAC layer SHOULD keep track of anomalous events and report them to a higher authority. For example, EBs reporting low Join Metrics for networks which can not be joined, as described above, may be a sign of attack. I do not think we should put any requirements for the MAC layer in this document. Also in the 802.15.4 the Join Metrics etc processing is done by the higher layer, not by MAC. Perhaps change the "The MAC layer" to "The 6TiSCH layer". ----------------------------- ANSWER 7 ----------------------------- We set this requirement to the 6TiSCH Layer as proposed. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D ----------------------------- REMARK 8 ----------------------------- >From my previous review: > 6)EDITORIAL ISSUE 4 > > Same for other names (slotOffset =3D=3D Timeslot, chOffset =3D=3D Channel= Offset). > Also the IEEE Std 802.15.4-2015 moved away from using link > Options as hex number (0x0f), and instead lists the separate bit-fields in it > (tx, rx, shared, timekeeping), as does the Appendix A. > > DISCUSSION > > I was wondering why we are using two different terms for same things. I.e. figure 1 uses slotOffset and chOffset, but the appendix A uses the "Timeslot" and "Channel Offset" instead. Perhaps using "Channel Offset" for "chOffset" in whole document, and add "slotOffset" to the Append A.2 similarly than what was done for "(Cells)", i.e. change Timeslot =3D 0x0000 (2B) to Timeslot (slotOffset) =3D 0x0000 (2B) The second item is that the saying "link Option 0x0f" in figure 1 is incorrect, as Link Options is not numeric field anymore, it is bitfield having bits "TX Link", "RX Link", "Shared Link", "Timekeeping" and "Priority" as is ----------------------------- ANSWER 8 ----------------------------- Thanks Tero we corrected this following your advice. 2017-02-10 17:15 GMT+01:00 Tero Kivinen : > 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 is my rereview of this draft. My original review found quite a > lot of issues, and most of them have already been taken care of. There > are still some remaining issues. > > Summary of the review: There are Issues. > > -- > > In section 4.6 the text > > Key K1 is used to authenticate EBs. As defined in Section 4.5.2, > EBs MUST be authenticated only (no encryption). > > is bit misleading, as while section 4.5.2 do define EBs it does not > tell anything about the security of them. > > Perhaps rewrite that: > > Key K1 is used to authenticate EBs. EBs MUST be authenticated > only (no encryption), and their contents is defined in the > Section 4.5.2. > > -- > > In section 4.6 the text about secExempt is bit incorrect. > > If neither key K1 nor key K2 is pre-configured, the JN uses the > secExempt mechanism (IEEE Std 802.15.4, Section 9.2.4) to process > EBs, and relies on the key distribution phase to learn K1 and K2. > Once K1 and K2 are learned, the secExempt mechanism MUST be > disabled and EBs properly authenticated using K1. > > The secExempt is needed both in the the joining node and the node > receiving the frames from the joining node. The joining node usually > do not use secExempt method, as it does not have keys, so it will not > turn security processing of the 802.15.4 on until it has keys. So > while still in joining process, it has security turned off and it can > receive frames without security. > > The joining assistant (or was it proxy in new terminology) will then > receive frames without security and when it receives them it should > then configure the security layer or the 802.15.4 so that from that > specific joining node the frames are allowed to come in without > security. After the joining process is finished, those secExempt rules > installed are removed. > > So the text should be written as: > > If neither key K1 nor key K2 is pre-configured, the JN will will > accept EBs as defined in the Section 6.3.1.2 of the 802.15.4, > i.e., they are passed forward even "if the status of the > unsecuring process indicated an error". The JN will then run key > distribution phase to learn K1 and K2. During that process the > node JN is talking to, uses the secExempt mechanism (IEEE Std > 802.15.4, Section 9.2.4) to process frames from JN. Once the key > distribution phase is done the node which has installed > secExempts for the JN MUST clear the exception rules installed. > > -- > > In the section 8 there is text saying: > > If both K1 and K2 are pre-provisioned, a joining node can > distinguish legitimate from fake EBs, and join the legitimate > network. The fake EBs have no impact. > > This is incorrect, as just few paragraphs before it was noted, that > "Fixed secrets will not remain secret.". > > Same applies also if only K1 is pre-provisioned. I.e., if K1 is > pre-provisioned attacker can physically extract the key from one > device, and then use that K1 to attack whole network by sending > authenticated EBs. So in all cases attacker can most likely cause the > joining node to initiate the joining process to the attacker. If > joining process includes authentication and distributing K2 to joining > node, then joining node will fail, and joining node will notice this. > > If both K1 and K2 are pre-provisioned and attacker extracted them from > one of the nodes earlier, joining node will not notice the attack. > > -- > > The text > > If neither K1 nor K2 is pre-provisioned, a joining node uses the > secExempt mechanism (IEEE Std 802.15.4, Section 9.2.4) to process > all correctly-formatted EBs. It therefore may mistake a fake EB > for a legitimate one and initiate a joining process to the > attacker. ... > > describes the secExempt system again, and does it again incorrectly, > so it would be better to just remove secExempt parts from there, and > leave them only in 4.6. I.e., change this to: > > If neither K1 nor K2 is pre-provisioned, a joining node may > mistake a fake EB for a legitimate one and initiate a joining > process to the attacker. ... > > -- > > Then we have text: > > Once the joining process is over, the node that has joined can > authenticate EBs (it knows K1). This means it can process their > contents and use EBs for synchronization. > > But if the K1 is pre-provisioned and we can then assume that attacker > knows it, the attacker can then send authenticated fake EBs to the > node even after that. So this section should analyze what those fake > EBs can do. If we limit the minimal so that none of the parameters in > the EBs can be changed during the lifetime of the network (i.e., the > network timing, used channels, slotframe size will remain static etc), > then the attacker cannot gain too much. It can still mess up the nodes > trying to join the network as explained earlier. > > We do have the text in the section 1 saying: > > When following this specification, the learned schedule is > the same for all nodes and does not change over time. > > which would indicate that all the parameters sent out in EB (except > ASN and Join metrics), but do we have somewhere the text saying that > nodes MUST ignore EBs which try to change the parameters? > > -- > > The security consideration section is missing the text about the fact > that TSCH does NOT provide replay protection for retransmitted frames. > I.e., if node A transmits frame X and attacker messes up the ACK from > the node B acking that frame, then the node A will retransmit that > frame X again using new ASN. The 802.15.4 layer would normally ignore > the retransmission as it has seen the frame counter before, but as > TSCH uses ASN instead of frame counter, this protection is not > available when using TSCH. > > This means that all upper layer protocols MUST be resistant to this > kind of attacks, and they MUST have mechanims to prevent this. > > For example if the 6top sends ADD message saying "Allocate 3 new > cells", there must be sequence number (SeqNum) and the 6top protocol > needs to notice that if it gets two ADD message with same SeqNum it > must ignore the replayed one. > > This might not be obvious to the users of the 6tisch, as 802.15.4 for > example do provide protection against retransmissions done by link > layer. > > -- > > In section 8 (security consideration) there is text: > > The MAC layer SHOULD keep track of anomalous events and report them > to a higher authority. For example, EBs reporting low Join Metrics > for networks which can not be joined, as described above, may be a > sign of attack. > > I do not think we should put any requirements for the MAC layer in > this document. Also in the 802.15.4 the Join Metrics etc processing is > done by the higher layer, not by MAC. Perhaps change the "The MAC > layer" to "The 6TiSCH layer". > > -- > > >From my previous review: > > > 6)EDITORIAL ISSUE 4 > > > > Same for other names (slotOffset =3D=3D Timeslot, chOffset =3D=3D Chann= el > Offset). > > Also the IEEE Std 802.15.4-2015 moved away from using link > > Options as hex number (0x0f), and instead lists the separate bit-fields > in it > > (tx, rx, shared, timekeeping), as does the Appendix A. > > > > DISCUSSION > > > > Don=E2=80=99t see what change is requested here > > I was wondering why we are using two different terms for same things. > I.e. figure 1 uses slotOffset and chOffset, but the appendix A uses > the "Timeslot" and "Channel Offset" instead. Perhaps using "Channel > Offset" for "chOffset" in whole document, and add "slotOffset" to the > Append A.2 similarly than what was done for "(Cells)", i.e. change > > Timeslot =3D 0x0000 (2B) > > to > > Timeslot (slotOffset) =3D 0x0000 (2B) > > The second item is that the saying "link Option 0x0f" in figure 1 is > incorrect, as Link Options is not numeric field anymore, it is > bitfield having bits "TX Link", "RX Link", "Shared Link", > "Timekeeping" and "Priority" as is already explained in section 4.2. > The figure 1 still insist using 0x0f. I think it is better to change > that to list individual flags, i.e. change > > | | (link Option 0x0f) | | > > in figure 1 to > > | | (Link Options: TX Link, | | > | | RX Link, Shared Link, | | > | | Timekeeping) | | > > Also the figure 1 has line: > > | | (LinkType ADVERTISING) | | > > as part of the Number of scheduled cells and it has EB marked as "X". > The LinkType is not transmitted over the wire at all, it is parameter > given to the MLME-SET-LINK.request primitive in the 802.15.4 MAC. So > claiming it being part of EB is misleading. > > Perhaps removing that LinkType from the figure 1, but add footnote > that applies to the Number of scheduled cells saying that "This cell > is also set to have LinkType of ADVERTISING)". > > -- > > So this document is in much better shape now, but I still think there > is issues that needs to be fixed before it can be approved. > -- > kivinen@iki.fi > --=20 Dr. Xavier Vilajosana Wireless Networks Lab *Internet Interdisciplinary Institute (IN3)Professor* (+34) 646 633 681 xvilajosana@uoc.edu http://xvilajosana.org http://wine.rdi.uoc.edu Parc Mediterrani de la Tecnologia Av Carl Friedrich Gauss 5, B3 Building 08860 Castelldefels (Barcelona). Catalonia. Spain [image: Universitat Oberta de Catalunya] =C2=AD --94eb2c19d676686b5a054880723f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Tero,

thanks so much fo= r your reviews. Find inline our responses. We proceed to publish another ve= rsion of the draft including the resolutions proposed in this email.
<= div>
regards,
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

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

This is my rereview of this draft. My= original review found quite a
lot of issues, and most of them ha= ve already been taken care of. There
are still some remaining iss= ues.

Summary of the review: There are Issues.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

----------------= -------------
REMARK 1
-----------------------------

In section 4.6 the text

=C2= =A0 =C2=A0 =C2=A0 Key K1 is used to authenticate EBs.=C2=A0 As defined in S= ection 4.5.2,
=C2=A0 =C2=A0 =C2=A0 EBs MUST be authenticated only= (no encryption).

is bit misleading, as while sect= ion 4.5.2 do define EBs it does not
tell anything about the secur= ity of them.

Perhaps rewrite that:

<= /div>
=C2=A0 =C2=A0 =C2=A0 Key K1 is used to authenticate EBs. EBs MUST= be authenticated
=C2=A0 =C2=A0 =C2=A0 only (no encryption), and = their contents is defined in the
=C2=A0 =C2=A0 =C2=A0 Section 4.5= .2.

-----------------------------
ANSWER= 1
-----------------------------

We have= adopted the proposed text. Thanks.

=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

-----------------------------
REMARK 2<= /div>
-----------------------------

In section= 4.6 the text about secExempt is bit incorrect.

= =C2=A0 =C2=A0 =C2=A0 If neither key K1 nor key K2 is pre-configured, the JN= uses the
=C2=A0 =C2=A0 =C2=A0 secExempt mechanism (IEEE Std 802.= 15.4, Section 9.2.4) to process
=C2=A0 =C2=A0 =C2=A0 EBs, and rel= ies on the key distribution phase to learn K1 and K2.
=C2=A0 =C2= =A0 =C2=A0 Once K1 and K2 are learned, the secExempt mechanism MUST be
=C2=A0 =C2=A0 =C2=A0 disabled and EBs properly authenticated using K1= .

The secExempt is needed both in the the joining = node and the node
receiving the frames from the joining node. The= joining node usually
do not use secExempt method, as it does not= have keys, so it will not
turn security processing of the 802.15= .4 on until it has keys. So
while still in joining process, it ha= s security turned off and it can
receive frames without security.=

The joining assistant (or was it proxy in new ter= minology) will then
receive frames without security and when it r= eceives them it should
then configure the security layer or the 8= 02.15.4 so that from that
specific joining node the frames are al= lowed to come in without
security. After the joining process is f= inished, those secExempt rules
installed are removed.
<= br>
So the text should be written as:

= =C2=A0 =C2=A0 =C2=A0 If neither key K1 nor key K2 is pre-configured, the JN= will will
=C2=A0 =C2=A0 =C2=A0 accept EBs as defined in the Sect= ion 6.3.1.2 of the 802.15.4,
=C2=A0 =C2=A0 =C2=A0 i.e., they are = passed forward even "if the status of the
=C2=A0 =C2=A0 =C2= =A0 unsecuring process indicated an error". The JN will then run key
=C2=A0 =C2=A0 =C2=A0 distribution phase to learn K1 and K2. During= that process the
=C2=A0 =C2=A0 =C2=A0 node JN is talking to, use= s the secExempt mechanism (IEEE Std
=C2=A0 =C2=A0 =C2=A0 802.15.4= , Section 9.2.4) to process frames from JN. Once the key
=C2=A0 = =C2=A0 =C2=A0 distribution phase is done the node which has installed
=
=C2=A0 =C2=A0 =C2=A0 secExempts for the JN MUST clear the exception ru= les installed.

-----------------------------
=
ANSWER 2
-----------------------------

<= div>We have adopted the proposed text. Thanks.

=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D

-----------------------------
= REMARK 3
-----------------------------

I= n the section 8 there is text saying:

=C2=A0 =C2= =A0 =C2=A0 If both K1 and K2 are pre-provisioned, a joining node can
<= div>=C2=A0 =C2=A0 =C2=A0 distinguish legitimate from fake EBs, and join the= legitimate
=C2=A0 =C2=A0 =C2=A0 network.=C2=A0 The fake EBs have= no impact.

This is incorrect, as just few paragra= phs before it was noted, that
"Fixed secrets will not remain= secret.".

Same applies also if only K1 is pr= e-provisioned. I.e., if K1 is
pre-provisioned attacker can physic= ally extract the key from one
device, and then use that K1 to att= ack whole network by sending
authenticated EBs. So in all cases a= ttacker can most likely cause the
joining node to initiate the jo= ining process to the attacker. If
joining process includes authen= tication and distributing K2 to joining
node, then joining node w= ill fail, and joining node will notice this.

If bo= th K1 and K2 are pre-provisioned and attacker extracted them from
one of the nodes earlier, joining node will not notice the attack.

-----------------------------
ANSWER 3
-----------------------------
We have changed the organization = of Section 8 by commenting two possible situations:=C2=A0

1) when the attacker knows the keys (K1, K2)
2) when the = attacker does not know the keys.=C2=A0

The discuss= ed text refers when the attacker do not know the keys.

=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D

-----------------------------
REMARK 4
-----------------------------

The text

=C2=A0 =C2=A0 =C2=A0 If neither K= 1 nor K2 is pre-provisioned, a joining node uses the
=C2=A0 =C2= =A0 =C2=A0 secExempt mechanism (IEEE Std 802.15.4, Section 9.2.4) to proces= s
=C2=A0 =C2=A0 =C2=A0 all correctly-formatted EBs.=C2=A0 It ther= efore may mistake a fake EB
=C2=A0 =C2=A0 =C2=A0 for a legitimate= one and initiate a joining process to the
=C2=A0 =C2=A0 =C2=A0 a= ttacker. ...

describes the secExempt system again,= and does it again incorrectly,
so it would be better to just rem= ove secExempt parts from there, and
leave them only in 4.6. I.e.,= change this to:

=C2=A0 =C2=A0 =C2=A0 If neither K= 1 nor K2 is pre-provisioned, a joining node may
=C2=A0 =C2=A0 =C2= =A0 mistake a fake EB for a legitimate one and initiate a joining
=C2=A0 =C2=A0 =C2=A0 process to the attacker. ...

-----------------------------
ANSWER 4
---------------= --------------

secExempt parts have been removed.<= /div>

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

----------= -------------------
REMARK 5
--------------------------= ---

Then we have text:

= =C2=A0 =C2=A0Once the joining process is over, the node that has joined can=
=C2=A0 =C2=A0authenticate EBs (it knows K1).=C2=A0 This means it= can process their
=C2=A0 =C2=A0contents and use EBs for synchron= ization.

But if the K1 is pre-provisioned and we c= an then assume that attacker
knows it, the attacker can then send= authenticated fake EBs to the
node even after that. So this sect= ion should analyze what those fake
EBs can do. If we limit the mi= nimal so that none of the parameters in
the EBs can be changed du= ring the lifetime of the network (i.e., the
network timing, used = channels, slotframe size will remain static etc),
then the attack= er cannot gain too much. It can still mess up the nodes
trying to= join the network as explained earlier.

We do have= the text in the section 1 saying:

=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0When following this specification, the learned s= chedule is
=C2=A0 =C2=A0the same for all nodes and does not chang= e over time.

which would indicate that all the par= ameters sent out in EB (except
ASN and Join metrics), but do we h= ave somewhere the text saying that
nodes MUST ignore EBs which tr= y to change the parameters?

----------------------= -------
ANSWER 5
-----------------------------

A sentence is added to indicate that in Section 4.5.2.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

-------------= ----------------
REMARK 6
-----------------------------=

The security consideration section is missing the= text about the fact
that TSCH does NOT provide replay protection= for retransmitted frames.
I.e., if node A transmits frame X and = attacker messes up the ACK from
the node B acking that frame, the= n the node A will retransmit that
frame X again using new ASN. Th= e 802.15.4 layer would normally ignore
the retransmission as it h= as seen the frame counter before, but as
TSCH uses ASN instead of= frame counter, this protection is not
available when using TSCH.=

This means that all upper layer protocols MUST be= resistant to this
kind of attacks, and they MUST have mechanims = to prevent this.

For example if the 6top sends ADD= message saying "Allocate 3 new
cells", there must be s= equence number (SeqNum) and the 6top protocol
needs to notice tha= t if it gets two ADD message with same SeqNum it
must ignore the = replayed one.

This might not be obvious to the use= rs of the 6tisch, as 802.15.4 for
example do provide protection a= gainst retransmissions done by link
layer.

-----------------------------
ANSWER 6
-------------= ----------------

A paragraph have been added, than= ks for the suggestion.

=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

=
-----------------------------
REMARK 7
-----= ------------------------

In section 8 (security co= nsideration) there is text:

=C2=A0 =C2=A0The MAC l= ayer SHOULD keep track of anomalous events and report them
=C2=A0= =C2=A0to a higher authority.=C2=A0 For example, EBs reporting low Join Met= rics
=C2=A0 =C2=A0for networks which can not be joined, as descri= bed above, may be a
=C2=A0 =C2=A0sign of attack.

I do not think we should put any requirements for the MAC layer in=
this document. Also in the 802.15.4 the Join Metrics etc process= ing is
done by the higher layer, not by MAC. Perhaps change the &= quot;The MAC
layer" to "The 6TiSCH layer".

-----------------------------
ANSWER 7
-----------------------------

We set this requir= ement to the 6TiSCH Layer as proposed.

=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

-----------------------------
REMARK= 8
-----------------------------

>Fro= m my previous review:

> 6)EDITORIAL ISSUE 4
>
> Same for other names (slotOffset =3D=3D Timeslot= , chOffset =3D=3D Channel Offset).
> Also the IEEE Std 802.15.= 4-2015 moved away from using link
> Options as hex number (0x0= f), and instead lists the separate bit-fields in it
> (tx, rx,= shared, timekeeping), as does the Appendix A.
>
>= ; DISCUSSION
>
>=C2=A0
I was wondering = why we are using two different terms for same things.
I.e. figure= 1 uses slotOffset and chOffset, but the appendix A uses
the &quo= t;Timeslot" and "Channel Offset" instead. Perhaps using &quo= t;Channel
Offset" for "chOffset" in whole document= , and add "slotOffset" to the
Append A.2 similarly than= what was done for "(Cells)", i.e. change

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Timeslot =3D 0x0000 (2B)

to

=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0Timeslot (slotOffset) =3D 0x0000 (2B)

The second item is that the saying "link Option 0x0f" in figure = 1 is
incorrect, as Link Options is not numeric field anymore, it = is
bitfield having bits "TX Link", "RX Link",= "Shared Link",
"Timekeeping" and "Prior= ity" as is

-----------------------------
ANSWER 8
-----------------------------

=
Thanks Tero we corrected this following your advice.

2017-02-10 17:15 GMT+01= :00 Tero Kivinen <kivinen@iki.fi>:
I have reviewed this document as part of the security directorate'= ;s
ongoing effort to review all IETF documents being processed by the
IESG.=C2=A0 These comments were written primarily for the benefit of the security area directors.=C2=A0 Document editors and WG chairs should treat<= br> these comments just like any other last call comments.

This is my rereview of this draft. My original review found quite a
lot of issues, and most of them have already been taken care of. There
are still some remaining issues.

Summary of the review: There are Issues.

--

In section 4.6 the text

=C2=A0 =C2=A0 =C2=A0 Key K1 is used to authenticate EBs.=C2=A0 As defined i= n Section 4.5.2,
=C2=A0 =C2=A0 =C2=A0 EBs MUST be authenticated only (no encryption).

is bit misleading, as while section 4.5.2 do define EBs it does not
tell anything about the security of them.

Perhaps rewrite that:

=C2=A0 =C2=A0 =C2=A0 Key K1 is used to authenticate EBs. EBs MUST be authen= ticated
=C2=A0 =C2=A0 =C2=A0 only (no encryption), and their contents is defined in= the
=C2=A0 =C2=A0 =C2=A0 Section 4.5.2.

--

In section 4.6 the text about secExempt is bit incorrect.

=C2=A0 =C2=A0 =C2=A0 If neither key K1 nor key K2 is pre-configured, the JN= uses the
=C2=A0 =C2=A0 =C2=A0 secExempt mechanism (IEEE Std 802.15.4, Section 9.2.4)= to process
=C2=A0 =C2=A0 =C2=A0 EBs, and relies on the key distribution phase to learn= K1 and K2.
=C2=A0 =C2=A0 =C2=A0 Once K1 and K2 are learned, the secExempt mechanism MU= ST be
=C2=A0 =C2=A0 =C2=A0 disabled and EBs properly authenticated using K1.

The secExempt is needed both in the the joining node and the node
receiving the frames from the joining node. The joining node usually
do not use secExempt method, as it does not have keys, so it will not
turn security processing of the 802.15.4 on until it has keys. So
while still in joining process, it has security turned off and it can
receive frames without security.

The joining assistant (or was it proxy in new terminology) will then
receive frames without security and when it receives them it should
then configure the security layer or the 802.15.4 so that from that
specific joining node the frames are allowed to come in without
security. After the joining process is finished, those secExempt rules
installed are removed.

So the text should be written as:

=C2=A0 =C2=A0 =C2=A0 If neither key K1 nor key K2 is pre-configured, the JN= will will
=C2=A0 =C2=A0 =C2=A0 accept EBs as defined in the Section 6.3.1.2 of the 80= 2.15.4,
=C2=A0 =C2=A0 =C2=A0 i.e., they are passed forward even "if the status= of the
=C2=A0 =C2=A0 =C2=A0 unsecuring process indicated an error". The JN wi= ll then run key
=C2=A0 =C2=A0 =C2=A0 distribution phase to learn K1 and K2. During that pro= cess the
=C2=A0 =C2=A0 =C2=A0 node JN is talking to, uses the secExempt mechanism (I= EEE Std
=C2=A0 =C2=A0 =C2=A0 802.15.4, Section 9.2.4) to process frames from JN. On= ce the key
=C2=A0 =C2=A0 =C2=A0 distribution phase is done the node which has installe= d
=C2=A0 =C2=A0 =C2=A0 secExempts for the JN MUST clear the exception rules i= nstalled.

--

In the section 8 there is text saying:

=C2=A0 =C2=A0 =C2=A0 If both K1 and K2 are pre-provisioned, a joining node = can
=C2=A0 =C2=A0 =C2=A0 distinguish legitimate from fake EBs, and join the leg= itimate
=C2=A0 =C2=A0 =C2=A0 network.=C2=A0 The fake EBs have no impact.

This is incorrect, as just few paragraphs before it was noted, that
"Fixed secrets will not remain secret.".

Same applies also if only K1 is pre-provisioned. I.e., if K1 is
pre-provisioned attacker can physically extract the key from one
device, and then use that K1 to attack whole network by sending
authenticated EBs. So in all cases attacker can most likely cause the
joining node to initiate the joining process to the attacker. If
joining process includes authentication and distributing K2 to joining
node, then joining node will fail, and joining node will notice this.

If both K1 and K2 are pre-provisioned and attacker extracted them from
one of the nodes earlier, joining node will not notice the attack.

--

The text

=C2=A0 =C2=A0 =C2=A0 If neither K1 nor K2 is pre-provisioned, a joining nod= e uses the
=C2=A0 =C2=A0 =C2=A0 secExempt mechanism (IEEE Std 802.15.4, Section 9.2.4)= to process
=C2=A0 =C2=A0 =C2=A0 all correctly-formatted EBs.=C2=A0 It therefore may mi= stake a fake EB
=C2=A0 =C2=A0 =C2=A0 for a legitimate one and initiate a joining process to= the
=C2=A0 =C2=A0 =C2=A0 attacker. ...

describes the secExempt system again, and does it again incorrectly,
so it would be better to just remove secExempt parts from there, and
leave them only in 4.6. I.e., change this to:

=C2=A0 =C2=A0 =C2=A0 If neither K1 nor K2 is pre-provisioned, a joining nod= e may
=C2=A0 =C2=A0 =C2=A0 mistake a fake EB for a legitimate one and initiate a = joining
=C2=A0 =C2=A0 =C2=A0 process to the attacker. ...

--

Then we have text:

=C2=A0 =C2=A0Once the joining process is over, the node that has joined can=
=C2=A0 =C2=A0authenticate EBs (it knows K1).=C2=A0 This means it can proces= s their
=C2=A0 =C2=A0contents and use EBs for synchronization.

But if the K1 is pre-provisioned and we can then assume that attacker
knows it, the attacker can then send authenticated fake EBs to the
node even after that. So this section should analyze what those fake
EBs can do. If we limit the minimal so that none of the parameters in
the EBs can be changed during the lifetime of the network (i.e., the
network timing, used channels, slotframe size will remain static etc),
then the attacker cannot gain too much. It can still mess up the nodes
trying to join the network as explained earlier.

We do have the text in the section 1 saying:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0When following this specification,= the learned schedule is
=C2=A0 =C2=A0the same for all nodes and does not change over time.

which would indicate that all the parameters sent out in EB (except
ASN and Join metrics), but do we have somewhere the text saying that
nodes MUST ignore EBs which try to change the parameters?

--

The security consideration section is missing the text about the fact
that TSCH does NOT provide replay protection for retransmitted frames.
I.e., if node A transmits frame X and attacker messes up the ACK from
the node B acking that frame, then the node A will retransmit that
frame X again using new ASN. The 802.15.4 layer would normally ignore
the retransmission as it has seen the frame counter before, but as
TSCH uses ASN instead of frame counter, this protection is not
available when using TSCH.

This means that all upper layer protocols MUST be resistant to this
kind of attacks, and they MUST have mechanims to prevent this.

For example if the 6top sends ADD message saying "Allocate 3 new
cells", there must be sequence number (SeqNum) and the 6top protocol needs to notice that if it gets two ADD message with same SeqNum it
must ignore the replayed one.

This might not be obvious to the users of the 6tisch, as 802.15.4 for
example do provide protection against retransmissions done by link
layer.

--

In section 8 (security consideration) there is text:

=C2=A0 =C2=A0The MAC layer SHOULD keep track of anomalous events and report= them
=C2=A0 =C2=A0to a higher authority.=C2=A0 For example, EBs reporting low Jo= in Metrics
=C2=A0 =C2=A0for networks which can not be joined, as described above, may = be a
=C2=A0 =C2=A0sign of attack.

I do not think we should put any requirements for the MAC layer in
this document. Also in the 802.15.4 the Join Metrics etc processing is
done by the higher layer, not by MAC. Perhaps change the "The MAC
layer" to "The 6TiSCH layer".

--

>From my previous review:

> 6)EDITORIAL ISSUE 4
>
> Same for other names (slotOffset =3D=3D Timeslot, chOffset =3D=3D Chan= nel Offset).
> Also the IEEE Std 802.15.4-2015 moved away from using link
> Options as hex number (0x0f), and instead lists the separate bit-field= s in it
> (tx, rx, shared, timekeeping), as does the Appendix A.
>
> DISCUSSION
>
> Don=E2=80=99t see what change is requested here

I was wondering why we are using two different terms for same things.
I.e. figure 1 uses slotOffset and chOffset, but the appendix A uses
the "Timeslot" and "Channel Offset" instead. Perhaps us= ing "Channel
Offset" for "chOffset" in whole document, and add "slot= Offset" to the
Append A.2 similarly than what was done for "(Cells)", i.e. chang= e

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Timeslot =3D 0x0000 (2B)

to

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Timeslot (slotOffset) =3D 0x0000 (= 2B)

The second item is that the saying "link Option 0x0f" in figure 1= is
incorrect, as Link Options is not numeric field anymore, it is
bitfield having bits "TX Link", "RX Link", "Shared= Link",
"Timekeeping" and "Priority" as is already explained in= section 4.2.
The figure 1 still insist using 0x0f. I think it is better to change
that to list individual flags, i.e. change

=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0(link Op= tion 0x0f)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0|

in figure 1 to

=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0(Link Op= tions: TX Link,=C2=A0 =C2=A0 |=C2=A0 =C2=A0|
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 RX Link= , Shared Link,=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0|
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 Timekee= ping)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0|

Also the figure 1 has line:

=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0(LinkTyp= e=C2=A0 =C2=A0 ADVERTISING)=C2=A0 |=C2=A0 =C2=A0|

as part of the Number of scheduled cells and it has EB marked as "X&qu= ot;.
The LinkType is not transmitted over the wire at all, it is parameter
given to the MLME-SET-LINK.request primitive in the 802.15.4 MAC. So
claiming it being part of EB is misleading.

Perhaps removing that LinkType from the figure 1, but add footnote
that applies to the Number of scheduled cells saying that "This cell is also set to have LinkType of ADVERTISING)".

--

So this document is in much better shape now, but I still think there
is issues that needs to be fixed before it can be approved.
--
kivinen@iki.fi



--
=
Dr. Xavier Vilajosan= a
Wireless Networks Lab
Internet Interdisciplinary Institut= e (IN3)
Professor
(+34) 646 633 681
xvilajosana@uoc.edu<= /a>
http://xvilajos= ana.org
http:/= /wine.rdi.uoc.edu
Parc Mediterrani de la Tecnologia=C2=A0
Av Carl Friedrich Gauss 5,= B3 Building
08860 Castelldefels (Barcelona). Catalonia. Spain
3D"Universitat=C2=A0=C2=A0
=C2=AD
--94eb2c19d676686b5a054880723f-- From nobody Wed Feb 15 04:11:10 2017 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D5A9129495; Wed, 15 Feb 2017 04:11:08 -0800 (PST) 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, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 82DLDZRkEnhI; Wed, 15 Feb 2017 04:11:08 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A584B129440; Wed, 15 Feb 2017 04:11:07 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v1FCB5AQ012532 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 15 Feb 2017 14:11:05 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v1FCB5gf003128; Wed, 15 Feb 2017 14:11:05 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22692.17753.244390.745262@fireball.acr.fi> Date: Wed, 15 Feb 2017 14:11:05 +0200 From: Tero Kivinen To: Xavi Vilajosana Guillen In-Reply-To: References: <1316481833.2081691.1486743383878.JavaMail.root@vilafranca.uoc.es> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 1 min X-Total-Time: 0 min Archived-At: Cc: The IESG , draft-ietf-6tisch-minimal.all@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-6tisch-minimal-19 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 12:11:08 -0000 Xavi Vilajosana Guillen writes: > Dear Tero, > > thanks so much for your reviews. Find inline our responses. We proceed to > publish another version of the draft including the resolutions proposed in > this email. The resolutions implemented in the draft-ietf-6tisch-minimal-20 are ok, and I think the document should be ready now. -- kivinen@iki.fi From nobody Wed Feb 15 13:00:51 2017 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF79C1297F3; Wed, 15 Feb 2017 13:00:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jyr43xgcUmpF; Wed, 15 Feb 2017 13:00:44 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EDAD1297E1; Wed, 15 Feb 2017 13:00:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3602; q=dns/txt; s=iport; t=1487192444; x=1488402044; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=9MG3bShfISb3GkywNh5pZ3FhhAAZnGDmiEjSRNYzXI0=; b=VzH6R3rgq15Q2HJQB9oH+lxforwNMWgILmI/Hs+o1LYKVZ8xadViCyVO sdXqm3eTWn21rsmIsK8v3lNUxuFUF1hzOrkCwoXBpvZs4zoBoBFiRw5GC yRPxzb2+9Zh9Gjr7G1AtlTUJbxRuzus1aqNSDOjZtvWeTPLD6w0ji0anA Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B9BAC2wKRY/5hdJa1eGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgykpgXGDUooIkXGVVYIMhiIcgXo/GAECAQEBAQEBAWIohRoRMxISASI?= =?us-ascii?q?CJgIEMBUSBAENiXCwPYIlizUBAQEBAQEBAQEBAQEBAQEBAQEggQuHRwiKPC6CM?= =?us-ascii?q?QWbdwGBTpBFCpB8kxYBHziBAFEVTgGGMYo6gQwBAQE?= X-IronPort-AV: E=Sophos;i="5.35,166,1484006400"; d="scan'208";a="385364164" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Feb 2017 21:00:43 +0000 Received: from XCH-RTP-005.cisco.com (xch-rtp-005.cisco.com [64.101.220.145]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v1FL0hYc000339 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 15 Feb 2017 21:00:43 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-005.cisco.com (64.101.220.145) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 15 Feb 2017 16:00:42 -0500 Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1210.000; Wed, 15 Feb 2017 16:00:42 -0500 From: "Brian Weis (bew)" To: secdir , The IESG Thread-Topic: Secdir review of draft-ietf-pals-mpls-tp-dual-homing-coordination-05 Thread-Index: AQHSh86RoCQRkfSqMEO1mBfN/G3u7A== Date: Wed, 15 Feb 2017 21:00:41 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.51.5] Content-Type: text/plain; charset="utf-8" Content-ID: <4198199F2AE2CD4089CBA73603131ACD@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-pals-mpls-tp-dual-homing-coordination.all@ietf.org" Subject: [secdir] Secdir review of draft-ietf-pals-mpls-tp-dual-homing-coordination-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 21:00:46 -0000 SSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgc2VjdXJpdHkgZGly ZWN0b3JhdGUncyBvbmdvaW5nIGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJl aW5nIHByb2Nlc3NlZCBieSB0aGUgSUVTRy4gVGhlc2UgY29tbWVudHMgd2VyZSB3cml0dGVuIHBy aW1hcmlseSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlIHNlY3VyaXR5IGFyZWEgZGlyZWN0b3JzLiBE b2N1bWVudCBlZGl0b3JzIGFuZCBXRyBjaGFpcnMgc2hvdWxkIHRyZWF0IHRoZXNlIGNvbW1lbnRz IGp1c3QgbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLg0KDQpUaGlzIGRvY3VtZW50 IGNvbmNlcm5zIGEgRHVhbC1Ob2RlIEludGVyY29ubmVjdGlvbiAoRE5JKSBtZXNzYWdlLCB3aGlj aCBpcyBjYXJyaWVkIG92ZXIgYW4gYWxyZWFkeSBkZWZpbmVkIHByb3RvY29sICgiRy1BQ2jigJ0p IHBsYWNlZCBiZXR3ZWVuIGEgcGFpciBvZiBNUExTLVRQIFByb3ZpZGVyIEVkZ2UgKFBFKSBkZXZp Y2UuIEluIHRoaXMgY2FzZSwg4oCcZHVhbC1ob21lZOKAnSBtZWFucyB0aGF0IGJvdGggUEUgcm91 dGVycyBhcmUgY29ubmVjdGVkIHRvIGEgQ3VzdG9tZXIgRWRnZSAoQ0UpIGRldmljZS4gVGhlIHR3 byBQRSBkZXZpY2VzIHVzZSB0aGUgRE5JIHRvIHNpZ25hbCB3aGljaCBvZiB0aGUgUHNldWRvd2ly ZXMgKFBXcykgbGVhZGluZyBmcm9tIHRoZSBQRSBkZXZpY2VzIGludG8gdGhlIHByb3ZpZGVyIG5l dHdvcmsgY3VycmVudGx5IGlzIGNhcnJ5aW5nIHRoZSBDRSB0cmFmZmljLiANCg0KVGhlIHNlY3Vy aXR5IGNvbnNpZGVyYXRpb25zIHNlY3Rpb24gaW4gdGhpcyBkb2N1bWVudCBwb2ludHMgdG8gdGhl IHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGZvciBHLUFDaCAoUkZDIDU1ODYpLCB3aGljaCBpbiB0 dXJuIHBvaW50cyB0byBSRkMgNDQ4NS4gVGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGZvciBS RkMgNDQ4NSBiYXNpY2FsbHkgc2F5cyBhbnkgYXBwbGljYXRpb24gdXNpbmcgdGhlIGNoYW5uZWwg c2hvdWxkIGZ1bGx5IGNvbnNpZGVyIHRoZSByZXN1bHRhbnQgc2VjdXJpdHkgaXNzdWVzIGFuZCBw cm92aWRlIG1lY2hhbmlzbXMgdG8gc3RvcCBhdHRhY2tzLiBJIGRvbuKAmXQgYWN0dWFsbHkgc2Vl IGFueSBzdWNoIGFuYWx5c2lzIGNvbnNpZGVyaW5nIHRoZSBzZWN1cml0eSBpc3N1ZXMgdG8gdGhl IEROSSAgaW4gdGhpcyBkb2N1bWVudCwgYW5kIEkgdGhpbmsgdGhhdCBpdCB3b3VsZCBiZSBnb29k IHNheSBhIGxpdHRsZSBzb21ldGhpbmcgYWJvdXQgaG93IHRoZSBETkkgY291bGQgYmUgbWlzLXVz ZWQgYnkgYW4gYXR0YWNrZXIuIEJlY2F1c2Ugb2YgdGhpcyAgSSBjb25zaWRlciB0aGlzIGRvY3Vt ZW50IHRvIGJlIFJlYWR5IHdpdGggSXNzdWVzLiBCZWxvdyBJIHN1Z2dlc3Qgd2hhdCBtaWdodCBi ZSB0aGUgYW5hbHlzaXMgYW5kIHdoYXQgY291bGQgYmUgYWRkZWQgdG8gdGhlIHRoZSBzZWN1cml0 eSBjb25zaWRlcmF0aW9ucy4NCg0KVGhlIGRhdGEgY2FycmllZCBpbiB0aGUgRE5JIGNvbnRhaW5z IGNvbnRyb2wgZGF0YSwgd2hpY2ggaWYgYW4gYXR0YWNrZXIgZmFsc2lmaWVkIG9yIGNoYW5nZWQg dGhlbiB0aGUgdHdvIFBFIGRldmljZXMgbWlnaHQgbm90IGFncmVlIG9uIHdoaWNoIHdoaWNoIFBF IHNob3VsZCBiZSBzdWVkICB0byBkZWxpdmVyIHRoZSBDRSBkYXRhLCBhbmQgdGhpcyBjb3VsZCBi ZSB1c2VkIGFzIGEgZGVuaWFsIG9mIHNlcnZpY2UgYXR0YWNrIGFnYWluc3QgdGhlIENFLiBJZiB0 aGUgRy1BQ2ggcHJvdG9jb2wgZXZlciBjcm9zc2VzIGFuIHVudHJ1c3RlZCBsaW5rIHdoZXJlIGFu IGF0dGFja2VyIGNvdWxkIG1ha2UgdGhpcyBhdHRhY2sgdGhlbiBpdCB3b3VsZCBiZSBhIGdvb2Qg aWRlYSBpZiB0aGUgRy1BQ2ggcHJvdG9jb2wgd2FzIGludGVncml0eSBwcm90ZWN0ZWQgc28gdGhh dCB0aGUgdHdvIFBFcyBoYXZlIGNvbmZpZGVuY2UgdGhhdCB0aGUgbWVzc2FnZSBhcnJpdmVkIHVu bW9kaWZpZWQuIEZvciBleGFtcGxlLCBJIGltYWdpbmUgdGhhdCBpZiB0aGUgUEUgZGV2aWNlcyB3 ZXJlIGluIGRpZmZlcmVudCBkYXRhIGNlbnRlcnMsIHRoZW4gcHJvYmFibHkgdGhlIEctQUNoIHBy b3RvY29sIGlzIHZ1bG5lcmFibGUgc29tZXdoZXJlIGluIHRoZSBuZXR3b3JrIOKAlCBldmVuIGlm IGl04oCZcyBhbGwgdGhlIHNhbWUgcHJvdmlkZXIgbmV0d29yay4gSXQgd291bGQgYmUgZ29vZCB0 byBhY2tub3dsZWRnZSB0aGlzIGluIHRoZSBkb2N1bWVudCBieSBzYXlpbmcgdGhhdCBpZiB0aGUg Ry1BQ2ggcHJvdG9jb2wgZ29lcyBhY3Jvc3MgYW4gdW50cnVzdGVkIGxpbmsgdGhhdCB0aGUgRE5J IG1lc3NhZ2VzIHNob3VsZCBiZSBpbnRlZ3JpdHkgcHJvdGVjdGVkLiBJIGRvbuKAmXQgc2VlIGFu eSBUTFZzIGRlZmluZWQgZm9yIHRoZSBHLUFDaCB0aGF0IHdvdWxkIHByb3ZpZGUgaW50ZWdyaXR5 LCBhbmQgSeKAmW0gbm90IGZhbWlsaWFyIGVub3VnaCB3aXRoIE1QTFMtVEUgbmV0d29ya3MgdG8g a25vdyBob3cgdGhhdCBjb3VsZCBiZSBkb25lLCBidXQgYSBoaW50IHRvIGltcGxlbWVudG9ycyBz YXlpbmcgaG93IHRoaXMgY291bGQgYmUgZG9uZSB3b3VsZCBhbHNvIGJlIGEgZ29vZCBpZGVhLg0K DQpCcmlhbg== From nobody Wed Feb 15 17:43:00 2017 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11573129C36; Wed, 15 Feb 2017 17:42:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Degeqklfg_y8; Wed, 15 Feb 2017 17:42:57 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67A6C1297C9; Wed, 15 Feb 2017 17:42:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2194; q=dns/txt; s=iport; t=1487209377; x=1488418977; h=from:to:cc:subject:date:message-id:mime-version; bh=NIPWpUd5lsbYcMxaUzeolehIplM/RDkIzz0gHUQ5gW0=; b=kr600nkIGV19aA90vLX/k1lpfZE7ANXBddlNqUVhrESCZL/mluwhvj6b WNPPc6fReyFFMysCkoSJg/PWQB4+8iI6460fxvD+/dXxIq8XudRdQ3S9w O7lii7PSOQWuKaA7r/PZQ+y1t9ZwADpauxqUo08TfwY286xPxX5/afxuQ 4=; X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CEAgCTAqVY/4YNJK1eGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBg1KBcY1akXGVVYIMhiKCFz8YAQIBAQEBAQEBYh0LhXASARxkJwQOE4l?= =?us-ascii?q?dsm+LOwEBAQEBAQEBAQEBAQEBAQEBAQEQD4hSCIJihHSDFIIxBYErAZpJAgGBT?= =?us-ascii?q?oIkggeMGpEGkxYBHziBAFFjAU+FYoo6gQwBAQE?= X-IronPort-AV: E=Sophos;i="5.35,167,1484006400"; d="asc'?scan'208";a="386178167" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Feb 2017 01:42:56 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v1G1guEb024747 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 16 Feb 2017 01:42:56 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 15 Feb 2017 19:42:55 -0600 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Wed, 15 Feb 2017 19:42:55 -0600 From: "Matt Miller (mamille2)" To: "secdir@ietf.org" Thread-Topic: Review of draft-draft-ietf-sidr-rpki-rtr-rfc6810-bis-08 Thread-Index: AQHSh/X+fRJZ/w0+LUaGVahbZOfhTw== Date: Thu, 16 Feb 2017 01:42:55 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.234.85] Content-Type: multipart/signed; boundary="Apple-Mail=_A19C5337-4B2C-49D9-B866-0E0F78A1B524"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-sidr-rpki-rtr-rfc6810-bis.all@ietf.org" Subject: [secdir] Review of draft-draft-ietf-sidr-rpki-rtr-rfc6810-bis-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 01:42:59 -0000 --Apple-Mail=_A19C5337-4B2C-49D9-B866-0E0F78A1B524 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii 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. Document: draft-ietf-sidr-rpki-rtr-rfc6810-bis-08 Reviewer: Matthew A. Miller Review Date: 2017-02-14 IETF LC End Date: 2017-01-30 IESG Telechat date: 2017-02-16 Summary: This document is ready for publication as a Proposed Standard, but has a minor concern that should be addressed. This document describes a protocol for distributing RPKI information to routers from trusted caches. Major issues: NONE Minor issues: * In Section 5.1. "Fields of a PDU", for the Flags: definition, it states that: """ The remaining bits in the flags field are reserved for future use. In protocol version 1, they MUST be 0 on transmission and SHOULD be ignored on receipt. """ However, this seems backwards to me. Would it seem safer that the reserved flags "MUST be ignored on receipt". Nits/editorial comments: NONE [posted to datatracker on 02-14] --Apple-Mail=_A19C5337-4B2C-49D9-B866-0E0F78A1B524 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJYpQOeAAoJEDWi+S0W7cO1UXsH/2+Zs8Ct5KZEKr6iCoQ1Kt/m SSzRbFLXZjfwBt2CJ/sNDfeCjdQFSzhydrFu/r4DlNCA5zRKxqBIiiTjZ0oUJBer dz6pbZrYoLNrVb116EyazSXY22HF/mJJd3STZ/GH4LPt5DCZbyBxlDiXQujmOJE6 MaZk+0tueJ2bfl8797TiJcbaEwYtRsRJZ9xuhRMDU4jiceKQ9wvm3FYL56eEXSHt VpDVja/D3nkrjIhgj/VoheowKhXnhTlBars7RzC4vglXFfC6IEeXbLX7UoKow8yX hVwrhbs//D4Ki+zNz5TlKkOKAP9StqRBpYk5ubw2m2qJJN4249UJU3DnOfc2epw= =emn2 -----END PGP SIGNATURE----- --Apple-Mail=_A19C5337-4B2C-49D9-B866-0E0F78A1B524-- From nobody Wed Feb 15 19:28:33 2017 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F883129CAF; Wed, 15 Feb 2017 19:28:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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 Fl6fMrtW-wRw; Wed, 15 Feb 2017 19:28:26 -0800 (PST) Received: from cmccmta1.chinamobile.com (cmccmta1.chinamobile.com [221.176.66.79]) by ietfa.amsl.com (Postfix) with ESMTP id 91C58129B7C; Wed, 15 Feb 2017 19:28:25 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.121.9]) by rmmx-syy-dmz-app01-12001 (RichMail) with SMTP id 2ee158a51c56a51-b5eae; Thu, 16 Feb 2017 11:28:23 +0800 (CST) X-RM-TRANSID: 2ee158a51c56a51-b5eae X-RM-SPAM-FLAG: 00000000 Received: from cmcc (unknown[10.2.51.86]) by rmsmtp-syy-appsvr05-12005 (RichMail) with SMTP id 2ee558a51c55332-a105d; Thu, 16 Feb 2017 11:28:23 +0800 (CST) X-RM-TRANSID: 2ee558a51c55332-a105d From: "Weiqiang Cheng" To: "'Brian Weis \(bew\)'" , "'secdir'" , "'The IESG'" References: In-Reply-To: Date: Thu, 16 Feb 2017 11:28:34 +0800 Message-ID: <004801d28804$c0f4c880$42de5980$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHSh86RoCQRkfSqMEO1mBfN/G3u7KFq+J0w Content-Language: zh-cn Archived-At: Cc: draft-ietf-pals-mpls-tp-dual-homing-coordination.all@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-pals-mpls-tp-dual-homing-coordination-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 03:28:28 -0000 Hi Brian, Thank you very much for your review and valuable comments. We authors will prepare some text about security considerations based on = your suggestions soon and send it back to you for review again. B.R. Weiqiang Cheng -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: Brian Weis (bew) [mailto:bew@cisco.com]=20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2017=E5=B9=B42=E6=9C=8816=E6=97=A5 = 5:01 =E6=94=B6=E4=BB=B6=E4=BA=BA: secdir; The IESG =E6=8A=84=E9=80=81: = draft-ietf-pals-mpls-tp-dual-homing-coordination.all@ietf.org =E4=B8=BB=E9=A2=98: Secdir review of = draft-ietf-pals-mpls-tp-dual-homing-coordination-05 I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. = These comments were written primarily for the benefit of the security = area directors. Document editors and WG chairs should treat these = comments just like any other last call comments. This document concerns a Dual-Node Interconnection (DNI) message, which = is carried over an already defined protocol ("G-ACh=E2=80=9D) placed = between a pair of MPLS-TP Provider Edge (PE) device. In this case, = =E2=80=9Cdual-homed=E2=80=9D means that both PE routers are connected to = a Customer Edge (CE) device. The two PE devices use the DNI to signal = which of the Pseudowires (PWs) leading from the PE devices into the = provider network currently is carrying the CE traffic.=20 The security considerations section in this document points to the = security considerations for G-ACh (RFC 5586), which in turn points to = RFC 4485. The security considerations for RFC 4485 basically says any = application using the channel should fully consider the resultant = security issues and provide mechanisms to stop attacks. I don=E2=80=99t = actually see any such analysis considering the security issues to the = DNI in this document, and I think that it would be good say a little = something about how the DNI could be mis-used by an attacker. Because of = this I consider this document to be Ready with Issues. Below I suggest = what might be the analysis and what could be added to the the security = considerations. The data carried in the DNI contains control data, which if an attacker = falsified or changed then the two PE devices might not agree on which = which PE should be sued to deliver the CE data, and this could be used = as a denial of service attack against the CE. If the G-ACh protocol ever = crosses an untrusted link where an attacker could make this attack then = it would be a good idea if the G-ACh protocol was integrity protected so = that the two PEs have confidence that the message arrived unmodified. = For example, I imagine that if the PE devices were in different data = centers, then probably the G-ACh protocol is vulnerable somewhere in the = network =E2=80=94 even if it=E2=80=99s all the same provider network. It = would be good to acknowledge this in the document by saying that if the = G-ACh protocol goes across an untrusted link that the DNI messages = should be integrity protected. I don=E2=80=99t see any TLVs defined for = the G-ACh that would provide integrity, and I=E2=80=99m not familiar = enough with MPLS-TE networks to know how that could be done, but a hint = to implementors saying how this could be done would also be a good idea. Brian From nobody Thu Feb 16 04:19:19 2017 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6345F129AB8 for ; Thu, 16 Feb 2017 04:19:17 -0800 (PST) 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.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148724755736.15933.9619550670855592295.idtracker@ietfa.amsl.com> Date: Thu, 16 Feb 2017 04:19:17 -0800 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 12:19:17 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2017-02-16 Reviewer LC end Draft Lt. Mundy 2017-01-26 draft-ietf-mpls-tp-linear-protection-mib-11 Sandra Murphy 2016-12-20 draft-ietf-6tisch-minimal-20 For telechat 2017-03-02 Reviewer LC end Draft Alan DeKok 2017-02-15 draft-bradner-rfc3979bis-11 Benjamin Kaduk R2017-01-17 draft-ietf-mpls-residence-time-13 Vincent Roca 2017-02-07 draft-ietf-nfsv4-rfc5666bis-10 Rich Salz 2017-03-01 draft-ietf-6man-rfc4291bis-07 Yaron Sheffer 2017-03-01 draft-ietf-6man-rfc2460bis-08 Melinda Shore 2017-02-27 draft-sgtatham-secsh-iutf8-05 Klaas Wierenga 2017-02-10 draft-ietf-dmm-hnprenum-06 Dacheng Zhang 2017-02-20 draft-ietf-httpbis-rfc5987bis-04 For telechat 2017-03-16 Reviewer LC end Draft John Bradley 2017-03-13 draft-mm-wg-effect-encrypt-07 Shawn Emery 2017-03-01 draft-ietf-pce-inter-layer-ext-12 Daniel Franke 2017-02-28 draft-ietf-pce-stateful-sync-optimizations-08 Daniel Gillmor 2017-02-28 draft-ietf-pce-stateful-pce-18 Ólafur Guðmundsson 2017-02-27 draft-ietf-dime-load-07 Last calls: Reviewer LC end Draft Derek Atkins None draft-ietf-i2nsf-problem-and-use-cases-09 Alan DeKok 2017-03-10 draft-bchv-rfc6890bis-04 Donald Eastlake 2017-03-09 draft-leiba-rfc2119-update-01 Tobias Gondrom 2017-02-27 draft-ietf-urnbis-rfc2141bis-urn-20 Phillip Hallam-Baker 2017-02-24 draft-ietf-dmm-lma-controlled-mag-params-03 Tom Yu 2017-02-20 draft-ietf-slim-negotiating-human-language-06 Early review requests: Reviewer Due Draft Daniel Gillmor 2016-02-01 draft-ietf-rtcweb-security-08 Brian Weis 2016-02-01 draft-ietf-cdni-uri-signing-10 Next in the reviewer rotation: Dan Harkins Paul Hoffman Russ Housley Christian Huitema Leif Johansson Benjamin Kaduk Charlie Kaufman Scott Kelly Stephen Kent Tero Kivinen From nobody Sun Feb 19 19:12:47 2017 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C4DE12943A; Sun, 19 Feb 2017 19:12:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aG6h3nIqalUZ; Sun, 19 Feb 2017 19:12:40 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 650BA1293EE; Sun, 19 Feb 2017 19:12:39 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DAX12859; Mon, 20 Feb 2017 03:12:37 +0000 (GMT) Received: from LHREML710-CAH.china.huawei.com (10.201.108.33) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 20 Feb 2017 03:12:36 +0000 Received: from SZXEMI415-HUB.china.huawei.com (10.86.210.48) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 20 Feb 2017 03:12:35 +0000 Received: from SZXEMI502-MBX.china.huawei.com ([169.254.5.216]) by SZXEMI415-HUB.china.huawei.com ([10.86.210.48]) with mapi id 14.03.0235.001; Mon, 20 Feb 2017 11:12:32 +0800 From: zhangdacheng To: "'secdir'" , "'The IESG'" Thread-Topic: Review of draft-ietf-httpbis-rfc5987bis-04 Thread-Index: AdKLJTvGJswF18oXQ9qocLPojVvtjA== Date: Mon, 20 Feb 2017 03:12:31 +0000 Message-ID: <879E76B64CF340468BF5E4DE504C2242C17179@szxemi502-mbx.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.167.227] Content-Type: multipart/alternative; boundary="_000_879E76B64CF340468BF5E4DE504C2242C17179szxemi502mbxchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090206.58AA5EA5.007D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.216, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: c4e71fab1af2012a37141d4b6f1b79a7 Archived-At: Cc: "draft-ietf-httpbis-rfc5987bis.all@ietf.org" Subject: [secdir] Review of draft-ietf-httpbis-rfc5987bis-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2017 03:12:42 -0000 --_000_879E76B64CF340468BF5E4DE504C2242C17179szxemi502mbxchina_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These com= ments were written primarily for the benefit of the security area directors= . Document editors and WG chairs should treat these comments just like any = other last call comments. This document specifies an encoding suitable for use in HTTP header fields = that is compatible with a simplified profile of the encoding defined in RFC= 2231, and obsoletes RFC5987. Compared to RFC 5987, the updates in this document does not introduce any a= dditional security considerations, and the contents in the security conside= rations section is exactly identical to the counterparts in RFC 5987. So, I= agree this document is ready for publication as Proposed Standard. Cheers Dacheng --_000_879E76B64CF340468BF5E4DE504C2242C17179szxemi502mbxchina_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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

 

This document specifies an encoding suitable for use in HTTP header= fields that is compatible with a simplified profile of the encoding defined in RFC2231, and obsoletes RFC= 5987.

 

Compared to RFC 5987, the up= dates in this document does not introduce any additional security considera= tions, and the contents in the security considerations section is exactly i= dentical to the counterparts in RFC 5987. So, I agree this document is ready for publication as Proposed Stand= ard.

 

Cheers

 

Dacheng

 

--_000_879E76B64CF340468BF5E4DE504C2242C17179szxemi502mbxchina_-- From nobody Mon Feb 20 03:26:27 2017 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 823781299AA; Mon, 20 Feb 2017 02:11:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1487585464; bh=CpAsqJU8Plt7OsDdFX5gMwk9dgFQpZMhBPu0KhnLFk0=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=lhaB1T2TRm83rI/DY9sC/UDfd/WbuaGh4HwN/rYiiGUOVSiAPpNRCyaYyQ/vwsJwr plS8grp050rHPTgK9BDotOQxITCIHid7bXgAKaVYBmljXEv6Tua4U4NXmjDVR19ae7 r4Cb9AIe67AldI1bU4n3J4F78n1OJJrtbPEffqcI= 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 953481299AA for ; Mon, 20 Feb 2017 02:11:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.902 X-Spam-Level: X-Spam-Status: No, score=-0.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fhLXMyWkx8dz for ; Mon, 20 Feb 2017 02:11:02 -0800 (PST) Received: from raoul.w3.org (raoul.w3.org [IPv6:2001:470:8b2d:804:52:12:128:0]) (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 34B87129999 for ; Mon, 20 Feb 2017 02:11:02 -0800 (PST) Received: from [2001:da8:203:80:2c7d:f4bf:8592:a499] by raoul.w3.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1cfkvs-0009Cg-Tt for new-work@ietf.org; Mon, 20 Feb 2017 10:11:01 +0000 To: new-work@ietf.org From: Xueyuan Jia Message-ID: Date: Mon, 20 Feb 2017 18:13:01 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Mon, 20 Feb 2017 03:26:26 -0800 Subject: [secdir] [new-work] Proposed W3C Charter: Web Application Security Working Group (until 2017-03-20) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2017 10:11:04 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to review a draft charter for the Web Application Security Working Group: https://www.w3.org/2011/webappsec/charter-2017.html As part of ensuring that the community is aware of proposed work at W3C, this draft charter is public during the Advisory Committee review period. W3C invites public comments through 2017-03-20 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 Wendy Seltzer, W3C Strategy Lead and Team Contact, at . Thank you, Xueyuan Jia, W3C Marketing & Communications [1] http://www.w3.org/Consortium/Member/List _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Tue Feb 21 09:22:24 2017 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D64112943D; Tue, 21 Feb 2017 09:22:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iz4vMVggJMij; Tue, 21 Feb 2017 09:22:20 -0800 (PST) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 4D83B1296CE; Tue, 21 Feb 2017 09:22:19 -0800 (PST) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 87510200007; Tue, 21 Feb 2017 17:22:17 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 716FE200005; Tue, 21 Feb 2017 17:22:17 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1487697737; bh=35AeFiLTpBTpoXH3VBWbqvCiQwqGcQlKck2o28C1tZw=; l=4559; h=From:To:Date:From; b=tUtxiMPurNvJ5AiwWW+eLiXZ3Gdgyi1MyJ7HA3AAl9sHfOsSZ+lKczPs6G8ttAWA1 Pt2KfW7Adzf34eR9HpHKTBvwGpoubkyxaAf+AjoIUQwvDm1h7Sqw8wdlKSrb6e8X97 ckWGS3YxyGKW988+QluHCOaUcThYlFcLVuufyGVg= Received: from email.msg.corp.akamai.com (usma1ex-casadmn.msg.corp.akamai.com [172.27.123.33]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 580601E07C; Tue, 21 Feb 2017 17:22:17 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 21 Feb 2017 12:22:16 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Tue, 21 Feb 2017 12:22:16 -0500 From: "Salz, Rich" To: "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-6man-rfc4291bis.all@ietf.org" Thread-Topic: secdir review of draft-ietf-6man-rfc4291bis -- ready with nits Thread-Index: AdKMYxPb+Mr9HztxT5aIisKQe4P/Ig== Date: Tue, 21 Feb 2017 17:22:16 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.178] Content-Type: multipart/alternative; boundary="_000_de698290c467420da1cb839bdd98d6cbusma1exdag1mb1msgcorpak_" MIME-Version: 1.0 Archived-At: Subject: [secdir] secdir review of draft-ietf-6man-rfc4291bis -- ready with nits X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 17:22:22 -0000 --_000_de698290c467420da1cb839bdd98d6cbusma1exdag1mb1msgcorpak_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments. Summary: ready with nits. Sec 2.1, What's the meaning of scope? Sec 2.2.3, Example 3, should the incorrect example be ":2:1" (i.e., add a m= issing colon and digit two) Is it worth mentioning that :: is only valid for the ipv6 syntax and not th= e dotted ipv4 syntax? (Just asking, not recommending) Sec 2.4.1, penultimate paragraph: looks like some words got chopped from = the middle line? The security section is fine. -- Senior Architect, Akamai Technologies Member, OpenSSL Dev Team IM: richsalz@jabber.at Twitter: RichSalz --_000_de698290c467420da1cb839bdd98d6cbusma1exdag1mb1msgcorpak_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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

 

Summary: ready with nits.

 

Sec 2.1, What’s the meaning of scope?

 

Sec 2.2.3, Example 3, should the incorrect example b= e “:2:1” (i.e., add a missing colon and digit two)

Is it worth mentioning that :: is only valid for the= ipv6 syntax and not the dotted ipv4 syntax?  (Just asking, not recomm= ending)

 

Sec 2.4.1, penultimate paragraph:   looks = like some words got chopped from the middle line?

 

The security section is fine.

 

-- 

Senior Architect, Akamai Technologies

Member, OpenSSL Dev Team

IM: richsalz@jabber.at Twitter: RichSalz<= /p>

 

--_000_de698290c467420da1cb839bdd98d6cbusma1exdag1mb1msgcorpak_-- From nobody Thu Feb 23 04:25:36 2017 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 375FD1296E8 for ; Thu, 23 Feb 2017 04:25:35 -0800 (PST) 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.45.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148785273518.20228.9397069683439143093.idtracker@ietfa.amsl.com> Date: Thu, 23 Feb 2017 04:25:35 -0800 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 12:25:35 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2017-03-02 Reviewer LC end Draft Alan DeKok 2017-02-15 draft-bradner-rfc3979bis-11 Tobias Gondrom 2017-02-27 draft-ietf-urnbis-rfc2141bis-urn-20 Benjamin Kaduk R2017-01-17 draft-ietf-mpls-residence-time-14 Vincent Roca 2017-02-07 draft-ietf-nfsv4-rfc5666bis-10 Yaron Sheffer 2017-03-01 draft-ietf-6man-rfc2460bis-08 Melinda Shore 2017-02-27 draft-sgtatham-secsh-iutf8-05 Klaas Wierenga 2017-02-10 draft-ietf-dmm-hnprenum-06 For telechat 2017-03-16 Reviewer LC end Draft John Bradley 2017-03-13 draft-mm-wg-effect-encrypt-07 Alan DeKok 2017-03-10 draft-bchv-rfc6890bis-04 Shawn Emery 2017-03-01 draft-ietf-pce-inter-layer-ext-12 Daniel Franke 2017-02-28 draft-ietf-pce-stateful-sync-optimizations-08 Daniel Gillmor 2017-02-28 draft-ietf-pce-stateful-pce-18 Ólafur Guðmundsson 2017-02-27 draft-ietf-dime-load-07 Dan Harkins None draft-ietf-rtcweb-overview-17 Paul Hoffman 2017-03-08 draft-ietf-lmap-yang-11 Christian Huitema None draft-ietf-ipsecme-rfc7321bis-04 Leif Johansson 2017-03-08 draft-ietf-lmap-information-model-17 Benjamin Kaduk 2017-03-07 draft-ietf-jsonbis-rfc7159bis-03 Charlie Kaufman 2017-03-06 draft-ietf-httpbis-http2-encryption-10 Scott Kelly 2017-03-03 draft-ietf-tls-rfc4492bis-12 Tero Kivinen 2017-03-03 draft-ietf-mpls-tp-temporal-hitless-psm-12 Watson Ladd 2017-03-03 draft-ietf-dane-smime-15 Last calls: Reviewer LC end Draft Derek Atkins None draft-ietf-i2nsf-problem-and-use-cases-09 Donald Eastlake 2017-03-09 draft-leiba-rfc2119-update-01 Phillip Hallam-Baker 2017-02-24 draft-ietf-dmm-lma-controlled-mag-params-03 Ben Laurie 2017-03-02 draft-ietf-dprive-dtls-and-tls-profiles-08 Barry Leiba 2017-03-02 draft-ietf-anima-grasp-09 Tom Yu 2017-02-20 draft-ietf-slim-negotiating-human-language-07 Early review requests: Reviewer Due Draft Daniel Gillmor 2016-02-01 draft-ietf-rtcweb-security-08 Brian Weis 2016-02-01 draft-ietf-cdni-uri-signing-10 Next in the reviewer rotation: Chris Lonvick David Mandelberg Catherine Meadows Alexey Melnikov Matthew Miller Adam Montville Russ Mundy Sandra Murphy Yoav Nir Magnus Nystrom From nobody Fri Feb 24 04:59:56 2017 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D644A129694; Fri, 24 Feb 2017 04:59:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 PhWNsZQvN8KQ; Fri, 24 Feb 2017 04:59:49 -0800 (PST) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (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 12A341296CD; Fri, 24 Feb 2017 04:59:48 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.35,201,1484002800"; d="scan'208,217";a="261943924" Received: from dom38-1-82-236-155-50.fbx.proxad.net (HELO [192.168.1.149]) ([82.236.155.50]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Feb 2017 13:59:46 +0100 From: Vincent Roca Content-Type: multipart/alternative; boundary="Apple-Mail=_A2109949-94DD-4124-A7BB-223F130803B2" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Message-Id: Date: Fri, 24 Feb 2017 13:59:44 +0100 To: IESG , secdir@ietf.org, draft-ietf-nfsv4-rfc5666bis.all@ietf.org X-Mailer: Apple Mail (2.3259) Archived-At: Subject: [secdir] Secdir review of draft-ietf-nfsv4-rfc5666bis-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 12:59:52 -0000 --Apple-Mail=_A2109949-94DD-4124-A7BB-223F130803B2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello, I have reviewed this document as part of the security directorate=E2=80=99= s ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments = just like any other last call comments. Summary: ready with issues Main comments: A long and detailed Security considerations section is provided, which = is clearly a good thing. However I have a few comments WRT this section: ** Privacy or confidentiality? Throughout section 8, authors mention = "Privacy" inappropriately IMHO. Privacy refers to PII (Personally identifiable information) which is = different. For instance in section 8.2, when saying: "However, integrity and privacy services require significant = movement of data on each endpoint host." the authors really mean confidentiality (this is mentioned just above, = when saying that RPCSEC_GSS implements "per-message confidentiality"). There are several mistakes of that kind = throughout section 8. ** On the opposite, meta-data can raise privacy issues, regardless of = whether the content is encrypted or not. Can an eavesdropper who observes the traffic from an intermediate node = (for instance) derive these meta-data and identify the hosts that communicate together, at what frequency, = when? It probably depends on the protection provided (IPsec versus other = RPCSEC integrated approach if I understand correctly). However if this is the case then there can be privacy = impacts... Is it the case, this is not detailed? ** Section 8.1: it is said: "The use of RPC-over-RDMA MUST NOT introduce any vulnerabilities = to system memory contents, nor to memory owned by user processes." This is of course highly desirable, but how can the destination be sure = that data copied in its own memory does not contain a malware? I have the feeling (but may be wrong) that there's a = confusion between the RPC-over-RDMA=20 **protocol** that MUST be secure, and the **content** transferred = between two hosts where it's more a matter of trust between them. ** Section 8.2.2.1: What happens when there's no TCP based NFS server on = port 2049? The authors could be more explicit and provide guidance. ** Section 8.2.2.4: There's something that is not clear to me. It is said that "IDs, connection credit limits, and chunk lists" are = exposed and if an attacker alters them, several consequences are possible. I understand that this information **is not** included in the RPCSEC_GSS = integrity verifications. Is it really the case? I'm asking this because the paragraph concludes = with: "The use of RPCSEC_GSS integrity or privacy services enable the = requester to detect if such tampering=20 has been done and reject the RPC message." which suggests that this information **is** protected. ** Last sentence: "To address attacks on RDMA protocols themselves, RDMA transport = implementations should conform to [RFC5042]." "should" or "SHOULD"? Minor comments: - A side comment: can we really say that IPsec can be co-located in RDMA = hardware "without any [...] loss of=20 data movement efficiency"? I'd rather say that the IPsec performance = impacts can be **greatly reduced**. - Typo in Introduction: "future NFSv4 minor verions" =3D> versions Cheers, Vincent --Apple-Mail=_A2109949-94DD-4124-A7BB-223F130803B2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello,

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


Summary: ready with issues
Main comments:

A long and = detailed Security considerations section is provided, which is clearly a = good thing. However I have
a few comments WRT this = section:

** Privacy or confidentiality? = Throughout section 8, authors mention "Privacy" inappropriately = IMHO.
Privacy refers to PII (Personally = identifiable information) which is different. For instance in section = 8.2, when saying:
    =     "However, integrity and privacy services require = significant movement of data on each endpoint host."
the authors really mean confidentiality (this is mentioned = just above, when saying that RPCSEC_GSS implements
"per-message confidentiality"). There are several mistakes of = that kind throughout section 8.


** = On the opposite, meta-data can raise privacy issues, regardless of = whether the content is encrypted or not.
Can an = eavesdropper who observes the traffic from an intermediate node (for = instance) derive these meta-data
and identify the = hosts that communicate together, at what frequency, when?
It probably depends on the protection provided (IPsec versus = other RPCSEC integrated approach if I understand
correctly). However if this is the case then there can be = privacy impacts... Is it the case, this is not detailed?


** Section 8.1: it is said:
  =       "The use of RPC-over-RDMA MUST NOT introduce any = vulnerabilities to system memory contents, nor to
= memory owned by user processes."
This is of = course highly desirable, but how can the destination be sure that data = copied in its own memory does not
contain a = malware? I have the feeling (but may be wrong) that there's a confusion = between the RPC-over-RDMA 
**protocol** that = MUST be secure, and the **content** transferred between two hosts where = it's more a matter of
trust between them.


** Section 8.2.2.1: What happens when there's no TCP based = NFS server on port 2049? The authors could be
more = explicit and provide guidance.


** = Section 8.2.2.4: There's something that is not clear to me.
It is said that "IDs, connection credit limits, and chunk = lists" are exposed and if an attacker alters them, several
consequences are possible.
I understand = that this information **is not** included in the RPCSEC_GSS integrity = verifications.
Is it really the case?  I'm = asking this because the paragraph concludes with:
        "The use of RPCSEC_GSS integrity = or privacy services enable the requester to detect if such = tampering 
has been done and reject the RPC = message."
which suggests that this information = **is** protected.


** Last = sentence:
"To address attacks on RDMA = protocols themselves, RDMA transport implementations should = conform
to [RFC5042]."
"should" or "SHOULD"?


Minor comments:

- A side comment: can we really say = that IPsec can be co-located in RDMA hardware "without any [...] loss = of 
data movement efficiency"? I'd rather say = that the IPsec performance impacts can be **greatly reduced**.

- Typo in Introduction: = "future NFSv4 minor verions" =3D> versions


Cheers,

   Vincent

= --Apple-Mail=_A2109949-94DD-4124-A7BB-223F130803B2-- From nobody Fri Feb 24 10:58:01 2017 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A49ED1294CC; Fri, 24 Feb 2017 10:57:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.088 X-Spam-Level: X-Spam-Status: No, score=-6.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-1.887, RP_MATCHES_RCVD=-0.001, 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 xSDYUh3HqvMS; Fri, 24 Feb 2017 10:57:58 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 3D565129486; Fri, 24 Feb 2017 10:57:58 -0800 (PST) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v1OIvvhi032315 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 24 Feb 2017 18:57:57 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v1OIvuf0007225 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 24 Feb 2017 18:57:56 GMT Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v1OIvtAJ028248; Fri, 24 Feb 2017 18:57:55 GMT Received: from dhcp-whq-5op-3rd-and-4th-floor-gen-off-10-211-47-189.usdhcp.oraclecorp.com (/10.211.47.189) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 24 Feb 2017 10:57:55 -0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Chuck Lever In-Reply-To: Date: Fri, 24 Feb 2017 10:57:53 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Vincent Roca X-Mailer: Apple Mail (2.3124) X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Cc: IESG , draft-ietf-nfsv4-rfc5666bis.all@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-nfsv4-rfc5666bis-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 18:58:00 -0000 > On Feb 24, 2017, at 4:59 AM, Vincent Roca = wrote: >=20 > Hello, >=20 > I have reviewed this document as part of the security directorate=E2=80=99= s ongoing > effort to review all IETF documents being processed by the IESG. These > comments were written primarily for the benefit of the security area > directors. Document editors and WG chairs should treat these comments = just > like any other last call comments. >=20 >=20 > Summary: ready with issues >=20 > Main comments: >=20 > A long and detailed Security considerations section is provided, which = is clearly a good thing. However I have > a few comments WRT this section: Hi Vincent- Thanks for your review. I believe your questions are mostly rhetorical, so I will respond to those by saying the authors, shepherd, and AD will attempt to address these issues with the next document revision. There is one remaining comment that IMO needs group discussion, below. > ** Privacy or confidentiality? Throughout section 8, authors mention = "Privacy" inappropriately IMHO. > Privacy refers to PII (Personally identifiable information) which is = different. For instance in section 8.2, when saying: > "However, integrity and privacy services require significant = movement of data on each endpoint host." > the authors really mean confidentiality (this is mentioned just above, = when saying that RPCSEC_GSS implements > "per-message confidentiality"). There are several mistakes of that = kind throughout section 8. >=20 >=20 > ** On the opposite, meta-data can raise privacy issues, regardless of = whether the content is encrypted or not. > Can an eavesdropper who observes the traffic from an intermediate node = (for instance) derive these meta-data > and identify the hosts that communicate together, at what frequency, = when? > It probably depends on the protection provided (IPsec versus other = RPCSEC integrated approach if I understand > correctly). However if this is the case then there can be privacy = impacts... Is it the case, this is not detailed? >=20 >=20 > ** Section 8.1: it is said: > "The use of RPC-over-RDMA MUST NOT introduce any = vulnerabilities to system memory contents, nor to > memory owned by user processes." > This is of course highly desirable, but how can the destination be = sure that data copied in its own memory does not > contain a malware? I have the feeling (but may be wrong) that there's = a confusion between the RPC-over-RDMA=20 > **protocol** that MUST be secure, and the **content** transferred = between two hosts where it's more a matter of > trust between them. >=20 >=20 > ** Section 8.2.2.1: What happens when there's no TCP based NFS server = on port 2049? The authors could be > more explicit and provide guidance. >=20 >=20 > ** Section 8.2.2.4: There's something that is not clear to me. > It is said that "IDs, connection credit limits, and chunk lists" are = exposed and if an attacker alters them, several > consequences are possible. > I understand that this information **is not** included in the = RPCSEC_GSS integrity verifications. > Is it really the case? I'm asking this because the paragraph = concludes with: > "The use of RPCSEC_GSS integrity or privacy services enable = the requester to detect if such tampering=20 > has been done and reject the RPC message." > which suggests that this information **is** protected. >=20 >=20 > ** Last sentence: > "To address attacks on RDMA protocols themselves, RDMA transport = implementations should conform > to [RFC5042]." > "should" or "SHOULD"? Lower case "should" is used here because this statement is IMO not an interoperability directive. I hope I correctly understand the intent of your question. If there is a security requirement that this be changed to the RFC 2119 term, please let us know and that can be done. Any other thoughts about this? > Minor comments: >=20 > - A side comment: can we really say that IPsec can be co-located in = RDMA hardware "without any [...] loss of=20 > data movement efficiency"? I'd rather say that the IPsec performance = impacts can be **greatly reduced**. >=20 > - Typo in Introduction: "future NFSv4 minor verions" =3D> versions >=20 >=20 > Cheers, >=20 > Vincent >=20 -- Chuck Lever From nobody Fri Feb 24 13:28:47 2017 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7CEC129515; Fri, 24 Feb 2017 13:28:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.889 X-Spam-Level: X-Spam-Status: No, score=-3.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.887, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WIBjXt9xFpTr; Fri, 24 Feb 2017 13:28:43 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0092.outbound.protection.outlook.com [104.47.36.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0D93129513; Fri, 24 Feb 2017 13:28:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=mqQCLpvBmCq/yPUSDGBoSohg+gQeBTAKak8ey82NqsI=; b=V/JucEAEPy2uKNU20WqfD4ptOA8kjdfdl7BLYCDlMQGSnPYScxXIQh7dPZK4cfxRtf+pNZ/rt+2MOjEPtEtXYzKndFd5Fy/hm5GCrOsWbKTGb5IDTN624R28s7TJ8EsqBr3MNWLIfbHpWvDwOJuDngDk5v/Kx91lH2+H2xjXd1A= Received: from BN6PR03MB2449.namprd03.prod.outlook.com (10.168.223.15) by BN6PR03MB2452.namprd03.prod.outlook.com (10.168.223.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.919.13; Fri, 24 Feb 2017 21:28:39 +0000 Received: from BN6PR03MB2449.namprd03.prod.outlook.com ([10.168.223.15]) by BN6PR03MB2449.namprd03.prod.outlook.com ([10.168.223.15]) with mapi id 15.01.0933.016; Fri, 24 Feb 2017 21:28:39 +0000 From: Tom Talpey To: Chuck Lever , Vincent Roca Thread-Topic: Secdir review of draft-ietf-nfsv4-rfc5666bis-10 Thread-Index: AQHSjp3mwI+h0fJJDU2WX5plDQmD9qF4gpGAgAAncYA= Date: Fri, 24 Feb 2017 21:28:37 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: oracle.com; dkim=none (message not signed) header.d=none;oracle.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [24.218.182.144] x-ms-office365-filtering-correlation-id: 6d540d58-536a-448b-2f08-08d45cfc1978 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN6PR03MB2452; x-microsoft-exchange-diagnostics: 1; BN6PR03MB2452; 7:LqoLODWs5fQYRschohh2T1cbeXHPjYuG7hbzylsEdpDQH8xfiWEHM3Zx0b/iP97GJKVE0lmDSq05lNKyYigCaD0NZe4kP4I7rEj7AbQHXLs0QjMYcfuSsdLCH63opB2oWqXgz0ZWMAtPRbs8IlcLKaW+ALQKZ+GdcOHv3LBDT6oOxc7yS4T4jYexkFACkFiAkZczrccjmLcxRLW3PPU04SYPrYekKbWcv/fUS3FWTg919AMgdCjn4q+GhAS51m4/CvxAU0pFnuHXQIBUimbuiKdEGd9+YsVpDFiJ1uzSjw99xzaeaE49y4cRaaEq6ZuOjYSRUzv+r/y/ckKBqOggRqS1twzUOz5fjU9TYnyz5NY= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(146099531331640); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123558025)(20161123564025)(20161123562025)(20161123560025)(20161123555025)(6072148)(6042181); SRVR:BN6PR03MB2452; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2452; x-forefront-prvs: 0228DDDDD7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(24454002)(377454003)(13464003)(38730400002)(10290500002)(5005710100001)(53546006)(77096006)(8990500004)(8676002)(2950100002)(6506006)(74316002)(6436002)(54906002)(122556002)(9686003)(10090500001)(4326007)(33656002)(55016002)(86612001)(92566002)(3280700002)(25786008)(99286003)(6116002)(7696004)(3846002)(102836003)(53936002)(3660700001)(76176999)(230783001)(5660300001)(189998001)(54356999)(7736002)(305945005)(106116001)(6246003)(81166006)(229853002)(2906002)(66066001)(8936002)(50986999); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2452; H:BN6PR03MB2449.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Feb 2017 21:28:37.7118 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2452 Archived-At: Cc: IESG , "draft-ietf-nfsv4-rfc5666bis.all@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-nfsv4-rfc5666bis-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 21:28:44 -0000 W2VsaWRpbmcgc29tZSBsaW5lcyBmb3IgYnJldml0eV0NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiBGcm9tOiBDaHVjayBMZXZlciBbbWFpbHRvOmNodWNrLmxldmVyQG9yYWNsZS5j b21dDQo+IFNlbnQ6IEZyaWRheSwgRmVicnVhcnkgMjQsIDIwMTcgMTo1OCBQTQ0KPiBUbzogVmlu Y2VudCBSb2NhIDx2aW5jZW50LnJvY2FAaW5yaWEuZnI+DQo+IENjOiBJRVNHIDxpZXNnQGlldGYu b3JnPjsgc2VjZGlyQGlldGYub3JnOyBkcmFmdC1pZXRmLW5mc3Y0LQ0KPiByZmM1NjY2YmlzLmFs bEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogU2VjZGlyIHJldmlldyBvZiBkcmFmdC1pZXRmLW5m c3Y0LXJmYzU2NjZiaXMtMTANCj4gDQo+IA0KPiA+IE9uIEZlYiAyNCwgMjAxNywgYXQgNDo1OSBB TSwgVmluY2VudCBSb2NhIDx2aW5jZW50LnJvY2FAaW5yaWEuZnI+IHdyb3RlOg0KPiA+DQo+ID4g SGVsbG8sDQo+ID4NCj4gPiBJIGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhcyBwYXJ0IG9m IHRoZSBzZWN1cml0eSBkaXJlY3RvcmF0ZeKAmXMNCj4gPiBvbmdvaW5nIGVmZm9ydCB0byByZXZp ZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUNCj4gPiBJRVNHLiBU aGVzZSBjb21tZW50cyB3ZXJlIHdyaXR0ZW4gcHJpbWFyaWx5IGZvciB0aGUgYmVuZWZpdCBvZiB0 aGUNCj4gPiBzZWN1cml0eSBhcmVhIGRpcmVjdG9ycy4gIERvY3VtZW50IGVkaXRvcnMgYW5kIFdH IGNoYWlycyBzaG91bGQgdHJlYXQNCj4gPiB0aGVzZSBjb21tZW50cyBqdXN0IGxpa2UgYW55IG90 aGVyIGxhc3QgY2FsbCBjb21tZW50cy4NCj4uLi4gDQo+IEhpIFZpbmNlbnQtDQo+IA0KPiBUaGFu a3MgZm9yIHlvdXIgcmV2aWV3Lg0KPiANCj4gSSBiZWxpZXZlIHlvdXIgcXVlc3Rpb25zIGFyZSBt b3N0bHkgcmhldG9yaWNhbCwgc28gSSB3aWxsIHJlc3BvbmQgdG8gdGhvc2UgYnkNCj4gc2F5aW5n IHRoZSBhdXRob3JzLCBzaGVwaGVyZCwgYW5kIEFEIHdpbGwgYXR0ZW1wdCB0byBhZGRyZXNzIHRo ZXNlIGlzc3VlcyB3aXRoDQo+IHRoZSBuZXh0IGRvY3VtZW50IHJldmlzaW9uLg0KPiANCj4gVGhl cmUgaXMgb25lIHJlbWFpbmluZyBjb21tZW50IHRoYXQgSU1PIG5lZWRzIGdyb3VwIGRpc2N1c3Np b24sIGJlbG93Lg0KPiANCj4gDQo+ID4gKiogUHJpdmFjeSBvciBjb25maWRlbnRpYWxpdHk/IFRo cm91Z2hvdXQgc2VjdGlvbiA4LCBhdXRob3JzIG1lbnRpb24NCj4gIlByaXZhY3kiIGluYXBwcm9w cmlhdGVseSBJTUhPLg0KPiA+IFByaXZhY3kgcmVmZXJzIHRvIFBJSSAoUGVyc29uYWxseSBpZGVu dGlmaWFibGUgaW5mb3JtYXRpb24pIHdoaWNoIGlzIGRpZmZlcmVudC4NCj4gRm9yIGluc3RhbmNl IGluIHNlY3Rpb24gOC4yLCB3aGVuIHNheWluZzoNCj4gPiAgICAgICAgICJIb3dldmVyLCBpbnRl Z3JpdHkgYW5kIHByaXZhY3kgc2VydmljZXMgcmVxdWlyZSBzaWduaWZpY2FudCBtb3ZlbWVudCBv Zg0KPiBkYXRhIG9uIGVhY2ggZW5kcG9pbnQgaG9zdC4iDQo+ID4gdGhlIGF1dGhvcnMgcmVhbGx5 IG1lYW4gY29uZmlkZW50aWFsaXR5ICh0aGlzIGlzIG1lbnRpb25lZCBqdXN0IGFib3ZlLA0KPiA+ IHdoZW4gc2F5aW5nIHRoYXQgUlBDU0VDX0dTUyBpbXBsZW1lbnRzICJwZXItbWVzc2FnZSBjb25m aWRlbnRpYWxpdHkiKS4NCj4gVGhlcmUgYXJlIHNldmVyYWwgbWlzdGFrZXMgb2YgdGhhdCBraW5k IHRocm91Z2hvdXQgc2VjdGlvbiA4Lg0KDQpSZWdhcmRpbmcgInByaXZhY3kiLCB0aGlzIHRlcm0g aXMgdXNlZCBpbiB0aGUgZG9jdW1lbnQgYmVjYXVzZSBhbGwgdGhlIE5GUyBSRkMncyB1c2UgaXQg aW4gdGhpcyB3YXkuIFdoaWxlIEkgYWdyZWUgd2l0aCB5b3UgdGhhdCB0aGVyZSBpcyByb29tIGZv ciBjb25mdXNpb24sIGl0IHdvdWxkIGJlIGV2ZW4gd2lkZXIgaWYgd2Ugc3dpdGNoZWQgdGVybWlu b2xvZ3kgaGVyZS4NCg0KPi4uLg0KPiA+ICoqIExhc3Qgc2VudGVuY2U6DQo+ID4gCSJUbyBhZGRy ZXNzIGF0dGFja3Mgb24gUkRNQSBwcm90b2NvbHMgdGhlbXNlbHZlcywgUkRNQSB0cmFuc3BvcnQN Cj4gaW1wbGVtZW50YXRpb25zIHNob3VsZCBjb25mb3JtDQo+ID4gCXRvIFtSRkM1MDQyXS4iDQo+ ID4gInNob3VsZCIgb3IgIlNIT1VMRCI/DQo+IA0KPiBMb3dlciBjYXNlICJzaG91bGQiIGlzIHVz ZWQgaGVyZSBiZWNhdXNlIHRoaXMgc3RhdGVtZW50IGlzIElNTyBub3QgYW4NCj4gaW50ZXJvcGVy YWJpbGl0eSBkaXJlY3RpdmUuIEkgaG9wZSBJIGNvcnJlY3RseSB1bmRlcnN0YW5kIHRoZSBpbnRl bnQgb2YgeW91cg0KPiBxdWVzdGlvbi4NCj4gDQo+IElmIHRoZXJlIGlzIGEgc2VjdXJpdHkgcmVx dWlyZW1lbnQgdGhhdCB0aGlzIGJlIGNoYW5nZWQgdG8gdGhlIFJGQyAyMTE5IHRlcm0sDQo+IHBs ZWFzZSBsZXQgdXMga25vdyBhbmQgdGhhdCBjYW4gYmUgZG9uZS4NCg0KSSBkb24ndCB0aGluayBT SE9VTEQgaXMgYXBwcm9wcmlhdGUgaGVyZS4gVGhpcyBzdGF0ZW1lbnQgcmVmZXJzIHRvIG90aGVy IHByb3RvY29scywgaW4gcGFydGljdWxhciBsb3dlciBsYXllcnMgdGhlbiB0aGlzIGRvY3VtZW50 LCBhbmQgaW4gdGhlIGNhc2Ugb2YgdGhlIHJlbGV2YW50IElFVEYgUkRNQSBwcm90b2NvbHMsIFJG QzUwNDIgaXMgYWxyZWFkeSBhIHJlcXVpcmVkIGNvbmZvcm1hbmNlLiBUaGVyZWZvcmUgdGhlIHN0 YXRlbWVudCBpcyBpbmZvcm1hdGlvbmFsIGhlcmUsIGFuZCBub3QgYW4gUkZDMjExOSB1c2FnZS4N Cg0KVG9tLg0KDQo= From nobody Fri Feb 24 13:37:49 2017 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BBB312951E; Fri, 24 Feb 2017 13:37:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.088 X-Spam-Level: X-Spam-Status: No, score=-6.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-1.887, RP_MATCHES_RCVD=-0.001, 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 oN83oqjtVhoz; Fri, 24 Feb 2017 13:37:46 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (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 735E11294F8; Fri, 24 Feb 2017 13:37:46 -0800 (PST) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v1OLbigb014180 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 24 Feb 2017 21:37:45 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v1OLbifv003169 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 24 Feb 2017 21:37:44 GMT Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v1OLbhuR008956; Fri, 24 Feb 2017 21:37:43 GMT Received: from dhcp-whq-5op-3rd-and-4th-floor-gen-off-10-211-47-189.usdhcp.oraclecorp.com (/10.211.47.189) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 24 Feb 2017 13:37:43 -0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Chuck Lever In-Reply-To: Date: Fri, 24 Feb 2017 13:37:41 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <96F6D457-9FCA-4A66-ACCB-4F55EB91DBDD@oracle.com> References: To: Tom Talpey , Vincent Roca X-Mailer: Apple Mail (2.3124) X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Cc: IESG , "draft-ietf-nfsv4-rfc5666bis.all@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-nfsv4-rfc5666bis-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 21:37:48 -0000 > On Feb 24, 2017, at 1:28 PM, Tom Talpey wrote: >=20 > [eliding some lines for brevity] >=20 >> -----Original Message----- >> From: Chuck Lever [mailto:chuck.lever@oracle.com] >> Sent: Friday, February 24, 2017 1:58 PM >> To: Vincent Roca >> Cc: IESG ; secdir@ietf.org; draft-ietf-nfsv4- >> rfc5666bis.all@ietf.org >> Subject: Re: Secdir review of draft-ietf-nfsv4-rfc5666bis-10 >>=20 >>=20 >>> On Feb 24, 2017, at 4:59 AM, Vincent Roca = wrote: >>>=20 >>> Hello, >>>=20 >>> I have reviewed this document as part of the security = directorate=E2=80=99s >>> ongoing effort to review all IETF documents being processed by the >>> IESG. These comments were written primarily for the benefit of the >>> security area directors. Document editors and WG chairs should = treat >>> these comments just like any other last call comments. >> ...=20 >> Hi Vincent- >>=20 >> Thanks for your review. >>=20 >> I believe your questions are mostly rhetorical, so I will respond to = those by >> saying the authors, shepherd, and AD will attempt to address these = issues with >> the next document revision. >>=20 >> There is one remaining comment that IMO needs group discussion, = below. >>=20 >>=20 >>> ** Privacy or confidentiality? Throughout section 8, authors mention >> "Privacy" inappropriately IMHO. >>> Privacy refers to PII (Personally identifiable information) which is = different. >> For instance in section 8.2, when saying: >>> "However, integrity and privacy services require significant = movement of >> data on each endpoint host." >>> the authors really mean confidentiality (this is mentioned just = above, >>> when saying that RPCSEC_GSS implements "per-message = confidentiality"). >> There are several mistakes of that kind throughout section 8. >=20 > Regarding "privacy", this term is used in the document because all the = NFS RFC's use it in this way. For example, RFC 7861 "Remote Procedure Call (RPC) Security Version 3" has this: =20 /// enum rpc_gss_service_t { /// /* Note: The enumerated value for 0 is reserved. */ /// rpc_gss_svc_none /// rpc_gss_svc_integrity /// rpc_gss_svc_privacy /// rpc_gss_svc_channel_prot =3D 4 /// }; The term "privacy" as used in rfc5666bis comes from RPCSEC. > While I agree with you that there is room for confusion, it would be = even wider if we switched terminology here. Perhaps we should consider replacing "per-message confidentiality" ? >> ... >>> ** Last sentence: >>> "To address attacks on RDMA protocols themselves, RDMA transport >> implementations should conform >>> to [RFC5042]." >>> "should" or "SHOULD"? >>=20 >> Lower case "should" is used here because this statement is IMO not an >> interoperability directive. I hope I correctly understand the intent = of your >> question. >>=20 >> If there is a security requirement that this be changed to the RFC = 2119 term, >> please let us know and that can be done. >=20 > I don't think SHOULD is appropriate here. This statement refers to = other protocols, in particular lower layers then this document, and in = the case of the relevant IETF RDMA protocols, RFC5042 is already a = required conformance. Therefore the statement is informational here, and = not an RFC2119 usage. >=20 > Tom. >=20 -- Chuck Lever From nobody Sat Feb 25 23:01:21 2017 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3B8212989D; Sat, 25 Feb 2017 23:01:15 -0800 (PST) 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 kJp7d9ot9M-v; Sat, 25 Feb 2017 23:01:13 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31502129630; Sat, 25 Feb 2017 23:01:13 -0800 (PST) Received: from [192.168.3.83] (unknown [181.165.116.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id BC5FA809EA; Sun, 26 Feb 2017 08:01:07 +0100 (CET) To: ietf@ietf.org References: <148599296506.18647.12389618334616420462.idtracker@ietfa.amsl.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: Date: Sun, 26 Feb 2017 03:42:08 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <148599296506.18647.12389618334616420462.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-6man-rfc2460bis@ietf.org, ipv6@ietf.org, "secdir@ietf.org" , suresh.krishnan@ericsson.com, =?UTF-8?Q?Iv=c3=a1n_Arce?= , "sec-ads@ietf.org" , 6man-chairs@ietf.org Subject: Re: [secdir] Last Call: (Internet Protocol, Version 6 (IPv6) Specification) to Internet Standard X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Feb 2017 07:01:15 -0000 Folks, Page 15 of the document says: For every packet that is to be fragmented, the source node generates an Identification value. The Identification must be different than that of any other fragmented packet sent recently* with the same Source Address and Destination Address. If a Routing header is present, the Destination Address of concern is that of the final destination. * "recently" means within the maximum likely lifetime of a packet, including transit time from source to destination and time spent awaiting reassembly with other fragments of the same packet. However, it is not required that a source node know the maximum packet lifetime. Rather, it is assumed that the requirement can be met by implementing an algorithm that results in a low identification reuse frequency. Examples of algorithms that can meet this requirement are described in [RFC7739]. This is certainly an improvement over RFC2460, which suggested the use of a simple counter to achieve this requirement. While the algorithms in RFC7739 are meant to result in non-predictable (by off-path attackers) Identification values, I believe that this spec should clarify that Identification values should not be predictable by off-path attackers. The survey in Appendix B of RFC7739 () shows some sample popular implementations that, unfortunately, still employ predictable Identification values. Given too-frequent pattern of protocol implementations employing improper numeric-identifier generators (see ) and ), I think an explicit requirement is warranted. Thanks, Fernando On 02/01/2017 08:49 PM, The IESG wrote: > > The IESG has received a request from the IPv6 Maintenance WG (6man) to > consider the following document: > - 'Internet Protocol, Version 6 (IPv6) Specification' > as Internet Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2017-03-01. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > This document specifies version 6 of the Internet Protocol (IPv6). > It obsoletes RFC2460 > > > > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-6man-rfc2460bis/ > > IESG discussion can be tracked via > https://datatracker.ietf.org/doc/draft-ietf-6man-rfc2460bis/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > > The document contains these normative downward references. > See RFC 3967 for additional information: > rfc4443: Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification (Draft Standard - IETF stream) > rfc3168: The Addition of Explicit Congestion Notification (ECN) to IP (Proposed Standard - IETF stream) > Note that some of these references may already be listed in the acceptable Downref Registry. > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sun Feb 26 07:03:54 2017 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1B85129462; Sun, 26 Feb 2017 07:03:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.102 X-Spam-Level: X-Spam-Status: No, score=-0.102 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=tobias.gondrom@gondrom.org header.d=gondrom.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 0E2luIxl2whh; Sun, 26 Feb 2017 07:03:46 -0800 (PST) Received: from gondrom.org (www.gondrom.org [5.35.241.16]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33F231204D9; Sun, 26 Feb 2017 07:03:46 -0800 (PST) Received: from seraph (unknown [103.70.220.18]) by gondrom.org (Postfix) with ESMTPSA id 784C564899; Sun, 26 Feb 2017 16:03:42 +0100 (CET) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=lsQk81XtGFo0sme5FpyAYUy6Mh/hZ6YwEf0z08+URfnxpkK6G6wulxUmP6aaw6d29t2LCMzRkPBWcviICPVeMTJX4556uL9N7/RmArvWldrvzkvtPFKMtz1CqJ4hdK7SVZcEPU+KrpoUnCXgVHX4SX4XBq2IhBJ3hxAIJLhKGwo=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type:X-Mailer:Thread-Index:Content-Language; From: "Tobias Gondrom" To: "'secdir'" Date: Sun, 26 Feb 2017 23:03:31 +0800 Message-ID: <022e01d29041$84daee20$8e90ca60$@gondrom.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_022F_01D29084.93007810" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdKQP7C3F07hiElCR1SP8L/pQN7qtg== Content-Language: en-us Archived-At: Cc: 'The IESG' Subject: [secdir] SecDir Review of draft-ietf-urnbis-rfc2141bis-urn-20 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Feb 2017 15:03:48 -0000 This is a multipart message in MIME format. ------=_NextPart_000_022F_01D29084.93007810 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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. draft-ietf-urnbis-rfc2141bis-urn-20: Uniform Resource Names (URNs) Updates: 2141, 3406 Intended status: Standards Track IMO the document is ready for IESG approval. I have no further additions or comments. Section 6.4.4. Security and Privacy covers security and privacy concerns mostly by referencing considerations from RFC6943, 3552 and 6973. Overall, I think it is sufficient. I also noted the shepherd document with regard to the overall working group consensus on this document: https://datatracker.ietf.org/doc/draft-ietf-urnbis-rfc2141bis-urn/shepherdwr iteup/ Best regards, Tobias ------=_NextPart_000_022F_01D29084.93007810 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have = reviewed this document as part of the security directorate's ongoing = effort to review all IETF documents being processed by the IESG. These = 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.

 

draft-ietf-urnbis-rfc2141bis-urn-20:=

Uniform Resource Names = (URNs)

Updates: 2141, 3406 =

Intended status: Standards = Track  

 

IMO the = document is ready for IESG approval.

I have = no further additions or comments.

Section = 6.4.4.  Security and Privacy covers security and privacy concerns = mostly by referencing considerations from RFC6943, 3552 and 6973. =

Overall, I think it is sufficient. =

 

I also = noted the shepherd document with regard to the overall working group = consensus on this document:

https://datatracker.ietf.org/doc/draft-ietf-urnbis-rfc= 2141bis-urn/shepherdwriteup/

 

Best regards, = Tobias

 

------=_NextPart_000_022F_01D29084.93007810-- From nobody Sun Feb 26 12:34:00 2017 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D69C6127A90; Sun, 26 Feb 2017 12:33:59 -0800 (PST) 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 2qmYKEXWsTEV; Sun, 26 Feb 2017 12:33:58 -0800 (PST) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::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 D22BE127735; Sun, 26 Feb 2017 12:33:55 -0800 (PST) Received: by mail-pg0-x232.google.com with SMTP id p5so10789954pga.1; Sun, 26 Feb 2017 12:33:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version; bh=TBsAyXZ0iu+BtsOOkmtw6rr7ug+6i938unVQZM7C5/E=; b=Sw/B9Nu/Y1K6J46WANwwHfv2VBmal4nCtDAYN3HDduDEYBpQzTAmCEDx2OwygHo7EC 0xVLOXmM56UIz3Pz/S+aLQXoxpuA4NUG//fQIEX2+qJaCpAF0kNgShK7a3T6GGK7mr2u rzFvy5ZLcDUVKjMsNYWgw8Jfmdy4RWk/TeLEj/Ihym5T+s7raBCRugwYTeMG/7lKIEZu HJcSZqQS+cc8dqi4baq6B3vu5qQwfbFJMhBrsBl3ZC411VB6vdeHJn4fIgxhFD5yAWcn ptqg1ie+uhMdMV2/FZtIsmboH/GKCNBMwJKHgvmFXU6EVlQK7pvyeibs0GeVUzfv/lHV CLYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version; bh=TBsAyXZ0iu+BtsOOkmtw6rr7ug+6i938unVQZM7C5/E=; b=rRu1HjzFaXctMm1lVzB4P/iUhTd21Oj0/fHy0/h1kjmQU1i8kepQsOQWUux3NnG7/C Bbin9Ee9jB8vlwzHFjDH6Z8zS+rAvHieJK5Som43efSSqio6vOg6HTrwX9okwZKMl+DV Zkj1kF1TRjHDYYdBqNXJWxx8s6BhcWZKiRiR/v9R/b78qEirzP1noz6ouHXEVDvO+dq1 hRMX4dG7efY1oJlM+W2eq3oX/Dpr1PjzObJvgHBdjkOk9toqQQlsQSQ/9oyGklC0pLcZ 038TAX9RKi666s0HmEI2jB55HWnz6gnp9AK2YrEw3sKNqHgb1AzCyYJ5917h5TFqvCWj Q1SQ== X-Gm-Message-State: AMke39m9TUa0P7RWVmAn8aCHsZLaqLO8JYjSfaeOdf8VniBIbm6Z8UqT5b3AK/hlbuRcHw== X-Received: by 10.98.41.5 with SMTP id p5mr16877752pfp.183.1488141234823; Sun, 26 Feb 2017 12:33:54 -0800 (PST) Received: from Melindas-MacBook-Pro.local (63-140-84-215-radius.dynamic.acsalaska.net. [63.140.84.215]) by smtp.gmail.com with ESMTPSA id u75sm20553223pfk.3.2017.02.26.12.33.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Feb 2017 12:33:54 -0800 (PST) To: secdir@ietf.org, iesg@ietf.org, draft-sgtatham-secsh-iutf8.all@ietf.org From: Melinda Shore Message-ID: Date: Sun, 26 Feb 2017 11:33:51 -0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="2TXfdiGDKOln4JETCTSqNUOHtLaFW1R1b" Archived-At: Subject: [secdir] SECDIR review of draft-sgtatham-secsh-iutf8 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Feb 2017 20:34:00 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --2TXfdiGDKOln4JETCTSqNUOHtLaFW1R1b Content-Type: multipart/mixed; boundary="SgoOe46dXEGcENTJb2KGP0X9PONEknkFx"; protected-headers="v1" From: Melinda Shore To: secdir@ietf.org, iesg@ietf.org, draft-sgtatham-secsh-iutf8.all@ietf.org Message-ID: Subject: SECDIR review of draft-sgtatham-secsh-iutf8 --SgoOe46dXEGcENTJb2KGP0X9PONEknkFx Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: ready with some incredibly minor nits This document adds a new opcode to ssh terminal modes, to match the iutf8 flag in the Linux terminal driver. This draft has been implemented in openssh and putty. There are no additional security concerns introduced by this draft beyond those already documented in RFC 4254. The nits checker didn't like the spacing in the table in section 4. There's an unused reference (UNICODE). Otherwise it's clean. Melinda --SgoOe46dXEGcENTJb2KGP0X9PONEknkFx-- --2TXfdiGDKOln4JETCTSqNUOHtLaFW1R1b Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJYszuwAAoJELiGRpM6HoEuvKcP/0nz/m1NLegW7xBU58UJtiKn IcO+UTQuicec9SuZQ8v31ImZdbij4GN63qBIwVzg40hlVgof7OhV7FUT3qs51//o 7Xh3lt2c7hQQlhTXcjXXGZHEQtrP+Y3ahyi6LpwvTE339+bmTK7jgoOG84br9+SB hG3hFDPxUvGBC7Og7XVuGsbBzab3EUfSffUnnU+C25bX3VPoKKA0Vgrw1yHKim49 IP2zXhmTl+XILISfluMv0b2xvvxQ6zaF/Ie0VbeiDZQgXdCnikHy5ZUbrdBp3VCY xB42b8k4cnaBWEX6bEgcT3HhFw1mdJCdjKMIiPnWZzc/oKDIpb9p38NOJRMFKos8 9dtlvQ9ICfAwf5Nm3LPUUVMmqI3C7kp5DxRNrL2N/tWGIp8sNhvh31dImV1nty2B 1CPfJP2Bv7FMxazvaR1itPVBHZawKcqIy1C3f/Z7kAMv8trcVmPUo4Zql3MIsAUJ y9xjDOtssglffy5VhGG+tVwbycWtegvKxFIJ9MdPjNovNS20zdFnW+ZS9Z2j0kq0 FLao6By6HoVAV83S5fLrxy4o1ARFCoTEEzzoOJHudE7K5FvrP5FRV+Ncc+bxr2qb Ic5wU+J/bhpdkgaAOuhsBESdnSiFaXsfspVUuq36u544nG0A5t+H1ecWc2RzqXSW qHmwrZFcZ5BcEVAhm2hW =RQht -----END PGP SIGNATURE----- --2TXfdiGDKOln4JETCTSqNUOHtLaFW1R1b--